7 ms·

To what extent have the problems in the book been addressed since 1994?

by j2kun 3y ago

cf100clunk 3y ago
Could you be more specific?
- justin66 3y ago
  To what extent have the problems in The Unix-Haters Handbook been addressed since 1994?
  - bee_rider 3y ago
    Maybe they wanted to know which month you were taking about.
    - cf100clunk 3y ago
      In Unix time please.
tyingq 3y ago
The "plethora of incomplete, incompatible shells" has narrowed down a fair amount if you only include ones in wide use. And "The push for a unified Unix" sort of happened, we're down to 2 or 3 that get any broad attention.
- AnimalMuppet 3y ago
  2 or 3? Linux, and what are the other 1 or 2?
  - tyingq 3y ago
    MacOS, and various might argue Minix (prevalence via Intel Management Engine), or FreeBSD (still very important for a few big companies), etc.
  - mongol 3y ago
    OSX I guess qualifies
  - usefulcat 3y ago
    MacOS, OpenBSD and/or FreeBSD?
ikidd 3y ago
Well, if we're talking about the problem of it still existing, that one has almost been solved.
GeorgeTirebiter 3y ago
I was thinking the same thing; so many of their original complaints have been addressed. However, one has not: unix still uses the NJ-style (vs the MIT style), which is, if you can't figure out how to handle an error -- then don't. Also, put the burden on the programmer. Lovely stuff like that, which is core to the "unix philosophy".
- mwcremer 3y ago
  To be fair, the web as a whole is like that these days, in that HTTP explicitly includes the user as part of the error handling (404, 500, 503). How many times have you hit "Reload" today?
- fanf2 3y ago
  That was much less true by the end of the 1990s. Partly due to things like BSD’s improved signal handling. And partly due to the userland code quality improvements from the BSD and GNU rewrites. Shell scripting is still a nightmare for error handling, but by the end of the 1990s there were better scripting languages available to use when that matters.
