11 ms·

Learning about Bootc

63 points by nikodunk 2y ago

account-5 2y ago
After reading the article I don't get why I need to know about bootc. It's something to do with immutability like a couple of OSs I've never used, of which I've only heard of 1.
- sevg 2y ago
  Yeah it’s not a great article. It didn’t even mention existing immutable technology at all (like rpm-ostree) let alone a technical comparison.
  - anonfordays 2y ago
    Nor did it mention immutable operating systems like Flatcar Linux, upon which you can deploy immutable containers...
- INTPenis 2y ago
  The main takeaway is that you can build your OS image like any OCI image, and you can boot these OCI images. I've been using immutable OS for over 2 years now and the main advantage to me is the ease of rollback. I even started using it professionally in my work with the main selling point being easier lifecycle management. Bootc is just an advancement of this, it's a next generation rpm-ostree. I could already boot my own OCI images before.
  - Joker_vD 2y ago
    But, like, I can already boot from a read-only ISO-image, you know.
    - INTPenis 2y ago
      If you prefer building ISO images over OCI images be my guest. Nobody is forcing you to use this new technology.
      - Joker_vD 2y ago
        Okay, now I am concerned because almost every time somebody tells me "nobody is forcing you to use this new technology", in 5 or so years (if this technology survives) I am starting to get forced to use this new technology because it's "mature enough, and is basically the new industry standard, what you are currently using is going to be deprecated in a couple of years". Apparently, it's because if someone wants to make their new way the only way, they have to tell people "of course we're not forcing anyone to do it this way" for the first several years, while keeping working on rooting the existing ways out. Anyway, I digress; what I actually would like to know is the benefits/downsides compared to e.g. immutable boot partitions, or whatever. After all, I don't generally build my own OS images, neither in .iso or in OCI-image format, I take and use off-the-shelf ones; but it generally involves dd-ing them onto the /dev/sdX at the very least. Using prepared .vdi's is another option.
        INTPenis 2y ago
        I generally don't build my own OS images either, because it's such a hassle and adds such overhead to lifecycle management. But I believe that building OCI images makes the overhead much less. Mainly because the OS I want to use already have a base image I can use, so my build is only a few lines of customization. Your first paragraph is kinda funny to me because 10 years ago I felt like an outsider supporting systemd, and now it's everywhere.
- vaylian 2y ago
  I think the article should also point to the /usr merge https://www.freedesktop.org/wiki/Software/systemd/TheCaseForTheUsrMerge/ https://www.freedesktop.org/wiki/Software/systemd/TheCaseFor... because it makes it feasible to have atomic distributions. Most Linux distributions today have moved all the distribution-specific system files under the /usr hierarchy. Which means that a Linux distribution consists mostly of the /usr and /boot directories. In addition, you have files in /var and /etc that can be modified by the local system administrator and you have /home (which is actually /var/home internally) where regular users can save local files. The local admin can still influence the system by editing files in /etc but she cannot mess with the files in /usr. The key benefit is that distributors can roll out very well-defined Linux distributions that still allow for local modifications in non-critical areas.
