9 ms·

Ubuntu Hoping to Remove Qt 5 Before Ubuntu 26.04 LTS

jftuga 2y ago
From the article: "Ubuntu developer Simon Quigley laid out the plans for hoping Ubuntu packages will move from Qt 5 to Qt 6 so that by the time of the Ubuntu 26.04 LTS cycle in early 2026 that the older version of this graphical toolkit can be removed."
- seb1204 2y ago
  Plans for hoping... That is no plan at all, it is wait and see.
  - kevincox 2y ago
    Wait and see is a plan! Not one that is likely to result in an Ubuntu without Qt 5. But a plan all the same.
  - cozzyd 2y ago
    I think the term of art is currently concepts of a plan.
01HNNWZ0MV43FF 2y ago
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.
robomartin 2y ago
I have always avoided Qt for any projects because of the incomprehensible licensing model that could very easily create a legal minefield for your product. No. Thanks.
- jcelerier 2y ago
  It's just LGPL if you make any standard desktop app. Like you can make pretty much the entirety of KDE with the LGPL parts of Qt.
foresto 2y ago
I think this is reasonable. Plasma 6 recently appeared in Debian Experimental, Qt 6 is already in the Stable branch, and a new Debian release seems likely in the coming year. I expect the folks managing Ubuntu just want to make sure their non-Debian stuff is ready for the upstream change.
mmsc 2y ago
Forcing modernisation of some - (probably) especially gui - applications is overall a positive for the platform as it also identifies projects which are under-maintained and allow for overall modernisation / forking / maintenance that is needed. I wouldn't expect to (easily) run php5 code on Ubuntu 26.04, either. Applications that refuse to modernise can build qt5 themselves.
- yjftsjthsd-h 2y ago
  > and allow for overall modernisation / forking / maintenance that is needed. Or, it allows for pointless churn, extra work, and breakage of apps that were still functional until someone yanked their dependencies. This kind of thing is why software rot is even a thing and people remarking that Win32 Is The Only Stable ABI on Linux ( https://blog.hiler.eu/win32-the-only-stable-abi/ https://blog.hiler.eu/win32-the-only-stable-abi/ ).
  - mmsc 2y ago
    Ubuntu does not claim they have a stable ABI between major version releases.
    - yjftsjthsd-h 2y ago
      Sure? Acknowledging a shortcoming of an OS doesn't remove it.
- eviks 2y ago
  Since you can identify the projects without mandatory deprecation, what does deprecation give you? Also resources don't magically appear just because a resource constraint had been identified since that fact is also a given and obvious to everyone involved
- greatgib 2y ago
  Alternatively, it is the best for the Linux desktop year to never come by always having major application totally reworked with the last shiny stuff instead of just polishing it with all the small bugs and features improved in the app.
kev009 2y ago
I think it makes sense to try and cycle the majority of the dependency network to the new versions but I also think it probably makes sense to let the old toolkits live on indefinitely (maybe strategically drop the webkit stuff everything else should be low maintenance) for a variety of reasons, particularly old commercial software. It is comical in some sense that a Motif app of yore would've been a great "investment" in terms of still functioning now and for the foreseeable future.. sort of like Win32/MFC.
- mrweasel 2y ago
  > Motif app of yore would've been a great "investment" ... sort of like Win32/MFC. I've slowly started getting back to desktop Linux, and honestly Motif (mwm) is fine for my needs. Maybe fvwm would be slightly better. If I where to do my career over, I'd consider going for C++ and Win32, it seems like a stable performant platform (I get that there's other problems on modern Windows).
  - exe34 2y ago
    wine is the stable abi on Linux.
    - throwaway2046 2y ago
      For those who don't know the reference: https://blog.hiler.eu/win32-the-only-stable-abi/ https://blog.hiler.eu/win32-the-only-stable-abi/
      - exe34 2y ago
        oh I'm pretty sure I've seen that a long time before. funnily enough there was a time if you had both an os x partition for Mac os and an ext2/3 partition for Linux, the only way to share files freely between the two was through a fat32 partition.
        moomoo3000 2y ago
