filesystem layout

filesystem layout

[Daniel Cegiełka]

@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...

Daniel

Re: filesystem layout

[Luca Barbato]

On 09/25/2012 11:58 AM, Daniel Cegiełka wrote:
> @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...

I commend their idea of removing dbus and implementing bluez w/out it.

Hopefully a libc wouldn't require a specific fs layout.

lu

Re: filesystem layout

[Daniel Cegiełka]

> I commend their idea of removing dbus and implementing bluez w/out it.
>
> Hopefully a libc wouldn't require a specific fs layout.
>
> lu

but I would see /sbin and /lib/exec

/bin - all executables
/sbin - perm: 700
/boot - all boot files
/dev - devices
/etc - system configuration
/lib - all lib*.so
/lib/exec - instead /usr/libexec
/opt
/svc - services
/home - user directories
/root - the root home
/var - spool, run, log, cache
/share - man pages, locales, dependencies
/devel - development environment
/devel/include
/devel/lib - all lib*.a
/devel/ports - ports, packages
/deve/distfiles - packed sources
/devel/src - kernel etc.


/devel can be easily separated from the system and then the / will be
very small.

daniel

Re: filesystem layout

[Luca Barbato]

On 09/25/2012 01:09 PM, Daniel Cegiełka wrote:
>> I commend their idea of removing dbus and implementing bluez w/out it.
>>
>> Hopefully a libc wouldn't require a specific fs layout.
>>
>> lu
> 
> but I would see /sbin and /lib/exec
> 

As long /etc contains the files the libc advanced stuff requires I guess
everybody is fine.

Their minimalistic approach is nice but just for their specific purposes.

Static linking could be dangerous from a security/maintainance
standpoint, but that is me looking at the specific scenarios in which
Gentoo shines.

lu

Re: filesystem layout

[Kurt H Maier]

On Tue, Sep 25, 2012 at 01:22:44PM +0200, Luca Barbato wrote:
> 
> Static linking could be dangerous from a security/maintainance
> standpoint, but that is me looking at the specific scenarios in which
> Gentoo shines.


This is a common myth.  lazy or ineffective system management is a
danger regardless of the linking type.

Re: filesystem layout

[Szabolcs Nagy]

* Daniel Cegie?ka <daniel.cegielka@gmail.com> [2012-09-25 13:09:05 +0200]:
> but I would see /sbin and /lib/exec
> 
...


i think such filesystem changes should
be tried out first

because it may turn out that lot of
tools have hardcoded /usr path in them

that may be solvable with ln -s / /usr
but that may have other issues

i would be interested in a system that
simplifies the fs layout, but i suspect
that you cannot gain much there without
breaking many legacy things

Re: filesystem layout

[Luca Barbato]

On 09/25/2012 01:26 PM, Kurt H Maier wrote:
> On Tue, Sep 25, 2012 at 01:22:44PM +0200, Luca Barbato wrote:
>>
>> Static linking could be dangerous from a security/maintainance
>> standpoint, but that is me looking at the specific scenarios in which
>> Gentoo shines.
> 
> 
> This is a common myth.  lazy or ineffective system management is a
> danger regardless of the linking type.

Spending lots of time unbundling dependencies from packages so they
could use the up-to-date shared version might bring you to have a bias.

Any system management that force you to reinstall all your packages
because zlib had a bug doesn't seem efficient.

lu

Re: filesystem layout

[Daniel Cegiełka]

2012/9/25 Luca Barbato <lu_zero@gentoo.org>:
> On 09/25/2012 01:26 PM, Kurt H Maier wrote:
>> On Tue, Sep 25, 2012 at 01:22:44PM +0200, Luca Barbato wrote:
>>>
>>> Static linking could be dangerous from a security/maintainance
>>> standpoint, but that is me looking at the specific scenarios in which
>>> Gentoo shines.
>>
>>
>> This is a common myth.  lazy or ineffective system management is a
>> danger regardless of the linking type.
>
> Spending lots of time unbundling dependencies from packages so they
> could use the up-to-date shared version might bring you to have a bias.
>
> Any system management that force you to reinstall all your packages
> because zlib had a bug doesn't seem efficient.

dynamic linking itself can generate problems:

http://www.catonmat.net/blog/ldd-arbitrary-code-execution/

