[gentoo-dev] Opinion against /usr merge

[Richard Yao]

Dear Everyone,

An often cited benefit of the /usr merge is the ability to put
everything but /etc on NFS and for that reason, we need to force an
initramfs on people happily using /usr without it.

Interestingly, the /usr merge changes made to genkernel permit us to
mount /etc from a genkernel-built initramfs by putting /etc on a
separate mount point in fstab and then doing `echo /etc >>
/etc/initramfs.mounts`.

Some people claim that the current approach is somehow broken by citing
Bluetooth keyboards. However, what makes that work is adopting an
initramfs and that does *not* require moving files into /usr. If people
do not want an initramfs, they can simply not have a separate /usr. The
/usr merge gives nothing to people using bluetooth while the /usr merge
will break systems of non-bluetooth users.

I have been told that moving everything into /usr would be easy for us
because Arch Linux did it and they are a rolling distribution too. Arch
Linux does all-or-nothing upgrades. They do not offer the ability for
their users to choose to use older versions of software and we will not
be able to move everything into /usr without breaking existing systems
that boot without issues now.

I have also been told that the /usr merge is necessary because upstream
will force it on us. Interestingly, most of @system on Gentoo Linux is
GNU software, which would need to stop supporting things in / in order
for that to happen. As far ass I know, systemd does not work on GNU HURD
and it would be incapable of functioning if the GNU project made this
change. Hell will freeze long before that happens.

The only thing that might require a merge is systemd and it is not in
@system. If we offered users the ability to choose rc systems, we would
still be supporting baselayout-1's rc system. If we start now, we should
bring that back.

With that said, there is a great deal of FUD being spread by the systemd
developers and I see no reason for us to accept it. We would be breaking
users' systems for no gain other than to make the systemd developers
happy. Their refusal to permit udev to be built separately from systemd
demonstrated complete disdain for Gentoo Linux. Why should we let them
dictate how we design our distribution at our users' expense?

Lastly, don't tell me to read systemd's case for why we should break
people's systems. I have read it and I find it flawed. There is
absolutely no need for us to make this change.

Yours truly,
Richard Yao

[Rich Freeman]

On Tue, Jul 17, 2012 at 5:20 PM, Richard Yao <ry...@gentoo.org> wrote:
> I have also been told that the /usr merge is necessary because upstream
> will force it on us. Interestingly, most of @system on Gentoo Linux is
> GNU software, which would need to stop supporting things in / in order
> for that to happen.

I don't think anybody in Gentoo is advocating a full /usr merge. I
think that the only thing that has been happening is that there will
not be any heroic measures to keep a system with a separate /usr
booting without the use of an initramfs or some early-running script.

It doesn't matter that the majority of @system software is GNU. For a
separate /usr to not work does not require ALL of the software to not
support it, but only for a few pieces of software to not support it -
a chain is as strong as its weakest link.

In any case, it sounds like for now some devs are continuing to adjust
ebuilds to keep a separate /usr working as well as possible, though it
apparently breaks in some edge cases right now without an initramfs,
as you've already noted in your email.

I don't think anybody in Gentoo is really pushing for a /usr merge -
there are just lots of devs saying that they aren't going to spend a
lot of time stopping it either. If upstream sticks files needed to
boot in /usr then it is basically up to somebody who cares to do
something to move them. Right now that isn't a lot of work, but the
reason people are concerned is that this is likely to change.

If somebody really is pushing for an all-out /usr move by all means
speak up, but I think that basically what everybody is advocating is
trying to follow upstream for individual packages.

Rich

[Olivier Crête]

On Tue, 2012-07-17 at 18:41 -0400, Rich Freeman wrote:
> If somebody really is pushing for an all-out /usr move by all means
> speak up, but I think that basically what everybody is advocating is
> trying to follow upstream for individual packages.

As I've been saying for a while, doing a full merge of /bin, /sbin, /lib
into /usr is probably unavoidable in the long term. We should be ready
for it, and even try to do it progressively. As currently, the split is
entirely arbitrary.

Also be ready for a merge of /bin and /sbin.. I'm sure most people can't
even explain the difference between them.

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

[William Hubbs]

On Tue, Jul 17, 2012 at 05:20:13PM -0400, Richard Yao wrote:
> An often cited benefit of the /usr merge is the ability to put
> everything but /etc on NFS and for that reason, we need to force an
> initramfs on people happily using /usr without it.

This is not quite correct. The initramfs is required because of [1].

> Interestingly, the /usr merge changes made to genkernel permit us to
> mount /etc from a genkernel-built initramfs by putting /etc on a
> separate mount point in fstab and then doing `echo /etc >>
> /etc/initramfs.mounts`.

That doesn't negate putting /usr on nfs and making it possible for
different hosts to share it.

> Some people claim that the current approach is somehow broken by citing
> Bluetooth keyboards. However, what makes that work is adopting an
> initramfs and that does *not* require moving files into /usr. If people
> do not want an initramfs, they can simply not have a separate /usr. The
> /usr merge gives nothing to people using bluetooth while the /usr merge
> will break systems of non-bluetooth users.

I don't see what bluetooth has to do with anything other than with the
'separate usr is broken' document which is a separate issue.

> I have been told that moving everything into /usr would be easy for us
> because Arch Linux did it and they are a rolling distribution too. Arch
> Linux does all-or-nothing upgrades. They do not offer the ability for
> their users to choose to use older versions of software and we will not
> be able to move everything into /usr without breaking existing systems
> that boot without issues now.

This issue is not completely flushed out with the upstream folks for
udev yet, and either way, it will be addressed in our version of udev.

> I have also been told that the /usr merge is necessary because upstream
> will force it on us. Interestingly, most of @system on Gentoo Linux is
> GNU software, which would need to stop supporting things in / in order
> for that to happen. As far ass I know, systemd does not work on GNU HURD
> and it would be incapable of functioning if the GNU project made this
> change. Hell will freeze long before that happens.

This is basically not relevant since we do not support HURD.

> The only thing that might require a merge is systemd and it is not in
> @system. If we offered users the ability to choose rc systems, we would
> still be supporting baselayout-1's rc system. If we start now, we should
> bring that back.

We offer several rc systems in the tree, but I don't know how up to
date they are. Either way, bringing back bl1 is not a relevant
argument, because it is not compatible with OpenRC.

> With that said, there is a great deal of FUD being spread by the systemd
> developers and I see no reason for us to accept it. We would be breaking
> users' systems for no gain other than to make the systemd developers
> happy. Their refusal to permit udev to be built separately from systemd
> demonstrated complete disdain for Gentoo Linux. Why should we let them
> dictate how we design our distribution at our users' expense?

I think we can do the /usr merge in a way that won't break systems; I am
looking into that possibility. I am not interested in breaking systems.

> Lastly, don't tell me to read systemd's case for why we should break
> people's systems. I have read it and I find it flawed. There is
> absolutely no need for us to make this change.

Without elaboration on why you find their case flawed, this sounds
like the typical, "if it isn't broke, don't fix it" argument.
While that has merrit, if there are advantages to doing
something, like I think there would be to doing the /usr merge, it may
be worth the transition, especially if we can make it as smooth as
possible.

William

[Dale]

William Hubbs wrote:
>
> This is not quite correct. The initramfs is required because of [1].
>
>

> William
>

Where is [1]?

Dale

:-) :-)

--
I am only responsible for what I said ... Not for what you understood or how you interpreted my words!

[William Hubbs]

On Tue, Jul 17, 2012 at 06:41:26PM -0400, Rich Freeman wrote:
> In any case, it sounds like for now some devs are continuing to adjust
> ebuilds to keep a separate /usr working as well as possible, though it
> apparently breaks in some edge cases right now without an initramfs,
> as you've already noted in your email.
>
> I don't think anybody in Gentoo is really pushing for a /usr merge -
> there are just lots of devs saying that they aren't going to spend a
> lot of time stopping it either. If upstream sticks files needed to
> boot in /usr then it is basically up to somebody who cares to do
> something to move them. Right now that isn't a lot of work, but the
> reason people are concerned is that this is likely to change.

Right, I'm definitely not advocating a full out /usr merge tomorrow or
anything, I am just not interested in doing a whole lot of patching to
keep something from moving to /usr if upstream moves it there.

Also, I am interested in looking at what is installed in /, and if
upstream defaults put it in /usr, allowing it to happen on gentoo that
way as well.

My thought is that eventually we will have more and more things that are
being installed in /usr.

> If somebody really is pushing for an all-out /usr move by all means
> speak up, but I think that basically what everybody is advocating is
> trying to follow upstream for individual packages.

Right, that's the issue. Some upstreams (mainly udev) have dropped
backward compatibility. But, I will be able to get around those for a
while.

William

[William Hubbs]

On Tue, Jul 17, 2012 at 06:13:06PM -0500, Dale wrote:
>
> William Hubbs wrote:
> >
> > This is not quite correct. The initramfs is required because of [1].
> >
> >
> > William
> >
>
> Where is [1]?

[1] http://freedesktop.org/wiki/Software/systemd/separate-usr-is-broken

We have a way around this in some limited circumstances with
busybox[sep-usr], but that definitely does not support anything fancy
like rade, lvm, etc.

William

[Richard Yao]

On 07/17/2012 07:02 PM, William Hubbs wrote:
> On Tue, Jul 17, 2012 at 05:20:13PM -0400, Richard Yao wrote:
>> An often cited benefit of the /usr merge is the ability to put
>> everything but /etc on NFS and for that reason, we need to force an
>> initramfs on people happily using /usr without it.
>
> This is not quite correct. The initramfs is required because of [1].

What is [1]?

>> Interestingly, the /usr merge changes made to genkernel permit us to
>> mount /etc from a genkernel-built initramfs by putting /etc on a
>> separate mount point in fstab and then doing `echo /etc >>
>> /etc/initramfs.mounts`.
>
> That doesn't negate putting /usr on nfs and making it possible for
> different hosts to share it.

People can still have different hosts share / with host-specific stuff
(e.g. /etc) mounted by genkernel.

>> I have also been told that the /usr merge is necessary because upstream
>> will force it on us. Interestingly, most of @system on Gentoo Linux is
>> GNU software, which would need to stop supporting things in / in order
>> for that to happen. As far ass I know, systemd does not work on GNU HURD
>> and it would be incapable of functioning if the GNU project made this
>> change. Hell will freeze long before that happens.
>
> This is basically not relevant since we do not support HURD.

It is relevant because it guarantees that the GNU stuff in @system will
continue working. That allows us to narrow our focus to the non-GNU
things required to use Gentoo Linux.

Looking at @system and what it typically pulls into @world, the only
thing that might cause a problem is udev, although virtual/dev-manager
is in @system, rather than udev. If that happens, we have a few ways of
dealing with that:

1. Patch udev.
2. Fork udev.
3. Consider breaking people's systems then.

Until then, doing what RedHat wants is unnecessary.

