Me again
So I am going to quote Laurent a bit out of order, sorry about
that, but it seems the best way to explain things:
> >Now as for other assertions in this thread that the FHS itself is
> >obsolete and violations of it should not be considered a bad thing, just
> >no.
>
> I don't think anyone said that.
And then in another mail the same Laurent says:
> Some of the original design decisions for the Unix directory structure,
> that you still find in the FHS today, never made sense. Most of them made
> sense at the time, but are obsoleted by today's needs. And some of them
> still make sense today.
... confusing - it is unclear if he is arguing that departures from the
standard should be entertained or not.
My argument is that the FHS should be followed, particularly for
devuan - the way I see it the motivation to work on devuan is that
debian has lost the plot and is making large-scale and ill-conceived
changes, and there are enough people who are keen on a classical unix
init/desktop/filesystem to fork to retain this.
Over to Laurent again:
> >The FHS was carefully designed
>
> Stopped reading there.
I think that is the problem right there.
Maybe design is the incorrect phrase, maybe say "carefully evolved".
There is a view that large complex systems do not get designed
in one go, they get built incrementally - and that the collective
experiences of many years of use are encoded in it.
Specific to the unix world, I think it was Henry Spencer who
said "Those who do not understand unix are doomed to re-invent
it[, poorly]".
And lets see this in action: The original unix approach was to
have a small/fast filesystem with just the essentials on it to
get the system going, so that the rest could be gotten somewhere
else, maybe /usr (ro) of the network and say /home (rw) from
some other server.
And now we have the inexperienced but loud-mouthed crowd show up and
tell us that the world has changed, that this isn't needed, disks
are all large and fast, nobody uses NFS and get with the times,
and /bin and /usr/bin get mushed together. All very modern.
Except we now have an initramfs which, big surprise, is a small fast
filesystem there to get the system going, so that the rest of
of the system can be gotten via, say raid/lvm over iSCSI - over
the network. The more things change the more they stay the same...
Except initrds are a poor imitation: Their layout varies wildly between
distributions, they are usually hidden from view, they can easily
become out of sync, they duplicate binaries and modules unnecessarily,
require a brittle pivot_root operation (amongst other deficiencies).
Yes I know *why* they exist - the bootloader loads them rather than
the kernel. I am not saying that there is absolutely no use for them...
But in a sane world there would be and option to have initrd
and {/{bin,lib,sbin} be the same - there would be no pivot_root.
It would require some care - /etc (and maybe /dev) would have to be
their own fileystems, and there would be a command called sync-initrd
which would take the root filesystem and build the initrd image to save
in /boot - essential kernel modules would live in /lib, the rest
would be symlinks into /usr/lib/modules, or modprobe would
use PATH concepts. And everybody would understand exactly why /bin
and /usr/bin are separate entities, and the cost of bloating up /sbin
or /bin would be obvious in increased bootup times and memory use.
Maybe devuan, once it it has solved all the other debian problems can
tackle this :)
More generally: The way I understand it, devuan is a reaction to
radical changes in debian and most other linux distributions - if
we take the classical/conservative/reactionary/careful tack, then
sticking to the FHS is consistent with that approach. People who want
to try new!exiting!web2.0! stuff have no shortage of other
distributions to try. Pity for them is that just when they have
gotten used to it, there will be more new!exiting! stuff, cause
last years filesystem hierarchy is obsolete too - upgrade treadmill
for the win.
regards
marc
_______________________________________________
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