daniel

Re: filesystem layout

[Luca Barbato]

On 09/25/2012 01:58 PM, Daniel Cegiełka wrote:
> dynamic linking itself can generate problems:
> 
> http://www.catonmat.net/blog/ldd-arbitrary-code-execution/

Less likely than a commonly used utility lib having flaws and needing to
be replaced all over instead of a single place ^^;

lu

Re: filesystem layout

[Kurt H Maier]

On Tue, Sep 25, 2012 at 01:35:45PM +0200, Luca Barbato wrote:
> On 09/25/2012 01:26 PM, Kurt H Maier wrote:
> Spending lots of time unbundling dependencies from packages so they
> could use the up-to-date shared version might bring you to have a bias.

My bias is toward effective, practical, convenient solutions.

> Any system management that force you to reinstall all your packages
> because zlib had a bug doesn't seem efficient.

Not being able to run a five-year-old binary because of versioned
libraries is not efficient.  Package upgrades are easy.  They're even
easier when their contents are statically linked.

Re: filesystem layout

[Christian Neukirchen]

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.

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).
/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

Re: filesystem layout

[Luca Barbato]

On 09/25/2012 02:50 PM, Kurt H Maier wrote:
> My bias is toward effective, practical, convenient solutions.

So is mine, thus I use a statically linked multicall binary when makes
sense to and I use shared libraries when is worthy.

lu

Re: filesystem layout

[Christian Neukirchen]

Luca Barbato <lu_zero@gentoo.org> writes:

> On 09/25/2012 01:26 PM, Kurt H Maier wrote:
>> On Tue, Sep 25, 2012 at 01:22:44PM +0200, Luca Barbato wrote:
>>>
>>> Static linking could be dangerous from a security/maintainance
>>> standpoint, but that is me looking at the specific scenarios in which
>>> Gentoo shines.
>> 
>> 
>> This is a common myth.  lazy or ineffective system management is a
>> danger regardless of the linking type.
>
> Spending lots of time unbundling dependencies from packages so they
> could use the up-to-date shared version might bring you to have a bias.
>
> Any system management that force you to reinstall all your packages
> because zlib had a bug doesn't seem efficient.

Note that you need to *restart all programs using zlib* anyway.
So what's the difference between

tar xzpf base.tar.gz
and
tar xzpf zlib.tar.gz

?
-- 
Christian Neukirchen  <chneukirchen@gmail.com>  http://chneukirchen.org

Re: filesystem layout

[Luca Barbato]

On 09/25/2012 03:09 PM, Christian Neukirchen wrote:
> Luca Barbato <lu_zero@gentoo.org> writes:
> 
>> On 09/25/2012 01:26 PM, Kurt H Maier wrote:
>>> On Tue, Sep 25, 2012 at 01:22:44PM +0200, Luca Barbato wrote:
>>>>
>>>> Static linking could be dangerous from a security/maintainance
>>>> standpoint, but that is me looking at the specific scenarios in which
>>>> Gentoo shines.
>>>
>>>
>>> This is a common myth.  lazy or ineffective system management is a
>>> danger regardless of the linking type.
>>
>> Spending lots of time unbundling dependencies from packages so they
>> could use the up-to-date shared version might bring you to have a bias.
>>
>> Any system management that force you to reinstall all your packages
>> because zlib had a bug doesn't seem efficient.
> 
> Note that you need to *restart all programs using zlib* anyway.
> So what's the difference between
> 
> tar xzpf base.tar.gz
> and
> tar xzpf zlib.tar.gz

I guess the whole thing is derailing. You assume that you have a daemon
or some kind of permanent program, I'm considering all the programs,
permanent and transient.

Even in your scenario

sys-libs/zlib-1.2.5.1-r2: 31 files, 16 non-files, 767.242 KB

Updating zlib would take less than 1mb uncompressed.

Updating a whole system few order of magnitude.

Again, we are derailing the purpose of this mailing list.

The original question could be summarized as "would musl require a
specific filesystem layout or non-fhs could be used easily?" and the
answer IMHO is that there isn't much in libc that requires a specific
layout.

lu

Re: filesystem layout

[Daniel Cegiełka]

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

Re: filesystem layout

[Daniel Cegiełka]