YawHawHawn 2y ago
[dead]
happosai 2y ago
Canonical, the company behind Ubuntu, could easily port the remaining Qt5 apps to Qt6 by the deadline. But they rather wait for the community to do it for them.
- NGRhodes 2y ago
  I suspect that means waiting for Debian to do it.
- eptcyka 2y ago
  Porting them out of tree would be worse than doing nothing.
- rlpb 2y ago
  I think you overestimate Canonical's size. What is happening though is really long support for older releases being provided by Canonical so you will be able to use older Qt 5 based apps on Ubuntu, security supported, until 2034, on Canonical's dime. With container technology (something that Canonical significantly funded, with Docker originally being based on Canonical-funded LXC) you'll be able to run those older apps on a newer base OS including future ones, too. Those are huge contributions to the user community you seem to be discounting. Disclosure: I work for Canonical. I don't speak for Canonical. But what I say above are simple verifiable and falsifiable facts and not really a matter of opinion.
  - mixmastamyk 2y ago
    Seems like the root misstep is when extending server support to 10 years they extended GUI app support as well. The two probably shouldn't be linked and GUI support should end with the desktop edition at five years.
- pkaye 2y ago
  What about the other distros? Are they waiting on the community to do it for them?
larrik 2y ago
On the one hand, yes. On the other, why does Ubuntu always do their craziest changes in the LTS? The LTS should boring, and the one after it should be the wild one. (That may not be what the plan is here, but it does sound like it)
- mort96 2y ago
  I'm guessing it's because everything that ships in the LTS must be maintained for 12 years. I understand Canonical's desire to not still be maintainig Qt 5 in 2038. Tho the ideal time to make this change would be in 25.10.
  - chris_wot 2y ago
    Perhaps they need to reconsider how an LTS works?
    - baq 2y ago
      In enterprise settings 12 years is not quite enough. There are racks of boxen set up with custom software targeting a particular distro version and there is no money or value in making changes to make it compatible with something newer. Hardware gets upgraded on 5-7 year cycles, but the software… isn’t happening.
      - throw16180339 2y ago
        As the saying goes, "Old hardware goes to the scrap heap, old software goes into production tonight."
      - hulitu 2y ago
        > Hardware gets upgraded on 5-7 year cycles, but the software… isn’t happening. Software gets rewritten every 1-3 years throwing away all the past experience. (Qt, GTK, and so on and so forth). /s
    - mort96 2y ago
      The value of LTS, and the reason companies spend tonnes of money on support contracts for those 12 years, is exactly this though: the set of libraries shipped in 26.04 will still be supported 12 years later without major backward incompatible changes. The very reason people would pay to keep using 26.04 in the mid 2030s and beyond would be that the software they built or bought in 2026 keeps working, typically without even having to recompile. You may argue that those customers should just update their software to use new versions of libraries or frameworks or replace discontinued libraries with new ones, or pester their vendor to do those things, or pay a bunch of money to consultancy companies to do those things; and you may well be right, but as long as those companies won't do that and are willing to instead pay Canonical, why wouldn't Canonical accept the money?
butz 2y ago
I am hoping KeepassXC will move to Qt6 soon.
- self_awareness 2y ago
  > I am hoping KeepassXC will move to Qt6 soon. Let's also hope this will happen before Qt7 will come out.
dgfitz 2y ago
Kind of sounds like Canonical and Qt are in cahoots, in a similar way that Qt and openembedded are. I sure don’t like Canonical.
- mort96 2y ago
  I sure as hell would prefer to not have to maintain Qt 5 for 13 more years if I could avoid it. I don't think this has anything to do with "being in cahoots with the Qt company", I think it has everything to do with "backporting fixes from a recent Qt 6 version to an older Qt 6 version is easier than backporting fixes from Qt 6 to Qt 5".
  - dgfitz 2y ago
    I’m all for qt6. I doubt I need to explain to you the licensing change.
m463 2y ago
clickbaity title. Makes it sound like Qt being removed. Better might be: Ubuntu Hoping to Remove Qt 5 in favor of Qt 6 Before Ubuntu 26.04 LTS or maybe: Ubuntu will try moving from Qt 5 to Qt 6 by Ubuntu 26.04 LTS

