4 ms·

Taking a quick glance through the sections: * Chapter 2: This is mostly still a problem, although many tools have gotten better about error messages, and there

Taking a quick glance through the sections: * Chapter 2: This is mostly still a problem, although many tools have gotten better about error messages, and there are a few footguns that have been removed. (A lot of this chapter, I presume, is basically about how something like VMS generally has a saner terminal interface than Unix does. But I've not used VMS enough to know for sure.) * Chapter 3: The internet exists and is easily accessible. There is still often a lot of issues with documentation in, say, man pages or the tool's command line option (see how often I complain about git's help!), but if you search for your problem on the internet, you'll probably find a more coherent answer anyways, so it's not as relevant anymore. * Chapter 4: Sendmail is no longer the dominant tool to send email on Unix systems, and for that matter, few sites run their own email servers anymore. Not really relevant anymore. * Chapter 5: Usenet is even less relevant. * Chapter 6: I've had some issues with terminal stuff in the past, but in general, most terminals just implement half of what xterm does, so it's often the case that programs emit the terminal escape codes directly. * Chapter 7: X is still moderately painful. Windowing is usually done via a higher-level toolkit like GTK or QT (and Motif isn't big anymore), or else often rolled on top of GL (or Vulkan) buffers. Xauth doesn't come up in practice anymore, and a lot of the other issues mentioned here aren't as relevant. But I still like the dig at X getting server and client confused. * Chapter 8: Shell proliferation has mostly gone away, largely down to either bash or POSIX-with-no-extensions sh. However, a lot of the criticism about shell as a programming language rings true. * Chapter 9: Several of the tools mentioned here are just less relevant these days, especially because something like makefiles tends to be autogenerated rather than written directly. * Chapter 10: C++11 is a pretty radical change to the language. And half of this chapter on C++ is somehow a rant on the C preprocessor, which is generally minimally tolerated by most C++ programmers, especially those on the committee. * Chapter 11: Another chapter of mostly irrelevant tools. * Chapter 12: This chapter is largely relevant, although nowadays, there are also ways you can set limits to avoid some of these problems. * Chapter 13: A lot of kvetching about filesystems no one uses anymore. Although some of the complaints about how POSIX views files is still appropriate, but do note that all major OSes these days end up sharing the same deficiencies in their file semantics. * Chapter 14: NFS is still around, although I think it's gotten a lot better in the past 30 years. Overall, the high-level criticism of Unix as a worse-is-better approach still rings true, but this is largely a book that prefers to take cheap potshots over any serious analysis, and those potshots have often not aged well.

mcguire 3y ago
Beating a dead horse here... "But I still like the dig at X getting server and client confused." A "server" is something that accepts requests and multiplexes some resource; a "client" makes requests. The X server is a server in that it multiplexes access to the UI hardware. Don't be fooled by the way a client gets event notifications from the server. (That's mostly just the tip of the iceberg of problems with the "client/server" idea.) The book remains wrong.
- DonHopkins 3y ago
  https://news.ycombinator.com/item?id=25736735 https://news.ycombinator.com/item?id=25736735 mcguire on Jan 11, 2021 | parent | context | favorite | on: XTerm: It's Better Than You Thought Don, did you ever figure out the difference between a "client" and a "server"? DonHopkins on Jan 12, 2021 [–] Sure: xterm a client of your display and keyboard and mouse, remote input and output services that the X11 server provides over the network. And at the same time, a web browser is the client of computing and data servers in the cloud, provided over the network. In reality, there can be many different client/server relationships existing in different directions over the same full duplex network connection. It's really a bi-directional multiplexed messaging channel, not a pure strict hierarchical relationship, and many client/server dependencies can go both ways over the same connection, at the same time. You can even run an ssh that opens tunnels in both directions, then tunnel X and http connections over that. Once a connection is established, it really don't matter which end initiated the connection (or how many links and proxies and tunnels there are along the way) -- you're just sending messages both ways. "Client/Server" is an over-simplified way of describing what's possible. ddingus on Jan 12, 2021 | parent [–] Only the server, actually serves the graphics to the user. Within the context of the X Window System, the server is the body of code responsible for delivering the display to the user viewing it. bitwize on Jan 12, 2021 | root | parent | next [–] > Only the server, actually serves the graphics to the user. The server actually serves the user to the remote client. It's like "you are not the customer, you are the product". The remote program needs to communicate graphically with you, and connects to the X server to do this; therefore, you are not the requester of a resource, you are the resource being served. :) ddingus on Jan 12, 2021 | root | parent | next [–] I like it. Clever, and current context relevant. Cheers. DonHopkins on Jan 12, 2021 | root | parent | prev | next [–] Great analogy. Think of it like Amazon Mechanical Turk. mcguire on Jan 13, 2021 | root | parent | prev [–] Think of it in terms of a print server. It's a long-running process that other processes connect to, in order to request a service. It handles the "impedance mismatch" between the clients and the hardware it controls---in the case of a print server, it demultiplexes requests and translates them into something the printer can deal with; in the case of X, it displays the information as requested by the client and provides notifications of events as requested by the client.

mcguire 3y ago

Beating a dead horse here... "But I still like the dig at X getting server and client confused." A "server" is something that accepts requests and multiplexes some resource; a "client" makes requests. The X server is a server in that it multiplexes access to the UI hardware. Don't be fooled by the way a client gets event notifications from the server. (That's mostly just the tip of the iceberg of problems with the "client/server" idea.) The book remains wrong.

DonHopkins 3y ago
https://news.ycombinator.com/item?id=25736735 https://news.ycombinator.com/item?id=25736735 mcguire on Jan 11, 2021 | parent | context | favorite | on: XTerm: It's Better Than You Thought Don, did you ever figure out the difference between a "client" and a "server"? DonHopkins on Jan 12, 2021 [–] Sure: xterm a client of your display and keyboard and mouse, remote input and output services that the X11 server provides over the network. And at the same time, a web browser is the client of computing and data servers in the cloud, provided over the network. In reality, there can be many different client/server relationships existing in different directions over the same full duplex network connection. It's really a bi-directional multiplexed messaging channel, not a pure strict hierarchical relationship, and many client/server dependencies can go both ways over the same connection, at the same time. You can even run an ssh that opens tunnels in both directions, then tunnel X and http connections over that. Once a connection is established, it really don't matter which end initiated the connection (or how many links and proxies and tunnels there are along the way) -- you're just sending messages both ways. "Client/Server" is an over-simplified way of describing what's possible. ddingus on Jan 12, 2021 | parent [–] Only the server, actually serves the graphics to the user. Within the context of the X Window System, the server is the body of code responsible for delivering the display to the user viewing it. bitwize on Jan 12, 2021 | root | parent | next [–] > Only the server, actually serves the graphics to the user. The server actually serves the user to the remote client. It's like "you are not the customer, you are the product". The remote program needs to communicate graphically with you, and connects to the X server to do this; therefore, you are not the requester of a resource, you are the resource being served. :) ddingus on Jan 12, 2021 | root | parent | next [–] I like it. Clever, and current context relevant. Cheers. DonHopkins on Jan 12, 2021 | root | parent | prev | next [–] Great analogy. Think of it like Amazon Mechanical Turk. mcguire on Jan 13, 2021 | root | parent | prev [–] Think of it in terms of a print server. It's a long-running process that other processes connect to, in order to request a service. It handles the "impedance mismatch" between the clients and the hardware it controls---in the case of a print server, it demultiplexes requests and translates them into something the printer can deal with; in the case of X, it displays the information as requested by the client and provides notifications of events as requested by the client.