Finding a Successor to the FHS(lwn.net) |
Finding a Successor to the FHS(lwn.net) |
Are CLI tools or low-level, privileged software (e.g. anything that requires root) also distributed using flatpak or snap these days?
Flatpak hasn't really taken the same path, it doesn't have much utility for anything other than desktop apps.
The problem is that systemd evokes some pretty visceral negative reactions in people. I still have mixed feelings about it, but, by and large, I encounter minimal real-world issues with it. Just because systemd has decided to do something that violates the older FHS3/4 standards, doesn't automatically make it a bad thing. Maybe what they're doing is a better way. Maybe not.
The most obvious example that comes to mind is /usr/lib/os-release, which file-hierarchy(7) indicates should actually be in /usr/share/os-release.
https://jdebp.uk/FGA/slashpackage.html or some derivative would be OK, too.
* https://man.openbsd.org/hier
* https://man.netbsd.org/hier.7
* https://man.freebsd.org/cgi/man.cgi?query=hier&sektion=7
* https://man.dragonflybsd.org/?command=hier§ion=7
There was a long time when the Linux world held /opt in disfavour, because officially it required either a stock market ticker name or some other corporate identity to make a subdirectory legitimate. You can still see traces of this in the Solaris descendant operating systems, where pkginfo(5) talks about package names using corporate stock ticker names.
* https://illumos.org/man/5/pkginfo
/opt/SUNW* used to be a very familiar thing to a lot of people.
Maybe enough time has passed for anti-corporate memory to fade. Maybe there's enough corporate backing in the Linux world now to resurrect the idea regardless.
Maybe /opt/RHT* is the shape of things to come. (-:
I've never over the years seen the systemd people advocate for /opt, though.
We need:
- query-able storage, because search&narrow is the current way of accessing information and collecting/transcluding data is the way to go;
- easy storage management, the "rampant layer violation" of zfs we really need;
- integration of such storage to the software stack, from the OS to single packages, it's a nonsense having to "spread" archives in a taxonomy to deploy them or downloading archives to be unpacked as well for updates when we have send-able filesystems (zfs send of snapthots) and binary diff (from a snapshot "tagged version" of a fs-package to another, sent over internet).
Unfortunately we need operation people together with devs and nowadays operation is nearly disappeared. Devs alone can't understand what we need, they can't go beyond their desktops in a mass large enough to avoid a positive evolution.
Except in zfs you have to think if you really want that device in that pool or that vdev. I use btrfs, slow and kinda unsafe, specifically because you just specify raid1c2/raid1c3/raid1c4 and it kind of survives c-1 dead disks (until you run out of disk space and everything goes to flames).
> - integration of such storage to the software stack, from the OS to single packages, it's a nonsense having to "spread" archives in a taxonomy to deploy them or downloading archives to be unpacked as well for updates when we have send-able filesystems (zfs send of snapthots) and binary diff (from a snapshot "tagged version" of a fs-package to another, sent over internet).
We (kinda, for some very generous definitions of) have that in composefs? But I still sense even with that, you still want some resemblance of sanity in your indivual layers.
No. freedesktop.org is the place where standards go to die and CADT development takes place.
But sure, absolutely, an installer should prompt the user for an install location, and I think a default under /opt is probably among the best defaults possible, if we consider installing outside $HOME to be reasonable.