6 ms·

Imagine if CLIs routinely died off and had to be rotated out. Sorry you are running stdout from 2022. You need 2025 stdout to print text. I guess you can alwa

Imagine if CLIs routinely died off and had to be rotated out. Sorry you are running stdout from 2022. You need 2025 stdout to print text. I guess you can always bundle Qt with your app but the X11 / Wayland split might have complicated that? I just hate it. Viscerally I hate it.

emptiestplace 2y ago
Conversely, Windows.
- wongarsu 2y ago
  Both in the sense that Win32 GUIs (introduced in Windows 95) are a bit out of style but are still supported and widely used; and Powershell being a major departure from traditional CLIs.
  - emptiestplace 2y ago
    I guess that's what I get for being so terse - I actually meant it as a counterexample. Windows is a good illustration of what happens when you avoid deprecating older systems: you end up with multiple design philosophies and interfaces layered on top of each other, leading to a less cohesive user experience overall.
duskwuff 2y ago
Counterpoint: libncurses5 vs libncurses6.
atomicnumber3 2y ago
Part of the benefit here though is that everyone has LOTS of options. Go run Debian or an LTS of something else. App packagers can appimage or flatpack. People can qt5 install from a PPA im sure. The key thing here is that it lets packagers keep focusing on more impactful things than babysitting projects that can't/won't upgrade, especially when that babysitting ending frees up a lot of brainpower AND is reasonably easily picked up by people who still need that.
jchw 2y ago
Qt isn't dying off. They're removing old versions of it from the distribution repositories. (Or well, trying to, anyways.) Yes, it's neat that you can still compile and run ancient Win32 programs on modern Windows, but maintaining all of that compatibility is a burden Microsoft was able to bear. The open source community is still struggling to try to provide a compelling desktop experience without this burden. Can you run ancient old Linux graphical software? Well, to an extent... Yes. Is it easy? ...No. At least, it's certainly not as easy as installing stuff from your OS vendor directly. As far as Wayland goes, there are no plans to get rid of XWayland any time soon. I'd wager it will remain in the toolkit for decades to come, and if anything, XWayland support keeps getting better rather than worse; just look at what KDE has been doing. Usually, when I want to try to run something really old I'll use the Docker debian/eol[1] images. Getting X11 apps to work inside of Docker requires a bit of fidgeting, but once you have it working, it's relatively straight-forward to install or build and use software inside of. The Linux desktop is necessarily going to keep going through large breaking shifts because well, it sucks. It needs to go through breakages. When the new thing also seems to suck, that hints that it might need to continue to break more. It's going to take a while to iron things out, especially because designing systems is hard and sometimes new ideas don't wind up panning out very well. (This has caused a lot of trouble with Wayland where a lot of ideas, indeed, did not pan out super well in practice in my opinion.) That said, I think we can do much work to improve interoperability with older software, and ensure that it can continue to run in the future. But, it doesn't have to, and really, shouldn't work by keeping everything else from moving. [1]: https://hub.docker.com/r/debian/eol https://hub.docker.com/r/debian/eol
- chgs 2y ago
  I find it amusing that there’s this constant assetion on this forum that the Linux desktop sucks Yet many of us have been quite happy with it for decades, and the major problems tend to be with new stuff that seems to be added just to do something different.
  - jchw 2y ago
    I have been using Linux as my primary operating system for two decades, and I think the Linux desktop sucks. I strongly disagree that my problems with it are largely the result of "new stuff that seems to be added just to do something different". When I first started using Linux, there was no kernel modesetting and XFree86 ran as root. I had to manually configure my graphics and display settings by editing the Xorg.conf in nano, or sometimes I could get YaST to do it. Multi-head output was not well-supported, and you often had to restart to reconfigure your outputs. Installing the NVIDIA driver was a straight up pain in the ass. (Some things never change.) X.Org eventually improved and added hotplugging. The Linux desktop stack went through a lot of "new stuff" like new versions of DRM/DRI, the addition of hotplugging, the introduction of KMS and libinput. Dynamic input configuration was added with the `xinput` command. The XInput2 extension was developed to greatly improve touch and pen tablet support. XRandr made it possible to dynamically arrange displays, replacing Xinerama. UI toolkits needed to be rewritten to support scalable rendering so that we could have high DPI support. Most recently, a lot of work and many new protocols across multiple parts of the desktop stack had to be re-hauled from kernel to userland to support explicit synchronization for graphics tasks and buffers. All of this required major shifts, and that broke user's workflows at some points. Plenty of people were broken by the gradual transition to using libinput, from graphics tablets to Synaptics touchpads, a lot of work had to be redone in order to re-haul the input system. Only recently are there Linux laptops where the out-of-the-box touchpad experience is good enough to rival a MacBook, and it's certainly not all of them. Don't get me wrong, I loved KDE 3. And despite all of it's flaws, I still prefer Linux greatly over the other options available. But would I go back to using Linux 2.6 and KDE 3 and etc. today? Fuck no, we've improved so many things since then. And yes, no question that at times things have felt like they've been moving backwards in some regards, but it really isn't for nothing. The fact that modern desktop Linux trivially hotplugs displays with different DPIs and refresh rates (and potentially variable refresh rates) is genuinely something that took a herculean effort. All of that work required massive rewrites. It required kernel changes, graphics driver changes, it required major UI toolkit changes, it required redesigning apps and rewriting components. And yes, I admit I am not the biggest contributor to open source or anything, my patches are mostly unimportant. But, when I hit something that sucks in the Linux desktop, I do try my best to see if I can't do something about it. I have contributed random little bits here and there to various projects I care about. Most recently, I've been doing work to improve some situations where thumbnails in KDE are suboptimal. There's easily thousands of these little small issues that make Linux worse to use on desktop, we've got plenty of work to do. And I make it work. Except for work-owned computers, all of my machines run Linux, and I have a fair number of them. I do not have a single box I own personally that boots any other kernel or any other desktop. I know my way around Wine, even enough to make occasional, if small, code contributions. (For example, I made a quick patch when graphics tablets were not working in Wine under XWayland.) So I'm not suggesting that it's unusable, but I can't recommend the Linux desktop to random people. It's been getting closer, but a lot of the reason it's getting closer is because of some of the efforts that I assume you'd complain about.
