11 ms·

I enjoyed the article but this quote jumped out at me: "What took thirty years to build isn't going to be replaced in a day." This was in regard to replacing X1

by mwfunk 7y ago

I enjoyed the article but this quote jumped out at me: "What took thirty years to build isn't going to be replaced in a day." This was in regard to replacing X11 with Wayland. It's funny because it would be closer to the truth to say that X11 took 5 years to build, and for the last 25 years everyone has been trying to get off of it, but in the meantime piling more stuff on top of it since that's easier than starting from scratch. 25 years ago there were people saying stuff like, "I wish we had something else, but this is what we're stuck with, and it's just too much work to make a new window system, so let's just add another protocol extension." So we're already 25 years into trying to replace X11, which is already far longer than the period of time in which it was being designed and actively developed on a foundational level. There's got to be some good lessons learned in all of this about software lifecycles or getting it right the first time or knowing when to move on or OS development by way of mailing list consensus. I totally get why it's still used after all these years, it performs an essential task- but I bet the original creators would be the ones most shocked that it's still a thing in 2019.

jolmg 7y ago
> but I bet the original creators would be the ones most shocked that it's still a thing in 2019. Couldn't we say the same thing about bash or basically most tools in your typical Unix-based OS? Old code is solid code. If they're to be shocked it's for doing something so right that it's persisted all this time.
- DonHopkins 7y ago
  Except that X11 isn't doing something so right -- it's still terrible, and it always has been, and we knew it was terrible at the time it was standardized. But it's funny that you would bring up something as terrible as a shell scripting language like bash to compare to how terrible X-Windows is. Have you ever read through a gnu configure file yourself, or do you just close your eyes and type "./configure"? Who in their right mind would ever write a shell script, when there are so many real scripting languages that don't terribly suck universally available, that don't shit themselves when they encounter a file name with a space in it? These quotes about X-Windows apply to bash as much as they do to X-Windows: "Using these toolkits is like trying to make a bookshelf out of mashed potatoes." -Jamie Zawinski "Programming X-Windows is like trying to find the square root of pi using roman numerals." -Unknown https://medium.com/@donhopkins/the-x-windows-disaster-128d398ebd47 https://medium.com/@donhopkins/the-x-windows-disaster-128d39...
  - jolmg 7y ago
    > as terrible as a shell scripting language That's a strong opinion. I'm not going to argue for lack of time, but suffice to say that 99% of my interactions with my computer and sometimes with my phone is with a shell scripting language. Shell scripting is awesome. > Have you ever read through a gnu configure file yourself, Yes. Generated scripts make for a boring read. > or do you just close your eyes and type "./configure"? I do, from people I chose to trust, whether by running the package build scripts written by the package maintainers of my distribution or from github accounts that I judge as trustworthy. There is a lot of trust involved in using a computer. I mean, if something nefarious might be in the ./configure script, it's more likely to also be in a precompiled program, since more people touched it. > Who in their right mind would ever write a shell script, I do. > when there are so many real scripting languages that don't terribly suck universally available, Each language is good for different reasons. Shell languages are meant primarily to be used interactively, as opposed to languages like python or ruby. The fact that you can put your everyday interactions in a file and run that is an added bonus. > that don't shit themselves when they encounter a file name with a space in it? I rather not have filenames with spaces if it means having a language that allows me to communicate with my machine in a terse manner, allowing for super-easy automation of all sorts of interactions. I mean, are you really suggesting to mandate quoting of all strings in a shell language? The quotes are optional. That's good! In a shell language, files are basically your variables, so why would you want more syntax around your variables when working interactively?
    - deleted 7y ago
      [deleted]
    - deleted 7y ago
      [deleted]
    - njepa 7y ago
      > That's a strong opinion. I'm not going to argue for lack of time, but suffice to say that 99% of my interactions with my computer and sometimes with my phone is with a shell scripting language. Shell scripting is awesome. It really isn't though. (It certainly can be fun however). Switching from shell scripts, and avoiding to do things manually (like ssh), likely increases your success rate at managing *nix by orders of magnitude. All these "configuration management" tools like Puppet, Chef, SaltStack, Ansible etc. are pretty much just to avoid shell scripts and interactive ssh.
