jgd@Dixie.Com (John G. DeArmond) (03/20/91)
rcd@ico.isc.com (Dick Dunn) writes: >I think the "cost per pound" of software has not gone up that much! I'm >serious--I think that if you check $/Mb, you'll find it's level or even >down. (The issue of whether you want all those extra Mb in the package is >a separate one--that's not my point here.:-) :-) Funny you'd mention that. We just got our ISC OFFICIAL ISV kit in today. The UPS man will never be the same. And yes, I WOULD like to return, oh, perhaps 10 lbs of that. >If you'd seen the figures coming out as V.4 emerged, you would have been >amazed at the amount of new/changed code with each delivery. We're talking >time frame of months and change/new amounts of 10^5-10^6 lines. That costs >money. Again, you can argue whether it's money well-spent, and/or whether >you really want to pay for it, but don't think the OS is a cash cow sitting >in the corner that you just milk whenever you want money. >Actually, John, in another place you used the Toyota analogy, which I like >a little better than hotrod, but be that as it may. This brings me back to >my original ranting. Sure, I want a Toyota-like OS...but I'm atypical. >And I don't believe 1968; I say the OS market stands today about where >cars did in '59. > In '91, people want a big OS with all the features and a chrome-plated > bas-relief GUI at any cost. They don't care if it wastes memory or > it's slow--memory is cheap and CPUs keep getting faster. I think > Peter's idea of "UNIX Classic" is neat, but I doubt you could give it > away to more than a handful of people. Sorry guy, I gotta disagree. I'd hate to see Unix go the way of DOS and start putting in what I call "Road Test" features; ie, those features that make dumbsh*t magazine reviewers babble but annoy the people who use the stuff all day. I can't believe that Atlanta is that much different than the rest of the country. I get around quite a bit in the Unix community here. I see only spots of feeping creaturism, mostly with people who wanna play the windows game. Most of us just want stable, functional and high performance platforms. And while we're talking about Release 4, I'd rather not. I used to think that Unix was a product too good for even AT&T to kill. With Release 4, I'm not so sure. Well hey, this is a network, let's do a little survey. A hand count will do. (If anyone actually wants to answer these questions, I'll tally 'em.) Question 1: How many people are wetting their pants waiting for System 4 on a PC platform. Hmm... A hand or 2. Well, there's always those types. After all, some people buy RS/6000s too. Question 2: Given a mythological Unix vendor, call it ISC, would you rather see this vendor put its resources in System 4 or would you rather see those resources put into making release 3.xxx more stable, more secure, faster, and last but not least, not have the Inode bug? Hmm, looks damn near unanamous for release 3. Question 3: Same premise but the alternative this time is this company sinking its resources in merging in Berkely functionality and compatability and maybe even getting with other vendors to try again to merge sys V and Berkely. Hmm. I did not know middle aged programmers could do double back flips. Question 4: How many people would just kill for a high performance K&R compiler with ANSI and POSIX relegated to the 4 letter word file? And a shared library facility that is a bit less brain dead in the process? Hmmm. Anybody remember the first aid for hyperventillation? Well there you have it. Leading programmers everywhere vote for stable, reliable, functional and high performance platforms. By overwhelming margins, programmers and managers hate porting and really want to devise workarounds to bugs once and get on with business rather then being presented with a whole new world every morning. And finally, we want to know what it would take to get AT&T declared an unfit parent and have the custody of Unix delivered to the user community? >Alas, software standards activities are one of the biggest sources of >rampant, gratuitous feature frenzy. Have a look at the "international- >ization" goo that wants every program to be at least a page of code, and >which has propagated baroque national-collating-sequence requirements into >programs that heretofore had nothing to do with natural language issues. We're in 100% agreement here. If I could only get the ANSI committee in a dark room for 15 minutes.... How could any group of reportedly educated men take a splendedly functional language like C and break it so thoroughly? I'll stop that thread now that my blood pressure is aproaching 4 digits. >(This came about from the idiotic prejudice that ASCII somehow represents >a parochial US-English collating sequence.) Notice that we're going to get >to deal with ISO OSI in the lower network layers--not because TCP/IP had >problems there, but precisely because TCP/IP was an accepted, widely-used, >successful standard! (It was used too heavily in the US to be accepted:-) >Look at the trigraph wart in standard C--something that nobody really >wanted and that doesn't solve the problem anyway. Try to sort through the >chaos of how ttys are supposed to work. I could go on for megabytes. (Caution: An overtly nationalistic statement follows.) I've not figured out why America didn't just say NO! Dammit, we invented the language. We invented the OS. We invented the platforms. And we write most of the good software. Most of the rest of the technical world speaks English anyway. Seems like a take-it-or-leave-it attitude would fit well. We could have given them Pascal as a sacrificial language. Please! I suspect that this phenomena is based on a distorted version of "winners' humility" that America tends to indulge in. You know, what they taught you in elementary school about being a humble winner. America seems to have a need to pull itself down to the rest of the world. Oh well. Probably opens up another market for some vendor to offer "C classic" to go along with "Unix Classic" and a "TCP/IP Classic." Well, this thread has been fun. I hope we've given all the PC platform vendors something to think about. (My email indicates as much.) John -- John De Armond, WD4OQC | "Purveyors of speed to the Trade" (tm) Rapid Deployment System, Inc. | Home of the Nidgets (tm) Marietta, Ga | {emory,uunet}!rsiatl!jgd |"Politically InCorrect.. And damn proud of it
jeffl@comix.UUCP (Jeff Liebermann) (03/21/91)
In article <8451@rsiatl.Dixie.Com> jgd@Dixie.Com (John G. DeArmond) writes: >rcd@ico.isc.com (Dick Dunn) writes: > >>Alas, software standards activities are one of the biggest sources of >>rampant, gratuitous feature frenzy. Have a look at the "international- >>ization" goo that wants every program to be at least a page of code, and >>which has propagated baroque national-collating-sequence requirements into >>programs that heretofore had nothing to do with natural language issues. Try this sort benchmark with SCO Unix 3.2.x /bin/time /bin/sort /etc/termcap > /dev/null real 24.2 (3.2 v2 sort binary) user 21.5 sys 0.1 /bin/time /bin/sort.old /etc/termcap > /dev/null real 1.9 (3.2.0 sort binary) user 0.9 sys 0.2 The difference is that 3.2.2 sort is intenationalized, posix compliant and uses shared libraries while 3.2.0 does not. I was told by SCO that it was not a problem because the sort program still yields valid results. If your pathalias compiles take forever, use the 3.2.0 sort program instead. Reference Number #300715 reported 9/15/90. -- # Jeff Liebermann Box 272 1540 Jackson Ave Ben Lomond CA 95005 # (408)336-2558 voice (408)429-0483 digital pager wb6ssy CIS:73557,2074 # PC REPAIR & RF DESIGN. Committee Against Double Spacing And Wide Margins. # jeffl@comix.santa-cruz.ca.us uunet!comix!jeffl ucscc.ucsc.edu!comix!jeffl
sef@kithrup.COM (Sean Eric Fagan) (03/22/91)
In article <107@comix.UUCP> jeffl@comix.UUCP (Jeff Liebermann) writes: >I was told by SCO >that it was not a problem because the sort program still yields valid >results. No, you were told by me, from home, that SCO probably wouldn't consider it a bug, as it still works. Making it work more quickly is a feature; there are things that yield wrong results that need to be taken care of first. I never said it wasn't a problem. In fact, it really is a problem, just not a bug. -- Sean Eric Fagan | "I made the universe, but please don't blame me for it; sef@kithrup.COM | I had a bellyache at the time." -----------------+ -- The Turtle (Stephen King, _It_) Any opinions expressed are my own, and generally unpopular with others.
rcd@ico.isc.com (Dick Dunn) (03/23/91)
jgd@Dixie.Com (John G. DeArmond) gives us a straw poll: > ...I'd hate to see Unix go the way of DOS and > start putting in what I call "Road Test" features; ie, those features that > make dumbsh*t magazine reviewers babble but annoy the people who use the > stuff all day... I think it's already started. Look, we've got X, which is an interesting experiment but it's got too much stuff that isn't right, or that happens at the wrong level or in the wrong way. (What the heck; it's got too much stuff, period.) So what are we going to do about it? Nothing; forget it, man, it's cast in concrete. The magazine reviewers have decided that one for us; they've mostly decided the Motif/Open-Look question and they're working on the next level beyond that. There are software folk saying "ummm...shouldn't we break up this part of the foundation and re-pour it??" while these guys are taping the wallboard on the second floor. Of course, if it falls, it gonna fall on our haids. > Well hey, this is a network, let's do a little survey. A hand count will do. > (If anyone actually wants to answer these questions, I'll tally 'em.) > > Question 1: How many people are wetting their pants waiting for System 4 on > a PC platform. Hmm... A hand or 2. Well, there's always those types. > After all, some people buy RS/6000s too. John, wait! You counted carefully in our vicinity, but look over there in the distance...see that glare? It's the unFortunate 500...they heard you say something about more features, and that uncomfortable brightness is the sun glinting off the drool on a thousand well-polished Guccis. > Question 2: Given a mythological Unix vendor, call it ISC, would you rather > see this vendor put its resources in System 4 or would you rather see > those resources put into making release 3.xxx more stable, more secure, > faster, and last but not least, not have the Inode bug? Hmm, looks > damn near unanamous for release 3. Now something changed in the distance. The glare is gone; instead I hear a grim muttering out there...wait, I'm catching it...it sounds something like "must move on / at all cost / if we pause / all is lost." They're closer now; I can see a few YSL-logo checkbook covers showing in that special subtle-brandishing motion, not calling attention but being sure they're seen, the nonverbal equivalent of clearing the throat and noting with some severity, "excuse me; I'm not sure I heard what I hoped you meant to say..." Meanwhile, some of the programmers who had their hands in the air have now nervously looked over their shoulders and are adopting different gestures, with matching facial expressions..."Who? What? Dear me, no, I was just scratching my head at how anyone could propose such a preposterous question!"..."Just brushing my hair back"..."The SUN was in my eyes"... > Question 3: Same premise but the alternative this time is this company sinking > its resources in merging in Berkely functionality and compatability and > maybe even getting with other vendors to try again to merge sys V and > Berkely. Hmm. I did not know middle aged programmers could do > double back flips. John, John, John...you have to watch for more than a second... Serious misinterpretation. Look at them now; they're flopping about on the floor, as if reliving the anguish of the electroshock treatments that they needed after dealing with the last attempt to merge BSD and SysV. A few have passed out as they grasped the totality of what you've suggested: an obscenely difficult task in the best of all possible worlds, merging two systems to produce something which retains all features of both while becoming simpler, introduces no incompatibilities and exacts neither time nor space penalties...and now a task which must succeed on technical merit alone, against the arrayed marketing skills of AT&T, SUN, OSF, DEC, HPollo, IBM,... The situation could have turned ugly on us, except that the suits listened to what you said, watched the histrionics of the hackers, and decided it was all a big joke. They're forcing smiles, nervously adjusting their ties, and a few are trying to make amends by saying things like, "well, you had us going for a bit, future-plan-wise, but let me assure you that we do appreciate your concerns and we'll be hoping you keep us apprised vis-a-vis the technical implications, not to say that we can ignore the value of image and presentation for the long-term bottom line of next week, and per- haps we should do lunch sometime in the nebulous frostbitten-Hades not- quite-near-future term, so please have your email call the car-phone-for- warding fax-machine for my answering service." _ _ _ _ _ OK, back to reality (but only for a moment, I promise!:-). John, I agree with a lot of what you say. NOW: Show me where there's bucks in your way. That's not to say it couldn't happen! I just want to see if you really think there's a good business case for it. Put forth a straw-man for a stable system. It should take about a page to sketch to reasonable detail; it's not hard. See how many people (more to the point, how many potential licenses) will sign up for it. Oh, and while you're at it, go back through a week or so of comp.unix. sysv386. Note the folks who are grumbling that ISC won't have production V.4 until later in the year. (Dear me, they want it *right*now*, but I'll give you dollars to donuts they also wanted it tested!) Note the ones who can't understand why we haven't got all eleventy-seven displays (from $27 Hercules through the UltraTurboHypergraphics setups that cost more than the rest of the machine) converted to X11R4 yet. I point them out because these are people who aren't having any of your idea. > Question 4: How many people would just kill for a high performance K&R > compiler with ANSI and POSIX relegated to the 4 letter word file?... Let's be a bit careful here...as much as I would like to go "forward...into the past!", I'd also like to stop worrying about getting code from the out- side world that has to be hacked before I can use it--like stuff that's starting to come across in ANSI C, or the endless stream of BSDish stuff created with long file names that collide when truncated in SysVland... Actually, *I'D* probably be fairly happy with a compiler that would ignore differences between ANSIosity and K&R. ok, I promised we wouldn't stay long in reality... _ _ _ _ _ > Well there you have it. Leading programmers everywhere vote for stable, > reliable, functional and high performance platforms... Yeah, but who wants to sell to programmers? They're SUCH a surly lot, and anyway, they don't have the big bucks. (sprinkle liberally with ":-)" before roasting) -- Dick Dunn rcd@ico.isc.com -or- ico!rcd Boulder, CO (303)449-2870 The Official Colorado State Vegetable is now the "state legislator".
paul@frcs.UUCP (Paul Nash) (03/26/91)
Thus spake rcd@ico.isc.com (Dick Dunn): > > jgd@Dixie.Com (John G. DeArmond) gives us a straw poll: > > > > Question 3: Same premise but the alternative this time is this company > > its resources in merging in Berkely functionality and compatability > > maybe even getting with other vendors to try again to merge sys V and > > Berkely. Hmm. I did not know middle aged programmers could do > > double back flips. > > obscenely difficult task in the best of all possible worlds, merging two > systems to produce something which retains all features of both while > becoming simpler, introduces no incompatibilities and exacts neither time > nor space penalties...and now a task which must succeed on technical merit > alone, against the arrayed marketing skills of AT&T, SUN, OSF, DEC, > HPollo, IBM,... The best bet is probably to go back to Version 7, which didn't have all the feeping creaturitis, and start again. Oh, maybe tidy up the kernel, convert it to message-passing, so that device drivers are easier. And of course, we want the source code, so that we can add those features that we want. Maybe a detailed description of the code as well, because comments in the source are often not as descriptive as one might like. Best of all, it is available right now ... pay Prentice Hall $150 and get a copy of Minix. Your boss might not like it, but it sure is a relief after playing with V.4. ---=---=---=---=---=---=---=---=---=---=---=---=---=---=---=---=---=--- Paul Nash Free Range Computer Systems cc paul@frcs.UUCP ...!uunet!m2xenix!frcs!paul
edhall@rand.org (Ed Hall) (03/28/91)
In article <428@frcs.UUCP> paul@frcs.UUCP (Paul Nash) writes: >The best bet is probably to go back to Version 7, which didn't have >all the feeping creaturitis, and start again. Oh, maybe tidy up >the kernel, convert it to message-passing, so that device drivers >are easier. > . . . . > it is available right >now ... pay Prentice Hall $150 and get a copy of Minix. I'm not going to let this slight on UNIX Version 7 go uncountered. 1) I've read both the V7 kernel and MINIX, and I have to admit, I found V7 easier to follow. This isn't a fair test, since I worked with V7 first, but one might assume this would have helped with understanding MINIX. Both are tidy, if K&R Standard C can be called "tidy". Once I understood the idiom, V7 didn't *need* comments. 2) The message-passing nature of MINIX is the source of one of its worse bottlenecks--its kernel is single-threaded. Nowhere does this impact performance so much as in the filesystem. This could be fixed by adding message queues, and a lot of complexity. Andy T. says "never". 3) I've written device drivers for V7 and for MINIX. Once the whole wakeup/sleep mechanism is understood, V7 is as simple to write device drivers for as MINIX, and in some ways, easier. For instance, the various message formats allowed in MINIX can be restrictive or confusing. Messages must be passed in MINIX (say, between the FS and KERNEL) where V7 only needs to massage the appropriate data structure (perhaps between spl's). That said, I like MINIX, and think it is an excellent teaching vehicle and a source of great pleasure to folks who always wanted to hack OS's. Even in 1979 when it was released, UNIX V7 source was priced about the same as System V is now (after inflation) for non- Universities, keeping it out of the hands of hobbyists, while the restrictions placed on University licensing prevented it from being a teaching vehicle, at least for the scrupulous... However, I agree with the original sentiment concerning System V, and would apply it equally to BSD. Perhaps the MACH folks have the True Vision, even if they have yet to fulfill it. -Ed Hall edhall@rand.org