3 ms·

The problem is that, as IT technologies become older, there will be less and less people who can understand what's going on, debug and fix things. At that point

The problem is that, as IT technologies become older, there will be less and less people who can understand what's going on, debug and fix things. At that point, degradation becomes inevitable, and projects go in maintenance-only mode because adding new features is just too hard and risky. Have you wondered why the X.Org server still fails at doing simple things like inferring the DPI and supporting retina displays without extra configuration? Or why you need external window compositors? Have you ever tried to play with the X11 C API, just to land on cryptic documentation that hasn't been updated in 25 years? Or, worse, dive into the source code of the server, and find 40 years of workarounds that make you feel like taking one straw away will make the whole castle collapse? Note that the same also applies to other pieces of software (like xterm) that are way past their expiry date. Software should not get into this stage and still be massively used in production. We should avoid projects like X.Org from becoming the next COBOL.

peoplefromibiza 4y ago
> At that point, degradation becomes inevitable, and projects go in maintenance-only mode because adding new features is just too hard and risky. I repeat it: Wayland is 15 years old and it's written in C. I'm waiting for a rewrite in Rust or whatever, so in 15 years I will still be using X11, because it's the only thing that works reliably across my devices, old and new. > Have you ever tried to play with the X11 C API yes, since 1996. > and find 40 years of workarounds that's called "SOLUTIONS" in professionals' World. The real World is full of edge cases, if your code is dealing with none of them, your solution is probably fragile. https://www.luckymethod.com/2013/03/the-big-redesign-in-the-sky/ https://www.luckymethod.com/2013/03/the-big-redesign-in-the-... > Software should not get into this stage and still be massively used in production > We should avoid projects like X.Org from becoming the next COBOL. That's the wrong way to look at it. We should ask ourselves: why COBOL is still in use after so long, while a JavaScript framework lasts 6 months and it's deprecated after 9? Can I rely long term on that thing or not? If I had to guess, COBOL will still be in use in 20 years from now. The demise of old technologies has been predicted so many times that it's now a joke in the industry. COBOL was already old and on its way out when I was in high school, studying those languages that would SURELY replace it, in the beginning of the 90s of the last century, almost 35 years ago. I understand that a young industry, that mostly runs on young people because of the ageism in SV, feels it can fix everything in a few months, but that's the illusion: we collectively can't. The more a technology stays in place, the more time it will stay relevant. There's also a law about it, I don't remember the name now.
- kaba0 4y ago
  Wayland is a fking protocol, it is not written in anything. If you can’t get that right then there is no point in any discussion.
  - peoplefromibiza 4y ago
    X11 is a protocol too, my pedantic friend. All the relevant Wayland implementations right now are written in C or C++. All the beautiful and safe languages implementations out there are used by virtually no one. After 15 years, X11 still works better (in the sense of on more hardware, with less headaches) than the new kid on the block. There must be a reason why, I strongly believe it's not the language the two protocol were mostly implemented in, because it's the same. I believe, but I could be wrong, it's that rewriting a fundamental piece of software infrastructure it's not as easy as people imagine. Implementing the 90% it's easy, making the rest 10% work is hard, making the switch worthwhile it's where usually all the dreams of a perfect World full of rainbows and unicorns go to die. And that's usually the moment when the "rewrite" gets "rewritten", to not admit failure. I would love to switch to Wayland, if only it worked all the time. I need to get things done unfortunately, I can't spend months debugging issues that should not be there in the first place, like drawing a few buttons and windows on the screen reliably.
badsectoracula 4y ago
> Have you wondered why the X.Org server still fails at doing simple things like inferring the DPI At least on my monitor X seems to have a good idea for the display size: dimensions: 1920x1080 pixels (508x285 millimeters) This should be all information any software needs to calculate DPI. "Dpi" is configured to 96 for backwards compatibility, but if any program actually needs that information it can query it. > and supporting retina displays without extra configuration? "Retina displays" is just a marketing term for displays that have high pixel density and supporting those is really a thing for the applications (they need to be able to handle scaling so that they appear at the same size as in a normal or low pixel density display). Unless the display server works with device independent units and doesn't deal with any pixel content whatsoever, you always need application support for that. > Or why you need external window compositors? (assume you mean desktop compositors like Compiz, etc) Because it is an optional feature introduced much later than X's inception, cannot work on every single hardware that can run X and after all since X has a mantra of providing mechanism instead of policy, it only provided enough functionality to implement compositors without forcing them or dictated a single way of what sort of functionality they'd provide (which at the time ended up with a multitude of different compositors with various effects and other functionality). It is also an optional feature which in my eyes is a great thing as i don't like the input lag they add even to simple desktop interactions like moving windows around (even with Wayland where the entire thing is designed with desktop composition in mind).