DonHopkins 7y ago
The reason X11 got pushed through so quickly 30 years ago was that some vendors were threatening to standardize on X10. Maybe they should have just gone with X10, because it would have been easier to eventually replace.
- rwmj 7y ago
  It's a real shame that MGR never got any traction (I think license problems and it came along too late). It was really "X done right". https://hack.org/mc/mgr/ https://hack.org/mc/mgr/ https://en.wikipedia.org/wiki/ManaGeR https://en.wikipedia.org/wiki/ManaGeR
amelius 7y ago
Well at least it's the best kind of lock-in.
0xfaded 7y ago
I've been reading through the Vulkan spec, which is in way similar in that OpenGL has been extended since its introduction in 1992 with more and more features to support new graphics capabilities as they evolved. I've seen Vulkan called the successor to OpenGL, but reading the spec it seems more like the end game for raster graphics card programming. OpenGL 4.0 was released in 2010, and since then changes have been incremental. We more or less have figured out how to do raster graphics (ray tracing may be a different story), so it made sense to invest tens (hundreds?) of millions of dollars to develop the Vulkan spec, and then many millions more to implement it. What other technologies are there were we are more or less at the end game? I know Qt5 widgets is considered feature complete for desktop apps.
- jchw 7y ago
  Qt Widgets is an amazing library, but honestly it is both more and less featureful than it needs to be in various cases. The rich text document stuff still holds up OK for basic cases, but I think the text rendering story could be a bit better. Last time I was doing low level text stuff in Qt, performance was not super impressive, and some of the APIs left a bit to be desired.
  - jlarcombe 7y ago
    Well said. The notion that Qt widgets are "finished" was just an aspiration not to spend much more money on it I think; they sort of rowed back on this when it became apparent that Qt Quick isn't always appropriate, but by then it had sort of spread around as a "Qt fact" amongst people who didn't actually use it. The number of rough edges, missing bits and outright bugs mean that it's certainly not "finished"... just like all software really.
    - pjmlp 7y ago
      They helped spread the rummor when plenty of new features are QML only, specially when targeting non-desktop devices. To this day if you want a common file dialog that works properly across all Qt deployment targets, you need to use QML, as the Widgets version is not adaptive and will display a tiny desktop common file dialog on an LCD display, for example.
simion314 7y ago
X is good enough for majority of the users, even if the architecture is not perfect.
- floatboth 7y ago
  Screen tearing, bad performance, bad touchscreen support (not independent of mouse cursor), and especially important these days: no real HiDPI support (practically impossible to support different scales for different monitors). It's not good enough.
  - chmln 7y ago
    These claims are blown out of proportion and/or simply untrue. Screen tearing: both Intel and AMD have hardware-backed "TearFree" buffering to prevent tearing. Bad performance: citation required - in my experience, Xorg is way faster. Touchscreen support - in most cases just works out of the box thanks to libinput. No HiDPI support for different scales per monitor - simply wrong - this is trivial with xrandr.
    - blibble 7y ago
      I still find tearing to be problematic I have a machine with a supported Radeon card (open-source driver), another machine with a supported nvidia card (binary blob driver), and another two machines using different intel onboard graphics chips (open-source driver) the radeon and the intel (both drivers which work with it) have issues putting out a stable jitterless 60fps without tearing (with tearfree on, and various combinations of with/without compositing/glx/...)
      - chmln 7y ago
        How did you test the fps? I'm using the intel driver as well, and it's definitely not perfect. But it's pretty close, at least for me - I get hardware-accelerated video decoding with VAAPI, no tearing, and excellent input latency (~3ms).
