there’s a world of options. this is an LTS distro. use Arch or Nix or whatever if you want the latest packages. i actually switched to NixOS because the CUDA drivers were too new on Arch, and i wanted a better way to pin versions.
or i dunno keep publicly complaining about it until someone does the work for you
i guess it would be nice, but packages being a few months out of date is pretty normal for Ubuntu, in my experience. i’m not sure what their testing process is like, but part of using something like Ubuntu is stability guarantees. if they felt like the couldn’t do that for newer versions for whatever reason (resource constraints, lack of downstream interest from stakeholders, etc) they’re not necessarily obligated to.
It would be nice, but the time it takes to do the work of validating package versions for LTS candidacy is either limited or not free, so this is the acceptable compromise.
I'd love to hear what your solution would be? They freeze everything two months out to allow for thorough testing and unless your answer to the problem is switching to a rolling release cycle (which is exactly the opposite of what its supposed to be), then I don't think there's anything to be done
This sort of distro is and always has prioritised stability over having the latest of everything and that's a good thing. I use CachyOS on my desktop but it's the absolute last thing I'd put on a server, let alone a production one.
It was about 4 months out of date at code freeze from my understanding and 6 months out of date on release which is honestly better than I'd expect normally for packages in official repos
Especially with the newer ROCm 7.2.x releases improving hardware support and other improvements. Especially with the rate of improvements to ROCm recently, it's unfortunate to see ROCm 7.1 shipped in the Ubuntu 26.04 archive.
Improvements!
But yeah, 3 months out of date for software that isn't security critical is fine. Probably just hit the feature freeze at a bad time. It still presumably works well enough for most people.
3 months isn't bad though. Especially since it's going to be locked out of changes so in 5 years it will be 5 years and 3 months out of date. The bigger problem with rocm is that they cut off older cards way too soon.
I bought a radeon pro vii brand new from a shop (granted it was a runout sale) and it was already cut off. It still works but not supported.
AMD can't keep complaining everyone focuses on CUDA when they don't even bother to support their own product. It supports very few cards and they get cut off way too soon.
Nvidia supports even midrange consumer cards and they keep supporting them a long time.
Support for older cards is getting more common. Some of them are working but not officially supported but I've seen more cards entering support than leaving
Ehh. 7.1 isnt that old. If they don't make any newer available until 28.04, then this'll just be a major baseline. It'll nice regardless just if it leads to more rocm support. The package and maintainers are in place for this to keep going every 6 months
Being old != bad. Some software is not critical in terms of cyber security. You have to assess the use case. Feels like you're screaming wolf, without knowing the package.
Yeah, would much rather a package designed for my distro than a flatpak.
I recall a time where the native package on my distro wasn’t working at all, I think this was when I was using discord and tried to use Vencord on Debian 12, so I tried the flatpak version and again it did not work. I was between a rock and a hard place, do I troubleshoot what is essentially a containerized/sandboxed application or try to figure out what’s going on my host machine.
I chose the latter and eventually got it working, but now I don’t use discord so waste of my time regardless.
No, Flatpak limitations literally make it impossible to get all Discord features working.
It’s not a problem with the config, it’s a design flaw of Flatpak itself.
This only holds true if you're talking about Debian Stable, there are definitely Sid or Testing based distros for which that doesn't hold true.
See PikaOS for example.
Apt packages used to get more updates in the past. Especially ubuntu repos. Today everything just seems to rely on Debian. Which is always lacking behind.
I don't like it either. Especially for gaming you really want the latest improvements. Or for science workloads. Or other professionals.
This is fine as long as upstream supports a convenient way to get the latest versions of software for which you actually need latest (APT repositories)
Stable base, only explicitly allow selected unstable/bleeding edge components.
This is what I do for ROCm and a few other things which need to be constantly updated (yt-dlp). Sometimes stable-backports repositories are enough, but not always.
The problem is that there's so many different ways of packaging and also that Windows generally does static linking so old binaries work after a decade. Whereas old Linux binaries are generally dynamically linked and are dependent on some other old library which isn't availible for [current kernel] and you get into dependency hell
saying “Linux does dynamic linking and Window does static linking” is both false and a mischaracterization. Windows absolutely does dynamic linking with its Dynamically Linked Libraries (.dll). how dependencies are linked is up to the developer and whatever hardware constraints. one reason i like Rust is that it prefers static linking, and a lot of tool chains are moving in that direction. the reason Linux distros push people toward their internal package management tools (eg apt) is to have tighter control over dynamic linking.
and we’re also glossing over scoop and chocolatey and winget and Docker.
but that’s where you get to stuff like flatpack and snap and Nix that try to contain the dynamic dependencies.
i don’t think downloading exes hoping that Windows has stuffed enough DLLs into the OS and just running them is a better solution.
oh i see. embedded systems makes sense. i wouldn’t even try to go beyond the factory recommendation for systems like that. maybe for fun. likely there are kernel modifications or modules that are required for those systems.
54 Comments
chrash0@lemmy.world · 41 pts · 148d
there’s a world of options. this is an LTS distro. use Arch or Nix or whatever if you want the latest packages. i actually switched to NixOS because the CUDA drivers were too new on Arch, and i wanted a better way to pin versions.
or i dunno keep publicly complaining about it until someone does the work for you
grue@lemmy.world · 14 pts · 148d
I mean, even in an LTS distro, it sure would be nice if the packages were reasonably up-to-date on the day the version was released.
chrash0@lemmy.world · 12 pts · 148d
i guess it would be nice, but packages being a few months out of date is pretty normal for Ubuntu, in my experience. i’m not sure what their testing process is like, but part of using something like Ubuntu is stability guarantees. if they felt like the couldn’t do that for newer versions for whatever reason (resource constraints, lack of downstream interest from stakeholders, etc) they’re not necessarily obligated to.
adarza@lemmy.ca · 11 pts · 148d
2 months. lts or not, ubuntu's freeze date is and has historically been about two months before release.
if the 2 year cycle between lts is too long for someone, they don't have to stay on that ride.
non_burglar@lemmy.world · 5 pts · 147d
It would be nice, but the time it takes to do the work of validating package versions for LTS candidacy is either limited or not free, so this is the acceptable compromise.
caseyweederman@lemmy.ca · 4 pts · 148d
26.04 is brand new
Strit@lemmy.linuxuserspace.show · 5 pts · 147d
But its software freeze was a couple of months ago.
chrash0@lemmy.world · 4 pts · 148d
it’s Ubuntu dawg. you get what you pay for.
cravl@slrpnk.net · 2 pts · 148d
…and you pay more for other distros?
chrash0@lemmy.world · 12 pts · 147d
just a silly turn of phrase meaning: you should know that this is what you signed up for
cravl@slrpnk.net · 2 pts · 142d
Yeah I know, just making a terrible attempt at humor. 😅
melroy@kbin.melroy.org · 1 pts · 148d
I didn't pay? Even if I did you got the same result, 🤣
caseyweederman@lemmy.ca · -3 pts · 148d
It's brand new so they have no excuse for having such an old package version.
NotSteve_@lemmy.ca · 8 pts · 147d
I'd love to hear what your solution would be? They freeze everything two months out to allow for thorough testing and unless your answer to the problem is switching to a rolling release cycle (which is exactly the opposite of what its supposed to be), then I don't think there's anything to be done
This sort of distro is and always has prioritised stability over having the latest of everything and that's a good thing. I use CachyOS on my desktop but it's the absolute last thing I'd put on a server, let alone a production one.
Just use Docker if you need something newer
caseyweederman@lemmy.ca · 0 pts · 147d
I'm very familiar with their freezing schedule. The impression I'd gotten from this thread was that the package was much more out of date.
NotSteve_@lemmy.ca · 6 pts · 147d
It was about 4 months out of date at code freeze from my understanding and 6 months out of date on release which is honestly better than I'd expect normally for packages in official repos
caseyweederman@lemmy.ca · 1 pts · 147d
Yeah Resolute's feature freeze was in February so that package should be two months old
Lemmchen@feddit.org · 17 pts · 148d
So, par for the course for Ubuntu, no?
Wolf314159@startrek.website · 4 pts · 147d
More like by design for an LTS release.
AndrewZabar@lemmy.world · 13 pts · 147d
I don’t think I know what rocm is 🤪
DieserTypMatthias@lemmy.ml · 1 pts · 147d
Part of AMD GPUs that you can run code on.
savvywolf@pawb.social · 12 pts · 148d
Improvements!
But yeah, 3 months out of date for software that isn't security critical is fine. Probably just hit the feature freeze at a bad time. It still presumably works well enough for most people.
Bloefz@lemmy.world · 9 pts · 148d
3 months isn't bad though. Especially since it's going to be locked out of changes so in 5 years it will be 5 years and 3 months out of date. The bigger problem with rocm is that they cut off older cards way too soon.
I bought a radeon pro vii brand new from a shop (granted it was a runout sale) and it was already cut off. It still works but not supported.
AMD can't keep complaining everyone focuses on CUDA when they don't even bother to support their own product. It supports very few cards and they get cut off way too soon.
Nvidia supports even midrange consumer cards and they keep supporting them a long time.
kunaltyagi@programming.dev · 1 pts · 147d
Support for older cards is getting more common. Some of them are working but not officially supported but I've seen more cards entering support than leaving
doodoo_wizard@lemmy.ml · 8 pts · 147d
Rocmuh balls
stupidcasey@lemmy.world · 4 pts · 147d
Why is this surprising? I would be more surprised if it didn't.
Stupendous@lemmy.world · 2 pts · 147d
Ehh. 7.1 isnt that old. If they don't make any newer available until 28.04, then this'll just be a major baseline. It'll nice regardless just if it leads to more rocm support. The package and maintainers are in place for this to keep going every 6 months
middlemanSI@lemmy.world · 2 pts · 148d
Being old != bad. Some software is not critical in terms of cyber security. You have to assess the use case. Feels like you're screaming wolf, without knowing the package.
Lemmchen@feddit.org · 5 pts · 148d
For rocm, old is bad.
Kanda@reddthat.com · 1 pts · 146d
Just build it from source, then
greedytacothief@lemmy.dbzer0.com · 1 pts · 147d
The most success I had at getting rocm working was just using containers.
umbrella@lemmy.ml · 1 pts · 148d
thingsiplay@lemmy.ml · 5 pts · 148d
Or this is why we are moving to a rolling-release model.
IEatDaFeesh@lemmy.world · 1 pts · 148d
Or this is why I'm rolling over.
ohshit604@sh.itjust.works · 5 pts · 148d
Yeah, would much rather a package designed for my distro than a flatpak.
I recall a time where the native package on my distro wasn’t working at all, I think this was when I was using discord and tried to use Vencord on Debian 12, so I tried the flatpak version and again it did not work. I was between a rock and a hard place, do I troubleshoot what is essentially a containerized/sandboxed application or try to figure out what’s going on my host machine.
I chose the latter and eventually got it working, but now I don’t use discord so waste of my time regardless.
umbrella@lemmy.ml · 2 pts · 148d
excel@lemming.megumin.org · 1 pts · 148d
No, Flatpak limitations literally make it impossible to get all Discord features working. It’s not a problem with the config, it’s a design flaw of Flatpak itself.
umbrella@lemmy.ml · 1 pts · 148d
mlfh@lm.mlfh.org · 1 pts · 148d
WormFood@lemmy.world · 1 pts · 147d
Rocm is the singular worst piece of software I've ever used
ratatouille@feddit.org · 1 pts · 148d
Will test it as soon as possible. Does someon know how compartible it is with a qemu VM ? I need some GPU abilities like Vulkan there.
Chaser@lemmy.zip · -1 pts · 148d
Surprise! A Debian based distro uses antique packages! Who would have seen that coming? 🙀 /s
melroy@kbin.melroy.org · 5 pts · 148d
Same with Linux mint. I don't like it. I like Linux mint a lot. I only dislike the old packages.
Lemmchen@feddit.org · 2 pts · 148d
This only holds true if you're talking about Debian Stable, there are definitely Sid or Testing based distros for which that doesn't hold true.
See PikaOS for example.
geneva_convenience@lemmy.ml · -3 pts · 148d
Hot take: Windows handles this stuff so much better.
melroy@kbin.melroy.org · 8 pts · 148d
Apt packages used to get more updates in the past. Especially ubuntu repos. Today everything just seems to rely on Debian. Which is always lacking behind.
I don't like it either. Especially for gaming you really want the latest improvements. Or for science workloads. Or other professionals.
wewbull@feddit.uk · 1 pts · 147d
Ironically, that stability is probably why AMD target Ubuntu. They don't want everything else on the bleeding edge. Just their bit.
vegetaaaaaaa@lemmy.world · 1 pts · 148d
This is fine as long as upstream supports a convenient way to get the latest versions of software for which you actually need latest (APT repositories)
Stable base, only explicitly allow selected unstable/bleeding edge components.
This is what I do for ROCm and a few other things which need to be constantly updated (yt-dlp). Sometimes
stable-backportsrepositories are enough, but not always.melroy@kbin.melroy.org · 1 pts · 147d
yea I also leverage PPAs in some cases for getting the latest binaries, yet relying on
apt.geneva_convenience@lemmy.ml · -1 pts · 148d
The problem is that there's so many different ways of packaging and also that Windows generally does static linking so old binaries work after a decade. Whereas old Linux binaries are generally dynamically linked and are dependent on some other old library which isn't availible for [current kernel] and you get into dependency hell
chrash0@lemmy.world · 5 pts · 147d
so, it’s the same.
saying “Linux does dynamic linking and Window does static linking” is both false and a mischaracterization. Windows absolutely does dynamic linking with its Dynamically Linked Libraries (.dll). how dependencies are linked is up to the developer and whatever hardware constraints. one reason i like Rust is that it prefers static linking, and a lot of tool chains are moving in that direction. the reason Linux distros push people toward their internal package management tools (eg
apt) is to have tighter control over dynamic linking.and we’re also glossing over
scoopandchocolateyandwingetand Docker.but that’s where you get to stuff like flatpack and snap and Nix that try to contain the dynamic dependencies.
i don’t think downloading
exes hoping that Windows has stuffed enough DLLs into the OS and just running them is a better solution.geneva_convenience@lemmy.ml · 1 pts · 147d
That's true but on Windows it's mostly just clicking install on everything on ninite. Linux libraries sometimes can't even install on a newer kernel.
I can usually get old Windows programs to run on newer Windows versions. On Linux I rarely had that sucess.
chrash0@lemmy.world · 1 pts · 147d
i’m curious where you run into this. i’ve never had this issue in 10 years of using Linux, most of which being on Arch with the latest kernel
geneva_convenience@lemmy.ml · 1 pts · 147d
Trying to do something like run ROS on anything but the Ubuntu distro it was made for.
Flashing an embedded board which requires Ubuntu 20.04 and didn't accept me using 22.04
Some more stuff too but I've forgotten
chrash0@lemmy.world · 1 pts · 147d
oh i see. embedded systems makes sense. i wouldn’t even try to go beyond the factory recommendation for systems like that. maybe for fun. likely there are kernel modifications or modules that are required for those systems.