* filesystem layout @ 2012-09-25 9:58 Daniel Cegiełka 2012-09-25 10:53 ` Luca Barbato ` (2 more replies) 0 siblings, 3 replies; 19+ messages in thread From: Daniel Cegiełka @ 2012-09-25 9:58 UTC (permalink / raw) To: musl @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 ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: filesystem layout 2012-09-25 9:58 filesystem layout Daniel Cegiełka @ 2012-09-25 10:53 ` Luca Barbato 2012-09-25 11:09 ` Daniel Cegiełka 2012-09-25 17:44 ` Rich Felker 2012-09-25 13:01 ` Christian Neukirchen 2012-09-25 17:40 ` Nathan McSween 2 siblings, 2 replies; 19+ messages in thread From: Luca Barbato @ 2012-09-25 10:53 UTC (permalink / raw) To: musl 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 ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: filesystem layout 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:35 ` Szabolcs Nagy 2012-09-25 17:44 ` Rich Felker 1 sibling, 2 replies; 19+ messages in thread From: Daniel Cegiełka @ 2012-09-25 11:09 UTC (permalink / raw) To: musl > 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 ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: filesystem layout 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 ` Szabolcs Nagy 1 sibling, 1 reply; 19+ messages in thread From: Luca Barbato @ 2012-09-25 11:22 UTC (permalink / raw) To: musl 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 ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: filesystem layout 2012-09-25 11:22 ` Luca Barbato @ 2012-09-25 11:26 ` Kurt H Maier 2012-09-25 11:35 ` Luca Barbato 0 siblings, 1 reply; 19+ messages in thread From: Kurt H Maier @ 2012-09-25 11:26 UTC (permalink / raw) To: musl 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. ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: filesystem layout 2012-09-25 11:26 ` Kurt H Maier @ 2012-09-25 11:35 ` Luca Barbato 2012-09-25 11:58 ` Daniel Cegiełka ` (2 more replies) 0 siblings, 3 replies; 19+ messages in thread From: Luca Barbato @ 2012-09-25 11:35 UTC (permalink / raw) To: musl 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 ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: filesystem layout 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:09 ` Christian Neukirchen 2 siblings, 1 reply; 19+ messages in thread From: Daniel Cegiełka @ 2012-09-25 11:58 UTC (permalink / raw) To: musl 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 ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: filesystem layout 2012-09-25 11:58 ` Daniel Cegiełka @ 2012-09-25 12:31 ` Luca Barbato 0 siblings, 0 replies; 19+ messages in thread From: Luca Barbato @ 2012-09-25 12:31 UTC (permalink / raw) To: musl 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 ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: filesystem layout 2012-09-25 11:35 ` Luca Barbato 2012-09-25 11:58 ` Daniel Cegiełka @ 2012-09-25 12:50 ` Kurt H Maier 2012-09-25 13:08 ` Luca Barbato 2012-09-25 13:09 ` Christian Neukirchen 2 siblings, 1 reply; 19+ messages in thread From: Kurt H Maier @ 2012-09-25 12:50 UTC (permalink / raw) To: musl 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. ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: filesystem layout 2012-09-25 12:50 ` Kurt H Maier @ 2012-09-25 13:08 ` Luca Barbato 0 siblings, 0 replies; 19+ messages in thread From: Luca Barbato @ 2012-09-25 13:08 UTC (permalink / raw) To: musl 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 ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: filesystem layout 2012-09-25 11:35 ` Luca Barbato 2012-09-25 11:58 ` Daniel Cegiełka 2012-09-25 12:50 ` Kurt H Maier @ 2012-09-25 13:09 ` Christian Neukirchen 2012-09-25 13:41 ` Luca Barbato 2 siblings, 1 reply; 19+ messages in thread From: Christian Neukirchen @ 2012-09-25 13:09 UTC (permalink / raw) To: musl 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 ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: filesystem layout 2012-09-25 13:09 ` Christian Neukirchen @ 2012-09-25 13:41 ` Luca Barbato 2012-09-25 13:51 ` Daniel Cegiełka 0 siblings, 1 reply; 19+ messages in thread From: Luca Barbato @ 2012-09-25 13:41 UTC (permalink / raw) To: musl 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 ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: filesystem layout 2012-09-25 13:41 ` Luca Barbato @ 2012-09-25 13:51 ` Daniel Cegiełka 0 siblings, 0 replies; 19+ messages in thread From: Daniel Cegiełka @ 2012-09-25 13:51 UTC (permalink / raw) To: musl 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 ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: filesystem layout 2012-09-25 11:09 ` Daniel Cegiełka 2012-09-25 11:22 ` Luca Barbato @ 2012-09-25 11:35 ` Szabolcs Nagy 1 sibling, 0 replies; 19+ messages in thread From: Szabolcs Nagy @ 2012-09-25 11:35 UTC (permalink / raw) To: musl * 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 ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: filesystem layout 2012-09-25 10:53 ` Luca Barbato 2012-09-25 11:09 ` Daniel Cegiełka @ 2012-09-25 17:44 ` Rich Felker 2012-09-26 8:13 ` Daniel Bainton 1 sibling, 1 reply; 19+ messages in thread From: Rich Felker @ 2012-09-25 17:44 UTC (permalink / raw) To: musl 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 ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: filesystem layout 2012-09-25 17:44 ` Rich Felker @ 2012-09-26 8:13 ` Daniel Bainton 0 siblings, 0 replies; 19+ messages in thread From: Daniel Bainton @ 2012-09-26 8:13 UTC (permalink / raw) To: musl 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 ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: filesystem layout 2012-09-25 9:58 filesystem layout Daniel Cegiełka 2012-09-25 10:53 ` Luca Barbato @ 2012-09-25 13:01 ` Christian Neukirchen 2012-09-25 13:42 ` Daniel Cegiełka 2012-09-25 17:40 ` Nathan McSween 2 siblings, 1 reply; 19+ messages in thread From: Christian Neukirchen @ 2012-09-25 13:01 UTC (permalink / raw) To: musl 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 ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: filesystem layout 2012-09-25 13:01 ` Christian Neukirchen @ 2012-09-25 13:42 ` Daniel Cegiełka 0 siblings, 0 replies; 19+ messages in thread From: Daniel Cegiełka @ 2012-09-25 13:42 UTC (permalink / raw) To: musl 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 ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: filesystem layout 2012-09-25 9:58 filesystem layout Daniel Cegiełka 2012-09-25 10:53 ` Luca Barbato 2012-09-25 13:01 ` Christian Neukirchen @ 2012-09-25 17:40 ` Nathan McSween 2 siblings, 0 replies; 19+ messages in thread From: Nathan McSween @ 2012-09-25 17:40 UTC (permalink / raw) To: musl 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. ^ permalink raw reply [flat|nested] 19+ messages in thread
end of thread, other threads:[~2012-09-26 8:13 UTC | newest] Thread overview: 19+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2012-09-25 9:58 filesystem layout 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 2012-09-25 17:40 ` Nathan McSween
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).