Live data from Hacker News

The Unix-Haters Handbook (1994) [pdf]

simson.net

101–110 of 150 posts

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

#101
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…

I disagree. As much as I dislike a lot of stuff in systemd, it was the _first_ init system that actually cares about reliability.

It evolved organically so it's a bit of a mess as a result, but it's the fate of most long-term projects (including Linux).

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

#102

Earlier quoted context omitted.

Windows is actually much closer to this limited, meaningless, form of the "everything is a file" meme. In Windows literally every kernel object is a Handle. A file, a thread, a mutex, a socket - all Handles. In Linux, some of these are file descriptors, some are completely different things. Of course, this is meaningless, as you can't actually do any common operation, except maybe Close*, on all of them. So them bein…

> Of course, this is meaningless, as you can't actually do any common operation, except maybe Close*, on all of them. You can write and read on anything on Unix that "is a file". You can't open or close all of them. Annoyingly, files come in 2 flavors, and you are supposed to optimize your reads and writes differently.

You can call write() and read() on any file descriptor, but it won't necessarily do something meaningful. For example, calling them on a socket in listen mode won't do anything meaningful. And many special files don't implement at least one of read or write - for example, reading or writing to many of the special files in /proc/fs doesn't do anything.

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

#103
I love Unix.

It's my favorite OS.

And I like it for its fundamental process model.

That combined with stdin/out and pipes.

All stitched together with a process aware shell.

Lots (most) OSes had a process concept. But in Unix, they not only existed, they were everywhere, they were dynamic, and they were "cheap". They were user accessible. A process with its ubiquitous stdin/out interface gave us great composablilty. We can click the processes together like legos.

For example, VMS had processes. But after 4 years of using it, I never tossed processes around using it like I did on Unix. I never "shelled out" of an editor. I never & something into the background. Just never came up. One terminal, one process.

On Unix, however, oh yea. Pipe construct on the command line, bang out of the editor, :r! in vi. And the eco-system the was created out of this simple concept. The "Unix Way(tm)".

And anything was a process. A C program. A shell script. At this level, everything was a "system language".

Then, They (those Unix wizard folks) made networking a well behaved citizen in this process stdin/out world. `inetd` could turn ANYTHING (because everything had stdin/out) into a network server. This command is magic: `ls | cpio -ov | rsh otherhost cat > /dev/tape`

Does `ls` know anything about file archives? No. Does `cpio` know anything about networking, or tape drives? No. Heck, `cat` doesn't know anything about tape drives.

You just could not, back in the day, plumb processes and computers together trivially like you could with Unix. Humans could do this. They didn't need to be wizard status, "admins", guys in white coats locked in the raised floor rooms, huffing Halon on the side. Assuming you could grok the arcane syntaxes (which, absolutely, were legion), you could make Unix do amazing things.

This flexibility allowed me to make all sorts of Rube-Goldbergian constructs of data flows and processes. Unix has always been empowering, and not constraining, once you accept it for what it is.

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

#104

Earlier quoted context omitted.

The only thing I remember is from the book Showstopper https://retrocomputing.stackexchange.com/questions/14150/how... [Cutler] expressed his low opinion of the Unix process input/output model by reciting "Get a byte, get a byte, get a byte byte byte" to the tune of the finale of Rossini's William Tell Overture.

Kind of crazy that what is possibly a throwaway remark by Cutler has become the basis for this whole "lore" of Dave hating Unix so much he went and made VMS (or variations on that theme). I guess it's a good story...

Almost all the major ways in which NT deviates from UNIX have strong cases as being architectural wins:

- A well-defined HAL for portability

- An object manager for unified resource lifecycle and governance

- Asynchronous I/O by default

- User-facing APIs bundled into independent “personalities” and decoupled from the kernel

The only real black mark I’m aware of is the move of the graphics subsystem into the kernel for performance, which I don’t think was Cutler’s idea.

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

#105
post #45
post #30

Earlier quoted context omitted.

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 f…

Yet another approach is exposing internal state.

That way you turn a very complex system into a set of much simpler artificial systems that you can control the interaction.

On your example, that would mean having different kinds of configuration options that go for each of those scenarios, but still all on the same software.

One can argue that systemd tries this (for example, there are many kinds of services). But in many cases, it does the complete opposite of this and reducing scope.

Still, I don't think init systems are a wicked problem (and so, it doesn't need advanced solutions to managing complexity). The wickedness is caused by the systemd's decision to do everything.

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

#106

Earlier quoted context omitted.

