Systemd 245 Shipping Soon With Systemd-Homed, Systemd-Repart Partitioner

[skeevy420]

several _adjective

• being more than two but fewer than many in number or kind

[jacob]

In case you didn't understand, this isn't a stylistic choice, it is a standard for basic application inter-interoperability. Changing it is a pain in the ass just as changing Xorg to something else (Wayland in our case) is a pain in the ass.
Or maybe more as now you need to hack all applications you ship to use the new folders you have defined, and all documentation now is wrong as stuff is no more where it was.

Nope. Well-developed software should not expect to be installed at any given absolute path. The fact that historically Unix-style software used to have a hard-coded prefix (in the best of cases, definable at compile-time) is a deficiency, not something to perpetuate or accept as normal. Plus, with custom namespaces and containerisation, it's not really a problem anyway.

Also why the fuck is your user even caring about what is in the root of the drive? They have their home folder to store their stuff and if your system does not have decent GUIs to change all relevant settings, your distro is garbage. There is a reason if GNOME filemanager hides that by default.

What is on the root of the drive should be explicit and self-evident for the same reason that any other information presented by the OS should be explicit and self-evident, not allegiant to some limitations and misguided short-sighted decisions made fifty years ago. The root of the drive should basically contain /system, /home, /apps and /settings. Of course by /settings I don't mean /etc with its hodgepodge of text files with arbitrary syntaxes but a structured key-value data store (whether JSON, YAML, binary or other is an implementation detail).

[xinorom]

Nope. Well-developed software should not expect to be installed at any given absolute path. The fact that historically Unix-style software used to have a hard-coded prefix (in the best of cases, definable at compile-time) is a deficiency, not something to perpetuate or accept as normal. Plus, with custom namespaces and containerisation, it's not really a problem anyway.

What is on the root of the drive should be explicit and self-evident for the same reason that any other information presented by the OS should be explicit and self-evident, not allegiant to some limitations and misguided short-sighted decisions made fifty years ago. The root of the drive should basically contain /system, /home, /apps and /settings. Of course by /settings I don't mean /etc with its hodgepodge of text files with arbitrary syntaxes but a structured key-value data store (whether JSON, YAML, binary or other is an implementation detail).

Oh shit, watch out guys. We've got the next Steve Jobs over here...

[jacob]

Oh shit, watch out guys. We've got the next Steve Jobs over here...

We don't but we need one. Or at least the part of Steve Jobs that could understand better than most what end-users actually expect from their computers.

[lumks]

/bin - What is bin? Recicle bin or binaries?

Its binary, and should only be a link to /usr/bin or not even there anymore.

/cdrom ? I have a DVD-writer.

What shitty distro does have a this in the root?

/etc ? What is this? Et cetera? Shouldn't be more clear if it was named configurations or settings ?

It's Et Cetera, because it's not for configurations or setting, but "everything that does not fit somewhere else". That heavy focus on local configs and settings is just a recent development. But here I am with you. It would be nice to have a place for local configs, made by the Admin that overwrite the pkgmanagers configs.

/usr ? Seriously, being so lazy on the root directories for one letter ?

usr is short for "Unix System Resources". So what letter?

I find much more clear and easier the windows filesytem with:
Windows
Program Files
Users

Because on Windows every folder is an "etc". Windows is for everything (Binary, settings/configs, artwork, libs, etc), Program Files contains also everything, and of course Users also contains everything., even the root level "c:" contains from apps, to configs everything. Windows does not have a strict hierarchy

And this is only one place where LInux is such a mess, there are many others that I saw.

The FSH is probably one of the only things thats quite good on Linux. Just because you do not understand it wont change this. Please read a bit about it.

[aht0]

It's Et Cetera, because it's not for configurations or setting, but "everything that does not fit somewhere else". That heavy focus on local configs and settings is just a recent development. But here I am with you. It would be nice to have a place for local configs, made by the Admin that overwrite the pkgmanagers configs.

/usr/local/etc ? The place exists, just persuade some distributor to make use of it.

[lumks]

/usr/local/etc ? The place exists, just persuade some distributor to make use of it.

Thats because /usr/local is for your own stuff, like things you build from source. Nothing that should be touched by the packagemanager. The one that is missing here would be /usr/etc, maybe even with better name.

http://www.pathname.com/fhs/pub/fhs-2.3.html#USRLOCALLOCALHIERARCHY

[xinorom]

People who quote the FHS are cringe. It's the most irrelevant "standard" there is. The parts that people actually follow predate the standard by a long time and the parts it invented, everyone just ignores.

[aht0]

People with attitude like yours are the root cause for inter-platform compatibility issues. Find something to do with your life, instead of mucking in things best left alone.

[skeevy420]

Thats because /usr/local is for your own stuff, like things you build from source. Nothing that should be touched by the packagemanager. The one that is missing here would be /usr/etc, maybe even with better name.

http://www.pathname.com/fhs/pub/fhs-...LOCALHIERARCHY

The problem with /usr/etc is it doesn't jive with read-only roots that treat everything under /usr as read-only.

/usr/etc would be a good place for the default configs and /var/etc could be for user overrides (meaning the sys admin and not Karen in HR).

The only problem is that may or may not work with systemd. Whenever you "systemctl enable" crap it tweaks stuff under /etc/systemd so all of systemd would need to be relocated to /srv, or /var/srv using the OS Tree standard, so that read-write is guaranteed. Frankly, that applies to any other init system and service manager that uses /etc for configuration so it's not really just a systemd problem and more a problem of "everyone dumping crap into /etc and not following the XDG standards".