4 ms·

It's ironic that this 30-year-old book, that was produced at a time when UNIX was not the colossus that it and related OSs are today, has been superseded by the

It's ironic that this 30-year-old book, that was produced at a time when UNIX was not the colossus that it and related OSs are today, has been superseded by the course of events. (Same as BYTE Magazine's 1995 cover story "Is UNIX Dead?" presaged its own death by only a few years.) Today, most computers (and phones, TVs, and household appliances also) run on UNIX or a related OS, while the Vaxes of 1994 have disappeared and the Windows Desktop is declining rapidly away. Author's Note: I have never used Windows as my 'daily driver'. I have used a UNIX Desktop throughout the 1990s, and a Linux Desktop since 2001.

kgwgk 3y ago
Worse is better.
KerrAvon 3y ago
I'm not sure about that. The Unixes that the book complains about have been completely out to pasture for a couple of decades. NeXT existed at the time and was specifically excluded.
- cafard 3y ago
  There's a snotty remark about Mach somewhere in there--does that count?
- DonHopkins 3y ago
  You know, your PDF reader probably has a search function, and the book itself has an index, which has numerous references to NeXT and NeXTSTEP. NeXT: 11, 14, 230, 296 NEXTSTEP: 11, 14, 54, 141 OpenStep: 14, 141 Page xxxi of The Unix-Haters Handbook mentions: "In fact, it was typeset using FrameMaker on a Macintosh, a Windows box, and a NeXTstation." (Affectionately called "PainMaker" by its victims.) I wrote three long paragraphs about NeXTSTEP (however you choose to spell and capitalize it), comparing it to NeWS and Display PostScript, in the X-Windows chapter. I even gave Steve Jobs a NeWS demo and a "NeRD" button at EduCOM, the month NeXTSTEP was finally released in November of 1988 (until then it was considered vaporware, and derisively called "NeVRSTEP" -- the critics even made t-shirts): >I gave a NeWS/Pie Menus/HyperTies/Emacs demo to Steve Jobs once, on the trade show floor at the Educom conference, right after he finally released the NeXT Machine, in November of 1988. >Sun was letting me demo NeWS and the stuff we were developing at the UMD Human Computer Interaction Lab on a workstation at their booth, and NeXT's booth was right across the aisle, so Ben Shneiderman rope-a-doped him and dragged him over for a demo. He jumped up and down and yelled "That sucks! That sucks! Wow, that's neat. That sucks!" >I figure a 3:1 sucks:neat ratio was pretty good for him comparing something different than his newborn baby NeXT Step, which critics had taken to calling NeVR Step, since it had been vaporware for so long until then. >When I tried to explain to him how flexible NeWS was, he told me "I don't need flexibility -- I got my window system right the first time!" And one of the editors, Simson Garfinkel <simsong@nextworld.com>, wrote a popular book about NeXTSTEP and was a senior editor at NeXTWORLD magazine. p. 11: Date: Wed, 20 Nov 91 09:37:23 PST From: simsong@nextworld.com To: UNIX-HATERS Subject: Unix names Perhaps keeping track of the different names for various versions of Unix is not a problem for most people, but today the copy editor here Standardizing Unconformity 11 at NeXTWORLD asked me what the difference was between AIX and A/UX. “AIX is Unix from IBM. A/UX is Unix from Apple.” “What’s the difference?” he asked. “I’m not sure. They’re both AT&T System V with gratuitous changes. Then there’s HP-UX which is HP’s version of System V with gratuitous changes. DEC calls its system ULTRIX. DGUX is Data General’s. And don’t forget Xenix—that’s from SCO.” NeXT, meanwhile, calls their version of Unix (which is really Mach with brain-dead Unix wrapped around it) NEXTSTEP. But it’s impossible to get a definition of NEXTSTEP: is it the window system? Objective-C? The environment? Mach? What? p. 13 (although the index says 14: blame PainMaker, which is riddled with features!): Sun Microsystems recently announced that it was joining with NeXT to promulgate OpenStep, a new standard for object-oriented user interfaces. To achieve this openness, Sun would will wrap C++ and DOE around Objective-C and NEXTSTEP. Can’t decide which standard you want to follow? No problem: now you can follow them all. p. 53 (although the index says 54, thanks PainMaker): Hmm… Excuse us for one second: % ls /lib cpp* gcrt0.o libsys_s.a cpp-precomp* i386/ m68k/ crt0.o libsys_p.a posixcrt0.o next% strings /lib/cpp-precomp | grep / /*%s*/ //%s /usr/local/include /NextDeveloper/Headers /NextDeveloper/Headers/ansi /NextDeveloper/Headers/bsd /LocalDeveloper/Headers /LocalDeveloper/Headers/ansi /LocalDeveloper/Headers/bsd /NextDeveloper/2.0CompatibleHeaders %s/%s /lib/%s/specs next% Silly us. NEXTSTEP’s /lib/cpp calls /lib/cpp-precomp. You won’t find that documented on the man page either: next% man cpp-precomp No manual entry for cpp-precomp. p. 140 (FrameMaker's index says 141): X Graphics: Square Peg in a Round Hole "Programming X Windows is like trying to find the square root of pi using roman numerals." —Unknown The PostScript imaging model, used by NeWS and Display PostScript, solves all these horrible problems in a high-level, standard, device independent manner. NeWS has integrated extensions for input, lightweight processes, networking, and windows. It can draw and respond to input in the same arbitrary coordinate system and define window shapes with PostScript paths. The Display PostScript extension for X is intended for output only and doesn’t address any window system issues, which must be dealt with through X. NEXTSTEP is a toolkit written in Objective-C, on top of NeXT’s own window server. NEXTSTEP uses Display PostScript for imaging, but not for input. It has an excellent imaging model and well designed toolkit, but the Display PostScript server is not designed to be programmed with interactive code: instead all events are sent to the client for processing, and the toolkit runs in the client, so it does not have the low bandwidth, context-switching, and code-sharing advantages of NeWS. Nevertheless, it is still superior to X, which lacks the device-independent imaging model. On the other hand, X’s spelling has remained constant over the years, while NeXT has at various times spelled their flagship product “NextStep,” “NeXTstep,” “NeXTStep,” “NeXTSTEP,” “NEXTSTEP,” and finally “OpenStep.” A standardized, consistent spelling is certainly easier on the marketing ’droids. Unfortunately, NeWS and NEXTSTEP were political failures because they suffer from the same two problems: oBNoXiOuS capitalization, and Amiga Persecution Attitude[TM]. p. 230 (hey FrameMaker got one right!!!): Footnote 2: Indeed, there are so many problems with partitioning in Unix that at least one vendor (NeXT, Inc.) recommends that disks be equipped with only a single partition. This is probably because NeXT’s Mach kernel can swap to the Unix file system, rather than requiring a special preallocated space on the system’s hard disk. p. 295 (FrameMaker guessed 296, two out of six ain't bad): Date: Wed, 18 Sep 1991 02:16:03 GMT From: meuer@roch.geom.umn.edu (Mark V. Meuer) Organization: Minnesota Supercomputer Institute Subject: Re: File find delay within Emacs on a NeXT To: help-gnu-emacs@prep.ai.mit.edu In article <1991Sep16.231808.9812@s1.msi.umn.edu> meuer@roch.geom.umn.edu (Mark V. Meuer) writes: I have a NeXT with version 2.1 of the system. We have Emacs 18.55 running. (Please don’t tell me to upgrade to version 18.57 unless you can also supply a pointer to diffs or at least s- and m- files for the NeXT.) There are several machines in our network and we are using yellow pages. The problem is that whenever I try to find a file (either through “C-x C-f”, “emacs file” or through a client talking to the server) Emacs freezes completely for between 15 and 30 seconds. The file then loads and everything works fine. In about 1 in 10 times the file loads immediately with no delay at all. Several people sent me suggestions (thank you!), but the obnoxious delay was finally explained and corrected by Scott Bertilson, one of the really smart people who works here at the Center. For people who have had this problem, one quick hack to correct it is to make /usr/lib/emacs/lock be a symbolic link to /tmp. The full explanation follows. I was able to track down that there was a file called !!!SuperLock!!! in /usr/lib/emacs/lock, and when that file existed the delay would occur. When that file wasn’t there, neither was the delay (usually). We found the segment of code that was causing the problem. When Emacs tries to open a file to edit, it tries to do an exclusive create on the superlock file. If the exclusive create fails, it tries 19 more times with a one second delay between each try. After 20 tries it just ignores the lock file being there and opens the file the user wanted. If it succeeds in creating the lock file, it opens the user’s file and then immediately removes the lock file. The problem we had was that /usr/lib/emacs/lock was mounted over NFS, and apparently NFS doesn’t handle exclusive create as well as one would hope. The command would create the file, but return an error saying it didn’t. Since Emacs thinks it wasn't able to create the lock file, it never removes it. But since it did create the file, all future attempts to open files encounter this lock file and force Emacs to go through a 20-second loop before proceeding. That was what was causing the delay. The hack we used to cure this problem was to make /usr/lib/emacs/lock be a symbolic link to /tmp, so that it would always point to a local directory and avoid the NFS exclusive create bug. I know this is far from perfect, but so far it is working correctly. Thanks to everyone who responded to my plea for help. It’s nice to know that there are so many friendly people on the net.
  - hulitu 3y ago
    > The PostScript imaging model, used by NeWS and Display PostScript, solves all these horrible problems in a high-level, standard, device independent manner. We have evolved. Now we draw "surfaces" (to draw a cursor). /s
1vuio0pswjnm7 3y ago
"Author's Note: I have never used Windows as my 'daily driver'." What about Apple MacIntosh. Depending on employer, it's not easy to have never used Windows or Mac. Must be one of the lucky ones. Even at university, I recall rooms of computers and printers set up for students' word processing use had DOS/Windows loaded on them. Labs had Macs. Above all the rest, I always preferred the room with the VAX and later the UNIX accounts we got. To me, it's not that UNIX is objectively good, it's that the alternatives have all been inferior. To someone else, that might not be true. I am not fond of GUIs. Other people might love them. Regardless of peoples' varied personal opinions, UNIX is still around and I'm using it every day by choice. No GUI.
- simonblack 3y ago
  Depending on employer, it's not easy to have never used Windows or Mac True, but all I needed to use Windows at work was one dedicated app. (And actually that app was purely UCSD Pascal under the hood, but running as a guest under Windows.) At home, I thankfully used my AT&T UNIX, then my Novell Unixware, and finally my Solaris I and II, before I switched to Linux in 2001. In the mid-90s I thought I would look at this 'new-fangled, best thing since sliced bread' thing called Windows 3.1. I was disgusted at how primitive and useless it was compared to my normal Unixware desktop of the time. I actually bought my wife a PowerBook in 2005. But I was horrified to discover that Apple is really no different to Microsoft.
- hulitu 3y ago
  >What about Apple MacIntosh. Apple is too expensive and lacks the programs needed for development. No CAD programs.

kgwgk 3y ago

Worse is better.

KerrAvon 3y ago

I'm not sure about that. The Unixes that the book complains about have been completely out to pasture for a couple of decades. NeXT existed at the time and was specifically excluded.

cafard 3y ago
There's a snotty remark about Mach somewhere in there--does that count?
DonHopkins 3y ago
You know, your PDF reader probably has a search function, and the book itself has an index, which has numerous references to NeXT and NeXTSTEP. NeXT: 11, 14, 230, 296 NEXTSTEP: 11, 14, 54, 141 OpenStep: 14, 141 Page xxxi of The Unix-Haters Handbook mentions: "In fact, it was typeset using FrameMaker on a Macintosh, a Windows box, and a NeXTstation." (Affectionately called "PainMaker" by its victims.) I wrote three long paragraphs about NeXTSTEP (however you choose to spell and capitalize it), comparing it to NeWS and Display PostScript, in the X-Windows chapter. I even gave Steve Jobs a NeWS demo and a "NeRD" button at EduCOM, the month NeXTSTEP was finally released in November of 1988 (until then it was considered vaporware, and derisively called "NeVRSTEP" -- the critics even made t-shirts): >I gave a NeWS/Pie Menus/HyperTies/Emacs demo to Steve Jobs once, on the trade show floor at the Educom conference, right after he finally released the NeXT Machine, in November of 1988. >Sun was letting me demo NeWS and the stuff we were developing at the UMD Human Computer Interaction Lab on a workstation at their booth, and NeXT's booth was right across the aisle, so Ben Shneiderman rope-a-doped him and dragged him over for a demo. He jumped up and down and yelled "That sucks! That sucks! Wow, that's neat. That sucks!" >I figure a 3:1 sucks:neat ratio was pretty good for him comparing something different than his newborn baby NeXT Step, which critics had taken to calling NeVR Step, since it had been vaporware for so long until then. >When I tried to explain to him how flexible NeWS was, he told me "I don't need flexibility -- I got my window system right the first time!" And one of the editors, Simson Garfinkel <simsong@nextworld.com>, wrote a popular book about NeXTSTEP and was a senior editor at NeXTWORLD magazine. p. 11: Date: Wed, 20 Nov 91 09:37:23 PST From: simsong@nextworld.com To: UNIX-HATERS Subject: Unix names Perhaps keeping track of the different names for various versions of Unix is not a problem for most people, but today the copy editor here Standardizing Unconformity 11 at NeXTWORLD asked me what the difference was between AIX and A/UX. “AIX is Unix from IBM. A/UX is Unix from Apple.” “What’s the difference?” he asked. “I’m not sure. They’re both AT&T System V with gratuitous changes. Then there’s HP-UX which is HP’s version of System V with gratuitous changes. DEC calls its system ULTRIX. DGUX is Data General’s. And don’t forget Xenix—that’s from SCO.” NeXT, meanwhile, calls their version of Unix (which is really Mach with brain-dead Unix wrapped around it) NEXTSTEP. But it’s impossible to get a definition of NEXTSTEP: is it the window system? Objective-C? The environment? Mach? What? p. 13 (although the index says 14: blame PainMaker, which is riddled with features!): Sun Microsystems recently announced that it was joining with NeXT to promulgate OpenStep, a new standard for object-oriented user interfaces. To achieve this openness, Sun would will wrap C++ and DOE around Objective-C and NEXTSTEP. Can’t decide which standard you want to follow? No problem: now you can follow them all. p. 53 (although the index says 54, thanks PainMaker): Hmm… Excuse us for one second: % ls /lib cpp* gcrt0.o libsys_s.a cpp-precomp* i386/ m68k/ crt0.o libsys_p.a posixcrt0.o next% strings /lib/cpp-precomp | grep / /*%s*/ //%s /usr/local/include /NextDeveloper/Headers /NextDeveloper/Headers/ansi /NextDeveloper/Headers/bsd /LocalDeveloper/Headers /LocalDeveloper/Headers/ansi /LocalDeveloper/Headers/bsd /NextDeveloper/2.0CompatibleHeaders %s/%s /lib/%s/specs next% Silly us. NEXTSTEP’s /lib/cpp calls /lib/cpp-precomp. You won’t find that documented on the man page either: next% man cpp-precomp No manual entry for cpp-precomp. p. 140 (FrameMaker's index says 141): X Graphics: Square Peg in a Round Hole "Programming X Windows is like trying to find the square root of pi using roman numerals." —Unknown The PostScript imaging model, used by NeWS and Display PostScript, solves all these horrible problems in a high-level, standard, device independent manner. NeWS has integrated extensions for input, lightweight processes, networking, and windows. It can draw and respond to input in the same arbitrary coordinate system and define window shapes with PostScript paths. The Display PostScript extension for X is intended for output only and doesn’t address any window system issues, which must be dealt with through X. NEXTSTEP is a toolkit written in Objective-C, on top of NeXT’s own window server. NEXTSTEP uses Display PostScript for imaging, but not for input. It has an excellent imaging model and well designed toolkit, but the Display PostScript server is not designed to be programmed with interactive code: instead all events are sent to the client for processing, and the toolkit runs in the client, so it does not have the low bandwidth, context-switching, and code-sharing advantages of NeWS. Nevertheless, it is still superior to X, which lacks the device-independent imaging model. On the other hand, X’s spelling has remained constant over the years, while NeXT has at various times spelled their flagship product “NextStep,” “NeXTstep,” “NeXTStep,” “NeXTSTEP,” “NEXTSTEP,” and finally “OpenStep.” A standardized, consistent spelling is certainly easier on the marketing ’droids. Unfortunately, NeWS and NEXTSTEP were political failures because they suffer from the same two problems: oBNoXiOuS capitalization, and Amiga Persecution Attitude[TM]. p. 230 (hey FrameMaker got one right!!!): Footnote 2: Indeed, there are so many problems with partitioning in Unix that at least one vendor (NeXT, Inc.) recommends that disks be equipped with only a single partition. This is probably because NeXT’s Mach kernel can swap to the Unix file system, rather than requiring a special preallocated space on the system’s hard disk. p. 295 (FrameMaker guessed 296, two out of six ain't bad): Date: Wed, 18 Sep 1991 02:16:03 GMT From: meuer@roch.geom.umn.edu (Mark V. Meuer) Organization: Minnesota Supercomputer Institute Subject: Re: File find delay within Emacs on a NeXT To: help-gnu-emacs@prep.ai.mit.edu In article <1991Sep16.231808.9812@s1.msi.umn.edu> meuer@roch.geom.umn.edu (Mark V. Meuer) writes: I have a NeXT with version 2.1 of the system. We have Emacs 18.55 running. (Please don’t tell me to upgrade to version 18.57 unless you can also supply a pointer to diffs or at least s- and m- files for the NeXT.) There are several machines in our network and we are using yellow pages. The problem is that whenever I try to find a file (either through “C-x C-f”, “emacs file” or through a client talking to the server) Emacs freezes completely for between 15 and 30 seconds. The file then loads and everything works fine. In about 1 in 10 times the file loads immediately with no delay at all. Several people sent me suggestions (thank you!), but the obnoxious delay was finally explained and corrected by Scott Bertilson, one of the really smart people who works here at the Center. For people who have had this problem, one quick hack to correct it is to make /usr/lib/emacs/lock be a symbolic link to /tmp. The full explanation follows. I was able to track down that there was a file called !!!SuperLock!!! in /usr/lib/emacs/lock, and when that file existed the delay would occur. When that file wasn’t there, neither was the delay (usually). We found the segment of code that was causing the problem. When Emacs tries to open a file to edit, it tries to do an exclusive create on the superlock file. If the exclusive create fails, it tries 19 more times with a one second delay between each try. After 20 tries it just ignores the lock file being there and opens the file the user wanted. If it succeeds in creating the lock file, it opens the user’s file and then immediately removes the lock file. The problem we had was that /usr/lib/emacs/lock was mounted over NFS, and apparently NFS doesn’t handle exclusive create as well as one would hope. The command would create the file, but return an error saying it didn’t. Since Emacs thinks it wasn't able to create the lock file, it never removes it. But since it did create the file, all future attempts to open files encounter this lock file and force Emacs to go through a 20-second loop before proceeding. That was what was causing the delay. The hack we used to cure this problem was to make /usr/lib/emacs/lock be a symbolic link to /tmp, so that it would always point to a local directory and avoid the NFS exclusive create bug. I know this is far from perfect, but so far it is working correctly. Thanks to everyone who responded to my plea for help. It’s nice to know that there are so many friendly people on the net.
- hulitu 3y ago
  > The PostScript imaging model, used by NeWS and Display PostScript, solves all these horrible problems in a high-level, standard, device independent manner. We have evolved. Now we draw "surfaces" (to draw a cursor). /s

1vuio0pswjnm7 3y ago

"Author's Note: I have never used Windows as my 'daily driver'." What about Apple MacIntosh. Depending on employer, it's not easy to have never used Windows or Mac. Must be one of the lucky ones. Even at university, I recall rooms of computers and printers set up for students' word processing use had DOS/Windows loaded on them. Labs had Macs. Above all the rest, I always preferred the room with the VAX and later the UNIX accounts we got. To me, it's not that UNIX is objectively good, it's that the alternatives have all been inferior. To someone else, that might not be true. I am not fond of GUIs. Other people might love them. Regardless of peoples' varied personal opinions, UNIX is still around and I'm using it every day by choice. No GUI.

simonblack 3y ago
Depending on employer, it's not easy to have never used Windows or Mac True, but all I needed to use Windows at work was one dedicated app. (And actually that app was purely UCSD Pascal under the hood, but running as a guest under Windows.) At home, I thankfully used my AT&T UNIX, then my Novell Unixware, and finally my Solaris I and II, before I switched to Linux in 2001. In the mid-90s I thought I would look at this 'new-fangled, best thing since sliced bread' thing called Windows 3.1. I was disgusted at how primitive and useless it was compared to my normal Unixware desktop of the time. I actually bought my wife a PowerBook in 2005. But I was horrified to discover that Apple is really no different to Microsoft.
hulitu 3y ago
>What about Apple MacIntosh. Apple is too expensive and lacks the programs needed for development. No CAD programs.