MiiMe19 2y ago
>They can turn it on and know it will boot properly without having to worry about things users had to worry about in the past like drivers, kernel mods, or new packages breaking things – the ghosts of Linux Desktop Past. I mean, you still need to setup your bootc image to contain those drivers and everything like that. Once you set up Debian, it will always just boot right too. This just seems like Yet Another Immutable Distro™. I guess stuff like this is a bit nicer for things like like game consoles, where you aren't actually using it like a computer and installing "normal" software, but I don't really see the how this will change the Linux desktop.
yjftsjthsd-h 2y ago
I want to know about - or rather, use - bootc. Unfortunately, the problem is this: FROM quay.io/fedora/fedora-bootc:41 If you're using Fedora (or maybe RHEL) and happy to use premade base images then it's apparently great. The moment you step off that happy path, good luck; nobody has written the code, and the docs are inadequate to do it yourself. Or at least, they were for me; I wanted to make an Alpine bootc image but everything was shades of "now start from this Fedora image, install this magic package with the systemd integration, invoke the rpm wrapper, and it all works!" which was kinda a problem trying to integrate with a system that had none of those things. It was annoying because I'm pretty sure the tech is actually distro agnostic, but it was too underdocumented to use.
- worthless-trash 2y ago
  I guess the community can step up and build their own bootc images.
  - yjftsjthsd-h 2y ago
    Am I not a member of the community? I am trying to build bootc images, but I can't work with nothing. Just now, I thought I'd go check and see if it'd improved, and guess what? It's actually worse than I remembered. There's a list of distros using it at https://github.com/bootc-dev/bootc/blob/main/ADOPTERS.md https://github.com/bootc-dev/bootc/blob/main/ADOPTERS.md - but actually the non-Fedora distros they list are RHEL and HeliumOS, which is a CentOS Stream derivative. (There's a list of ostree users, but that's not the same and they even admit that this is more of a 'hey these use related tech and someday maybe they can use this'). So I went looking through docs, and found https://bootc-dev.github.io/bootc/installation.html https://bootc-dev.github.io/bootc/installation.html which again says that this really only supports Fedora/CentOS/RHEL, but does link to the issue tracking work for others to use it. That's https://github.com/coreos/bootupd/issues/468 https://github.com/coreos/bootupd/issues/468 , which is 2 years old and... basically is, again, a bunch of different folks saying they'd like to make it work on different distros and getting nowhere. There is one person who posted on https://github.com/bootc-dev/bootc/issues/865 https://github.com/bootc-dev/bootc/issues/865 and who claims to have converted an ostree Arch system to using bootc, but they didn't post steps to reproduce. Actually clicking around I eventually found their repo https://github.com/frap129/arch-bootc/tree/main https://github.com/frap129/arch-bootc/tree/main which again doesn't say how to do it, but does appear to contain their code, so maybe I can reverse-engineer from there... Anyways. The community would very much like to step up, but we can only step up over so high of a learning curve, or possibly so high of a porting curve (a lot of comments indicate being tied to rpm integration).
dailykoder 2y ago
Sounds interesting, but since I haven't been in touch much with this topic I ask myself: Does this have any benefit for my personal home-computer usage? For a long time I have the urge to try out Nix, because I clutter up my computer way too fast and therefore often get mad and just install a fresh system. This works fine with my files, but there are always applications which I forget about and forget to save configs. So having this all in a git repo to spin it up fast would be nice. Is bootc, fedora silverblue and so forth trying to achieve something similar?
- averms 2y ago
  I think bootc is exactly what you're looking for. I use it[1] for configuration like you mentioned but also for: - Installing codecs from third-party repositories. This is especially nice to do in CI because you get a build failure if packaging drift happens. - Installing out-of-tree drivers. Again, you get a build failure in CI if an out-of-tree kernel module won't build. In addition, you can use multi-stage builds (see the Dockerfile in my repo for an example) to avoid pulling dependencies into your final system image. This saves me from having the 70 or so RPM packages that are required for building NVIDIA drivers installed on my PC. It's not as ambitious as NixOS but I think it gives a lot of the same benefits with far less effort. [1]: https://github.com/averms/verms-os https://github.com/averms/verms-os
  - dailykoder 2y ago
    Thank you! Then I'll look a bit more into it.
stakhanov 2y ago
I'll offer a less charitable framing of the whole topic of immutable / atomic distros: This is pretty much Linux distributors deciding they want to stop doing their job (or redefine what their job is to a much smaller scope). -- I'm not saying it's not justifiable that the ecosystem may need to be reshaped in that way. I'm just cautioning people from drinking the “this is the future and the future looks bright” Kool-Aid all too easily. The job of making a Linux distribution has always been what, in an old-fashioned term, used to be called “system integration” work. They would start with a bewilderingly huge array of open-source packages, each being developed without any centralized standard or centralized control over what the system actually looks like. Then they would curate a collection of build recipes and patches for those packages. The value a distro delivers for the user is that, for any package “foo” that their heart desires, a user can just say “apt install foo” and it'll “just work”. There will be default configuration and patches to make foo integrate perfectly with the rest of the system. The value a distro delivers for package maintainers is: “Don't worry about the packaging. Just put your code out as open source, and we'll take care of the rest.” The job of a distributor is extremely difficult, because of all the moving parts: People select their hardware, their packages, and they mess with the default configurations. It is no wonder at all that Linux distributions don't always succeed in their mission to truly deliver on this. But it's a huge engineering achievement that they work as well as they do, and I think we shouldn't lightly give up on that achievement. What we have now is basically distros going: Awwwww. Fuck it. This is too hard. I'm done with this. You know what? Instead of “any package your heart desires”, you get a fixed set of packages. The ones that everyone needs regardless of what they actually do with their computer. Instead of being allowed to mess with your configuration, we'll make your rootfs read-only. (In the case of SteamOS): Instead of doing our best to make it work on your hardware, we'll tell you precisely which piece of hardware you'll need to buy if you want our software to run on it. User: Well, that's additional money I need to spend. And, how do I install my favourite app “foo”? The one I need to actually get useful work out of my computer? Distro: Don't worry, we've got you covered. We'll provide a runtime for distrobox and flatpaks. Package maintainer of “foo”: How do I get my package out in a way that perfectly integrates with distros? Distro: Make a container. Congratulations: This is additional work you have to do now, that you didn't have to do before. And about that idea of perfect integration: You can kiss that goodbye. User: I don't know. I'm also in favour of integration. Distro: That's alright. You can share and unshare stuff between containers and the host system. This, of course, is additional work you didn't have to do before. Less work for me, more work for everyone else. The future looks so bright.
hamandcheese 2y ago
Ahh, just what I need, shoddy Dockerfiles to define not only my applications but now my whole OS!
- BiteCode_dev 2y ago
  The next step is obviously: curl https://install.os.shoddydockerfile.com https://install.os.shoddydockerfile.com | sh
  - ChocolateGod 2y ago
    You forgot the sudo in the second part.
