Upstream images vs bazzite: https://github.com/ublue-os/countme/blob/main/growth_upstream_with_bazzite.svg

My prediction: bazzite may have more installs than Fedora KDE by the end of the year.

you are viewing a single comment's thread
view the rest of the comments
[–] 3 points 2 months ago* (10 children)

I still miss the advantages for these cases.

Zero-maintenance and upgrades.

Update it every once in a while or setup auto updates. I do not see any difference between traditional os and immutable. You’re likely not modifying any system files anyway.

You're overthinking it, there's no reason to care if the root disk is readable or not. If it updates reliably out of the box there's no reason to touch it.

Are they really going to brick their system? That would require opening the terminal. But I mean, fair.

You don't need to open a terminal to brick a traditional linux system they tend to do that on their own.

What I do not understand is why there are users swearing by bazzite and other immutable distributions. These examples you make is basically for users who just do the most basic operations with their systems.

I can't speak for "immutable distributions" but for bazzite it's to ensure working upgrades.

What I do not understand is why technically adept people are so excited for these kinds of distributions?

I'm technically adept at Linux I expect software to work. (system upgrades should work, app installation shouldn't break the PC, etc.)

  • source
  • parent
  • hideshow 10 child comments
  • [–] 1 point 2 months ago (9 children)

    So, the main advantage is that it is ensured that an update will not brick the system?

    That is pretty neat, but it's been quite a while since the last update which broke something for me. And that was either on arch of switching Debian version.

    I reckon it is nice that you ensure updates won't break anything, even though I'm not sure that can be ensured, in most cases I had it was the repo itself which made mistakes in packaging the software who broke it and I don't think there's solution for that. Either way, I myself do not see this such an advantage as to displace the pain of having everything run in flatpak.

  • source
  • parent
  • hideshow 9 child comments
  • [–] 4 points 2 months ago (8 children)

    Updates can be ensured and broken repositories go away entirely that's the entire point. I don't think it's "nice" I would consider that a basic feature in Linux. If you like Linux your way then that doesn't go away.

  • source
  • parent
  • hideshow 8 child comments
  • [–] 1 point 2 months ago (7 children)

    What do you mean? How can it be possible to eliminate a packaging error? If the packaging team makes a mistake you get a broken software, regardless whether you download a binary through a repository or through flatpak.

  • source
  • parent
  • hideshow 7 child comments
  • [–] 4 points 2 months ago (6 children)

    Because the image never gets built if there's a packaging error, so the user never ends up on a broken image. A broken package never makes it to the end. If it's broken the user just doesn't get an image until the package is fixed and then they get a new image.

  • source
  • parent
  • hideshow 6 child comments
  • [–] 1 point 2 months ago (5 children)

    I had broken packages getting installed before. They would compile correctly but certain functionality would not work due to how it was packaged. This is not something which can be prevented, I do not believe it is possible.

  • source
  • parent
  • hideshow 5 child comments
  • [–] 3 points 2 months ago (4 children)

    It is 100% possible and people have been doing it for years. If the package is broken the final product is never built, it's impossible to ship it to the end user since it's one whole complete image.

  • source
  • parent
  • hideshow 4 child comments
  • [–] 1 point 2 months ago (3 children)

    I am afraid we are talking about different things. Recently I had to report a broken package to a repository. The problem was that they mapped a path to the incorrect directory.

    The software compiled and worked correctly, but some specific functionality which needed to read data from that directory was broken.

    I do not think there is a way to prevent this kind of errors.

  • source
  • parent
  • hideshow 3 child comments
  • [+] 1 point 2 months ago* (last edited 3 weeks ago) (2 children)
  • [–] 1 point 2 months ago (1 child)

    In normal repos they also test their packages. I do not think it is possible in any distribution repo to ship a binary which did not compile. Dynamic library linking may have some problems I guess, but unless you're using arch that is generally never a real problem with package manager installations. I have never got a package which plain does not run.

  • source
  • parent
  • hideshow 1 child comment