pjmlp 2y ago
Image if stdout still required a physical UNIX teletype from 1970's actually work.
- neilv 2y ago
  Did it ever, or was that the tty abstraction rather than stdout?
  - pjmlp 2y ago
    Of course, C only came to be after six editions of UNIX.
    - nineteen999 2y ago
      Fourth edition UNIX was written in C in 1973: https://gunkies.org/wiki/UNIX_Fourth_Edition https://gunkies.org/wiki/UNIX_Fourth_Edition Unless we have different definitions of "edition".
serbuvlad 2y ago
I hate dynamic linking and this is one of the reasons. APIs should be small, self-contained, not break backwards compatibility (except for security reasons). Libraries provide much more extensive features and, as such, need to change a lot more often. APIs are: Linux system calls, the std{in,out,err} convention, termcap/terminfo, X/Wayland, D-Bus, PulseAudio/PipeWire etc. These change very rarely, and when they do they generally offer compatibility layers (XWayland, pipewire-pulse). But dynamic linking makes every single library an API that can break!
zamadatix 2y ago
That's why I stick to using sh. Wait no, bash... but make sure it's got all of the features from the 5.2 release... unless it's when I'm using zsh in which case we'll need to change some syntax around. For interactive use the program has an ncurses 6 interface, if you want to manage it that way, so make sure you aren't still back on ncurses 5 and have an xterm-256color terminal! Jokes aside, stdout is more like the X11/Wayland comment than anything... and even then it's been what, >30 years with one backwards compatible swap there?
- yjftsjthsd-h 2y ago
  Where's the joke? I do in fact target somewhat oldish POSIX sh when writing shell scripts; I want to write a script once and not have to worry about where it will run, and sh is basically universal.
  - deleted 2y ago
    [deleted]
  - zamadatix 2y ago
    The joke was the over the top-ness in the example of how CLI solutions have lacked forward compatibility as often as GUI solutions. The latter parts about how both CLI and GUI have decent examples of long term backwards compatibility were serious.
    - yjftsjthsd-h 2y ago
      I don't think it works that way either, though. AIUI the problem is that QT5 apps don't automatically work on QT6 (otherwise this would be a non-problem; Ubuntu would just ship QT6 alone and everything would work). But none of the shell examples given have that problem; AFAIK virtually every script that worked on BASH 4 works on BASH 5 - as does virtually every script that worked on any other older version of BASH, and every script that targets plain sh. If you wanted to make that argument, the ncurses suggestion by https://news.ycombinator.com/item?id=42020272 https://news.ycombinator.com/item?id=42020272 is probably more compelling than the shell itself, which is amazingly backwards compatible.