- akdev1l 2y ago
  You can use buildah(shell, python, etc) or nix to create OCI images. This has nothing to do with docker.
  - max-privatevoid 2y ago
    OCI isn't a particularly good image format, the only thing it has going for itself is that it's the thing Docker uses. I would absolutely not be surprised if 90% of future bootc OCI images are built with Dockerfiles.
  - hamandcheese 2y ago
    Okay, but at that point why bother with the intermediate OCI images? Especially with nix, if you're gonna use Nix you may as well build the OS directly (i.e. use NixOS).
udev4096 2y ago
> Bazzite, was a better experience than SteamOS Bazzite is so much worse than SteamOS in terms of usability. I installed it on my deck and it was full of bugs, the ISO image size is the biggest I have ever seen (~10G), KDE crashes way too often, invoking keyboard doesn't work half the time, comes with so much bloat (waydroid being one of them). It's a joke to even call it a better "experience". Also, immutability absolutely sucks for daily drive. I have to wait for 10mins for rpm-ostree to install a package while a normal distro can do it in seconds. Immutability makes sense in case of routers, VMs running core services (such as a reverse proxy, dns, etc)
- fuzzy2 2y ago
  The idea is that you do not install packages, at all. Instead, you would use Flatpak and the like, plus mutable containers (Distrobox or whatever) if needed.
  - vaylian 2y ago
    This. Installing packages via rpm-ostree is something one can do, but in most cases it should not be necessary. It's more of an escape hatch than an everyday tool. Most additional software will be installed in the user's home directory.
  - udev4096 2y ago
    Flatpak wants to download a gazillion dependencies before the actual package. And even the original package size is huge, compared to apk, deb, rpm, etc. Stop with the bloat. Native package managers are always going to be fast, easy to use and have a minimal size
    - akdev1l 2y ago
      > Flatpak wants to download a gazillion dependencies before the actual package Ah yes unlike other package managers that magically make applications not need dependencies.
      - 2y ago
eriksjolund 2y ago
If you want to know why bootc is needed check this list of goals: https://containers.github.io/bootable/ https://containers.github.io/bootable/ I found that URL by following the link in "bootc is the key component in a broader mission of bootable containers." (https://bootc-dev.github.io/bootc/intro.html https://bootc-dev.github.io/bootc/intro.html)
MortyWaves 2y ago
> Simple, right? This copies a file to run a Nginx container as a quadlet and a config into the /etc folder. This brings GitOps to my OS. With this whenever my machine starts, whether for the first time or millionth time, its going to be configured to work exactly as expected with no extra work or additional configuration. That isn't GitOps. That's immutable file systems. Make it as immutable as you want, that has nothing to do with GitOps. You need the other half of the story, the infrastructure-as-code and the deployment.
TacticalCoder 2y ago
[dead]
linuxftw 2y ago
bootc is a great evolution for rpmostree IMO. Fedora Atomic had decent build tooling, but all of that was thrown away for Fedora CoreOS due to the ignition use. I was never a can of Fedora CoreOS but I really liked Atomic. This seems to be a sensible pivot back the other direction. We don't need the CoreOS parts that never really delivered any value. And now building an system image is a simple as writing the container file. This way of doing things probably offers little to the average Linux user. However, it's a great model for distributing 'appliance' images, or having transactional updates on your servers. In the cloud, transactional updates aren't that big of a deal, you can do a rolling replace of your instances. On bare metal machines, doing in-place transactional updates is a big win. Rancher also has an interesting project called Elemental. It seems to be a little more portable for other distros, but I haven't played around with it.
- akdev1l 2y ago
  The thing it should really do is enabling users to more easily build their own “distros”. bootc should have support for distros other than Fedora eventually
  - linuxftw 2y ago
    I think they're working on that. Probably not a high priority feature considering most of the developers are Fedora-focused.
