* Olivier Crête schrieb am 04.01.12 um 18:32 Uhr:
> On Wed, 2012-01-04 at 18:12 +0100, Ulrich Mueller wrote:
> > >>>>> On Wed, 4 Jan 2012, Michał Górny wrote:
> > 
> > >> What mistakes?
> > 
> > > The mistake of introducing a pointless separation based on a rule of
> > > thumb which becomes more and more blurry over time, and hacking
> > > packages just to make it work.
> > 
> > There's really nothing pointless or blurry about this separation.
> > The FHS has a nice definition: "The contents of the root filesystem
> > must be adequate to boot, restore, recover, and/or repair the system."
> 
> The problem is that to boot a modern system, you need a shitload of
> stuff. 

To boot the system on its highest level: yes. But Linux/UNIX systems
have a concept called runlevels that can perfectly cover cases where
this "shitload of stuff" is not required.

For example, to make that FHS definition be reality there are (can
be) runlevels that will only boot a system with all basic stuff
required to mount the rootfs and make root being able to login to
the local text console. These are the things that make a unixoid
system valuable over other kind of systems.

> For example, modern network filesystems often have secure
> authentication and probably LDAP too, so that means we need to move ldap
> and openssl into / and all the dependencies. Also, anything that
> installs a udev rule needs to be in /, and the list goes on an on. Very
> soon, you have almost everything in /...

You do not need everything to make a system boot some sort of
recovery-console for example.

> 
> This rule made sense in the 80s, but it doesn't match the modern world
> anymore.

Why? The benefits to keep a system bootable and repairable is one of
the reasons why unix systems are more robust or can better be
repeaired than, lets say windows systems for example.

I do not like the idea to throw away all those benefits just because
so many (younger/newer) people do not know about the possibilities
an "old fashioned" unix system tends to have.

-Marc
-- 
8AAC 5F46 83B4 DB70 8317  3723 296C 6CCA 35A6 4134

Attachment: pgpkTWMsEkKlm.pgp
Description: PGP signature

Reply via email to