From: "Daniel Cegiełka" <daniel.cegielka@gmail.com>
To: musl@lists.openwall.com
Subject: Re: filesystem layout
Date: Tue, 25 Sep 2012 15:42:25 +0200 [thread overview]
Message-ID: <CAPLrYEQVp3Sd7YFd27e0QfA+mu9P67QTWah1KmqiWnaMa80cmQ@mail.gmail.com> (raw)
In-Reply-To: <87haqmgsts.fsf@gmail.com>
2012/9/25 Christian Neukirchen <chneukirchen@gmail.com>:
> Daniel Cegiełka <daniel.cegielka@gmail.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@gmail.com> http://chneukirchen.org
next prev parent reply other threads:[~2012-09-25 13:42 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-09-25 9:58 Daniel Cegiełka
2012-09-25 10:53 ` Luca Barbato
2012-09-25 11:09 ` Daniel Cegiełka
2012-09-25 11:22 ` Luca Barbato
2012-09-25 11:26 ` Kurt H Maier
2012-09-25 11:35 ` Luca Barbato
2012-09-25 11:58 ` Daniel Cegiełka
2012-09-25 12:31 ` Luca Barbato
2012-09-25 12:50 ` Kurt H Maier
2012-09-25 13:08 ` Luca Barbato
2012-09-25 13:09 ` Christian Neukirchen
2012-09-25 13:41 ` Luca Barbato
2012-09-25 13:51 ` Daniel Cegiełka
2012-09-25 11:35 ` Szabolcs Nagy
2012-09-25 17:44 ` Rich Felker
2012-09-26 8:13 ` Daniel Bainton
2012-09-25 13:01 ` Christian Neukirchen
2012-09-25 13:42 ` Daniel Cegiełka [this message]
2012-09-25 17:40 ` Nathan McSween
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CAPLrYEQVp3Sd7YFd27e0QfA+mu9P67QTWah1KmqiWnaMa80cmQ@mail.gmail.com \
--to=daniel.cegielka@gmail.com \
--cc=musl@lists.openwall.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.vuxu.org/mirror/musl/
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).