>> Lastly, don't tell me to read systemd's case for why we should break
>> people's systems. I have read it and I find it flawed. There is
>> absolutely no need for us to make this change.
>
> Without elaboration on why you find their case flawed, this sounds
> like the typical, "if it isn't broke, don't fix it" argument.
> While that has merrit, if there are advantages to doing
> something, like I think there would be to doing the /usr merge, it may
> be worth the transition, especially if we can make it as smooth as
> possible.

The cost to benefit ratio is simply too low for "lets change it because
it could be better this way" to merit making the change. The things that
I have heard are going to break existing systems that I have gone
through some trouble to support. I really don't want to see that.

[Dale]

Ah, read that link a while back. Nothing new there I don't guess.

[William Hubbs]

On Tue, Jul 17, 2012 at 07:19:48PM -0400, Richard Yao wrote:
> On 07/17/2012 07:02 PM, William Hubbs wrote:
> > This is basically not relevant since we do not support HURD.
>
> It is relevant because it guarantees that the GNU stuff in @system will
> continue working. That allows us to narrow our focus to the non-GNU
> things required to use Gentoo Linux.
>
> Looking at @system and what it typically pulls into @world, the only
> thing that might cause a problem is udev, although virtual/dev-manager
> is in @system, rather than udev. If that happens, we have a few ways of
> dealing with that:
>
> 1. Patch udev.

I think I can come up with a patch locally that will read rules from
/lib/udev/rules.d if that's what we want to do for now.

> 2. Fork udev.

I don't think this is necessary, and it would create more work for us
than is needed.

> >> Lastly, don't tell me to read systemd's case for why we should break
> >> people's systems. I have read it and I find it flawed. There is
> >> absolutely no need for us to make this change.
> >
> > Without elaboration on why you find their case flawed, this sounds
> > like the typical, "if it isn't broke, don't fix it" argument.
> > While that has merrit, if there are advantages to doing
> > something, like I think there would be to doing the /usr merge, it may
> > be worth the transition, especially if we can make it as smooth as
> > possible.
>
> The cost to benefit ratio is simply too low for "lets change it because
> it could be better this way" to merit making the change. The things that
> I have heard are going to break existing systems that I have gone
> through some trouble to support. I really don't want to see that.

You are still not saying what things you have heard. Your concerns can't
be addressed if you don't tell us what they are.

William

[Ian Stakenvicius]

On 2012-07-17, at 7:07 PM, Olivier Crête <tes...@gentoo.org> wrote:

> I'm sure most people can't
> even explain the difference between them.
>

/sbin is for bins that only root should be able to run. easy. :)

[Richard Yao]

On 07/17/2012 08:12 PM, William Hubbs wrote:
>>>> Lastly, don't tell me to read systemd's case for why we should break
>>>> people's systems. I have read it and I find it flawed. There is
>>>> absolutely no need for us to make this change.
>>>
>>> Without elaboration on why you find their case flawed, this sounds
>>> like the typical, "if it isn't broke, don't fix it" argument.
>>> While that has merrit, if there are advantages to doing
>>> something, like I think there would be to doing the /usr merge, it may
>>> be worth the transition, especially if we can make it as smooth as
>>> possible.
>>
>> The cost to benefit ratio is simply too low for "lets change it because
>> it could be better this way" to merit making the change. The things that
>> I have heard are going to break existing systems that I have gone
>> through some trouble to support. I really don't want to see that.
>
> You are still not saying what things you have heard. Your concerns can't
> be addressed if you don't tell us what they are.
>
> William
>

I have yet to see any convincing reason to do this other than "RedHat is
doing it". This change will not make Gentoo a better distribution and it
is simply not worth the pain. Some people appear to think that this is
an urgent issue and I doubt anything I say will change their minds. The
main problem that I have is getting them to accept that they are wrong
that urgent action is needed. I firmly believe that we could wait a few
years before doing anything.

With that said, I have done enough to get the attention of systemd
advocates. Giving you an itemized critique of the systemd documentation
on the list would draw even more attention to myself and I do not want
that. Anything more needs to be said off the list, but quite frankly, I
think what I have said is more than sufficient.

[Rich Freeman]

On Tue, Jul 17, 2012 at 8:34 PM, Richard Yao <ry...@gentoo.org> wrote:
> I have yet to see any convincing reason to do this other than "RedHat is
> doing it". This change will not make Gentoo a better distribution and it
> is simply not worth the pain. Some people appear to think that this is
> an urgent issue and I doubt anything I say will change their minds. The
> main problem that I have is getting them to accept that they are wrong
> that urgent action is needed. I firmly believe that we could wait a few
> years before doing anything.

I don't think anybody else is suggesting doing anything at all in the
first place.

If we don't do anything, then lots of stuff moves to /usr. I think
that is what you're missing. The /usr move basically starts happening
on its own automatically if we DON'T do much. This is because
upstream is the one pushing it.

Few are advocating rushing either - if upstream takes years to make
this happen I doubt it will upset many on this list.

My sense is the general maintainer sentiment is to go with the flow -
they're not going to patch udev/etc to move more stuff into usr, but
they're not gong to patch it to move stuff back out either. If you
really want to support leaving stuff where it is then you or others
need to volunteer to start helping with maintaining these packages,
and deal with any mess it creates.

Rich

[Olivier Crête]

Except when it isn't the case, for example /sbin/ifconfig is a good way
to find one's ip address, etc.

[Olivier Crête]

On Tue, 2012-07-17 at 20:37 -0400, Ian Stakenvicius wrote:

