Mailing List Archive

On Fri, 2012-01-06 at 08:44 +0800, Patrick Lauer wrote:
> On 01/06/12 05:26, Olivier Crête wrote:
> [snip]
> > The only thing I see them sacrificing is loose coupling, they provide
> > more functionality than any other init system, more correctness
> > (seriously, did you ever read most init scripts out there?), more well
> > defined behavior (all systemd systems boot exactly the same), more
> > stability (I'll claim that Lennart's C is better than any of the
> > boot-time shell scripts I've seen) and well understandability depends
> > who much you can understand C. Probably a bit less understandable for
> > sysadmins, but since they can just play with config files, it's
> > probably easier to understand in the end (and much less prone to
> > breaking than mucking around shell scripts).
> As you apparently have no idea what a sysadmin does I'd appreciate it if
> people like you didn't try to guess what would make things better and
> instead listened to people that have more than their desktop to run.
> (Hint: It's not pressing reset buttons)

I know what they do.. play in random scripts until whatever they're
trying to hack together it seems to work, because oh well, its just a
one time thing.. and then when stuff breaks they call Red Hat's support
line.

> Given the choice between a single line of shell ( cat "$urandom_seed" >
> /dev/urandom ) or 145 lines of undocumented C (which, if naively
> modified by me, might just make systemd segfault) ... there is no choice.

Actually, you don't have to do that, systemd does it for you and takes
care of all the annoying details [1].

That said, you can trivially disable systemd-random-seed-save.service
and systemd-random-seed-load.service and instead write a unit file that
runs whatever you want. You don't HAVE to do any C to run stuff from
systemd, but it does provide many things written in C that are much more
solid than the shell equivalents.

> I do agree with you on one point - most init scripts are really bad
> code, but that doesn't mean shell is bad, it means that you need to
> educate people and file bugs. I've laughed at SLES' /etc/bashrc, I read
> most of upstart and wondered how ... why ... is it can be drunk tiem?
> Still that doesn't mean that rewriting it in bad C is in any way more
> agreeable, and you just made debugging exquisitely painful. Yey.

The big reason for C vs shell scripts is that the type of people who
write them are not the same.. The type of people who write shell scripts
tend to hack together stuff until it works. The people who write C tend
to think about the problem for a long time and then write a complete
solution that tries to take into account all of the possible error
scenarios.

[1] http://cgit.freedesktop.org/systemd/tree/src/random-seed.c

--
Olivier Crête
tester@gentoo.org
Gentoo Developer

* Olivier Crête schrieb am 06.01.12 um 03:15 Uhr:
> On Fri, 2012-01-06 at 08:44 +0800, Patrick Lauer wrote:
> > On 01/06/12 05:26, Olivier Crête wrote:
> > [snip]
> > > The only thing I see them sacrificing is loose coupling, they provide
> > > more functionality than any other init system, more correctness
> > > (seriously, did you ever read most init scripts out there?), more well
> > > defined behavior (all systemd systems boot exactly the same), more
> > > stability (I'll claim that Lennart's C is better than any of the
> > > boot-time shell scripts I've seen) and well understandability depends
> > > who much you can understand C. Probably a bit less understandable for
> > > sysadmins, but since they can just play with config files, it's
> > > probably easier to understand in the end (and much less prone to
> > > breaking than mucking around shell scripts).
> > As you apparently have no idea what a sysadmin does I'd appreciate it if
> > people like you didn't try to guess what would make things better and
> > instead listened to people that have more than their desktop to run.
> > (Hint: It's not pressing reset buttons)
>
> I know what they do.. play in random scripts until whatever they're
> trying to hack together it seems to work, because oh well, its just a
> one time thing.. and then when stuff breaks they call Red Hat's support
> line.

Oh, Are you really telling that the freedom of being able to "play
in random scripts" is a bad thing and that its better to make this
impossible by hiding everything in compiled binaries?

To me its kind of arrogant to think that the "everage admin" is too
stupid to handle her system properly. Sure there are admins that do
bad "one time things" with scripts. So what. Is this a reason to
prevent anyone from doing so?

Do you think there are also good admins, that are able to FIX a bug
in a script?

And about RedHat support: They PAY for being able USE it!

> > Given the choice between a single line of shell ( cat "$urandom_seed" >
> > /dev/urandom ) or 145 lines of undocumented C (which, if naively
> > modified by me, might just make systemd segfault) ... there is no choice.
>
> Actually, you don't have to do that, systemd does it for you and takes
> care of all the annoying details [1].

Yeah. And systemd will be 100% bugfree! Always! Granted!


> That said, you can trivially disable systemd-random-seed-save.service
> and systemd-random-seed-load.service and instead write a unit file that
> runs whatever you want. You don't HAVE to do any C to run stuff from
> systemd, but it does provide many things written in C that are much more
> solid than the shell equivalents.

And if just ONE bug exists that wil make systemd segfault? A faulty
script will only fail to do the action it was made for (most
propably) ...

> > I do agree with you on one point - most init scripts are really bad
> > code, but that doesn't mean shell is bad, it means that you need to
> > educate people and file bugs. I've laughed at SLES' /etc/bashrc, I read
> > most of upstart and wondered how ... why ... is it can be drunk tiem?
> > Still that doesn't mean that rewriting it in bad C is in any way more
> > agreeable, and you just made debugging exquisitely painful. Yey.
>
> The big reason for C vs shell scripts is that the type of people who
> write them are not the same.. The type of people who write shell scripts
> tend to hack together stuff until it works.

This is plain wrong and insulting. You can do more bad things with C
than you can do with a shell.


> The people who write C tend
> to think about the problem for a long time and then write a complete
> solution that tries to take into account all of the possible error
> scenarios.

I would be happy if it was really like that...

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

2012/1/5 Olivier Crête <tester@gentoo.org>:
> On Fri, 2012-01-06 at 08:44 +0800, Patrick Lauer wrote:
>> On 01/06/12 05:26, Olivier Crête wrote:
>> [snip]
>> > The only thing I see them sacrificing is loose coupling, they provide
>> > more functionality than any other init system, more correctness
>> > (seriously, did you ever read most init scripts out there?), more well
>> > defined behavior (all systemd systems boot exactly the same), more
>> > stability (I'll claim that Lennart's C is better than any of the
>> > boot-time shell scripts I've seen) and well understandability depends
>> > who much you can understand C. Probably a bit less understandable for
>> > sysadmins, but since they can just play with config files, it's
>> > probably easier to understand in the end (and much less prone to
>> > breaking than mucking around shell scripts).
>> As you apparently have no idea what a sysadmin does I'd appreciate it if
>> people like you didn't try to guess what would make things better and
>> instead listened to people that have more than their desktop to run.
>> (Hint: It's not pressing reset buttons)
>
> I know what they do.. play in random scripts until whatever they're
> trying to hack together it seems to work, because oh well, its just a
> one time thing..  and then when stuff breaks they call Red Hat's support
> line.

Way to insult a large number of list members.

>
>> Given the choice between a single line of shell ( cat "$urandom_seed" >
>> /dev/urandom ) or 145 lines of undocumented C (which, if naively
>> modified by me, might just make systemd segfault) ... there is no choice.
>
> Actually, you don't have to do that, systemd does it for you and takes
> care of all the annoying details [1].
>
> That said, you can trivially disable systemd-random-seed-save.service
> and systemd-random-seed-load.service and instead write a unit file that
> runs whatever you want. You don't HAVE to do any C to run stuff from
> systemd, but it does provide many things written in C that are much more
> solid than the shell equivalents.
>
>> I do agree with you on one point - most init scripts are really bad
>> code, but that doesn't mean shell is bad, it means that you need to
>> educate people and file bugs. I've laughed at SLES' /etc/bashrc, I read
>> most of upstart and wondered how ... why ... is it can be drunk tiem?
>> Still that doesn't mean that rewriting it in bad C is in any way more
>> agreeable, and you just made debugging exquisitely painful. Yey.
>
> The big reason for C vs shell scripts is that the type of people who
> write them are not the same.. The type of people who write shell scripts
> tend to hack together stuff until it works. The people who write C tend
> to think about the problem for a long time and then write a complete
> solution that tries to take into account all of the possible error
> scenarios.

There are plenty of situations where shell scripts are entirely
appropriate. I am in agreement that most of the time initscripts are
not one of them. That being said I am not a fan of the tight coupling
here. Init is not supposed to segfault. A bug in one of the modules
may cause this to happen, so us old codger-y sysadmins (who apparently
love writing shell scripts and can't write real code to save our
lives) would much prefer some kind of separation. Perhaps keep 'init'
as a fairly simple codebase and run 'systemd' as pid 2 and they can
chat with each other (over dbus?)

-A

>
> [1] http://cgit.freedesktop.org/systemd/tree/src/random-seed.c
>
> --
> Olivier Crête
> tester@gentoo.org
> Gentoo Developer

On 05-01-2012 21:15:41 -0500, Olivier Crête wrote:
> The big reason for C vs shell scripts is that the type of people who
> write them are not the same.. The type of people who write shell scripts
> tend to hack together stuff until it works. The people who write C tend
> to think about the problem for a long time and then write a complete
> solution that tries to take into account all of the possible error
> scenarios.

How are we supposed to take you seriously? You don't have to make up
arguments. Instead, you can just tell what is your preference without
making a fool out of yourself.


--
Fabian Groffen
Gentoo on a different level

On Thu, Jan 5, 2012 at 5:36 PM, Alex Alexander <wired@gentoo.org> wrote:
> If people are really interested in keeping a tight, self contained root,
> we need to:
>
> - establish a [tight] list of software we consider critical for /
> - fix/patch software in that list so it can run without /usr there
> - create /bin => /usr/bin/ symlinks for above software (simplifies
>  things if packages start hardcoding /usr/bin here and there)
> - move everything else in /usr/bin/

You're missing one thing:

- establish a list of all the configurations that will actually work
with this self-contained root

I think this is why there is so much disagreement over whether this is
a good move. If you have a really simple configuration, then the
self-contained root concept works reasonably well (though apparently
we'll have to heavily patch newer versions of udev or abandon it to
sustain this).

However, if you have a very complex configuration the current
self-contained root is already broken and you need an initramfs
anyway. For in-between cases things might work now but that is likely
to change as upstream moves on.

The binary distros don't have users tweaking their kernels and init
scripts, so they basically have to design for worst-case. Gentoo can
get away with designing for more of an average case since we just tell
anybody with a complex case to go read a howto and configure what is
necessary (and we like to do that stuff anyway).

We can choose not to like it, but it sounds like maintaining a
self-contained root for even the typical case will become untenable.
Those who argue that having /usr on a separate partition simply
shouldn't be supported are basically just saying that our
"self-contained root" should include everything in /usr which seems to
defeat the whole point of a "self-contained root" anyway.

It seems to me that the most reasonable approach is to not force the
issue, but not deviate greatly from upstream either. That means
accepting that over time the rootfs will become less and less capable
of working on its own, and immediately improving tools like dracut to
overcome these limitations. Users who can get away with it can avoid
using an initramfs, at least for a time.

Sure, it is all open source, and Gentoo can swim upstream if we REALLY
want to. However, this only works if developers are willing to spend
the time constantly fixing upstream's tools. It sounds to me like the
maintainers of packages like udev/systemd/etc want to actually move in
the same direction as upstream so in practice I don't see that
happening.

Now, Gentoo is about choice, so one thing we should try to do as much
as possible is understand the limitations of the various
configurations and make it clear to users when they do and don't need
an initramfs. To be honest, tight coupling worries me more than the
/usr move, since that has a lot more potential to constrain the
choices we can offer our users (which is a great deal of the value
that Gentoo offers). I understand its advantages, but it seems
somewhat contrary to "the unix way."

Rich

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 06/01/12 03:16 AM, Alec Warner wrote:
> Perhaps keep 'init' as a fairly simple codebase and run 'systemd'
> as pid 2 and they can chat with each other (over dbus?)
>

I seriously hope that was a troll... the whole point of systemd, as I
understand it, is to entirely replace
sysvinit+whatever-rc-script-system you have. To instead make systemd
only an openrc alternative, and then trash sysvinit by making it
communicate over dbus, would be a more horrible kludge.

Addressing your point, though, I think it might be desirable to
perhaps strip out all of the actual direct service-control stuffs from
systemd and make it more of a sysvinit replacement -- that is, have it
simply launch/control services via init.d/ shell scripts (or whatever,
as long as they're external) instead of relying on internal service
code within the systemd binary itself. And I expect that this
wouldn't really be that hard to do, given that systemd already has to
support external service scripts right?

That said, I don't think I ever intend to migrate to systemd for my
server systems -- sysvinit + baselayout-1-rc is still working just
fine for me; I haven't even migrated most of them to openrc yet.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.17 (GNU/Linux)

iF4EAREIAAYFAk8HExcACgkQAJxUfCtlWe07kQEA08+XUqQbAybxlmfiPI6QCcUN
f9kQX3arCKshaIou4M0A/j0IXAi/uZlg3a7pZ9+HXo2fwcpz84J7PKQSwKr20mrq
=sC3I
-----END PGP SIGNATURE-----

On Fri, Jan 06, 2012 at 08:35:32AM -0500, Rich Freeman wrote:
> On Thu, Jan 5, 2012 at 5:36 PM, Alex Alexander <wired@gentoo.org> wrote:
> > If people are really interested in keeping a tight, self contained root,
> > we need to:
> >
> > - establish a [tight] list of software we consider critical for /
> > - fix/patch software in that list so it can run without /usr there
> > - create /bin => /usr/bin/ symlinks for above software (simplifies
> >  things if packages start hardcoding /usr/bin here and there)
> > - move everything else in /usr/bin/
>
> You're missing one thing:
>
> - establish a list of all the configurations that will actually work
> with this self-contained root
>
> I think this is why there is so much disagreement over whether this is
> a good move. If you have a really simple configuration, then the
> self-contained root concept works reasonably well (though apparently
> we'll have to heavily patch newer versions of udev or abandon it to
> sustain this).
>
> However, if you have a very complex configuration the current
> self-contained root is already broken and you need an initramfs
> anyway. For in-between cases things might work now but that is likely
> to change as upstream moves on.
>
> The binary distros don't have users tweaking their kernels and init
> scripts, so they basically have to design for worst-case. Gentoo can
> get away with designing for more of an average case since we just tell
> anybody with a complex case to go read a howto and configure what is
> necessary (and we like to do that stuff anyway).
>
> We can choose not to like it, but it sounds like maintaining a
> self-contained root for even the typical case will become untenable.
> Those who argue that having /usr on a separate partition simply
> shouldn't be supported are basically just saying that our
> "self-contained root" should include everything in /usr which seems to
> defeat the whole point of a "self-contained root" anyway.
>
> It seems to me that the most reasonable approach is to not force the
> issue, but not deviate greatly from upstream either. That means
> accepting that over time the rootfs will become less and less capable
> of working on its own, and immediately improving tools like dracut to
> overcome these limitations. Users who can get away with it can avoid
> using an initramfs, at least for a time.
>
> Sure, it is all open source, and Gentoo can swim upstream if we REALLY
> want to. However, this only works if developers are willing to spend
> the time constantly fixing upstream's tools. It sounds to me like the
> maintainers of packages like udev/systemd/etc want to actually move in
> the same direction as upstream so in practice I don't see that
> happening.
>
> Now, Gentoo is about choice, so one thing we should try to do as much
> as possible is understand the limitations of the various
> configurations and make it clear to users when they do and don't need
> an initramfs. To be honest, tight coupling worries me more than the
> /usr move, since that has a lot more potential to constrain the
> choices we can offer our users (which is a great deal of the value
> that Gentoo offers). I understand its advantages, but it seems
> somewhat contrary to "the unix way."

That's why I wrote "tight list". I do not expect the self-contained root
to be able to handle everything /usr (or a complete initramfs) would.
What it could and couldn't do is something that needs to be decided, but
some work is already done there - it's just a bit messy and incomplete
and because most people don't care it keeps getting worse.

The important thing here is to make a clear definition of where we draw
the line and make sure things work the way we want them to.

I agree with you in that at some point patching may become too time
consuming, but I still believe that if we do this properly, with a
well-defined plan and list of packages we want to keep in / (with
symlinks to be compatible with whatever others are trying to do), we
won't be alone in this. Gentoo may be one of the most hardcore
power-user distros out there, but we're certainly not the only one.

Now, if only we had people interested enough in doing this... :)
--
Alex Alexander | wired
+ Gentoo Linux Developer
++ www.linuxized.com

* William Hubbs <williamh@gentoo.org> schrieb:

Hi folks,

> a significant change is taking place with several upstreams that will affect
> us in gentoo, so I wanted to bring it to the list for discussion.
>
> Udev, kmod (which is a replacement for module-init-tools which will be needed
> by >=udev-176), systemd, and soon others, are advocating a major change
> to the locations where binaries and libraries are stored on linux
> systems.
>
> The goal is to deprecate /bin, /lib, /sbin and /usr/sbin. My
> understanding is that they want to move software that is installed in
> /bin, /sbin and /usr/sbin to /usr/bin. Also, they want to move
> everything from /lib to /usr/lib.

Yep, the same issue alreay came up a few weeks ago on @debian.

I don't want to repeat all the arguments, why these Windows-imitator
guys are completely wrong, anymore. (IMHO already been said in this
thread).

If upstream really wants to stick in that silly chance, it's time for
a fork. We're already allocating about 20..30hrs per week beginning
with 2012/2 for such a project in our resource plan. This stupidity
can become really dangerous thousands of systems around the world,
so it needs to be stopped.

BTW: the original argument (AFAIK) is that moving everything to
/usr should somehow make maintenance easier. Well, how actually ?
Perhaps for people who are too lazy to backup a few more directories ?
Silly.

Actually, at this point, I'd raise the question why not dropping
/usr instead (in little steps). The impact is practically the
same (well, replaces the risk of unbootable system by the risk
of filling up separated / filesystems) but would remove an
then obsolete additional directory. ;-O



cu
--
----------------------------------------------------------------------
Enrico Weigelt, metux IT service -- http://www.metux.de/

phone: +49 36207 519931 email: weigelt@metux.de
mobile: +49 151 27565287 icq: 210169427 skype: nekrad666
----------------------------------------------------------------------
Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme
----------------------------------------------------------------------

* Olivier Cr?te <tester@gentoo.org> schrieb:

> You clearly have failed to realize that d-bus is a now the bus for
> system messaging and is as much part of the system as syslog or bash.
> Probably even more so, for example, in Fedora 17, you'll be able to boot
> without syslog or bash, but you need d-bus.

That's one of the reasons why Fedora is so bad, that I must
refuse to use it in critical enterprise systems (same as RHEL).
It already was ugly about 5 years ago (while SuSE is ranking 1
you-really-dont-wanna-use-it distros since about 10 years)

Please, don't let Gentoo become as bad as Fedora, RHEL or SLES.


cu
--
----------------------------------------------------------------------
Enrico Weigelt, metux IT service -- http://www.metux.de/

phone: +49 36207 519931 email: weigelt@metux.de
mobile: +49 151 27565287 icq: 210169427 skype: nekrad666
----------------------------------------------------------------------
Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme
----------------------------------------------------------------------

* Olivier Cr?te <tester@gentoo.org> schrieb:

> d-bus is not high-level stuff... For example, you can't use bluetooth
> without d-bus. Even Android has it..

really sad, that so many important packages are depending on
that misdesigned bloat.


cu
--
----------------------------------------------------------------------
Enrico Weigelt, metux IT service -- http://www.metux.de/

phone: +49 36207 519931 email: weigelt@metux.de
mobile: +49 151 27565287 icq: 210169427 skype: nekrad666
----------------------------------------------------------------------
Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme
----------------------------------------------------------------------

On Fri, 6 Jan 2012 18:50:49 +0100
Enrico Weigelt <weigelt@metux.de> wrote:

> I don't want to repeat all the arguments, why these Windows-imitator
> guys are completely wrong, anymore. (IMHO already been said in this
> thread).

Yes, having a single locations for all applications is so-windows. We
should go the other way then, and create a separate prefix for every
application. I wonder why we removed that awesome /usr/X11R6.

> If upstream really wants to stick in that silly chance, it's time for
> a fork. We're already allocating about 20..30hrs per week beginning
> with 2012/2 for such a project in our resource plan. This stupidity
> can become really dangerous thousands of systems around the world,
> so it needs to be stopped.

Wow, an enterprise fork taking 20-30 hrs per week to reimplement hacks
necessary for running applications randomly spread over filesystems?

> BTW: the original argument (AFAIK) is that moving everything to
> /usr should somehow make maintenance easier. Well, how actually ?
> Perhaps for people who are too lazy to backup a few more directories ?
> Silly.

Enjoy sharing those few more directories over NFS. Ah, yes, only silly
people want to share their systems over NFS. Enterprise admins reserve
20-30 hrs per week to keep systems in sync.

> Actually, at this point, I'd raise the question why not dropping
> /usr instead (in little steps). The impact is practically the
> same (well, replaces the risk of unbootable system by the risk
> of filling up separated / filesystems) but would remove an
> then obsolete additional directory. ;-O

That's because people would like to get rid of additional directories
in /, not introduce additional ones. But if you really want to, we can
start making random packages install on rootfs. Just let us know when
they happily fill up your rootfs.

--
Best regards,
Michał Górny

* Patrick Lauer <patrick@gentoo.org> schrieb:

> Please don't try to bring the GnomeOS vision of having MacOS without
> paying for it to my computing experience ...

+10


cu
--
----------------------------------------------------------------------
Enrico Weigelt, metux IT service -- http://www.metux.de/

phone: +49 36207 519931 email: weigelt@metux.de
mobile: +49 151 27565287 icq: 210169427 skype: nekrad666
----------------------------------------------------------------------
Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme
----------------------------------------------------------------------

* Micha?? G?rny <mgorny@gentoo.org> schrieb:

> > I don't want to repeat all the arguments, why these Windows-imitator
> > guys are completely wrong, anymore. (IMHO already been said in this
> > thread).
>
> Yes, having a single locations for all applications is so-windows. We
> should go the other way then, and create a separate prefix for every
> application. I wonder why we removed that awesome /usr/X11R6.

I was talking about other things, like giving up the typical
unix-style separation of subsystems, all the bloating happening
in certain DE's and then pulling down that bloat to the system
level (just starting w/ dbus)

> > If upstream really wants to stick in that silly chance, it's time for
> > a fork. We're already allocating about 20..30hrs per week beginning
> > with 2012/2 for such a project in our resource plan. This stupidity
> > can become really dangerous thousands of systems around the world,
> > so it needs to be stopped.
>
> Wow, an enterprise fork taking 20-30 hrs per week to reimplement hacks
> necessary for running applications randomly spread over filesystems?

This is just our donation, I'm hoping others will join in.
For the actual development, half of the resources should be
fine, but testing dozens of uncommon scenarios will eat up
a multiple of that.

> > BTW: the original argument (AFAIK) is that moving everything to
> > /usr should somehow make maintenance easier. Well, how actually ?
> > Perhaps for people who are too lazy to backup a few more directories ?
> > Silly.
>
> Enjoy sharing those few more directories over NFS.

Yes, what's the big deal ? Done that with thousands of nodes.

> > Actually, at this point, I'd raise the question why not dropping
> > /usr instead (in little steps). The impact is practically the
> > same (well, replaces the risk of unbootable system by the risk
> > of filling up separated / filesystems) but would remove an
> > then obsolete additional directory. ;-O
>
> That's because people would like to get rid of additional directories
> in /, not introduce additional ones.

Aha. Then why not also moving /home, /etc and /var to /usr, too ? ;-o
(hmm, some mindless jerks really could pick up that silly idea...)


cu
--
----------------------------------------------------------------------
Enrico Weigelt, metux IT service -- http://www.metux.de/

phone: +49 36207 519931 email: weigelt@metux.de
mobile: +49 151 27565287 icq: 210169427 skype: nekrad666
----------------------------------------------------------------------
Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme
----------------------------------------------------------------------

On Fri, 6 Jan 2012 19:41:27 +0100
Enrico Weigelt <weigelt@metux.de> wrote:

> * Micha?? G?rny <mgorny@gentoo.org> schrieb:
>
> > > I don't want to repeat all the arguments, why these
> > > Windows-imitator guys are completely wrong, anymore. (IMHO
> > > already been said in this thread).
> >
> > Yes, having a single locations for all applications is so-windows.
> > We should go the other way then, and create a separate prefix for
> > every application. I wonder why we removed that awesome /usr/X11R6.
>
> I was talking about other things, like giving up the typical
> unix-style separation of subsystems, all the bloating happening
> in certain DE's and then pulling down that bloat to the system
> level (just starting w/ dbus)

Yes, three arguments and just a one, silly example which is basically
incorrect assuming noone obliges you to use systemd.

> > > If upstream really wants to stick in that silly chance, it's time
> > > for a fork. We're already allocating about 20..30hrs per week
> > > beginning with 2012/2 for such a project in our resource plan.
> > > This stupidity can become really dangerous thousands of systems
> > > around the world, so it needs to be stopped.
> >
> > Wow, an enterprise fork taking 20-30 hrs per week to reimplement
> > hacks necessary for running applications randomly spread over
> > filesystems?
>
> This is just our donation, I'm hoping others will join in.
> For the actual development, half of the resources should be
> fine, but testing dozens of uncommon scenarios will eat up
> a multiple of that.

I thought you reserved that much time for mailing lists.

> > > BTW: the original argument (AFAIK) is that moving everything to
> > > /usr should somehow make maintenance easier. Well, how actually ?
> > > Perhaps for people who are too lazy to backup a few more
> > > directories ? Silly.
> >
> > Enjoy sharing those few more directories over NFS.
>
> Yes, what's the big deal ? Done that with thousands of nodes.

Without initramfs? Syncing rootfs over and over again or just updating
packages installing into it once a year?

> > > Actually, at this point, I'd raise the question why not dropping
> > > /usr instead (in little steps). The impact is practically the
> > > same (well, replaces the risk of unbootable system by the risk
> > > of filling up separated / filesystems) but would remove an
> > > then obsolete additional directory. ;-O
> >
> > That's because people would like to get rid of additional
> > directories in /, not introduce additional ones.
>
> Aha. Then why not also moving /home, /etc and /var to /usr, too ? ;-o
> (hmm, some mindless jerks really could pick up that silly idea...)

You should consider taking like 1 or 2 hours of your precious time to
read about the use and meaning of various directories in the filesystem.

--
Best regards,
Michał Górny

* Micha?? G?rny <mgorny@gentoo.org> schrieb:

> > I was talking about other things, like giving up the typical
> > unix-style separation of subsystems, all the bloating happening
> > in certain DE's and then pulling down that bloat to the system
> > level (just starting w/ dbus)
>
> Yes, three arguments and just a one, silly example which is basically
> incorrect assuming noone obliges you to use systemd.

IIRC, systemd is not the only system-level package depending on dbus.

> > Yes, what's the big deal ? Done that with thousands of nodes.
>
> Without initramfs?

Yes. Using PXE and nfsroot.

> Syncing rootfs over and over again or just updating
> packages installing into it once a year?

Regularily updating packages, but with quite conservative policy.
Of course, this required proper service restarts, etc,
but thats an topic on its own ...

> > > That's because people would like to get rid of additional
> > > directories in /, not introduce additional ones.
> >
> > Aha. Then why not also moving /home, /etc and /var to /usr, too ? ;-o
> > (hmm, some mindless jerks really could pick up that silly idea...)
>
> You should consider taking like 1 or 2 hours of your precious time to
> read about the use and meaning of various directories in the filesystem.

I studied FHS and its purpose somewhat >15 years ago, and I don't
want to repeat all the arguments. My argument was just: if you
wanna move /bin+co to /usr for easier maintenance, you could also
put /usr/* to / for quite the same reasons.


cu
--
----------------------------------------------------------------------
Enrico Weigelt, metux IT service -- http://www.metux.de/

phone: +49 36207 519931 email: weigelt@metux.de
mobile: +49 151 27565287 icq: 210169427 skype: nekrad666
----------------------------------------------------------------------
Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme
----------------------------------------------------------------------

On Wed, Jan 04, 2012 at 01:51:26PM -0500, Olivier Cr?te wrote

> No no no, the idea is that once all binaries are in /usr, you can easily
> share /usr between different systems and do updates in a sane way.. You
> can also mount /usr read-only, but still have / be read-write.

One size does not fit all. It breaks Gentoo horribly. Here's my setup

waltdnes@d530 / $ du -s /usr
3057917 usr

waltdnes@d530 /usr $ du -s /usr/portage
1394646 /usr/portage

waltdnes@d530 /usr $ du -s /usr/src
665069 /usr/src

In my 3 gig /usr directory, over 2 gigs are devoted to Gentoo-specific
stuff that a binary distro like Redhat does not require. What do we do
if /usr is read-only? Symlink or bindmount onto it?

And sharing binaries does *NOT* work in Gentoo, unless *EVERYBODY* has
*IDENTICAL* machines, or else you drop down to the lowest common
denominator. That's one of the main points about Gentoo. We don't use
generic i686 code, we use code optimised for our machines. I'm not a
"Gentoo ricer", but here's a prime example... a 3 and 1/2 year old Dell
Dimension 530 with an onboard Intel graphics chip. Right after the
initial install (i686 code from the install CD), the onboard graphics
could not handle NHL Gamecentre Live fullscreen (1920x1080). There
would be constant stuttering. After I emerged system and world with
"-march=native -O2 -mfpmath=sse", it handles NHL Gamecentre Live
fullscreen, and even a 1080p movie clip downloaded from Youtube. Fedora
with generic i686 code would not work for me.

--
Walter Dnes <waltdnes@waltdnes.org>

On Fri, 2012-01-06 at 19:41 -0500, Walter Dnes wrote:
> On Wed, Jan 04, 2012 at 01:51:26PM -0500, Olivier Cr?te wrote
>
> > No no no, the idea is that once all binaries are in /usr, you can easily
> > share /usr between different systems and do updates in a sane way.. You
> > can also mount /usr read-only, but still have / be read-write.
>
> One size does not fit all. It breaks Gentoo horribly. Here's my setup
>
> waltdnes@d530 / $ du -s /usr
> 3057917 usr
>
> waltdnes@d530 /usr $ du -s /usr/portage
> 1394646 /usr/portage
>
> waltdnes@d530 /usr $ du -s /usr/src
> 665069 /usr/src
>
> In my 3 gig /usr directory, over 2 gigs are devoted to Gentoo-specific
> stuff that a binary distro like Redhat does not require. What do we do
> if /usr is read-only? Symlink or bindmount onto it?

You don't understand the purpose of read-only /usr. It has nothing to do
with source vs binary. It is for when you have many machines that are
identical or at least similar.

The idea is that you can mount the same /usr on many machines (using NFS
or something like that). So you can have a relatively small / as a r/w
nfsroot (containing /etc, /var, /tmp, etc, etc), and then share /usr
among all the machines in your cluster or machine room or your many user
desktops.

With the current system, you either have to maintain in sync
the /bin, /sbin, /usr, etc separately, making life harder for everyone.

But clearly, you've never been the sysadmin of that kind of setup.

--
Olivier Crête
tester@gentoo.org
Gentoo Developer

On Fri, Jan 06, 2012 at 07:41:27PM +0100, Enrico Weigelt wrote

> This is just our donation, I'm hoping others will join in.
> For the actual development, half of the resources should be
> fine, but testing dozens of uncommon scenarios will eat up
> a multiple of that.

I'm not a C programmer, bash is my forte. I'm retired, and I have a
spare machine to play around with for testing. Contact me offline if
I can help.

--
Walter Dnes <waltdnes@waltdnes.org>

On Fri, 06 Jan 2012 19:59:45 -0500
Olivier Crête <tester@gentoo.org> wrote:

> On Fri, 2012-01-06 at 19:41 -0500, Walter Dnes wrote:
> > On Wed, Jan 04, 2012 at 01:51:26PM -0500, Olivier Cr?te wrote
> >
> > > No no no, the idea is that once all binaries are in /usr, you can
> > > easily share /usr between different systems and do updates in a
> > > sane way.. You can also mount /usr read-only, but still have / be
> > > read-write.
> >
> > One size does not fit all. It breaks Gentoo horribly. Here's my
> > setup
> >
> > waltdnes@d530 / $ du -s /usr
> > 3057917 usr
> >
> > waltdnes@d530 /usr $ du -s /usr/portage
> > 1394646 /usr/portage
> >
> > waltdnes@d530 /usr $ du -s /usr/src
> > 665069 /usr/src
> >
> > In my 3 gig /usr directory, over 2 gigs are devoted to
> > Gentoo-specific stuff that a binary distro like Redhat does not
> > require. What do we do if /usr is read-only? Symlink or bindmount
> > onto it?
>
> You don't understand the purpose of read-only /usr. It has nothing to
> do with source vs binary. It is for when you have many machines that
> are identical or at least similar.
>
> The idea is that you can mount the same /usr on many machines (using
> NFS or something like that). So you can have a relatively small / as
> a r/w nfsroot (containing /etc, /var, /tmp, etc, etc), and then
> share /usr among all the machines in your cluster or machine room or
> your many user desktops.
>
> With the current system, you either have to maintain in sync
> the /bin, /sbin, /usr, etc separately, making life harder for
> everyone.
>
> But clearly, you've never been the sysadmin of that kind of setup.
>

Not saying it's just you, but people should stop being dicks. Being
antagonistic against everyone is not getting us anywhere and only
serves to divide the community. People shouldn't use the hate in
dealing with whether or not to change on other people, use it on the
actual argument :D

--
Matthew Thode (prometheanfire)

On 01/05/2012 03:40 AM, Zac Medico wrote:
> The FHS notion of "root filesystem as a recovery partition" existed long
> before the relatively modern development of things like busybox and
> initramfs made it more practical to use an initramfs as a recovery
> partition. Anyone who wouldn't prefer to use an initramfs for their
> "recover partition" probably just doesn't realize how well suited an
> initramfs is for the job. It's so well suited for the job that it makes
> the old FHS notion of "root filesystem as a recovery partition" seem quaint.

Please stop hailing to busybox. I think it's a bulk load of faulty, half
implemented code that's not worth the time compiling.

You can do better w/ the real tools. (Not my crappy little initrd
script, but the well established, fully operational, as used to programms)

http://xmw.de/dotfiles/scripts/mkinitramfs.sh

--
Gentoo Dev
http://xmw.de/

On 01/06/2012 07:10 PM, Michael Weber wrote:
> On 01/05/2012 03:40 AM, Zac Medico wrote:
>> The FHS notion of "root filesystem as a recovery partition" existed long
>> before the relatively modern development of things like busybox and
>> initramfs made it more practical to use an initramfs as a recovery
>> partition. Anyone who wouldn't prefer to use an initramfs for their
>> "recover partition" probably just doesn't realize how well suited an
>> initramfs is for the job. It's so well suited for the job that it makes
>> the old FHS notion of "root filesystem as a recovery partition" seem quaint.
>
> Please stop hailing to busybox. I think it's a bulk load of faulty, half
> implemented code that's not worth the time compiling.
>
> You can do better w/ the real tools. (Not my crappy little initrd
> script, but the well established, fully operational, as used to programms)
>
> http://xmw.de/dotfiles/scripts/mkinitramfs.sh

That seems like an awfully large initramfs to load into memory for every
boot, just to have it wiped from memory after switching to the real
root. It's fine as long as you're not trying to shave every last
microsecond off of your boot time though.

An alternative approach to a having a bulky initramfs "recovery
partition" like yours would be to put the content of a livecd/usb
recovery disk onto a spare partition, and configure your lean busybox
initramfs to mount that as the root if something goes wrong with your
real root.
--
Thanks,
Zac

On Fri, 06 Jan 2012 22:58:58 -0800
Zac Medico <zmedico@gentoo.org> wrote:

> An alternative approach to a having a bulky initramfs "recovery
> partition" like yours would be to put the content of a livecd/usb
> recovery disk onto a spare partition, and configure your lean busybox
> initramfs to mount that as the root if something goes wrong with your
> real root.

And busybox again. Busybox is awfully big even when all useless tools
are disabled. klibc is the way to go if initramfs is not supposed to be
completely functional.

--
Best regards,
Michał Górny

On Fri, 6 Jan 2012 19:41:39 -0500
"Walter Dnes" <waltdnes@waltdnes.org> wrote:

> In my 3 gig /usr directory, over 2 gigs are devoted to
> Gentoo-specific stuff that a binary distro like Redhat does not
> require. What do we do if /usr is read-only? Symlink or bindmount
> onto it?

Remount read/write whenever necessary (i.e. when doing administrative
tasks).

> And sharing binaries does *NOT* work in Gentoo, unless *EVERYBODY*
> has *IDENTICAL* machines, or else you drop down to the lowest common
> denominator. That's one of the main points about Gentoo. We don't
> use generic i686 code, we use code optimised for our machines. I'm
> not a "Gentoo ricer", but here's a prime example... a 3 and 1/2 year
> old Dell Dimension 530 with an onboard Intel graphics chip. Right
> after the initial install (i686 code from the install CD), the
> onboard graphics could not handle NHL Gamecentre Live fullscreen
> (1920x1080). There would be constant stuttering. After I emerged
> system and world with "-march=native -O2 -mfpmath=sse", it handles
> NHL Gamecentre Live fullscreen, and even a 1080p movie clip
> downloaded from Youtube. Fedora with generic i686 code would not
> work for me.

Sharing is usually useful when everybody actually has identical
machines. Also, there's '-mtune' switch in gcc.

--
Best regards,
Michał Górny

* Walter Dnes <waltdnes@waltdnes.org> schrieb:
> On Fri, Jan 06, 2012 at 07:41:27PM +0100, Enrico Weigelt wrote
>
> > This is just our donation, I'm hoping others will join in.
> > For the actual development, half of the resources should be
> > fine, but testing dozens of uncommon scenarios will eat up
> > a multiple of that.
>
> I'm not a C programmer, bash is my forte. I'm retired, and I have a
> spare machine to play around with for testing. Contact me offline if
> I can help.

Great. Perhaps you could create some unusual setups (perhaps in a
full-VM), so we can build an test platform on it.

IIRC the main problem are scenarios where /usr is not available
at boot, eg. has to be mounted from somewhere else (eg. NFS).
So, our test platform should have such setups.


cu
--
----------------------------------------------------------------------
Enrico Weigelt, metux IT service -- http://www.metux.de/

phone: +49 36207 519931 email: weigelt@metux.de
mobile: +49 151 27565287 icq: 210169427 skype: nekrad666
----------------------------------------------------------------------
Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme
----------------------------------------------------------------------

On 01/07/2012 07:58 AM, Zac Medico wrote:
> That seems like an awfully large initramfs to load into memory for every
> boot, just to have it wiped from memory after switching to the real
> root. It's fine as long as you're not trying to shave every last
> microsecond off of your boot time though.
The size is 59MB,
core2duo 2x2.20GHz, 44MB/s HDD needs approx 3 seconds reading from xfs /boot

> An alternative approach to a having a bulky initramfs "recovery
> partition" like yours would be to put the content of a livecd/usb
> recovery disk onto a spare partition, and configure your lean busybox
> initramfs to mount that as the root if something goes wrong with your
> real root.
Yeah, i have full disk ecnryption and /boot is my "recovery" partition.
I don't want to reboot or picup usb/optical media to fix problems.
Well, and i can backup my system via nc/ssh/sshd/..., plus screen-lock.

3 seconds "penalty" on approx 50 boos/year are less time than standing
up and search-rescue an potentially outdated external media.

And yes, I decided against recompiled binaries (USE=-X) in favor of
creation time (approx 3 minutes), that f**ks vim and nethack.

Michael

--
Gentoo Dev
http://xmw.de/