russed 7y ago
This is exactly what I think when I hear "worse is better". Some software just needs to be right the first time.
bsder 7y ago
The problem is actually Linux. Linux development is quite fine--until you have a problem that crosses domain boundaries. Then you have hot flaming hairballs of failure. This is why video, audio, Bluetooth, SoC detection/driver installation, etc. all suck on Linux. Nobody giving Linux the spec for video chipsets just adds to the misery.
roenxi 7y ago
> since that's easier than starting from scratch That is not quite accurate, although it isn't far off. More accurately; the design mistakes that make/made X11 terrible were being enforced at the driver level. Take the fact that for many years X was being run as root on linux. Horrific state of affairs for security. Everyone knows it is bad. Some bright spark tries to write a new window system that runs as an unprivilaged user; and ran smack-bang into the fact that the drivers live in the window system because the Kernel doesn't accept closed source modules and the graphics vendors only support X. That eventually got fixed with the Intel/AMD graphics graphics open sourcing 2008-2018; at the moment X is becoming a very thin comparability layer for most people and a mandatory pain for Nvidia users as far as I know. There were a lot of issues like that, and still are with Nvidia. The point is that it isn't replacing X that is hard. The issues is coordinating with Nvidia is hard.
- IntelMiner 7y ago
  I orbit someone on the nouveau team, so I might be a bit biased with regard to Nvidia As far as I can tell, Nvidia has two modes of operation with the Linux community, "hostile" and "inept" Hostile is when they do things like require signed firmware for their GPU's or try to force their will on things like EGLstreams, while everyone else is using GBM Inept is their situation with things like the Tegra mobile platforms. They simply use nouveau instead I'm told. Even though the two GPU lines of course, share a ton of engineering. For some reason they just decided it's easier to use nouveau on that side, and only that side
- bscphil 7y ago
  >That eventually got fixed with the Intel/AMD graphics graphics open sourcing 2008-2018; at the moment X is becoming a very thin comparability layer for most people and a mandatory pain for Nvidia users as far as I know. It's even better than that now. For me no part of X is running as root. Last I checked the only reason anyone had X as root (other than driver issues) was if they were running a graphical login manager). Since the login manager has to be up and running before any users are logged in, and likely requires X, it makes since that it's got to run in a privileged context, and works most easily as root. In my case I just use xinit to start my graphical sessions after I've logged directly into a (getty) terminal. I think supposedly GDM can do rootless X, but I haven't tested that.

by mwfunk 7y ago

jolmg 7y ago

> but I bet the original creators would be the ones most shocked that it's still a thing in 2019. Couldn't we say the same thing about bash or basically most tools in your typical Unix-based OS? Old code is solid code. If they're to be shocked it's for doing something so right that it's persisted all this time.