Or you can try this experiment and see what breaks:
chmod og-rwx /sbin/* /usr/sbin/*

[William Hubbs]

Not quite, check out this link [1].

William

[1] http://www.osnews.com/story/25556

[Richard Yao]

On 07/17/2012 08:46 PM, Rich Freeman wrote:
> If we don't do anything, then lots of stuff moves to /usr. I think
> that is what you're missing. The /usr move basically starts happening
> on its own automatically if we DON'T do much. This is because
> upstream is the one pushing it.

Which upstream is pushing this? So far, only RedHat wants this and their
ability to get various upstreams to try to force it is rather limited.
The only upstream where I have seen any indication that this could be
forced is systemd.

[Jeff Horelick]

Forgetting that GNOME is mostly managed by RedHat employees, OpenSuSE
and Mageia tend to follow RedHat's lead....I can probably go on if I
cared to do more research.

[Richard Yao]

GNOME is part of the GNU project, so we should be safe unless they
decide against portability. OpenSuSe and Mageia are other distributions,
so they are not upstream for us.

[Richard Yao]

The difference is simple. You put stuff into /sbin when you do not want
regular users to be able to select it via tab completion by default.

[Duncan]

Richard Yao posted on Tue, 17 Jul 2012 17:20:13 -0400 as excerpted:

> The only thing that might require a merge is systemd and it is not in
> @system. If we offered users the ability to choose rc systems, we would
> still be supporting baselayout-1's rc system. If we start now, we should
> bring that back.

Just addressing this little bit.

The first and primary requirement for gentoo support of any rc/init
system is that there's someone (gentoo dev or not, but baselayout was
gentoo based so gentoo dev, or at least an advanced gentoo user, would be
most likely) interested in maintaining it as upstream, and a gentoo dev
(can be the same person) interested in maintaining the gentoo package/
ebuild. Gentoo's a community distro build on FLOSS, and if nobody's
interested in assuming that work/responsibility for either gentoo or as
upstream, ultimately, it gets tree-cleaned.

Think about it.


Consider things like kde3 and the kde-sunset overlay, too. That's not
system init, but you're likely talking a job of similar size to continue
to support it, with all the necessary initscripts, etc. kde-sunset is
what happens when there's sufficiently interested users but no
sufficiently interested gentoo devs, and/or a break in upstream
maintainership (tho it eventually continued via the trinity project).


Other (not even officially supported) init systems such as systemd that
happen to be in our tree have at least that required minimum, and remain
in the tree. kde3, despite having an active remaining gentoo userbase
that continues to maintain it to some degree, didn't have that minimum.

But I can say this. If there had been a sufficient level of gentoo
developer interest in maintaining kde3 in-tree, it would have happened.
Where there's developer interest, the product says around. There simply
weren't developers stepping up to maintain it, so it ended up in an
overlay.


The same thing applies to baselayout-1... and for that matter,
baselayout-2/openrc. If there had been sufficient developer interest in
maintaining a working baselayout-1, it would have happened. Without it,
no arbitrary ruling, no "if systemd, then baselayout-1", no "thus saith
the council", will change it.

Similarly, no wishing, "should be"s, decrees from council, etc, got
baselayout-2/openrc stabilized, until williamh volunteered to push on it
(certainly with help from others, but it didn't happen until someone
stepped up to take personal responsibility for ensuring that it WOULD
happen) until it got done.


What you're seeing here with the unified / and /usr idea is more or less
a similar dynamic, tho to quite a lessor extent. Upstreams are making
their choices, and the gentoo maintainers of the corresponding packages
are making /their/ choices. That's all there is to it. Upstream's going
its way, but regardless of that, if there's sufficient interest among
gentoo devs to guarantee patch development, testing, deployment, further
testing, stabilization, and bug followup, gentoo WILL continue to make an
initr*-less separate /usr work.

But one of the things that had (at least until recently, I've seen
arguments that it's breaking down now, with android, ubuntu, etc, going
their own way to a greater extent than most before, and android
especially is big enough to pull it off!) kept Linux from fragmenting the
way the old Unices did was that while FLOSS ALLOWS forking, it also
provides significant pressure to ONLY fork where one REALLY feels it's a
high priority deal. Otherwise, it's simply less work and less expense,
to go with upstream. That's why we have all these distributions, each
generally different in their own way (and gentoo's certainly rather
different from the generally binary distros, for sure!), but except for
the features that a particular distro is emphasizing, that it thinks are
important enough to be worth the trouble of maintaining that
differentiation, it tends to stay pretty close to mainline.


Which again, is exactly the dynamic we're seeing here. What we're going
thru right now, with all the threads and discussion related to this, is
simply debating whether, as a distro, gentoo considers this
differentiation from upstream worth the cost of continued maintenance.
Which is where the point I made above comes in. If there's no gentoo
devs caring enough to make it their job to ensure that support remains,
the default will simply be to follow upstream, only maintaining the
minimal patches necessary to continue what gentoo, individually and
collectively, finds high enough priority to be worth the time and effort
cost to maintain the differentiation.

And as of now, just as with kde3, the fact of the matter is that despite
a decent level of interest from users, it doesn't look like we have the
necessary interest from devs to commit to such support, long-term. What
we're seeing is devs committing to maintaining support for the short and
intermediate (?) future, out perhaps six months to a year or two, but the
differentiation cost trend beyond that looks to increase quite
dramatically, and at least at present, we don't have enough developers
willing to commit to maintaining it beyond that.


And the thing is, no "should"s are going to change that. If you (and
other users, personally I'm in the middle, interested but not caring
enough to really commit to it) want it, there's two ways to get it:

1) Start now, and either convince enough current devs or convince to join
enough new devs, so when the time comes, that commitment can be made,
even if it means a significantly increased patch load, to the point of de-
facto or official forking.

2) Get ready for a user-managed overlay, similar to kde-sunset.

Of course the other alternative would be to find a distro more suitable,
but for a lot of gentooers, that's not an alternative they consider
viable, as gentoo's close enough to what they want that there really
/aren't/ a lot of distros even /close/ to suitable, let alone /more/ so.
Of course, both users and distros change over time, and a lot can happen
in two years, but...

Then of course there's the "found your own distro" club... Something
gentoo's founder, Daniel Robbins, has done more than once, now... But of
course just as his current gentoo-based funtoo (and other gentoo-based
distros, after all, gentoo even claims meta-distro, so gentoo-based distro
fits right in!), just because you do your own thing doesn't mean you
can't base on gentoo to whatever degree you want/need, as long as you
maintain compatible licensing and at least semi-compatible package-
management.

--
Duncan - List replies preferred. No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master." Richard Stallman

[Olivier Crête]

That's certainly not how te FHS explains it.

[Olivier Crête]

On Tue, 2012-07-17 at 23:24 -0400, Richard Yao wrote:
> GNOME is part of the GNU project, so we should be safe unless they
> decide against portability. OpenSuSe and Mageia are other distributions,
> so they are not upstream for us.

With my GNOME hat on:

GNOME does not take any marching orders from RMS or anyone else in the
GNU project. We will do any changes that we believe are necessary to
produce a better end user experience or to make our code more
maintainable. If that means adding dependencies that are Linux specific,
we will do it. And we have done it before, for example, we have
dependencies on udev for certain features.

[Michał Górny]

On Tue, 17 Jul 2012 17:20:13 -0400

Richard Yao <ry...@gentoo.org> wrote:

> An often cited benefit of the /usr merge is the ability to put
> everything but /etc on NFS and for that reason, we need to force an
> initramfs on people happily using /usr without it.

Are you going to send a single mail for every single benefit I will add
to the wiki? :>

--
Best regards,
Michał Górny

[Michał Górny]

Now put that definition into my cold logic brain.

[Michał Górny]

On Tue, 17 Jul 2012 17:20:13 -0400
Richard Yao <ry...@gentoo.org> wrote:

> Dear Everyone,
>
> An often cited benefit of the /usr merge is the ability to put
> everything but /etc on NFS and for that reason, we need to force an
> initramfs on people happily using /usr without it.

You forgot about /var. And possibly /srv. But yes, you are probably
having separate filesystems so you don't care about people having
different layout.

> With that said, there is a great deal of FUD being spread by the
> systemd developers and I see no reason for us to accept it. We would
> be breaking users' systems for no gain other than to make the systemd
> developers happy. Their refusal to permit udev to be built separately
> from systemd demonstrated complete disdain for Gentoo Linux. Why
> should we let them dictate how we design our distribution at our
> users' expense?

Didn't you see Lennart's opinions on Gentoo Linux? I don't think their
refusal needed to be expressed at all.

[Duncan]

Michał Górny posted on Wed, 18 Jul 2012 10:18:49 +0200 as excerpted:

> Didn't you see Lennart's opinions on Gentoo Linux? I don't think their
> refusal needed to be expressed at all.

I don't believe I did. Link?

(FWIW I expect I'll eventually switch to systemd, but there's no hurry,
and IMO it has some maturing to do still. Meanwhile, openrc's working
great for me ATM and I have no immediate plans to switch.)

[Michał Górny]

On Wed, 18 Jul 2012 09:49:24 +0000 (UTC)
Duncan <1i5t5....@cox.net> wrote:

> Michał Górny posted on Wed, 18 Jul 2012 10:18:49 +0200 as excerpted:
>
> > Didn't you see Lennart's opinions on Gentoo Linux? I don't think
> > their refusal needed to be expressed at all.
>
> I don't believe I did. Link?

http://lalists.stanford.edu/lad/2009/06/0191.html

Around the non-wrapped line.

[Duncan]

Michał Górny posted on Wed, 18 Jul 2012 11:55:32 +0200 as excerpted:

Thanks. Not too surprising for a major binary-distro dev, I guess.

Meanwhile, I'm more appreciative than ever of gentoo's abilities. Where
else would I be able to run a fully distro-supported kde, without all the
kde semantic-desktop stuff dragging stuff down? Turning it off at
runtime didn't cut it, but killing it at build-time surely did! =:^)

That's an option people running most distros won't ever have; a contrast
they'll never be able to make, at least not without a whole lot more
manual fiddling than necessary on gentoo, anyway.

Makes me really appreciate what we have, here on gentoo.

[Richard Yao]

That was meant as a joke, although the irony is that it is true.

[Canek Peláez Valdés]

On Wed, Jul 18, 2012 at 8:18 AM, Richard Yao <ry...@gentoo.org> wrote:
> On 07/18/2012 04:10 AM, Michał Górny wrote:
>> On Tue, 17 Jul 2012 23:54:16 -0400
>> Richard Yao <ry...@gentoo.org> wrote:

[snip]

>>> The difference is simple. You put stuff into /sbin when you do not
>>> want regular users to be able to select it via tab completion by
>>> default.
>>
>> Now put that definition into my cold logic brain.
>
> That was meant as a joke, although the irony is that it is true.

So, you are rationalizing a posteriori an original irrational decision.

Understanding the bin, sbin, usr/bin , usr/sbin split:
http://lists.busybox.net/pipermail/busybox/2010-December/074114.html

"The /bin vs /usr/bin split (and all the others) is an artifact of
this, a 1970's implementation detail that got carried forward for
decades by bureaucrats who never question _why_ they're doing things.
It stopped making any sense before Linux was ever invented, for
multiple reasons"

I don't mind the merge of /bin, /usr/bin, /sbin and /usr/sbin;
moreover, I want an even more radical change:

/usr -> /System
/home -> /Users
/etc -> /Config

Why should we care about ancient filesystems that didn't supported
long paths, and therefore we got stuck with /usr since we didn't
wanted to waste another *single* character to make it /user?

Let that silly legacy stuff die. Keep symbolic links to the old
directories for compatibility reasons, if you want to (modern software
should not need it anyhow), and move on. Remember /usr/X11R6? We kept
a /usr/X11R6 -> /usr link for years. Do you miss it?

I surely not. Regards.
--
Canek Peláez Valdés
Posgrado en Ciencia e Ingeniería de la Computación
Universidad Nacional Autónoma de México

[Walter Dnes]

On Tue, Jul 17, 2012 at 07:12:09PM -0500, William Hubbs wrote

> On Tue, Jul 17, 2012 at 07:19:48PM -0400, Richard Yao wrote:
> >
> > Looking at @system and what it typically pulls into @world, the only
> > thing that might cause a problem is udev, although virtual/dev-manager
> > is in @system, rather than udev. If that happens, we have a few ways of
> > dealing with that:
> >
> > 1. Patch udev.
>
> I think I can come up with a patch locally that will read rules from
> /lib/udev/rules.d if that's what we want to do for now.
>
> > 2. Fork udev.
>
> I don't think this is necessary, and it would create more work for us
> than is needed.

3. More support for mdev; e.g. https://wiki.gentoo.org/wiki/Mdev and
(still in beta) https://wiki.gentoo.org/wiki/Mdev/Automount_USB The
next challenge is "custom mdev rules", which should be do-able.

--
Walter Dnes <walt...@waltdnes.org>

[Hobbit]

> Why should we care about ancient filesystems that didn't supported
> long paths, and therefore we got stuck with /usr since we didn't
> wanted to waste another *single* character to make it /user?

Because of it's original name: "UNIX System Resources" (usr).

[William Hubbs]

Actually this is not correct (see my earlier post with the link to
osnews.com).
Originally it contained user directories like /home does now.

William

[Hobbit]

On 11:26 Wed 18 Jul , William Hubbs wrote:
> Actually this is not correct (see my earlier post with the link to
> osnews.com).

Indeed. My bad.

[Canek Peláez Valdés]

As William pointed out, this is just another silly rationalization
done after the fact. But, just for argument's sake, lets suppose that
"usr" was named like that because it was the acronym for "UNIX System
Resources".

*Who cares about that now?* It was 43 years ago. My cellphone is
thousands of times faster than the PDP-7 Unix was originally developed
for, and it has millions of times more storage. The length
restrictions imposed on system directories are completely superfluous
now.

All the arguments for keeping /bin, /sbin, /usr/bin, and /usr/sbin
separated are really instances of the Chewbacca defense [1]. They just
don't make any sense.

If upstream projects want to move everything to one location, Gentoo
should follow suit. If enough Gentoo devs (as others had argued) want
to waste their efforts in maintaining this artificial and silly
division between /bin, /sbin, /usr/bin, and /usr/sbin, it is of course
their prerogative. But it must be clear that all the rationale behind
said division was invented after the fact, and (as Rob Landley said in
his email [2]) maintained "for decades by bureaucrats who never

question _why_ they're doing things".

Regards.

[1] http://en.wikipedia.org/wiki/Chewbacca_defense
[2] http://lists.busybox.net/pipermail/busybox/2010-December/074114.html

[Ciaran McCreesh]

On Wed, 18 Jul 2012 12:35:58 -0500
Canek Peláez Valdés <can...@gmail.com> wrote:
> All the arguments for keeping /bin, /sbin, /usr/bin, and /usr/sbin
> separated are really instances of the Chewbacca defense [1]. They just
> don't make any sense.

All the arguments for changing things are just realising that the horse
has fled the barn and then trying to rationalise not needing a horse.

--
Ciaran McCreesh

[Jason A. Donenfeld]

On Wed, Jul 18, 2012 at 1:07 AM, Olivier Crête <tes...@gentoo.org> wrote:
> Also be ready for a merge of /bin and /sbin.. I'm sure most people can't
> even explain the difference between them.

Whoa hey what why? Who's pushing this forward?

[Michał Górny]

I believe I don't need a horse. I don't even have a barn either.

[Maxim Kammerer]

On Wed, Jul 18, 2012 at 8:35 PM, Canek Peláez Valdés <can...@gmail.com> wrote:
> But it must be clear that all the rationale behind
> said division was invented after the fact,

I would say that the rationale was not “invented”, but rather adapted
to an evolving system.

> and (as Rob Landley said in
> his email [2]) maintained "for decades by bureaucrats who never
> question _why_ they're doing things".

I am surprised that anyone took that rant seriously. It is just a
rant, ignoring evolution of systems (where initially arbitrary
configuration changes and gets meaning with time), and treating
developers who have to deal with backwards compatibility issues and
established usage conventions as thick bureaucrats.

--
Maxim Kammerer
Liberté Linux: http://dee.su/liberte

[Michael Mol]

On Wed, Jul 18, 2012 at 11:04 AM, Canek Peláez Valdés <can...@gmail.com> wrote:
> I don't mind the merge of /bin, /usr/bin, /sbin and /usr/sbin;
> moreover, I want an even more radical change:
>
> /usr -> /System
> /home -> /Users
> /etc -> /Config

This would be a terrible idea, IMO. If you can rationalize this, why
not any of these?

/etc -> /設定
/etc -> /组态
/etc -> /組態
/etc -> /configuración

Codes (and things like 'usr', 'etc' and 'home' are codes) may not be
the most intuitive, but they have roughly the same difficulty
regardless of your source language.

Worse, I think /home to /Users is an *egregiously* poor choice; any
native English speaker who has rudimenatry (or even intimate)
knowledge of how things previously worked would be very likely to
confuse /Users with the historical /usr.

> Why should we care about ancient filesystems that didn't supported
> long paths, and therefore we got stuck with /usr since we didn't
> wanted to waste another *single* character to make it /user?
>
> Let that silly legacy stuff die. Keep symbolic links to the old
> directories for compatibility reasons, if you want to (modern software
> should not need it anyhow), and move on. Remember /usr/X11R6? We kept
> a /usr/X11R6 -> /usr link for years. Do you miss it?

The longer something exists, the more things like procedures and best
practices grow to depend on it both explicitly and implicitly. There's
a lot of stuff out there which assumes the existing structure. Stuff
that people don't necessarily even think about any more, because it
just works.

Grossly changing the filesystem layout does worse than make
maintenance of known software more difficult, it changes a lot of
longstanding assumptions for ancient, still-functional code written
ages upon ages ago, and it makes it that much more difficult to
install new software onto production systems which have been running
for decades.

That's the legacy of being a UNIX-alike. Heck, I know a local guy who
has to struggle to get newish versions of Python, CUPS and other
things onto an AIX box, because those are the tools he has to use to
satisfy company needs. Based on IRC conversations, it sounds like he
spends at least 5% of his time (that *I* know about, anyway) trying to
wedge new software into old systems.

Change almost always breaks more things than you expect, because you
only expect the things you remembered to consider, not the things you
forgot existed.

Ugh. I've gone offtopic. This email went from having anything to do
with udev to being about filesystems layouts.

--
:wq

[Jason A. Donenfeld]

On Wed, Jul 18, 2012 at 5:35 PM, Walter Dnes <walt...@waltdnes.org> wrote:
>
> 3. More support for mdev; e.g. https://wiki.gentoo.org/wiki/Mdev and
> (still in beta) https://wiki.gentoo.org/wiki/Mdev/Automount_USB The
> next challenge is "custom mdev rules", which should be do-able.

Innnnnteresting. Can you talk more about the benefits of mdev in
non-embedded systems? Why would I want to use this instead of udev
(aside from the /usr dispute).

[Fabian Groffen]

On 18-07-2012 14:11:07 -0400, Michael Mol wrote:
> Worse, I think /home to /Users is an *egregiously* poor choice; any
> native English speaker who has rudimenatry (or even intimate)
> knowledge of how things previously worked would be very likely to
> confuse /Users with the historical /usr.

You *are* aware OSX uses this, right?

> ... Heck, I know a local guy who

> has to struggle to get newish versions of Python, CUPS and other
> things onto an AIX box, because those are the tools he has to use to
> satisfy company needs. Based on IRC conversations, it sounds like he
> spends at least 5% of his time (that *I* know about, anyway) trying to
> wedge new software into old systems.

How is this related to something like a /usr merge?

> Ugh. I've gone offtopic. This email went from having anything to do
> with udev to being about filesystems layouts.

Seems to me we're in a different thread here :)


--
Fabian Groffen
Gentoo on a different level

[Michał Górny]

I don't think we should give more support to building a system from
a statically linked rescue suite tool.

[Michael Mol]

To carry the analogy, udev forcing a /usr merge is much like "We don't
need a horse, so we don't think anyone else should have one, either.
If they need a horse, they can use one of those newfangled tractors."

Personally, I think the original reasoning behind udev's move was
flawed. When I read it, it sounded like "we can't control whether or
not anyone else puts boot-required packages into /usr before /usr has
been mounted. In order to cover for those packages, we'll force the
issue by putting ourselves there."

I think that any package which puts boot-required things into a path
which may not be available at boot time is inherently broken, and
needs to be fixed. There's absolutely nothing about the move which
both accounts for boot-required packages requiring access to /var
_and_ a sysadmin's need to have /var as a special mount point.

To me, it looks a lot like what once was / is now expected to be an
initramfs, which I find extraordinarily problematic, for the following
reasons:

1) There are no truly mature tools for automatically generating and
installing an initramfs based on system requirements. Canek likes to
recommend dracut, which still isn't marked stable. I've gotten stable
genkernel to work reasonably, but its error reporting is terrible.
2) There's no good means for applying software and security updates to
an initramfs. If having an initramfs is to be considered the new
normal, there should be some means of updating it as part of routine
system updates.
3) With an initramfs and the tools to generate it, we have more moving
parts were previously there were few.

--
:wq

[Alec Warner]

Debian uses initramfs-tools...

[Michael Mol]

On Wed, Jul 18, 2012 at 2:47 PM, Alec Warner <ant...@gentoo.org> wrote:
> On Wed, Jul 18, 2012 at 8:25 PM, Michael Mol <mik...@gmail.com> wrote:

[snip]

>> To me, it looks a lot like what once was / is now expected to be an
>> initramfs, which I find extraordinarily problematic, for the following
>> reasons:
>>
>> 1) There are no truly mature tools for automatically generating and
>> installing an initramfs based on system requirements. Canek likes to
>> recommend dracut, which still isn't marked stable. I've gotten stable
>> genkernel to work reasonably, but its error reporting is terrible.
>> 2) There's no good means for applying software and security updates to
>> an initramfs. If having an initramfs is to be considered the new
>> normal, there should be some means of updating it as part of routine
>> system updates.
>
> Debian uses initramfs-tools...

AFAIK, neither genkernel nor dracut were expected to get tied to the
Gentoo update process. Has that changed?

--
:wq

[Canek Peláez Valdés]

On Wed, Jul 18, 2012 at 1:53 PM, Michael Mol <mik...@gmail.com> wrote:
> On Wed, Jul 18, 2012 at 2:47 PM, Alec Warner <ant...@gentoo.org> wrote:

[snip]

>> Debian uses initramfs-tools...
>
> AFAIK, neither genkernel nor dracut were expected to get tied to the
> Gentoo update process. Has that changed?

The kernel you are running (if you update your machine) is not tied to
the Gentoo update process. The *source code* gets installed, but the
kernel source remains unchanged in /usr/src/whatever. It's the user
responsibility to configure, compile, and install the kernel (and then
update LILO, grub-legacy or GRUB2). It can be automated with (ta-da)
genkernel, but it's not "tied to the Gentoo update process".

I really don't see that much difference with needing to also update
the initramfs, if needed.

Because, besides, if your /usr is not in a different partition, you
don't even *need* an initramfs. In that case not using an initramfs is
supported by all upstreams.

Regards.

[Rich Freeman]

On Wed, Jul 18, 2012 at 2:53 PM, Michael Mol <mik...@gmail.com> wrote:
> AFAIK, neither genkernel nor dracut were expected to get tied to the
> Gentoo update process. Has that changed?

We don't even update kernels as part of the regular update process,
let alone initramfs systems.

In general you update them together.

The only issue I could see is if problems arise if you have a
different version of udev in your initramfs than on your system. I
don't know if that actually causes problems. For the most part after
the system is booted the initramfs is done its job.

If some package did need a kernel/initramfs/etc to be updated it
should be the subject of news or an ewarn unless it becomes routine
practice. I don't think we want the system to start touching these
things without operator intervention unless we make it really
bulletproof like they do on big distros (the only reason they can is
they have one-size-fits-all kernels and initramfs designs).

Rich

[Michael Mol]

On Wed, Jul 18, 2012 at 3:03 PM, Canek Peláez Valdés <can...@gmail.com> wrote:
> On Wed, Jul 18, 2012 at 1:53 PM, Michael Mol <mik...@gmail.com> wrote:
>> On Wed, Jul 18, 2012 at 2:47 PM, Alec Warner <ant...@gentoo.org> wrote:
> [snip]
>>> Debian uses initramfs-tools...
>>
>> AFAIK, neither genkernel nor dracut were expected to get tied to the
>> Gentoo update process. Has that changed?
>
> The kernel you are running (if you update your machine) is not tied to
> the Gentoo update process. The *source code* gets installed, but the
> kernel source remains unchanged in /usr/src/whatever. It's the user
> responsibility to configure, compile, and install the kernel (and then
> update LILO, grub-legacy or GRUB2). It can be automated with (ta-da)
> genkernel, but it's not "tied to the Gentoo update process".
>
> I really don't see that much difference with needing to also update
> the initramfs, if needed.

What if your DNS resolver in your rescue shell has a vulnerability?
What if wget, links or whatever network tools you use during recovery
have a vulnerability?

These are tools which are commonly placed in initramfs.

>
> Because, besides, if your /usr is not in a different partition, you
> don't even *need* an initramfs. In that case not using an initramfs is
> supported by all upstreams.

And what of /var? /opt? The problem with the /usr merge upstream is
that someone didn't think things through when they pushed it, and the
same reasoning used to justify it easily justifies changing the way
/var and /opt are treated.

--
:wq

[Michał Górny]

On Wed, 18 Jul 2012 15:12:14 -0400

Michael Mol <mik...@gmail.com> wrote:

> On Wed, Jul 18, 2012 at 3:03 PM, Canek Peláez Valdés
> <can...@gmail.com> wrote:
> > On Wed, Jul 18, 2012 at 1:53 PM, Michael Mol <mik...@gmail.com>
> > wrote:
> >> On Wed, Jul 18, 2012 at 2:47 PM, Alec Warner <ant...@gentoo.org>
> >> wrote:
> > [snip]
> >>> Debian uses initramfs-tools...
> >>
> >> AFAIK, neither genkernel nor dracut were expected to get tied to
> >> the Gentoo update process. Has that changed?
> >
> > The kernel you are running (if you update your machine) is not tied
> > to the Gentoo update process. The *source code* gets installed, but
> > the kernel source remains unchanged in /usr/src/whatever. It's the
> > user responsibility to configure, compile, and install the kernel
> > (and then update LILO, grub-legacy or GRUB2). It can be automated
> > with (ta-da) genkernel, but it's not "tied to the Gentoo update
> > process".
> >
> > I really don't see that much difference with needing to also update
> > the initramfs, if needed.
>
> What if your DNS resolver in your rescue shell has a vulnerability?
> What if wget, links or whatever network tools you use during recovery
> have a vulnerability?

What if whatever tools you have in rootfs have a vulnerability and they
are statically linked so that we don't have to move half of the system
into rootfs?

> > Because, besides, if your /usr is not in a different partition, you
> > don't even *need* an initramfs. In that case not using an initramfs
> > is supported by all upstreams.
>
> And what of /var? /opt? The problem with the /usr merge upstream is
> that someone didn't think things through when they pushed it, and the
> same reasoning used to justify it easily justifies changing the way
> /var and /opt are treated.

What with them? /var has a special place of its own, and I don't see
why it is brought here.

/opt is a defined prefix. Like /usr is. Moving anything into or out of
it is a completely separate topic.

[Canek Peláez Valdés]

On Wed, Jul 18, 2012 at 2:18 PM, Michael Mol <mik...@gmail.com> wrote:

> On Wed, Jul 18, 2012 at 3:05 PM, Rich Freeman <ri...@gentoo.org> wrote:
>> On Wed, Jul 18, 2012 at 2:53 PM, Michael Mol <mik...@gmail.com> wrote:
>>> AFAIK, neither genkernel nor dracut were expected to get tied to the
>>> Gentoo update process. Has that changed?
>>
>> We don't even update kernels as part of the regular update process,
>> let alone initramfs systems.
>>
>> In general you update them together.
>>
>> The only issue I could see is if problems arise if you have a
>> different version of udev in your initramfs than on your system. I
>> don't know if that actually causes problems. For the most part after
>> the system is booted the initramfs is done its job.
>

> The most widely touted benefit I've heard for initramfs is its
> capability to ease system recovery in case, e.g. a critical filesystem
> refuses to mount. With recovery roles come recovery tools, which
> quickly extends network-aware tools and a security attack surface.

The real benefit is that it allows you to mount any partition, if the
tools to mount it live in the same partition. Recovering tools can be
put in the initramfs, but I don't think nobody actually thinks that
this is the "most widely touted benefit". Again, citation please.

> Hence why I tend to feel that if an initramfs is going to become the
> go-to solution for bootstrapping userland, it's important to consider
> the difficulties of keeping the packed tools up-to-date; it's not just
> a bootstrap tool, it's also the first recovery option a sysadmin
> faces.

If you keep your initramfs synchronized (which is easily done with
dracut, for example), that problem goes away.

Regards.

[Canek Peláez Valdés]

On Wed, Jul 18, 2012 at 2:12 PM, Michael Mol <mik...@gmail.com> wrote:
> On Wed, Jul 18, 2012 at 3:03 PM, Canek Peláez Valdés <can...@gmail.com> wrote:
>> On Wed, Jul 18, 2012 at 1:53 PM, Michael Mol <mik...@gmail.com> wrote:
>>> On Wed, Jul 18, 2012 at 2:47 PM, Alec Warner <ant...@gentoo.org> wrote:
>> [snip]
>>>> Debian uses initramfs-tools...
>>>
>>> AFAIK, neither genkernel nor dracut were expected to get tied to the
>>> Gentoo update process. Has that changed?
>>
>> The kernel you are running (if you update your machine) is not tied to
>> the Gentoo update process. The *source code* gets installed, but the
>> kernel source remains unchanged in /usr/src/whatever. It's the user
>> responsibility to configure, compile, and install the kernel (and then
>> update LILO, grub-legacy or GRUB2). It can be automated with (ta-da)
>> genkernel, but it's not "tied to the Gentoo update process".
>>
>> I really don't see that much difference with needing to also update
>> the initramfs, if needed.
>
> What if your DNS resolver in your rescue shell has a vulnerability?
> What if wget, links or whatever network tools you use during recovery
> have a vulnerability?
>
> These are tools which are commonly placed in initramfs.

First of all, none of this has nothing to do with the discussion at
hand. Second, I don't know what kind of initramfs you are familiar
with, but mine has nothing network related, and I don't see *any*
reason to include *anything* network related to an initramfs.

>> Because, besides, if your /usr is not in a different partition, you
>> don't even *need* an initramfs. In that case not using an initramfs is
>> supported by all upstreams.
>
> And what of /var? /opt?

What about them? Again, what it has this anything to do with our
current discussion?

> The problem with the /usr merge upstream is
> that someone didn't think things through when they pushed it, and the
> same reasoning used to justify it easily justifies changing the way
> /var and /opt are treated.

That's pure speculation. Nobody has ever suggested merging /opt nor
/var; if I'm mistaken I would love to see even a single link (mail,
blog post, IRC discussion) were it was at least mentioned as a good
idea to do the same with /opt or /var. I'm pretty sure you don't have
any.

[Michael Mol]

On Wed, Jul 18, 2012 at 3:05 PM, Rich Freeman <ri...@gentoo.org> wrote:

> On Wed, Jul 18, 2012 at 2:53 PM, Michael Mol <mik...@gmail.com> wrote:
>> AFAIK, neither genkernel nor dracut were expected to get tied to the
>> Gentoo update process. Has that changed?
>
> We don't even update kernels as part of the regular update process,
> let alone initramfs systems.
>
> In general you update them together.
>
> The only issue I could see is if problems arise if you have a
> different version of udev in your initramfs than on your system. I
> don't know if that actually causes problems. For the most part after
> the system is booted the initramfs is done its job.

The most widely touted benefit I've heard for initramfs is its
capability to ease system recovery in case, e.g. a critical filesystem
refuses to mount. With recovery roles come recovery tools, which
quickly extends network-aware tools and a security attack surface.

Hence why I tend to feel that if an initramfs is going to become the
go-to solution for bootstrapping userland, it's important to consider
the difficulties of keeping the packed tools up-to-date; it's not just
a bootstrap tool, it's also the first recovery option a sysadmin
faces.

>

> If some package did need a kernel/initramfs/etc to be updated it
> should be the subject of news or an ewarn unless it becomes routine
> practice. I don't think we want the system to start touching these
> things without operator intervention unless we make it really
> bulletproof like they do on big distros (the only reason they can is
> they have one-size-fits-all kernels and initramfs designs).

Absolutely.

--
:wq

[Michael Mol]

On Wed, Jul 18, 2012 at 3:20 PM, Canek Peláez Valdés <can...@gmail.com> wrote:
> On Wed, Jul 18, 2012 at 2:12 PM, Michael Mol <mik...@gmail.com> wrote:
>> On Wed, Jul 18, 2012 at 3:03 PM, Canek Peláez Valdés <can...@gmail.com> wrote:
>>> On Wed, Jul 18, 2012 at 1:53 PM, Michael Mol <mik...@gmail.com> wrote:
>>>> On Wed, Jul 18, 2012 at 2:47 PM, Alec Warner <ant...@gentoo.org> wrote:
>>> [snip]
>>>>> Debian uses initramfs-tools...
>>>>
>>>> AFAIK, neither genkernel nor dracut were expected to get tied to the
>>>> Gentoo update process. Has that changed?
>>>
>>> The kernel you are running (if you update your machine) is not tied to
>>> the Gentoo update process. The *source code* gets installed, but the
>>> kernel source remains unchanged in /usr/src/whatever. It's the user
>>> responsibility to configure, compile, and install the kernel (and then
>>> update LILO, grub-legacy or GRUB2). It can be automated with (ta-da)
>>> genkernel, but it's not "tied to the Gentoo update process".
>>>
>>> I really don't see that much difference with needing to also update
>>> the initramfs, if needed.
>>
>> What if your DNS resolver in your rescue shell has a vulnerability?
>> What if wget, links or whatever network tools you use during recovery
>> have a vulnerability?
>>
>> These are tools which are commonly placed in initramfs.
>
> First of all, none of this has nothing to do with the discussion at
> hand.

I completely disagree. If you take a step in a direction, you have
momentum. So before you take a step in that direction, you should look
where that momentum will carry you.

> Second, I don't know what kind of initramfs you are familiar
> with, but mine has nothing network related, and I don't see *any*
> reason to include *anything* network related to an initramfs.

So your initramfs doesn't include network tools such as ping,
traceroute or wget. Fine. Fundamentally speaking, why shouldn't
someone else's?

>
>>> Because, besides, if your /usr is not in a different partition, you
>>> don't even *need* an initramfs. In that case not using an initramfs is
>>> supported by all upstreams.
>>
>> And what of /var? /opt?
>
> What about them? Again, what it has this anything to do with our
> current discussion?

See my reply to Michal.

>
>> The problem with the /usr merge upstream is
>> that someone didn't think things through when they pushed it, and the
>> same reasoning used to justify it easily justifies changing the way
>> /var and /opt are treated.
>
> That's pure speculation.

I'll repeat myself. If you take a step, you have momentum. Before you
take a step, you should see where that momentum will carry you.

> Nobody has ever suggested merging /opt nor
> /var; if I'm mistaken I would love to see even a single link (mail,
> blog post, IRC discussion) were it was at least mentioned as a good
> idea to do the same with /opt or /var. I'm pretty sure you don't have
> any.

I don't believe anyone *does* think it's a good idea, but I don't see
how the arguments on behalf of a /usr merge don't operate in the same
way on /var or /opt. If the argument is flawed for either of those
two, I don't see how it isn't equally flawed for /usr. I've never seen
where people have examined that in depth.

--
:wq

[Michael Mol]

On Wed, Jul 18, 2012 at 3:25 PM, Canek Peláez Valdés <can...@gmail.com> wrote:
> On Wed, Jul 18, 2012 at 2:18 PM, Michael Mol <mik...@gmail.com> wrote:
>> On Wed, Jul 18, 2012 at 3:05 PM, Rich Freeman <ri...@gentoo.org> wrote:
>>> On Wed, Jul 18, 2012 at 2:53 PM, Michael Mol <mik...@gmail.com> wrote:
>>>> AFAIK, neither genkernel nor dracut were expected to get tied to the
>>>> Gentoo update process. Has that changed?
>>>
>>> We don't even update kernels as part of the regular update process,
>>> let alone initramfs systems.
>>>
>>> In general you update them together.
>>>
>>> The only issue I could see is if problems arise if you have a
>>> different version of udev in your initramfs than on your system. I
>>> don't know if that actually causes problems. For the most part after
>>> the system is booted the initramfs is done its job.
>>
>> The most widely touted benefit I've heard for initramfs is its
>> capability to ease system recovery in case, e.g. a critical filesystem
>> refuses to mount. With recovery roles come recovery tools, which
>> quickly extends network-aware tools and a security attack surface.
>
> The real benefit is that it allows you to mount any partition, if the
> tools to mount it live in the same partition.

Certainly that's a benefit.

> Recovering tools can be
> put in the initramfs, but I don't think nobody actually thinks that
> this is the "most widely touted benefit". Again, citation please.

I'm sorry, but I'm not going to grep through almost a decade of IRC
logs to find every discussion where someone says 'well, just put $tool
in your {initramfs,initrd}.' It's definitely something I've seen a
number of times. I *know* I've heard the line more than once in LUG
meetings, from people who hand-build theirs, but given that's a
local-to-me thing, you probably wouldn't know most of them by name.

>
>> Hence why I tend to feel that if an initramfs is going to become the
>> go-to solution for bootstrapping userland, it's important to consider
>> the difficulties of keeping the packed tools up-to-date; it's not just
>> a bootstrap tool, it's also the first recovery option a sysadmin
>> faces.
>
> If you keep your initramfs synchronized (which is easily done with
> dracut, for example), that problem goes away.

Again, dracut isn't stable, genkernel isn't part of any normal routine
system update, and I hold the same trepidations expressed by Rich
about limitations on circumstances where that's even appropriate.
--
:wq

[Ian Stakenvicius]

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

On 18/07/12 03:47 PM, Michael Mol wrote:
> On Wed, Jul 18, 2012 at 3:25 PM, Canek Peláez Valdés
> <can...@gmail.com> wrote:
>> On Wed, Jul 18, 2012 at 2:18 PM, Michael Mol <mik...@gmail.com>
>> wrote:
>>
>> The real benefit is that it allows you to mount any partition, if
>> the tools to mount it live in the same partition.
>
> Certainly that's a benefit.
>

...don't you mean, "if the tools to mount it live in the initramfs" ??

if the partition isn't mounted I don't see how the initramfs will
allow you to mount it using its own tools...
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)

iF4EAREIAAYFAlAHE3QACgkQ2ugaI38ACPDQBwD9HOn8skOvLhpPYuqCnH1Nuh7e
zefAwVaHDQQsz9vKVeYA/1utNcF2ROdeiHlMfvte4TGH42lo+NOjdM1Ml0wpU9b/
=5AMo
-----END PGP SIGNATURE-----

[Michael Mol]

On Wed, Jul 18, 2012 at 3:50 PM, Ian Stakenvicius <a...@gentoo.org> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> On 18/07/12 03:47 PM, Michael Mol wrote:
>> On Wed, Jul 18, 2012 at 3:25 PM, Canek Peláez Valdés
>> <can...@gmail.com> wrote:
>>> On Wed, Jul 18, 2012 at 2:18 PM, Michael Mol <mik...@gmail.com>
>>> wrote:
>>>
>>> The real benefit is that it allows you to mount any partition, if
>>> the tools to mount it live in the same partition.
>>
>> Certainly that's a benefit.
>>
>
> ...don't you mean, "if the tools to mount it live in the initramfs" ??
>
> if the partition isn't mounted I don't see how the initramfs will
> allow you to mount it using its own tools...

I think you're replying to Canek. I took it to mean that having an
initramfs allows you to mount the very filesystems where you would
_traditionally_ expect to find the tools. E.g., being able to mount an
encrypted /.

--
:wq

[Ian Stakenvicius]

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

Yeah i was.. i just wanted to re-emphasize the point that the tools
to mount it need to be on the initramfs (in whatever version or form
they were when the initramfs was built), and really have nothing to do
with them (including their current and possibly more up-to-date
version) living on said partition..

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

iF4EAREIAAYFAlAHFZUACgkQ2ugaI38ACPAiMAD/eWHxvaZPu1ikYN9ZeClsEWnB
pBDgfVPC0UTDeoUOVFcA+gKCmqa+lhs0x+arJhF7AZfWEbYb+jMK+bVxUVgfElR4
=O0O4
-----END PGP SIGNATURE-----

[Rich Freeman]

On Wed, Jul 18, 2012 at 3:40 PM, Michael Mol <mik...@gmail.com> wrote:
> So your initramfs doesn't include network tools such as ping,
> traceroute or wget. Fine. Fundamentally speaking, why shouldn't
> someone else's?

So, an initramfs is just a piece of kernel functionality. You can do
almost ANYTHING in an initramfs, subject to the limitation that it is
stored in RAM without any backing store.

There are lots of reasons to use an initramfs, and the biggest ones
don't pertain much to Gentoo. Here are some of the big use cases:

1. One-size-fits-all kernel. You want to support root and /usr on
any filesystem, on any kind of hard drive, or on a SAN, or who knows
where. That either means saying Y to every driver in the kernel, or
saying M and using an initramfs to load what is needed to get to root.

2. One-size-fits-all grub config. You put the smarts in the
initramfs, and use filesystem labels and such to identify partitions.

3. Use of labels/UUIDs on partitions. When mdadm decides to renumber
half your devices on a whim or you add a drive and everything bubbles
down by one, your system still boots.

4. Cleaner mounting of root, ability to fsck on initial mount, etc.

5. When something goes wrong you can get a dash/bash shell instead of
a grub shell. The former is clearly more useful even if you don't
have firefox+X11 in your initramfs.

6. Support for booting off of stuff that the kernel can't find on its
own, like SANs/etc. That might require network support in the
initramfs, and that usually isn't a big deal. If somebody can spoof
DNS on your fiber channel interface you've got bigger problems.

Sure, the more you do with the initramfs the bigger the potential
security risks. Most distros don't have users build either kernels or
initramfs which means they can just push updates, but that requires #1
above, which I think most Gentoo users would not appreciate.

However, the initramfs shouldn't leave much of anything running after
it chroots, so the window should be fairly small.

Rich

[Alec Warner]

I'm not really following your logic here, so forgive me. I completely
understand why folks do not say, rebuild their kernel when it is
updated (kernel configs are annoying.)

However lets say I have coreutils in / and coreutils in my initramfs.
I upgrade coreutils from v1 to v2. Are you saying that you are too
afraid to update coreutils in / and then also update it in the
initramfs (probably by running $TOOL to copy coreutils from / to
initramfs-root.)

I'm not suggesting that we necessarily do this automatically, just
that people claim 'the tools do not exist to do this now' when in fact
it seems fairly straightforward to do.

I mean presumably you used $TOOL to build the initramfs once, so
running $TOOL again to generate a new initramfs probably should not
screw you, provided you have control over the configuration of $TOOL.

-A

>
> Rich
>

[Ian Stakenvicius]

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

On 18/07/12 04:05 PM, Alec Warner wrote:
> [...] However lets say I have coreutils in / and coreutils in my

> initramfs. I upgrade coreutils from v1 to v2. Are you saying that
> you are too afraid to update coreutils in / and then also update it
> in the initramfs (probably by running $TOOL to copy coreutils from
> / to initramfs-root.)
>
> I'm not suggesting that we necessarily do this automatically, just
> that people claim 'the tools do not exist to do this now' when in
> fact it seems fairly straightforward to do.
>
> I mean presumably you used $TOOL to build the initramfs once, so
> running $TOOL again to generate a new initramfs probably should
> not screw you, provided you have control over the configuration of
> $TOOL.

IIRC, and unless this has changed recently (ie within the last year or
two), a genkernel-generated initramfs is built on specific versions of
all the tools that genkernel itself ensures is downloaded, ie, *NOT*
the same versions as are installed in your / , and often are actually
older.

You can, of course, change this via /etc/genkernel.conf for each tool.

..so in that particular case, one would want their initramfs
regenerated when genkernel gets upgraded (but after
/etc/genkernel.conf is etc-update'd)


If I remember my hearsay correctly, dracut does build the initramfs
from tools on / , though...?

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

iF4EAREIAAYFAlAHGFAACgkQ2ugaI38ACPCjlAD/Qin9JKK6SFAr/5G2vjgqJmau
BATFNwP/nbgtIb5i0rgA/jlEmZFBK9n14GOYzQxi3BJewGhRvi62WAHsX7EMQzDL
=HLZG
-----END PGP SIGNATURE-----

[Michael Mol]

On Wed, Jul 18, 2012 at 4:02 PM, Rich Freeman <ri...@gentoo.org> wrote:
> On Wed, Jul 18, 2012 at 3:40 PM, Michael Mol <mik...@gmail.com> wrote:
>> So your initramfs doesn't include network tools such as ping,
>> traceroute or wget. Fine. Fundamentally speaking, why shouldn't
>> someone else's?
>
> So, an initramfs is just a piece of kernel functionality. You can do
> almost ANYTHING in an initramfs, subject to the limitation that it is
> stored in RAM without any backing store.

Yup. IIRC, it has effectively the same underlying implementation as
tmpfs, using always-dirty file cache pages.

>
> There are lots of reasons to use an initramfs, and the biggest ones
> don't pertain much to Gentoo. Here are some of the big use cases:
>
> 1. One-size-fits-all kernel. You want to support root and /usr on
> any filesystem, on any kind of hard drive, or on a SAN, or who knows
> where. That either means saying Y to every driver in the kernel, or
> saying M and using an initramfs to load what is needed to get to root.
>
> 2. One-size-fits-all grub config. You put the smarts in the
> initramfs, and use filesystem labels and such to identify partitions.
>
> 3. Use of labels/UUIDs on partitions. When mdadm decides to renumber
> half your devices on a whim or you add a drive and everything bubbles
> down by one, your system still boots.
>
> 4. Cleaner mounting of root, ability to fsck on initial mount, etc.
>
> 5. When something goes wrong you can get a dash/bash shell instead of
> a grub shell. The former is clearly more useful even if you don't
> have firefox+X11 in your initramfs.
>
> 6. Support for booting off of stuff that the kernel can't find on its
> own, like SANs/etc. That might require network support in the
> initramfs, and that usually isn't a big deal. If somebody can spoof
> DNS on your fiber channel interface you've got bigger problems.
>
> Sure, the more you do with the initramfs the bigger the potential
> security risks. Most distros don't have users build either kernels or
> initramfs which means they can just push updates, but that requires #1
> above, which I think most Gentoo users would not appreciate.

I fall into use cases 3 and 5, myself. Incidentally, bash is also
network-aware. (Not sure if the default USE flag set allows it,
though.) Were I to explicitly add network-aware tools, I'd probably
add either ssh/sftp/scp or links.

>
> However, the initramfs shouldn't leave much of anything running after
> it chroots, so the window should be fairly small.

So is the window for spoofing DNS responses. That didn't stop DNS
hijacking from being fairly easy. (And why there was a large
coordinated, cross-vendor effort to add source-port randomization once
it was shown to be easy.)

Multi-threaded native code has been my day job for the last five
years. I may be a bit biased when it comes to race conditions.

--
:wq

[Peter Stuge]

Rich Freeman wrote:
> 5. When something goes wrong you can get a dash/bash shell

..

> useful even if you don't have firefox+X11 in your initramfs.

This is one of the first videographed use cases for coreboot.

The initramfs in the video[1] admittedly does not have a browser.

Those days, boot flash were up to 2 Mbyte. Today they are up to 16
Mbyte, so a browser can certainly be added.

http://www.coreboot.org/Screenshots#LinuxBIOS_with_X_Server_Inside


//Peter

[1] http://www.youtube.com/watch?v=nuzRsXKm_NQ
[1] http://downloads.sourceforge.net/fornix/linuxbios.ogg

[llemi...@aol.com]

In the beginning there were root (/bin) and /usr programs

See UNIX Programmer's Manual (Thompson, Ritchie, November
1971). [http://cm.bell-labs.com/cm/cs/who/dmr/manintro.pdf]

/usr programs were "not considered part of the UNIX system"
[bottom of page ii].

Root (/) contained all the system files and configuration;
/usr all the user's files.

In the UNIX V7 manuals hosted here:
http://plan9.bell-labs.com/7thEdMan/bswv7.html
Dennis Rtichie suggests moving binary files from root (/bin)
to /usr/bin because it might speed up systems:
See page 152 of UNIX Version 7, Volume 2B
UNIX Programmers Manual.

Hence, he suggests leaving only maintenance binary files in
root (see para. 3 under Disk Layout, Pg. 152).

The most important remark comes in paragraph 2 of the disk
layout page:

"There are two considerations in deciding how to adjust the
arrangement of things on your disks: the most important is
making sure there is adequate space for what is required;
secondarily, throughput should be maximised."



For me the argument is about what gets mounted in which way.
I want to be able to ensure filesystems are mounted to prevent
potential privilege escalation.
Consequently, I have split my Gentoo system with the following
settings.

At boot /usr is present in / (on same partition)
/tmp is mounted nosuid from a separate partition
/var is mounted nosuid from a separate partition
/home is mounted nosuid from a separate partition

/bin and /sbin programs that do not require root authority
are all marked nosuid.

None of the executables/configuration files in / or /usr are
user-writable.

umasks are 077.

On my backup server, /home is mounted noexec, nosuid.

Personally I like the split between /bin and /usr/bin and /sbin
and /usr/sbin - provided ports maintainers stick to an
understanding that /bin is for maintenance files and /usr/bin
is for user application files (i.e. applications used by users).

/sbin and /usr/sbin should segregate root's/system maintenance
executables and root's/system application executables.


Although I am not sure at all that executables have been so
split by recent developers/maintainers (a lot of time has passed)...

It would be nice if a sensible structure could be proposed and
agreed by ALL Linux distributions (coordinated with BSD).

For me, it is a credit to Ken and Dennis' vision that they foresaw
the benefit of file permissions, including suid and sgid and the
EXCEPTIONALLY BRILLIANT idea of the sticky bit for /tmp.

It is incredible that they came up with much of this structure in
1969 - 1978.

"Progress, far from consisting in change, depends on retentiveness.
When change is absolute there remains no being to improve and
no direction is set for possible improvement: and when experience
is not retained, as among savages, infancy is perpetual.
Those who cannot remember the past are condemned to repeat it."
SATAYANA

Those querying a separate /usr partition or otherwise might like to
peruse UNIX Version 7 UNIX Programmers manual, Volume 2A:
UNIX for Beginners (Brian W. Kernighan)
Page 46 of this PDF: http://plan9.bell-labs.com/7thEdMan/v7vol2a.pdf

I LIKE THE IDEA of a separate /usr partition - but that is from a
mounting file-systems perspective rather than relying on the history
of UNIX...

Live free or die - UNIX.

Mike




On 18/07/12 18:35, Canek Peláez Valdés wrote:
> As William pointed out, this is just another silly rationalization
> done after the fact. But, just for argument's sake, lets suppose that
> "usr" was named like that because it was the acronym for "UNIX System
> Resources".
>
> *Who cares about that now?* It was 43 years ago. My cellphone is
> thousands of times faster than the PDP-7 Unix was originally developed
> for, and it has millions of times more storage. The length
> restrictions imposed on system directories are completely superfluous
> now.

[Walter Dnes]

On Wed, Jul 18, 2012 at 08:06:41PM +0200, Jason A. Donenfeld wrote

The biggest benefit is that Gentoo wouldn't become a Redhat-based
distro. You can compile Redhat (or Centos) from source with SRPM
packages if you wanted a Redhat-based build-from-source distro. They
proclaim that udev will not require systemd for the time being. But
given how cavalierly they broke 20 years of linux file hierarchy, I'm
skeptical of their promises of continued backwards compatability. And
what else do they have coming down the pike? What's next to get broken?

Alpine Linux http://alpinelinux.org/ is busybox-based, so it can be
done. A major problem for me is that it also uses uclibc. It does do
X11, e.g. GNOME, XFCE, etc), but uclibc rules out my Nvidia card with
proprietary drivers. I'm also a paying subscriber of NHL Gamecentre
Live, so I need proprietary Flash, which gets broken by uclibc. I've
tried Nouveau and Gnash, and they are not ready for primetime.

--
Walter Dnes <walt...@waltdnes.org>

[Matthew Marlowe]

> It would be nice if a sensible structure could be proposed and
> agreed by ALL Linux distributions (coordinated with BSD).
>

+1

If a new file system standard is required, my preferences based on a
history of what is worked and changed over the last 20-30 years would
be:

- OK with requiring / and /usr on the same FS. This has become common
practice with virtualization and small system deployments, and I
haven't seen any compelling advantage for keeping separate on larger
boxes.
- NOT OK with limitation on allowing /var, /opt, /home, or any other
common server mount points to require use of initramfs/initrd. There
is enough disagreement as to the reliability and ease of maintenance
of initramfs/initrd that it should not be needed for common server
deployments.
- It would be nice if the rootfs used a snapshot based filesystem and
if the bootloader was intelligent enough to easily allow admins to
boot to older snapshots as an expectation for any standard modern unix
system.
- Ideally, server motherboards would come with flash based storage
where sysadmins could install rescue environments as part of a normal
unix install, and that the boot loader or bios would be smart enough
to provide the option to boot from it automatically whenever a normal
boot failed.
- NOT OK with removing the distinction between user and system
binaries. Essential binaries required to boot and troubleshoot system
problems should be located separately from user binaries. Security
sensitive or paranoid admins should be able to make the system binary
path read-only or completely remove the user binary directory from
roots PATH if they so wish.
- OK with merging / and /usr, but in that case...why not just move
everything in /usr to /...but limit /sbin to system binaries and /bin
to user ones? This would be horrible for migrations though and
possibly confuse many scripts.
- NOT OK with making systemd the default init system anytime in the
next few years, it is way too immature and like most major system
software changes...probably will take much longer before it really has
the standing to propose being a new standard.
- What other elements can new filesystems like btrfs offer that should
be considered? ext3/ext4 has worked great with the older
standards...but it essentially mimicked the capabilities of older
file-systems that the original unix standards were based on. Btrfs
might change our expectations. I'm assuming that btrfs will be the
standard production fs in a few years.

[Patrick Lauer]

And here's an epic failure mode waiting to happen - what if the kernel
is not stored in /boot ?

I can think of at least two common setups where that happens. One is
virtual machines (Xen for example usually stores the kernel outside the
guest filesystem), the other is systems with full-disk encryption where
you don't have a bootloader on the local disk.

Ah, who would have guessed that there are linux installs that are not
single-disk desktops!

[Walter Dnes]

On Wed, Jul 18, 2012 at 08:27:29PM +0200, Micha?? G??rny wrote

Busybox is a well-supported lightweight replacement for udev and most
of coreutils, and also happens to double up as a rescue tool. See my
reply to Jason A. Donenfeld for more. BTW, "static" is an optional USE
flag for busybox.

--
Walter Dnes <walt...@waltdnes.org>

[Olivier Crête]

On Wed, 2012-07-18 at 18:24 -0700, Matthew Marlowe wrote:
> > It would be nice if a sensible structure could be proposed and
> > agreed by ALL Linux distributions (coordinated with BSD).
> >
>
> +1
>
> If a new file system standard is required, my preferences based on a
> history of what is worked and changed over the last 20-30 years would
> be:
>
> - OK with requiring / and /usr on the same FS. This has become common
> practice with virtualization and small system deployments, and I
> haven't seen any compelling advantage for keeping separate on larger
> boxes.

No one proposes that, the only requirement that you have for modern
Linux to work well is that if /usr is on a separate partition, you need
to mount it before starting your main system (ie, from an initramfs).

> - NOT OK with limitation on allowing /var, /opt, /home, or any other
> common server mount points to require use of initramfs/initrd. There
> is enough disagreement as to the reliability and ease of maintenance
> of initramfs/initrd that it should not be needed for common server
> deployments.

This is clearly not needed, /run was even invented to allow /var to be
mounted later.

> - It would be nice if the rootfs used a snapshot based filesystem and
> if the bootloader was intelligent enough to easily allow admins to
> boot to older snapshots as an expectation for any standard modern unix
> system.

One of the reasons to put everything in /usr is to allow using a
snapshot based FS, so you can run a system where /usr is read-only and
where when you can do all upgrade atomically by writing your changes to
a read-write snapshot and then switch all at once. So you never have any
half-upgraded package on your system.

> - Ideally, server motherboards would come with flash based storage
> where sysadmins could install rescue environments as part of a normal
> unix install, and that the boot loader or bios would be smart enough
> to provide the option to boot from it automatically whenever a normal
> boot failed.
> - NOT OK with removing the distinction between user and system
> binaries. Essential binaries required to boot and troubleshoot system
> problems should be located separately from user binaries. Security
> sensitive or paranoid admins should be able to make the system binary
> path read-only or completely remove the user binary directory from
> roots PATH if they so wish.

The rescue system should be entirely separate from the main system, so
it survives mishandled upgrades. So having that should not hinder how
your main system is built. So you should have it as a separate partition
or you can even have it an initramfs (ie, in a single file on the main
system).

> - OK with merging / and /usr, but in that case...why not just move
> everything in /usr to /...but limit /sbin to system binaries and /bin
> to user ones? This would be horrible for migrations though and
> possibly confuse many scripts.

The idea of putting everything in /usr instead of / is that you can then
make /usr read-only and you can share /usr between multiple systems,
while / is read-write and contains /root and /etc.

> - NOT OK with making systemd the default init system anytime in the
> next few years, it is way too immature and like most major system
> software changes...probably will take much longer before it really has
> the standing to propose being a new standard.

I fully expect systemd to be the init system of the next iteration of
RedHat Enterprise Linux, which is probably the most "enterprise" of all
distributions, with the most QA and support and everything. It's not a
side project of dude of his basement, it has the full support of a large
team of people at RedHat. There has probably already been more testing
done on systemd today than on OpenRC...

> - What other elements can new filesystems like btrfs offer that should
> be considered? ext3/ext4 has worked great with the older
> standards...but it essentially mimicked the capabilities of older
> file-systems that the original unix standards were based on. Btrfs
> might change our expectations. I'm assuming that btrfs will be the
> standard production fs in a few years.

The big thing that btrfs brings is snapshots and subvolumes... So it
makes it possible to do atomic upgrades and such. Also, you can have
"apps" be subvolumes and also handled atomically.

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

[Duncan]

Canek Peláez Valdés posted on Wed, 18 Jul 2012 10:04:33 -0500 as
excerpted:

> I don't mind the merge of /bin, /usr/bin, /sbin and /usr/sbin; moreover,
> I want an even more radical change:
>
> /usr -> /System /home -> /Users /etc -> /Config

Ugh. At least kill the shift key requirement. Other than that, no real
objection, but it's far afield from the current discussion and would be a
lot of (arguably unnecessary) work to migrate.

FWIW, tho, that does look a lot like... I think it's gobo linux... If you
like that sort of thing, I'd suggest looking at it.

--
Duncan - List replies preferred. No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master." Richard Stallman

[Duncan]

Jason A. Donenfeld posted on Wed, 18 Jul 2012 19:47:49 +0200 as excerpted:

> On Wed, Jul 18, 2012 at 1:07 AM, Olivier Crête <tes...@gentoo.org>
> wrote:
>> Also be ready for a merge of /bin and /sbin.. I'm sure most people
>> can't even explain the difference between them.
>
> Whoa hey what why? Who's pushing this forward?

AFAIK it has been discussed for Fedora/RH, but I think they're doing
the / /usr merge first and /usr/bin /usr/sbin (which would then take care
of the already merged /bin /sbin) later. I believe they've mostly
decided already, but timing, etc, will depend on how the first phase,
the / /usr merger, goes, and of course if that turns out to go worse than
expected, the second phase could still be called off. But don't bet on
it as certainly, people will have already been running their systems that
way in ordered to seriously advocate it, so it's likely to mostly just
take a couple release cycles to work thru their system and get the corner-
case kinks worked out.

[Matthew Marlowe]

On Wed, Jul 18, 2012 at 7:04 PM, Olivier Crête <tes...@gentoo.org> wrote:
> On Wed, 2012-07-18 at 18:24 -0700, Matthew Marlowe wrote:
>
>> - It would be nice if the rootfs used a snapshot based filesystem and
>> if the bootloader was intelligent enough to easily allow admins to
>> boot to older snapshots as an expectation for any standard modern unix
>> system.
>
> One of the reasons to put everything in /usr is to allow using a
> snapshot based FS, so you can run a system where /usr is read-only and
> where when you can do all upgrade atomically by writing your changes to
> a read-write snapshot and then switch all at once. So you never have any
> half-upgraded package on your system.
>

I understand that RHEL is promoting this system management model, but
I'm not sure it is any way superior than other models that do not
require RO /usr. Many enterprises today solve the same issue via
automation with puppet, active traffic management via LVS/HA/Load
Balancers, or replace /usr snapshots with virtualization where a new
VM snapshot or clone is upgraded and then replaces the active VM.
Therefore, I'm not convinced we should promote /usr/bin and /usr/sbin
over /bin and /sbin. It is a point in their favor to give more
flexibility but the simplicity of also just removing /usr would also
be compelling if our goal afterall is to simplify the FHS.

>
>> - OK with merging / and /usr, but in that case...why not just move
>> everything in /usr to /...but limit /sbin to system binaries and /bin
>> to user ones? This would be horrible for migrations though and
>> possibly confuse many scripts.
>
> The idea of putting everything in /usr instead of / is that you can then
> make /usr read-only and you can share /usr between multiple systems,
> while / is read-write and contains /root and /etc.
>

Most enterprises that need the ability to make /usr RO for canonical
server configs could just as well get by with automated configuration
management tools (e.g. puppet) and smart hypervisors/SAN storage.
This allows deployment of new servers within minutes and it reflects
at least the true reality that a true controlled system state is a
snapshot of server config files, virtual hardware, and all binaries.
Just making /usr RO is a cheat that might work well for long lived
binary distributions that require major version upgrades anytime
software packages update their config behavior dramatically. I
haven't found it very helpful for source type systems like Gentoo. Of
course, others may disagree.

>> - NOT OK with making systemd the default init system anytime in the
>> next few years, it is way too immature and like most major system
>> software changes...probably will take much longer before it really has
>> the standing to propose being a new standard.
>
> I fully expect systemd to be the init system of the next iteration of
> RedHat Enterprise Linux, which is probably the most "enterprise" of all
> distributions, with the most QA and support and everything. It's not a
> side project of dude of his basement, it has the full support of a large
> team of people at RedHat. There has probably already been more testing
> done on systemd today than on OpenRC...
>

Well, we know that systemd will be in the next RHEL release - it was
in their recent roadmap presentation. However, that release would be
RHEL7 and most established servers are RHEL5 now and RHEL6 is still
relatively early in deployment. It will be a few years before most
RedHat customers can say whether systemd was a good move for RHEL.
And, RedHat has made changes in the past that while supported might
not become the default config for other distributions (e.g. SE Linux).
I don't see that we need to assume now that systemd will define the
default Linux ecosystem in the future, even if it becomes widely
deployed on RedHat systems..

[Duncan]

Michael Mol posted on Wed, 18 Jul 2012 15:18:35 -0400 as excerpted:

> On Wed, Jul 18, 2012 at 3:05 PM, Rich Freeman <ri...@gentoo.org> wrote:
>> On Wed, Jul 18, 2012 at 2:53 PM, Michael Mol <mik...@gmail.com> wrote:
>>> AFAIK, neither genkernel nor dracut were expected to get tied to the
>>> Gentoo update process. Has that changed?
>>
>> We don't even update kernels as part of the regular update process, let
>> alone initramfs systems.
>>
>> In general you update them together.
>>
>> The only issue I could see is if problems arise if you have a different
>> version of udev in your initramfs than on your system. I don't know if
>> that actually causes problems. For the most part after the system is
>> booted the initramfs is done its job.
>
> The most widely touted benefit I've heard for initramfs is its
> capability to ease system recovery in case, e.g. a critical filesystem
> refuses to mount. With recovery roles come recovery tools, which quickly
> extends network-aware tools and a security attack surface.
>
> Hence why I tend to feel that if an initramfs is going to become the
> go-to solution for bootstrapping userland, it's important to consider
> the difficulties of keeping the packed tools up-to-date; it's not just a
> bootstrap tool, it's also the first recovery option a sysadmin faces.

As others have stated, that might be /a/ widely touted benefit, but the
reason for initr* being there in the first place, is to solve the
otherwise chicken/egg issue of having the tools/modules necessary to
mount a filesystem, /on/ that filesystem, since now they're on the initr*
as well, and that is maintained with the kernel.

But meanwhile, recovery /is/ /a/ widely touted benefit, which really
presents its own problem, in the form of a choice:

a) automatically update the initr* and get the security benefits but risk
breaking the recovery tools when they break with an update to the main
system,

OR:

b) don't automatically update the initr* in ordered to keep a known/
tested-working first recovery mechanism, but at the cost of potentially
unfixed security-vulns in the initr* that were already fixed on the main
system.

Of course (b) is the usual case on an initr* (unless it's one-size-fits-
all automatically updated by the distro), due to static linking. So
security is already taking second priority to a known-working recovery
mechanism, and updating the initr* on a user-configured/managed distro
like gentoo pretty much must remain in that user-admin domain. There's
simply no way around it, without going the one-size-fits-all-distro-
configured route, which by accepted definition isn't palatable to
gentooers, or they'd be using something else.

So IMO, updating the initr* is and must remain user-admin domain, not
something gentoo really can worry about, other than to the extent of
making those updates as easy and stupid-mistake-proof as can reasonably
be done while still placing the responsibility of actually configuring
and maintaining the initr* with the user-admin.

[Rich Freeman]

On Wed, Jul 18, 2012 at 4:05 PM, Alec Warner <ant...@gentoo.org> wrote:
>
> I'm not really following your logic here, so forgive me. I completely
> understand why folks do not say, rebuild their kernel when it is
> updated (kernel configs are annoying.)
>
> However lets say I have coreutils in / and coreutils in my initramfs.
> I upgrade coreutils from v1 to v2. Are you saying that you are too
> afraid to update coreutils in / and then also update it in the
> initramfs (probably by running $TOOL to copy coreutils from / to
> initramfs-root.)

As others have mentioned, coreutils doesn't impact the initramfs much
anyway, though other tools like mdadm/lvm/etc are more likely to.

I think the more practical issue is that it isn't straightforward to
do in an automated way. I suppose we could keep an always-up-to-date
kernel and initramfs SOMEWHERE, but that won't necessarily be where
the user boots it from. Also, we need flexibility as users tend to
tweak these things - dracut has lots of options for how the initramfs
is built, users might use any of several initramfs implementations,
and the kernel config is frequently tweaked, and doesn't always work
if you just do a make oldconfig. Usually the way other distros make
all of this work is by making everything generic and not support
configurability.

Rich

[Richard Yao]

On 07/18/2012 02:25 PM, Michael Mol wrote:
> 1) There are no truly mature tools for automatically generating and
> installing an initramfs based on system requirements. Canek likes to
> recommend dracut, which still isn't marked stable. I've gotten stable
> genkernel to work reasonably, but its error reporting is terrible.

Please file a bug report and CC me on it. I will be more than happy to
improve this for you.

[Walter Dnes]

On Wed, Jul 18, 2012 at 07:04:15PM -0700, Olivier Cr?te wrote

> The rescue system should be entirely separate from the main system, so
> it survives mishandled upgrades. So having that should not hinder how
> your main system is built. So you should have it as a separate partition
> or you can even have it an initramfs (ie, in a single file on the main
> system).

If you want *REALLY* "entirely separate from the main system", you
should be looking at a "rescue CD" or bootable USB key. That's about as
safe as you can get.

--
Walter Dnes <walt...@waltdnes.org>

[Christopher Head]

On Thu, 19 Jul 2012 07:05:39 -0400
Rich Freeman <ri...@gentoo.org> wrote:

> As others have mentioned, coreutils doesn't impact the initramfs much
> anyway, though other tools like mdadm/lvm/etc are more likely to.
>
> I think the more practical issue is that it isn't straightforward to
> do in an automated way. I suppose we could keep an always-up-to-date
> kernel and initramfs SOMEWHERE, but that won't necessarily be where
> the user boots it from. Also, we need flexibility as users tend to
> tweak these things - dracut has lots of options for how the initramfs
> is built, users might use any of several initramfs implementations,
> and the kernel config is frequently tweaked, and doesn't always work
> if you just do a make oldconfig. Usually the way other distros make
> all of this work is by making everything generic and not support
> configurability.
>
> Rich
>

For me, the issue isn't so much that it's *hard* to rebuild an
initramfs as that it's not obvious *when* to do so. For the kernel,
this is a trivial problem: when sys-kernel/gentoo-sources bumps,
rebuild the kernel. For an initramfs, when do I rebuild? When there's a
new, what? Coreutils? Mdadm? LVM? Glibc? Busybox? Something-firmware?
What about any less-obvious libraries they might link to, like zlib or
something? All of those things are presumably in my initramfs, but
there's no canonical list I'm aware of that tells me "if one of the
packages in this list updates, you must rebuild your initramfs if you
wish to take advantage of the upgrade".

Chris

[Luca Barbato]

On 07/18/2012 08:27 PM, Michał Górny wrote:
> I don't think we should give more support to building a system from
> a statically linked rescue suite tool.

For people wanting to shave some seconds from their boot openrc using
busybox is quite handy and should be used as default IMHO.

lu

[Jeroen Roovers]

On Wed, 18 Jul 2012 20:27:29 +0200
Michał Górny <mgo...@gentoo.org> wrote:

> > 3. More support for mdev; e.g. https://wiki.gentoo.org/wiki/Mdev
> > and (still in beta) https://wiki.gentoo.org/wiki/Mdev/Automount_USB
> > The next challenge is "custom mdev rules", which should be do-able.
>

> I don't think we should give more support to building a system from
> a statically linked rescue suite tool.

Could you try and be a bit more respectful, please? Bashing other
people's preferred tools of the trade usually amounts in horrible flame
wars and sometimes ends in people forking their very own sibling
projects (through spite or excommunication).


Thanks,
jer