3 ms·

Finally, another distribution that seriously adopts the immutable distribution approach. The future is now, old man. I am just waiting for the day we have an o

by sph 3y ago

Finally, another distribution that seriously adopts the immutable distribution approach. The future is now, old man. I am just waiting for the day we have an officially-supported Arch Linux Atomic distro based on ostree (pacman-ostree?)

BSDobelix 3y ago
The intelligent thing would be something like MirageOS or OSv, and not a complete Operating-system as a host for containers.
- sph 3y ago
  Isn't a modern Linux distribution a complete operating system as a host for containers already? The issue is that most things are not containerized (or should I say namespaced) yet.
  - BSDobelix 3y ago
    >Isn't a modern Linux distribution a complete operating system as a host for containers already? Yep and that's the problem, not talking about stuff that is in the container the running app never uses.
    - NoZebra120vClip 3y ago
      In the mid-90s, dynamic/shared objects were the new hotness on SunOS. Imagine if you'd told us that in 30 years, applications would be linked statically... not merely with their libraries, but with the entire OS as a dependency!
      - nottorp 3y ago
        > Imagine if you'd told us that in 30 years, applications would be linked statically... not merely with their libraries, but with the entire OS as a dependency! Javascript "applications" aren't far from that are they? Copy of Chrome, copy of all modules...
      - BSDobelix 3y ago
        >not merely with their libraries, but with the entire OS as a dependency! And then they made Java ;)
        vrighter 3y ago
        and of course, they put java in a container. an os statically linked to what's practically another os, statically linked to the application itself. (I consider containers to be a form of static linking)
diggan 3y ago
Newer versions of SteamOS is essentially that, although it does focus on the gaming/multimedia use-case rather than general desktop usage, but it does the general desktop usage part just fine too.
candiddevmike 3y ago
I don't see the point of ostree personally. It's overly complicated for what it's trying to do (immutable base). I have been working on an immutable OS that uses squashfs instead and it seems to work better. The contract is tighter with squashfs, as you really _can't_ change the underlying squashfs stuff. Upgrades are easily scriptable and transparent on what they're trying to accomplish, too. The distribution is designed as a "meta" distribution with different flavors (deb, ubu, arc, fed, etc) that you can easily "swap" to just by changing the boot stuff, all configured to deliver the same kind of functionality (container host, mostly).
- PlutoIsAPlanet 3y ago
  OSTree is moving to using OCI images, which removes a large amount of complexity in its current form. On top of using composefs, this will make it impossible to change the underlying files manually without causing the file to be invalidated. https://fedoraproject.org/wiki/Changes/OstreeNativeContainerStable https://fedoraproject.org/wiki/Changes/OstreeNativeContainer...
  - vaylian 3y ago
    Does that mean that system updates will pull complete container images instead of diff?
    - dralley 3y ago
      I believe diff support between container images is being worked on as well. edit: there's a link in that document to https://github.com/containers/image/pull/902 https://github.com/containers/image/pull/902
- merb 3y ago
  Yeah I do not like it as well. Especially since redhat tried to force it on users of CoreOS Container Linux, with a completely new os without any upgrade path and half the features. Forking base worked at the beginning , but was painful and broke sometimes. I migrated all coreos machines to flatcarlinux which was a fork of coreos and was bought by Microsoft and is still maintained by them. What a strange world. (I was a big fan of back than and used centos/fedora heavily. I dropped everything in favor of Debian/tumbleweed/manjora and almalinux(centos migrated)) I think flatcar uses squashfs