DonHopkins 7y ago
Except that X11 isn't doing something so right -- it's still terrible, and it always has been, and we knew it was terrible at the time it was standardized. But it's funny that you would bring up something as terrible as a shell scripting language like bash to compare to how terrible X-Windows is. Have you ever read through a gnu configure file yourself, or do you just close your eyes and type "./configure"? Who in their right mind would ever write a shell script, when there are so many real scripting languages that don't terribly suck universally available, that don't shit themselves when they encounter a file name with a space in it? These quotes about X-Windows apply to bash as much as they do to X-Windows: "Using these toolkits is like trying to make a bookshelf out of mashed potatoes." -Jamie Zawinski "Programming X-Windows is like trying to find the square root of pi using roman numerals." -Unknown https://medium.com/@donhopkins/the-x-windows-disaster-128d398ebd47 https://medium.com/@donhopkins/the-x-windows-disaster-128d39...
- jolmg 7y ago
  > as terrible as a shell scripting language That's a strong opinion. I'm not going to argue for lack of time, but suffice to say that 99% of my interactions with my computer and sometimes with my phone is with a shell scripting language. Shell scripting is awesome. > Have you ever read through a gnu configure file yourself, Yes. Generated scripts make for a boring read. > or do you just close your eyes and type "./configure"? I do, from people I chose to trust, whether by running the package build scripts written by the package maintainers of my distribution or from github accounts that I judge as trustworthy. There is a lot of trust involved in using a computer. I mean, if something nefarious might be in the ./configure script, it's more likely to also be in a precompiled program, since more people touched it. > Who in their right mind would ever write a shell script, I do. > when there are so many real scripting languages that don't terribly suck universally available, Each language is good for different reasons. Shell languages are meant primarily to be used interactively, as opposed to languages like python or ruby. The fact that you can put your everyday interactions in a file and run that is an added bonus. > that don't shit themselves when they encounter a file name with a space in it? I rather not have filenames with spaces if it means having a language that allows me to communicate with my machine in a terse manner, allowing for super-easy automation of all sorts of interactions. I mean, are you really suggesting to mandate quoting of all strings in a shell language? The quotes are optional. That's good! In a shell language, files are basically your variables, so why would you want more syntax around your variables when working interactively?
  - deleted 7y ago
    [deleted]
  - deleted 7y ago
    [deleted]
  - njepa 7y ago
    > That's a strong opinion. I'm not going to argue for lack of time, but suffice to say that 99% of my interactions with my computer and sometimes with my phone is with a shell scripting language. Shell scripting is awesome. It really isn't though. (It certainly can be fun however). Switching from shell scripts, and avoiding to do things manually (like ssh), likely increases your success rate at managing *nix by orders of magnitude. All these "configuration management" tools like Puppet, Chef, SaltStack, Ansible etc. are pretty much just to avoid shell scripts and interactive ssh.

DonHopkins 7y ago

The reason X11 got pushed through so quickly 30 years ago was that some vendors were threatening to standardize on X10. Maybe they should have just gone with X10, because it would have been easier to eventually replace.

rwmj 7y ago
It's a real shame that MGR never got any traction (I think license problems and it came along too late). It was really "X done right". https://hack.org/mc/mgr/ https://hack.org/mc/mgr/ https://en.wikipedia.org/wiki/ManaGeR https://en.wikipedia.org/wiki/ManaGeR

amelius 7y ago

Well at least it's the best kind of lock-in.

0xfaded 7y ago

I've been reading through the Vulkan spec, which is in way similar in that OpenGL has been extended since its introduction in 1992 with more and more features to support new graphics capabilities as they evolved. I've seen Vulkan called the successor to OpenGL, but reading the spec it seems more like the end game for raster graphics card programming. OpenGL 4.0 was released in 2010, and since then changes have been incremental. We more or less have figured out how to do raster graphics (ray tracing may be a different story), so it made sense to invest tens (hundreds?) of millions of dollars to develop the Vulkan spec, and then many millions more to implement it. What other technologies are there were we are more or less at the end game? I know Qt5 widgets is considered feature complete for desktop apps.

jchw 7y ago
Qt Widgets is an amazing library, but honestly it is both more and less featureful than it needs to be in various cases. The rich text document stuff still holds up OK for basic cases, but I think the text rendering story could be a bit better. Last time I was doing low level text stuff in Qt, performance was not super impressive, and some of the APIs left a bit to be desired.
- jlarcombe 7y ago
  Well said. The notion that Qt widgets are "finished" was just an aspiration not to spend much more money on it I think; they sort of rowed back on this when it became apparent that Qt Quick isn't always appropriate, but by then it had sort of spread around as a "Qt fact" amongst people who didn't actually use it. The number of rough edges, missing bits and outright bugs mean that it's certainly not "finished"... just like all software really.
  - pjmlp 7y ago
    They helped spread the rummor when plenty of new features are QML only, specially when targeting non-desktop devices. To this day if you want a common file dialog that works properly across all Qt deployment targets, you need to use QML, as the Widgets version is not adaptive and will display a tiny desktop common file dialog on an LCD display, for example.