2012/9/25 Luca Barbato <lu_zero@gentoo.org>:
> On 09/25/2012 03:09 PM, Christian Neukirchen wrote:
>> Luca Barbato <lu_zero@gentoo.org> writes:
>>
>>> On 09/25/2012 01:26 PM, Kurt H Maier wrote:
>>>> On Tue, Sep 25, 2012 at 01:22:44PM +0200, Luca Barbato wrote:
>>>>>
>>>>> Static linking could be dangerous from a security/maintainance
>>>>> standpoint, but that is me looking at the specific scenarios in which
>>>>> Gentoo shines.
>>>>
>>>>
>>>> This is a common myth.  lazy or ineffective system management is a
>>>> danger regardless of the linking type.
>>>
>>> Spending lots of time unbundling dependencies from packages so they
>>> could use the up-to-date shared version might bring you to have a bias.
>>>
>>> Any system management that force you to reinstall all your packages
>>> because zlib had a bug doesn't seem efficient.
>>
>> Note that you need to *restart all programs using zlib* anyway.
>> So what's the difference between
>>
>> tar xzpf base.tar.gz
>> and
>> tar xzpf zlib.tar.gz
>
> I guess the whole thing is derailing. You assume that you have a daemon
> or some kind of permanent program, I'm considering all the programs,
> permanent and transient.
>
> Even in your scenario
>
> sys-libs/zlib-1.2.5.1-r2: 31 files, 16 non-files, 767.242 KB
>
> Updating zlib would take less than 1mb uncompressed.
>
> Updating a whole system few order of magnitude.

not the whole :)

scanelf -qyRF '%p %n' /bin/ | grep libz.so

This can be done automatically by the installer (package manager).

> Again, we are derailing the purpose of this mailing list.

yup.

Daniel

Re: filesystem layout

[Nathan McSween]

Well here's my peanuts on this bikeshed:

/usr/bin - binaries
/usr/sbin - static binaries
/usr/lib/<triplet> - architecture dependent binary libraries
/usr/lib/<triplet>/<pkg> - architecture dependent binary package libraries
/usr/sub/<triplet?>/<pkg> - gratuitous libexec renaming, short for 
subprocess sublibrary, etc
/usr/int/<arch> - arch dependent includes
/usr/share/int - arch independent includes
/usr/share/sub - arch independent sub...
/var/srv/<pkg> - package specific variable data such as apache, git, etc
/run - runtime data

I would have to look at debain multiarch more.

Re: filesystem layout

[Rich Felker]

On Tue, Sep 25, 2012 at 12:53:55PM +0200, Luca Barbato wrote:
> On 09/25/2012 11:58 AM, Daniel Cegiełka wrote:
> > @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...
> 
> I commend their idea of removing dbus and implementing bluez w/out it.

I'm quite interested in this. Do they have it working?

> Hopefully a libc wouldn't require a specific fs layout.

From a libc standpoint, the only thing I have to say is that I'm
against any gratuitous filesystem layout changes that would force libc
to be aware of additional variants; that's just gratuitous bloat and
incompatibility. In particular, /dev, /proc, /etc, /tmp, /bin/sh, and
/lib/ld* should not move.

Otherwise, the fs layout is rather irrelevant to libc. As discussed
before, non-libc topics related to this community's projects/ideas are
on-topic on this list, but I also think fs layout is mostly irrelevant
to the "new platform" thread as well. It wasn't my intent to impose
any particular filesystem policy with the new platform except perhaps
some unix socket paths, etc. that would be part of the "api".

Where the fs layout topic is interesting is when you're designing a
distro or want to make binary packages that fit into an existing fs
layout. I don't mind if that's discussed here, but it's getting mildly
off-topic.

Rich

Re: filesystem layout

[Daniel Bainton]

On 25 September 2012 20:44, Rich Felker <dalias@aerifal.cx> wrote:
> On Tue, Sep 25, 2012 at 12:53:55PM +0200, Luca Barbato wrote:
>> On 09/25/2012 11:58 AM, Daniel Cegiełka wrote:
>> > @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...
>>
>> I commend their idea of removing dbus and implementing bluez w/out it.
>
> I'm quite interested in this. Do they have it working?

It's just an idea of what they want, nobody has even started working on it yet.

--
Daniel