jmclnx 3y ago
> Adaptable Linux Platform (ALP) New one on me, I had to search for its meaning. This seems to be a SUSE marketing term. But what I read seems to be some kind of immutable distribution with heavy focus on containers. Good for SUSE, glad right now my distro is not going down that path and as far as I know there are no plans for that. But I am sure someday upstream may force it to. When that happens, depending on how it plays out, off to OpenBSD full time, I use BSD now to test all development I do on Linux. I really like the simplicity of pledge(2) and unveil(2) plus the protections OpenBSD has by defaults. Testing on OpenBSD helped find some obscure bugs in a few of my objects.
tmtvl 3y ago
'Immutable' distributions suffer from bad branding, the only thing that's immutable is /usr, so it's far less terrible than the name makes it seem. Loading and blacklisting modules, modifying grub configuration, changing sysctl settings,... all of those things work fine. But people see 'immutable' and think 'oh, I can't change my fan speed', 'oh, I can't disable the annoying PC speaker beep', and so on. I don't know how the branding could be improved, but I do think that better branding would help getting people invested.
- crabbone 3y ago
  Even just immutable /usr is still bad for individual users. Eg. I build a few projects myself. And sometimes I also need to debug them, after they are installed. Also, very frequently used programs, like Web browsers end up there. So, if I had to use an immutable system, I would either not put anything useful in /usr, or would not use an immutable system at all. This is, of course, not true for systems that are meant to be deployed and changed very infrequently, where stability of operation and ability to cleanly undo an upgrade are much more valuable than the convenience of changing whatever you need. ---- I think, a lot of such systems also very quickly earned a bad reputation because they also tried to ship with common applications for interactive use that don't work well (or at all) on such systems (eg. code editors). So, the first people to try such systems were programmers, who spend most of their time using the system in the code editor, and seeing how that doesn't work saw such a system as worthless.
  - tmtvl 3y ago
    By 'I build a few projects myself', do you mean you install binaries to /usr/bin (or /usr/local/bin)? If so, why don't you just put them in $HOME/bin? And about the web browsers, aside from the fact that immutable distributions tend to ship one by default, can't you just install them via Flatpak?
    - crabbone 3y ago
      If I put my binaries in a place other than the "immutable" one, what's the point in having the immutable place if I don't use it? If I put my binaries in the "immutable" place, it's no longer immutable. I mean, if, say, I don't build my shell myself -- I'm also not going to modify it anyways. So, expending extra efforts on ensuring immutability is just making my system more complex for no reason. But, if I do build my shell myself, then immutability only gets in the way. There isn't a situation where I gain something tangible from immutability (again, as an individual user). ---- Actually, from my history, the most common thing I need to do in /usr is to create symlinks for various shared objects. Didn't even think about it at first.

by sph 3y ago

BSDobelix 3y ago

The intelligent thing would be something like MirageOS or OSv, and not a complete Operating-system as a host for containers.

sph 3y ago
Isn't a modern Linux distribution a complete operating system as a host for containers already? The issue is that most things are not containerized (or should I say namespaced) yet.
- BSDobelix 3y ago
  >Isn't a modern Linux distribution a complete operating system as a host for containers already? Yep and that's the problem, not talking about stuff that is in the container the running app never uses.
  - NoZebra120vClip 3y ago
    In the mid-90s, dynamic/shared objects were the new hotness on SunOS. Imagine if you'd told us that in 30 years, applications would be linked statically... not merely with their libraries, but with the entire OS as a dependency!
    - nottorp 3y ago
      > Imagine if you'd told us that in 30 years, applications would be linked statically... not merely with their libraries, but with the entire OS as a dependency! Javascript "applications" aren't far from that are they? Copy of Chrome, copy of all modules...
    - BSDobelix 3y ago
      >not merely with their libraries, but with the entire OS as a dependency! And then they made Java ;)
      - vrighter 3y ago
        and of course, they put java in a container. an os statically linked to what's practically another os, statically linked to the application itself. (I consider containers to be a form of static linking)

diggan 3y ago

Newer versions of SteamOS is essentially that, although it does focus on the gaming/multimedia use-case rather than general desktop usage, but it does the general desktop usage part just fine too.

candiddevmike 3y ago

I don't see the point of ostree personally. It's overly complicated for what it's trying to do (immutable base). I have been working on an immutable OS that uses squashfs instead and it seems to work better. The contract is tighter with squashfs, as you really _can't_ change the underlying squashfs stuff. Upgrades are easily scriptable and transparent on what they're trying to accomplish, too. The distribution is designed as a "meta" distribution with different flavors (deb, ubu, arc, fed, etc) that you can easily "swap" to just by changing the boot stuff, all configured to deliver the same kind of functionality (container host, mostly).