bee_rider 3y ago
There are no longer good operating systems to compare Unix-clones against, so those of us who’ve grown up in this millennium don’t even see the problems.
tech_ken 3y ago
X11 continues to be A Thing, although the transition to Wayland is somewhat underway
- tedunangst 3y ago
  > Even if you can get an X program to compile, there’s no guarantee it’ll work with your server. If an application requires an X extension that your server doesn’t provide, then it fails. Thankfully Wayland fixed this by locking down the protocol and banning extensions.
  - deleted 3y ago
    [deleted]
  - DonHopkins 3y ago
    Which is why Wayland was a failure from the start, and still hasn't displaced X-Windows after all these years. The fact that it didn't occur to the Wayland designers to make it extensible with an embedded scripting language like PostScript in NeWS or Lisp in Emacs or Python in Blender or Lua in Redis or JavaScript in web browsers means that it was obsolete from the start. And that's why billions of more people use web browsers every day than Wayland. Some critics argue that The Unix-Haters Handbook indulges in historical revisionism and presents non-constructive unactionable complaints, without suggesting improvements or alternatives. However, I stand by the accuracy and validity of the insights and suggestions in the X-Windows chapter, as evidenced by the development of web browsers and the ascendancy of JavaScript. https://www.theregister.com/2023/11/29/rhel_10_dropping_x11/ https://www.theregister.com/2023/11/29/rhel_10_dropping_x11/ >[...] The transition from the now 30+ year old X Window System to the newer Wayland-based stack has been happening for the past 15 or so years. >We found this statement amusing for two reasons. Firstly, the X window system is much closer to 40 than 30 – we celebrated its 38th birthday in the middle of last year. X tore through its first ten major releases in just a few years. The first version was in 1984, and the 11th – which is why it's called X11 for short – was in 1987. >Secondly, as we noted when a GNOME developer proposed that Gtk5 drop X11 support, Wayland itself is getting old now. Work on it started in 2008; if RHEL 10 does ship in 2025, Wayland will be 17. So at the time when the biggest enterprise Linux goes Wayland-only, that protocol will in the same general ballpark age-wise that X11 was when Kristian Høgsberg started work on its replacement. At that time, X11 had been around for 21 years. >The Reg FOSS desk remains somewhat skeptical about Wayland, but the critical mass is getting there. KDE 6 will be Wayland-only. As it happens, personally, this vulture isn't a big fan of either GNOME or KDE, so it reassures us that two of the most popular Wayland holdouts are both adjusting their attitudes. Mint is experimenting with support in Cinnamon, and so is the Xfce team. [...] >This would be an epic task, and without a commercial backer, it doesn't seem likely to happen. Perhaps it really is time to just let X die. If that seems drastic, we advise reading chapter 7 of The Unix Hater's Handbook. >Perhaps the more independent-minded Unixes could do an end run around Wayland and switch to Arcan instead. Or even start over. Don Hopkins, the author of that chapter, suggested to us that a better plan would be to reimplement something akin to NeWS using JavaScript instead of PostScript. That sounds fun. ® See the "Hold my bong" essay I wrote in response to somebody asking for my opinion of Wayland and ideas about using extension languages like JavaScript: https://news.ycombinator.com/item?id=29097030 https://news.ycombinator.com/item?id=29097030 >Hi DonHopkins! Would you mind to share your opinion on Wayland with us? Thanks for asking! Hold my bong. ;) I've never had any reason to use Wayland or desire to learn much about it, so I can't tell you anything technical or from first hand experience. But I think we have X-Windows to thank for the fact that most Unix programmers use Macs now. And it's way too late for Wayland to change that fact. Especially with the release of the M1 Max. That ship has sailed. It didn't matter how much better NeWS was than X-Windows -- it still lost despite all its merits. And I don't see Wayland as being any more better than X-Windows, than NeWS was better, decades ago. So simply "being better than X" is not sufficient to displace it, and Wayland isn't even that much better than X, and is even worse in some ways. The fact that it didn't occur to the Wayland designers to make it extensible with an embedded scripting language like PostScript in NeWS or Lisp in Emacs or Python in Blender or Lua in Redis or JavaScript in web browsers means that it was obsolete from the start, and its designers should have considered the design and architecture of NeWS and Emacs and Blender and Redis and web browsers before designing Yet-Another-X-Windows-Clone. It's not like those ideas were secret, or patented, or hard to find, or wrong. The world moved up the stack a layer to the web browser, and that's where all the excitement's happening these days, not in the window system layer. Why have X-Windows or Wayland at all, when you could just run the web browser itself directly on the hardware, as efficiently and flexibly as possible, and implement all your user interface, window management and desktop stuff with modern open standard JavaScript / WebAssembly / JSON / XML / HTML / SVG / CSS / Canvas / WebGL / WebGPU / HTTPS / WebRTC? I've written about this numerous times before, but I'll transclude and reorganize some of it with checked and updated archive urls to save you the pointing and clicking: https://news.ycombinator.com/item?id=5844345 https://news.ycombinator.com/item?id=5844345 [...see link for more...] And here is this more recent thread about window management, ICCCM, Wayland, extension languages, and all the walls that Simon Schneegan hit in his wonderful work on FlyPie, OpenPie, Gnome-Pie, Coral Menus, and Trace Menus: https://news.ycombinator.com/item?id=38442660 https://news.ycombinator.com/item?id=38442660 I'm frustrated that Wayland doesn't support all the good ideas (and avoid all the bad ideas) of X-Windows or NeWS, and doesn't even have a built-in extension language like emacs and web browsers do. (What were they even thinking, not making it extensible at runtime? That everybody would want to compile their own server to customize it in C? Or that they'd solved all possible problems perfectly and there would be no need for customization?) [...] Some years ago, Simon discussed some of the problems with Wayland that made it impossible to implement all the features of Gnome-Pie. I don't know how much Wayland has progressed to address those problems since then, but he's moved onto developing cross platform pie menus with Kando - An Open Source, Cross-Platform Pie Menu, to reach the much wider audience of Windows and Mac users as well as Linux. It baffles me that the Wayland compositor wasn't designed from the ground up in the first place around a scripting language like JavaScript (or PostScript even ;). It's not like the idea was a secret or patented, and it seems to work well for emacs and web browsers. Then it would have been much easier to address all those problems and implement much more flexible powerful and efficient window managers, pie menus, tabbed windows, etc. And then maybe Wayland wouldn't be so limited, and would have already fully taken over from X11 decades ago. https://schneegans.github.io/news/2017/07/09/gnome-pie-071 https://schneegans.github.io/news/2017/07/09/gnome-pie-071 Simon Schneegan wrote about the problems of wayland in his Gnome-Pie 0.7.1 announcement: https://schneegans.github.io/news/2017/07/09/gnome-pie-071 https://schneegans.github.io/news/2017/07/09/gnome-pie-071 >Wayland – in it’s current state – makes applications such as Gnome-Pie hardly possible. Due to security concerns, applications are much more isolated. There is a good summary on the cairo-dock forums. https://glx-dock.org/mr_article.php?b=5&a=73 https://glx-dock.org/mr_article.php?b=5&a=73 >Here are the big bummers: >No client side window placement: Application cannot position their windows. How shall we open the Pie beneath the cursor? The only way I can think of is to open a transparent full screen window and draw Gnome-Pie at the pointer location. Sadly, this is not possible either: Only as soon as the user moves the pointer over the window, we can get the pointer location. I see no chance in getting this information more early. That means that we simply do not know were the mouse is when we open the full screen window. Hence, Pies can be opened at the center of the screen only. >No global input grabbing: Another reason for the full screen window is, that input capturing is impossible. This is the only possibility to close Gnome-Pie when the user clicks outside the activation radius. The full screen window makes the whole thing much slower and may lead to unwanted side effects such as auto-hiding panels. >No global key bindings: Applications cannot intercept keyboard or mouse events anymore. While this seems reasonable in the context of security concerns, it limits the usefulness of Gnome-Pie drastically. The only possibility is to open Pies with the terminal command gnome-pie --open <ID of your Pie>. Of course, this command can be bound to global hot keys of your desktop shell (as can be seen in the screen shot above), assigned to hot corners, etc. However, there is no way to support the turbo mode and delayed activation mode Gnome-Pie features on X11. >No mouse pointer warping: It is impossible for an application to manipulate the position of the mouse pointer. Therefore it is impossible to warp the pointer to the center of the Pie. >No client side window management: This is something for the desktop shell. There is possibility for a client application to get a list of opened windows. Therefore something like the window list slice group (Alt-Tab) is not possible. Maybe there will be an interface in future? Gnome-Pie uses wnck which is specific to X11. >No sending of fake keyboard events: This is a very useful action type for pie slices. In addition, this is required for deferred pie activation. >The conclusion Hopefully this can be improved in future, however a lot of security decisions have been made during the development of Wayland which make applications like Gnome-Pie basically impossible. If there are no large scale changes in Wayland, I see bad future for Gnome-Pie. >If someone knows solutions for some of these problems please help making Gnome-Pie useful on Wayland! [...]
arp242 3y ago
Pretty much all of them, insofar they were even valid concerns to begin with because many are not, or are at least hugely simplified, and a number of others have nothing to do with "Unix" in the first place. The entire book is basically "let's compare the worst of 10 Unix systems to the best of 10 other systems, and then come to the conclusion all of Unix sucks and all the others are brilliant". Well, anything "sucks" in that way. And that is assuming that "best of 10 other systems" is accurate and not hugely biased and viewed with rose-coloured glasses. I think this sentence probably sums up the book quite nicely: > Will journaling become prevalent in the Unix world at large? Probably not. After all, it’s non-standard. Which probably tells you all you need to know about the mentality of the authors. Nothing in any standard prevented anyone from journaling. It's just FUD. The first journaling filesystem was introduced in 1990, in AIX, and then in 1991 in HP-UX. Both are Unix. Windows followed in 1993, Apple in 1998. This book is from 1994. This was more or less cutting-edge(-ish) stuff back then. "Storing files" reliably has always been hard, on any system. "Unix can lose files" – well, yeah, just like any other system mate. Unix lead the way on improving that with journaling, and the book even acknowledges that in the paragraph before the one I quoted, and it's still whinging and whining and spreading bullshit FUD. I'm not saying Unix is perfect today and I'm sure as hell not saying Unix anno 1994 was perfect. but a careful thoughtful criticism this book is not. The best part is Dennis Ritchie's "anti-foreword". A book refuting all the bullshit in this book, even from a 1994 perspective, would probably be longer than this book. It's a classic case of bullshit asymmetry where flinging some nonsense in to the world takes almost no effort at all, but refuting it takes a lot more effort.
- justin66 3y ago
  > whinging and whining and spreading bullshit FUD I’m pretty sure that if Freud were present, he’d point out the rage you’re feeling right now isn’t really about the thirty year old nerd satire book you’re commenting on, it’s about your relationship with your father.
  - arp242 3y ago
    The problem is that it's historical revisionism. It keeps getting posted on HN and taken serious (it was never intended as satire in the first place) and people think it somehow represents an accurate view of ... anything. It doesn't. But the less said about my father the better, so maybe shrug.
postmodest 3y ago
Unix has gotten better while everything else got worse. We no longer have dinosaurs like LISP-M or TOPS-10 for the Unix-haters to get rose-colored nostalgia for. And Windows NT proved how terrible the alternative could be. The NT api and Powershell is basically the "Monkey's-Paw" version of what the authors wanted. Be careful what you wish for.
- kazinator 3y ago
  > Unix has gotten better Well, Linux has. Unix is the same old: when you log in to any of it (BSD, Solaris, AIX, ...), it's like a time machine back to 1990.
  - dcminter 3y ago
    OSX is a Unix. I don't like it compared to Linux personally but I'm obviously in a minority there.
    - kazinator 3y ago
      The Darwin environment can be described as stagnant waters, where you need to bring in third-party FOSS package management in order not to be stuck with twenty-year-old forks of GNU utilities. It's no longer positioned as a server OS, which on the surface just looks like a business move, but I suspect it's because the kernel and surrounding environment aren't very good. The writing was on the wall for years.
  - ahoka 3y ago
    I think this is Torvalds’ true genius: creating an OS as different as possible from UNIX while being compatible with it.
  - hulitu 3y ago
    > Well, Linux has. Linux is getting worse. The freedesktop.org cancer is eating it from the inside (systemd, wayland).
    - 3y ago
jcranmer 3y ago
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.

To what extent have the problems in the book been addressed since 1994?

by j2kun 3y ago

To what extent have the problems in the book been addressed since 1994?

cf100clunk 3y ago

Could you be more specific?

justin66 3y ago
To what extent have the problems in The Unix-Haters Handbook been addressed since 1994?
- bee_rider 3y ago
  Maybe they wanted to know which month you were taking about.
  - cf100clunk 3y ago
    In Unix time please.

tyingq 3y ago

The "plethora of incomplete, incompatible shells" has narrowed down a fair amount if you only include ones in wide use. And "The push for a unified Unix" sort of happened, we're down to 2 or 3 that get any broad attention.

AnimalMuppet 3y ago
2 or 3? Linux, and what are the other 1 or 2?
- tyingq 3y ago
  MacOS, and various might argue Minix (prevalence via Intel Management Engine), or FreeBSD (still very important for a few big companies), etc.
- mongol 3y ago
  OSX I guess qualifies
- usefulcat 3y ago
  MacOS, OpenBSD and/or FreeBSD?

ikidd 3y ago

Well, if we're talking about the problem of it still existing, that one has almost been solved.

GeorgeTirebiter 3y ago

I was thinking the same thing; so many of their original complaints have been addressed. However, one has not: unix still uses the NJ-style (vs the MIT style), which is, if you can't figure out how to handle an error -- then don't. Also, put the burden on the programmer. Lovely stuff like that, which is core to the "unix philosophy".

mwcremer 3y ago
To be fair, the web as a whole is like that these days, in that HTTP explicitly includes the user as part of the error handling (404, 500, 503). How many times have you hit "Reload" today?
fanf2 3y ago
That was much less true by the end of the 1990s. Partly due to things like BSD’s improved signal handling. And partly due to the userland code quality improvements from the BSD and GNU rewrites. Shell scripting is still a nightmare for error handling, but by the end of the 1990s there were better scripting languages available to use when that matters.

bee_rider 3y ago

There are no longer good operating systems to compare Unix-clones against, so those of us who’ve grown up in this millennium don’t even see the problems.

tech_ken 3y ago

X11 continues to be A Thing, although the transition to Wayland is somewhat underway

tedunangst 3y ago
> Even if you can get an X program to compile, there’s no guarantee it’ll work with your server. If an application requires an X extension that your server doesn’t provide, then it fails. Thankfully Wayland fixed this by locking down the protocol and banning extensions.
- deleted 3y ago
  [deleted]
- DonHopkins 3y ago
  Which is why Wayland was a failure from the start, and still hasn't displaced X-Windows after all these years. The fact that it didn't occur to the Wayland designers to make it extensible with an embedded scripting language like PostScript in NeWS or Lisp in Emacs or Python in Blender or Lua in Redis or JavaScript in web browsers means that it was obsolete from the start. And that's why billions of more people use web browsers every day than Wayland. Some critics argue that The Unix-Haters Handbook indulges in historical revisionism and presents non-constructive unactionable complaints, without suggesting improvements or alternatives. However, I stand by the accuracy and validity of the insights and suggestions in the X-Windows chapter, as evidenced by the development of web browsers and the ascendancy of JavaScript. https://www.theregister.com/2023/11/29/rhel_10_dropping_x11/ https://www.theregister.com/2023/11/29/rhel_10_dropping_x11/ >[...] The transition from the now 30+ year old X Window System to the newer Wayland-based stack has been happening for the past 15 or so years. >We found this statement amusing for two reasons. Firstly, the X window system is much closer to 40 than 30 – we celebrated its 38th birthday in the middle of last year. X tore through its first ten major releases in just a few years. The first version was in 1984, and the 11th – which is why it's called X11 for short – was in 1987. >Secondly, as we noted when a GNOME developer proposed that Gtk5 drop X11 support, Wayland itself is getting old now. Work on it started in 2008; if RHEL 10 does ship in 2025, Wayland will be 17. So at the time when the biggest enterprise Linux goes Wayland-only, that protocol will in the same general ballpark age-wise that X11 was when Kristian Høgsberg started work on its replacement. At that time, X11 had been around for 21 years. >The Reg FOSS desk remains somewhat skeptical about Wayland, but the critical mass is getting there. KDE 6 will be Wayland-only. As it happens, personally, this vulture isn't a big fan of either GNOME or KDE, so it reassures us that two of the most popular Wayland holdouts are both adjusting their attitudes. Mint is experimenting with support in Cinnamon, and so is the Xfce team. [...] >This would be an epic task, and without a commercial backer, it doesn't seem likely to happen. Perhaps it really is time to just let X die. If that seems drastic, we advise reading chapter 7 of The Unix Hater's Handbook. >Perhaps the more independent-minded Unixes could do an end run around Wayland and switch to Arcan instead. Or even start over. Don Hopkins, the author of that chapter, suggested to us that a better plan would be to reimplement something akin to NeWS using JavaScript instead of PostScript. That sounds fun. ® See the "Hold my bong" essay I wrote in response to somebody asking for my opinion of Wayland and ideas about using extension languages like JavaScript: https://news.ycombinator.com/item?id=29097030 https://news.ycombinator.com/item?id=29097030 >Hi DonHopkins! Would you mind to share your opinion on Wayland with us? Thanks for asking! Hold my bong. ;) I've never had any reason to use Wayland or desire to learn much about it, so I can't tell you anything technical or from first hand experience. But I think we have X-Windows to thank for the fact that most Unix programmers use Macs now. And it's way too late for Wayland to change that fact. Especially with the release of the M1 Max. That ship has sailed. It didn't matter how much better NeWS was than X-Windows -- it still lost despite all its merits. And I don't see Wayland as being any more better than X-Windows, than NeWS was better, decades ago. So simply "being better than X" is not sufficient to displace it, and Wayland isn't even that much better than X, and is even worse in some ways. The fact that it didn't occur to the Wayland designers to make it extensible with an embedded scripting language like PostScript in NeWS or Lisp in Emacs or Python in Blender or Lua in Redis or JavaScript in web browsers means that it was obsolete from the start, and its designers should have considered the design and architecture of NeWS and Emacs and Blender and Redis and web browsers before designing Yet-Another-X-Windows-Clone. It's not like those ideas were secret, or patented, or hard to find, or wrong. The world moved up the stack a layer to the web browser, and that's where all the excitement's happening these days, not in the window system layer. Why have X-Windows or Wayland at all, when you could just run the web browser itself directly on the hardware, as efficiently and flexibly as possible, and implement all your user interface, window management and desktop stuff with modern open standard JavaScript / WebAssembly / JSON / XML / HTML / SVG / CSS / Canvas / WebGL / WebGPU / HTTPS / WebRTC? I've written about this numerous times before, but I'll transclude and reorganize some of it with checked and updated archive urls to save you the pointing and clicking: https://news.ycombinator.com/item?id=5844345 https://news.ycombinator.com/item?id=5844345 [...see link for more...] And here is this more recent thread about window management, ICCCM, Wayland, extension languages, and all the walls that Simon Schneegan hit in his wonderful work on FlyPie, OpenPie, Gnome-Pie, Coral Menus, and Trace Menus: https://news.ycombinator.com/item?id=38442660 https://news.ycombinator.com/item?id=38442660 I'm frustrated that Wayland doesn't support all the good ideas (and avoid all the bad ideas) of X-Windows or NeWS, and doesn't even have a built-in extension language like emacs and web browsers do. (What were they even thinking, not making it extensible at runtime? That everybody would want to compile their own server to customize it in C? Or that they'd solved all possible problems perfectly and there would be no need for customization?) [...] Some years ago, Simon discussed some of the problems with Wayland that made it impossible to implement all the features of Gnome-Pie. I don't know how much Wayland has progressed to address those problems since then, but he's moved onto developing cross platform pie menus with Kando - An Open Source, Cross-Platform Pie Menu, to reach the much wider audience of Windows and Mac users as well as Linux. It baffles me that the Wayland compositor wasn't designed from the ground up in the first place around a scripting language like JavaScript (or PostScript even ;). It's not like the idea was a secret or patented, and it seems to work well for emacs and web browsers. Then it would have been much easier to address all those problems and implement much more flexible powerful and efficient window managers, pie menus, tabbed windows, etc. And then maybe Wayland wouldn't be so limited, and would have already fully taken over from X11 decades ago. https://schneegans.github.io/news/2017/07/09/gnome-pie-071 https://schneegans.github.io/news/2017/07/09/gnome-pie-071 Simon Schneegan wrote about the problems of wayland in his Gnome-Pie 0.7.1 announcement: https://schneegans.github.io/news/2017/07/09/gnome-pie-071 https://schneegans.github.io/news/2017/07/09/gnome-pie-071 >Wayland – in it’s current state – makes applications such as Gnome-Pie hardly possible. Due to security concerns, applications are much more isolated. There is a good summary on the cairo-dock forums. https://glx-dock.org/mr_article.php?b=5&a=73 https://glx-dock.org/mr_article.php?b=5&a=73 >Here are the big bummers: >No client side window placement: Application cannot position their windows. How shall we open the Pie beneath the cursor? The only way I can think of is to open a transparent full screen window and draw Gnome-Pie at the pointer location. Sadly, this is not possible either: Only as soon as the user moves the pointer over the window, we can get the pointer location. I see no chance in getting this information more early. That means that we simply do not know were the mouse is when we open the full screen window. Hence, Pies can be opened at the center of the screen only. >No global input grabbing: Another reason for the full screen window is, that input capturing is impossible. This is the only possibility to close Gnome-Pie when the user clicks outside the activation radius. The full screen window makes the whole thing much slower and may lead to unwanted side effects such as auto-hiding panels. >No global key bindings: Applications cannot intercept keyboard or mouse events anymore. While this seems reasonable in the context of security concerns, it limits the usefulness of Gnome-Pie drastically. The only possibility is to open Pies with the terminal command gnome-pie --open <ID of your Pie>. Of course, this command can be bound to global hot keys of your desktop shell (as can be seen in the screen shot above), assigned to hot corners, etc. However, there is no way to support the turbo mode and delayed activation mode Gnome-Pie features on X11. >No mouse pointer warping: It is impossible for an application to manipulate the position of the mouse pointer. Therefore it is impossible to warp the pointer to the center of the Pie. >No client side window management: This is something for the desktop shell. There is possibility for a client application to get a list of opened windows. Therefore something like the window list slice group (Alt-Tab) is not possible. Maybe there will be an interface in future? Gnome-Pie uses wnck which is specific to X11. >No sending of fake keyboard events: This is a very useful action type for pie slices. In addition, this is required for deferred pie activation. >The conclusion Hopefully this can be improved in future, however a lot of security decisions have been made during the development of Wayland which make applications like Gnome-Pie basically impossible. If there are no large scale changes in Wayland, I see bad future for Gnome-Pie. >If someone knows solutions for some of these problems please help making Gnome-Pie useful on Wayland! [...]

arp242 3y ago

Pretty much all of them, insofar they were even valid concerns to begin with because many are not, or are at least hugely simplified, and a number of others have nothing to do with "Unix" in the first place. The entire book is basically "let's compare the worst of 10 Unix systems to the best of 10 other systems, and then come to the conclusion all of Unix sucks and all the others are brilliant". Well, anything "sucks" in that way. And that is assuming that "best of 10 other systems" is accurate and not hugely biased and viewed with rose-coloured glasses. I think this sentence probably sums up the book quite nicely: > Will journaling become prevalent in the Unix world at large? Probably not. After all, it’s non-standard. Which probably tells you all you need to know about the mentality of the authors. Nothing in any standard prevented anyone from journaling. It's just FUD. The first journaling filesystem was introduced in 1990, in AIX, and then in 1991 in HP-UX. Both are Unix. Windows followed in 1993, Apple in 1998. This book is from 1994. This was more or less cutting-edge(-ish) stuff back then. "Storing files" reliably has always been hard, on any system. "Unix can lose files" – well, yeah, just like any other system mate. Unix lead the way on improving that with journaling, and the book even acknowledges that in the paragraph before the one I quoted, and it's still whinging and whining and spreading bullshit FUD. I'm not saying Unix is perfect today and I'm sure as hell not saying Unix anno 1994 was perfect. but a careful thoughtful criticism this book is not. The best part is Dennis Ritchie's "anti-foreword". A book refuting all the bullshit in this book, even from a 1994 perspective, would probably be longer than this book. It's a classic case of bullshit asymmetry where flinging some nonsense in to the world takes almost no effort at all, but refuting it takes a lot more effort.

justin66 3y ago
> whinging and whining and spreading bullshit FUD I’m pretty sure that if Freud were present, he’d point out the rage you’re feeling right now isn’t really about the thirty year old nerd satire book you’re commenting on, it’s about your relationship with your father.
- arp242 3y ago
  The problem is that it's historical revisionism. It keeps getting posted on HN and taken serious (it was never intended as satire in the first place) and people think it somehow represents an accurate view of ... anything. It doesn't. But the less said about my father the better, so maybe shrug.

postmodest 3y ago

Unix has gotten better while everything else got worse. We no longer have dinosaurs like LISP-M or TOPS-10 for the Unix-haters to get rose-colored nostalgia for. And Windows NT proved how terrible the alternative could be. The NT api and Powershell is basically the "Monkey's-Paw" version of what the authors wanted. Be careful what you wish for.

kazinator 3y ago
> Unix has gotten better Well, Linux has. Unix is the same old: when you log in to any of it (BSD, Solaris, AIX, ...), it's like a time machine back to 1990.
- dcminter 3y ago
  OSX is a Unix. I don't like it compared to Linux personally but I'm obviously in a minority there.
  - kazinator 3y ago
    The Darwin environment can be described as stagnant waters, where you need to bring in third-party FOSS package management in order not to be stuck with twenty-year-old forks of GNU utilities. It's no longer positioned as a server OS, which on the surface just looks like a business move, but I suspect it's because the kernel and surrounding environment aren't very good. The writing was on the wall for years.
- ahoka 3y ago
  I think this is Torvalds’ true genius: creating an OS as different as possible from UNIX while being compatible with it.
- hulitu 3y ago
  > Well, Linux has. Linux is getting worse. The freedesktop.org cancer is eating it from the inside (systemd, wayland).
  - 3y ago

jcranmer 3y ago

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.