From the article: "Ubuntu developer Simon Quigley laid out the plans for hoping Ubuntu packages will move from Qt 5 to Qt 6 so that by the time of the Ubuntu 26.04 LTS cycle in early 2026 that the older version of this graphical toolkit can be removed."

seb1204 2y ago
Plans for hoping... That is no plan at all, it is wait and see.
- kevincox 2y ago
  Wait and see is a plan! Not one that is likely to result in an Ubuntu without Qt 5. But a plan all the same.
- cozzyd 2y ago
  I think the term of art is currently concepts of a plan.

01HNNWZ0MV43FF 2y ago

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.

robomartin 2y ago

I have always avoided Qt for any projects because of the incomprehensible licensing model that could very easily create a legal minefield for your product. No. Thanks.

jcelerier 2y ago
It's just LGPL if you make any standard desktop app. Like you can make pretty much the entirety of KDE with the LGPL parts of Qt.

foresto 2y ago

I think this is reasonable. Plasma 6 recently appeared in Debian Experimental, Qt 6 is already in the Stable branch, and a new Debian release seems likely in the coming year. I expect the folks managing Ubuntu just want to make sure their non-Debian stuff is ready for the upstream change.

mmsc 2y ago

Forcing modernisation of some - (probably) especially gui - applications is overall a positive for the platform as it also identifies projects which are under-maintained and allow for overall modernisation / forking / maintenance that is needed. I wouldn't expect to (easily) run php5 code on Ubuntu 26.04, either. Applications that refuse to modernise can build qt5 themselves.

yjftsjthsd-h 2y ago
> and allow for overall modernisation / forking / maintenance that is needed. Or, it allows for pointless churn, extra work, and breakage of apps that were still functional until someone yanked their dependencies. This kind of thing is why software rot is even a thing and people remarking that Win32 Is The Only Stable ABI on Linux ( https://blog.hiler.eu/win32-the-only-stable-abi/ https://blog.hiler.eu/win32-the-only-stable-abi/ ).
- mmsc 2y ago
  Ubuntu does not claim they have a stable ABI between major version releases.
  - yjftsjthsd-h 2y ago
    Sure? Acknowledging a shortcoming of an OS doesn't remove it.
eviks 2y ago
Since you can identify the projects without mandatory deprecation, what does deprecation give you? Also resources don't magically appear just because a resource constraint had been identified since that fact is also a given and obvious to everyone involved
greatgib 2y ago
Alternatively, it is the best for the Linux desktop year to never come by always having major application totally reworked with the last shiny stuff instead of just polishing it with all the small bugs and features improved in the app.

kev009 2y ago

I think it makes sense to try and cycle the majority of the dependency network to the new versions but I also think it probably makes sense to let the old toolkits live on indefinitely (maybe strategically drop the webkit stuff everything else should be low maintenance) for a variety of reasons, particularly old commercial software. It is comical in some sense that a Motif app of yore would've been a great "investment" in terms of still functioning now and for the foreseeable future.. sort of like Win32/MFC.

mrweasel 2y ago
> Motif app of yore would've been a great "investment" ... sort of like Win32/MFC. I've slowly started getting back to desktop Linux, and honestly Motif (mwm) is fine for my needs. Maybe fvwm would be slightly better. If I where to do my career over, I'd consider going for C++ and Win32, it seems like a stable performant platform (I get that there's other problems on modern Windows).
- exe34 2y ago
  wine is the stable abi on Linux.
  - throwaway2046 2y ago
    For those who don't know the reference: https://blog.hiler.eu/win32-the-only-stable-abi/ https://blog.hiler.eu/win32-the-only-stable-abi/
    - exe34 2y ago
      oh I'm pretty sure I've seen that a long time before. funnily enough there was a time if you had both an os x partition for Mac os and an ext2/3 partition for Linux, the only way to share files freely between the two was through a fat32 partition.
      - moomoo3000 2y ago

YawHawHawn 2y ago

[dead]

happosai 2y ago

