4 ms·

> We're in 2023, and I'm still reading about pieces of software that can be exploited because of poor memory management (either unexpected reads, unexpected wri

> We're in 2023, and I'm still reading about pieces of software that can be exploited because of poor memory management (either unexpected reads, unexpected writes, or incorrect deallocation). wait until 2123 when you will still read about them and Wayland will almost be ready. side note: can we please stop this nonsense whining around infrastructures? yes, infrastructures are old, they are old because they work, they work because they were carefully engineered and maintained. A bug in some infrastructure code is not the end of the World, it's, on the contrary, a sign of its vitality. Yes, roads still have holes in them, even though we invented them thousands years ago, it doesn't make them less useful. EDIT: rewriting X11 proved to be almost a failure, after 15 years, in 2023, on my laptop KDE/Wayland can't start the plasmashell, while X11 still rocks the boat without a glitch. This constant lamentation about "safe languages", that sounds like the sirens in The Odyssey, and the promotion of "rewrite it!" - in this case X11 (AGAIN!) - in some new shiny language of today like if 40 years totally make the difference between the past and the future, it's the most serious form of delusion I have ever witnessed in my whole life.

blacklight 4y ago
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.
c-cube 4y ago
40 years is a really long time in computing. If you add to that the fact that C was already antiquated when it was designed, it means a modern language that learnt from decades of practice and CS advances can be a truly different beast.
- peoplefromibiza 4y ago
  > 40 years is a really long time in computing get used to it. it's just the first time we had 40 years ahead of us to use the same software for 40 years. LISP is just 63 years old, C 51, C++ only 38... Everything is still brand new in computing. > it means a modern language that learnt from decades of practice and CS it's only a matter of computational speed, we knew about "advanced concepts" in the 30s of the last century already.
  - c-cube 4y ago
    > it's only a matter of computational speed, we knew about "advanced concepts" in the 30s of the last century already. Believe it or not, but type theory and CS in general have kept making progress since. I know lambda calculus existed in the 30s, but it was a lot more basic in many ways. C is so primitive. It has a poor type system, it has no sum types (enums, in rust), no closures, no type inference, no bound checking even though it was already known to be beneficial, really its strong point is that it's easy to compile. If you think these are just "computational speed", that's fine, but other people think these are qualitative improvements.
    - peoplefromibiza 4y ago
      > C is so primitive. It has a poor type system, it has no sum types (enums, in rust), no closures, no type inference, no bound checking even though it was already known to be beneficial, computational speed mattered. compilers needed to be fast. bounds checking is not really in the ballpark of "advancements in CS". C could easily become a better language and evolve, the problem is it needs to maintain the billions of lines already written valid. OTOH there were better languages already when C came out, C won in large part because it was simpler, smaller and a better ASM than ASM. Rust is a safer language, the problem is once we rewrote everything in Rust, Rust will be as legacy as C and new languages with better features enabled by the orders of magnitude faster chips will be available. It's like when young people blame the older people, forgetting that they will be old too one day and that in most part life is keeping going on evolving things at a very slow pace, because inertia is the strongest force in societies.

blacklight 4y ago

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.

c-cube 4y ago

40 years is a really long time in computing. If you add to that the fact that C was already antiquated when it was designed, it means a modern language that learnt from decades of practice and CS advances can be a truly different beast.

peoplefromibiza 4y ago
> 40 years is a really long time in computing get used to it. it's just the first time we had 40 years ahead of us to use the same software for 40 years. LISP is just 63 years old, C 51, C++ only 38... Everything is still brand new in computing. > it means a modern language that learnt from decades of practice and CS it's only a matter of computational speed, we knew about "advanced concepts" in the 30s of the last century already.
- c-cube 4y ago
  > it's only a matter of computational speed, we knew about "advanced concepts" in the 30s of the last century already. Believe it or not, but type theory and CS in general have kept making progress since. I know lambda calculus existed in the 30s, but it was a lot more basic in many ways. C is so primitive. It has a poor type system, it has no sum types (enums, in rust), no closures, no type inference, no bound checking even though it was already known to be beneficial, really its strong point is that it's easy to compile. If you think these are just "computational speed", that's fine, but other people think these are qualitative improvements.
  - peoplefromibiza 4y ago
    > C is so primitive. It has a poor type system, it has no sum types (enums, in rust), no closures, no type inference, no bound checking even though it was already known to be beneficial, computational speed mattered. compilers needed to be fast. bounds checking is not really in the ballpark of "advancements in CS". C could easily become a better language and evolve, the problem is it needs to maintain the billions of lines already written valid. OTOH there were better languages already when C came out, C won in large part because it was simpler, smaller and a better ASM than ASM. Rust is a safer language, the problem is once we rewrote everything in Rust, Rust will be as legacy as C and new languages with better features enabled by the orders of magnitude faster chips will be available. It's like when young people blame the older people, forgetting that they will be old too one day and that in most part life is keeping going on evolving things at a very slow pace, because inertia is the strongest force in societies.