Live data from Hacker News

The Unix-Haters Handbook (1994) [pdf]

simson.net

41–50 of 150 posts

Re: The Unix-Haters Handbook (1994) [pdf]

#41

As a side point, I believe David Cutler, the venerable OS engineer who programmed and designed three OSes, did not like Unix very much back in the 90s. I wonder what was the reason, and did he change his mind later?

It was because adding one to each of the letters in UNIX yields gibberish, but adding one to each of the letters in VMS gets WNT.

Era-appropriate joking aside: There's no actual evidence that Cutler held the views on Unix, or even on DEC's Eunice, that have been ascribed to xem from anecdotes by Armando Stettner and edits to Wikipedia and writing by G. Pascal Zachary. I and others went into more detail on this years ago: https://news.ycombinator.com/item?id=22814012

Re: The Unix-Haters Handbook (1994) [pdf]

#42
post #3

I've always liked the end of the anti-foreword: > Here is my metaphor: your book is a pudding stuffed with apposite observations, many well-conceived. Like excrement, it contains enough undigested nuggets of nutrition to sustain life for some. But it is not a tasty pie: it reeks too much of contempt and of envy.

Props for the inclusion of that in the book. "Mighty white of them", as they used to say in Bechuanaland.

My first instinct was that this phrase is racist, especially with you saying it was used in an ex-British southern African colony.

This was the best I could find as to its origins:

https://boards.straightdope.com/t/where-did-thats-mighty-whi...

Re: The Unix-Haters Handbook (1994) [pdf]

#43
post #25
post #16

Earlier quoted context omitted.

On UNIX the "everything is a file" quickly breaks down, when networking, or features added post UNIX System V get used, but the meme still holds apparently. If you want really everything is a file, that was fixed by UNIX authors in Plan 9 and Inferno.

I was recently thinking that object orientation is kind of everything is a file 2.0 in the form everything is an object I mean ofcourse didn’t pan out that good. Haven’t googled yet what people had to say about that already before. P.s. big fan of ur comments.

I actually read a decent paper on that a while back

Unix, Plan 9 and the Lurking Smalltalk

https://www.humprog.org/~stephen/research/papers/kell19unix-...

Late binding is a bit out of fashion these days but it really brings a lot of cool benefits for composition.

Re: The Unix-Haters Handbook (1994) [pdf]

#44
post #16

Earlier quoted context omitted.

On UNIX the "everything is a file" quickly breaks down, when networking, or features added post UNIX System V get used, but the meme still holds apparently. If you want really everything is a file, that was fixed by UNIX authors in Plan 9 and Inferno.

Some GOSIP (remember that?) implementations on some Unicies did have files for network connections, but it was very much in the minority. Since BSD was the home of the first widely usable socket() implementations for TCP/IP it became the norm; sockets are a file, but just not linked to any filesystem and control is connect()/accept() and the networking equivalent (setsockopt()) of the Unix system call dumping ground;…

I don't remember any of the ones I used having it, or then I missed it.

Kind of, sockets don't do seek().

Re: The Unix-Haters Handbook (1994) [pdf]

#45
post #30
post #5

I want to write a systemd haters handbook. Like: 1. You start and stop services with 'systemctl start/stop nginx'. But logs for that service can be read through an easy-to-remember 'journalctl -xeu nginx.service'. Why not 'systemctl logs nginx'? Nobody knows. 2. If you look at the built-in help for systemctl, the top-level options list things like `--firmware-setup` and `--image-policy`. 3. systemd unifies devices, m…

The inconsistency comes from the author thinking "All this init stuff is ancient, and filled with absurd work arounds, hacks, and inconsistencies. I'll fix that!". Then as time passes discovering that "Oh wait, I should add a hack for this special case, and this one, and this one, guess these were really needed!" as bug reports come in over the years. To be fair, this could happen to any of us, especially early in ca…

When a complex system cannot be meaningfully reduced, another approach might be trying to reduce scope.

Current areas include managing services on a server, managing a single-user laptop, and enterprise features for fleet of devices/users.

There is some overlap at the core where sharing code is useful, but it feels way more complexity than needed gets shipped to my laptop. I wonder how much could be shaved off when focusing only on a single scenario.

Re: The Unix-Haters Handbook (1994) [pdf]

#46
post #30
post #5

I want to write a systemd haters handbook. Like: 1. You start and stop services with 'systemctl start/stop nginx'. But logs for that service can be read through an easy-to-remember 'journalctl -xeu nginx.service'. Why not 'systemctl logs nginx'? Nobody knows. 2. If you look at the built-in help for systemctl, the top-level options list things like `--firmware-setup` and `--image-policy`. 3. systemd unifies devices, m…

