rcd@ico.isc.com (Dick Dunn) (04/13/91)
jerry@TALOS.UUCP (Jerry Gitomer) writes: > kemnitz@POSTGRES.BERKELEY.EDU (Greg Kemnitz) writes: [first painful encounter with X] > |...But it appears that it is easier to wait for fast > |machines rather than to design standard graphics protocols that aren't bloated, > |politically acceptable masses. Also, it appears that the de facto trend in > |industry is to hope hardware improves fast enough to let poorly written > |software run well rather than writing software properly, and it is hard to > |argue that this strategy has been a complete failure,... Note here: I don't see Greg arguing in favor of this approach; I read his argument as saying simply "it works (so far)". > I take exception to it being "hard to argue that this strategy > has been a complete failure". What I see is an industry that has > forgotten its brief past, ignored any research done more than ten > years ago, and is constantly moving from fad to fad. Yes to forgetting past, ignoring research, and being fad-oriented. But it's been profitable! Greg is saying the same thing as Jerry, as far as what the industry has done. Jerry says it's crazy, where Greg has with- held any value judgment other than noting (cynically) that on the bottom line, it works. It's not a complete failure because, while it may be a technical disaster, it sells. In my heart, I believe it's the royal road to disaster--I believe I can see a heat death coming. But what do I know? It hasn't happened yet, and there are very large companies making very large amounts of money selling bloated software. Can you make a convincing argument that says better, simpler software without all the goo will sell? Can you cite any market- place examples as evidence? I can't. Chrome sells. > Over 25 years ago IBM published data (I only have a copy of a > final published chart) illustrating that doubling the size of > a program quadrupled the cost of developing that program -- and > this held true regardless of the programming language used. OK, suppose that's true. There's good reason to believe it's true for a fair class of programs, because the number of potential interactions goes quadratically with size. So what? Sell more hardware to hold the larger programs; use some of the profit to hire more programmers. It works, just like cancer...and it sells! > Therefore, IMHO, today's baroque software is not only a complete > failure, but a fiasco... You can believe it's a fiasco (and I'll agree wholeheartedly), but it is NOT a failure, in the one sense that matters to the suits: It sells. > ...I believe that baroque is a synonymn for > broke. This bloated software is (generally speaking) noted for > substituting features no one really needs for the reliability that > every serious user needs. No doubt true. But it sells. OK, enough marketplace cynicism for a moment. What are we gonna DO about it? Anybody got any ideas for getting back to where UNIX started...to the "simplicity, elegance, and ease of use" that characterized it when R&T wrote about it in '74? I don't expect anything that will sweep the world; I'd settle for something that could find a comfortable niche. Do we have to wait for the current mess to collapse of its own weight, at which point it will be a crisis? Or is there a path out, or a way to start over, without getting sucked into the second-system effect? -- Dick Dunn rcd@ico.isc.com -or- ico!rcd Boulder, CO (303)449-2870 ...While you were reading this, Motif grew by another kilobyte.
mjr@hussar.dco.dec.com (Marcus J. Ranum) (04/13/91)
rcd@ico.isc.com (Dick Dunn) writes: > >In my heart, I believe it's the royal road to disaster--I believe I can see >a heat death coming. But what do I know? It hasn't happened yet [...] I admit this causes my mind to boggle, sometimes. By the time you look at the state of the U*IX watermelon (formerly kernel) and add the layered stuff on top of it, there is simply too much for any one person to understand well. This lack of understanding causes failures, and has a strong negative impact on the cost of products - development time increases, development costs increase, and the customer funds it. I don't agree with Dick - heat death is a long way off, and may never come. My suspicion is that U*IX and its associated layered stuff (windows systems, GUIs, utilities, compilers, etc) is already complicated past the point where any one person can truly be said to understand it all. Specialization is the result. In most large organizations that have a bunch of U*IX gurus around, there will typically be some kind of division of knowledge - some mess with X, some are into filesystems, some hack network stuff, and so on. This model works - it has worked in the past - if you go to a "typical IBM mainframe shop" you'll find the same kind of division of labor as a result of the sheer number of layers of arcana and backwards compatibility - a thin slice of compuarcheology. How many of your U*IX filesystems are a grotty web of symbolic links because systems software providers prefer to make a link: /usr/adm -> /var/adm rather than to simply *FIX* the applications that have hardcoded paths in them? Possibly these kinds of bletcherous backwards compatibility hacks will produce enough software friction that things will collapse from complexity. I want to applaud the guys at Berkeley - their efforts in separating pathnames out into stuff like pathnames.h is a good start, unfortunately the market is betrothed to the false god Backward Compatibility, who dictates that old mistakes must be preserved, and that the current U*IX scheme of "each system software package has its own configuration file someplace (undefined) each of which is written in a different syntax, none of which use the same API to access it". The market demands "commercial quality U*IX" but will not tolerate the momentary upset that fixing the grot would cause. In fact, because of all the "features" that would have to be provided to make a minimal "U*IX" that the market would like, it would take too long to produce - there's just too much sheer *stuff*. Currently any product on U*IX has about a page of copyrights and licensing credits, containing the names of just about every U*IX vendor out there. This is because there is just too much sheer *stuff* for anyone to throw it away and rewrite it cleanly, so any vendor who wants to market U*IX in a timely manner winds up licensing goo from all over the place. This adds to the customer's costs, and adds tremendously to complexity, as well as delaying shipping (sometimes) - all for what? >OK, enough marketplace cynicism for a moment. What are we gonna DO about >it? Educate the customer. As long as "informed consumer" remains an oxymoron, this will continue. If someone writes a public domain microkernel tomorrow that ran splendidly but couldn't support X11 - it'd be mostly ignored, and completely ignored by the "users" until some martyr grafted X onto it. mjr. -- Clearly, all these opinions are my own. My cats don't even agree with me.