I don’t think I know what rocm is 🤪
this post was submitted on 25 Apr 2026
89 points (94.1% liked)
Linux
65007 readers
873 users here now
From Wikipedia, the free encyclopedia
Linux is a family of open source Unix-like operating systems based on the Linux kernel, an operating system kernel first released on September 17, 1991 by Linus Torvalds. Linux is typically packaged in a Linux distribution (or distro for short).
Distributions include the Linux kernel and supporting system software and libraries, many of which are provided by the GNU Project. Many Linux distributions use the word "Linux" in their name, but the Free Software Foundation uses the name GNU/Linux to emphasize the importance of GNU software, causing some controversy.
Rules
- Posts must be relevant to operating systems running the Linux kernel. GNU/Linux or otherwise.
- No misinformation
- No NSFW content
- No hate speech, bigotry, etc
Related Communities
Community icon by Alpár-Etele Méder, licensed under CC BY 3.0
founded 7 years ago
MODERATORS
Part of AMD GPUs that you can run code on.
Rocmuh balls
Why is this surprising? I would be more surprised if it didn't.
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
Just build it from source, then
Rocm is the singular worst piece of software I've ever used
The most success I had at getting rocm working was just using containers.
Hot take: Windows handles this stuff so much better.
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.
Ironically, that stability is probably why AMD target Ubuntu. They don't want everything else on the bleeding edge. Just their bit.
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.
yea I also leverage PPAs in some cases for getting the latest binaries, yet relying on apt.
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
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 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.
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.
Linux libraries sometimes can't even install on a newer kernel.
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
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
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.
Idk it's not just on embedded systems. For example you can't run ros 22.04 on Ubuntu24.04 ** https://docs.ros.org/en/humble/Installation/Ubuntu-Install-Debs.html
Windows doesn't have these issues. Not that I use Windows for development stuff, but you can usually install any .exe for Windows10 on Windows 11. Even older stuff frequently still works and only sometimes requires running in compatibility mode.
ROS is an embedded systems OS, right?
It runs on embedded systems but also on "normal" computers. It's not an OS but moreso a server/database which communicates messages between different programs.
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 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.
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 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.
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.
26.04 is brand new
But its software freeze was a couple of months ago.
load more comments
(10 replies)
But It's Months Out-Of-Date
So, par for the course for Ubuntu, no?
More like by design for an LTS release.
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
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.
For rocm, old is bad.
view more: next ›