eric@snark.thyrsus.com (Eric S. Raymond) (12/23/90)
Ten Things I Hate About UNIX
(by a UNIX weenie who has
(at least for the duration of this message)
Seen the Light...)
1. The @!$#! file system is so stupid that it has to masturbate for
three to five minutes before it's sure it's retained enough of
its vitality to let me boot up.
2. X. Don't get me started about X. Only in X could you need to write
three pages of Old Sanskrit to do "Hello, world!". Yes, X, the
window system so hoglike and slow that it brings even RISC machines
to their knees. And the X documentation? Don't make me laugh...
3. Kitchen-sink kernels that enshrine every incompatible special-purpose
hack in the last ten years. Fer cripes' sake, who *needs* cruft
like the Indian Hill IPC package or ioctl handlers for every I/O device
more recent than a @#!$% stone tablet to be resident all the time?
4. Four different (and, of course, mutually incompatible) wild-carding
notations. Was that `.' or `?', sir? Do you want `*' or `.*',
sir? Can I use `+' here? or `|' here? Sheesh...
5. The `editor' vi. Oh, this is a good one. Don't you just *love*
insert vs, command mode? Doesn't it make your day to press an arrow
key and get `[[B' munged into your text?
6. The $#@&!!# default octal escapes in all the tools, which we're
stuck with forever because Ritchie thought it was more important
to support hand-hacking three-bit PDP11 opcode fields than to be
able to actually read data dumps on a byte-addressable machine.
7. The pcc compiler, perpetually about three to five years behind the
times and the *only* major implementation not to support the bloody
ANSI standard (not that X3J11 doesn't have its own share of brain-
damage).
8. Data dependencies in all those nice clean `filters' UNIXoids like to
rave about. Did you ever try passing nulls for a graphics escape
through nroff or the print spooler? Or typing high-half graphics
characters to cat(1) through the shell's `cooked' line discipline?
Yeah, you'll find out about `cooked' all right...
9. Text-processing tools that `silently truncate' long lines.
Better than that: fixed-length buffers as far as the eye can see in
tools with no input-length checks, so you can garbage static data,
smash your stack or worse (``worse'' as in the RTM worm).
10. And there's no !@#$@ legal *source* any more for less than the
approximate yearly GNP of a small third-world nation, so I can't
*fix* things. *That* is the most unkindest cut of all.
--
Eric S. Raymond = eric@snark.thyrsus.com (mad mastermind of TMN-Netnews)
P.S.:
Serious replies to this will be flushed.bzs@world.std.com (Barry Shein) (12/23/90)
(Followups redirected to alt.religion.computers) Ok, I'll take the bait...probably a slow week anyhow. From: eric@snark.thyrsus.com (Eric S. Raymond) >1. The @!$#! file system is so stupid that it has to masturbate for > three to five minutes before it's sure it's retained enough of > its vitality to let me boot up. Encore and other systems have had a "clean" bit for years, if a file system is unmounted cleanly (e.g. orderly shutdown) then a bit in the superblock is marked which means "don't bother fsck'ing this file system". It really works. I believe Sun has been touting some sort of faster fsck tho it might be an unbundled product (?) >2. X. Don't get me started about X. Only in X could you need to write > three pages of Old Sanskrit to do "Hello, world!". Yes, X, the > window system so hoglike and slow that it brings even RISC machines > to their knees. And the X documentation? Don't make me laugh... X has been referred to as the OS/370 of Unix. Certainly the .Xdefaults file rivals JCL in complexity and even has a very similar philosophy and format (e.g. everything you leave out defaults to something which is practically impossible to know what and is not what you want.) And for all this X is horribly device/resolution dependant. That might be excusable if the libraries/toolkits hid this, but they don't. In fact, from what I've seen, they make it worse (bury resolution assumptions into ever more complex data structures with ever more magical properties.) So we tend to agree. We (the community) don't know what the hell we're doing with these window systems. They're botched, and what some seem to think is progress is just stupidity. (Dropshadows, who the hell needs dropshadows, the moral equivalent of putting fins on automobiles to try to make you think they're more aerodynamic that way. Oh boy, dropshadows, MUST BE EASY TO USE!) More and more pixels doing less and less work. As a product reviewer I often get two copies of a product, one touting an "openlook" interface and the other "motif". It almost brings me to tears when I realize that all they really mean is that one has rounded buttons and the other has square ones with dramatic dropshadows. I mean, someone spent *time* on that (or at least making their software able to link into either library.) Probably the biggest waste of human effort since the invention of car wax. >3. Kitchen-sink kernels that enshrine every incompatible special-purpose > hack in the last ten years. Fer cripes' sake, who *needs* cruft > like the Indian Hill IPC package or ioctl handlers for every I/O device > more recent than a @#!$% stone tablet to be resident all the time? This is true, but I keep hoping vendors and other people will fix this by making it all easy to configure out. I doubt SVR4 specifies that this crap has to be resident, just available (if not, so much for that effort...) Obviously we've got marketroids driving this stuff and all they think about is what percentage of the market they might be able to cover. Of course, the only answer is add more and more, no matter how ill-considered, so they can theoretically sell their boxes to anyone. If cars were designed like this we'd all have amphibious four-wheel drive station wagons with racing stripes capable of hauling 50K LB loads and outfitted with active armor and gun-turrets (can't forget that military market!) Pencils are general purpose also, like computers, but no one suggests putting ink in them to make sure we don't insult the indelible market. >4. Four different (and, of course, mutually incompatible) wild-carding > notations. Was that `.' or `?', sir? Do you want `*' or `.*', > sir? Can I use `+' here? or `|' here? Sheesh... I don't see this as a big problem, could use some better proposals I suppose. >5. The `editor' vi. Oh, this is a good one. Don't you just *love* > insert vs, command mode? Doesn't it make your day to press an arrow > key and get `[[B' munged into your text? "rm /usr/ucb/vi /usr/ucb/ex" fixes this, so hard to get excited about. Not that I hate vi, I use it all the time even tho my primary editor is GNU emacs. But for those that hate it the fix is easy enough and available to all. I consider "view" to be "less" done right. >6. The $#@&!!# default octal escapes in all the tools, which we're > stuck with forever because Ritchie thought it was more important > to support hand-hacking three-bit PDP11 opcode fields than to be > able to actually read data dumps on a byte-addressable machine. Minor, how often do you really run into this as a problem? >7. The pcc compiler, perpetually about three to five years behind the > times and the *only* major implementation not to support the bloody > ANSI standard (not that X3J11 doesn't have its own share of brain- > damage). The existence of gcc makes this a minor problem. >8. Data dependencies in all those nice clean `filters' UNIXoids like to > rave about. Did you ever try passing nulls for a graphics escape > through nroff or the print spooler? Or typing high-half graphics > characters to cat(1) through the shell's `cooked' line discipline? > Yeah, you'll find out about `cooked' all right... Any OS perpetually needs "modernizing" which involves a lot of drudgery, going thru zillions of little utilities and subroutine libraries and cleaning them up. This falls into the same category as the internationalization problems. I assume the only real problem is inertia and the desire to do some new zingy thing rather than cleaning these things up. The main thing we can say in Unix's favor is it's probably the first and only OS that anyone has even considered demanding this kind of modernization in. Is there an int'l charcter version of VMS? Can you process GIF files with CMS's REXX? Would anyone even bother suggesting such things? >9. Text-processing tools that `silently truncate' long lines. > Better than that: fixed-length buffers as far as the eye can see in > tools with no input-length checks, so you can garbage static data, > smash your stack or worse (``worse'' as in the RTM worm). Similar to 8. >10. And there's no !@#$@ legal *source* any more for less than the > approximate yearly GNP of a small third-world nation, so I can't > *fix* things. *That* is the most unkindest cut of all. "Fixed in the next release". Don't lose the faith. -- -Barry Shein Software Tool & Die | {xylogics,uunet}!world!bzs | bzs@world.std.com Purveyors to the Trade | Voice: 617-739-0202 | Login: 617-739-WRLD
eric@snark.thyrsus.com (Eric S. Raymond) (12/23/90)
In <1Yst7y#1yY2sB8TrJ2w0Gc4SK4BkdGO=eric@snark.thyrsus.com> I wrote:
> Ten Things I Hate About UNIX
I wasn't going to explain this, but since I've already gotten one dyspeptic
note...it was a joke, son. A joke. I wrote it for the unix-haters mailing
list, which I need to be on for some folklore research. I thought this
crowd might get a giggle out of it.
I gather I should have close-captioned it for the humor-impaired.
--
Eric S. Raymond = eric@snark.thyrsus.com (mad mastermind of TMN-Netnews)john@newave.UUCP (John A. Weeks III) (12/28/90)
In article <1Yst7y#1yY2sB8TrJ2w0Gc4SK4BkdGO=eric@snark.thyrsus.com> eric@snark.thyrsus.com (Eric S. Raymond) writes: > Ten Things I Hate About UNIX > (by a UNIX weenie who has Seen the Light...) I used to be frusterated working with UNIX while I was in school. Afterall, I had the world's best computer at home--a Macintosh! But during my first computer job, I had to do some hacking in FORTRAN on an IBM/43xx using nothing more than X-EDIT (a line editor from hell). That's when I learned to really like "vi", and UNIX didn't look all that bad after that experience. -john- -- =============================================================================== John A. Weeks III (612) 942-6969 john@newave.mn.org NeWave Communications ...uunet!rosevax!tcnet!wd0gol!newave!john ===============================================================================