[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAPLrYEQVp3Sd7YFd27e0QfA+mu9P67QTWah1KmqiWnaMa80cmQ@mail.gmail.com>
Date: Tue, 25 Sep 2012 15:42:25 +0200
From: Daniel Cegiełka <daniel.cegielka@...il.com>
To: musl@...ts.openwall.com
Subject: Re: filesystem layout
2012/9/25 Christian Neukirchen <chneukirchen@...il.com>:
> Daniel Cegiełka <daniel.cegielka@...il.com> writes:
>
>> @vision of the new platform
>>
>> http://sta.li/filesystem
>>
>> stali from http://suckless.org/ proposes an alternative filesystem
>> scheme. It gives clear organization of the system... but not
>> compatible with FHS. What do you think of this solution? Sabotage
>> distro also has its own concept...
>
> Sabotage's idea was essentially a symlink /usr -> / (and that came from
> Hurd).
>
> So far, the only good reason not to do that was that it's easier to put
> /usr on a NFS shared among multiple hosts.
Right arguments.
/usr and NFS - I think more to move to the /bin what is currently in
the "base" system and placed in /usr/bin and /usr/sbin. So I would see
it this way that, for example consolidates all of your obase stuff in
/bin and /sbin (admin tools and daemons).. and a heavy things you can
keep in the /opt or /usr or anything... like NFS based tree.
FHS solutions was useful when the newest supercomputer was slower than
today's calculators.. disk space limited etc... we have a weak reason
to still keep system tools in a separated /bin and /usr/bin etc. if
they belong to base system.
> Regarding the stali idea, I don't think it is useful to make /devel
> seperate (e.g. sabotage had development tools in a seperate set, but
> installed them into /bin as well).
It's not a problem. This can be done by gcc-spec file etc.
Daniel
> /lib/exec is not useful either. Daemons should go to /bin, programs
> strictly for internal purporses can go to /lib/$pkgname/.
> (This works well in Arch already.)
>
> --
> Christian Neukirchen <chneukirchen@...il.com> http://chneukirchen.org
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