sevensor 2y ago
> There is no denying that most applications are shipped today as a Docker container and most developers have some experience with them Author and I move in quite different circles. This is not my experience of applications or of software developers.
- jmchuster 2y ago
  Even if docker is the most popular build tool used across all professionals [1], that usage number is still only 59% of professional developers. [1] https://survey.stackoverflow.co/2024/technology#most-popular-technologies-tools-tech-prof https://survey.stackoverflow.co/2024/technology#most-popular...
nimbius 2y ago
this is the absolute nadier of container/cloud/devsecops chinstrap hipster nonsense. we want to turn the entire system into a docker container because reasons? without ever addressing the sins of flatpak and the performance hit from containerization vs bare metal? what exactly is the win here? "Bootc allows you to make an OS the same way you make an application, using containers!" but why. "There is no denying that most applications are shipped today as a Docker container" postfix, dovecot, nginx, veloren, gnome, hell roughly 16,000 packaged applications in the EPEL repository do not insist upon themselves as containers. Forgejo doesnt require a docker container either. the only people pushing docker are developers who are trapped toiling with some teetering monstrosity of rails/gunicorn/pypi dependencies that are so odious and brittle to deploy in a normal fashion that a containerized offering is the only way people would ever use them in the first place. is this just another attempt to market capture my desktop with a proprietary backend store like snaps? or force me to sign up for a docker account just to log into my laptop? did a docker C level write this?

63 points by nikodunk 2y ago

After reading the article I don't get why I need to know about bootc. It's something to do with immutability like a couple of OSs I've never used, of which I've only heard of 1.

sevg 2y ago
Yeah it’s not a great article. It didn’t even mention existing immutable technology at all (like rpm-ostree) let alone a technical comparison.
- anonfordays 2y ago
  Nor did it mention immutable operating systems like Flatcar Linux, upon which you can deploy immutable containers...
INTPenis 2y ago
The main takeaway is that you can build your OS image like any OCI image, and you can boot these OCI images. I've been using immutable OS for over 2 years now and the main advantage to me is the ease of rollback. I even started using it professionally in my work with the main selling point being easier lifecycle management. Bootc is just an advancement of this, it's a next generation rpm-ostree. I could already boot my own OCI images before.
- Joker_vD 2y ago
  But, like, I can already boot from a read-only ISO-image, you know.
  - INTPenis 2y ago
    If you prefer building ISO images over OCI images be my guest. Nobody is forcing you to use this new technology.
    - Joker_vD 2y ago
      Okay, now I am concerned because almost every time somebody tells me "nobody is forcing you to use this new technology", in 5 or so years (if this technology survives) I am starting to get forced to use this new technology because it's "mature enough, and is basically the new industry standard, what you are currently using is going to be deprecated in a couple of years". Apparently, it's because if someone wants to make their new way the only way, they have to tell people "of course we're not forcing anyone to do it this way" for the first several years, while keeping working on rooting the existing ways out. Anyway, I digress; what I actually would like to know is the benefits/downsides compared to e.g. immutable boot partitions, or whatever. After all, I don't generally build my own OS images, neither in .iso or in OCI-image format, I take and use off-the-shelf ones; but it generally involves dd-ing them onto the /dev/sdX at the very least. Using prepared .vdi's is another option.
      - INTPenis 2y ago
        I generally don't build my own OS images either, because it's such a hassle and adds such overhead to lifecycle management. But I believe that building OCI images makes the overhead much less. Mainly because the OS I want to use already have a base image I can use, so my build is only a few lines of customization. Your first paragraph is kinda funny to me because 10 years ago I felt like an outsider supporting systemd, and now it's everywhere.