simion314 7y ago

X is good enough for majority of the users, even if the architecture is not perfect.

floatboth 7y ago
Screen tearing, bad performance, bad touchscreen support (not independent of mouse cursor), and especially important these days: no real HiDPI support (practically impossible to support different scales for different monitors). It's not good enough.
- chmln 7y ago
  These claims are blown out of proportion and/or simply untrue. Screen tearing: both Intel and AMD have hardware-backed "TearFree" buffering to prevent tearing. Bad performance: citation required - in my experience, Xorg is way faster. Touchscreen support - in most cases just works out of the box thanks to libinput. No HiDPI support for different scales per monitor - simply wrong - this is trivial with xrandr.
  - blibble 7y ago
    I still find tearing to be problematic I have a machine with a supported Radeon card (open-source driver), another machine with a supported nvidia card (binary blob driver), and another two machines using different intel onboard graphics chips (open-source driver) the radeon and the intel (both drivers which work with it) have issues putting out a stable jitterless 60fps without tearing (with tearfree on, and various combinations of with/without compositing/glx/...)
    - chmln 7y ago
      How did you test the fps? I'm using the intel driver as well, and it's definitely not perfect. But it's pretty close, at least for me - I get hardware-accelerated video decoding with VAAPI, no tearing, and excellent input latency (~3ms).

russed 7y ago

This is exactly what I think when I hear "worse is better". Some software just needs to be right the first time.

bsder 7y ago

The problem is actually Linux. Linux development is quite fine--until you have a problem that crosses domain boundaries. Then you have hot flaming hairballs of failure. This is why video, audio, Bluetooth, SoC detection/driver installation, etc. all suck on Linux. Nobody giving Linux the spec for video chipsets just adds to the misery.

roenxi 7y ago

> since that's easier than starting from scratch That is not quite accurate, although it isn't far off. More accurately; the design mistakes that make/made X11 terrible were being enforced at the driver level. Take the fact that for many years X was being run as root on linux. Horrific state of affairs for security. Everyone knows it is bad. Some bright spark tries to write a new window system that runs as an unprivilaged user; and ran smack-bang into the fact that the drivers live in the window system because the Kernel doesn't accept closed source modules and the graphics vendors only support X. That eventually got fixed with the Intel/AMD graphics graphics open sourcing 2008-2018; at the moment X is becoming a very thin comparability layer for most people and a mandatory pain for Nvidia users as far as I know. There were a lot of issues like that, and still are with Nvidia. The point is that it isn't replacing X that is hard. The issues is coordinating with Nvidia is hard.

IntelMiner 7y ago
I orbit someone on the nouveau team, so I might be a bit biased with regard to Nvidia As far as I can tell, Nvidia has two modes of operation with the Linux community, "hostile" and "inept" Hostile is when they do things like require signed firmware for their GPU's or try to force their will on things like EGLstreams, while everyone else is using GBM Inept is their situation with things like the Tegra mobile platforms. They simply use nouveau instead I'm told. Even though the two GPU lines of course, share a ton of engineering. For some reason they just decided it's easier to use nouveau on that side, and only that side
bscphil 7y ago
>That eventually got fixed with the Intel/AMD graphics graphics open sourcing 2008-2018; at the moment X is becoming a very thin comparability layer for most people and a mandatory pain for Nvidia users as far as I know. It's even better than that now. For me no part of X is running as root. Last I checked the only reason anyone had X as root (other than driver issues) was if they were running a graphical login manager). Since the login manager has to be up and running before any users are logged in, and likely requires X, it makes since that it's got to run in a privileged context, and works most easily as root. In my case I just use xinit to start my graphical sessions after I've logged directly into a (getty) terminal. I think supposedly GDM can do rootless X, but I haven't tested that.