5 ms·

> but wouldn't you rather have your root be a SquashFS image on an SD card or similar, with the storage section being ZFS? Read-only root filesystems are one o

> but wouldn't you rather have your root be a SquashFS image on an SD card or similar, with the storage section being ZFS? Read-only root filesystems are one of those things that everybody ought to do, yet are usually impractical. Unfortunately, most software doesn't really support the Linux Filesystem Hierarchy Standard, so you have software that modifies itself under /usr (supposed to be read-only), ever-growing logs and caches not stored under /var/log and /var/cache so they can't be managed automatically, etc. You generally find squashfs roots where the distro is specialized and not general-purpose - for a recent example, see Talos.

Legogris 7y ago
Have you checked out NixOS? Everything is read-only and derived from static configuration.
- solatic 7y ago
  I run NixOS as a daily driver, and while I'm aware that the install media is a squashfs mount and that it's feasible to create server images where /nix/store is a squashfs mount as well. But in day-to-day use on a development machine, running nixos-rebuild switch makes a read-only root impractical, so far as I know.
AnIdiotOnTheNet 7y ago
The OSs that insisted upon scattering application files all over the hierarchy only have themselves to blame for this situation. At some point in the past 30 years thought could have been given to the idea that applications are separate from the platform they run on, but UNIX just doesn't think that way. Everything must be part of the same gigantic Goldberg-esq state so everything can catch fire and burn down at once as soon as there's a conflict of any kind. Anyway, the fix is pretty obvious: put each application in its own namespace, thus its view of "/usr" isn't the same as the immutable OS "/usr" and it is free to write whatever it wants without causing any trouble.
- cat199 7y ago
  > At some point in the past 30 years thought could have been given to the idea that applications are separate from the platform they run on, but UNIX just doesn't think that way. Everything must be part of the same gigantic Goldberg-esq state so everything can catch fire and burn down at once as soon as there's a conflict of any kind. this only happens if one isnt aren't managing applications coherently (e.g binary only packages managed haphazardly, like most linux binary packagers) on systems where there is a clear base+add-ons distinction (e.g. source based ports), these things happen much less often - all packages are built from a coherent source tree, and read only root is often feasable because packages only install reference files into their respective '/usr/share' area and don't muck with the 'real system' in /etc - the latter being an administrative action (e.g. package installation is a separate action from service configuration / execution)
  - AnIdiotOnTheNet 7y ago
    So basically, all software has to be built from source by maintainers who are careful to make sure it doesn't conflict with other software. And people wonder why applications aren't ported to these OSs. The OS should be a platform. I should be able to build an application and distribute it to users and have it just run on that platform without involving third party middlemen and regardless of other software they have. You know what OSs accomplished this? The original Macintosh, RiscOS, DOS, and (mostly) Windows 3.1. Why is it that we can't accomplish today something we did 30 years ago?
    - cat199 7y ago
      a platform for what? a platform for 'building your system', or a platform for 'distributing and executing binaries'? the binary only distribution mentality comes from microcomputer culture, which postdates unix/mini culture and is rooted in non-technical users installing purchased 'application' programs from vendors rather than computer users (read: programmers) building their systems to suit their own personal data processing tasks. you highlight this in your choice of platforms 'getting this right', but really, these are two different mentalities, cultures, and modes of operation. not saying one is superior to the other, but square peg, round hole. and besides: many proprietary programs for unix just ship with static executables. problem solved.
curt15 7y ago
Fedora Silverblue aspires to implement read-only root for a general-purpose distro. The main cost of their implementation is that you have to reboot after installing or upgrading packages to make the changes effective.

Legogris 7y ago

Have you checked out NixOS? Everything is read-only and derived from static configuration.

solatic 7y ago
I run NixOS as a daily driver, and while I'm aware that the install media is a squashfs mount and that it's feasible to create server images where /nix/store is a squashfs mount as well. But in day-to-day use on a development machine, running nixos-rebuild switch makes a read-only root impractical, so far as I know.

AnIdiotOnTheNet 7y ago

The OSs that insisted upon scattering application files all over the hierarchy only have themselves to blame for this situation. At some point in the past 30 years thought could have been given to the idea that applications are separate from the platform they run on, but UNIX just doesn't think that way. Everything must be part of the same gigantic Goldberg-esq state so everything can catch fire and burn down at once as soon as there's a conflict of any kind. Anyway, the fix is pretty obvious: put each application in its own namespace, thus its view of "/usr" isn't the same as the immutable OS "/usr" and it is free to write whatever it wants without causing any trouble.

cat199 7y ago
> At some point in the past 30 years thought could have been given to the idea that applications are separate from the platform they run on, but UNIX just doesn't think that way. Everything must be part of the same gigantic Goldberg-esq state so everything can catch fire and burn down at once as soon as there's a conflict of any kind. this only happens if one isnt aren't managing applications coherently (e.g binary only packages managed haphazardly, like most linux binary packagers) on systems where there is a clear base+add-ons distinction (e.g. source based ports), these things happen much less often - all packages are built from a coherent source tree, and read only root is often feasable because packages only install reference files into their respective '/usr/share' area and don't muck with the 'real system' in /etc - the latter being an administrative action (e.g. package installation is a separate action from service configuration / execution)
- AnIdiotOnTheNet 7y ago
  So basically, all software has to be built from source by maintainers who are careful to make sure it doesn't conflict with other software. And people wonder why applications aren't ported to these OSs. The OS should be a platform. I should be able to build an application and distribute it to users and have it just run on that platform without involving third party middlemen and regardless of other software they have. You know what OSs accomplished this? The original Macintosh, RiscOS, DOS, and (mostly) Windows 3.1. Why is it that we can't accomplish today something we did 30 years ago?
  - cat199 7y ago
    a platform for what? a platform for 'building your system', or a platform for 'distributing and executing binaries'? the binary only distribution mentality comes from microcomputer culture, which postdates unix/mini culture and is rooted in non-technical users installing purchased 'application' programs from vendors rather than computer users (read: programmers) building their systems to suit their own personal data processing tasks. you highlight this in your choice of platforms 'getting this right', but really, these are two different mentalities, cultures, and modes of operation. not saying one is superior to the other, but square peg, round hole. and besides: many proprietary programs for unix just ship with static executables. problem solved.

curt15 7y ago

Fedora Silverblue aspires to implement read-only root for a general-purpose distro. The main cost of their implementation is that you have to reboot after installing or upgrading packages to make the changes effective.