The inconsistency comes from the author thinking "All this init stuff is ancient, and filled with absurd work arounds, hacks, and inconsistencies. I'll fix that!". Then as time passes discovering that "Oh wait, I should add a hack for this special case, and this one, and this one, guess these were really needed!" as bug reports come in over the years. To be fair, this could happen to any of us, especially early in ca…

> The inconsistency comes from the author thinking "All this init stuff is ancient, and filled with absurd work arounds, hacks, and inconsistencies. I'll fix that!". Then as time passes discovering that "Oh wait, I should add a hack for this special case, and this one, and this one, guess these were really needed!" as bug reports come in over the years.

Don't forget the best one: "We don't support that uncommon use case, we will not accept nor maintain patches to support it, and you shoulden't do it that way anyway, and we are going to make it impossible in the future" -- to something that's worked well for decades.

Re: The Unix-Haters Handbook (1994) [pdf]

#47
post #25

Earlier quoted context omitted.

I was recently thinking that object orientation is kind of everything is a file 2.0 in the form everything is an object I mean ofcourse didn’t pan out that good. Haven’t googled yet what people had to say about that already before. P.s. big fan of ur comments.

I actually read a decent paper on that a while back Unix, Plan 9 and the Lurking Smalltalk https://www.humprog.org/~stephen/research/papers/kell19unix-... Late binding is a bit out of fashion these days but it really brings a lot of cool benefits for composition.

There is also an interesting from Xerox PARC,

"UNIX Needs A True Integrated Environment: CASE Closed"

http://www.bitsavers.org/pdf/xerox/parc/techReports/CSL-89-4...

For the TL;DR; crowd

"We 've painted a dim picture of what it takes to bring IPEs to UNIX. The problems of locating. user interfaces. system seamlessness. and incrementality are hard to solve for current UNIXes--but not impossible. One of the reasons so little attention has been paid to the needs of IPEs in UNIX is that UNIX had not had good examples of IPEs for inspiration. This is changing: for instance. one of this article's authors has helped to develop the Small talk IPE for UNIX (see the adjacent story). and two others of us are working to make the Cedar IPE available on UNIX.

What's more. new UNIX facilities. such as shared memory and lightweight processes (threads). go a long way toward enabling seamless integration. Of course. these features don't themselves deliver integration: that takes UNIX programmers shaping UNIX as they always have--in the context of a friendly and cooperative community. As more UNIX programmers come to know IPEs and their power. UNIX itself will inevitably evolve toward being a full IPE. And then UNIX programmers can have what Lisp and Small talk and Cedar programmers have had for many years: a truly comfortable place to program."

Re: The Unix-Haters Handbook (1994) [pdf]

#48
post #16

As someone in the midst of transitioning to Linux for the first time ever, the thing is: I still kinda hate Unix, but my AI friends (Claude Code / Codex) are very good at Unix/Linux and the everything is a file nature of it is amenable to AI helping me make my OS do what I want in a way that Windows definitely isn't.

On UNIX the "everything is a file" quickly breaks down, when networking, or features added post UNIX System V get used, but the meme still holds apparently. If you want really everything is a file, that was fixed by UNIX authors in Plan 9 and Inferno.

Well it depends on what "file" means. Linuxian interpretation would be that file is something you can get file descriptor for. And then the "everything is a file" mantra holds better again.

Re: The Unix-Haters Handbook (1994) [pdf]

#49
post #41

As a side point, I believe David Cutler, the venerable OS engineer who programmed and designed three OSes, did not like Unix very much back in the 90s. I wonder what was the reason, and did he change his mind later?

It was because adding one to each of the letters in UNIX yields gibberish, but adding one to each of the letters in VMS gets WNT. Era-appropriate joking aside: There's no actual evidence that Cutler held the views on Unix, or even on DEC's Eunice, that have been ascribed to xem from anecdotes by Armando Stettner and edits to Wikipedia and writing by G. Pascal Zachary. I and others went into more detail on this years…

Really? VOJY could easily be a modern company, couldn't it? The .dot was parked though ... :)

Re: The Unix-Haters Handbook (1994) [pdf]

#50
post #48
post #16

Earlier quoted context omitted.

On UNIX the "everything is a file" quickly breaks down, when networking, or features added post UNIX System V get used, but the meme still holds apparently. If you want really everything is a file, that was fixed by UNIX authors in Plan 9 and Inferno.

Well it depends on what "file" means. Linuxian interpretation would be that file is something you can get file descriptor for. And then the "everything is a file" mantra holds better again.

Although many people nowadays misunderstand Linux for UNIX, it still isn't the same.
Post reply on HN