vaylian 2y ago
I think the article should also point to the /usr merge https://www.freedesktop.org/wiki/Software/systemd/TheCaseForTheUsrMerge/ https://www.freedesktop.org/wiki/Software/systemd/TheCaseFor... because it makes it feasible to have atomic distributions. Most Linux distributions today have moved all the distribution-specific system files under the /usr hierarchy. Which means that a Linux distribution consists mostly of the /usr and /boot directories. In addition, you have files in /var and /etc that can be modified by the local system administrator and you have /home (which is actually /var/home internally) where regular users can save local files. The local admin can still influence the system by editing files in /etc but she cannot mess with the files in /usr. The key benefit is that distributors can roll out very well-defined Linux distributions that still allow for local modifications in non-critical areas.

MiiMe19 2y ago

>They can turn it on and know it will boot properly without having to worry about things users had to worry about in the past like drivers, kernel mods, or new packages breaking things – the ghosts of Linux Desktop Past. I mean, you still need to setup your bootc image to contain those drivers and everything like that. Once you set up Debian, it will always just boot right too. This just seems like Yet Another Immutable Distro™. I guess stuff like this is a bit nicer for things like like game consoles, where you aren't actually using it like a computer and installing "normal" software, but I don't really see the how this will change the Linux desktop.

yjftsjthsd-h 2y ago

I want to know about - or rather, use - bootc. Unfortunately, the problem is this: FROM quay.io/fedora/fedora-bootc:41 If you're using Fedora (or maybe RHEL) and happy to use premade base images then it's apparently great. The moment you step off that happy path, good luck; nobody has written the code, and the docs are inadequate to do it yourself. Or at least, they were for me; I wanted to make an Alpine bootc image but everything was shades of "now start from this Fedora image, install this magic package with the systemd integration, invoke the rpm wrapper, and it all works!" which was kinda a problem trying to integrate with a system that had none of those things. It was annoying because I'm pretty sure the tech is actually distro agnostic, but it was too underdocumented to use.

worthless-trash 2y ago
I guess the community can step up and build their own bootc images.
- yjftsjthsd-h 2y ago
  Am I not a member of the community? I am trying to build bootc images, but I can't work with nothing. Just now, I thought I'd go check and see if it'd improved, and guess what? It's actually worse than I remembered. There's a list of distros using it at https://github.com/bootc-dev/bootc/blob/main/ADOPTERS.md https://github.com/bootc-dev/bootc/blob/main/ADOPTERS.md - but actually the non-Fedora distros they list are RHEL and HeliumOS, which is a CentOS Stream derivative. (There's a list of ostree users, but that's not the same and they even admit that this is more of a 'hey these use related tech and someday maybe they can use this'). So I went looking through docs, and found https://bootc-dev.github.io/bootc/installation.html https://bootc-dev.github.io/bootc/installation.html which again says that this really only supports Fedora/CentOS/RHEL, but does link to the issue tracking work for others to use it. That's https://github.com/coreos/bootupd/issues/468 https://github.com/coreos/bootupd/issues/468 , which is 2 years old and... basically is, again, a bunch of different folks saying they'd like to make it work on different distros and getting nowhere. There is one person who posted on https://github.com/bootc-dev/bootc/issues/865 https://github.com/bootc-dev/bootc/issues/865 and who claims to have converted an ostree Arch system to using bootc, but they didn't post steps to reproduce. Actually clicking around I eventually found their repo https://github.com/frap129/arch-bootc/tree/main https://github.com/frap129/arch-bootc/tree/main which again doesn't say how to do it, but does appear to contain their code, so maybe I can reverse-engineer from there... Anyways. The community would very much like to step up, but we can only step up over so high of a learning curve, or possibly so high of a porting curve (a lot of comments indicate being tied to rpm integration).

dailykoder 2y ago

Sounds interesting, but since I haven't been in touch much with this topic I ask myself: Does this have any benefit for my personal home-computer usage? For a long time I have the urge to try out Nix, because I clutter up my computer way too fast and therefore often get mad and just install a fresh system. This works fine with my files, but there are always applications which I forget about and forget to save configs. So having this all in a git repo to spin it up fast would be nice. Is bootc, fedora silverblue and so forth trying to achieve something similar?

