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

91–100 of 150 posts

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

#91

Post by MisterTea »

pjmlp wrote: post #78
MisterTea wrote: post #76

Earlier quoted context omitted.

> object orientation is kind of everything is a file 2.0 in the form everything is an object That is why I love Plan 9. 9P serves you a tree of named objects that can be byte addressed. Those objects are on the other end of an RPC server that can run anywhere, on any machine, thanks to 9p being architecture agnostic. Those named objects could be memory, hardware devices, actual on-disk files, etc. Very flexible and s…

I rather pick Inferno, as it improved on top of Plan 9 learnings, like the safe userspace in form of Limbo, after conclusion throwing away Alef wasn't that great in the end.

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: Dis, its user space VM. However, Dis does not protect memory as it was developed for mmu-less embedded use. It implicitly trusts the programmer not to clobber other programs memory. It is also hopelessly stuck in 32bit land.

These days Inferno is not actively maintained by anyone. There are a few forks in various states and a few attempts to make inferno 64 bit but so far no one has succeeded. You can check: https://github.com/henesy/awesome-inferno

Alef was abandoned because they needed to build a compiler for each arch and they already had a full C compiler suite. So they took the ideas from Alef and made the thread(2) C library. If you're curious about the history of Alef and how it influenced thread(2), Limbo and Go: https://seh.dev/go-legacy/

These days Plan 9 is still alive and well in the form of 9front, an actively developed fork. I know a lot of the devs and some of them daily drive their work via 9front running on actual hardware. I also daily drive 9front via drawterm to a physical CPU sever that also serves DNS and DHCP so my network is managed via ndb. Super simple to setup vs other clunky operating systems.

And lastly, 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.

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

#92

Post by flavio81 »

moomin wrote: 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…

>It’s really interesting reading about LISP machines but no-one’s building a new one

There have been two open source Lisp Machine OS created in the last 15 or 10 years.

However a big part of the power of the Symbolics/LMI machines was in the software itself (applications), and this is still propietary code.

To reimplement the Lisp Machine applications would take quite a big effort.

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

#93

Post by flavio81 »

anthk wrote: 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...

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

#95

Post by JdeBP »

gonzopancho wrote: post #79
JdeBP wrote: post #41

Earlier quoted context omitted.

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…

Didn’t Cutler design Mach?

No.

* https://cs.cmu.edu/afs/cs/project/mach/public/www/people-for...

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

#96

Post by monocasa »

moomin wrote: 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…

Pretty much all of the benefits provided by the hardware of lisp machines are provided by modern CPUs, just in more general ways.

Most of the benefit was pushing their interpreter into microcode, leaving more of the data bus free for actual data. Now we have ubiquitous icaches which give you a pseudo harvard architecture when it comes to the core's external bandwidth.

Some of the benefit was having a separate core with it's own microcode doing some of the garbage collection work. Now we have ubiquitous general multicore systems.

Etc.

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

#97

Post by op00to »

atoav wrote: post #87
op00to wrote: post #70

Earlier quoted context omitted.

It doesn't mean the requirements and solutions aren't wacky, weird, or inscrutable though.

Yeah sure, I didn't intend to paint it as if these problems were easy to solve. They are not.

Didn't take it that way, I was trying not to minimize the opposite point of view. systemd is a riddle wrapped up in a big ball of wtf.

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

#98

Post by zozbot234 »

MisterTea wrote: post #91
pjmlp wrote: post #78

Earlier quoted context omitted.

I rather pick Inferno, as it improved on top of Plan 9 learnings, like the safe userspace in form of Limbo, after conclusion throwing away Alef wasn't that great in the end.

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 technology stack?

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

#99

Post by marcosdumay »

tsimionescu wrote: post #75
zokier wrote: post #48

Earlier quoted context omitted.

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.

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.

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

#100

Post by cyberax »

e-khadem wrote: post #17
cyberax wrote: 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…

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.

Post reply on HN