NikkiA 2y ago
You'll be hard pressed to find many CLI apps that still run properly on non-VT100 terminals, but back in the 80s and 90s software usually ran fine on a tvi912, wyse30, zenith22 AND vt100s as long as the termtype was set right. So in a sense, it do be like that, somewhat.

emptiestplace 2y ago

Conversely, Windows.

wongarsu 2y ago
Both in the sense that Win32 GUIs (introduced in Windows 95) are a bit out of style but are still supported and widely used; and Powershell being a major departure from traditional CLIs.
- emptiestplace 2y ago
  I guess that's what I get for being so terse - I actually meant it as a counterexample. Windows is a good illustration of what happens when you avoid deprecating older systems: you end up with multiple design philosophies and interfaces layered on top of each other, leading to a less cohesive user experience overall.

duskwuff 2y ago

Counterpoint: libncurses5 vs libncurses6.

atomicnumber3 2y ago

Part of the benefit here though is that everyone has LOTS of options. Go run Debian or an LTS of something else. App packagers can appimage or flatpack. People can qt5 install from a PPA im sure. The key thing here is that it lets packagers keep focusing on more impactful things than babysitting projects that can't/won't upgrade, especially when that babysitting ending frees up a lot of brainpower AND is reasonably easily picked up by people who still need that.

jchw 2y ago

Qt isn't dying off. They're removing old versions of it from the distribution repositories. (Or well, trying to, anyways.) Yes, it's neat that you can still compile and run ancient Win32 programs on modern Windows, but maintaining all of that compatibility is a burden Microsoft was able to bear. The open source community is still struggling to try to provide a compelling desktop experience without this burden. Can you run ancient old Linux graphical software? Well, to an extent... Yes. Is it easy? ...No. At least, it's certainly not as easy as installing stuff from your OS vendor directly. As far as Wayland goes, there are no plans to get rid of XWayland any time soon. I'd wager it will remain in the toolkit for decades to come, and if anything, XWayland support keeps getting better rather than worse; just look at what KDE has been doing. Usually, when I want to try to run something really old I'll use the Docker debian/eol[1] images. Getting X11 apps to work inside of Docker requires a bit of fidgeting, but once you have it working, it's relatively straight-forward to install or build and use software inside of. The Linux desktop is necessarily going to keep going through large breaking shifts because well, it sucks. It needs to go through breakages. When the new thing also seems to suck, that hints that it might need to continue to break more. It's going to take a while to iron things out, especially because designing systems is hard and sometimes new ideas don't wind up panning out very well. (This has caused a lot of trouble with Wayland where a lot of ideas, indeed, did not pan out super well in practice in my opinion.) That said, I think we can do much work to improve interoperability with older software, and ensure that it can continue to run in the future. But, it doesn't have to, and really, shouldn't work by keeping everything else from moving. [1]: https://hub.docker.com/r/debian/eol https://hub.docker.com/r/debian/eol

chgs 2y ago
I find it amusing that there’s this constant assetion on this forum that the Linux desktop sucks Yet many of us have been quite happy with it for decades, and the major problems tend to be with new stuff that seems to be added just to do something different.
- jchw 2y ago
  I have been using Linux as my primary operating system for two decades, and I think the Linux desktop sucks. I strongly disagree that my problems with it are largely the result of "new stuff that seems to be added just to do something different". When I first started using Linux, there was no kernel modesetting and XFree86 ran as root. I had to manually configure my graphics and display settings by editing the Xorg.conf in nano, or sometimes I could get YaST to do it. Multi-head output was not well-supported, and you often had to restart to reconfigure your outputs. Installing the NVIDIA driver was a straight up pain in the ass. (Some things never change.) X.Org eventually improved and added hotplugging. The Linux desktop stack went through a lot of "new stuff" like new versions of DRM/DRI, the addition of hotplugging, the introduction of KMS and libinput. Dynamic input configuration was added with the `xinput` command. The XInput2 extension was developed to greatly improve touch and pen tablet support. XRandr made it possible to dynamically arrange displays, replacing Xinerama. UI toolkits needed to be rewritten to support scalable rendering so that we could have high DPI support. Most recently, a lot of work and many new protocols across multiple parts of the desktop stack had to be re-hauled from kernel to userland to support explicit synchronization for graphics tasks and buffers. All of this required major shifts, and that broke user's workflows at some points. Plenty of people were broken by the gradual transition to using libinput, from graphics tablets to Synaptics touchpads, a lot of work had to be redone in order to re-haul the input system. Only recently are there Linux laptops where the out-of-the-box touchpad experience is good enough to rival a MacBook, and it's certainly not all of them. Don't get me wrong, I loved KDE 3. And despite all of it's flaws, I still prefer Linux greatly over the other options available. But would I go back to using Linux 2.6 and KDE 3 and etc. today? Fuck no, we've improved so many things since then. And yes, no question that at times things have felt like they've been moving backwards in some regards, but it really isn't for nothing. The fact that modern desktop Linux trivially hotplugs displays with different DPIs and refresh rates (and potentially variable refresh rates) is genuinely something that took a herculean effort. All of that work required massive rewrites. It required kernel changes, graphics driver changes, it required major UI toolkit changes, it required redesigning apps and rewriting components. And yes, I admit I am not the biggest contributor to open source or anything, my patches are mostly unimportant. But, when I hit something that sucks in the Linux desktop, I do try my best to see if I can't do something about it. I have contributed random little bits here and there to various projects I care about. Most recently, I've been doing work to improve some situations where thumbnails in KDE are suboptimal. There's easily thousands of these little small issues that make Linux worse to use on desktop, we've got plenty of work to do. And I make it work. Except for work-owned computers, all of my machines run Linux, and I have a fair number of them. I do not have a single box I own personally that boots any other kernel or any other desktop. I know my way around Wine, even enough to make occasional, if small, code contributions. (For example, I made a quick patch when graphics tablets were not working in Wine under XWayland.) So I'm not suggesting that it's unusable, but I can't recommend the Linux desktop to random people. It's been getting closer, but a lot of the reason it's getting closer is because of some of the efforts that I assume you'd complain about.

