Don't bother with the motherboard, the new BIOS is worse. I have two that just randomly shut off whenever they feel like it. I just bought a thinkpad instead, shrug.
Imho its not necessary for the average user, adding too much complexity.
For example, I tried to config gpsd to use another port, nothing would work; systemd quietly overrides gpsd's configfile and required additional systemd incantations to change what should have been easy. And the man pages are a mess
And journalctl makes me want to pull my hair out; just let me grep a regular file - discovering namespaces is a nightmare
Personally I think moving away from the hodgepodge of scripts, giving a consistent interface for people to use, extend, etc, is kinda necessary for the average user to have a decent system. It can often be complex to make things simple.
I'm also not sure how systemd could override a config file, because systemd does not write the unit files on a system. Wouldn't that be on the maintainer, distro, or other methods of getting the unit file?
It sets up the network for services, but it's been a minute since so I don't remember the specifics, just that I needed to make a new file in some deep folder to tell it to use a non-standard port.
To me its just more complexity, and not super consistent, which is fine for enterprise, or automation. I'm used to openbsd, regular shell init scripts go in /etc/rc.d, and my logs are in /var/log. Can't get much simpler than that, but i understand its limitations, and Linux is certainly more of a hodgepodge
Edit: found my notes, first was discovering the "gpsd" & "gpsd.socket" namespaces existence, then needing to do "systemd edit --full gpsd.socket" because without "--full" it makes an override file that didn't actually override anything...my note quality declined rapidly after that due to anger
It’s at odds with the philosophy of do one thing and do it well. Its monolithic feature set pushes out smaller contributors and leads to increased reliance on a singular package. This tends to self reinforce. I also use systemd in my current distro so not sure where I stand on this but it’s a fair concern.
Before systemd I had Redhat machines with 3 to 4 years of uptime, and now you need to restart Linux after updates....while Windows people rarely and they laugh at you...
If you use the command line to do the update there is no need to reboot, however, the issues that the offline update is trying to solve still stands.
Some programs can crash when all their files are suddenly swapped for new ones. I've seen multiple linux systems bork themselves during an update because the update itself caused the desktop session to crash, which caused the update process to be interrupted just as it was modifying some crucial files, thus rendering the system unbootable.
>> If you use the command line to do the update there is no need to reboot
Completely untrue.
And before systemd, updating sshd or cron usually meant restarting that one daemon. With systemd, core updates can affect PID 1, logind, journald, udev, user managers, socket activation and cgroup state as one dependency graph.
Before, its was replace a library and restart the few daemons using it. Now the same library may be loaded by system services, user services and systemd components, making a clean partial restart harder to verify.
I'm sorry this is happening to you. I'm on the team that helped bring podman into the CNCF and I worked on ubuntu for over a decade, this isn't a technical problem this is a business one.
Podman is in universe, so Canonical doesn't care unless you pay. Fair enough, good engineers cost money. RH isn't going to pay.
Podman engineers would love to be in Ubuntu, the Red Hat engineers would love to directly upload into Universe. Everything in this thread makes sense, it's a matter of who wants to pay for it. End users have been asking for this for years.
The engineers don't make the decisions. Canonical doesn't want to pay, Red Hat doesn't want to pay. Users stuck in the middle.
I get podman from brew even on Linux because the idea that vendors fighting over uploading tarballs to a server is stupid. Fuck distros.
I'm confused, the latest LTS version of Ubuntu is 26.04 (released on 2026/04/23) and has Podman v5.7.0 (released on 2025/11/11). [1]
If they're on a 24.04 LTS release is there any reason they would be on a newer version of Podman (without jumping through hoops)? Ubuntu 24.04LTS released on 2024/04/25 and the Debian Import Freeze was on 2024/02/29.
The bleeding edge Podman release at that time was a pre-release v5.0.0-RC3 (2024/02/22) and the latest actual release was v4.9.3 (2024/02/13). That's the version Ubuntu 24.04LTS has. [2][3][4]
So aren't they on the exact version of Podman they're supposed to be on for the operating system version they're running?
Ubuntu loves to mess with upstream by shipping a bunch of vendor patches. It's one of the main reasons I run Fedora, they do this the least in my experience
I don't claim to understand the business or politics between RedHat and Ubuntu.
I do know many projects with way less resources seem to be able to support Ubuntu and other popular distros just fine. Often through PPAs or their own apt repos (like Docker, PostgreSQL, or Incus).
If RedHat doesn't choose to, so be it. But IMO, they can't really compete with Docker when getting a recent release on the most popular distros is such a major cluster F.
If I manage an open source program like this, my job is to write the code and docs, publish it somewhere and maybe make some changes to make it more portable. That's it!
It's the distro's job to package and integrate this software with the rest of the system, to make it easier for their users.
I have 1677 packages installed. I absolutely _do not_ want to go to 1677 places to install or look for the latest version.
24.04 is a stable release. Package updates in stable releases need to follow the Stable Release Update process https://ubuntu.com/project/docs/SRU/stable-release-updates/
In essence someone needs to do contribute time and effort to make it happen. Canonical is free to choose the packages they want to maintain themselves and which ones go to universe and are community maintained. The upstream, if they care enough, can choose to get involved and try to do the updates. The process isn't exactly easy or fun. There's a bunch of requirements regarding backward compatibility and testing that need to be met. Snapd upstream goes though it for almost every release and it takes anything from a couple of weeks to a month. I don't think anything is stopping either party from updating the packages, although I don't why upstream wouldn't be interested in getting involved making this happen.
This memory bandwidth combo is amazing for homelabbers. kyuz0's work on these containers has made the investment in this kit so valuable I hope Framework is sending you hardware!
https://projectbluefin.io/server/ is what I'm hoping to ship, designed to just ship setups like this ootb and things like this would be so much harder without kyuz0!
(Note: The 64GB ones are going for $1700-ish empty, the prices on the 128's are outrageous we can just keep making the labs more deterministic over time!)
Yep, nice write up, seems we are all doing this. Its as close as you can get to Provider level for essentially prosumer hardware. I'll share what I've got with this running under k0s and the npu work.
Lots of orgs have been documenting their moves to KubeVirt over the past year or so. There's KubeCon video recordings on the youtube channel from Amsterdam with lots of this kind of stuff, especially from european end users.
One thing I find consistent is orgs are also looking at the whole stack, this is just another major component of digital sovereignty.
Disclaimer: work for CNCF on this but worked on the first version of VMWare Tanzu so every announcement in this space is interesting lol.
Both approaches are indeed competitive, but you can also leverage both to achieve the same thing. We're experimenting with a pure ddi Bluefin, a buildstream/GNOMEOS one that spits out a bootc image, as well as a Bluefin that is just a systemd-sysext on top of GNOME OS. Chef's choice!
There will be many ways to slice this problem -- my opinion is that in the end it will be how you design the infrastructure to make these and not the artifacts themselves.
We already have CentOS/Fedora builds alongside these, long term we'll see which ones end up being the most efficient. Buildstream is a tool which people should look at in this space too: https://buildstream.build/index.html