PlutoIsAPlanet 3y ago
OSTree is moving to using OCI images, which removes a large amount of complexity in its current form. On top of using composefs, this will make it impossible to change the underlying files manually without causing the file to be invalidated. https://fedoraproject.org/wiki/Changes/OstreeNativeContainerStable https://fedoraproject.org/wiki/Changes/OstreeNativeContainer...
- vaylian 3y ago
  Does that mean that system updates will pull complete container images instead of diff?
  - dralley 3y ago
    I believe diff support between container images is being worked on as well. edit: there's a link in that document to https://github.com/containers/image/pull/902 https://github.com/containers/image/pull/902
merb 3y ago
Yeah I do not like it as well. Especially since redhat tried to force it on users of CoreOS Container Linux, with a completely new os without any upgrade path and half the features. Forking base worked at the beginning , but was painful and broke sometimes. I migrated all coreos machines to flatcarlinux which was a fork of coreos and was bought by Microsoft and is still maintained by them. What a strange world. (I was a big fan of back than and used centos/fedora heavily. I dropped everything in favor of Debian/tumbleweed/manjora and almalinux(centos migrated)) I think flatcar uses squashfs

jmclnx 3y ago

> Adaptable Linux Platform (ALP) New one on me, I had to search for its meaning. This seems to be a SUSE marketing term. But what I read seems to be some kind of immutable distribution with heavy focus on containers. Good for SUSE, glad right now my distro is not going down that path and as far as I know there are no plans for that. But I am sure someday upstream may force it to. When that happens, depending on how it plays out, off to OpenBSD full time, I use BSD now to test all development I do on Linux. I really like the simplicity of pledge(2) and unveil(2) plus the protections OpenBSD has by defaults. Testing on OpenBSD helped find some obscure bugs in a few of my objects.

tmtvl 3y ago

'Immutable' distributions suffer from bad branding, the only thing that's immutable is /usr, so it's far less terrible than the name makes it seem. Loading and blacklisting modules, modifying grub configuration, changing sysctl settings,... all of those things work fine. But people see 'immutable' and think 'oh, I can't change my fan speed', 'oh, I can't disable the annoying PC speaker beep', and so on. I don't know how the branding could be improved, but I do think that better branding would help getting people invested.

crabbone 3y ago
Even just immutable /usr is still bad for individual users. Eg. I build a few projects myself. And sometimes I also need to debug them, after they are installed. Also, very frequently used programs, like Web browsers end up there. So, if I had to use an immutable system, I would either not put anything useful in /usr, or would not use an immutable system at all. This is, of course, not true for systems that are meant to be deployed and changed very infrequently, where stability of operation and ability to cleanly undo an upgrade are much more valuable than the convenience of changing whatever you need. ---- I think, a lot of such systems also very quickly earned a bad reputation because they also tried to ship with common applications for interactive use that don't work well (or at all) on such systems (eg. code editors). So, the first people to try such systems were programmers, who spend most of their time using the system in the code editor, and seeing how that doesn't work saw such a system as worthless.
- tmtvl 3y ago
  By 'I build a few projects myself', do you mean you install binaries to /usr/bin (or /usr/local/bin)? If so, why don't you just put them in $HOME/bin? And about the web browsers, aside from the fact that immutable distributions tend to ship one by default, can't you just install them via Flatpak?
  - crabbone 3y ago
    If I put my binaries in a place other than the "immutable" one, what's the point in having the immutable place if I don't use it? If I put my binaries in the "immutable" place, it's no longer immutable. I mean, if, say, I don't build my shell myself -- I'm also not going to modify it anyways. So, expending extra efforts on ensuring immutability is just making my system more complex for no reason. But, if I do build my shell myself, then immutability only gets in the way. There isn't a situation where I gain something tangible from immutability (again, as an individual user). ---- Actually, from my history, the most common thing I need to do in /usr is to create symlinks for various shared objects. Didn't even think about it at first.