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

141–150 of 150 posts

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

#141

Post by amszmidt »

flavio81 wrote: post #92
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.

The LMI and MIT Lisp Machine source code is not proprietary since about 10 and 20 years respectively.

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

#142

Post by mixmastamyk »

dark-star wrote: post #134
mixmastamyk wrote: post #125

Earlier quoted context omitted.

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.

I certainly have thought this through. Network packets don't need a destination address. Broadcast addresses exist. Also, packets to invalid/unknown destinations exist. You can send network packets with invalid source or destination addresses already anyway. Taking a raw chunk of data and putting it on the wire as-is is the most logical interpretation of "writing to the ethernet device". Does it make sense to allow e…

My first comment mentions multicast. Invalid packets won’t get routed, unless lucky enough to be accidentally valid.

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

#143

Post by RichardCA »

ferguess_k wrote: post #135
RichardCA wrote: post #116

OK I have a question. I've been trying to track down a Unix book that was similar from that time period, covering command-line tools and shell programming. It had some funny cartoons in between the text. One particular cartoon featured a man who had spent too much time at the command line and was using single-word commands for everything, e.g. when he needed to send a letter he would point to it and say "MAIL" and wh…

Asked ChatGPT and it told me the book might be "The Unix Programming Environment". It happens that the second link on Google is a pdf so I took a brief look, but did not find any cartoon. I asked it a second time and it said "UNIX for the Impatient", which does look like the one but I didn't find any pdf. Hopefully it helps.

Thanks but no, everyone who came up in that era knew about K&P (K&R was the C book). The main publishers back then were O'Reilly, SAMS, QUE and a few others. I think it was a SAMS book but I'm not sure.

A more likely candidate is the Kochan book but the original 1985 first edition. It had the scrappy sense of humor that characterized the Unix culture in the 80's.

https://www.goodreads.com/book/show/293206.UNIX_Shell_Progra...

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

#145

Post by zozbot234 »

MisterTea wrote: post #138
zozbot234 wrote: post #120

Earlier quoted context omitted.

WASI has nothing to do with hypertext though. Even WASM itself is not especially web centric, despite the name.

I am well aware of that. My point is a web browser, originally a hypertext viewer, is now a clunky runtime for all sorts of ad-hoc standards including a WASM VM. So instead, start with a portable WASM VM that is a light weight OS that you build a browser inside of composed of individual components like Lego. You get all the benefits of having a real OS including process isolation, memory management, file system, secu…

The WASI folks are accepting new API proposals. If the existing API does not fit an Inferno-like design, you can propose tweaked APIs in order to improve that fit.

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

#146

Post by dark-star »

mixmastamyk wrote: post #142
dark-star wrote: post #134

Earlier quoted context omitted.

I certainly have thought this through. Network packets don't need a destination address. Broadcast addresses exist. Also, packets to invalid/unknown destinations exist. You can send network packets with invalid source or destination addresses already anyway. Taking a raw chunk of data and putting it on the wire as-is is the most logical interpretation of "writing to the ethernet device". Does it make sense to allow e…

My first comment mentions multicast. Invalid packets won’t get routed, unless lucky enough to be accidentally valid.

Packets don't need to be routed. Sometimes you just want to communicate with a host on the same Layer-2 network. I said "Broadcast" (not Multicast) on purpose.

Sometimes you don't even want TCP/IP on the wire. Heck, sometimes you maybe don't even want DIX Ethernet on the wire.

Anyway, this discussion is going nowhere. Handcrafting packets is possible (it's basically what the kernel does anyway), sometimes it's useful, and if you could write a user-space program that could just open /dev/eth0 and write its own handcrafted packets to that stream would be helpful.

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

#147

Post by b112 »

cyberax wrote: post #123
b112 wrote: post #121

Earlier quoted context omitted.

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.

Tracking services doesn't provide for a reliable init system. From my perspective, the only job for init is to control startup and shutdown of services.

Not to keep them running. Not to restart them. Not to track them.

I have logs, and monitoring software for that. I have loads of applications to do that, if I wish. But regardless of what you believe an init system is for, the reliability of it is separate from "keeping apps that are so crappy they crash, running".

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

#148

Post by swatson741 »

awesome_dude wrote: post #21
swatson741 wrote: post #14

They certainly came up with a lot of good one-liners for this book. I wonder why Dennis Ritchie was so infuriated though. He criticizes them for wanting simple functionality, but it's not because language is a powerful tool for solving problems it's because it limits the potential of the platform to it's functionality (which has been simplified and in of itself limited). So this is confusing to me. Using language to…

Thous shalt not write criticisms of a demigod!

He's more like a juggernaut talking thru people than a demigod leading mortals imo.

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

#149

Post by dang »

cperciva wrote: post #7
microtonal wrote: post #4

Earlier quoted context omitted.

As an aside: Hacker News is getting old, the 2008 discussion is closer to the book’s year (1994) than it is to now.

I just realized that my most famous comment on HN is the same age as I was when I won the Putnam.

https://news.ycombinator.com/item?id=45045535

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

#150

Post by tankenmate »

pjmlp wrote: post #44
tankenmate wrote: post #33

Earlier quoted context omitted.

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

Not all devices support seek either, they're still files; ENOSYS
Post reply on HN