Canonical, the company behind Ubuntu, could easily port the remaining Qt5 apps to Qt6 by the deadline. But they rather wait for the community to do it for them.

NGRhodes 2y ago
I suspect that means waiting for Debian to do it.
eptcyka 2y ago
Porting them out of tree would be worse than doing nothing.
rlpb 2y ago
I think you overestimate Canonical's size. What is happening though is really long support for older releases being provided by Canonical so you will be able to use older Qt 5 based apps on Ubuntu, security supported, until 2034, on Canonical's dime. With container technology (something that Canonical significantly funded, with Docker originally being based on Canonical-funded LXC) you'll be able to run those older apps on a newer base OS including future ones, too. Those are huge contributions to the user community you seem to be discounting. Disclosure: I work for Canonical. I don't speak for Canonical. But what I say above are simple verifiable and falsifiable facts and not really a matter of opinion.
- mixmastamyk 2y ago
  Seems like the root misstep is when extending server support to 10 years they extended GUI app support as well. The two probably shouldn't be linked and GUI support should end with the desktop edition at five years.
pkaye 2y ago
What about the other distros? Are they waiting on the community to do it for them?

larrik 2y ago

On the one hand, yes. On the other, why does Ubuntu always do their craziest changes in the LTS? The LTS should boring, and the one after it should be the wild one. (That may not be what the plan is here, but it does sound like it)

mort96 2y ago
I'm guessing it's because everything that ships in the LTS must be maintained for 12 years. I understand Canonical's desire to not still be maintainig Qt 5 in 2038. Tho the ideal time to make this change would be in 25.10.
- chris_wot 2y ago
  Perhaps they need to reconsider how an LTS works?
  - baq 2y ago
    In enterprise settings 12 years is not quite enough. There are racks of boxen set up with custom software targeting a particular distro version and there is no money or value in making changes to make it compatible with something newer. Hardware gets upgraded on 5-7 year cycles, but the software… isn’t happening.
    - throw16180339 2y ago
      As the saying goes, "Old hardware goes to the scrap heap, old software goes into production tonight."
    - hulitu 2y ago
      > Hardware gets upgraded on 5-7 year cycles, but the software… isn’t happening. Software gets rewritten every 1-3 years throwing away all the past experience. (Qt, GTK, and so on and so forth). /s
  - mort96 2y ago
    The value of LTS, and the reason companies spend tonnes of money on support contracts for those 12 years, is exactly this though: the set of libraries shipped in 26.04 will still be supported 12 years later without major backward incompatible changes. The very reason people would pay to keep using 26.04 in the mid 2030s and beyond would be that the software they built or bought in 2026 keeps working, typically without even having to recompile. You may argue that those customers should just update their software to use new versions of libraries or frameworks or replace discontinued libraries with new ones, or pester their vendor to do those things, or pay a bunch of money to consultancy companies to do those things; and you may well be right, but as long as those companies won't do that and are willing to instead pay Canonical, why wouldn't Canonical accept the money?

butz 2y ago

I am hoping KeepassXC will move to Qt6 soon.

self_awareness 2y ago
> I am hoping KeepassXC will move to Qt6 soon. Let's also hope this will happen before Qt7 will come out.

dgfitz 2y ago

Kind of sounds like Canonical and Qt are in cahoots, in a similar way that Qt and openembedded are. I sure don’t like Canonical.

mort96 2y ago
I sure as hell would prefer to not have to maintain Qt 5 for 13 more years if I could avoid it. I don't think this has anything to do with "being in cahoots with the Qt company", I think it has everything to do with "backporting fixes from a recent Qt 6 version to an older Qt 6 version is easier than backporting fixes from Qt 6 to Qt 5".
- dgfitz 2y ago
  I’m all for qt6. I doubt I need to explain to you the licensing change.

m463 2y ago

clickbaity title. Makes it sound like Qt being removed. Better might be: Ubuntu Hoping to Remove Qt 5 in favor of Qt 6 Before Ubuntu 26.04 LTS or maybe: Ubuntu will try moving from Qt 5 to Qt 6 by Ubuntu 26.04 LTS