Fedora introduced a whole new distro where you can’t install anything with dnf anymore and people love it. People love using flatpaks instead (yes I know of all the shortcomings, but you can always choose another install method for that broken package). And ubuntu users just hate ubuntu for what they do. The difference may also be that fedora gives a choice to the user and does not directly force it
Well there is immutable, which you probably refer to with Fedoras new distro, and then there is Canonical pushing their shitty snap format, and kinda non-sideloading. Can’t wait for the day when apt only ever allows to install snap packages.
There are reasons why Flatpaks are better, both technical and social.
On the technical side, Snaps add to boot up time, as all of them are mounted on boot, which can make the machine several seconds slower to boot in my experience. I don’t need Thunderbird before I’ve logged into my account, yet Thunderbird is already mounted and partially decompressed the moment I see a login prompt.
On the social side, you can easily host your own Flatpak server. Don’t trust flathub? Set up your own website! Users can add your repo with one command and you’re good. Users even get a prompt on package conflicts so they can pick which repo to use. On Snap, there are no alternative stores. The backend is hardcoded to use Canonical’s infrastructure, the alternative repos need to be installed as Snaps, and Oracle charges a hefty sum to those wanting to maintain a repo.
I wouldn’t be very upset if Canonical migrated to snaps had they implemented their system in a reasonably open design. There are advantages to Snaps over APT packages, for sure, and even though I’d rather see them use Flatpaks instead, a fully integrated Snap environment seems to be working just as well.
Canonical did a lot of things right. Mir was a good idea, for instance. AppArmor is much better than the SELinux tooling that Red Hat ships. They have some excellent dev tools for things like k8s (running on Snap, ironically). Plus, they have one of the best server distros out there.
Mir is not a good example of good distro engineering, because it’s an extreme case of NIH syndrome. Unlike what it is today, the original Mir was an alternative to Wayland.
The story started when Canonical decided that X isn’t good enough and they needed an alternative. They chose Wayland first, exciting the entire Linux desktop community. But then they dropped Wayland in favor of the new in-house Mir project, citing several drawbacks to Wayland. The Wayland community responded with several articles explaining why Canonicals concerns were unwarranted. But in typical Canonical style, they simply neglected all the replies and stuck with Mir.
This irked the entire Linux community who promised to promote Wayland and not support Mir at all. This continued for a while until Canonical realized their mistake late, like always. Then they repurposed Mir as a Wayland compositor.
Now this is a repeating story. You see this with Flatpak vs Snap, Incus vs LXD, etc. The amount of high handedness we see from Canonical is incredible.
FYI my understanding is that Incus is forked from LXD, because nobody trusts Canonical any longer. I don’t think LXD itself is them doing the thing that makes them untrustworthy.
You might be referring to something they have done since then, apologies if I misunderstood. Wouldn’t be surprised if they tried to make it a Snap or force Snaps into it.
LXD was under the Linux containers project earlier. After the Canonical takeover of LXD, the following changes were made:
The repo privileges of the original LXD developers were revoked. Those developers are driving the development of Incus now.
LXD’s license was changed to AGPL+CLA
The first point means that Incus is the true successor of the original LXD. The current LXD is a jealously guarded pet project of Canonical in the same manner as Snap and Mir.
As for the second point, I’m usually a proponent of AGPL. But CLA corrupts it so much that it’s more harmful than with a permissive license. The real intention of this license change is to prevent Incus from incorporating changes from LXD (since the copyleft license of LXD code is incompatible with the permissive license of Incus). Meanwhile LXD continues to incorporate changes from Incus, although the Incus developers haven’t signed any CLA. This move by Canonical is in very bad faith, IMO.
So yes - I consider LXD to be untrustworthy. But that doesn’t cover the old LXD code, its developers or its community. Those transformed fully into the Incus project the same way OpenOffice was forked into LibreOffice. And I don’t trust the LXD name anymore in the same way nobody trusted the OpenOffice name after the fork (before it was donated to the Apache foundation).
Fedora Silverblue is in an entirely different ball game. You can’t use dnf because it’s an immutable image based system where you can’t make direct changes to the Root system without making use of the rpm-ostree & VCS mechanisms. You’re making a conscious choice by using Fedora Silverblue, and the pros out way the cons for most people making that choice.
In contrast Fedora Workstation allows you to use dnf just as normal because it’s not an immutable image based system.
Ubuntu doesn’t make use of any such system so their reliance on containerized user-space apps isn’t a technical one.
It is absolutely a different situation if it is opt-in. If Ubuntu made Snaps opt-in, people might not like them but it’d be a minor critique instead of fleeing the distro.
@babara@lemmy.ml
The difference with Fedora Atomic, which I think you refer to, is that it’s totally open. For example, people started using the OCI containers differently than Fedora intended, which resulted in uBlue and stuff like Bazzite.
Also, no one forces you to use Flatpak. You can still use Distrobox and use Pacman/ APT/ DNF/ whatever you prefer and export your apps that way. It’s just that Flatpak “won” and doesn’t have many drawbacks, and is very convenient. I mostly like them.
And, most importantly, Fedora is the fronteer of innovation.
There were many projects and ideas that failed, but many more succedded (Wayland, image based distros, etc.), and Project Atomic is just one more “testing ground” that is well thought out imo. Therefore people are expecting to “test out” new generation Linux stuff, it’s just part of Fedora. If you don’t like that, use Debian instead.
I can recommend you to give Fedora Atomic a chance, it’s an extremely nice family of distros (e.g. Bluefin/ Aurora, Bazzite, etc.)!
Edit: one more thing is that Fedora is, in contrast to Ubuntu, not controlled by a company. RedHat doesn’t have nearly as much influence as people think, it’s mainly community driven, and therefore choices aren’t (in theory) influenced by $$$
And, most importantly, Fedora is the fronteer of innovation.
What I find impressive about this is that they turn this into a stable product. Early Fedora Core was more of an experimental distribution but those times are long gone (IIRC around Fedora 19).
Fedora Atomic a chance, it’s an extremely nice family of distros (e.g. Bluefin/ Aurora, Bazzite, etc.)!
Can you elaborate on this? I landed on nix for my PC turned server and haven’t regretted it, but I’ve been hesitant to go all in on my main laptop (I’m wary of my laptop iGPU and GPU switching becoming a config issue, and I’m dreading having to configure my wsl dev environments again…)
Windows is getting blatantly terrible enough I know I’m just putting it off, maybe a cool new technology might help make it sound more fun
I don’t know what I should say tbh 😅
For the start, you can read my post about image based distros: https://feddit.de/post/8234416
Imo, Fedora Atomic is NixOS made easy. You can go to the uBlue-builder and modify a custom image if you’re a tinkerer.
NixOS is down-to-top (local config file that defines your host), while uBlue is top-to-bottom (you modify an image, image gets built on GitHub and then shipped to you).
This allows you to fork or create an existing “distro” without having to maintain a whole distro yourself.
Other than that, especially uBlue is extremely user friendly imo.
It updates itself in the background, updates get staged and applied after you’ve shut down your PC in the evening.
You can rebase anytime you want to another flavor, e.g. I switched to KDE 6 from Gnome after it came out.
You have to use containers for everything (mostly Flatpak, but also Distrobox or Nix)
It’s ultra low maintenance and even more reliable, you can boot into an old image if a new update broke anything or made something buggy
For a casual user, not distinguishable from regular Fedora
Ok, when I googled it earlier I saw “containers and roll back to previous version” and I made a note to do more reading
Your write up was good, much clearer than what’s on fedora and Wikipedia. And the fact you pitched immutable OS’s in general first caught my attention… The concept is a no brainer. Decouple the os and the rest of the software, and don’t bother digging into one of a kind conflicts when updating things - just make it rebuildable and create it fresh. You never know when the wrong bit will flip
Nix’s “learn this one thing, configure it once, and you’re done” stuck in my head. And after a different distros, a couple lines installed Nvidia, Nvidia’s docker package and docker
But then I had to configure WiFi and spend half an hour learning why I couldn’t mount an external drive and how to manage it… I still have no regrets, I’ve got a USB that should start converting my friends and family’s old PCs into a self organizing AI/self hosting cluster… Hopefully it works next month lol
But not what I want in a daily driver. I want something that’ll quickly do what I tell it and gracefully handle the fact I have 6 versions of Java and no idea why I need a version from 2018 specifically. And that I’m going to add a repo to install something and instantly forget what I did if it seems like the best path forward at the time
You’ve sold that pretty well - my takeaway was that atomic fedora is very modular and low side effect and also an interchangable foundation I can swap out and roll back easily… At this point, if it can run containers and the drivers I need, it sounds like a great option.
I used to use VMs so every 6-12 months I could start clean with the latest and run setup scripts for my dependencies… It was just easier than debugging some conflict. This sounds even cleaner - I swap out the base at will, and the stuff I’ve built on it should stay intact. Plus it sounds much more testable
So my main concern is will it run on an HP omen - it has zero Linux support and a bunch of concerning driver needs, but it does have a second m2 slot… What’s the worst that can happen? Except apparently some models forget they have fans in Linux and I just know the iGPU-GPU switch will cause some problem with sleeping… But Windows is only going to get worse
Now that you’ve convinced me this might be the best course (I only see less problems than other distros would have), and I’ve talked myself into giving it a go, is there any recommended reading or key concepts I should look into? Any particular flavor(s) you’d point me to first?
Now that you’ve convinced me this might be the best course (I only see less problems than other distros would have)
Sometimes, software, especially install scripts for something, are less common for Silverblue, but executing those is very risky anyway and I never felt the need for it.
And, as I said, some things just work differently. But NixOS is one million times worse than that in that regard, so don’t worry about it. You shouldn’t have many issues.
any recommended reading or key concepts I should look into? Any particular flavor(s) you’d point me to first?
I don’t know. In my opinion, my post should cover most stuff concepts and differences.
Don’t worry about it, you’ll use Flatpak anyway most of the time, and it updates itself automatically, so the package manager (rpm-ostree) doesn’t matter much for you.
You can still use your prefered package manager (apt, dnf, etc.) in Distrobox.
Other than that, just don’t worry and use your laptop for whatever you want to do.
People love using flatpaks instead (yes I know of all the shortcomings, but you can always choose another install method for that broken package).
Not on Ubuntu nor Fedora, but yes: If a “larger” package breaks on update and there is no fix available and I use that application on a pretty much daily basis, then I remove it and install the Flatpak variant.
Flatpaks are slower, do not work super well with Wayland (especially scaling, some applications have GIANT text, some have 5 pixels large text, but fortunately I was able to circumvent those issues for most applications I use via Flatpak), and you need to run another system for updates and updates are friggin slow.
There is also this monstrosity ...
It is not fault-proof and it throws an error if there no older drivers, but this prevents accumulation of outdated Nvidia driver packages (at one point I had nearly 30 different variants installed, resulting of a couple of gigabytes of unused drivers that are “updated” every time I ran flatpak update).
I think they got the nvidia driver accumulation thing straightened out. On Fedora 40, I had it automatically remove a bunch of older versions and now it only lists the 64 and 32 bit versions I expect it to.
$ flatpak list | grep nvidia
nvidia-550-76 org.freedesktop.Platform.GL.nvidia-550-761.4system
nvidia-550-76 org.freedesktop.Platform.GL32.nvidia-550-761.4system
I think you have a typo in your last paragraph.
Flatpak should run better on Wayland compared to Snaps. Not to mention Flatpak has much better XDG Portal Integration.
It’s astonishing.
Fedora introduced a whole new distro where you can’t install anything with dnf anymore and people love it. People love using flatpaks instead (yes I know of all the shortcomings, but you can always choose another install method for that broken package). And ubuntu users just hate ubuntu for what they do. The difference may also be that fedora gives a choice to the user and does not directly force it
Well there is immutable, which you probably refer to with Fedoras new distro, and then there is Canonical pushing their shitty snap format, and kinda non-sideloading. Can’t wait for the day when apt only ever allows to install snap packages.
There are reasons why Flatpaks are better, both technical and social.
On the technical side, Snaps add to boot up time, as all of them are mounted on boot, which can make the machine several seconds slower to boot in my experience. I don’t need Thunderbird before I’ve logged into my account, yet Thunderbird is already mounted and partially decompressed the moment I see a login prompt.
On the social side, you can easily host your own Flatpak server. Don’t trust flathub? Set up your own website! Users can add your repo with one command and you’re good. Users even get a prompt on package conflicts so they can pick which repo to use. On Snap, there are no alternative stores. The backend is hardcoded to use Canonical’s infrastructure, the alternative repos need to be installed as Snaps, and Oracle charges a hefty sum to those wanting to maintain a repo.
I wouldn’t be very upset if Canonical migrated to snaps had they implemented their system in a reasonably open design. There are advantages to Snaps over APT packages, for sure, and even though I’d rather see them use Flatpaks instead, a fully integrated Snap environment seems to be working just as well.
Canonical did a lot of things right. Mir was a good idea, for instance. AppArmor is much better than the SELinux tooling that Red Hat ships. They have some excellent dev tools for things like k8s (running on Snap, ironically). Plus, they have one of the best server distros out there.
Mir is not a good example of good distro engineering, because it’s an extreme case of NIH syndrome. Unlike what it is today, the original Mir was an alternative to Wayland.
The story started when Canonical decided that X isn’t good enough and they needed an alternative. They chose Wayland first, exciting the entire Linux desktop community. But then they dropped Wayland in favor of the new in-house Mir project, citing several drawbacks to Wayland. The Wayland community responded with several articles explaining why Canonicals concerns were unwarranted. But in typical Canonical style, they simply neglected all the replies and stuck with Mir.
This irked the entire Linux community who promised to promote Wayland and not support Mir at all. This continued for a while until Canonical realized their mistake late, like always. Then they repurposed Mir as a Wayland compositor.
Now this is a repeating story. You see this with Flatpak vs Snap, Incus vs LXD, etc. The amount of high handedness we see from Canonical is incredible.
FYI my understanding is that Incus is forked from LXD, because nobody trusts Canonical any longer. I don’t think LXD itself is them doing the thing that makes them untrustworthy.
You might be referring to something they have done since then, apologies if I misunderstood. Wouldn’t be surprised if they tried to make it a Snap or force Snaps into it.
https://linuxiac.com/incus-project-lxd-fork/
LXD was under the Linux containers project earlier. After the Canonical takeover of LXD, the following changes were made:
The first point means that Incus is the true successor of the original LXD. The current LXD is a jealously guarded pet project of Canonical in the same manner as Snap and Mir.
As for the second point, I’m usually a proponent of AGPL. But CLA corrupts it so much that it’s more harmful than with a permissive license. The real intention of this license change is to prevent Incus from incorporating changes from LXD (since the copyleft license of LXD code is incompatible with the permissive license of Incus). Meanwhile LXD continues to incorporate changes from Incus, although the Incus developers haven’t signed any CLA. This move by Canonical is in very bad faith, IMO.
So yes - I consider LXD to be untrustworthy. But that doesn’t cover the old LXD code, its developers or its community. Those transformed fully into the Incus project the same way OpenOffice was forked into LibreOffice. And I don’t trust the LXD name anymore in the same way nobody trusted the OpenOffice name after the fork (before it was donated to the Apache foundation).
Oh, yep, that’s shady and bad behavior. Thank you.
Fedora Silverblue is in an entirely different ball game. You can’t use dnf because it’s an immutable image based system where you can’t make direct changes to the Root system without making use of the rpm-ostree & VCS mechanisms. You’re making a conscious choice by using Fedora Silverblue, and the pros out way the cons for most people making that choice.
In contrast Fedora Workstation allows you to use dnf just as normal because it’s not an immutable image based system.
Ubuntu doesn’t make use of any such system so their reliance on containerized user-space apps isn’t a technical one.
It is absolutely a different situation if it is opt-in. If Ubuntu made Snaps opt-in, people might not like them but it’d be a minor critique instead of fleeing the distro.
@babara@lemmy.ml
The difference with Fedora Atomic, which I think you refer to, is that it’s totally open. For example, people started using the OCI containers differently than Fedora intended, which resulted in uBlue and stuff like Bazzite.
Also, no one forces you to use Flatpak. You can still use Distrobox and use Pacman/ APT/ DNF/ whatever you prefer and export your apps that way. It’s just that Flatpak “won” and doesn’t have many drawbacks, and is very convenient. I mostly like them.
And, most importantly, Fedora is the fronteer of innovation.
There were many projects and ideas that failed, but many more succedded (Wayland, image based distros, etc.), and Project Atomic is just one more “testing ground” that is well thought out imo. Therefore people are expecting to “test out” new generation Linux stuff, it’s just part of Fedora. If you don’t like that, use Debian instead.
I can recommend you to give Fedora Atomic a chance, it’s an extremely nice family of distros (e.g. Bluefin/ Aurora, Bazzite, etc.)!
Edit: one more thing is that Fedora is, in contrast to Ubuntu, not controlled by a company. RedHat doesn’t have nearly as much influence as people think, it’s mainly community driven, and therefore choices aren’t (in theory) influenced by $$$
What I find impressive about this is that they turn this into a stable product. Early Fedora Core was more of an experimental distribution but those times are long gone (IIRC around Fedora 19).
Can you elaborate on this? I landed on nix for my PC turned server and haven’t regretted it, but I’ve been hesitant to go all in on my main laptop (I’m wary of my laptop iGPU and GPU switching becoming a config issue, and I’m dreading having to configure my wsl dev environments again…)
Windows is getting blatantly terrible enough I know I’m just putting it off, maybe a cool new technology might help make it sound more fun
I don’t know what I should say tbh 😅
For the start, you can read my post about image based distros: https://feddit.de/post/8234416
Imo, Fedora Atomic is NixOS made easy. You can go to the uBlue-builder and modify a custom image if you’re a tinkerer.
NixOS is down-to-top (local config file that defines your host), while uBlue is top-to-bottom (you modify an image, image gets built on GitHub and then shipped to you).
This allows you to fork or create an existing “distro” without having to maintain a whole distro yourself.
Other than that, especially uBlue is extremely user friendly imo.
I love nothing else more.
Ok, when I googled it earlier I saw “containers and roll back to previous version” and I made a note to do more reading
Your write up was good, much clearer than what’s on fedora and Wikipedia. And the fact you pitched immutable OS’s in general first caught my attention… The concept is a no brainer. Decouple the os and the rest of the software, and don’t bother digging into one of a kind conflicts when updating things - just make it rebuildable and create it fresh. You never know when the wrong bit will flip
Nix’s “learn this one thing, configure it once, and you’re done” stuck in my head. And after a different distros, a couple lines installed Nvidia, Nvidia’s docker package and docker
But then I had to configure WiFi and spend half an hour learning why I couldn’t mount an external drive and how to manage it… I still have no regrets, I’ve got a USB that should start converting my friends and family’s old PCs into a self organizing AI/self hosting cluster… Hopefully it works next month lol
But not what I want in a daily driver. I want something that’ll quickly do what I tell it and gracefully handle the fact I have 6 versions of Java and no idea why I need a version from 2018 specifically. And that I’m going to add a repo to install something and instantly forget what I did if it seems like the best path forward at the time
You’ve sold that pretty well - my takeaway was that atomic fedora is very modular and low side effect and also an interchangable foundation I can swap out and roll back easily… At this point, if it can run containers and the drivers I need, it sounds like a great option.
I used to use VMs so every 6-12 months I could start clean with the latest and run setup scripts for my dependencies… It was just easier than debugging some conflict. This sounds even cleaner - I swap out the base at will, and the stuff I’ve built on it should stay intact. Plus it sounds much more testable
So my main concern is will it run on an HP omen - it has zero Linux support and a bunch of concerning driver needs, but it does have a second m2 slot… What’s the worst that can happen? Except apparently some models forget they have fans in Linux and I just know the iGPU-GPU switch will cause some problem with sleeping… But Windows is only going to get worse
Now that you’ve convinced me this might be the best course (I only see less problems than other distros would have), and I’ve talked myself into giving it a go, is there any recommended reading or key concepts I should look into? Any particular flavor(s) you’d point me to first?
Sometimes, software, especially install scripts for something, are less common for Silverblue, but executing those is very risky anyway and I never felt the need for it.
And, as I said, some things just work differently. But NixOS is one million times worse than that in that regard, so don’t worry about it. You shouldn’t have many issues.
I don’t know. In my opinion, my post should cover most stuff concepts and differences.
Don’t worry about it, you’ll use Flatpak anyway most of the time, and it updates itself automatically, so the package manager (rpm-ostree) doesn’t matter much for you.
You can still use your prefered package manager (apt, dnf, etc.) in Distrobox.
Other than that, just don’t worry and use your laptop for whatever you want to do.
And about flavor choice, there are a few options:
Just go to the uBlue homepage and see for yourself what appeals to you :)
Not on Ubuntu nor Fedora, but yes: If a “larger” package breaks on update and there is no fix available and I use that application on a pretty much daily basis, then I remove it and install the Flatpak variant.
Flatpaks are slower, do not work super well with Wayland (especially scaling, some applications have GIANT text, some have 5 pixels large text, but fortunately I was able to circumvent those issues for most applications I use via Flatpak), and you need to run another system for updates and updates are friggin slow.
There is also this monstrosity ...
It is not fault-proof and it throws an error if there no older drivers, but this prevents accumulation of outdated Nvidia driver packages (at one point I had nearly 30 different variants installed, resulting of a couple of gigabytes of unused drivers that are “updated” every time I ran
flatpak update).flatpak-update () { LATEST_NVIDIA=$(flatpak list | grep "GL.nvidia" | cut -f2 | cut -d '.' -f5) flatpak update flatpak remove --unused --delete-data flatpak list | grep org.freedesktop.Platform.GL32.nvidia- | cut -f2 | grep -v "$LATEST_NVIDIA" | xargs -o flatpak uninstall flatpak repair flatpak update }On the other hand, the applications provided via Flatpak just work.
And messing with 32 bits multilib dependency hell for Steam or installing pretty much half of Kde just for Kdenlive simply isn’t something I want.
I think they got the nvidia driver accumulation thing straightened out. On Fedora 40, I had it automatically remove a bunch of older versions and now it only lists the 64 and 32 bit versions I expect it to.
$ flatpak list | grep nvidia nvidia-550-76 org.freedesktop.Platform.GL.nvidia-550-76 1.4 system nvidia-550-76 org.freedesktop.Platform.GL32.nvidia-550-76 1.4 systemEdit: looks like it’s fixed by this.
I think you have a typo in your last paragraph.
Flatpak should run better on Wayland compared to Snaps. Not to mention Flatpak has much better XDG Portal Integration.
Should.