Inferno was a commercial attempt at competing with Sun's Java. The plan 9 folks had to shift gears so they took Plan 9 and built a smaller portable version of it in about a year. Both the Plan 9 kernel and Inferno kernel share a lot of code and build system so moving code between them is pretty simple. The real interesting magic behind Plan 9 is 9P and its VFS design so that leaves Inferno with one thing going for it…

> I would like to see a better Inferno but it would be a lot of work. 64 bit support and memory protection would be key along with other languages. It would make a better drawterm and a good platform for web applications. Doesn't Wasm/WASI provide these same features already? That doesn't seem like "a lot of work", it's basically there already. Does dis add anything compelling when compared to that existing technolog…

Inferno was initially released in 1996, 21 years before WASM existed.

An inferno built using WASM would be interesting. Though WASI would likely be supplanted by a Plan 9/Inferno interface possibly with WASI compatibility. Instead of a hacked up hyper text viewer you start with a real portable virtual OS that can run hosted or native. Then you build whatever you'd like on top like HTML renderers, JS interpreters, media players/codecs, etc. You profile is a user account so you get security for free using the OS mechanisms. Would make a very interesting platform.

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

#107

Earlier quoted context omitted.

Yeah, I was really confused when I learned that every device was simply a file in /dev, except the network interfaces. I never understood why there is no /dev/eth0 ... That was back in the mid-90s but even today I still don't understand why network interfaces are treated differently than other devices

What would it mean to write to a network interface? Blast everyone as multicast? Not that useful. But Plan9 had connections as files, though I’ve never tried.

That's a bad argument. What does it mean to write to a mouse device? To the audio mixer? To the i2c bus device? To a raw SCSI device (scanner or whatever)? Those are all not very useful either.

Especially since there actually is a very useful thing that writing to /dev/eth0 would do: Put a raw frame on the wire, and reading from it would read raw frames.

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

#108
post #40

We need, OTOH, the other side of the coin: The EMACS hater handbook. Under a GFDL license, of course. No multithreading, I/O locks under GNUs/eww, glacial slow email header parsing under GNUs, huge badass file for RMAIL if you don't like GNUs (instead of parsing MailDir) and so on.

>No multithreading, I/O locks under GNUs/eww, glacial slow All this would not happen if RMS had chosen Common Lisp to implement it...

RMS hates Common Lisp because it's a bit bloated (tons) and the closes to GNU Emacs written in CL it's Lem and it feels far slower than Emacs.

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

#109
post #61
post #52

I have a hard copy of this from back in the day. It’s a great read and a mixture of historical artefact and still relevant criticism. e.g. It’s really interesting reading about LISP machines but no-one’s building a new one. Equally, all the criticism of sendmail and csh is valid but no-one uses them anymore either. Most of the reliability criticisms have been addressed over the years but people are still trying to ad…

Yeah, I learned an enormous amount from it when I encountered it (in hard copy of course) in 01996, and some of what I learned is now no longer relevant. There are some people building new Lisp machines: https://opencores.org/projects/igor https://github.com/lisper/cpus-caddr https://interlisp.org/ http://pt.withington.org/publications/LispM.html http://pt.withington.org/publications/VLM.html https://github.com/dseag…

You encountered this book in 01996? Is that around the time of the Norman Conquest?

I'm assuming you're using octal here. Myself, I haven't used octal since 03677.

:-)

I see you mentioned https://interlisp.org/ ; while it's not a Lisp machine, the Medley Interlisp Project aims to recreate the Interlisp environment that ran on Xerox D-machines up through the 1980s or so. Still very interesting.

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

#110

Earlier quoted context omitted.

These are fine points, and there are rough edges, but: 1. `systemctl status nginx.service` suffices in many cases. journalctl is for when you need to dig deeper, and it demands many more options. You would have complained about "too noisy CLI arguments" if these were unified. 2. I am not sure about how I should parse this. You mean there are too many arguments in total (2a) or the man page or the help message is not…

1. systemctl already supports logging output, and it's already overloaded. 2. The options are not filtered, so useful options like ('--lines') are lost. E.g. what other options apply to "systemctl status"? The systemd documentation, in general, is a mess. It's a good _reference_ documentation (like 'man') but not a good guide. 3. Network filesystems exist. And they can become unavailable for a time.

> 3. Network filesystems exist. And they can become unavailable for a time.

See [1]

> the same applies to remote file system mounts. If you want them to be mounted only upon access, you will need to use the x-systemd.automount parameters. In addition, you can use the x-systemd.mount-timeout= option to specify how long systemd should wait for the mount command to finish. Also, the _netdev option ensures systemd understands that the mount is network dependent and order it after the network is online.

> You may also specify an idle timeout for a mount with the x-systemd.idle-timeout flag.

[1] https://wiki.archlinux.org/title/Fstab#Automount_with_system...

Post reply on HN