averms 2y ago
I think bootc is exactly what you're looking for. I use it[1] for configuration like you mentioned but also for: - Installing codecs from third-party repositories. This is especially nice to do in CI because you get a build failure if packaging drift happens. - Installing out-of-tree drivers. Again, you get a build failure in CI if an out-of-tree kernel module won't build. In addition, you can use multi-stage builds (see the Dockerfile in my repo for an example) to avoid pulling dependencies into your final system image. This saves me from having the 70 or so RPM packages that are required for building NVIDIA drivers installed on my PC. It's not as ambitious as NixOS but I think it gives a lot of the same benefits with far less effort. [1]: https://github.com/averms/verms-os https://github.com/averms/verms-os
- dailykoder 2y ago
  Thank you! Then I'll look a bit more into it.

stakhanov 2y ago

I'll offer a less charitable framing of the whole topic of immutable / atomic distros: This is pretty much Linux distributors deciding they want to stop doing their job (or redefine what their job is to a much smaller scope). -- I'm not saying it's not justifiable that the ecosystem may need to be reshaped in that way. I'm just cautioning people from drinking the “this is the future and the future looks bright” Kool-Aid all too easily. The job of making a Linux distribution has always been what, in an old-fashioned term, used to be called “system integration” work. They would start with a bewilderingly huge array of open-source packages, each being developed without any centralized standard or centralized control over what the system actually looks like. Then they would curate a collection of build recipes and patches for those packages. The value a distro delivers for the user is that, for any package “foo” that their heart desires, a user can just say “apt install foo” and it'll “just work”. There will be default configuration and patches to make foo integrate perfectly with the rest of the system. The value a distro delivers for package maintainers is: “Don't worry about the packaging. Just put your code out as open source, and we'll take care of the rest.” The job of a distributor is extremely difficult, because of all the moving parts: People select their hardware, their packages, and they mess with the default configurations. It is no wonder at all that Linux distributions don't always succeed in their mission to truly deliver on this. But it's a huge engineering achievement that they work as well as they do, and I think we shouldn't lightly give up on that achievement. What we have now is basically distros going: Awwwww. Fuck it. This is too hard. I'm done with this. You know what? Instead of “any package your heart desires”, you get a fixed set of packages. The ones that everyone needs regardless of what they actually do with their computer. Instead of being allowed to mess with your configuration, we'll make your rootfs read-only. (In the case of SteamOS): Instead of doing our best to make it work on your hardware, we'll tell you precisely which piece of hardware you'll need to buy if you want our software to run on it. User: Well, that's additional money I need to spend. And, how do I install my favourite app “foo”? The one I need to actually get useful work out of my computer? Distro: Don't worry, we've got you covered. We'll provide a runtime for distrobox and flatpaks. Package maintainer of “foo”: How do I get my package out in a way that perfectly integrates with distros? Distro: Make a container. Congratulations: This is additional work you have to do now, that you didn't have to do before. And about that idea of perfect integration: You can kiss that goodbye. User: I don't know. I'm also in favour of integration. Distro: That's alright. You can share and unshare stuff between containers and the host system. This, of course, is additional work you didn't have to do before. Less work for me, more work for everyone else. The future looks so bright.

hamandcheese 2y ago

Ahh, just what I need, shoddy Dockerfiles to define not only my applications but now my whole OS!

BiteCode_dev 2y ago
The next step is obviously: curl https://install.os.shoddydockerfile.com https://install.os.shoddydockerfile.com | sh
- ChocolateGod 2y ago
  You forgot the sudo in the second part.
akdev1l 2y ago
You can use buildah(shell, python, etc) or nix to create OCI images. This has nothing to do with docker.
- max-privatevoid 2y ago
  OCI isn't a particularly good image format, the only thing it has going for itself is that it's the thing Docker uses. I would absolutely not be surprised if 90% of future bootc OCI images are built with Dockerfiles.
- hamandcheese 2y ago
  Okay, but at that point why bother with the intermediate OCI images? Especially with nix, if you're gonna use Nix you may as well build the OS directly (i.e. use NixOS).

udev4096 2y ago

