Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Unix-Haters Handbook (1994) [pdf]

simson.net

Post reply on HN
Print view View original

121–130 of 150 posts

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

#121

Post by b112 »

cyberax wrote: post #101
b112 wrote: 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…

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).

Reliability!!

It's the least reliable init system I've ever used!

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

#122

Post by cyberax »

e-khadem wrote: post #110
cyberax wrote: post #100

Earlier quoted context omitted.

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

> Note that this option can only be used in /etc/fstab, and will be ignored when part of the Options= setting in a unit file.

What did I say about consistency (or more precisely, the lack thereof)?

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

#123

Post by cyberax »

b112 wrote: post #121
cyberax wrote: post #101

Earlier quoted context omitted.

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).

Reliability!! It's the least reliable init system I've ever used!

Yes, reliability. Systemd was the first mainstream init system to deal with service confinement via cgroups, service readiness protocols, and true event-based service activation.

To give you some perspective, at that time, upstart was using ptrace() to detect the double-forking to allow services to be tracked.

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

#124

Post by kazinator »

anthk wrote: post #118
kazinator wrote: post #111

Earlier quoted context omitted.

Ironically, the GNU system now needs hundreds of megabytes of installation just to compile C.

The bloat is not about the size (sbcl and ecl can be pretty slim for what they do), it's the spec.

To write down the full spec, you have to document everything in those hundreds of megabytes. That's going to run for thousands of pages.

If your spec is small but you have hundreds of megabytes of bloat, it means you're not even remotely documenting everything.

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

#125

Post by mixmastamyk »

dark-star wrote: post #107
mixmastamyk wrote: post #86

Earlier quoted context omitted.

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.

You haven't thought through what you're asking. That's the bad argument. Network packets are not viable without a destination address. Nor does anyone want unaddressed (garbage) packets on their network.

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

#126

Post by atoav »

skydhash wrote: post #81
atoav wrote: post #66

Earlier quoted context omitted.

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

I believe when people run one of my programs and read the manual, it is my job to not waste their time and respect why they chose to do that.

And that means the first screen they read should cover all the basics if possible.

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

#127

Post by microtonal »

avhception wrote: post #34
simonh wrote: post #24

Earlier quoted context omitted.

I'm a Brit born in 66, and growing up I felt that WW2 was recent history. War films were a dominant genre in my early life, we visited the German defences on the French coast while camping as a teenager along with my Grandfather, who served there and visited some locations he remembered. Some buildings still had war damage. In many ways the world of the 70s felt closer to the war era than to nowadays. It was still th…

As a German born in 87, it didn't feel _that_ recent any more. But it was definitely close, both my granddads served in the war and were scarred for life by that, mentally and physically. Family history a mess of war-torn biographies. I found some rusted, old big munition in the forest as a kid. Old bunkers and flak towers can still be seen in the cities, and many of the local kids in my hometown and age cohort adven…

I am from 82 (Dutch) and I still remember vividly visiting the border/iron curtain in 89 (just before the wall came down). My mom would jokingly put her arm through the fence and say 'my arm is in communist East Germany' (technically DMZ I guess) and my parents would tell that they would shoot people trying to cross from the other side.

We often go to Germany, but this summer we went to Rügen. To get there we have to travel directly east, those trips just make you realize how close we were to the border and thus to an authoritarian regime.

Many of the buildings still had bullet holes and it felt like you could touch history.

When you know where to look, you can still find the scars everywhere. Our church tower still has bullet holes from WWII.

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

#128

Post by Karrot_Kream »

anthk wrote: post #108
flavio81 wrote: post #93

Earlier quoted context omitted.

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

Bloated? Sure. But slower than emacs? Strong disagreement here.

I find Lem a lot snappier than emacs.

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

#129

Post by VagabundoP »

darkwater wrote: post #20
e-khadem wrote: post #17

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…

As always RTFM applies - or at least glance through it at high speed.

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

#130

Post by dwattttt »

marcosdumay wrote: post #99
tsimionescu wrote: post #75

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 try to read/write the same on Windows: ReadFile (and friends) take a HANDLE.

It won't make sense to try to read from all things you can get a HANDLE to on Windows either, but it's up to what created the HANDLE/object as to what operations are valid.

https://learn.microsoft.com/en-us/windows/win32/sysinfo/kern...

Post reply on HN