pjmlp 2y ago

Image if stdout still required a physical UNIX teletype from 1970's actually work.

neilv 2y ago
Did it ever, or was that the tty abstraction rather than stdout?
- pjmlp 2y ago
  Of course, C only came to be after six editions of UNIX.
  - nineteen999 2y ago
    Fourth edition UNIX was written in C in 1973: https://gunkies.org/wiki/UNIX_Fourth_Edition https://gunkies.org/wiki/UNIX_Fourth_Edition Unless we have different definitions of "edition".

serbuvlad 2y ago

I hate dynamic linking and this is one of the reasons. APIs should be small, self-contained, not break backwards compatibility (except for security reasons). Libraries provide much more extensive features and, as such, need to change a lot more often. APIs are: Linux system calls, the std{in,out,err} convention, termcap/terminfo, X/Wayland, D-Bus, PulseAudio/PipeWire etc. These change very rarely, and when they do they generally offer compatibility layers (XWayland, pipewire-pulse). But dynamic linking makes every single library an API that can break!

zamadatix 2y ago

That's why I stick to using sh. Wait no, bash... but make sure it's got all of the features from the 5.2 release... unless it's when I'm using zsh in which case we'll need to change some syntax around. For interactive use the program has an ncurses 6 interface, if you want to manage it that way, so make sure you aren't still back on ncurses 5 and have an xterm-256color terminal! Jokes aside, stdout is more like the X11/Wayland comment than anything... and even then it's been what, >30 years with one backwards compatible swap there?

yjftsjthsd-h 2y ago
Where's the joke? I do in fact target somewhat oldish POSIX sh when writing shell scripts; I want to write a script once and not have to worry about where it will run, and sh is basically universal.
- deleted 2y ago
  [deleted]
- zamadatix 2y ago
  The joke was the over the top-ness in the example of how CLI solutions have lacked forward compatibility as often as GUI solutions. The latter parts about how both CLI and GUI have decent examples of long term backwards compatibility were serious.
  - yjftsjthsd-h 2y ago
    I don't think it works that way either, though. AIUI the problem is that QT5 apps don't automatically work on QT6 (otherwise this would be a non-problem; Ubuntu would just ship QT6 alone and everything would work). But none of the shell examples given have that problem; AFAIK virtually every script that worked on BASH 4 works on BASH 5 - as does virtually every script that worked on any other older version of BASH, and every script that targets plain sh. If you wanted to make that argument, the ncurses suggestion by https://news.ycombinator.com/item?id=42020272 https://news.ycombinator.com/item?id=42020272 is probably more compelling than the shell itself, which is amazingly backwards compatible.

NikkiA 2y ago

You'll be hard pressed to find many CLI apps that still run properly on non-VT100 terminals, but back in the 80s and 90s software usually ran fine on a tvi912, wyse30, zenith22 AND vt100s as long as the termtype was set right. So in a sense, it do be like that, somewhat.