> Bazzite, was a better experience than SteamOS Bazzite is so much worse than SteamOS in terms of usability. I installed it on my deck and it was full of bugs, the ISO image size is the biggest I have ever seen (~10G), KDE crashes way too often, invoking keyboard doesn't work half the time, comes with so much bloat (waydroid being one of them). It's a joke to even call it a better "experience". Also, immutability absolutely sucks for daily drive. I have to wait for 10mins for rpm-ostree to install a package while a normal distro can do it in seconds. Immutability makes sense in case of routers, VMs running core services (such as a reverse proxy, dns, etc)

fuzzy2 2y ago
The idea is that you do not install packages, at all. Instead, you would use Flatpak and the like, plus mutable containers (Distrobox or whatever) if needed.
- vaylian 2y ago
  This. Installing packages via rpm-ostree is something one can do, but in most cases it should not be necessary. It's more of an escape hatch than an everyday tool. Most additional software will be installed in the user's home directory.
- udev4096 2y ago
  Flatpak wants to download a gazillion dependencies before the actual package. And even the original package size is huge, compared to apk, deb, rpm, etc. Stop with the bloat. Native package managers are always going to be fast, easy to use and have a minimal size
  - akdev1l 2y ago
    > Flatpak wants to download a gazillion dependencies before the actual package Ah yes unlike other package managers that magically make applications not need dependencies.
    - 2y ago

eriksjolund 2y ago

If you want to know why bootc is needed check this list of goals: https://containers.github.io/bootable/ https://containers.github.io/bootable/ I found that URL by following the link in "bootc is the key component in a broader mission of bootable containers." (https://bootc-dev.github.io/bootc/intro.html https://bootc-dev.github.io/bootc/intro.html)

MortyWaves 2y ago

> Simple, right? This copies a file to run a Nginx container as a quadlet and a config into the /etc folder. This brings GitOps to my OS. With this whenever my machine starts, whether for the first time or millionth time, its going to be configured to work exactly as expected with no extra work or additional configuration. That isn't GitOps. That's immutable file systems. Make it as immutable as you want, that has nothing to do with GitOps. You need the other half of the story, the infrastructure-as-code and the deployment.

TacticalCoder 2y ago

[dead]

linuxftw 2y ago

bootc is a great evolution for rpmostree IMO. Fedora Atomic had decent build tooling, but all of that was thrown away for Fedora CoreOS due to the ignition use. I was never a can of Fedora CoreOS but I really liked Atomic. This seems to be a sensible pivot back the other direction. We don't need the CoreOS parts that never really delivered any value. And now building an system image is a simple as writing the container file. This way of doing things probably offers little to the average Linux user. However, it's a great model for distributing 'appliance' images, or having transactional updates on your servers. In the cloud, transactional updates aren't that big of a deal, you can do a rolling replace of your instances. On bare metal machines, doing in-place transactional updates is a big win. Rancher also has an interesting project called Elemental. It seems to be a little more portable for other distros, but I haven't played around with it.

akdev1l 2y ago
The thing it should really do is enabling users to more easily build their own “distros”. bootc should have support for distros other than Fedora eventually
- linuxftw 2y ago
  I think they're working on that. Probably not a high priority feature considering most of the developers are Fedora-focused.

sevensor 2y ago

> There is no denying that most applications are shipped today as a Docker container and most developers have some experience with them Author and I move in quite different circles. This is not my experience of applications or of software developers.

jmchuster 2y ago
Even if docker is the most popular build tool used across all professionals [1], that usage number is still only 59% of professional developers. [1] https://survey.stackoverflow.co/2024/technology#most-popular-technologies-tools-tech-prof https://survey.stackoverflow.co/2024/technology#most-popular...

nimbius 2y ago

this is the absolute nadier of container/cloud/devsecops chinstrap hipster nonsense. we want to turn the entire system into a docker container because reasons? without ever addressing the sins of flatpak and the performance hit from containerization vs bare metal? what exactly is the win here? "Bootc allows you to make an OS the same way you make an application, using containers!" but why. "There is no denying that most applications are shipped today as a Docker container" postfix, dovecot, nginx, veloren, gnome, hell roughly 16,000 packaged applications in the EPEL repository do not insist upon themselves as containers. Forgejo doesnt require a docker container either. the only people pushing docker are developers who are trapped toiling with some teetering monstrosity of rails/gunicorn/pypi dependencies that are so odious and brittle to deploy in a normal fashion that a containerized offering is the only way people would ever use them in the first place. is this just another attempt to market capture my desktop with a proprietary backend store like snaps? or force me to sign up for a docker account just to log into my laptop? did a docker C level write this?