peoplefromibiza 4y ago

> At that point, degradation becomes inevitable, and projects go in maintenance-only mode because adding new features is just too hard and risky. I repeat it: Wayland is 15 years old and it's written in C. I'm waiting for a rewrite in Rust or whatever, so in 15 years I will still be using X11, because it's the only thing that works reliably across my devices, old and new. > Have you ever tried to play with the X11 C API yes, since 1996. > and find 40 years of workarounds that's called "SOLUTIONS" in professionals' World. The real World is full of edge cases, if your code is dealing with none of them, your solution is probably fragile. https://www.luckymethod.com/2013/03/the-big-redesign-in-the-sky/ https://www.luckymethod.com/2013/03/the-big-redesign-in-the-... > Software should not get into this stage and still be massively used in production > We should avoid projects like X.Org from becoming the next COBOL. That's the wrong way to look at it. We should ask ourselves: why COBOL is still in use after so long, while a JavaScript framework lasts 6 months and it's deprecated after 9? Can I rely long term on that thing or not? If I had to guess, COBOL will still be in use in 20 years from now. The demise of old technologies has been predicted so many times that it's now a joke in the industry. COBOL was already old and on its way out when I was in high school, studying those languages that would SURELY replace it, in the beginning of the 90s of the last century, almost 35 years ago. I understand that a young industry, that mostly runs on young people because of the ageism in SV, feels it can fix everything in a few months, but that's the illusion: we collectively can't. The more a technology stays in place, the more time it will stay relevant. There's also a law about it, I don't remember the name now.

kaba0 4y ago
Wayland is a fking protocol, it is not written in anything. If you can’t get that right then there is no point in any discussion.
- peoplefromibiza 4y ago
  X11 is a protocol too, my pedantic friend. All the relevant Wayland implementations right now are written in C or C++. All the beautiful and safe languages implementations out there are used by virtually no one. After 15 years, X11 still works better (in the sense of on more hardware, with less headaches) than the new kid on the block. There must be a reason why, I strongly believe it's not the language the two protocol were mostly implemented in, because it's the same. I believe, but I could be wrong, it's that rewriting a fundamental piece of software infrastructure it's not as easy as people imagine. Implementing the 90% it's easy, making the rest 10% work is hard, making the switch worthwhile it's where usually all the dreams of a perfect World full of rainbows and unicorns go to die. And that's usually the moment when the "rewrite" gets "rewritten", to not admit failure. I would love to switch to Wayland, if only it worked all the time. I need to get things done unfortunately, I can't spend months debugging issues that should not be there in the first place, like drawing a few buttons and windows on the screen reliably.

badsectoracula 4y ago

> Have you wondered why the X.Org server still fails at doing simple things like inferring the DPI At least on my monitor X seems to have a good idea for the display size: dimensions: 1920x1080 pixels (508x285 millimeters) This should be all information any software needs to calculate DPI. "Dpi" is configured to 96 for backwards compatibility, but if any program actually needs that information it can query it. > and supporting retina displays without extra configuration? "Retina displays" is just a marketing term for displays that have high pixel density and supporting those is really a thing for the applications (they need to be able to handle scaling so that they appear at the same size as in a normal or low pixel density display). Unless the display server works with device independent units and doesn't deal with any pixel content whatsoever, you always need application support for that. > Or why you need external window compositors? (assume you mean desktop compositors like Compiz, etc) Because it is an optional feature introduced much later than X's inception, cannot work on every single hardware that can run X and after all since X has a mantra of providing mechanism instead of policy, it only provided enough functionality to implement compositors without forcing them or dictated a single way of what sort of functionality they'd provide (which at the time ended up with a multitude of different compositors with various effects and other functionality). It is also an optional feature which in my eyes is a great thing as i don't like the input lag they add even to simple desktop interactions like moving windows around (even with Wayland where the entire thing is designed with desktop composition in mind).