Live data from Hacker News

The Unix-Haters Handbook (1994) [pdf]

simson.net

81–90 of 150 posts

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

#81
post #66

Earlier quoted context omitted.

That’s a tutorial or a getting started guide. The manual is a memory helper, like a tiny encyclopedia, not a teaching material.

How does that change my point about an order by frequency of use being superior? If it is a memory helper, then the stuff people tend to use more often is certainly the stuff that needs to be looked up more.

That’s a variable order. I prefer a more consistent order like a default section structure (which a lot of man pages adopt) and an alphabetical order for flags (which a lot of man pages also adopt).

When I open a manual it’s usually for: flags and argument ordering; argument format (for things like string format or globbing). Some manuals are short enough that it can serve as a guide, but most assumes domain knowledge.

What you want is a cheatsheet. And there’s a lot on the internet and even some tools that collect them. But most practitioners write shell aliases and functions

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

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

Systemd got better with time and I got better with it over time, which makes it acceptable for me now. I still miss SMF from Solaris years later though. I'm sure there are better systems out there but when the ubiquity is not there it's really hard to adopt them especially in corporate environments. And then you have to learn 2 things if you want to use something else at home, which is already too much for me...

I also liked SMF as well, but I do admit I “cheated” by using a website to make the XML service manifests.

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

#84
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.

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

Plan 9 does exactly this but all networking protocols live in /net - ethernet, tcp, udp, tls, icmp, etc. The dial string in the form of "net!address!service" abstracts the protocol from the application. A program can dial tcp!1.2.3.4!7788 or maybe udp!1.2.3.4!7788. How about raw Ethernet? /net/ether1!aabbccddeeff!12345. The dial(2) routine takes a dial string and returns an fd you read() and write(). Very simple networking API.

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

#85

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 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. I'm not at all a systemd hater (I think it was needed and it's nowadays a very solid piece of software) but the logs thing should be totally tweakable when viewing it from `systemctl status` and i…

OMG, TIL, too. This made my morning.

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

#86
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.

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.

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

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

“Those who do not understand Unix are condemned to reinvent it, poorly.” — Henry Spencer, 1987
Post reply on HN