[gentoo-user] udev + /usr

[gentoo-user] udev + /usr

[Alan Mackenzie]

Hi, everybody.

Hope nobody minds me starting a new thread with an accurate name.

Which version of udev is it that has this nauseating feature of needing
/usr loaded to boot?

Somewhere in that version's source will be several (or lots of) "/usr".
Just how difficult is it going to be to replace "/usr/bin" with "/bin"
throughout the source?

udev is part of the kernel.  How come the kernel hackers aren't up in
arms about this as much as we are?  Or are they, maybe?  In which case,
maybe the kernel people would welcome an option to disrequire the early
mounting of /usr as much as we would.

Anyhow, I'd like to take a peek at the source code which does this evil
thing.  Would somebody please tell me which version of udev is involved.

Thanks.

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: [gentoo-user] udev + /usr

[Michael Schreckenbauer]

Hi Alan,

On Monday, 12. September 2011 15:02:48 Alan Mackenzie wrote:
> Hi, everybody.
> 
> Hope nobody minds me starting a new thread with an accurate name.
> 
> Which version of udev is it that has this nauseating feature of needing
> /usr loaded to boot?

> Somewhere in that version's source will be several (or lots of) "/usr".
> Just how difficult is it going to be to replace "/usr/bin" with "/bin"
> throughout the source?

you misunderstood something. udev is able to run arbitrary scripts. Some of 
those scripts are located in /usr/* or need something there. I doubt you will 
find references to /usr in the udev-sources.

> udev is part of the kernel.

No. udev is usperspace.

> How come the kernel hackers aren't up in
> arms about this as much as we are?  Or are they, maybe?  In which case,
> maybe the kernel people would welcome an option to disrequire the early
> mounting of /usr as much as we would.
> 
> Anyhow, I'd like to take a peek at the source code which does this evil
> thing.  Would somebody please tell me which version of udev is involved.

Every udev version works this way.
Fixing udev to continue working with separate /usr is far from trivial imo. 
Changing some paths is not the way to go for sure.
First of all, udev has to distinguish between "device not present" and "script 
error of some kind". Failing scripts have to be queued somehow for later 
execution. If a script keeps failing, it has to be removed from that queue, 
with a message to syslog or something like that. If udev needs a script in 
/usr/* to mount /usr then there's a chicken-egg-problem, which could be hard 
to solve (if possible at all without moving things from /usr/ to /).
Note, that I am wild guessing here, I did not study the udev sources or any 
related script/rule :)

> Thanks.

Best,
Michael

Re: [gentoo-user] udev + /usr

[Alan Mackenzie]

Hi, Michael.

On Mon, Sep 12, 2011 at 05:33:34PM +0200, Michael Schreckenbauer wrote:
> Hi Alan,

> On Monday, 12. September 2011 15:02:48 Alan Mackenzie wrote:

> > Hope nobody minds me starting a new thread with an accurate name.

> > Which version of udev is it that has this nauseating feature of needing
> > /usr loaded to boot?

> > Somewhere in that version's source will be several (or lots of) "/usr".
> > Just how difficult is it going to be to replace "/usr/bin" with "/bin"
> > throughout the source?

> you misunderstood something. udev is able to run arbitrary scripts. Some of 
> those scripts are located in /usr/* or need something there. I doubt you will 
> find references to /usr in the udev-sources.

Well, I'm a hacker.  udev is free source, therefore fair game.  I don't
intend to put up with this nonsense without a fight.  As far as I can
make out, this is just one guy, Kay Sievers, who's on a power trip.  Are
there any indications at all that he actually talked to anybody in the
wide world before making such a far reaching decision?

On my current system, udev (164-r2) works without an earlily loaded /usr.
Seemingly, later versions don't.  That was why I was asking for somebody
to identify one of these later versions for me.

> > udev is part of the kernel.

> No. udev is usperspace.

OK, udev is in userspace, _very_ _close_ to the kernel.  ;-)

> > How come the kernel hackers aren't up in arms about this as much as
> > we are?  Or are they, maybe?  In which case, maybe the kernel people
> > would welcome an option to disrequire the early mounting of /usr as
> > much as we would.

> > Anyhow, I'd like to take a peek at the source code which does this evil
> > thing.  Would somebody please tell me which version of udev is involved.

> Every udev version works this way.

My udev (164-r2) is just fine at the moment.  I'm not sure what you mean
by that statement.

> Fixing udev to continue working with separate /usr is far from trivial imo. 
> Changing some paths is not the way to go for sure.

Maybe, maybe not.  But it seems a changing of paths (/ -> /usr) is
precisely what is breaking newer udevs.  It might be possible to change
them back.  This could involve moving a fair amount of stuff from /usr to
/, but not half as much as moving the entire /usr partition.

> First of all, udev has to distinguish between "device not present" and "script 
> error of some kind". Failing scripts have to be queued somehow for later 
> execution. If a script keeps failing, it has to be removed from that queue, 
> with a message to syslog or something like that. If udev needs a script in 
> /usr/* to mount /usr then there's a chicken-egg-problem, which could be hard 
> to solve (if possible at all without moving things from /usr/ to /).
> Note, that I am wild guessing here, I did not study the udev sources or any 
> related script/rule :)

This sounds like a separate (if related) problem.

> > Thanks.

> Best,
> Michael

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: [gentoo-user] udev + /usr

[Michael Mol]

On Mon, Sep 12, 2011 at 1:17 PM, Alan Mackenzie <acm@muc.de> wrote:
> On Mon, Sep 12, 2011 at 05:33:34PM +0200, Michael Schreckenbauer wrote:
>> On Monday, 12. September 2011 15:02:48 Alan Mackenzie wrote:
>
>> > Hope nobody minds me starting a new thread with an accurate name.
>
>> > Which version of udev is it that has this nauseating feature of needing
>> > /usr loaded to boot?
>
>> > Somewhere in that version's source will be several (or lots of) "/usr".
>> > Just how difficult is it going to be to replace "/usr/bin" with "/bin"
>> > throughout the source?
>
>> you misunderstood something. udev is able to run arbitrary scripts. Some of
>> those scripts are located in /usr/* or need something there. I doubt you will
>> find references to /usr in the udev-sources.
>
> Well, I'm a hacker.  udev is free source, therefore fair game.  I don't
> intend to put up with this nonsense without a fight.  As far as I can
> make out, this is just one guy, Kay Sievers, who's on a power trip.  Are
> there any indications at all that he actually talked to anybody in the
> wide world before making such a far reaching decision?

udev has always been able to run arbitrary scripts. The trouble is
that the arbitrary scripts other packages provide sometimes call for
things under /usr.

If I've read messages over the last couple days correctly, I think the
recent change is that some stuff udev *directly* depends on, as part
of the udev package itself, is being moved into /usr.

My best guess is that this allows udev to force the issue; it gets
blamed for other packages not loading correctly (when those other
packages put things in places which may or may not be available yet),
so the udev developer chose to force systems to have all of /usr
available before udev is run.

The first step in a clean solution, IMO, is to revert that change. The
second step is to fix the 'silent failure' problem for packages which
depend on /usr before /usr is available.

You might do it with a dependency tree which would control the order
things are done, but some packages may not be able to know what they
depend on. (take dhcpd, for example; it doesn't know what kind of
weird magic someone else put in exit-hooks)

Another solution would be to have a retry queue like what
Schreckenbauer (sorry; too many Mikes) was suggesting. It might be
difficult to discern a rulescript failure that stems from another rule
needing to be run first versus a rulescript failure that stems from,
e.g. a syntax error.

-- 
:wq

Re: [gentoo-user] udev + /usr

[Michael Schreckenbauer]

On Monday, 12. September 2011 13:39:59 Michael Mol wrote:
> On Mon, Sep 12, 2011 at 1:17 PM, Alan Mackenzie <acm@muc.de> wrote:
> > On Mon, Sep 12, 2011 at 05:33:34PM +0200, Michael Schreckenbauer wrote:
> >> On Monday, 12. September 2011 15:02:48 Alan Mackenzie wrote:

> >> you misunderstood something. udev is able to run arbitrary scripts.
> >> Some of those scripts are located in /usr/* or need something there.
> >> I doubt you will find references to /usr in the udev-sources.
> > 
> > Well, I'm a hacker.  udev is free source, therefore fair game.  I don't
> > intend to put up with this nonsense without a fight.  As far as I can
> > make out, this is just one guy, Kay Sievers, who's on a power trip.  Are
> > there any indications at all that he actually talked to anybody in the
> > wide world before making such a far reaching decision?
> 
> udev has always been able to run arbitrary scripts. The trouble is
> that the arbitrary scripts other packages provide sometimes call for
> things under /usr.

Exactly.

> If I've read messages over the last couple days correctly, I think the
> recent change is that some stuff udev *directly* depends on, as part
> of the udev package itself, is being moved into /usr.

I seem to have missed that part.

> My best guess is that this allows udev to force the issue; it gets
> blamed for other packages not loading correctly (when those other
> packages put things in places which may or may not be available yet),
> so the udev developer chose to force systems to have all of /usr
> available before udev is run.

Sounds reasonable.

> The first step in a clean solution, IMO, is to revert that change. The
> second step is to fix the 'silent failure' problem for packages which
> depend on /usr before /usr is available.

ack.

> You might do it with a dependency tree which would control the order
> things are done, but some packages may not be able to know what they
> depend on. (take dhcpd, for example; it doesn't know what kind of
> weird magic someone else put in exit-hooks)

Sounds good.

> Another solution would be to have a retry queue like what
> Schreckenbauer (sorry; too many Mikes) was suggesting. It might be
> difficult to discern a rulescript failure that stems from another rule
> needing to be run first versus a rulescript failure that stems from,
> e.g. a syntax error.

Maybe a combination of the two?
If dhcpd fails in your example, put it in the retry queue. After some failing 
attempts, remove it from there and log the error.

BTW: if there are too many Michaels/Mikes on the list, call me "grimlog". I am 
used to that nick and feel strange if someone calls me "Schreckenbauer" :)

Best,
Michael, aka grimlog

Re: [gentoo-user] udev + /usr

[Canek Peláez Valdés]

On Mon, Sep 12, 2011 at 1:39 PM, Michael Mol <mikemol@gmail.com> wrote:
> On Mon, Sep 12, 2011 at 1:17 PM, Alan Mackenzie <acm@muc.de> wrote:
>> On Mon, Sep 12, 2011 at 05:33:34PM +0200, Michael Schreckenbauer wrote:
>>> On Monday, 12. September 2011 15:02:48 Alan Mackenzie wrote:
>>
>>> > Hope nobody minds me starting a new thread with an accurate name.
>>
>>> > Which version of udev is it that has this nauseating feature of needing
>>> > /usr loaded to boot?
>>
>>> > Somewhere in that version's source will be several (or lots of) "/usr".
>>> > Just how difficult is it going to be to replace "/usr/bin" with "/bin"
>>> > throughout the source?
>>
>>> you misunderstood something. udev is able to run arbitrary scripts. Some of
>>> those scripts are located in /usr/* or need something there. I doubt you will
>>> find references to /usr in the udev-sources.
>>
>> Well, I'm a hacker.  udev is free source, therefore fair game.  I don't
>> intend to put up with this nonsense without a fight.  As far as I can
>> make out, this is just one guy, Kay Sievers, who's on a power trip.  Are
>> there any indications at all that he actually talked to anybody in the
>> wide world before making such a far reaching decision?
>
> udev has always been able to run arbitrary scripts. The trouble is
> that the arbitrary scripts other packages provide sometimes call for
> things under /usr.
>
> If I've read messages over the last couple days correctly, I think the
> recent change is that some stuff udev *directly* depends on, as part
> of the udev package itself, is being moved into /usr.
>
> My best guess is that this allows udev to force the issue; it gets
> blamed for other packages not loading correctly (when those other
> packages put things in places which may or may not be available yet),
> so the udev developer chose to force systems to have all of /usr
> available before udev is run.
>
> The first step in a clean solution, IMO, is to revert that change. The
> second step is to fix the 'silent failure' problem for packages which
> depend on /usr before /usr is available.

No fixable, in reality. The flexibility of udev is in part in that the
userspace can (and actually do) run arbitrary scripts and binaries
from udev rules. You can "fix" the ones that require binaries in /usr
*NOW*, but not forever, unless you forbid the use of arbitrary
binaries from udev rules.

And then you lose the flexibility.

The explanation from
http://www.freedesktop.org/wiki/Software/systemd/separate-usr-is-broken
seems more than reasonable to me: /lib and /bin and /sbin were the way
old-Unix solved the problem of needing some binaries before /usr was
mounted.

Linux has a much better, flexible and automatized (dracut) way of
doing this, by using an initramfs. With an initramfs you can have the
smallest / in the world, and mount everything else afterwards. The
initramfs memory is free'd after the pivot_root happens, so who cares
how big it is?

And yeah, that's not how classical Unix do things. Who cares? Linux
does it so much better.

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

Re: [gentoo-user] udev + /usr

[Michael Mol]

On Mon, Sep 12, 2011 at 2:37 PM, Canek Peláez Valdés <caneko@gmail.com> wrote:
> On Mon, Sep 12, 2011 at 1:39 PM, Michael Mol <mikemol@gmail.com> wrote:
>> The first step in a clean solution, IMO, is to revert that change. The
>> second step is to fix the 'silent failure' problem for packages which
>> depend on /usr before /usr is available.
>
> No fixable, in reality. The flexibility of udev is in part in that the
> userspace can (and actually do) run arbitrary scripts and binaries
> from udev rules. You can "fix" the ones that require binaries in /usr
> *NOW*, but not forever, unless you forbid the use of arbitrary
> binaries from udev rules.
>
> And then you lose the flexibility.

Here's the chief problem with that argument...it's not just limited to
/usr. If you're going to say that a script can do whatever it wants,
and udev will make declarative statements about supported and
unsupported filesystem layouts to allow that to work, then you *must*
say that the entire filesystem be on the same partition as /, or that
one must use initramfs.

Because you can't know that a script won't depend on something under
/var. Or /opt. Or /home.  And if if /home is excluded from this
must-be-available set, what makes it more special than /usr? If it's
OK to say "no script must access files under /home", then why isn't it
OK to say "no script must access files under /usr"?

You're imposing a rule either way. If a script author must be aware of
rules, why can't he be aware of something like "be aware of when a
file may or may not be available, and do not access files which are
not yet available. If you can't know, document the requirement so that
a package maintainer or sysadmin can ensure your constraints are met."
That seems pretty simple to me. It's the *job* of package maintainers
to understand how software interacts with a distro's infrastructure.

>
> The explanation from
> http://www.freedesktop.org/wiki/Software/systemd/separate-usr-is-broken
> seems more than reasonable to me: /lib and /bin and /sbin were the way
> old-Unix solved the problem of needing some binaries before /usr was
> mounted.

I read that page. I understand the problem. I'm not convinced.

>
> Linux has a much better, flexible and automatized (dracut) way of
> doing this, by using an initramfs. With an initramfs you can have the
> smallest / in the world, and mount everything else afterwards. The
> initramfs memory is free'd after the pivot_root happens, so who cares
> how big it is?

People you (and the Fedora dev) don't care about, clearly. You ask
"who cares" rhetorically, when people on this very list have said,
"hey, I care!" There's a disconnect there I don't quite grasp.

A change like this is going to make life more difficult for embedded
hardware manufacturers, too. They'll have to have more memory
available for a larger initrd if they want to do something so simple
as a print server or a plug-and-play NAS node. And then there was that
mention of MIPS, earlier, that highlighted architectural physical
constraints that this would break. That's not exactly a trivial
problem.

> And yeah, that's not how classical Unix do things. Who cares? Linux
> does it so much better.

I really don't see where you're getting "better". You're saying, "Hey!
This is more flexible than any other solution." What you're not saying
(or noticing) is that you're kicking the can farther down the road;
the same fundamental complexities will pop up later unless you use the
initrd. With the initrd, you're turning every disk-installed system
into something equivalent to a livecd, with the capability of updating
the live cd as you go along. If that's actually the desire, there
would be far better options than initrd.

-- 
:wq

Re: [gentoo-user] udev + /usr

[Canek Peláez Valdés]

On Mon, Sep 12, 2011 at 3:00 PM, Michael Mol <mikemol@gmail.com> wrote:
> On Mon, Sep 12, 2011 at 2:37 PM, Canek Peláez Valdés <caneko@gmail.com> wrote:
>> On Mon, Sep 12, 2011 at 1:39 PM, Michael Mol <mikemol@gmail.com> wrote:
>>> The first step in a clean solution, IMO, is to revert that change. The
>>> second step is to fix the 'silent failure' problem for packages which
>>> depend on /usr before /usr is available.
>>
>> No fixable, in reality. The flexibility of udev is in part in that the
>> userspace can (and actually do) run arbitrary scripts and binaries
>> from udev rules. You can "fix" the ones that require binaries in /usr
>> *NOW*, but not forever, unless you forbid the use of arbitrary
>> binaries from udev rules.
>>
>> And then you lose the flexibility.
>
> Here's the chief problem with that argument...it's not just limited to
> /usr. If you're going to say that a script can do whatever it wants,
> and udev will make declarative statements about supported and
> unsupported filesystem layouts to allow that to work, then you *must*
> say that the entire filesystem be on the same partition as /, or that
> one must use initramfs.
>
> Because you can't know that a script won't depend on something under
> /var. Or /opt. Or /home.  And if if /home is excluded from this
> must-be-available set, what makes it more special than /usr? If it's
> OK to say "no script must access files under /home", then why isn't it
> OK to say "no script must access files under /usr"?
>
> You're imposing a rule either way. If a script author must be aware of
> rules, why can't he be aware of something like "be aware of when a
> file may or may not be available, and do not access files which are
> not yet available. If you can't know, document the requirement so that
> a package maintainer or sysadmin can ensure your constraints are met."
> That seems pretty simple to me. It's the *job* of package maintainers
> to understand how software interacts with a distro's infrastructure.
>
>>
>> The explanation from
>> http://www.freedesktop.org/wiki/Software/systemd/separate-usr-is-broken
>> seems more than reasonable to me: /lib and /bin and /sbin were the way
>> old-Unix solved the problem of needing some binaries before /usr was
>> mounted.
>
> I read that page. I understand the problem. I'm not convinced.

I can respect that. I can only then say that we must agree to
disagree, because I also understand the problem, and I am convinced.

But what you guys don't seem to realize is that /lib and /bin and
/sbin was the original hack: everything really should go into /usr,
because now (with an initramfs) we can do what we were not able 30
years ago. We not need anything in /, really.

Anyway, I'm not trying to convince anyone. Just wanted to show the
links and to make clear among other things that *no one* has ever
proposed (even less try to force) a non separatable /var. You can
speculate all you want, but that's all: speculation.

Going back to work: nice chatting with you guys.

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

Re: [gentoo-user] udev + /usr

[Michael Mol]

On Mon, Sep 12, 2011 at 3:35 PM, Canek Peláez Valdés <caneko@gmail.com> wrote:
> On Mon, Sep 12, 2011 at 3:00 PM, Michael Mol <mikemol@gmail.com> wrote:
>> On Mon, Sep 12, 2011 at 2:37 PM, Canek Peláez Valdés <caneko@gmail.com> wrote:
>>> On Mon, Sep 12, 2011 at 1:39 PM, Michael Mol <mikemol@gmail.com> wrote:
>>>> The first step in a clean solution, IMO, is to revert that change. The
>>>> second step is to fix the 'silent failure' problem for packages which
>>>> depend on /usr before /usr is available.
>>>
>>> No fixable, in reality. The flexibility of udev is in part in that the
>>> userspace can (and actually do) run arbitrary scripts and binaries
>>> from udev rules. You can "fix" the ones that require binaries in /usr
>>> *NOW*, but not forever, unless you forbid the use of arbitrary
>>> binaries from udev rules.
>>>
>>> And then you lose the flexibility.
>>
>> Here's the chief problem with that argument...it's not just limited to
>> /usr. If you're going to say that a script can do whatever it wants,
>> and udev will make declarative statements about supported and
>> unsupported filesystem layouts to allow that to work, then you *must*
>> say that the entire filesystem be on the same partition as /, or that
>> one must use initramfs.
>>
>> Because you can't know that a script won't depend on something under
>> /var. Or /opt. Or /home.  And if if /home is excluded from this
>> must-be-available set, what makes it more special than /usr? If it's
>> OK to say "no script must access files under /home", then why isn't it
>> OK to say "no script must access files under /usr"?
>>
>> You're imposing a rule either way. If a script author must be aware of
>> rules, why can't he be aware of something like "be aware of when a
>> file may or may not be available, and do not access files which are
>> not yet available. If you can't know, document the requirement so that
>> a package maintainer or sysadmin can ensure your constraints are met."
>> That seems pretty simple to me. It's the *job* of package maintainers
>> to understand how software interacts with a distro's infrastructure.
>>
>>>
>>> The explanation from
>>> http://www.freedesktop.org/wiki/Software/systemd/separate-usr-is-broken
>>> seems more than reasonable to me: /lib and /bin and /sbin were the way
>>> old-Unix solved the problem of needing some binaries before /usr was
>>> mounted.
>>
>> I read that page. I understand the problem. I'm not convinced.
>
> I can respect that. I can only then say that we must agree to
> disagree, because I also understand the problem, and I am convinced.
>
> But what you guys don't seem to realize is that /lib and /bin and
> /sbin was the original hack: everything really should go into /usr,
> because now (with an initramfs) we can do what we were not able 30
> years ago. We not need anything in /, really.

Then is / anything other than a root node in a logical tree?

> Anyway, I'm not trying to convince anyone. Just wanted to show the
> links and to make clear among other things that *no one* has ever
> proposed (even less try to force) a non separatable /var. You can
> speculate all you want, but that's all: speculation.

Everything seems to revolve around coming upon a more-correct or
most-correct solution. The speculation is nothing more than thinking
ahead about consequences, and whether or not the change to udev
ultimately solves anything, or whether it is merely change for
change's sake. I don't see that it solves the logical problem the
Fedora dev claims it solves.



-- 
:wq

Re: [gentoo-user] udev + /usr

[Alex Schuster]

Canek Peláez Valdés writes:

> But what you guys don't seem to realize is that /lib and /bin and
> /sbin was the original hack: everything really should go into /usr,
> because now (with an initramfs) we can do what we were not able 30
> years ago. We not need anything in /, really.

You do have a point here.

> Anyway, I'm not trying to convince anyone. Just wanted to show the
> links and to make clear among other things that *no one* has ever
> proposed (even less try to force) a non separatable /var. You can
> speculate all you want, but that's all: speculation.

I cannot find it, but I'm very sure I just read about /var also being
affected. But it looks indeed like that will not be necessary at all.

> Going back to work: nice chatting with you guys.

Thanks for your input and your time.

Personally, I don't really care that much. Either I somehow update my
initramfs (I expect this to be easy) to include the stuff needed
formounting /usr, or I extend my root partition and put /usr in it. I
still don't like that much, but there are just more important problems,
and it's really not such a big deal. Just another big update that needs
manual intervention, as it happens from time to time. Like the migration
to openrc for example. I wonder why no one complained about that when it
happened.

	Wonko

Re: [gentoo-user] udev + /usr

[Joost Roeleveld]

On Monday, September 12, 2011 10:24:05 PM Alex Schuster wrote:
> Canek Peláez Valdés writes:
> > But what you guys don't seem to realize is that /lib and /bin and
> > /sbin was the original hack: everything really should go into /usr,
> > because now (with an initramfs) we can do what we were not able 30
> > years ago. We not need anything in /, really.
> 
> You do have a point here.
> 
> > Anyway, I'm not trying to convince anyone. Just wanted to show the
> > links and to make clear among other things that *no one* has ever
> > proposed (even less try to force) a non separatable /var. You can
> > speculate all you want, but that's all: speculation.
> 
> I cannot find it, but I'm very sure I just read about /var also being
> affected. But it looks indeed like that will not be necessary at all.

What about dependencies for:
/var/lock/lvm/..... (For LVM-operations)
/var/run/dbus/system_bus_socket (Isn't "dbus" going to be part of systemd?)

To me, this seems like either these need to be moved to "/", or there is a 
dependency for /var.

> > Going back to work: nice chatting with you guys.
> 
> Thanks for your input and your time.
> 
> Personally, I don't really care that much. Either I somehow update my
> initramfs (I expect this to be easy) to include the stuff needed
> formounting /usr, or I extend my root partition and put /usr in it. I
> still don't like that much, but there are just more important problems,
> and it's really not such a big deal. Just another big update that needs
> manual intervention, as it happens from time to time. Like the migration
> to openrc for example. I wonder why no one complained about that when it
> happened.

The migration to openrc went fine for me when it went into stable. The only 
issue I had was that /etc/init.d/net.eth0 didn't exist. That was an easy fix.
I'm glad I always have access to the console here.
This was also reported quite early in the documentation and mailing lists, 
which I checked *after* I upgraded one of the xen-domains on the server.

This requirement is going to force me to use an init* for all my machines and 
I need to check how to get this to work for Xen PV-domains. I have managed to 
avoid using bootloaders for this as I don't store the kernel on the domains 
themselves.

--
Joost

Re: [gentoo-user] udev + /usr

[Alan Mackenzie]

On Mon, Sep 12, 2011 at 03:35:19PM -0400, Canek Peláez Valdés wrote:

> > I read that page. I understand the problem. I'm not convinced.

> I can respect that. I can only then say that we must agree to
> disagree, because I also understand the problem, and I am convinced.

> But what you guys don't seem to realize is that /lib and /bin and
> /sbin was the original hack: everything really should go into /usr,
> because now (with an initramfs) we can do what we were not able 30
> years ago. We not need anything in /, really.

They could have put everything on /usr 30 years ago, if they'd have seen
fit.  They saw then good reason not to.  What you and KS seem oblivious
to is the reason for /bin, /sbin.  It is to allow a small boot so as to
permit system maintenance - fsck, resizing or moving partions, even
undeleting files - all these things are difficult, or even impossible
perhaps, if the pertinent partition is mounted.  To pretend otherwise is
disingenuous.

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

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: [gentoo-user] udev + /usr

[Peter Humphrey]

On Monday 12 September 2011 21:31:09 Alan Mackenzie wrote:

> They could have put everything on /usr 30 years ago, if they'd have seen
> fit.  They saw then good reason not to.  What you and KS seem oblivious
> to is the reason for /bin, /sbin.  It is to allow a small boot so as to
> permit system maintenance - fsck, resizing or moving partions, even
> undeleting files - all these things are difficult, or even impossible
> perhaps, if the pertinent partition is mounted.

It wouldn't be everyone's favourite method, but for those purposes I always 
install a small rescue system at the end of the the disk, with its own entry 
in grub.conf, and with fstab and mount points arranged for convenient 
maintenance.

And nowadays, of course, the ready availability of rescue systems on USB, CD 
etc saves you even having to set that up if you prefer not to. That might 
not be useful on server farms, though.

-- 
Rgds
Peter		Linux Counter 5290, 1994-04-23

Re: [gentoo-user] udev + /usr

[Joost Roeleveld]

On Tuesday, September 13, 2011 04:18:38 AM Peter Humphrey wrote:
> On Monday 12 September 2011 21:31:09 Alan Mackenzie wrote:
> > They could have put everything on /usr 30 years ago, if they'd have seen
> > fit.  They saw then good reason not to.  What you and KS seem oblivious
> > to is the reason for /bin, /sbin.  It is to allow a small boot so as to
> > permit system maintenance - fsck, resizing or moving partions, even
> > undeleting files - all these things are difficult, or even impossible
> > perhaps, if the pertinent partition is mounted.
> 
> It wouldn't be everyone's favourite method, but for those purposes I always
> install a small rescue system at the end of the the disk, with its own entry
> in grub.conf, and with fstab and mount points arranged for convenient
> maintenance.
> 
> And nowadays, of course, the ready availability of rescue systems on USB, CD
> etc saves you even having to set that up if you prefer not to. That might
> not be useful on server farms, though.

You'd still need to keep those updated with current versions and tools. Even 
for my desktop I find that a non-usable solution.
The rescue-systems are nice, for when my system won't boot at all. The 
likelihood of needing a rescue-cd/usb/... will increase substantially when all 
partitions need to be mounted even before init starts.
Especially as I don't expect an automated tool that will keep the init* 
updated after EVERY emerge/kernel-compile/....

I see a requirement for every ebuild to add the following:
*** pseude-code ***
if ebuild part of set in init* then
  rebuild init*
*******

When the rebuild part ever breaks, the whole boot-process will break. We'll be 
making Linux worse then MS Windows 95.

--
Joost

Re: [gentoo-user] udev + /usr

[Paul Colquhoun]

On Mon, 12 Sep 2011 08:31:09 PM Alan Mackenzie wrote:
> On Mon, Sep 12, 2011 at 03:35:19PM -0400, Canek Peláez Valdés wrote:
> > > I read that page. I understand the problem. I'm not convinced.
> > 
> > I can respect that. I can only then say that we must agree to
> > disagree, because I also understand the problem, and I am convinced.
> > 
> > But what you guys don't seem to realize is that /lib and /bin and
> > /sbin was the original hack: everything really should go into /usr,
> > because now (with an initramfs) we can do what we were not able 30
> > years ago. We not need anything in /, really.
> 
> They could have put everything on /usr 30 years ago, if they'd have seen
> fit.  They saw then good reason not to.  What you and KS seem oblivious
> to is the reason for /bin, /sbin.  It is to allow a small boot so as to
> permit system maintenance - fsck, resizing or moving partions, even
> undeleting files - all these things are difficult, or even impossible
> perhaps, if the pertinent partition is mounted.  To pretend otherwise is
> disingenuous.
> 
> > Regards.


Of course, nowdays you can do the maintanence from a bootable CD or a minimal 
shell running from within an initramfs, so that problem has multiple 
solutions.

My major worry is that udev is happily running arbitrary scripts from 
arbitrary locations early in the boot process, and is actively trying to make 
this easier.

How much more Microsoft-security-ish do we want Linux to get?


-- 
Reverend Paul Colquhoun, ULC.    http://andor.dropbear.id.au/~paulcol
 Before you criticize someone, you should walk a mile in their shoes.
Then, when you do, you'll be a mile away, and you'll have their shoes.

Re: [gentoo-user] udev + /usr

[Dale]

Paul Colquhoun wrote:
> On Mon, 12 Sep 2011 08:31:09 PM Alan Mackenzie wrote:
>> On Mon, Sep 12, 2011 at 03:35:19PM -0400, Canek Peláez Valdés wrote:
>>>> I read that page. I understand the problem. I'm not convinced.
>>> I can respect that. I can only then say that we must agree to
>>> disagree, because I also understand the problem, and I am convinced.
>>>
>>> But what you guys don't seem to realize is that /lib and /bin and
>>> /sbin was the original hack: everything really should go into /usr,
>>> because now (with an initramfs) we can do what we were not able 30
>>> years ago. We not need anything in /, really.
>> They could have put everything on /usr 30 years ago, if they'd have seen
>> fit.  They saw then good reason not to.  What you and KS seem oblivious
>> to is the reason for /bin, /sbin.  It is to allow a small boot so as to
>> permit system maintenance - fsck, resizing or moving partions, even
>> undeleting files - all these things are difficult, or even impossible
>> perhaps, if the pertinent partition is mounted.  To pretend otherwise is
>> disingenuous.
>>
>>> Regards.
>
> Of course, nowdays you can do the maintanence from a bootable CD or a minimal
> shell running from within an initramfs, so that problem has multiple
> solutions.
>

You do know that some systems don't have that ability right?  Some 
servers don't even have a CD drive at all.  Also, some people manage 
remote system where they have no physical access at all.  I feel sorry 
for those for sure.

Dale

:-)  :-)

Re: [gentoo-user] udev + /usr

[David W Noon]

[-- Attachment #1: Type: text/plain, Size: 2706 bytes --]

On Mon, 12 Sep 2011 15:00:49 -0400, Michael Mol wrote about Re:
[gentoo-user] udev + /usr:

> On Mon, Sep 12, 2011 at 2:37 PM, Canek Peláez Valdés
> <caneko@gmail.com> wrote:
[snip]
> > And then you lose the flexibility.
> 
> Here's the chief problem with that argument...it's not just limited to
> /usr. If you're going to say that a script can do whatever it wants,
> and udev will make declarative statements about supported and
> unsupported filesystem layouts to allow that to work, then you *must*
> say that the entire filesystem be on the same partition as /, or that
> one must use initramfs.
> 
> Because you can't know that a script won't depend on something under
> /var. Or /opt. Or /home.  And if if /home is excluded from this
> must-be-available set, what makes it more special than /usr? If it's
> OK to say "no script must access files under /home", then why isn't it
> OK to say "no script must access files under /usr"?

This gets back to what I wrote a few days back: put everything on / and
call it C:.

The real question is: how much flexibility do udev scripts actually
need?

My take is that udev scripts should only need to handle hardware
interfaces presenting devices to the system, at least early in the
bootstrap sequence.  Later on, virtual devices, such as those presented
by virtual machine managers to connect to the outside, need also to be
handled.

Then we have to consider what resources these scripts should be allowed
to use.  The main bugbear here is [semi-]interpretive scripting
languages, such as Perl and Python.  Quite simply, these should not be
used.  The external resources used by udev scripts should be statically
linked, native object code binaries; this includes the system shells
such as bash, zsh, etc.  This has always been the case for hardware
management code -- and with good reason: the greater the complexity of
getting a piece of functionality running, the higher the likelihood
that something is not yet available and it will fail.  Yes, this is old;
it's FORTRAN; it's COBOL; but it works reliably with minimal stress on
the hardware.

Now it becomes a matter of identifying those udev scripts that violate
this idea and replacing them with better code.  Logging script failures
would be a first step in the right direction.  However, given that many
of the people coding these scripts don't bother checking return codes,
this could be "asking for the moon on a stick".
-- 
Regards,

Dave  [RLU #314465]
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
dwnoon@ntlworld.com (David W Noon)
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-user] udev + /usr

[Michael Schreckenbauer]

On Monday, 12. September 2011 14:37:24 Canek Peláez Valdés wrote:
> On Mon, Sep 12, 2011 at 1:39 PM, Michael Mol <mikemol@gmail.com> wrote:
> > On Mon, Sep 12, 2011 at 1:17 PM, Alan Mackenzie <acm@muc.de> wrote:
> >> On Mon, Sep 12, 2011 at 05:33:34PM +0200, Michael Schreckenbauer wrote:
> >>> On Monday, 12. September 2011 15:02:48 Alan Mackenzie wrote:
> >>> > Hope nobody minds me starting a new thread with an accurate
> >>> > name.
> >>> > 
> >>> > Which version of udev is it that has this nauseating feature of
> >>> > needing /usr loaded to boot?
> >>> > 
> >>> > Somewhere in that version's source will be several (or lots of)
> >>> > "/usr". Just how difficult is it going to be to replace
> >>> > "/usr/bin" with "/bin" throughout the source?
> >>> 
> >>> you misunderstood something. udev is able to run arbitrary scripts.
> >>> Some of those scripts are located in /usr/* or need something
> >>> there. I doubt you will find references to /usr in the
> >>> udev-sources.
> >> 
> >> Well, I'm a hacker.  udev is free source, therefore fair game.  I
> >> don't
> >> intend to put up with this nonsense without a fight.  As far as I can
> >> make out, this is just one guy, Kay Sievers, who's on a power trip.
> >>  Are
> >> there any indications at all that he actually talked to anybody in the
> >> wide world before making such a far reaching decision?
> > 
> > udev has always been able to run arbitrary scripts. The trouble is
> > that the arbitrary scripts other packages provide sometimes call for
> > things under /usr.
> > 
> > If I've read messages over the last couple days correctly, I think the
> > recent change is that some stuff udev *directly* depends on, as part
> > of the udev package itself, is being moved into /usr.
> > 
> > My best guess is that this allows udev to force the issue; it gets
> > blamed for other packages not loading correctly (when those other
> > packages put things in places which may or may not be available yet),
> > so the udev developer chose to force systems to have all of /usr
> > available before udev is run.
> > 
> > The first step in a clean solution, IMO, is to revert that change. The
> > second step is to fix the 'silent failure' problem for packages which
> > depend on /usr before /usr is available.
> 
> No fixable, in reality. The flexibility of udev is in part in that the
> userspace can (and actually do) run arbitrary scripts and binaries
> from udev rules. You can "fix" the ones that require binaries in /usr
> *NOW*, but not forever, unless you forbid the use of arbitrary
> binaries from udev rules.

Why do you need to run arbitrary scripts to mount /usr?

> Linux has a much better, flexible and automatized (dracut) way of
> doing this, by using an initramfs. With an initramfs you can have the
> smallest / in the world, and mount everything else afterwards. The
> initramfs memory is free'd after the pivot_root happens, so who cares
> how big it is?

KISS. An initramfs is an additional layer, that can fail.

> Regards.

Regards,
Michael

Re: [gentoo-user] udev + /usr

[Michael Mol]

On Mon, Sep 12, 2011 at 3:07 PM, Michael Schreckenbauer <grimlog@gmx.de> wrote:
> On Monday, 12. September 2011 14:37:24 Canek Peláez Valdés wrote:
>> No fixable, in reality. The flexibility of udev is in part in that the
>> userspace can (and actually do) run arbitrary scripts and binaries
>> from udev rules. You can "fix" the ones that require binaries in /usr
>> *NOW*, but not forever, unless you forbid the use of arbitrary
>> binaries from udev rules.
>
> Why do you need to run arbitrary scripts to mount /usr?

It's not specifically that you need to run arbitrary scripts to mount
/usr. It's that it's unknown that /usr must be mounted before some
hotplug events are handled.

>
>> Linux has a much better, flexible and automatized (dracut) way of
>> doing this, by using an initramfs. With an initramfs you can have the
>> smallest / in the world, and mount everything else afterwards. The
>> initramfs memory is free'd after the pivot_root happens, so who cares
>> how big it is?
>
> KISS. An initramfs is an additional layer, that can fail.

Concur. While a massive machine full of moving parts is beautiful to
behold, it's also the easiest thing to break, accidentally or
otherwise.

-- 
:wq

Re: [gentoo-user] udev + /usr

[Michael Schreckenbauer]

On Monday, 12. September 2011 15:18:53 Michael Mol wrote:
> On Mon, Sep 12, 2011 at 3:07 PM, Michael Schreckenbauer <grimlog@gmx.de> 
wrote:
> > On Monday, 12. September 2011 14:37:24 Canek Peláez Valdés wrote:
> >> No fixable, in reality. The flexibility of udev is in part in that the
> >> userspace can (and actually do) run arbitrary scripts and binaries
> >> from udev rules. You can "fix" the ones that require binaries in /usr
> >> *NOW*, but not forever, unless you forbid the use of arbitrary
> >> binaries from udev rules.
> > 
> > Why do you need to run arbitrary scripts to mount /usr?
> 
> It's not specifically that you need to run arbitrary scripts to mount
> /usr. It's that it's unknown that /usr must be mounted before some
> hotplug events are handled.

Claiming "this is not fixable... unless you forbid the use of arbitrary  
binaries from udev rules" implies, that you need to run arbitrary scripts to 
mount /usr. Otherwise a fix would be to mount /usr with whatever is needed to 
do this and then run the arbitrary scripts. Sadly udev does not support this.

Best,
Michael

Re: [gentoo-user] udev + /usr

[Michael Mol]

On Mon, Sep 12, 2011 at 3:41 PM, Michael Schreckenbauer <grimlog@gmx.de> wrote:
> On Monday, 12. September 2011 15:18:53 Michael Mol wrote:
>> On Mon, Sep 12, 2011 at 3:07 PM, Michael Schreckenbauer <grimlog@gmx.de>
> wrote:
>> > On Monday, 12. September 2011 14:37:24 Canek Peláez Valdés wrote:
>> >> No fixable, in reality. The flexibility of udev is in part in that the
>> >> userspace can (and actually do) run arbitrary scripts and binaries
>> >> from udev rules. You can "fix" the ones that require binaries in /usr
>> >> *NOW*, but not forever, unless you forbid the use of arbitrary
>> >> binaries from udev rules.
>> >
>> > Why do you need to run arbitrary scripts to mount /usr?
>>
>> It's not specifically that you need to run arbitrary scripts to mount
>> /usr. It's that it's unknown that /usr must be mounted before some
>> hotplug events are handled.
>
> Claiming "this is not fixable... unless you forbid the use of arbitrary
> binaries from udev rules" implies, that you need to run arbitrary scripts to
> mount /usr.

No, it states that it's not solveable for the broadest set of cases (I
hesitate to say 'universally') unless you can run arbitrary scripts
which may be in /usr.

Consider it possible that nfsd is needed to mount /usr. The
credentials needed for NFS to connect to the server are on an
encrypted partition. The key for decrypting that partition is stored
on a USB flash drive. The USB flash drive is formatted using a very
recent version of NTFS. FUSE is necessary to read that flash drive's
filesystem.

In this scenario, the NFS binaries and FUSE binaries are located under /usr.

It's this kind of scenario that falls under the general class that
udev's trying to solve. If I understand it properly, the mentality is,
"I can't forsee what distros and sysadmins will want to do, I get bug
reports when peoples' configurations fail because they were trying to
load things from unmounted filesystems, so if I say the filesystem
*must* be mounted (or they must use an initramfs) in order to use
udev, those bug reports will solve themselves."

> Otherwise a fix would be to mount /usr with whatever is needed to
> do this and then run the arbitrary scripts. Sadly udev does not support this.

Which requires some kind of dependency or retry scheme, which adds
complexity to udev that the Fedora dev decided he didn't want to spend
the time on.

-- 
:wq

Re: [gentoo-user] udev + /usr

[Alan McKinnon]

On Mon, 12 Sep 2011 16:07:46 -0400
Michael Mol <mikemol@gmail.com> wrote:

> No, it states that it's not solveable for the broadest set of cases (I
> hesitate to say 'universally') unless you can run arbitrary scripts
> which may be in /usr.
> 
> Consider it possible that nfsd is needed to mount /usr. The
> credentials needed for NFS to connect to the server are on an
> encrypted partition. The key for decrypting that partition is stored
> on a USB flash drive. The USB flash drive is formatted using a very
> recent version of NTFS. FUSE is necessary to read that flash drive's
> filesystem.

You do realize what you just did, right?

You ruined a wonderfully heated argument by inserting perfectly
valid facts.

I must now wander off and re-consider my position. I don't like you and
you're not my friend anymore <waaaaaaaaah, weep>

:-)



-- 
Alan McKinnnon
alan.mckinnon@gmail.com

Re: [gentoo-user] udev + /usr

[Michael Schreckenbauer]

On Monday, 12. September 2011 22:57:40 Alan McKinnon wrote:
> On Mon, 12 Sep 2011 16:07:46 -0400
> 
> Michael Mol <mikemol@gmail.com> wrote:
> > No, it states that it's not solveable for the broadest set of cases (I
> > hesitate to say 'universally') unless you can run arbitrary scripts
> > which may be in /usr.
> > 
> > Consider it possible that nfsd is needed to mount /usr. The
> > credentials needed for NFS to connect to the server are on an
> > encrypted partition. The key for decrypting that partition is stored
> > on a USB flash drive. The USB flash drive is formatted using a very
> > recent version of NTFS. FUSE is necessary to read that flash drive's
> > filesystem.
> 
> You do realize what you just did, right?
> 
> You ruined a wonderfully heated argument by inserting perfectly
> valid facts.

I'd love to see the working initramfs for that scenario...
and then the version dracut made :)

> I must now wander off and re-consider my position. I don't like you and
> you're not my friend anymore <waaaaaaaaah, weep>
> 
> :-)

Best,
Michael

Re: [gentoo-user] udev + /usr

[Canek Peláez Valdés]

On Mon, Sep 12, 2011 at 6:00 PM, Michael Schreckenbauer <grimlog@gmx.de> wrote:
> On Monday, 12. September 2011 22:57:40 Alan McKinnon wrote:
>> On Mon, 12 Sep 2011 16:07:46 -0400
>>
>> Michael Mol <mikemol@gmail.com> wrote:
>> > No, it states that it's not solveable for the broadest set of cases (I
>> > hesitate to say 'universally') unless you can run arbitrary scripts
>> > which may be in /usr.
>> >
>> > Consider it possible that nfsd is needed to mount /usr. The
>> > credentials needed for NFS to connect to the server are on an
>> > encrypted partition. The key for decrypting that partition is stored
>> > on a USB flash drive. The USB flash drive is formatted using a very
>> > recent version of NTFS. FUSE is necessary to read that flash drive's
>> > filesystem.
>>
>> You do realize what you just did, right?
>>
>> You ruined a wonderfully heated argument by inserting perfectly
>> valid facts.
>
> I'd love to see the working initramfs for that scenario...
> and then the version dracut made :)

Not my use case, so maybe wrong, but:

USE="crypt crypt-gpg nfs" emerge -v sys-kernel/dracut
dracut -H -m "crypt crypt-gpg nfs" --filesystems fuse

...and maybe some -i flags to include the ntfs-3g binaries.

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

Re: [gentoo-user] udev + /usr

[Joost Roeleveld]

On Monday, September 12, 2011 07:31:54 PM Canek Peláez Valdés wrote:
> On Mon, Sep 12, 2011 at 6:00 PM, Michael Schreckenbauer <grimlog@gmx.de> 
wrote:
> > On Monday, 12. September 2011 22:57:40 Alan McKinnon wrote:
> >> On Mon, 12 Sep 2011 16:07:46 -0400
> >> 
> >> Michael Mol <mikemol@gmail.com> wrote:
> >> > No, it states that it's not solveable for the broadest set of
> >> > cases (I
> >> > hesitate to say 'universally') unless you can run arbitrary
> >> > scripts
> >> > which may be in /usr.
> >> > 
> >> > Consider it possible that nfsd is needed to mount /usr. The
> >> > credentials needed for NFS to connect to the server are on an
> >> > encrypted partition. The key for decrypting that partition is
> >> > stored
> >> > on a USB flash drive. The USB flash drive is formatted using a
> >> > very
> >> > recent version of NTFS. FUSE is necessary to read that flash
> >> > drive's
> >> > filesystem.
> >> 
> >> You do realize what you just did, right?
> >> 
> >> You ruined a wonderfully heated argument by inserting perfectly
> >> valid facts.
> > 
> > I'd love to see the working initramfs for that scenario...
> > and then the version dracut made :)
> 
> Not my use case, so maybe wrong, but:
> 
> USE="crypt crypt-gpg nfs" emerge -v sys-kernel/dracut
> dracut -H -m "crypt crypt-gpg nfs" --filesystems fuse
> 
> ...and maybe some -i flags to include the ntfs-3g binaries.

Having to specify all these options doesn't show "dracut" to be very clever to 
me.
It should automatically parse someones configuration and create the required 
init* to get to a "udev-god-supported-version".
A tool that does that will make this less invasive.

--
Joost

Re: [gentoo-user] udev + /usr

[Michael Schreckenbauer]

On Monday, 12. September 2011 19:31:54 Canek Peláez Valdés wrote:
> On Mon, Sep 12, 2011 at 6:00 PM, Michael Schreckenbauer <grimlog@gmx.de> 
wrote:
> > On Monday, 12. September 2011 22:57:40 Alan McKinnon wrote:
> >> On Mon, 12 Sep 2011 16:07:46 -0400
> >> 
> >> Michael Mol <mikemol@gmail.com> wrote:
> >> > No, it states that it's not solveable for the broadest set of
> >> > cases (I
> >> > hesitate to say 'universally') unless you can run arbitrary
> >> > scripts
> >> > which may be in /usr.
> >> > 
> >> > Consider it possible that nfsd is needed to mount /usr. The
> >> > credentials needed for NFS to connect to the server are on an
> >> > encrypted partition. The key for decrypting that partition is
> >> > stored
> >> > on a USB flash drive. The USB flash drive is formatted using a
> >> > very
> >> > recent version of NTFS. FUSE is necessary to read that flash
> >> > drive's
> >> > filesystem.
> >> 
> >> You do realize what you just did, right?
> >> 
> >> You ruined a wonderfully heated argument by inserting perfectly
> >> valid facts.
> > 
> > I'd love to see the working initramfs for that scenario...
> > and then the version dracut made :)
> 
> Not my use case, so maybe wrong, but:
> 
> USE="crypt crypt-gpg nfs" emerge -v sys-kernel/dracut
> dracut -H -m "crypt crypt-gpg nfs" --filesystems fuse

USE does not work. Has to be DRACUT_MODULES :)

> ...and maybe some -i flags to include the ntfs-3g binaries.

Maybe... what if I miss some modules, so that my initramfs is not able to 
mount /usr? I assume dracut is installed in /usr/*? How would one get a 
working system again?

> Regards.

Best,
Michael

Re: [gentoo-user] udev + /usr

[Pandu Poluan]

[-- Attachment #1: Type: text/plain, Size: 3604 bytes --]

On Sep 13, 2011 3:16 AM, "Michael Mol" <mikemol@gmail.com> wrote:
>
> On Mon, Sep 12, 2011 at 3:41 PM, Michael Schreckenbauer <grimlog@gmx.de>
wrote:
> > On Monday, 12. September 2011 15:18:53 Michael Mol wrote:
> >> On Mon, Sep 12, 2011 at 3:07 PM, Michael Schreckenbauer <grimlog@gmx.de
>
> > wrote:
> >> > On Monday, 12. September 2011 14:37:24 Canek Peláez Valdés wrote:
> >> >> No fixable, in reality. The flexibility of udev is in part in that
the
> >> >> userspace can (and actually do) run arbitrary scripts and binaries
> >> >> from udev rules. You can "fix" the ones that require binaries in
/usr
> >> >> *NOW*, but not forever, unless you forbid the use of arbitrary
> >> >> binaries from udev rules.
> >> >
> >> > Why do you need to run arbitrary scripts to mount /usr?
> >>
> >> It's not specifically that you need to run arbitrary scripts to mount
> >> /usr. It's that it's unknown that /usr must be mounted before some
> >> hotplug events are handled.
> >
> > Claiming "this is not fixable... unless you forbid the use of arbitrary
> > binaries from udev rules" implies, that you need to run arbitrary
scripts to
> > mount /usr.
>
> No, it states that it's not solveable for the broadest set of cases (I
> hesitate to say 'universally') unless you can run arbitrary scripts
> which may be in /usr.
>
> Consider it possible that nfsd is needed to mount /usr. The
> credentials needed for NFS to connect to the server are on an
> encrypted partition. The key for decrypting that partition is stored
> on a USB flash drive. The USB flash drive is formatted using a very
> recent version of NTFS. FUSE is necessary to read that flash drive's
> filesystem.
>
> In this scenario, the NFS binaries and FUSE binaries are located under
/usr.
>
> It's this kind of scenario that falls under the general class that
> udev's trying to solve. If I understand it properly, the mentality is,
> "I can't forsee what distros and sysadmins will want to do, I get bug
> reports when peoples' configurations fail because they were trying to
> load things from unmounted filesystems, so if I say the filesystem
> *must* be mounted (or they must use an initramfs) in order to use
> udev, those bug reports will solve themselves."
>
> > Otherwise a fix would be to mount /usr with whatever is needed to
> > do this and then run the arbitrary scripts. Sadly udev does not support
this.
>
> Which requires some kind of dependency or retry scheme, which adds
> complexity to udev that the Fedora dev decided he didn't want to spend
> the time on.
>
> --
> :wq
>

Hmmm... after reading Michael (non_grimlog)'s explanation, I'm starting to
understand udev's dev's thoughts.

It seems too many people (mis)use udev to execute something in /usr while at
the same time using a separated /usr that needs to be mounted first. Too
many people are perhaps too lazy to RTFM, and blame the resulting boot
failure to udev.

Understandable, but his way out is instead by forcing a 'way of life' that's
incompatible with what many sysadmins (especially Gentoo sysadmins) are
familiar with.

So the solution IMO should be:

* Keep udev as it was before (i.e., living in / instead of in /usr) and
somehow make sure that everyone RTFM/RTFFAQ, or

* Make two versions of udev, one which lives in / for those who've done
their homework, and another version in /usr for the ignoramuses

Users of 'Technical Distros' like Gentoo can choose between root-udev or
usr-udev, while 'Less Technical Distros' can just use usr-udev
out-of-the-box.

Rgds,

[-- Attachment #2: Type: text/html, Size: 4424 bytes --]

Re: [gentoo-user] udev + /usr

[Walter Dnes]

On Tue, Sep 13, 2011 at 04:14:26AM +0700, Pandu Poluan wrote

> * Keep udev as it was before (i.e., living in / instead of in /usr) and
> somehow make sure that everyone RTFM/RTFFAQ, or
> 
> * Make two versions of udev, one which lives in / for those who've done
> their homework, and another version in /usr for the ignoramuses
> 
> Users of 'Technical Distros' like Gentoo can choose between root-udev or
> usr-udev, while 'Less Technical Distros' can just use usr-udev
> out-of-the-box.

Gimmee an "F"
FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF

Gimmee an "O"
OOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOO

Gimmee an "R"
RRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRR

Gimmee a  "K"
KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK

What does that spell?
FORK

What does that spell?
FORK

What does that spell?
FORK

Well come on all you big stronger coders
Uncle UDEV is stinking up with nasty odors
Got himself in a terrible jam
Won't boot up without INIT RAM(fs)



  That's about all I can come up with on short notice...

NSFW (Not Safe For Work) video, due to coarse language, search for
"Woodstock Cheer" on YouTube.

-- 
Walter Dnes <waltdnes@waltdnes.org>

Re: [gentoo-user] udev + /usr

[Joost Roeleveld]

On Monday, September 12, 2011 04:07:46 PM Michael Mol wrote:
> On Mon, Sep 12, 2011 at 3:41 PM, Michael Schreckenbauer <grimlog@gmx.de> 
wrote:
> > On Monday, 12. September 2011 15:18:53 Michael Mol wrote:
> >> On Mon, Sep 12, 2011 at 3:07 PM, Michael Schreckenbauer
> >> <grimlog@gmx.de>
> > 
> > wrote:
> >> > On Monday, 12. September 2011 14:37:24 Canek Peláez Valdés wrote:
> >> >> No fixable, in reality. The flexibility of udev is in part in
> >> >> that the userspace can (and actually do) run arbitrary scripts
> >> >> and binaries from udev rules. You can "fix" the ones that
> >> >> require binaries in /usr *NOW*, but not forever, unless you
> >> >> forbid the use of arbitrary binaries from udev rules.
> >> > 
> >> > Why do you need to run arbitrary scripts to mount /usr?
> >> 
> >> It's not specifically that you need to run arbitrary scripts to mount
> >> /usr. It's that it's unknown that /usr must be mounted before some
> >> hotplug events are handled.
> > 
> > Claiming "this is not fixable... unless you forbid the use of arbitrary
> > binaries from udev rules" implies, that you need to run arbitrary
> > scripts to mount /usr.
> 
> No, it states that it's not solveable for the broadest set of cases (I
> hesitate to say 'universally') unless you can run arbitrary scripts
> which may be in /usr.
> 
> Consider it possible that nfsd is needed to mount /usr. The
> credentials needed for NFS to connect to the server are on an
> encrypted partition. The key for decrypting that partition is stored
> on a USB flash drive. The USB flash drive is formatted using a very
> recent version of NTFS. FUSE is necessary to read that flash drive's
> filesystem.
> 
> In this scenario, the NFS binaries and FUSE binaries are located under /usr.

Since when does NFS need credentials to connect to the server? :)

also, why use NTFS on a flash-drive storing the keys, this is simply an 
example of someone trying to be clever and being far too lazy to properly 
implement it.
It should fail and the error message should read: "PEBKAC" (Problem Exists 
Between Keyboard And Chair)

> It's this kind of scenario that falls under the general class that
> udev's trying to solve. If I understand it properly, the mentality is,
> "I can't forsee what distros and sysadmins will want to do, I get bug
> reports when peoples' configurations fail because they were trying to
> load things from unmounted filesystems, so if I say the filesystem
> *must* be mounted (or they must use an initramfs) in order to use
> udev, those bug reports will solve themselves."

In other words, this dev has a god-complex and feels he should fix all that is 
wrong in this world.
He should do his job and fix his error-reporting and documentation to specify 
that EITHER the people demanding this ensure the scripts run by udev will work 
with only "/" mounted or ensure all other required partitions are mounted by 
init*.
Not force all partitions to be available when "init" starts.

> > Otherwise a fix would be to mount /usr with whatever is needed to
> > do this and then run the arbitrary scripts. Sadly udev does not support
> > this.
> Which requires some kind of dependency or retry scheme, which adds
> complexity to udev that the Fedora dev decided he didn't want to spend
> the time on.

Fixing the docs and error-reporting is the logical and least invasive option.

--
Joost

Re: [gentoo-user] udev + /usr

[Dale]

Canek Peláez Valdés wrote:
> And yeah, that's not how classical Unix do things. Who cares? Linux 
> does it so much better. Regards. 

Some of us here care.  That is the reason we are not liking this one bit.

Dale

:-)  :-)

Re: [gentoo-user] udev + /usr

[Walter Dnes]

On Mon, Sep 12, 2011 at 02:37:24PM -0400, Canek Pel??ez Vald??s wrote

> No fixable, in reality. The flexibility of udev is in part in that the
> userspace can (and actually do) run arbitrary scripts and binaries
> from udev rules. You can "fix" the ones that require binaries in /usr
> *NOW*, but not forever, unless you forbid the use of arbitrary
> binaries from udev rules.

  No the problem is that I don't think we should force 100% of all
users to migrate to initramfs or a Windows-like C:\ simply to satisfy
the 1% that run into problems with the current udev.  Let *THOSE* users
migrate to initramfs or a Windows-like C:\.

> And then you lose the flexibility.

  And then *I* lose the flexibility of a small / *WITHOUT* initramfs.

[i3][root][/] "fdisk -l" shows

   Device Boot      Start         End      Blocks   Id  System
/dev/sda1              63  1953520064   976760001    5  Extended
/dev/sda5             126      530144      265009+  83  Linux
/dev/sda6          530208    19422584     9446188+  82  Linux swap / Solaris
/dev/sda7        19422648  1953520064   967048708+  83  Linux

  Some lines from /etc/fstab
/dev/sda5               /         ext2     noatime,nodiratime,async 0 1
/dev/sda7               /home     reiserfs noatime,nodiratime,async,notail 0 1
/home/bindmounts/opt    /opt      auto     bind 0 0
/home/bindmounts/var    /var      auto     bind 0 0
/home/bindmounts/usr    /usr      auto     bind 0 0
/home/bindmounts/tmp    /tmp      auto     bind 0 0
/dev/sda6               none      swap     sw 0 0

[i3][root][/] du -cs /usr
5664646 /usr
5664646 total

> And yeah, that's not how classical Unix do things. Who cares? Linux
> does it so much better.

And yeah, that's not how classical Gentoo does things. Who cares? Distro X
does it so much better. </SARCASM>  Guess what, if I really wanted to
run Distro X, I'd be running Distro X.

  And for those that claim /var would never be needed early, what if
somebody's weirdo setup wants a network connection early?  I assume
they'd want the firewall to be up when the network goes up.  Ever heard
of /var/lib/iptables/rules-save ?

-- 
Walter Dnes <waltdnes@waltdnes.org>

Re: [gentoo-user] udev + /usr

[Neil Bothwick]

[-- Attachment #1: Type: text/plain, Size: 779 bytes --]

On Mon, 12 Sep 2011 23:28:07 -0400, Walter Dnes wrote:

>   And for those that claim /var would never be needed early, what if
> somebody's weirdo setup wants a network connection early?  I assume
> they'd want the firewall to be up when the network goes up.  Ever heard
> of /var/lib/iptables/rules-save ?

This is why the whole /usr issue is irrelevant and not a fix at all. All
it does is avoid the most common breakages caused by udev trying to run
all its rules too early in the boot process. Putting /var on / would
"fix" your example, but what if a rule required access to an NFS mount?

Every time you fix one of these breakages, you are kludging around the
real problem.


-- 
Neil Bothwick

Everyone has a photographic memory. Some don't have film.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-user] udev + /usr

[Walter Dnes]

On Tue, Sep 13, 2011 at 08:04:14AM +0100, Neil Bothwick wrote

> This is why the whole /usr issue is irrelevant and not a fix at all. All
> it does is avoid the most common breakages caused by udev trying to run
> all its rules too early in the boot process. Putting /var on / would
> "fix" your example, but what if a rule required access to an NFS mount?
> 
> Every time you fix one of these breakages, you are kludging around the
> real problem.

  How many people really need to run *ARBITRARY* binaries that early in
the boot process?  The 1% who do shouldn't force the other 99% of us to
go with initramfs or a Windows C:\ drive.  I've masked out pam and hal
and dbus in package.mask and my system runs fine with out them.

  This thread reminds me of the old joke that an elephant is actually a
mouse designed by a committee.  Trying to cover every possible edge case
with a one-size-fits-all solution doesn't work without bloating
everybody's system.  If someone wants an arbitrary binary really early
in bootup, link it statically and save to /etc/udev/bin or where ever,
and leave the other 99% of us to ignore initramfs.  Is this from the
same Redhat that brought us BlueCurve and made Pulseadio the default on
their OS?

-- 
Walter Dnes <waltdnes@waltdnes.org>

Re: [gentoo-user] udev + /usr

[Michael Schreckenbauer]

On Tuesday, 13. September 2011 11:21:22 Walter Dnes wrote:
>   This thread reminds me of the old joke that an elephant is actually a
> mouse designed by a committee.  Trying to cover every possible edge case
> with a one-size-fits-all solution doesn't work without bloating
> everybody's system.  If someone wants an arbitrary binary really early
> in bootup, link it statically and save to /etc/udev/bin or where ever,

+1

> and leave the other 99% of us to ignore initramfs.  Is this from the
> same Redhat that brought us BlueCurve and made Pulseadio the default on
> their OS?

No, this is some other guy.
Kay Sievers hacks on udev, systemd and related stuff. He's the one responsible 
for this "initramfs is needed for separate /usr"-crap afaict.
The one doing pulseaudio is Lennart "BSD isn't relevant anymore" Poettering. 

Best,
Michael

Re: [gentoo-user] udev + /usr

[Neil Bothwick]

[-- Attachment #1: Type: text/plain, Size: 1038 bytes --]

On Tue, 13 Sep 2011 11:21:22 -0400, Walter Dnes wrote:

> > This is why the whole /usr issue is irrelevant and not a fix at all.
> > All it does is avoid the most common breakages caused by udev trying
> > to run all its rules too early in the boot process. Putting /var on /
> > would "fix" your example, but what if a rule required access to an
> > NFS mount?
> > 
> > Every time you fix one of these breakages, you are kludging around the
> > real problem.  
> 
>   How many people really need to run *ARBITRARY* binaries that early in
> the boot process?  The 1% who do shouldn't force the other 99% of us to
> go with initramfs or a Windows C:\ drive.

There is no 1%. The problem is that udev is able to run arbitrary
binaries, which has its advantages, but it also has to be started early
in the boot process to fulfil its other duties. It is trying to combine
these two functions that leads to the need for more than / to be
available before filesystems are mounted.


-- 
Neil Bothwick

Reboot America.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-user] udev + /usr

[Joost Roeleveld]

On Tuesday, September 13, 2011 04:49:25 PM Neil Bothwick wrote:
> On Tue, 13 Sep 2011 11:21:22 -0400, Walter Dnes wrote:
> > > This is why the whole /usr issue is irrelevant and not a fix at all.
> > > All it does is avoid the most common breakages caused by udev trying
> > > to run all its rules too early in the boot process. Putting /var on
> > > /
> > > would "fix" your example, but what if a rule required access to an
> > > NFS mount?
> > > 
> > > Every time you fix one of these breakages, you are kludging around
> > > the
> > > real problem.
> > > 
> >   How many people really need to run *ARBITRARY* binaries that early
> >   in
> > 
> > the boot process?  The 1% who do shouldn't force the other 99% of us to
> > go with initramfs or a Windows C:\ drive.
> 
> There is no 1%. The problem is that udev is able to run arbitrary
> binaries, which has its advantages, but it also has to be started early
> in the boot process to fulfil its other duties. It is trying to combine
> these two functions that leads to the need for more than / to be
> available before filesystems are mounted.

And these 2 capabilities should be handled by different processes.
Process 1: Populate the /dev-tree
Process 2: Run scripts when necessary

Process 2 should NOT be started untill after the local filesystems are 
mounted.

I have not seen any realistic use-cases where process 2 should be started 
sooner. Any script/tool/program that is required to get to the stage where 
process 2 can run should be either in "/" or in an init*.
Eg. for the use-case where fuse, ntfs-3g, nfs, crypt-setup,.... are needed to 
mount the local filesystems, go build an init* and let the rest build more 
sane environments.

--
Joost

Re: [gentoo-user] udev + /usr

[Michael Schreckenbauer]

Hi Alan,

On Monday, 12. September 2011 17:17:37 Alan Mackenzie wrote:
> Hi, Michael.
> 
> On Mon, Sep 12, 2011 at 05:33:34PM +0200, Michael Schreckenbauer wrote:
> > Hi Alan,
> > 
> > On Monday, 12. September 2011 15:02:48 Alan Mackenzie wrote:
> > > Hope nobody minds me starting a new thread with an accurate name.
> > > 
> > > Which version of udev is it that has this nauseating feature of
> > > needing
> > > /usr loaded to boot?
> > > 
> > > Somewhere in that version's source will be several (or lots of)
> > > "/usr".
> > > Just how difficult is it going to be to replace "/usr/bin" with
> > > "/bin"
> > > throughout the source?
> > 
> > you misunderstood something. udev is able to run arbitrary scripts. Some
> > of those scripts are located in /usr/* or need something there. I doubt
> > you will find references to /usr in the udev-sources.
> 
> Well, I'm a hacker.  udev is free source, therefore fair game.  I don't
> intend to put up with this nonsense without a fight.  As far as I can
> make out, this is just one guy, Kay Sievers, who's on a power trip.  Are
> there any indications at all that he actually talked to anybody in the
> wide world before making such a far reaching decision?
> On my current system, udev (164-r2) works without an earlily loaded /usr.
> Seemingly, later versions don't.  That was why I was asking for somebody
> to identify one of these later versions for me.

it works for you, because your udev-rules need nothing from /usr/*
It's *not* udev requiring /usr, it's the scripts triggered by the rules.

> > > udev is part of the kernel.
> > 
> > No. udev is usperspace.
> 
> OK, udev is in userspace, _very_ _close_ to the kernel.  ;-)
> 
> > > How come the kernel hackers aren't up in arms about this as much as
> > > we are?  Or are they, maybe?  In which case, maybe the kernel people
> > > would welcome an option to disrequire the early mounting of /usr as
> > > much as we would.
> > > 
> > > Anyhow, I'd like to take a peek at the source code which does this
> > > evil
> > > thing.  Would somebody please tell me which version of udev is
> > > involved.> 
> > Every udev version works this way.
> 
> My udev (164-r2) is just fine at the moment.  I'm not sure what you mean
> by that statement.

It works for you.
Every udev-version I know of, is able to run any script you like it to.

> > Fixing udev to continue working with separate /usr is far from trivial
> > imo. Changing some paths is not the way to go for sure.
> 
> Maybe, maybe not.

No, I wrote "for sure", because I *know* this.

> But it seems a changing of paths (/ -> /usr) is
> precisely what is breaking newer udevs.

No, it is *not*

> It might be possible to change
> them back.  This could involve moving a fair amount of stuff from /usr to
> /, but not half as much as moving the entire /usr partition.

Again, udev can run arbitrary scripts.

> > First of all, udev has to distinguish between "device not present" and
> > "script error of some kind". Failing scripts have to be queued somehow
> > for later execution. If a script keeps failing, it has to be removed
> > from that queue, with a message to syslog or something like that. If
> > udev needs a script in /usr/* to mount /usr then there's a
> > chicken-egg-problem, which could be hard to solve (if possible at all
> > without moving things from /usr/ to /). Note, that I am wild guessing
> > here, I did not study the udev sources or any related script/rule :)
> 
> This sounds like a separate (if related) problem.

No, this *is* the problem.Canek has posted some links in the other thread, 
some other guy, I have forgotten who it was, posted others. If interested read 
them. I really don't want to offend you, but unless you understand, how things 
work and what the problem is, don't waste your time looking at udev's sources.

Best,
Michael

Re: [gentoo-user] udev + /usr

[Alan Mackenzie]

On Mon, Sep 12, 2011 at 07:50:13PM +0200, Michael Schreckenbauer wrote:
> Hi Alan,

> On Monday, 12. September 2011 17:17:37 Alan Mackenzie wrote:
> > Hi, Michael.

> > On Mon, Sep 12, 2011 at 05:33:34PM +0200, Michael Schreckenbauer wrote:
> > > Hi Alan,

> > Well, I'm a hacker.  udev is free source, therefore fair game.  I don't
> > intend to put up with this nonsense without a fight.  As far as I can
> > make out, this is just one guy, Kay Sievers, who's on a power trip.  Are
> > there any indications at all that he actually talked to anybody in the
> > wide world before making such a far reaching decision?
> > On my current system, udev (164-r2) works without an earlily loaded /usr.
> > Seemingly, later versions don't.  That was why I was asking for somebody
> > to identify one of these later versions for me.

> it works for you, because your udev-rules need nothing from /usr/*
> It's *not* udev requiring /usr, it's the scripts triggered by the rules.

Ah.  OK.  Maybe I've misunderstood the whole thing.  Could it be that
there's no explicit requirement for early mounting of /usr, providing one
has the discipline to keep everything needed for booting in the /
partition?

> > > Fixing udev to continue working with separate /usr is far from trivial
> > > imo. Changing some paths is not the way to go for sure.

> > Maybe, maybe not.

> No, I wrote "for sure", because I *know* this.

Sorry about that.

> > > First of all, udev has to distinguish between "device not present" and
> > > "script error of some kind". Failing scripts have to be queued somehow
> > > for later execution. If a script keeps failing, it has to be removed
> > > from that queue, with a message to syslog or something like that. If
> > > udev needs a script in /usr/* to mount /usr then there's a
> > > chicken-egg-problem, which could be hard to solve (if possible at all
> > > without moving things from /usr/ to /). Note, that I am wild guessing
> > > here, I did not study the udev sources or any related script/rule :)

> Best,
> Michael

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: [gentoo-user] udev + /usr

[Michael Schreckenbauer]

Hi Alan,

On Tuesday, 13. September 2011 14:40:36 Alan Mackenzie wrote:
> On Mon, Sep 12, 2011 at 07:50:13PM +0200, Michael Schreckenbauer wrote:
> > Hi Alan,
> > 
> > On Monday, 12. September 2011 17:17:37 Alan Mackenzie wrote:
> > > Hi, Michael.
> > > 
> > > On Mon, Sep 12, 2011 at 05:33:34PM +0200, Michael Schreckenbauer wrote:
> > > > Hi Alan,
> > > 
> > > Well, I'm a hacker.  udev is free source, therefore fair game.  I
> > > don't
> > > intend to put up with this nonsense without a fight.  As far as I
> > > can
> > > make out, this is just one guy, Kay Sievers, who's on a power trip. 
> > > Are there any indications at all that he actually talked to anybody
> > > in the wide world before making such a far reaching decision?
> > > On my current system, udev (164-r2) works without an earlily loaded
> > > /usr. Seemingly, later versions don't.  That was why I was asking
> > > for somebody to identify one of these later versions for me.
> > 
> > it works for you, because your udev-rules need nothing from /usr/*
> > It's *not* udev requiring /usr, it's the scripts triggered by the rules.
> 
> Ah.  OK.  Maybe I've misunderstood the whole thing.  Could it be that
> there's no explicit requirement for early mounting of /usr, providing one
> has the discipline to keep everything needed for booting in the /
> partition?

I think so. But you will run an unsupported config afaict. Another point is, 
that baselayout might change, iff gentoo follows fedora. Afaik fedora wants 
/bin, /sbin and /lib to be symlinks to /usr/*  and keep them only for "legacy 
reasons".

> > > > Fixing udev to continue working with separate /usr is far from
> > > > trivial imo. Changing some paths is not the way to go for sure.
> > > 
> > > Maybe, maybe not.
> > 
> > No, I wrote "for sure", because I *know* this.
> 
> Sorry about that.

No problem. Sorry for the tone, too. Sounded ruder than it was meant.

Best,
Michael

Re: [gentoo-user] udev + /usr

[Alan Mackenzie]

Hi, Michael.

On Tue, Sep 13, 2011 at 04:55:15PM +0200, Michael Schreckenbauer wrote:
> Hi Alan,

> On Tuesday, 13. September 2011 14:40:36 Alan Mackenzie wrote:
> > On Mon, Sep 12, 2011 at 07:50:13PM +0200, Michael Schreckenbauer wrote:

> > Ah.  OK.  Maybe I've misunderstood the whole thing.  Could it be that
> > there's no explicit requirement for early mounting of /usr, providing one
> > has the discipline to keep everything needed for booting in the /
> > partition?

> I think so. But you will run an unsupported config afaict. Another point is, 
> that baselayout might change, iff gentoo follows fedora. Afaik fedora wants 
> /bin, /sbin and /lib to be symlinks to /usr/*  and keep them only for "legacy 
> reasons".

If the reaction of people in this mailing list is anything to go by,
Gentoo won't be following Fedora.

Yes, that one developer seems to want to empty /bin and /sbin.  He wants
to abolish single user mode.  Whether that's official policy at Fedora
remains to be seen.  Still, there's one program that can't be moved, and
that's /sbin/init.  :-)  (We'll see if the kernel hackers are willing to
make it a compile time option to use /usr/sbin/init instead.  I doubt it,
somehow.)

By the way are there any Gentoo documents which document the process of
creating an initramfs?

> Best,
> Michael

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: [gentoo-user] udev + /usr

[Canek Peláez Valdés]

On Tue, Sep 13, 2011 at 11:38 AM, Alan Mackenzie <acm@muc.de> wrote:
> Hi, Michael.
>
> On Tue, Sep 13, 2011 at 04:55:15PM +0200, Michael Schreckenbauer wrote:
>> Hi Alan,
>
>> On Tuesday, 13. September 2011 14:40:36 Alan Mackenzie wrote:
>> > On Mon, Sep 12, 2011 at 07:50:13PM +0200, Michael Schreckenbauer wrote:
>
>> > Ah.  OK.  Maybe I've misunderstood the whole thing.  Could it be that
>> > there's no explicit requirement for early mounting of /usr, providing one
>> > has the discipline to keep everything needed for booting in the /
>> > partition?
>
>> I think so. But you will run an unsupported config afaict. Another point is,
>> that baselayout might change, iff gentoo follows fedora. Afaik fedora wants
>> /bin, /sbin and /lib to be symlinks to /usr/*  and keep them only for "legacy
>> reasons".
>
> If the reaction of people in this mailing list is anything to go by,
> Gentoo won't be following Fedora.

http://article.gmane.org/gmane.linux.gentoo.devel/72730
http://article.gmane.org/gmane.linux.gentoo.devel/72736
http://article.gmane.org/gmane.linux.gentoo.devel/72739
http://article.gmane.org/gmane.linux.gentoo.devel/72748
http://article.gmane.org/gmane.linux.gentoo.devel/72750
http://article.gmane.org/gmane.linux.gentoo.devel/72751
http://article.gmane.org/gmane.linux.gentoo.devel/72752
http://article.gmane.org/gmane.linux.gentoo.devel/72760
http://article.gmane.org/gmane.linux.gentoo.devel/72761
http://article.gmane.org/gmane.linux.gentoo.devel/72768
http://article.gmane.org/gmane.linux.gentoo.devel/72769
http://article.gmane.org/gmane.linux.gentoo.devel/72775
http://article.gmane.org/gmane.linux.gentoo.devel/72783

I repeat that I pointed this thread since the beginning. We (the
users) can argue until our mouths are dry. The final decision (and the
only one that matters) is on the developer's hands.

Read the thread: there are objections to the inclusion of an initramfs
or the moving of /usr to /, but the discussion seems to have ended
with the conclusion that is better to follow the rest of the distros.
That's my reading: other may (and surely will) disagree.

But the devs thread is really really short (compared to the ones on
-user). I think that means that the ones that will actually write the
code will, you know, actually write code, and the change will in the
end happen. Probably when dracut seems  to be stable enough.

So, please, don't think that anything will be decided by how many
people object in -user. Because, in the first place, not all Gentoo
users are suscribed in gentoo-user, and of those suscribed, not
everyone writes. I didn't, for a really long time (and I have been
using Gentoo since 2003).

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

Re: [gentoo-user] udev + /usr

[Alan McKinnon]

On Tue, 13 Sep 2011 12:14:42 -0400
Canek Peláez Valdés <caneko@gmail.com> wrote:

> I repeat that I pointed this thread since the beginning. We (the
> users) can argue until our mouths are dry. The final decision (and the
> only one that matters) is on the developer's hands.

That is patently not true. It implies that there is *nothing* mere
users can do about it, that it is a done deal and we just have to live
with it.

Nothing could be further from the truth.

Have you never observed a person communicating to another and getting
them to change their mind?

-- 
Alan McKinnnon
alan.mckinnon@gmail.com

Re: [gentoo-user] udev + /usr

[Canek Peláez Valdés]

On Tue, Sep 13, 2011 at 4:35 PM, Alan McKinnon <alan.mckinnon@gmail.com> wrote:
> On Tue, 13 Sep 2011 12:14:42 -0400
> Canek Peláez Valdés <caneko@gmail.com> wrote:
>
>> I repeat that I pointed this thread since the beginning. We (the
>> users) can argue until our mouths are dry. The final decision (and the
>> only one that matters) is on the developer's hands.
>
> That is patently not true. It implies that there is *nothing* mere
> users can do about it, that it is a done deal and we just have to live
> with it.

That's not what I'm saying. I have explained this ad nauseum, I will
not go at it again.

> Nothing could be further from the truth.
>
> Have you never observed a person communicating to another and getting
> them to change their mind?

Of course I have. But then, why are you "communicating" this on -user?

It doesn't matter if you convince me of your POV, or if I change
yours. You need to change the mind of the people that will write the
code, either following the new changes pushed from upstream, or
implementing the support code for the stuff upstream will stop
supporting.

I find the dicussions here usually interesting, but this list is
basically for helping us each other, and to discuss general topics
related to Gentoo stuff. It is not to decide the direction of the
distribution.

Want to change the direction of the distro? You know what needs to be done.

And for sure is not discussing it in -user.

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

Re: [gentoo-user] udev + /usr

[Michael Mol]

On Tue, Sep 13, 2011 at 4:52 PM, Canek Peláez Valdés <caneko@gmail.com> wrote:
> Want to change the direction of the distro? You know what needs to be done.

Be more specific. It sounds like there are a lot of people in here who
want to change the direction of the distro.

Is it simply subscribing to -dev and voicing the conversation there?

-- 
:wq

Re: [gentoo-user] udev + /usr

[Canek Peláez Valdés]

On Tue, Sep 13, 2011 at 4:57 PM, Michael Mol <mikemol@gmail.com> wrote:
> On Tue, Sep 13, 2011 at 4:52 PM, Canek Peláez Valdés <caneko@gmail.com> wrote:
>> Want to change the direction of the distro? You know what needs to be done.
>
> Be more specific. It sounds like there are a lot of people in here who
> want to change the direction of the distro.

Sorry: I said it a lot of times before in the other thread, so I
thought it was clear.

> Is it simply subscribing to -dev and voicing the conversation there?

Of course not. But please, do that if you think it will help to steer
Gentoo to whatever direction do you think is the correct one.
Personaly I don't think the devs (who, AFAIK, do not receive a single
dime for working on Gentoo) will appreciate anybody telling them how
they should do their jobs, the one they do for free. But that's just
me.

No, by "you know what needs to be done" I mean: code. Contribute.
Become a developer. Make shit happens the way you think it should
happen.

Shut up and code. Google it, I didn't come with the phrase.

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

Re: [gentoo-user] udev + /usr

[Michael Schreckenbauer]

On Tuesday, 13. September 2011 17:10:40 Canek Peláez Valdés wrote:
> On Tue, Sep 13, 2011 at 4:57 PM, Michael Mol <mikemol@gmail.com> wrote:
> > On Tue, Sep 13, 2011 at 4:52 PM, Canek Peláez Valdés <caneko@gmail.com> 
wrote:
> >> Want to change the direction of the distro? You know what needs to be
> >> done.> 
> > Be more specific. It sounds like there are a lot of people in here who
> > want to change the direction of the distro.
> 
> Sorry: I said it a lot of times before in the other thread, so I
> thought it was clear.
> 
> > Is it simply subscribing to -dev and voicing the conversation there?
> 
> Of course not. But please, do that if you think it will help to steer
> Gentoo to whatever direction do you think is the correct one.
> Personaly I don't think the devs (who, AFAIK, do not receive a single
> dime for working on Gentoo) will appreciate anybody telling them how
> they should do their jobs, the one they do for free. But that's just
> me.

As you well know, not all of "our" devs are in favour of this idea.
To quote one of them (vapier)

"brain dead behavior in other packages has no bearing on openrc.  openrc will 
never require crap like initramfs simply to boot.
-mike"

And in a later mail:

"...if there is something in openrc that doesnt 
work with a split /usr or /var, then file a bug because it is a bug..."

> No, by "you know what needs to be done" I mean: code. Contribute.
> Become a developer. Make shit happens the way you think it should
> happen.
> Shut up and code. Google it, I didn't come with the phrase.

There are already devs on "our" side. Fortunatly one of them maintains openrc 
:)

> Regards.

Regards,
Michael

Re: [gentoo-user] udev + /usr

[Canek Peláez Valdés]

On Tue, Sep 13, 2011 at 5:30 PM, Michael Schreckenbauer <grimlog@gmx.de> wrote:
> On Tuesday, 13. September 2011 17:10:40 Canek Peláez Valdés wrote:
>> On Tue, Sep 13, 2011 at 4:57 PM, Michael Mol <mikemol@gmail.com> wrote:
>> > On Tue, Sep 13, 2011 at 4:52 PM, Canek Peláez Valdés <caneko@gmail.com>
> wrote:
>> >> Want to change the direction of the distro? You know what needs to be
>> >> done.>
>> > Be more specific. It sounds like there are a lot of people in here who
>> > want to change the direction of the distro.
>>
>> Sorry: I said it a lot of times before in the other thread, so I
>> thought it was clear.
>>
>> > Is it simply subscribing to -dev and voicing the conversation there?
>>
>> Of course not. But please, do that if you think it will help to steer
>> Gentoo to whatever direction do you think is the correct one.
>> Personaly I don't think the devs (who, AFAIK, do not receive a single
>> dime for working on Gentoo) will appreciate anybody telling them how
>> they should do their jobs, the one they do for free. But that's just
>> me.
>
> As you well know, not all of "our" devs are in favour of this idea.
> To quote one of them (vapier)
>
> "brain dead behavior in other packages has no bearing on openrc.  openrc will
> never require crap like initramfs simply to boot.
> -mike"
>
> And in a later mail:
>
> "...if there is something in openrc that doesnt
> work with a split /usr or /var, then file a bug because it is a bug..."
>
>> No, by "you know what needs to be done" I mean: code. Contribute.
>> Become a developer. Make shit happens the way you think it should
>> happen.
>> Shut up and code. Google it, I didn't come with the phrase.
>
> There are already devs on "our" side. Fortunatly one of them maintains openrc
> :)

I really don't see them as "sides". "We" are not at "war". And if
OpenRC is capable of booting without needing an initramfs, I really,
truly believe that is *GREAT*. But

a) It doesn't stop OpenRC to actually use an initramfs
b) Doesn't mean every other part of the stack will keep working
without an initramfs *AND* with a separated /usr.
c) Doesn't mean there are enough developers to keep supporting the
things upstream stop supporting.

Again, it all comes down to whoever writes the code. If Vapier wants
to support OpenRC for systems without initramfs and a separated /usr,
that's amazing and we should all said thanks to him and the other devs
for the extra effort. But it *WILL* be extra effort for him the moment
more upstreams choose to assume that either /usr is in /, or that the
system boots with an initramfs.

We can thank Vapier, but we cannot *demand* of him to support whatever
we want. Nor to any other dev.

So,if you *TRULY* believe that Gentoo should forever and ever support
any setup it has supported up until now, better start coding. Because
otherwise you can never be sure somebody else will do it for you.

And maybe I shouldn't even mention it, but I don't use OpenRC. I use
systemd. And it works great on Gentoo.

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

Re: [gentoo-user] udev + /usr

[Michael Schreckenbauer]

On Tuesday, 13. September 2011 17:53:04 Canek Peláez Valdés wrote:
> On Tue, Sep 13, 2011 at 5:30 PM, Michael Schreckenbauer <grimlog@gmx.de> 
wrote:
> > There are already devs on "our" side. Fortunatly one of them maintains
> > openrc> 
> > :)
> 
> I really don't see them as "sides". "We" are not at "war".

:)

> And if
> OpenRC is capable of booting without needing an initramfs, I really,
> truly believe that is *GREAT*. But
> 
> a) It doesn't stop OpenRC to actually use an initramfs
> b) Doesn't mean every other part of the stack will keep working
> without an initramfs *AND* with a separated /usr.
> c) Doesn't mean there are enough developers to keep supporting the
> things upstream stop supporting.
> 
> Again, it all comes down to whoever writes the code. If Vapier wants
> to support OpenRC for systems without initramfs and a separated /usr,
> that's amazing and we should all said thanks to him and the other devs
> for the extra effort. But it *WILL* be extra effort for him the moment
> more upstreams choose to assume that either /usr is in /, or that the
> system boots with an initramfs.
> 
> We can thank Vapier, but we cannot *demand* of him to support whatever
> we want. Nor to any other dev.

I do not demand anything from any developer (unless I pay him).
 
> So,if you *TRULY* believe that Gentoo should forever and ever support
> any setup it has supported up until now, better start coding. Because
> otherwise you can never be sure somebody else will do it for you.

Not that it has some value for this discussion, but I *do* code. It's just not 
udev, openrc or as a gentoo-dev.
If gentoo follows fedora on this mandatory initramfs trail, I'll switch to 
FreeBSD completely. My software works on way more systems than just "Linux".

> And maybe I shouldn't even mention it, but I don't use OpenRC. I use
> systemd. And it works great on Gentoo.

Well. Linux only. If I wanted a monoculture, I would use MS-Windows or OSX.

> Regards.

Regards,
Michael

Re: [gentoo-user] udev + /usr

[Canek Peláez Valdés]

On Tue, Sep 13, 2011 at 6:10 PM, Michael Schreckenbauer <grimlog@gmx.de> wrote:
> On Tuesday, 13. September 2011 17:53:04 Canek Peláez Valdés wrote:
>> On Tue, Sep 13, 2011 at 5:30 PM, Michael Schreckenbauer <grimlog@gmx.de>
> wrote:
>> > There are already devs on "our" side. Fortunatly one of them maintains
>> > openrc>
>> > :)
>>
>> I really don't see them as "sides". "We" are not at "war".
>
> :)
>
>> And if
>> OpenRC is capable of booting without needing an initramfs, I really,
>> truly believe that is *GREAT*. But
>>
>> a) It doesn't stop OpenRC to actually use an initramfs
>> b) Doesn't mean every other part of the stack will keep working
>> without an initramfs *AND* with a separated /usr.
>> c) Doesn't mean there are enough developers to keep supporting the
>> things upstream stop supporting.
>>
>> Again, it all comes down to whoever writes the code. If Vapier wants
>> to support OpenRC for systems without initramfs and a separated /usr,
>> that's amazing and we should all said thanks to him and the other devs
>> for the extra effort. But it *WILL* be extra effort for him the moment
>> more upstreams choose to assume that either /usr is in /, or that the
>> system boots with an initramfs.
>>
>> We can thank Vapier, but we cannot *demand* of him to support whatever
>> we want. Nor to any other dev.
>
> I do not demand anything from any developer (unless I pay him).
>
>> So,if you *TRULY* believe that Gentoo should forever and ever support
>> any setup it has supported up until now, better start coding. Because
>> otherwise you can never be sure somebody else will do it for you.
>
> Not that it has some value for this discussion, but I *do* code. It's just not
> udev, openrc or as a gentoo-dev.

Me too. That's why I put so much value on the people that writes the code.

> If gentoo follows fedora on this mandatory initramfs trail, I'll switch to
> FreeBSD completely. My software works on way more systems than just "Linux".

That's of course your prerogative. And, as I said before: "Linux
strives to be much more than Unix, and that means do things
differently." If you want to do things the same way that it was done
in the last 20 years, maybe Linux is not the best of choices.

I myself think the new technologies are worth to change the way we did
things before. But that's just me.

>> And maybe I shouldn't even mention it, but I don't use OpenRC. I use
>> systemd. And it works great on Gentoo.
>
> Well. Linux only. If I wanted a monoculture, I would use MS-Windows or OSX.

Relax man. I mention what I use: I'm not forcing you (or anybody else)
to use it. But I repeat (because I said it before) that I care about
Linux, and Linux only.

But that's just me.

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

Re: [gentoo-user] udev + /usr

[Joost Roeleveld]

On Tuesday, September 13, 2011 06:33:01 PM Canek Peláez Valdés wrote:
> On Tue, Sep 13, 2011 at 6:10 PM, Michael Schreckenbauer <grimlog@gmx.de> 
wrote:
> > If gentoo follows fedora on this mandatory initramfs trail, I'll switch
> > to FreeBSD completely. My software works on way more systems than just
> > "Linux".
> That's of course your prerogative. And, as I said before: "Linux
> strives to be much more than Unix, and that means do things
> differently." If you want to do things the same way that it was done
> in the last 20 years, maybe Linux is not the best of choices.

I read it before, but to be much more then Unix, Linux should be doing things 
better. Being different is what led to MS Windows'

> I myself think the new technologies are worth to change the way we did
> things before. But that's just me.

The new technologies have great merit. But, the implementation of it isn't 
thought through.

> >> And maybe I shouldn't even mention it, but I don't use OpenRC. I use
> >> systemd. And it works great on Gentoo.
> > 
> > Well. Linux only. If I wanted a monoculture, I would use MS-Windows or
> > OSX.
> Relax man. I mention what I use: I'm not forcing you (or anybody else)
> to use it. But I repeat (because I said it before) that I care about
> Linux, and Linux only.

If you care about Linux, why do you allow it to be broken in such a 
fundamental way?

--
Joost

Re: [gentoo-user] udev + /usr

[Canek Peláez Valdés]

On Wed, Sep 14, 2011 at 1:52 AM, Joost Roeleveld <joost@antarean.org> wrote:
> On Tuesday, September 13, 2011 06:33:01 PM Canek Peláez Valdés wrote:
>> On Tue, Sep 13, 2011 at 6:10 PM, Michael Schreckenbauer <grimlog@gmx.de>
> wrote:
>> > If gentoo follows fedora on this mandatory initramfs trail, I'll switch
>> > to FreeBSD completely. My software works on way more systems than just
>> > "Linux".
>> That's of course your prerogative. And, as I said before: "Linux
>> strives to be much more than Unix, and that means do things
>> differently." If you want to do things the same way that it was done
>> in the last 20 years, maybe Linux is not the best of choices.
>
> I read it before, but to be much more then Unix, Linux should be doing things
> better. Being different is what led to MS Windows'

But that's the thing: we (you and me) don't see the situation the same
way. To me, the proposed changes are for the better.

>> I myself think the new technologies are worth to change the way we did
>> things before. But that's just me.
>
> The new technologies have great merit. But, the implementation of it isn't
> thought through.

In my humble opinion, what you just said is a little pedantic. You can
disagree with the proposed changes, you can argue why you think
another approach could be better. But just saying "the implementation
of it isn't  thought through", is a little insulting to the devs. I
think they though about the implementation a lot.

>> >> And maybe I shouldn't even mention it, but I don't use OpenRC. I use
>> >> systemd. And it works great on Gentoo.
>> >
>> > Well. Linux only. If I wanted a monoculture, I would use MS-Windows or
>> > OSX.
>> Relax man. I mention what I use: I'm not forcing you (or anybody else)
>> to use it. But I repeat (because I said it before) that I care about
>> Linux, and Linux only.
>
> If you care about Linux, why do you allow it to be broken in such a
> fundamental way?

Again, to me is not "breaking it". To me is "improving it".

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

Re: [gentoo-user] udev + /usr

[Dale]

Canek Peláez Valdés wrote:
> On Wed, Sep 14, 2011 at 1:52 AM, Joost Roeleveld<joost@antarean.org>  wrote:
>> On Tuesday, September 13, 2011 06:33:01 PM Canek Peláez Valdés wrote:
>>> On Tue, Sep 13, 2011 at 6:10 PM, Michael Schreckenbauer<grimlog@gmx.de>
>> wrote:
>>>> If gentoo follows fedora on this mandatory initramfs trail, I'll switch
>>>> to FreeBSD completely. My software works on way more systems than just
>>>> "Linux".
>>> That's of course your prerogative. And, as I said before: "Linux
>>> strives to be much more than Unix, and that means do things
>>> differently." If you want to do things the same way that it was done
>>> in the last 20 years, maybe Linux is not the best of choices.
>> I read it before, but to be much more then Unix, Linux should be doing things
>> better. Being different is what led to MS Windows'
> But that's the thing: we (you and me) don't see the situation the same
> way. To me, the proposed changes are for the better.

You are one of very few that feel this way.

>
>>> I myself think the new technologies are worth to change the way we did
>>> things before. But that's just me.
>> The new technologies have great merit. But, the implementation of it isn't
>> thought through.
> In my humble opinion, what you just said is a little pedantic. You can
> disagree with the proposed changes, you can argue why you think
> another approach could be better. But just saying "the implementation
> of it isn't  thought through", is a little insulting to the devs. I
> think they though about the implementation a lot.

The dev only thought about himself and the distro he uses.  He 
apparently didn't consider how what he is doing is going to affect 
others or he would have done something better.  People have already 
explained what should be done so there is a better way to do this 
without breaking things.


>
>>>>> And maybe I shouldn't even mention it, but I don't use OpenRC. I use
>>>>> systemd. And it works great on Gentoo.
>>>> Well. Linux only. If I wanted a monoculture, I would use MS-Windows or
>>>> OSX.
>>> Relax man. I mention what I use: I'm not forcing you (or anybody else)
>>> to use it. But I repeat (because I said it before) that I care about
>>> Linux, and Linux only.
>> If you care about Linux, why do you allow it to be broken in such a
>> fundamental way?
> Again, to me is not "breaking it". To me is "improving it".
>
> Regards.

It is breaking it.  Why you can't see that is beyond me.  It has already 
been said what is supposed to be required for booting and /usr and 
possibly /var is not on the list.

Dale

:-)  :-)

Re: [gentoo-user] udev + /usr

[Canek Peláez Valdés]

On Wed, Sep 14, 2011 at 2:36 PM, Dale <rdalek1967@gmail.com> wrote:
> Canek Peláez Valdés wrote:
>>
>> On Wed, Sep 14, 2011 at 1:52 AM, Joost Roeleveld<joost@antarean.org>
>>  wrote:
>>>
>>> On Tuesday, September 13, 2011 06:33:01 PM Canek Peláez Valdés wrote:
>>>>
>>>> On Tue, Sep 13, 2011 at 6:10 PM, Michael Schreckenbauer<grimlog@gmx.de>
>>>
>>> wrote:
>>>>>
>>>>> If gentoo follows fedora on this mandatory initramfs trail, I'll switch
>>>>> to FreeBSD completely. My software works on way more systems than just
>>>>> "Linux".
>>>>
>>>> That's of course your prerogative. And, as I said before: "Linux
>>>> strives to be much more than Unix, and that means do things
>>>> differently." If you want to do things the same way that it was done
>>>> in the last 20 years, maybe Linux is not the best of choices.
>>>
>>> I read it before, but to be much more then Unix, Linux should be doing
>>> things
>>> better. Being different is what led to MS Windows'
>>
>> But that's the thing: we (you and me) don't see the situation the same
>> way. To me, the proposed changes are for the better.
>
> You are one of very few that feel this way.

Who actually speaks on the list. As far as we know, maybe the only
Gentoo users disagreeing with the changes are the ones saying so on
the list. We don't know.

>>>> I myself think the new technologies are worth to change the way we did
>>>> things before. But that's just me.
>>>
>>> The new technologies have great merit. But, the implementation of it
>>> isn't
>>> thought through.
>>
>> In my humble opinion, what you just said is a little pedantic. You can
>> disagree with the proposed changes, you can argue why you think
>> another approach could be better. But just saying "the implementation
>> of it isn't  thought through", is a little insulting to the devs. I
>> think they though about the implementation a lot.
>
> The dev only thought about himself and the distro he uses.

That's one of the many things you don't get, Dale. It's not one dev.
It's not one distro. And that's the principal reason why I thing the
change willl indeed happen.

> He apparently
> didn't consider how what he is doing is going to affect others or he would
> have done something better.  People have already explained what should be
> done so there is a better way to do this without breaking things.

That people say things you agree with, doesn't necessarily means they
are right. Like Sebastian said, the thread goes in circles, so I will
not repeat my reasons for not agreeing: but be assured that many
people don't agree with your reasoning, and that several Gentoo devs
agree with the change. And they are working as we speak to implement
it.

Other devs do not agree, but again, code talks. At the end of the day,
the ones writing the code will have their way.

>>>>>> And maybe I shouldn't even mention it, but I don't use OpenRC. I use
>>>>>> systemd. And it works great on Gentoo.
>>>>>
>>>>> Well. Linux only. If I wanted a monoculture, I would use MS-Windows or
>>>>> OSX.
>>>>
>>>> Relax man. I mention what I use: I'm not forcing you (or anybody else)
>>>> to use it. But I repeat (because I said it before) that I care about
>>>> Linux, and Linux only.
>>>
>>> If you care about Linux, why do you allow it to be broken in such a
>>> fundamental way?
>>
>> Again, to me is not "breaking it". To me is "improving it".
>>
>> Regards.
>
> It is breaking it.  Why you can't see that is beyond me.

Because, thanks to evolution, people have the ability (and liberty) to
think differently.

> It has already
> been said what is supposed to be required for booting and /usr and possibly
> /var is not on the list.

I have heard many ideas of "what is supposed to be required" for many
things. I haven't heard of anyone willing to implement most of those
great ideas. I have only heard from the Gentoo devs working in
following upstreams, and from the devs in said upstreams.

As long as nobody is willing to implement it (and maintain it, and
debug it, and support it), no "solution" is worth the bits used to
express it.

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

Re: [gentoo-user] udev + /usr

[William Kenworthy]

On Wed, 2011-09-14 at 14:55 -0400, Canek Peláez Valdés wrote:
> On Wed, Sep 14, 2011 at 2:36 PM, Dale <rdalek1967@gmail.com> wrote:
> > Canek Peláez Valdés wrote:
> >>
> >> On Wed, Sep 14, 2011 at 1:52 AM, Joost Roeleveld<joost@antarean.org>
> >>  wrote:
> >>>
> >>> On Tuesday, September 13, 2011 06:33:01 PM Canek Peláez Valdés wrote:
> >>>>
> >>>> On Tue, Sep 13, 2011 at 6:10 PM, Michael Schreckenbauer<grimlog@gmx.de>
> >>>
> >>> wrote:
...
> 
> Who actually speaks on the list. As far as we know, maybe the only
> Gentoo users disagreeing with the changes are the ones saying so on
> the list. We don't know.
> 
...


ok, as one of the silent ones on this topic so far, I'll chime in.

Dont assume that the silent majority are in favour - they just might be
on the other side.  Perhaps others who disagree can say "me too" in
order to support Dale who has been carrying the argument very well.

From my point of view, its looking like I will have to redesign a number
of systems to take this into a/c, expose those systems to a proven
higher risk of failure* all because of some corner cases that dont apply
to me or the majority and perhaps the biggest point is that I have no
choice in the matter, and possibly no choice about when it will happen.

I wonder if going back to a static /dev is still possible.  Server
hardware doesnt change much once in service so its a once only hit to
set it up.

I dont mind that you want to use systemd and an initramfs - but I dont,
and I dont want to be forced to go along with you.

BillK

* my biggest failure when doing sys admin tasks at a workplace involved
initrd's - now I do not use them on gentoo (I dont have a choice on the
ubuntu systems), and guess what ... Ive never had an initrd failure on
gentoo since :)  I know initramfs isnt initrd, but the exposure is the
same.

Re: [gentoo-user] udev + /usr

[Dale]

William Kenworthy wrote:
> On Wed, 2011-09-14 at 14:55 -0400, Canek Peláez Valdés wrote:
>> Who actually speaks on the list. As far as we know, maybe the only
>> Gentoo users disagreeing with the changes are the ones saying so on
>> the list. We don't know.
>>
> ok, as one of the silent ones on this topic so far, I'll chime in.
>
> Dont assume that the silent majority are in favour - they just might be
> on the other side.  Perhaps others who disagree can say "me too" in
> order to support Dale who has been carrying the argument very well.
>
> > From my point of view, its looking like I will have to redesign a number
> of systems to take this into a/c, expose those systems to a proven
> higher risk of failure* all because of some corner cases that dont apply
> to me or the majority and perhaps the biggest point is that I have no
> choice in the matter, and possibly no choice about when it will happen.
>
> I wonder if going back to a static /dev is still possible.  Server
> hardware doesnt change much once in service so its a once only hit to
> set it up.
>
> I dont mind that you want to use systemd and an initramfs - but I dont,
> and I dont want to be forced to go along with you.
>
> BillK
>
> * my biggest failure when doing sys admin tasks at a workplace involved
> initrd's - now I do not use them on gentoo (I dont have a choice on the
> ubuntu systems), and guess what ... Ive never had an initrd failure on
> gentoo since :)  I know initramfs isnt initrd, but the exposure is the
> same.
>

The init system was one reason I left Mandriva too.  To have to go back 
to using one just makes me wonder if I should have stuck with it and all 
the headaches.  I really like Gentoo but it is going in the direction of 
being like all the rest with the addition of compiling everything.

What will be next I wonder.

Dale

:-)  :-)

Re: [gentoo-user] udev + /usr

[Mike Edenfield]

On Wednesday, September 14, 2011 01:36:56 PM Dale wrote:
> Canek Peláez Valdés wrote:

> > But that's the thing: we (you and me) don't see the situation the same
> > way. To me, the proposed changes are for the better.
> 
> You are one of very few that feel this way.

You are probably correct that he's one of the relatively few people (along 
with the udev developer, and those few people for whom it will fix their 
problems) who think these changes are a real improvement.

I would estimate that the vast, vast, vast majority of users are those such as 
myslelf, who have no opinion whatsoever, and either will not be affected at all 
by these changes (because they don't separate / and /usr), or will simply 
apply the proposed initramfs solution and move on.

Then there are those relatively few people, such as the handful making up the 
rest of this thread, who think that these changes are a horrible idea and will 
have a severe deterimental affect on their systems.

Not that the relative "size" of the various sides in this debate is really the 
issue, but despite the tone of this and the other thread, I don't think 
there's really a huge, overwhelming outcry against these changes.

--Mike

Re: [gentoo-user] udev + /usr

[Michael Mol]

On Thu, Sep 15, 2011 at 4:42 PM, Mike Edenfield <kutulu@kutulu.org> wrote:
> On Wednesday, September 14, 2011 01:36:56 PM Dale wrote:
>> Canek Peláez Valdés wrote:
>
>> > But that's the thing: we (you and me) don't see the situation the same
>> > way. To me, the proposed changes are for the better.
>>
>> You are one of very few that feel this way.
>
> You are probably correct that he's one of the relatively few people (along
> with the udev developer, and those few people for whom it will fix their
> problems) who think these changes are a real improvement.
>
> I would estimate that the vast, vast, vast majority of users are those such as
> myslelf, who have no opinion whatsoever, and either will not be affected at all
> by these changes (because they don't separate / and /usr), or will simply
> apply the proposed initramfs solution and move on.
>
> Then there are those relatively few people, such as the handful making up the
> rest of this thread, who think that these changes are a horrible idea and will
> have a severe deterimental affect on their systems.
>
> Not that the relative "size" of the various sides in this debate is really the
> issue, but despite the tone of this and the other thread, I don't think
> there's really a huge, overwhelming outcry against these changes.

My complaints are chiefly philosophical; it's not a correct solution,
because the problems it purports to fix will just re-emerge down the
road. I'm all in favor of well-architected systems and good, sound,
informed discussion. I've only been involved in this thread as much as
I have been because there's been a dearth of such in it.

-- 
:wq

Re: [gentoo-user] udev + /usr

[Joost Roeleveld]

On Thursday, September 15, 2011 04:42:23 PM Mike Edenfield wrote:
> On Wednesday, September 14, 2011 01:36:56 PM Dale wrote:
> > Canek Peláez Valdés wrote:
> > > But that's the thing: we (you and me) don't see the situation the
> > > same
> > > way. To me, the proposed changes are for the better.
> > 
> > You are one of very few that feel this way.
> 
> You are probably correct that he's one of the relatively few people (along
> with the udev developer, and those few people for whom it will fix their
> problems) who think these changes are a real improvement.

If for those people using an initramfs solves their problems, then I'm not 
against it. And I don't think many others are either.
But why are people forced to use an initramfs where it is not needed?

> I would estimate that the vast, vast, vast majority of users are those such
> as myslelf, who have no opinion whatsoever, and either will not be affected
> at all by these changes (because they don't separate / and /usr), or will
> simply apply the proposed initramfs solution and move on.

You also don't have /var (or /var/log) seperated? Or any of the other parts of 
the filesystem that might be required by udev-rules?

> Then there are those relatively few people, such as the handful making up
> the rest of this thread, who think that these changes are a horrible idea
> and will have a severe deterimental affect on their systems.

Any added complexity is another thing that can go wrong.
In the thread on gentoo-dev, I am trying to figure out 3 things:
1) How are the Gentoo Developers planning on adding this new change?
2) What are the options for not having to have an initramfs if the udev-rules 
used don't actually require /usr and co to be mounted.
3) Get their input in a possible alternative (like fixing the, what I see, 
design-flaws of udev)

On "1", I am actually quite pleased. The actual information I could find 
previously sounded a lot worse. I've just got a few more questions open based 
on their answers. Once I have the full picture, I'll post it back here.

For "2", I've only just started. I'll also post back here on what my findings 
are.

For "3", I've got some feedback on how udev currently handles things. These 
actually have given me a few other ways in which to try to "solve" the issue. 
I'll need to try to find out how udev actually handles the "retry" queue 
currently.

> Not that the relative "size" of the various sides in this debate is really
> the issue, but despite the tone of this and the other thread, I don't think
> there's really a huge, overwhelming outcry against these changes.

I wonder how many are actually aware of these changes. But yes, I think plenty 
of people will not care and if the Gentoo-devs handle this correctly (which, 
so far, I think they are) those people won't even notice.

But, there will always be some people who get bitten by this and my reasons 
for going with parts 1 and 2 is to see how to keep this group as small as 
possible.

--
Joost

Re: [gentoo-user] udev + /usr

[Canek Peláez Valdés]

On Thu, Sep 15, 2011 at 5:16 PM, Joost Roeleveld <joost@antarean.org> wrote:
> On Thursday, September 15, 2011 04:42:23 PM Mike Edenfield wrote:
>> On Wednesday, September 14, 2011 01:36:56 PM Dale wrote:
>> > Canek Peláez Valdés wrote:
>> > > But that's the thing: we (you and me) don't see the situation the
>> > > same
>> > > way. To me, the proposed changes are for the better.
>> >
>> > You are one of very few that feel this way.
>>
>> You are probably correct that he's one of the relatively few people (along
>> with the udev developer, and those few people for whom it will fix their
>> problems) who think these changes are a real improvement.
>
> If for those people using an initramfs solves their problems, then I'm not
> against it. And I don't think many others are either.
> But why are people forced to use an initramfs where it is not needed?

<bad_joke>Well, technically it's not "forced"... if you put /usr in /
then you don't need it...</bad_joke>

The thing is that the initramfs solution solves the general problem
(as the devs keep trying to explain in -dev). You may not *want* to
use an initramfs, but it *will* solve the problem.

The devs *could* make up an alternative for an initramfs for those
people who fell they don't need one, but then they (not us) need to
maintain it, test it, document it, etc. It is not worth it if the
initramfs works for everyone... even for those who don't want it.

>> I would estimate that the vast, vast, vast majority of users are those such
>> as myslelf, who have no opinion whatsoever, and either will not be affected
>> at all by these changes (because they don't separate / and /usr), or will
>> simply apply the proposed initramfs solution and move on.
>
> You also don't have /var (or /var/log) seperated? Or any of the other parts of
> the filesystem that might be required by udev-rules?

Many laptop users don't split /, among other things because the free
space gets fragmented. Also, some people keep Windows (and their
recovery partitions), and with a swap they got already used the four
extended partition, and some people don't like logical partitions. And
it's really the same as not wanting an initramfs.

>> Then there are those relatively few people, such as the handful making up
>> the rest of this thread, who think that these changes are a horrible idea
>> and will have a severe deterimental affect on their systems.
>
> Any added complexity is another thing that can go wrong.

Take that to the limit and then we will still be using only the terminal (no X).

> In the thread on gentoo-dev, I am trying to figure out 3 things:
> 1) How are the Gentoo Developers planning on adding this new change?
> 2) What are the options for not having to have an initramfs if the udev-rules
> used don't actually require /usr and co to be mounted.
> 3) Get their input in a possible alternative (like fixing the, what I see,
> design-flaws of udev)
>
> On "1", I am actually quite pleased. The actual information I could find
> previously sounded a lot worse. I've just got a few more questions open based
> on their answers. Once I have the full picture, I'll post it back here.
>
> For "2", I've only just started. I'll also post back here on what my findings
> are.
>
> For "3", I've got some feedback on how udev currently handles things. These
> actually have given me a few other ways in which to try to "solve" the issue.
> I'll need to try to find out how udev actually handles the "retry" queue
> currently.

I also think the discussion in -dev is really good, and I think is
cleaning the air abot many issues.

>> Not that the relative "size" of the various sides in this debate is really
>> the issue, but despite the tone of this and the other thread, I don't think
>> there's really a huge, overwhelming outcry against these changes.
>
> I wonder how many are actually aware of these changes. But yes, I think plenty
> of people will not care and if the Gentoo-devs handle this correctly (which,
> so far, I think they are) those people won't even notice.

Concur.

> But, there will always be some people who get bitten by this and my reasons
> for going with parts 1 and 2 is to see how to keep this group as small as
> possible.

I think most of the Gentoo users, if able to survive the installation,
are able to deal with almost anything.

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

Re: [gentoo-user] udev + /usr

[Mike Edenfield]

On Thursday, September 15, 2011 11:16:03 PM Joost Roeleveld wrote:
> On Thursday, September 15, 2011 04:42:23 PM Mike Edenfield wrote:

> > I would estimate that the vast, vast, vast majority of users are those
> > such as myslelf, who have no opinion whatsoever, and either will not be
> > affected at all by these changes (because they don't separate / and
> > /usr), or will simply apply the proposed initramfs solution and move
> > on.
> 
> You also don't have /var (or /var/log) seperated? Or any of the other parts
> of the filesystem that might be required by udev-rules?

Speaking solely for myself, no. Years ago I routinely split /, /usr, and /var 
when setting up my FreeBSD systems, and found that it only ever caused 
problems when I could not get /usr or /var mounted when I needed them.

At least since I switched to Gentoo, I've simply set up one partition with 
everything on it, and kept regular backups in case of failure. 

I clearly recognize that there are valid reasons to split your partitions, I 
have just never found any of them applicable to my situations.

--Mike

Re: [gentoo-user] udev + /usr

[Mark Knecht]

On Thu, Sep 15, 2011 at 3:05 PM, Mike Edenfield <kutulu@kutulu.org> wrote:
> On Thursday, September 15, 2011 11:16:03 PM Joost Roeleveld wrote:
>> On Thursday, September 15, 2011 04:42:23 PM Mike Edenfield wrote:
>
>> > I would estimate that the vast, vast, vast majority of users are those
>> > such as myslelf, who have no opinion whatsoever, and either will not be
>> > affected at all by these changes (because they don't separate / and
>> > /usr), or will simply apply the proposed initramfs solution and move
>> > on.
>>
>> You also don't have /var (or /var/log) seperated? Or any of the other parts
>> of the filesystem that might be required by udev-rules?
>
> Speaking solely for myself, no. Years ago I routinely split /, /usr, and /var
> when setting up my FreeBSD systems, and found that it only ever caused
> problems when I could not get /usr or /var mounted when I needed them.
>
> At least since I switched to Gentoo, I've simply set up one partition with
> everything on it, and kept regular backups in case of failure.
>
> I clearly recognize that there are valid reasons to split your partitions, I
> have just never found any of them applicable to my situations.
>
> --Mike

My first response to this 300+ post thread, and only to say that in
something like 15 years of playing with & using Linux I've never split
/usr & no longer split /var. I also don't use LVM or anything fancy
like that. I just keep backups and use them if there's a failure. Life
is pretty simple.

My suspicion is that by far most casual desktop users of Linux, Gentoo
based or not, run pretty much this way and will be unaffected by this
whole change and as such have no reason to post.

As for the initrd stuff, I'd welcome a way to have one built
automatically as part of the kernel build/install. My experience with
software RAID has been such that I often cannot get a new RAID to boot
without it so having one that's up to date and 'just there' (@tm)
would be fairly cool from my POV.

My only & last post on this thread.

Cheers,
Mark

Re: [gentoo-user] udev + /usr

[Canek Peláez Valdés]

On Thu, Sep 15, 2011 at 6:26 PM, Mark Knecht <markknecht@gmail.com> wrote:
> On Thu, Sep 15, 2011 at 3:05 PM, Mike Edenfield <kutulu@kutulu.org> wrote:
>> On Thursday, September 15, 2011 11:16:03 PM Joost Roeleveld wrote:
>>> On Thursday, September 15, 2011 04:42:23 PM Mike Edenfield wrote:
>>
>>> > I would estimate that the vast, vast, vast majority of users are those
>>> > such as myslelf, who have no opinion whatsoever, and either will not be
>>> > affected at all by these changes (because they don't separate / and
>>> > /usr), or will simply apply the proposed initramfs solution and move
>>> > on.
>>>
>>> You also don't have /var (or /var/log) seperated? Or any of the other parts
>>> of the filesystem that might be required by udev-rules?
>>
>> Speaking solely for myself, no. Years ago I routinely split /, /usr, and /var
>> when setting up my FreeBSD systems, and found that it only ever caused
>> problems when I could not get /usr or /var mounted when I needed them.
>>
>> At least since I switched to Gentoo, I've simply set up one partition with
>> everything on it, and kept regular backups in case of failure.
>>
>> I clearly recognize that there are valid reasons to split your partitions, I
>> have just never found any of them applicable to my situations.
>>
>> --Mike
>
> My first response to this 300+ post thread, and only to say that in
> something like 15 years of playing with & using Linux I've never split
> /usr & no longer split /var. I also don't use LVM or anything fancy
> like that. I just keep backups and use them if there's a failure. Life
> is pretty simple.
>
> My suspicion is that by far most casual desktop users of Linux, Gentoo
> based or not, run pretty much this way and will be unaffected by this
> whole change and as such have no reason to post.

Ubuntu recommends /, /home and swap [1]. Fedora recommends /, /boot
and swap [2]. OpenSUSE has several sets, but the "simple" and "dual
booting" recommends /, /boot, /home and swap [3]. Debian says [4]:

"For new users, personal Debian boxes, home systems, and other
single-user setups, a single / partition (plus swap) is probably the
easiest, simplest way to go. However, this might not be such a good
idea when you have lots of disk capacity, e.g., 20GB or so. Ext2
partitions tend to perform poorly on file system integrity checking
when they are larger than 6GB or so.

For multi-user systems or systems with lots of disk, it's best to put
/usr, /var, /tmp, and /home each on their own partitions separate from
the / partition."

Interestingly, the Gentoo handbook [5] recommends /, /boot and swap.
Damn, I haven't installed Gentoo in a long time, I hadn't looked at
the handbook in years.

Anyway, Debian is the only "big" distro recommending separated /usr,
and then only for multiuser setups. It's really years since I've
looked at the recommended partition schemes: when I started using
Linux, a separated /home was almost a must. And we had tiny hard
drives then. Now get out of my lawn.

Regards.

[1] http://www.easy-ubuntu-linux.com/ubuntu-installation-606-7.html
[2] http://docs.fedoraproject.org/en-US/Fedora/13/html/Installation_Guide/s2-diskpartrecommend-x86.html
[3] http://en.opensuse.org/SDB:Partitioning
[4] http://www.debian.org/releases/woody/i386/ch-partitioning.en.html
[5] http://www.gentoo.org/doc/en/handbook/handbook-amd64.xml?full=1
-- 
Canek Peláez Valdés
Posgrado en Ciencia e Ingeniería de la Computación
Universidad Nacional Autónoma de México

Re: [gentoo-user] udev + /usr

[Joost Roeleveld]

On Thursday, September 15, 2011 06:44:58 PM Canek Peláez Valdés wrote:
> On Thu, Sep 15, 2011 at 6:26 PM, Mark Knecht <markknecht@gmail.com> wrote:
> > On Thu, Sep 15, 2011 at 3:05 PM, Mike Edenfield <kutulu@kutulu.org> wrote:
> >> On Thursday, September 15, 2011 11:16:03 PM Joost Roeleveld wrote:
> >>> On Thursday, September 15, 2011 04:42:23 PM Mike Edenfield wrote:
> >>> > I would estimate that the vast, vast, vast majority of users are
> >>> > those such as myslelf, who have no opinion whatsoever, and
> >>> > either will not be affected at all by these changes (because
> >>> > they don't separate / and /usr), or will simply apply the
> >>> > proposed initramfs solution and move on.
> >>> 
> >>> You also don't have /var (or /var/log) seperated? Or any of the
> >>> other parts of the filesystem that might be required by udev-rules?
> >> 
> >> Speaking solely for myself, no. Years ago I routinely split /, /usr,
> >> and /var when setting up my FreeBSD systems, and found that it only
> >> ever caused problems when I could not get /usr or /var mounted when I
> >> needed them.
> >> 
> >> At least since I switched to Gentoo, I've simply set up one partition
> >> with everything on it, and kept regular backups in case of failure.
> >> 
> >> I clearly recognize that there are valid reasons to split your
> >> partitions, I have just never found any of them applicable to my
> >> situations.
> >> 
> >> --Mike
> > 
> > My first response to this 300+ post thread, and only to say that in
> > something like 15 years of playing with & using Linux I've never split
> > /usr & no longer split /var. I also don't use LVM or anything fancy
> > like that. I just keep backups and use them if there's a failure. Life
> > is pretty simple.
> > 
> > My suspicion is that by far most casual desktop users of Linux, Gentoo
> > based or not, run pretty much this way and will be unaffected by this
> > whole change and as such have no reason to post.
> 
> Ubuntu recommends /, /home and swap [1]. Fedora recommends /, /boot
> and swap [2]. OpenSUSE has several sets, but the "simple" and "dual
> booting" recommends /, /boot, /home and swap [3]. Debian says [4]:
> 
> "For new users, personal Debian boxes, home systems, and other
> single-user setups, a single / partition (plus swap) is probably the
> easiest, simplest way to go. However, this might not be such a good
> idea when you have lots of disk capacity, e.g., 20GB or so. Ext2
> partitions tend to perform poorly on file system integrity checking
> when they are larger than 6GB or so.
> 
> For multi-user systems or systems with lots of disk, it's best to put
> /usr, /var, /tmp, and /home each on their own partitions separate from
> the / partition."
> 
> Interestingly, the Gentoo handbook [5] recommends /, /boot and swap.
> Damn, I haven't installed Gentoo in a long time, I hadn't looked at
> the handbook in years.
> 
> Anyway, Debian is the only "big" distro recommending separated /usr,
> and then only for multiuser setups. It's really years since I've
> looked at the recommended partition schemes: when I started using
> Linux, a separated /home was almost a must. And we had tiny hard
> drives then. Now get out of my lawn.

Gentoo still has some guides recommending split /usr:
http://www.gentoo.org/doc/en/gentoo-x86+raid+lvm2-quickinstall.xml

There are several people using this type of layout.
The suggested partitioning scheme is usually for beginner installations. Not 
necessarily for larger installations with specific requirements.

The debian guide talks about 20GB drives. I don't have those anymore. the 
smallest drive I have is a 320GB IDE-drive for the database server in the lab.

The server has 2 mirrored 500GB drives for the OS, email and websites. The 
rest of the data is on drives larger then 1TB.
Sticking all these on a single partition is going to take forever to fsck and 
will make maintenance a nightmare. I like the flexibility LVM brings me.

On the gentoo-dev list, I am now hearing that in future, I will need to use a 
full initramfs for my usecase. I'm trying to find out if there is a way to 
avoid this.
Once I find out, I will post the info here.

--
Joost


> Regards.
> 
> [1] http://www.easy-ubuntu-linux.com/ubuntu-installation-606-7.html
> [2]
> http://docs.fedoraproject.org/en-US/Fedora/13/html/Installation_Guide/s2-di
> skpartrecommend-x86.html [3] http://en.opensuse.org/SDB:Partitioning
> [4] http://www.debian.org/releases/woody/i386/ch-partitioning.en.html
> [5] http://www.gentoo.org/doc/en/handbook/handbook-amd64.xml?full=1

Re: [gentoo-user] udev + /usr

[Alan McKinnon]

On Fri, 16 Sep 2011 10:46:02 +0200
Joost Roeleveld <joost@antarean.org> wrote:

> > Anyway, Debian is the only "big" distro recommending separated /usr,
> > and then only for multiuser setups. It's really years since I've
> > looked at the recommended partition schemes: when I started using
> > Linux, a separated /home was almost a must. And we had tiny hard
> > drives then. Now get out of my lawn.  
> 
> Gentoo still has some guides recommending split /usr:
> http://www.gentoo.org/doc/en/gentoo-x86+raid+lvm2-quickinstall.xml
> 
> There are several people using this type of layout.
> The suggested partitioning scheme is usually for beginner
> installations. Not necessarily for larger installations with specific
> requirements.

Using layout suggestions from install docs to justify what the udev
maintainers want to do is simply disingenuous.

The install docs are obviously a guideline only and do not form any
sort of requirement. That is obvious to anyone with some experience in
the field. Anyone suggesting otherwise is either being hyper-literal or
is following some sneaky agenda. Either way, neither type should be
allowed anywhere near policy making as their goals conflict with the
community. 

> The debian guide talks about 20GB drives. I don't have those anymore.
> the smallest drive I have is a 320GB IDE-drive for the database
> server in the lab.

I need 73G SCSI drives for some old servers still running, they cost a
fortune from Dell. The nice man from Dell sales tells me they haven't
had 20G drives in the stores for years and years, he mentioned numbers
like "5" or "8"

:-)



-- 
Alan McKinnnon
alan.mckinnon@gmail.com

Re: [gentoo-user] udev + /usr

[Joost Roeleveld]

On Friday, September 16, 2011 12:00:16 PM Alan McKinnon wrote:
> On Fri, 16 Sep 2011 10:46:02 +0200
> 
> Joost Roeleveld <joost@antarean.org> wrote:
> > > Anyway, Debian is the only "big" distro recommending separated /usr,
> > > and then only for multiuser setups. It's really years since I've
> > > looked at the recommended partition schemes: when I started using
> > > Linux, a separated /home was almost a must. And we had tiny hard
> > > drives then. Now get out of my lawn.
> > 
> > Gentoo still has some guides recommending split /usr:
> > http://www.gentoo.org/doc/en/gentoo-x86+raid+lvm2-quickinstall.xml
> > 
> > There are several people using this type of layout.
> > The suggested partitioning scheme is usually for beginner
> > installations. Not necessarily for larger installations with specific
> > requirements.
> 
> Using layout suggestions from install docs to justify what the udev
> maintainers want to do is simply disingenuous.

I referenced that asa response to the list of "distro-guides".
> 
> The install docs are obviously a guideline only and do not form any
> sort of requirement. That is obvious to anyone with some experience in
> the field. Anyone suggesting otherwise is either being hyper-literal or
> is following some sneaky agenda. Either way, neither type should be
> allowed anywhere near policy making as their goals conflict with the
> community.

I agree and I used my example to point out that any layout that is used by a 
few people is likely to be documented somewhere on the internet.

> > The debian guide talks about 20GB drives. I don't have those anymore.
> > the smallest drive I have is a 320GB IDE-drive for the database
> > server in the lab.
> 
> I need 73G SCSI drives for some old servers still running, they cost a
> fortune from Dell. The nice man from Dell sales tells me they haven't
> had 20G drives in the stores for years and years, he mentioned numbers
> like "5" or "8"

Yes, the 320GB disk is in a machine that was written off by some company about 
4 or 5 years ago. Not sure how long that company used it before they got rid 
of it.

--
Joost

Re: [gentoo-user] udev + /usr

[Alan McKinnon]

On Fri, 16 Sep 2011 12:54:46 +0200
Joost Roeleveld <joost@antarean.org> wrote:

> > Using layout suggestions from install docs to justify what the udev
> > maintainers want to do is simply disingenuous.  
> 
> I referenced that asa response to the list of "distro-guides".

I was backing you up, not arguing against you :-)

-- 
Alan McKinnnon
alan.mckinnon@gmail.com

Re: [gentoo-user] udev + /usr

[Joost Roeleveld]

On Wednesday, September 14, 2011 10:30:03 AM Canek Peláez Valdés wrote:
> On Wed, Sep 14, 2011 at 1:52 AM, Joost Roeleveld <joost@antarean.org> wrote:
> > On Tuesday, September 13, 2011 06:33:01 PM Canek Peláez Valdés wrote:
> >> On Tue, Sep 13, 2011 at 6:10 PM, Michael Schreckenbauer
> >> <grimlog@gmx.de>
> > 
> > wrote:
> >> > If gentoo follows fedora on this mandatory initramfs trail, I'll
> >> > switch to FreeBSD completely. My software works on way more
> >> > systems than just "Linux".
> >> 
> >> That's of course your prerogative. And, as I said before: "Linux
> >> strives to be much more than Unix, and that means do things
> >> differently." If you want to do things the same way that it was done
> >> in the last 20 years, maybe Linux is not the best of choices.
> > 
> > I read it before, but to be much more then Unix, Linux should be doing
> > things better. Being different is what led to MS Windows'
> 
> But that's the thing: we (you and me) don't see the situation the same
> way. To me, the proposed changes are for the better.

There are not many people who agree with you here.
The changes will lead to a C:-drive, similar to MS Windows, where everything 
has to be a single partition.
For various reasons, using seperate partitions are a better solution:
-  It allows for the use of filesystems better suited to the type of files and 
usage on each partition. 
- It prevents a single part of the filesystem to kill the entire system. (I 
can risk loosing 1 partition and not loose the rest of my data)

> >> I myself think the new technologies are worth to change the way we did
> >> things before. But that's just me.
> > 
> > The new technologies have great merit. But, the implementation of it
> > isn't thought through.
> 
> In my humble opinion, what you just said is a little pedantic. You can
> disagree with the proposed changes, you can argue why you think
> another approach could be better. But just saying "the implementation
> of it isn't  thought through", is a little insulting to the devs. I
> think they though about the implementation a lot.

They may have thought about it, but didn't think things through.
I have already stated a better way of doing it in the past few days. I will 
repeat it here.

The problem-scope that udev is TRYING to solve should NOT be solved in a 
single tool.
The main purpose of udev is to populate the /dev-tree.
The running of scripts based on /dev-tree events should be in a seperate tool 
that starts later in the boot-process.

Merging these 2, without properly handling failures, is bad design.
Forcing ALL Linux users to use a C-drive is one of the worst design flaws I 
have ever encountered.
Forcing the use of an init* which can leave systems unbootable, is also a 
design flaw.

How do you propose to fix the situation where the init* is broken and someone 
is unable to mount all the filesystems needed to rebuild the init* because 
udev, which SHOULD be populating the /dev-tree, refuses to do the single job 
it is designed to do?
Then rethink about the fact that not all computers are easily accessible 
and/or have cd-drives/usb-ports active.
My desktop has them active, my servers don't as I do not need USB on the 
server.

> >> >> And maybe I shouldn't even mention it, but I don't use OpenRC. I
> >> >> use
> >> >> systemd. And it works great on Gentoo.
> >> > 
> >> > Well. Linux only. If I wanted a monoculture, I would use
> >> > MS-Windows or
> >> > OSX.
> >> 
> >> Relax man. I mention what I use: I'm not forcing you (or anybody else)
> >> to use it. But I repeat (because I said it before) that I care about
> >> Linux, and Linux only.
> > 
> > If you care about Linux, why do you allow it to be broken in such a
> > fundamental way?
> 
> Again, to me is not "breaking it". To me is "improving it".

Adding another SPOF (Single Point Of Failure) is not an improvement.

--
Joost

Re: [gentoo-user] udev + /usr

[Michael Mol]

On Thu, Sep 15, 2011 at 3:01 AM, Joost Roeleveld <joost@antarean.org> wrote:
> There are not many people who agree with you here.
> The changes will lead to a C:-drive, similar to MS Windows, where everything
> has to be a single partition.

Technically, this isn't true. %PROGRAMFILES need not be on
%SYSTEMDRIVE%. %PROGRAMFILES(x86)% need not be on the same drive as
%PROGRAMFILES%. I believe most of the system key locations are allowed
to be in disparate locations.

> For various reasons, using seperate partitions are a better solution:
> -  It allows for the use of filesystems better suited to the type of files and
> usage on each partition.
> - It prevents a single part of the filesystem to kill the entire system. (I
> can risk loosing 1 partition and not loose the rest of my data)

Fully concur.

>> In my humble opinion, what you just said is a little pedantic. You can
>> disagree with the proposed changes, you can argue why you think
>> another approach could be better. But just saying "the implementation
>> of it isn't  thought through", is a little insulting to the devs. I
>> think they though about the implementation a lot.
>
> They may have thought about it, but didn't think things through.
> I have already stated a better way of doing it in the past few days. I will
> repeat it here.
>
> The problem-scope that udev is TRYING to solve should NOT be solved in a
> single tool.

Concur.

> The main purpose of udev is to populate the /dev-tree.
> The running of scripts based on /dev-tree events should be in a seperate tool
> that starts later in the boot-process.

I'm not *entirely* convinced this is the case, because it feels like
some situations like network devices (nbd, iSCSI) or loopback would
require userland tools to bring up once networking is up.

> Merging these 2, without properly handling failures, is bad design.

Concur.

>> Again, to me is not "breaking it". To me is "improving it".
>
> Adding another SPOF (Single Point Of Failure) is not an improvement.

Concur.

-- 
:wq

Re: [gentoo-user] udev + /usr

[Joost Roeleveld]

On Thursday, September 15, 2011 09:47:34 AM Michael Mol wrote:
> > The main purpose of udev is to populate the /dev-tree.
> > The running of scripts based on /dev-tree events should be in a seperate
> > tool that starts later in the boot-process.
> 
> I'm not entirely convinced this is the case, because it feels like
> some situations like network devices (nbd, iSCSI) or loopback would
> require userland tools to bring up once networking is up.

Yes, but the kernel-events referencing those devices won't appear untill after 
the networking is brought up.
The scripts that "udev" starts are run *after* a device-event is created. If 
the device itself has not been spotted by the kernel (for instance, the 
networking doesn't exist yet), the event won't be triggered yet.

This situation does not require udev to start all these tools when network-
devices appear.

I hope the following would make my thoughts a bit clearer:

1) kernel boots

2) kernel detects network device and places "network-device-event" in the 
queue

3) further things happen and kernel places relevant events in the queue (some 
other events may also already be in the queue before step 2)

4) udev starts and starts processing the queue

5) For each event, udev creates the corresponding device-entry and places 
action-entries in a queue

6) system-init-scripts mount all local filesystems

7) udev-actions starts (I made up this name)

8) udev-actions processes all the entries in the action-queue

From step 4, udev will keep processing further events it gets, which means 
that if any action taken by "udev-actions" causes further devices to become 
available, "udev" will create the device-entries and place the action in the 
action-queue.

If anyone has a setup where /usr can not be mounted easily, it won't work 
currently either and a init* would be necessary anyway.
(Am thinking of NFS, CIFS, iSCSI, NBD, special raid-drivers,.... hosting /usr 
or other required filesystems)

But anyone with a currently working environment should be able to expect a 
currently working environment. If it fails to boot with only updating 
versions, it's a regression. And one of the worst kinds of all.

--
Joost

Re: [gentoo-user] udev + /usr

[Michael Mol]

On Thu, Sep 15, 2011 at 10:11 AM, Joost Roeleveld <joost@antarean.org> wrote:
>> I'm not entirely convinced this is the case, because it feels like
>> some situations like network devices (nbd, iSCSI) or loopback would
>> require userland tools to bring up once networking is up.
>
> Yes, but the kernel-events referencing those devices won't appear untill after
> the networking is brought up.
> The scripts that "udev" starts are run *after* a device-event is created. If
> the device itself has not been spotted by the kernel (for instance, the
> networking doesn't exist yet), the event won't be triggered yet.
>
> This situation does not require udev to start all these tools when network-
> devices appear.
>
> I hope the following would make my thoughts a bit clearer:
>
> 1) kernel boots
>
> 2) kernel detects network device and places "network-device-event" in the
> queue
>
> 3) further things happen and kernel places relevant events in the queue (some
> other events may also already be in the queue before step 2)
>
> 4) udev starts and starts processing the queue
>
> 5) For each event, udev creates the corresponding device-entry and places
> action-entries in a queue
>
> 6) system-init-scripts mount all local filesystems
>
> 7) udev-actions starts (I made up this name)
>
> 8) udev-actions processes all the entries in the action-queue
>
> From step 4, udev will keep processing further events it gets, which means
> that if any action taken by "udev-actions" causes further devices to become
> available, "udev" will create the device-entries and place the action in the
> action-queue.

So, if I read this correctly, there are two classes of processing
events. kernel events and scripted actions. Here's rough pseudocode
describing what I think you're saying. (Or perhaps what I'm hoping
you're saying)

while(wait_for_event())
{
  kevent* pkEvent = NULL;
  if(get_waiting_kernel_event(pkEvent)) // returns true if an event was waiting
  {
    process_kernel_event(pkEvent);
  }
  else
  {
    aevent* pAction = NULL;
    if(get_waiting_action(pAction)) // Returns true if there's an
action waiting.
    {
      process_action(pAction);
    }
  }
}

So, udev processes one event at a time, and always processes kernel
events with a higher priority than resulting scripts. This makes a
certain amount of sense; an action could launch, e.g. nbdclient, which
would cause a new kernel event to get queued.

> If anyone has a setup where /usr can not be mounted easily, it won't work
> currently either and a init* would be necessary anyway.
> (Am thinking of NFS, CIFS, iSCSI, NBD, special raid-drivers,.... hosting /usr
> or other required filesystems)

I don't see how this is relevant to actually fixing udev. (See below)

> But anyone with a currently working environment should be able to expect a
> currently working environment. If it fails to boot with only updating
> versions, it's a regression. And one of the worst kinds of all.

I agree that the direction udev is going is a regression. There aren't
very many people active in this thread who would disagree with that
point. So let's just drop it and focus on what a good, general
solution would look like. (And anyone who says something amounting to
'status quo' for udev needs another explanation of why the udev
developer sees the current scenario as broken. And he's right; the
current scenario is architecturally unsound. I just think he's wrong
about the solution.)

-- 
:wq

Re: [gentoo-user] udev + /usr

[Joost Roeleveld]

On Thursday, September 15, 2011 10:32:50 AM Michael Mol wrote:
> On Thu, Sep 15, 2011 at 10:11 AM, Joost Roeleveld <joost@antarean.org> 
wrote:
> >> I'm not entirely convinced this is the case, because it feels like
> >> some situations like network devices (nbd, iSCSI) or loopback would
> >> require userland tools to bring up once networking is up.
> > 
> > Yes, but the kernel-events referencing those devices won't appear untill
> > after the networking is brought up.
> > The scripts that "udev" starts are run *after* a device-event is
> > created. If the device itself has not been spotted by the kernel (for
> > instance, the networking doesn't exist yet), the event won't be
> > triggered yet.
> > 
> > This situation does not require udev to start all these tools when
> > network- devices appear.
> > 
> > I hope the following would make my thoughts a bit clearer:
> > 
> > 1) kernel boots
> > 
> > 2) kernel detects network device and places "network-device-event" in
> > the
> > queue
> > 
> > 3) further things happen and kernel places relevant events in the queue
> > (some other events may also already be in the queue before step 2)
> > 
> > 4) udev starts and starts processing the queue
> > 
> > 5) For each event, udev creates the corresponding device-entry and
> > places
> > action-entries in a queue
> > 
> > 6) system-init-scripts mount all local filesystems
> > 
> > 7) udev-actions starts (I made up this name)
> > 
> > 8) udev-actions processes all the entries in the action-queue
> > 
> > From step 4, udev will keep processing further events it gets, which
> > means that if any action taken by "udev-actions" causes further devices
> > to become available, "udev" will create the device-entries and place
> > the action in the action-queue.
> 
> So, if I read this correctly, there are two classes of processing
> events. kernel events and scripted actions. Here's rough pseudocode
> describing what I think you're saying. (Or perhaps what I'm hoping
> you're saying)
> 
> while(wait_for_event())
> {
>   kevent* pkEvent = NULL;
>   if(get_waiting_kernel_event(pkEvent)) // returns true if an event was
> waiting {
>     process_kernel_event(pkEvent);
>   }
>   else
>   {
>     aevent* pAction = NULL;
>     if(get_waiting_action(pAction)) // Returns true if there's an
> action waiting.
>     {
>       process_action(pAction);
>     }
>   }
> }

This is, sort-of, what I feel should happen. But currently, in pseudo-code, 
the following seems to happen:
while(wait_for_event())
{
  kevent* pkEvent = NULL;
  if(get_waiting_kernel_event(pkEvent)) // returns true if an event was 
waiting {
    process_kernel_event(pkEvent);
  }
}

I would prefer to see 2 seperate processes:

--- process 1 ---
while(wait_for_event())
{
  kevent* pkEvent = NULL;
  if(get_waiting_kernel_event(pkEvent)) // returns true if an event was 
waiting
  {
    action_event = process_kernel_event(pkEvent);
    if (action_event != NULL)
    {
      put_action_event(pkEvent);
    }
  }
}

------

--- process 2 ---
while(wait_for_event())
{
  aevent* paEvent = NULL;
  if(get_waiting_action_event(paEvent)) // returns true if an event was 
waiting
  {
    process_action_event(paEvent);
  }
}
-------

> So, udev processes one event at a time, and always processes kernel
> events with a higher priority than resulting scripts. This makes a
> certain amount of sense; an action could launch, e.g. nbdclient, which
> would cause a new kernel event to get queued.

Yes, except that udev ONLY handles kernel-events and doesn't process any 
"actions" itself.
These are placed on a seperate queue for a seperate process.

> > If anyone has a setup where /usr can not be mounted easily, it won't
> > work
> > currently either and a init* would be necessary anyway.
> > (Am thinking of NFS, CIFS, iSCSI, NBD, special raid-drivers,.... hosting
> > /usr or other required filesystems)
> 
> I don't see how this is relevant to actually fixing udev. (See below)
> 
> > But anyone with a currently working environment should be able to expect
> > a currently working environment. If it fails to boot with only updating
> > versions, it's a regression. And one of the worst kinds of all.
> 
> I agree that the direction udev is going is a regression. There aren't
> very many people active in this thread who would disagree with that
> point. So let's just drop it and focus on what a good, general
> solution would look like. (And anyone who says something amounting to
> 'status quo' for udev needs another explanation of why the udev
> developer sees the current scenario as broken. And he's right; the
> current scenario is architecturally unsound. I just think he's wrong
> about the solution.)

I agree he is wrong about the solution as well.

I have actually just posted my idea to the gentoo-dev list to see how the 
developers actually feel about possible splitting udev into 2 parts.

I'm not a good enough programmer to do this myself. But if anyone who can code 
and who also agrees with me that my idea for a solution is actually a good 
idea, please let me know and lets see how far we can get with implementing 
this solution.

--
Joost

Re: [gentoo-user] udev + /usr

[Canek Peláez Valdés]

On Thu, Sep 15, 2011 at 10:48 AM, Joost Roeleveld <joost@antarean.org> wrote:
> On Thursday, September 15, 2011 10:32:50 AM Michael Mol wrote:
>> On Thu, Sep 15, 2011 at 10:11 AM, Joost Roeleveld <joost@antarean.org>
> wrote:
>> >> I'm not entirely convinced this is the case, because it feels like
>> >> some situations like network devices (nbd, iSCSI) or loopback would
>> >> require userland tools to bring up once networking is up.
>> >
>> > Yes, but the kernel-events referencing those devices won't appear untill
>> > after the networking is brought up.
>> > The scripts that "udev" starts are run *after* a device-event is
>> > created. If the device itself has not been spotted by the kernel (for
>> > instance, the networking doesn't exist yet), the event won't be
>> > triggered yet.
>> >
>> > This situation does not require udev to start all these tools when
>> > network- devices appear.
>> >
>> > I hope the following would make my thoughts a bit clearer:
>> >
>> > 1) kernel boots
>> >
>> > 2) kernel detects network device and places "network-device-event" in
>> > the
>> > queue
>> >
>> > 3) further things happen and kernel places relevant events in the queue
>> > (some other events may also already be in the queue before step 2)
>> >
>> > 4) udev starts and starts processing the queue
>> >
>> > 5) For each event, udev creates the corresponding device-entry and
>> > places
>> > action-entries in a queue
>> >
>> > 6) system-init-scripts mount all local filesystems
>> >
>> > 7) udev-actions starts (I made up this name)
>> >
>> > 8) udev-actions processes all the entries in the action-queue
>> >
>> > From step 4, udev will keep processing further events it gets, which
>> > means that if any action taken by "udev-actions" causes further devices
>> > to become available, "udev" will create the device-entries and place
>> > the action in the action-queue.
>>
>> So, if I read this correctly, there are two classes of processing
>> events. kernel events and scripted actions. Here's rough pseudocode
>> describing what I think you're saying. (Or perhaps what I'm hoping
>> you're saying)
>>
>> while(wait_for_event())
>> {
>>   kevent* pkEvent = NULL;
>>   if(get_waiting_kernel_event(pkEvent)) // returns true if an event was
>> waiting {
>>     process_kernel_event(pkEvent);
>>   }
>>   else
>>   {
>>     aevent* pAction = NULL;
>>     if(get_waiting_action(pAction)) // Returns true if there's an
>> action waiting.
>>     {
>>       process_action(pAction);
>>     }
>>   }
>> }
>
> This is, sort-of, what I feel should happen. But currently, in pseudo-code,
> the following seems to happen:
> while(wait_for_event())
> {
>  kevent* pkEvent = NULL;
>  if(get_waiting_kernel_event(pkEvent)) // returns true if an event was
> waiting {
>    process_kernel_event(pkEvent);
>  }
> }
>
> I would prefer to see 2 seperate processes:
>
> --- process 1 ---
> while(wait_for_event())
> {
>  kevent* pkEvent = NULL;
>  if(get_waiting_kernel_event(pkEvent)) // returns true if an event was
> waiting
>  {
>    action_event = process_kernel_event(pkEvent);
>    if (action_event != NULL)
>    {
>      put_action_event(pkEvent);
>    }
>  }
> }
>
> ------
>
> --- process 2 ---
> while(wait_for_event())
> {
>  aevent* paEvent = NULL;
>  if(get_waiting_action_event(paEvent)) // returns true if an event was
> waiting
>  {
>    process_action_event(paEvent);
>  }
> }
> -------
>
>> So, udev processes one event at a time, and always processes kernel
>> events with a higher priority than resulting scripts. This makes a
>> certain amount of sense; an action could launch, e.g. nbdclient, which
>> would cause a new kernel event to get queued.
>
> Yes, except that udev ONLY handles kernel-events and doesn't process any
> "actions" itself.
> These are placed on a seperate queue for a seperate process.
>
>> > If anyone has a setup where /usr can not be mounted easily, it won't
>> > work
>> > currently either and a init* would be necessary anyway.
>> > (Am thinking of NFS, CIFS, iSCSI, NBD, special raid-drivers,.... hosting
>> > /usr or other required filesystems)
>>
>> I don't see how this is relevant to actually fixing udev. (See below)
>>
>> > But anyone with a currently working environment should be able to expect
>> > a currently working environment. If it fails to boot with only updating
>> > versions, it's a regression. And one of the worst kinds of all.
>>
>> I agree that the direction udev is going is a regression. There aren't
>> very many people active in this thread who would disagree with that
>> point. So let's just drop it and focus on what a good, general
>> solution would look like. (And anyone who says something amounting to
>> 'status quo' for udev needs another explanation of why the udev
>> developer sees the current scenario as broken. And he's right; the
>> current scenario is architecturally unsound. I just think he's wrong
>> about the solution.)
>
> I agree he is wrong about the solution as well.
>
> I have actually just posted my idea to the gentoo-dev list to see how the
> developers actually feel about possible splitting udev into 2 parts.
>
> I'm not a good enough programmer to do this myself. But if anyone who can code
> and who also agrees with me that my idea for a solution is actually a good
> idea, please let me know and lets see how far we can get with implementing
> this solution.

Now we are talking. I am really, *REALLY* interested to know the devs
saying in the matter.

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

Re: [gentoo-user] udev + /usr

[Canek Peláez Valdés]

On Thu, Sep 15, 2011 at 10:58 AM, Canek Peláez Valdés <caneko@gmail.com> wrote:
> On Thu, Sep 15, 2011 at 10:48 AM, Joost Roeleveld <joost@antarean.org> wrote:
>> On Thursday, September 15, 2011 10:32:50 AM Michael Mol wrote:
>>> On Thu, Sep 15, 2011 at 10:11 AM, Joost Roeleveld <joost@antarean.org>
>> wrote:
>>> >> I'm not entirely convinced this is the case, because it feels like
>>> >> some situations like network devices (nbd, iSCSI) or loopback would
>>> >> require userland tools to bring up once networking is up.
>>> >
>>> > Yes, but the kernel-events referencing those devices won't appear untill
>>> > after the networking is brought up.
>>> > The scripts that "udev" starts are run *after* a device-event is
>>> > created. If the device itself has not been spotted by the kernel (for
>>> > instance, the networking doesn't exist yet), the event won't be
>>> > triggered yet.
>>> >
>>> > This situation does not require udev to start all these tools when
>>> > network- devices appear.
>>> >
>>> > I hope the following would make my thoughts a bit clearer:
>>> >
>>> > 1) kernel boots
>>> >
>>> > 2) kernel detects network device and places "network-device-event" in
>>> > the
>>> > queue
>>> >
>>> > 3) further things happen and kernel places relevant events in the queue
>>> > (some other events may also already be in the queue before step 2)
>>> >
>>> > 4) udev starts and starts processing the queue
>>> >
>>> > 5) For each event, udev creates the corresponding device-entry and
>>> > places
>>> > action-entries in a queue
>>> >
>>> > 6) system-init-scripts mount all local filesystems
>>> >
>>> > 7) udev-actions starts (I made up this name)
>>> >
>>> > 8) udev-actions processes all the entries in the action-queue
>>> >
>>> > From step 4, udev will keep processing further events it gets, which
>>> > means that if any action taken by "udev-actions" causes further devices
>>> > to become available, "udev" will create the device-entries and place
>>> > the action in the action-queue.
>>>
>>> So, if I read this correctly, there are two classes of processing
>>> events. kernel events and scripted actions. Here's rough pseudocode
>>> describing what I think you're saying. (Or perhaps what I'm hoping
>>> you're saying)
>>>
>>> while(wait_for_event())
>>> {
>>>   kevent* pkEvent = NULL;
>>>   if(get_waiting_kernel_event(pkEvent)) // returns true if an event was
>>> waiting {
>>>     process_kernel_event(pkEvent);
>>>   }
>>>   else
>>>   {
>>>     aevent* pAction = NULL;
>>>     if(get_waiting_action(pAction)) // Returns true if there's an
>>> action waiting.
>>>     {
>>>       process_action(pAction);
>>>     }
>>>   }
>>> }
>>
>> This is, sort-of, what I feel should happen. But currently, in pseudo-code,
>> the following seems to happen:
>> while(wait_for_event())
>> {
>>  kevent* pkEvent = NULL;
>>  if(get_waiting_kernel_event(pkEvent)) // returns true if an event was
>> waiting {
>>    process_kernel_event(pkEvent);
>>  }
>> }
>>
>> I would prefer to see 2 seperate processes:
>>
>> --- process 1 ---
>> while(wait_for_event())
>> {
>>  kevent* pkEvent = NULL;
>>  if(get_waiting_kernel_event(pkEvent)) // returns true if an event was
>> waiting
>>  {
>>    action_event = process_kernel_event(pkEvent);
>>    if (action_event != NULL)
>>    {
>>      put_action_event(pkEvent);
>>    }
>>  }
>> }
>>
>> ------
>>
>> --- process 2 ---
>> while(wait_for_event())
>> {
>>  aevent* paEvent = NULL;
>>  if(get_waiting_action_event(paEvent)) // returns true if an event was
>> waiting
>>  {
>>    process_action_event(paEvent);
>>  }
>> }
>> -------
>>
>>> So, udev processes one event at a time, and always processes kernel
>>> events with a higher priority than resulting scripts. This makes a
>>> certain amount of sense; an action could launch, e.g. nbdclient, which
>>> would cause a new kernel event to get queued.
>>
>> Yes, except that udev ONLY handles kernel-events and doesn't process any
>> "actions" itself.
>> These are placed on a seperate queue for a seperate process.
>>
>>> > If anyone has a setup where /usr can not be mounted easily, it won't
>>> > work
>>> > currently either and a init* would be necessary anyway.
>>> > (Am thinking of NFS, CIFS, iSCSI, NBD, special raid-drivers,.... hosting
>>> > /usr or other required filesystems)
>>>
>>> I don't see how this is relevant to actually fixing udev. (See below)
>>>
>>> > But anyone with a currently working environment should be able to expect
>>> > a currently working environment. If it fails to boot with only updating
>>> > versions, it's a regression. And one of the worst kinds of all.
>>>
>>> I agree that the direction udev is going is a regression. There aren't
>>> very many people active in this thread who would disagree with that
>>> point. So let's just drop it and focus on what a good, general
>>> solution would look like. (And anyone who says something amounting to
>>> 'status quo' for udev needs another explanation of why the udev
>>> developer sees the current scenario as broken. And he's right; the
>>> current scenario is architecturally unsound. I just think he's wrong
>>> about the solution.)
>>
>> I agree he is wrong about the solution as well.
>>
>> I have actually just posted my idea to the gentoo-dev list to see how the
>> developers actually feel about possible splitting udev into 2 parts.
>>
>> I'm not a good enough programmer to do this myself. But if anyone who can code
>> and who also agrees with me that my idea for a solution is actually a good
>> idea, please let me know and lets see how far we can get with implementing
>> this solution.
>
> Now we are talking. I am really, *REALLY* interested to know the devs
> saying in the matter.

(This mail is to keep the guys un -user in the loop about -devel).

OK, so Joost posted his proposal to -dev:

http://archives.gentoo.org/gentoo-dev/msg_21e5b8c030cda26c5b317a0e3d9fad67.xml

Zac (portage maintainer, if you need to know) answered:

“Like it or not, it's the simplest possible solution if you want separate
/usr. The plan is to provide a minimal initramfs that won't contain any
modules, so it won't have to be rebuilt for each kernel. See the "/usr
vs. initramfs redux" thread:

http://archives.gentoo.org/gentoo-dev/msg_020fa80d72c84c5b587b90d8001264ef.xml”

Joost asked for details about the Gentoo-sponsored minimal initramfs,
and Zac responded. Read the thread for the whole deal (Zac last
response is not up yet in the archive, should be in a couple hours I
think). I want to focus in how Zac closes his last mail:

“[Joost says]> If someone can explain to me why my idea won't work,
please let me know.

If your goal is to expose yourself to the possibility of unsatisfied
dependencies, they your idea will achieve it.”

Zac's answer is only true in the general case. But he (along with the
rest of the Gentoo devs) is responsible for a *whole* distro. The
important case is the general case. And in the general case, an
initramfs it's the only rational solution.

Zac does not speak for all of the Gentoo devs, of course. But the ones
opposing the idea cannot do much about it, if the ones actually
implementing it write the necessary code. The only alternative is to
write a fork of udev, like Joost is planning.

I would also like to point you guys to this article in LWN.net:

http://lwn.net/SubscriberLink/458789/3ae00c9827889929/

The article (the second part about systemd) closes with:

“The overall picture was of a project that is on a roll, gaining
features and users at a fast rate. The Systemd view of the world has
not yet won over everybody, but the opposition seems to be fading.
Systemd looks like the init system of the future (and more) for a lot
of high-profile distributions.”

The article was written by Jonathan Corbet, editor of LWN and (I think
most people would agree with me) someone who has always tried to be
objective and impartial.

So, if Joost and others are willing and able to implement the
necessary bits to avoid the need for an initramfs, I salute them and
wish them luck. But the most probable outcome is this:

* The fork/replacement will take years of man-effort: design,
implementation, debug, documentation, mainteinance.
* At the same time, the dev-approved solution of a minimal initramfs
or a dracut/genkernel generated one will be available and working.
* If the forking/replacement team manages to create a workable
fork/replacement, it will have to sell it to the Gentoo devs, and if
the initramfs solution is working properly the most rational answer
will be "no, thank you".

I'm sorry if my analysis bother some people, but it's basically what
I've been saying from the beginning. I'm glad Joost asked the
developers for their input. I think it clears the air about a lot of
things.

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

Re: [gentoo-user] udev + /usr

[Joost Roeleveld]

On Thursday, September 15, 2011 01:43:17 PM Canek Peláez Valdés wrote:
> On Thu, Sep 15, 2011 at 10:58 AM, Canek Peláez Valdés <caneko@gmail.com> 
wrote:
> (This mail is to keep the guys un -user in the loop about -devel).
> 
> OK, so Joost posted his proposal to -dev:

<snipped brief discussion on gentoo-dev>

The thread on gentoo-dev is not yet finished and I intend to try to get some 
more information. As I mentioned in my other email.

> I would also like to point you guys to this article in LWN.net:
> 
> http://lwn.net/SubscriberLink/458789/3ae00c9827889929/
> 
> The article (the second part about systemd) closes with:
> 
> “The overall picture was of a project that is on a roll, gaining
> features and users at a fast rate. The Systemd view of the world has
> not yet won over everybody, but the opposition seems to be fading.
> Systemd looks like the init system of the future (and more) for a lot
> of high-profile distributions.”
> 
> The article was written by Jonathan Corbet, editor of LWN and (I think
> most people would agree with me) someone who has always tried to be
> objective and impartial.

I'll read this later (probably tomorrow) and get back to you on this if 
necessary.

> So, if Joost and others are willing and able to implement the
> necessary bits to avoid the need for an initramfs, I salute them and
> wish them luck. But the most probable outcome is this:
> 
> * The fork/replacement will take years of man-effort: design,
> implementation, debug, documentation, mainteinance.
> * At the same time, the dev-approved solution of a minimal initramfs
> or a dracut/genkernel generated one will be available and working.
> * If the forking/replacement team manages to create a workable
> fork/replacement, it will have to sell it to the Gentoo devs, and if
> the initramfs solution is working properly the most rational answer
> will be "no, thank you".

The time needed for this is not certain as we are planning on basing it on the 
current udev and see what is possible.
If the Gentoo-devs come up with a fool-proof solution, which is one of the 
possible outcomes I am trying to get to in the gentoo-dev thread, I will be 
happy there as well.

As for the udev-fork to ever becoming mainstream, I can't say. It might not 
even work the way we are hoping. Only time will tell.

> I'm sorry if my analysis bother some people, but it's basically what
> I've been saying from the beginning. I'm glad Joost asked the
> developers for their input. I think it clears the air about a lot of
> things.

I have no problem with your analysis and yes, the initial response from Zac 
was what you've been saying.
I am hoping to get more information on this and I will have no problem if you 
keep reporting it back here.

One of the reasons I asked it on Gentoo-dev is simply because I agree with 
some people here that this thread was starting to go in circles and no new 
information was being added.

--
Joost

Re: [gentoo-user] udev + /usr

[Canek Peláez Valdés]

On Thu, Sep 15, 2011 at 5:25 PM, Joost Roeleveld <joost@antarean.org> wrote:
[ Hugemongous snip ]
> If the Gentoo-devs come up with a fool-proof solution

No such thing in computing, I think. But I also think is really
laudable that you want to ensure no many users will get bitten by this
change.

And I also tend to believe that Gentoo users are more than able to
deal with this and almost any other thing.

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

Re: [gentoo-user] udev + /usr

[Joost Roeleveld]

On Thursday, September 15, 2011 05:34:11 PM Canek Peláez Valdés wrote:
> On Thu, Sep 15, 2011 at 5:25 PM, Joost Roeleveld <joost@antarean.org> wrote:
> [ Hugemongous snip ]
> 
> > If the Gentoo-devs come up with a fool-proof solution
> 
> No such thing in computing, I think.

I'm afraid you're right on this as that is also my experience. And not just in 
computing.
The biggest difficult with designing fool-proof systems is the fact that 
designers will always underestimate the ingenuity of fools.

> But I also think is really
> laudable that you want to ensure no many users will get bitten by this
> change.

I work in IT. Currently in support (enterprise-software, not home users) and 
moving into consulting soon.
I don't like to see broken systems and always want to find solutions to 
problems I encounter. I might not always succeed, but I will certainly try.

> And I also tend to believe that Gentoo users are more than able to
> deal with this and almost any other thing.

I agree, the vast majority of people on this list know how to solve issues for 
themselves or are able to formulate their problems/questions in such a way 
that others with more experience in that particular field can come up with the 
answer.

However, I also think there are plenty of Gentoo-users who don't subscribe to 
this list and may easily get caught out when this situation really starts 
affecting them.

--
Joost

Re: [gentoo-user] udev + /usr

[Walter Dnes]

On Thu, Sep 15, 2011 at 11:25:11PM +0200, Joost Roeleveld wrote
> On Thursday, September 15, 2011 01:43:17 PM Canek Pel??ez Vald??s wrote:
> > On Thu, Sep 15, 2011 at 10:58 AM, Canek Pel??ez Vald??s <caneko@gmail.com> 
> wrote:
> > (This mail is to keep the guys un -user in the loop about -devel).
> > 
> > OK, so Joost posted his proposal to -dev:
> 
> <snipped brief discussion on gentoo-dev>
> 
> The thread on gentoo-dev is not yet finished and I intend to try to get some 
> more information. As I mentioned in my other email.

  I've asked on the busybox list, and one of the people there says he
does have a chrooted Gentoo running with mdev (a busybox tool) replacing
udev.  There were various other changes he had to make to get it
working, but it obviously can be done.  He's busy for the next couple of
weeks, but has offered (offline) to work on generalizing it to work in
more general cases.  Apparently, the mdev code is a small part of
busybox, so he figures it would be simplest to copy the code out of
busybox, and make a standalone mdev.  The busybox mdev doesn't have all
the features of udev, and busybox's developers will obviously want to
keep their code lean-and-mean.  That's why a standalone mdev seems to be
the way to go.

-- 
Walter Dnes <waltdnes@waltdnes.org>

Re: [gentoo-user] udev + /usr

[Michael Mol]

On Thu, Sep 15, 2011 at 10:48 AM, Joost Roeleveld <joost@antarean.org> wrote:
> On Thursday, September 15, 2011 10:32:50 AM Michael Mol wrote:
>> On Thu, Sep 15, 2011 at 10:11 AM, Joost Roeleveld <joost@antarean.org>
> wrote:
>> >> I'm not entirely convinced this is the case, because it feels like
>> >> some situations like network devices (nbd, iSCSI) or loopback would
>> >> require userland tools to bring up once networking is up.
>> >
>> > Yes, but the kernel-events referencing those devices won't appear untill
>> > after the networking is brought up.
>> > The scripts that "udev" starts are run *after* a device-event is
>> > created. If the device itself has not been spotted by the kernel (for
>> > instance, the networking doesn't exist yet), the event won't be
>> > triggered yet.
>> >
>> > This situation does not require udev to start all these tools when
>> > network- devices appear.
>> >
>> > I hope the following would make my thoughts a bit clearer:
>> >
>> > 1) kernel boots
>> >
>> > 2) kernel detects network device and places "network-device-event" in
>> > the
>> > queue
>> >
>> > 3) further things happen and kernel places relevant events in the queue
>> > (some other events may also already be in the queue before step 2)
>> >
>> > 4) udev starts and starts processing the queue
>> >
>> > 5) For each event, udev creates the corresponding device-entry and
>> > places
>> > action-entries in a queue
>> >
>> > 6) system-init-scripts mount all local filesystems
>> >
>> > 7) udev-actions starts (I made up this name)
>> >
>> > 8) udev-actions processes all the entries in the action-queue
>> >
>> > From step 4, udev will keep processing further events it gets, which
>> > means that if any action taken by "udev-actions" causes further devices
>> > to become available, "udev" will create the device-entries and place
>> > the action in the action-queue.
>>
>> So, if I read this correctly, there are two classes of processing
>> events. kernel events and scripted actions. Here's rough pseudocode
>> describing what I think you're saying. (Or perhaps what I'm hoping
>> you're saying)
>>
>> while(wait_for_event())
>> {
>>   kevent* pkEvent = NULL;
>>   if(get_waiting_kernel_event(pkEvent)) // returns true if an event was
>> waiting {
>>     process_kernel_event(pkEvent);
>>   }
>>   else
>>   {
>>     aevent* pAction = NULL;
>>     if(get_waiting_action(pAction)) // Returns true if there's an
>> action waiting.
>>     {
>>       process_action(pAction);
>>     }
>>   }
>> }
>
> This is, sort-of, what I feel should happen. But currently, in pseudo-code,
> the following seems to happen:
> while(wait_for_event())
> {
>  kevent* pkEvent = NULL;
>  if(get_waiting_kernel_event(pkEvent)) // returns true if an event was
> waiting {
>    process_kernel_event(pkEvent);
>  }
> }
>
> I would prefer to see 2 seperate processes:
>
> --- process 1 ---
> while(wait_for_event())
> {
>  kevent* pkEvent = NULL;
>  if(get_waiting_kernel_event(pkEvent)) // returns true if an event was
> waiting
>  {
>    action_event = process_kernel_event(pkEvent);
>    if (action_event != NULL)
>    {
>      put_action_event(pkEvent);
>    }
>  }
> }
>
> ------
>
> --- process 2 ---
> while(wait_for_event())
> {
>  aevent* paEvent = NULL;
>  if(get_waiting_action_event(paEvent)) // returns true if an event was
> waiting
>  {
>    process_action_event(paEvent);
>  }
> }
> -------
>
>> So, udev processes one event at a time, and always processes kernel
>> events with a higher priority than resulting scripts. This makes a
>> certain amount of sense; an action could launch, e.g. nbdclient, which
>> would cause a new kernel event to get queued.
>
> Yes, except that udev ONLY handles kernel-events and doesn't process any
> "actions" itself.
> These are placed on a seperate queue for a seperate process.

The problem with this is that you now need to manage synchronization
between the kernel event processor and the action processor, which is
actually more complicated than keeping them together in a
single-threaded, single-process scenario.


-- 
:wq

Re: [gentoo-user] udev + /usr

[Michael Schreckenbauer]

On Thursday, 15. September 2011 11:03:09 Michael Mol wrote:
> > Yes, except that udev ONLY handles kernel-events and doesn't process any
> > "actions" itself.
> > These are placed on a seperate queue for a seperate process.
> 
> The problem with this is that you now need to manage synchronization
> between the kernel event processor and the action processor, which is
> actually more complicated than keeping them together in a
> single-threaded, single-process scenario.

Yes, it's more complicated to do. But not impossible.
IPC, shared memory and what not, exists for a reason

Best,
Michael

Re: [gentoo-user] udev + /usr

[Michael Mol]

On Thu, Sep 15, 2011 at 11:16 AM, Michael Schreckenbauer <grimlog@gmx.de> wrote:
> On Thursday, 15. September 2011 11:03:09 Michael Mol wrote:
>> > Yes, except that udev ONLY handles kernel-events and doesn't process any
>> > "actions" itself.
>> > These are placed on a seperate queue for a seperate process.
>>
>> The problem with this is that you now need to manage synchronization
>> between the kernel event processor and the action processor, which is
>> actually more complicated than keeping them together in a
>> single-threaded, single-process scenario.
>
> Yes, it's more complicated to do. But not impossible.
> IPC, shared memory and what not, exists for a reason

Sure. But it's not KISS, it's not necessary and it's a royal PITA. One
of queued tasks here at work is debugging _exactly_ that kind of code.
You need a _very_ good reason to use it, because it doesn't make any
solution more elegant.

I don't see a pragmatic value to splitting the process. At work, I
have to do it because it links to badly-written crash-prone code I
can't fix. If I can reasonably guarantee that the code I need to run
will behave, then the overhead and complexity definitely doesn't seem
worthwhile.

And because I've sat on two sides of the KISS argument in as many
messages, I'd like to make some points clear:

* The udev tool needs to be reliable, and this means no complexity
unnecessary to fulfilling its role. However...
* Part of udev's role needs to be *not* impose constraints on a system
without a clear path to get from point A to point B; as long an API is
understood, someone plugging into udev should be able to find a way to
reliably do what they want to do.


-- 
:wq

Re: [gentoo-user] udev + /usr

[Joost Roeleveld]

On Thursday, September 15, 2011 11:03:09 AM Michael Mol wrote:
> On Thu, Sep 15, 2011 at 10:48 AM, Joost Roeleveld <joost@antarean.org> 
wrote:
> > On Thursday, September 15, 2011 10:32:50 AM Michael Mol wrote:
> >> On Thu, Sep 15, 2011 at 10:11 AM, Joost Roeleveld <joost@antarean.org>
> > 
> > wrote:
> >> >> I'm not entirely convinced this is the case, because it feels
> >> >> like
> >> >> some situations like network devices (nbd, iSCSI) or loopback
> >> >> would
> >> >> require userland tools to bring up once networking is up.
> >> > 
> >> > Yes, but the kernel-events referencing those devices won't appear
> >> > untill after the networking is brought up.
> >> > The scripts that "udev" starts are run *after* a device-event is
> >> > created. If the device itself has not been spotted by the kernel
> >> > (for
> >> > instance, the networking doesn't exist yet), the event won't be
> >> > triggered yet.
> >> > 
> >> > This situation does not require udev to start all these tools when
> >> > network- devices appear.
> >> > 
> >> > I hope the following would make my thoughts a bit clearer:
> >> > 
> >> > 1) kernel boots
> >> > 
> >> > 2) kernel detects network device and places "network-device-event"
> >> > in
> >> > the
> >> > queue
> >> > 
> >> > 3) further things happen and kernel places relevant events in the
> >> > queue (some other events may also already be in the queue before
> >> > step 2)
> >> > 
> >> > 4) udev starts and starts processing the queue
> >> > 
> >> > 5) For each event, udev creates the corresponding device-entry and
> >> > places
> >> > action-entries in a queue
> >> > 
> >> > 6) system-init-scripts mount all local filesystems
> >> > 
> >> > 7) udev-actions starts (I made up this name)
> >> > 
> >> > 8) udev-actions processes all the entries in the action-queue
> >> > 
> >> > From step 4, udev will keep processing further events it gets,
> >> > which
> >> > means that if any action taken by "udev-actions" causes further
> >> > devices to become available, "udev" will create the
> >> > device-entries and place the action in the action-queue.
> >> 
> >> So, if I read this correctly, there are two classes of processing
> >> events. kernel events and scripted actions. Here's rough pseudocode
> >> describing what I think you're saying. (Or perhaps what I'm hoping
> >> you're saying)
> >> 
> >> while(wait_for_event())
> >> {
> >>   kevent* pkEvent = NULL;
> >>   if(get_waiting_kernel_event(pkEvent)) // returns true if an event
> >> was
> >> waiting {
> >>     process_kernel_event(pkEvent);
> >>   }
> >>   else
> >>   {
> >>     aevent* pAction = NULL;
> >>     if(get_waiting_action(pAction)) // Returns true if there's an
> >> action waiting.
> >>     {
> >>       process_action(pAction);
> >>     }
> >>   }
> >> }
> > 
> > This is, sort-of, what I feel should happen. But currently, in
> > pseudo-code, the following seems to happen:
> > while(wait_for_event())
> > {
> >  kevent* pkEvent = NULL;
> >  if(get_waiting_kernel_event(pkEvent)) // returns true if an event was
> > waiting {
> >    process_kernel_event(pkEvent);
> >  }
> > }
> > 
> > I would prefer to see 2 seperate processes:
> > 
> > --- process 1 ---
> > while(wait_for_event())
> > {
> >  kevent* pkEvent = NULL;
> >  if(get_waiting_kernel_event(pkEvent)) // returns true if an event was
> > waiting
> >  {
> >    action_event = process_kernel_event(pkEvent);
> >    if (action_event != NULL)
> >    {
> >      put_action_event(pkEvent);
> >    }
> >  }
> > }
> > 
> > ------
> > 
> > --- process 2 ---
> > while(wait_for_event())
> > {
> >  aevent* paEvent = NULL;
> >  if(get_waiting_action_event(paEvent)) // returns true if an event was
> > waiting
> >  {
> >    process_action_event(paEvent);
> >  }
> > }
> > -------
> > 
> >> So, udev processes one event at a time, and always processes kernel
> >> events with a higher priority than resulting scripts. This makes a
> >> certain amount of sense; an action could launch, e.g. nbdclient, which
> >> would cause a new kernel event to get queued.
> > 
> > Yes, except that udev ONLY handles kernel-events and doesn't process any
> > "actions" itself.
> > These are placed on a seperate queue for a seperate process.
> 
> The problem with this is that you now need to manage synchronization
> between the kernel event processor and the action processor, which is
> actually more complicated than keeping them together in a
> single-threaded, single-process scenario.

I don't agree. Why does this need to be synchronized?

The kernel puts events in the new-dev-event-queue that process 1 picks up.
process 1 creates the /dev-entrie(s) and, if there is an action to be taken, 
puts the action in the new-action-event-queue.

Process 2 will then pick up this action from the new-action-event-queue and 
will process this.

If, as a side-effect, of the action processed by process 2, a new device 
appears for the kernel, the kernel will simply put a corresponding event in 
the new-dev-event-queue.

At which state does this need to be synchronized?
We can simply use a pipe-device as, for instance, used for syslog?

--
Joost

Re: [gentoo-user] udev + /usr

[Michael Mol]

On Thu, Sep 15, 2011 at 11:43 AM, Joost Roeleveld <joost@antarean.org> wrote:
> On Thursday, September 15, 2011 11:03:09 AM Michael Mol wrote:
>> On Thu, Sep 15, 2011 at 10:48 AM, Joost Roeleveld <joost@antarean.org>
> wrote:
>> The problem with this is that you now need to manage synchronization
>> between the kernel event processor and the action processor, which is
>> actually more complicated than keeping them together in a
>> single-threaded, single-process scenario.
>
> I don't agree. Why does this need to be synchronized?
>
> The kernel puts events in the new-dev-event-queue that process 1 picks up.
> process 1 creates the /dev-entrie(s) and, if there is an action to be taken,
> puts the action in the new-action-event-queue.
>
> Process 2 will then pick up this action from the new-action-event-queue and
> will process this.
>
> If, as a side-effect, of the action processed by process 2, a new device
> appears for the kernel, the kernel will simply put a corresponding event in
> the new-dev-event-queue.
>
> At which state does this need to be synchronized?
> We can simply use a pipe-device as, for instance, used for syslog?

Let's assume that you have a single-reader, single-writer scenario,
and that either the protocol includes a 'record end' marker, or that
protocol messages are all of a fixed length and are written
atomically. With that out of the way, I don't know. Perhaps no
additional synchronization is necessary.

You still have a problem with race conditions. Virtually all scripts
I've read and written assume a single-threaded environment, but you've
defined a two-threaded environment.

Here's a potential scenario:

1) A kernel hotplug event comes in when a device is inserted.
2) keventler catches the hotplug event, creates the device node,
queues an action event.
3) actionhandler catches the action event, launches the script.
4) The action handler script is still running for the plug-in event,
when A kernel hotplug event comes in indicating the device was
removed. keventler catches the new hotplug event, removes the device
node--
5) --the scheduler comes around and resumes working on the action
handler script. Or perhaps the action handler script was on a
different CPU core, and never needed to be unscheduled. The device
node it was expecting to be there just disappeared out from under it,
violating one of its assumptions, and putting it in an inconsistent
state. The inconsistency might occur in a place the script author
expected it, or the inconsistency might have occurred in an unexpected
place. One presumes the script author didn't sign up to deal with
concurrency issues in a bash or python script.
6) keventler  registers a new action event, for actioning on the disconnect.
7) actionhandler picks up this new action event, runs the script.
Kudos to the script author for thinking ahead to have a shutdown
script properly clean up an inconsistent system state left by the
partially failed setup script.

Steps 3-5 are a classic example of a race condition, and stem from two
active threads operating concurrently. Entire programming languages
are developed with the core intent of reducing the programmer's need
to worry about such things.

You _must not_ change the operating environment of a script out from under it.

In bash scripts, this is an extraordinarily common pattern:

if [ -d $SOME_PATH ]; then
  // do something
fi

That's common and accepted; nobody expects a shell script to fail in a
scenario like that, because it's is a single-threaded language, and
that's been true since its inception. When something keventler does
causes the result of "[ -d $SOME_PATH ]" to change after the test had
already been done, then the script is only broken because
keventler/actionhandler broke it, not because the script was badly
written.

I've really got to get back to working on stuff I'm being paid for.
I'll chat with you guys this weekend. I'm very interested in helping
with a reasoned critical perspective, so if this wanders over to a new
mailing list or discussion environment, drop me an invite.

-- 
:wq

Re: [gentoo-user] udev + /usr

[Joost Roeleveld]

On Thursday, September 15, 2011 12:16:24 PM Michael Mol wrote:
> On Thu, Sep 15, 2011 at 11:43 AM, Joost Roeleveld <joost@antarean.org> 
wrote:
> > On Thursday, September 15, 2011 11:03:09 AM Michael Mol wrote:
> >> On Thu, Sep 15, 2011 at 10:48 AM, Joost Roeleveld <joost@antarean.org>
> > 
> > wrote:
> >> The problem with this is that you now need to manage synchronization
> >> between the kernel event processor and the action processor, which is
> >> actually more complicated than keeping them together in a
> >> single-threaded, single-process scenario.
> > 
> > I don't agree. Why does this need to be synchronized?
> > 
> > The kernel puts events in the new-dev-event-queue that process 1 picks
> > up. process 1 creates the /dev-entrie(s) and, if there is an action to
> > be taken, puts the action in the new-action-event-queue.
> > 
> > Process 2 will then pick up this action from the new-action-event-queue
> > and will process this.
> > 
> > If, as a side-effect, of the action processed by process 2, a new device
> > appears for the kernel, the kernel will simply put a corresponding event
> > in the new-dev-event-queue.
> > 
> > At which state does this need to be synchronized?
> > We can simply use a pipe-device as, for instance, used for syslog?
> 
> Let's assume that you have a single-reader, single-writer scenario,
> and that either the protocol includes a 'record end' marker, or that
> protocol messages are all of a fixed length and are written
> atomically. With that out of the way, I don't know. Perhaps no
> additional synchronization is necessary.
> 
> You still have a problem with race conditions. Virtually all scripts
> I've read and written assume a single-threaded environment, but you've
> defined a two-threaded environment.
> 
> Here's a potential scenario:
> 
> 1) A kernel hotplug event comes in when a device is inserted.
> 2) keventler catches the hotplug event, creates the device node,
> queues an action event.
> 3) actionhandler catches the action event, launches the script.
> 4) The action handler script is still running for the plug-in event,
> when A kernel hotplug event comes in indicating the device was
> removed. keventler catches the new hotplug event, removes the device
> node--
> 5) --the scheduler comes around and resumes working on the action
> handler script. Or perhaps the action handler script was on a
> different CPU core, and never needed to be unscheduled. The device
> node it was expecting to be there just disappeared out from under it,
> violating one of its assumptions, and putting it in an inconsistent
> state. The inconsistency might occur in a place the script author
> expected it, or the inconsistency might have occurred in an unexpected
> place. One presumes the script author didn't sign up to deal with
> concurrency issues in a bash or python script.
> 6) keventler  registers a new action event, for actioning on the disconnect.
> 7) actionhandler picks up this new action event, runs the script.
> Kudos to the script author for thinking ahead to have a shutdown
> script properly clean up an inconsistent system state left by the
> partially failed setup script.
> 
> Steps 3-5 are a classic example of a race condition, and stem from two
> active threads operating concurrently. Entire programming languages
> are developed with the core intent of reducing the programmer's need
> to worry about such things.
>
> You _must not_ change the operating environment of a script out from under
> it.
> 
> In bash scripts, this is an extraordinarily common pattern:
> 
> if [ -d $SOME_PATH ]; then
>   // do something
> fi
> 
> That's common and accepted; nobody expects a shell script to fail in a
> scenario like that, because it's is a single-threaded language, and
> that's been true since its inception. When something keventler does
> causes the result of "[ -d $SOME_PATH ]" to change after the test had
> already been done, then the script is only broken because
> keventler/actionhandler broke it, not because the script was badly
> written.

Ok, didn't think of this scenario. Thank you for pointing this out to me.
Your pseudo-code would be better then, except there should be some way of 
delaying action-tasks based on wether or not required files (including 
dependencies) are available. Or a retry-queue that retries an action a few 
times with certain intervals. This, however, will be more difficult to 
implement especially with the race-condition you mentioned.

> I've really got to get back to working on stuff I'm being paid for.
> I'll chat with you guys this weekend. I'm very interested in helping
> with a reasoned critical perspective, so if this wanders over to a new
> mailing list or discussion environment, drop me an invite.

We will, but for now, why not keep it on here? :)

Was wondering, does udev actually support actions for when a device is 
removed?
Ok, just checked on my server and it does. All nicely pointing to scripts in 
/etc/....

Also, anyone knows how udev handles the scenario where a device is removed 
while the script is still running? Wouldn't it fail mid-execution because the 
kernel no longer allows actions with that device?

--
Joost

Re: [gentoo-user] udev + /usr

[Michael Schreckenbauer]

On Thursday, 15. September 2011 16:48:45 Joost Roeleveld wrote:
> I agree he is wrong about the solution as well.
> 
> I have actually just posted my idea to the gentoo-dev list to see how the
> developers actually feel about possible splitting udev into 2 parts.

I've read it there. Thanks for doing this.

> I'm not a good enough programmer to do this myself. But if anyone who can
> code and who also agrees with me that my idea for a solution is actually a
> good idea, please let me know and lets see how far we can get with
> implementing this solution.

I'm definitely interested in this. I don't know, how many or little I can 
contribute. Working as a freelancer, I have some time now, but this could 
change quite fast. I have developed quite a few daemons at the company I 
worked for the past ~10 years. So I can say, I have some experience in doing 
things your proposal needs.
Feel free to send me PM, if you have questions about me, my knowledge or 
simply to exchange ideas.

> --
> Joost

Best,
Michael

Re: [gentoo-user] udev + /usr

[Mick]

[-- Attachment #1: Type: Text/Plain, Size: 1825 bytes --]

On Thursday 15 Sep 2011 16:13:26 Michael Schreckenbauer wrote:
> On Thursday, 15. September 2011 16:48:45 Joost Roeleveld wrote:
> > I agree he is wrong about the solution as well.
> > 
> > I have actually just posted my idea to the gentoo-dev list to see how the
> > developers actually feel about possible splitting udev into 2 parts.
> 
> I've read it there. Thanks for doing this.

Thanks Joost for posting in the dev list and for explaining your proposed 
approach there.  I've just read your thread in the dev list:

http://thread.gmane.org/gmane.linux.gentoo.devel/72969


Zac's response helped me understand better what the Gentoo devs have been 
suggesting here:

http://archives.gentoo.org/gentoo-dev/msg_020fa80d72c84c5b587b90d8001264ef.xml

and it does make sense - their version of initramfs-'lite'.

From what I understand:

1.  The minimal initramfs will only need to be built once (and rarely rebuilt 
thereafter).  This removes one of my fears and it was a main objection for me 
- I would hate to have to rebuild initramfs every time I roll a new kernel, or 
libs and what not of fs happen to be udpated, etc.

2. If initramfs fails, then Zac says it will drop you into a minimal shell, so 
we should still be able to recover/troubleshoot/reboot from there.

The only drawback is the 2 minutes it will take a user the first time this 
change is introduced to build the initramfs and change the kernel line in 
grub.conf.  I am warming up to this proposal because it seems to me that it 
will end up being less painful that I originally thought.

However, I still see it as a workaround to a more elegant solution, which as 
Joost and others suggest would involve separating udev's probing for devices 
with the rules running of scripts for them.
-- 
Regards,
Mick

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-user] udev + /usr

[Canek Peláez Valdés]

On Thu, Sep 15, 2011 at 1:59 PM, Mick <michaelkintzios@gmail.com> wrote:
> On Thursday 15 Sep 2011 16:13:26 Michael Schreckenbauer wrote:
>> On Thursday, 15. September 2011 16:48:45 Joost Roeleveld wrote:
>> > I agree he is wrong about the solution as well.
>> >
>> > I have actually just posted my idea to the gentoo-dev list to see how the
>> > developers actually feel about possible splitting udev into 2 parts.
>>
>> I've read it there. Thanks for doing this.
>
> Thanks Joost for posting in the dev list and for explaining your proposed
> approach there.  I've just read your thread in the dev list:
>
> http://thread.gmane.org/gmane.linux.gentoo.devel/72969
>
>
> Zac's response helped me understand better what the Gentoo devs have been
> suggesting here:
>
> http://archives.gentoo.org/gentoo-dev/msg_020fa80d72c84c5b587b90d8001264ef.xml
>
> and it does make sense - their version of initramfs-'lite'.
>
> From what I understand:
>
> 1.  The minimal initramfs will only need to be built once (and rarely rebuilt
> thereafter).  This removes one of my fears and it was a main objection for me
> - I would hate to have to rebuild initramfs every time I roll a new kernel, or
> libs and what not of fs happen to be udpated, etc.

In my experience, it takes more time to build the kernel than it takes
to rebuild the initramfs. And if you choose to use dracut, the process
is automatic (you always call dracut with the same options, unless you
suddenly add LVM or something similar).

I didn't use an initramfs for my first years using Gentoo. Since I
started to use media-gfx/splashutils a couple of years ago, every time
I upgraded my kernel, I splash_geninitramfs'd my initramfs. Now I do
the same, but with plymouth and systemd using dracut. It's just part
of the process of getting a new kernel.

> 2. If initramfs fails, then Zac says it will drop you into a minimal shell, so
> we should still be able to recover/troubleshoot/reboot from there.

From the last response in the -dev list (from Rich Freeman):

“It should be noted that the alternative is to use a more
full-featured initramfs like dracut, which will also be updated to
support mounting /usr (it already parses /etc/fstab to remount root
anyway).

...

Note that dracut does drop you to a shell if it fails (this is
configurable), but by default this shell is dash, not bash.  No doubt
it would work fine either way, but bash is likely to be a little
slower.  I don't think RAM use is likely to be a problem - it should
be completely de-allocated before init runs.”

> The only drawback is the 2 minutes it will take a user the first time this
> change is introduced to build the initramfs and change the kernel line in
> grub.conf.  I am warming up to this proposal because it seems to me that it
> will end up being less painful that I originally thought.

Reading the homepages of the projects involved always helps to better
understand the possible outcome of using the new technologies. Perhaps
you should take a look at dracut: Maybe a complete initramfs solution
will convince you, especially if an initramfs will be needed anyway.

> However, I still see it as a workaround to a more elegant solution, which as
> Joost and others suggest would involve separating udev's probing for devices
> with the rules running of scripts for them.

Maybe that's the more elegant solution. Certainly it will take a lot
more effort, in the sense that somebody has to implement, test and
debug said solution. I sincerely wish them good luck.

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

Re: [gentoo-user] udev + /usr

[Neil Bothwick]

[-- Attachment #1: Type: text/plain, Size: 824 bytes --]

On Thu, 15 Sep 2011 15:04:37 -0400, Canek Peláez Valdés wrote:

> > 1.  The minimal initramfs will only need to be built once (and rarely
> > rebuilt thereafter).  This removes one of my fears and it was a main
> > objection for me
> > - I would hate to have to rebuild initramfs every time I roll a new
> > kernel, or libs and what not of fs happen to be udpated, etc.  
> 
> In my experience, it takes more time to build the kernel than it takes
> to rebuild the initramfs. And if you choose to use dracut, the process
> is automatic (you always call dracut with the same options, unless you
> suddenly add LVM or something similar).

The concern is not the time (Gentoo users are used to waiting for things
to install) it's the opportunity for failure.


-- 
Neil Bothwick

IBM: Itty Bitty Mentality

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-user] udev + /usr

[Joost Roeleveld]

On Thursday, September 15, 2011 03:04:37 PM Canek Peláez Valdés wrote:
> On Thu, Sep 15, 2011 at 1:59 PM, Mick <michaelkintzios@gmail.com> wrote:
> > On Thursday 15 Sep 2011 16:13:26 Michael Schreckenbauer wrote:
> > 1.  The minimal initramfs will only need to be built once (and rarely
> > rebuilt thereafter).  This removes one of my fears and it was a main
> > objection for me - I would hate to have to rebuild initramfs every time
> > I roll a new kernel, or libs and what not of fs happen to be udpated,
> > etc.
> 
> In my experience, it takes more time to build the kernel than it takes
> to rebuild the initramfs. And if you choose to use dracut, the process
> is automatic (you always call dracut with the same options, unless you
> suddenly add LVM or something similar).

Canek, as you've been using dracut already extensively, is it possible to set 
default options/modules/whatever to get to the situation where simply running 
"dracut" without any extra options will always recreate the correct initramfs?

> I didn't use an initramfs for my first years using Gentoo. Since I
> started to use media-gfx/splashutils a couple of years ago, every time
> I upgraded my kernel, I splash_geninitramfs'd my initramfs. Now I do
> the same, but with plymouth and systemd using dracut. It's just part
> of the process of getting a new kernel.

And, if the initramfs has other tools in it, after every emerge of these 
tools. This is where I see a possible cause for failure as then the situation 
arises where the initramfs will still start "correctly", but because it's 
using older tools it's possible that older versions and new versions start 
running simultaneously and get mixed up in a way that is not immediately 
apparent.

--
Joost

Re: [gentoo-user] udev + /usr

[Canek Peláez Valdés]

On Thu, Sep 15, 2011 at 5:30 PM, Joost Roeleveld <joost@antarean.org> wrote:
> On Thursday, September 15, 2011 03:04:37 PM Canek Peláez Valdés wrote:
>> On Thu, Sep 15, 2011 at 1:59 PM, Mick <michaelkintzios@gmail.com> wrote:
>> > On Thursday 15 Sep 2011 16:13:26 Michael Schreckenbauer wrote:
>> > 1.  The minimal initramfs will only need to be built once (and rarely
>> > rebuilt thereafter).  This removes one of my fears and it was a main
>> > objection for me - I would hate to have to rebuild initramfs every time
>> > I roll a new kernel, or libs and what not of fs happen to be udpated,
>> > etc.
>>
>> In my experience, it takes more time to build the kernel than it takes
>> to rebuild the initramfs. And if you choose to use dracut, the process
>> is automatic (you always call dracut with the same options, unless you
>> suddenly add LVM or something similar).
>
> Canek, as you've been using dracut already extensively, is it possible to set
> default options/modules/whatever to get to the situation where simply running
> "dracut" without any extra options will always recreate the correct initramfs?

The modules get defined by the DRACUT_MODULES variable, which is
use-expanded. The options are configured in /etc/dracut.conf, but I
believe there are some command line options not configurable.

>> I didn't use an initramfs for my first years using Gentoo. Since I
>> started to use media-gfx/splashutils a couple of years ago, every time
>> I upgraded my kernel, I splash_geninitramfs'd my initramfs. Now I do
>> the same, but with plymouth and systemd using dracut. It's just part
>> of the process of getting a new kernel.
>
> And, if the initramfs has other tools in it, after every emerge of these
> tools. This is where I see a possible cause for failure as then the situation
> arises where the initramfs will still start "correctly", but because it's
> using older tools it's possible that older versions and new versions start
> running simultaneously and get mixed up in a way that is not immediately
> apparent.

I see it the other way around: you ensure that your initramfs is in
sync with your system. In other words: the initramfs contains a subset
of your normal installation. That is why it makes redundant /lib,
/sbin and /bin.

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

Re: [gentoo-user] udev + /usr

[Joost Roeleveld]

On Thursday, September 15, 2011 05:38:41 PM Canek Peláez Valdés wrote:
> On Thu, Sep 15, 2011 at 5:30 PM, Joost Roeleveld <joost@antarean.org> wrote:
> > On Thursday, September 15, 2011 03:04:37 PM Canek Peláez Valdés wrote:
> >> On Thu, Sep 15, 2011 at 1:59 PM, Mick <michaelkintzios@gmail.com> wrote:
> >> > On Thursday 15 Sep 2011 16:13:26 Michael Schreckenbauer wrote:
> >> > 1.  The minimal initramfs will only need to be built once (and
> >> > rarely
> >> > rebuilt thereafter).  This removes one of my fears and it was a
> >> > main
> >> > objection for me - I would hate to have to rebuild initramfs every
> >> > time I roll a new kernel, or libs and what not of fs happen to be
> >> > udpated, etc.
> >> 
> >> In my experience, it takes more time to build the kernel than it takes
> >> to rebuild the initramfs. And if you choose to use dracut, the process
> >> is automatic (you always call dracut with the same options, unless you
> >> suddenly add LVM or something similar).
> > 
> > Canek, as you've been using dracut already extensively, is it possible
> > to set default options/modules/whatever to get to the situation where
> > simply running "dracut" without any extra options will always recreate
> > the correct initramfs?
> The modules get defined by the DRACUT_MODULES variable, which is
> use-expanded. The options are configured in /etc/dracut.conf, but I
> believe there are some command line options not configurable.

The developers suggested I try dracut and I do intend to do that.
My problem is, the one most likely affected by this is also the one I want to 
experiment the least with. Guess I'll have to test this inside a VM.

> >> I didn't use an initramfs for my first years using Gentoo. Since I
> >> started to use media-gfx/splashutils a couple of years ago, every time
> >> I upgraded my kernel, I splash_geninitramfs'd my initramfs. Now I do
> >> the same, but with plymouth and systemd using dracut. It's just part
> >> of the process of getting a new kernel.
> > 
> > And, if the initramfs has other tools in it, after every emerge of these
> > tools. This is where I see a possible cause for failure as then the
> > situation arises where the initramfs will still start "correctly", but
> > because it's using older tools it's possible that older versions and
> > new versions start running simultaneously and get mixed up in a way
> > that is not immediately apparent.
> 
> I see it the other way around: you ensure that your initramfs is in
> sync with your system. In other words: the initramfs contains a subset
> of your normal installation. That is why it makes redundant /lib,
> /sbin and /bin.

The reason I ditched lilo when grub came out was because I always would forget 
to run the lilo-command. (Another was that lilo wouldn't work on a new 
machine, but that's not important)
The same will be true for dracut. And probably not just for me.

The on-disk-format may stay the same and the tools (am thinking LVM here) 
should always be able to find my filesystems. But, what if the initramfs does 
the fsck with older tools?

Currently, the fsck runs before actually mounting the filesystems. If the 
filesystems end up being pre-mounted, when will fsck run and which version?

--
Joost

Re: [gentoo-user] udev + /usr

[Pandu Poluan]

[-- Attachment #1: Type: text/plain, Size: 1341 bytes --]

On Sep 16, 2011 4:03 PM, "Joost Roeleveld" <joost@antarean.org> wrote:
>
> On Thursday, September 15, 2011 05:38:41 PM Canek Peláez Valdés wrote:
> >
[--major snippage--]
> > I see it the other way around: you ensure that your initramfs is in
> > sync with your system. In other words: the initramfs contains a subset
> > of your normal installation. That is why it makes redundant /lib,
> > /sbin and /bin.
>
> The reason I ditched lilo when grub came out was because I always would
forget
> to run the lilo-command. (Another was that lilo wouldn't work on a new
> machine, but that's not important)
> The same will be true for dracut. And probably not just for me.
>
> The on-disk-format may stay the same and the tools (am thinking LVM here)
> should always be able to find my filesystems. But, what if the initramfs
does
> the fsck with older tools?
>
> Currently, the fsck runs before actually mounting the filesystems. If the
> filesystems end up being pre-mounted, when will fsck run and which
version?
>

Speaking of fsck, didn't someone lamented the fact that fsck can no longer
be statically linked, thus making initr* 'blew up' in size?

When more and more utilities go the non-statically-linked way...
congratulations! You now have an initr* that's practically a cpio-ized
version of /

Rgds,

[-- Attachment #2: Type: text/html, Size: 1606 bytes --]

Re: [gentoo-user] udev + /usr

[Canek Peláez Valdés]

On Fri, Sep 16, 2011 at 5:29 AM, Pandu Poluan <pandu@poluan.info> wrote:
>
> On Sep 16, 2011 4:03 PM, "Joost Roeleveld" <joost@antarean.org> wrote:
>>
>> On Thursday, September 15, 2011 05:38:41 PM Canek Peláez Valdés wrote:
>> >
> [--major snippage--]
>> > I see it the other way around: you ensure that your initramfs is in
>> > sync with your system. In other words: the initramfs contains a subset
>> > of your normal installation. That is why it makes redundant /lib,
>> > /sbin and /bin.
>>
>> The reason I ditched lilo when grub came out was because I always would
>> forget
>> to run the lilo-command. (Another was that lilo wouldn't work on a new
>> machine, but that's not important)
>> The same will be true for dracut. And probably not just for me.
>>
>> The on-disk-format may stay the same and the tools (am thinking LVM here)
>> should always be able to find my filesystems. But, what if the initramfs
>> does
>> the fsck with older tools?
>>
>> Currently, the fsck runs before actually mounting the filesystems. If the
>> filesystems end up being pre-mounted, when will fsck run and which
>> version?
>>
>
> Speaking of fsck, didn't someone lamented the fact that fsck can no longer
> be statically linked, thus making initr* 'blew up' in size?
>
> When more and more utilities go the non-statically-linked way...
> congratulations! You now have an initr* that's practically a cpio-ized
> version of /

Now, common: that's an exaggeration. My dracut generated initramfs
(with systemd, plymouth, udev, and I don't remember what many things
more) is 5 Mb. That's a little less than my several-gigabytes /.

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

Re: [gentoo-user] udev + /usr

[Dale]

Canek Peláez Valdés wrote:
> On Fri, Sep 16, 2011 at 5:29 AM, Pandu Poluan<pandu@poluan.info>  wrote:
>> Speaking of fsck, didn't someone lamented the fact that fsck can no longer
>> be statically linked, thus making initr* 'blew up' in size?
>>
>> When more and more utilities go the non-statically-linked way...
>> congratulations! You now have an initr* that's practically a cpio-ized
>> version of /
> Now, common: that's an exaggeration. My dracut generated initramfs
> (with systemd, plymouth, udev, and I don't remember what many things
> more) is 5 Mb. That's a little less than my several-gigabytes /.
>
> Regards.

Give it time.  Something will need /home on the root partition next.  
Like someone else posted, we are headed towards windows land with this.  
I won't be surprised if /boot will have to be on / next too.

Dale

:-)  :-)

Re: [gentoo-user] udev + /usr

[Canek Peláez Valdés]

On Fri, Sep 16, 2011 at 11:57 AM, Dale <rdalek1967@gmail.com> wrote:
> Canek Peláez Valdés wrote:
>>
>> On Fri, Sep 16, 2011 at 5:29 AM, Pandu Poluan<pandu@poluan.info>  wrote:
>>>
>>> Speaking of fsck, didn't someone lamented the fact that fsck can no
>>> longer
>>> be statically linked, thus making initr* 'blew up' in size?
>>>
>>> When more and more utilities go the non-statically-linked way...
>>> congratulations! You now have an initr* that's practically a cpio-ized
>>> version of /
>>
>> Now, common: that's an exaggeration. My dracut generated initramfs
>> (with systemd, plymouth, udev, and I don't remember what many things
>> more) is 5 Mb. That's a little less than my several-gigabytes /.
>>
>> Regards.
>
> Give it time.  Something will need /home on the root partition next.  Like
> someone else posted, we are headed towards windows land with this.  I won't
> be surprised if /boot will have to be on / next too.

I think I know what I am talking about when I say this:

The sky is, in fact, not falling.

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

Re: [gentoo-user] udev + /usr

[Mark Knecht]

On Fri, Sep 16, 2011 at 8:57 AM, Dale <rdalek1967@gmail.com> wrote:
> Canek Peláez Valdés wrote:
>>
>> On Fri, Sep 16, 2011 at 5:29 AM, Pandu Poluan<pandu@poluan.info>  wrote:
>>>
>>> Speaking of fsck, didn't someone lamented the fact that fsck can no
>>> longer
>>> be statically linked, thus making initr* 'blew up' in size?
>>>
>>> When more and more utilities go the non-statically-linked way...
>>> congratulations! You now have an initr* that's practically a cpio-ized
>>> version of /
>>
>> Now, common: that's an exaggeration. My dracut generated initramfs
>> (with systemd, plymouth, udev, and I don't remember what many things
>> more) is 5 Mb. That's a little less than my several-gigabytes /.
>>
>> Regards.
>
> Give it time.  Something will need /home on the root partition next.  Like
> someone else posted, we are headed towards windows land with this.  I won't
> be surprised if /boot will have to be on / next too.
>
> Dale

Not the case IMO. My read of all this stuff is that within a few
months we'll be back to allowing /usr to be anywhere without an
initramfs or initramfs generated automagically such that you hardly
know it's there.

While I'm no expert on initramfs technology, it's not large. Mine is
only a bit larger than 2MB. Likely it doesn't contain whatever is
required to deal with systemd/udev but it's not like it's much disk
space...

c2stable ~ # ls -al /boot/my-initramfs.cpio.gz
-rw-r--r-- 1 root root 2296212 Jan  1  2011 /boot/my-initramfs.cpio.gz
c2stable ~ #

- Mark

Re: [gentoo-user] udev + /usr

[Dale]

Mark Knecht wrote:
> On Fri, Sep 16, 2011 at 8:57 AM, Dale<rdalek1967@gmail.com>  wrote:
>> Canek Peláez Valdés wrote:
>>> On Fri, Sep 16, 2011 at 5:29 AM, Pandu Poluan<pandu@poluan.info>    wrote:
>>>> Speaking of fsck, didn't someone lamented the fact that fsck can no
>>>> longer
>>>> be statically linked, thus making initr* 'blew up' in size?
>>>>
>>>> When more and more utilities go the non-statically-linked way...
>>>> congratulations! You now have an initr* that's practically a cpio-ized
>>>> version of /
>>> Now, common: that's an exaggeration. My dracut generated initramfs
>>> (with systemd, plymouth, udev, and I don't remember what many things
>>> more) is 5 Mb. That's a little less than my several-gigabytes /.
>>>
>>> Regards.
>> Give it time.  Something will need /home on the root partition next.  Like
>> someone else posted, we are headed towards windows land with this.  I won't
>> be surprised if /boot will have to be on / next too.
>>
>> Dale
> Not the case IMO. My read of all this stuff is that within a few
> months we'll be back to allowing /usr to be anywhere without an
> initramfs or initramfs generated automagically such that you hardly
> know it's there.
>
> While I'm no expert on initramfs technology, it's not large. Mine is
> only a bit larger than 2MB. Likely it doesn't contain whatever is
> required to deal with systemd/udev but it's not like it's much disk
> space...
>
> c2stable ~ # ls -al /boot/my-initramfs.cpio.gz
> -rw-r--r-- 1 root root 2296212 Jan  1  2011 /boot/my-initramfs.cpio.gz
> c2stable ~ #
>
> - Mark
>
>

I hope you are right about sanity returning.  I have been wrong before 
but I have also been right too.  I picture this going bad for a lot of 
people and the dev getting a lot of emails about it.  Someone is going 
to try rebooting and have a jaw dropping experience.  One that comes to 
mind is hal but there are others that went south too.

Dale

:-)  :-)

Re: [gentoo-user] udev + /usr

[Pandu Poluan]

[-- Attachment #1: Type: text/plain, Size: 1185 bytes --]

On Sep 16, 2011 11:00 PM, "Dale" <rdalek1967@gmail.com> wrote:
>
> Canek Peláez Valdés wrote:
>>
>> On Fri, Sep 16, 2011 at 5:29 AM, Pandu Poluan<pandu@poluan.info>  wrote:
>>>
>>> Speaking of fsck, didn't someone lamented the fact that fsck can no
longer
>>>
>>> be statically linked, thus making initr* 'blew up' in size?
>>>
>>> When more and more utilities go the non-statically-linked way...
>>> congratulations! You now have an initr* that's practically a cpio-ized
>>> version of /
>>
>> Now, common: that's an exaggeration. My dracut generated initramfs
>> (with systemd, plymouth, udev, and I don't remember what many things
>> more) is 5 Mb. That's a little less than my several-gigabytes /.
>>
>> Regards.
>
>
> Give it time.  Something will need /home on the root partition next.  Like
someone else posted, we are headed towards windows land with this.  I won't
be surprised if /boot will have to be on / next too.
>

Heh. If it's only limited to 'everything in /' it's still acceptable. MIGHTY
annoying, and most likely an admin hell, but workable.

Now, if everything needs to go into initr* (yes, I'm exaggerating, but...)
...

Rgds,

[-- Attachment #2: Type: text/html, Size: 1603 bytes --]

Re: [gentoo-user] udev + /usr

[Joost Roeleveld]

On Friday, September 16, 2011 11:21:12 PM Pandu Poluan wrote:
> On Sep 16, 2011 11:00 PM, "Dale" <rdalek1967@gmail.com> wrote:
> > Canek Peláez Valdés wrote:
> >> On Fri, Sep 16, 2011 at 5:29 AM, Pandu Poluan<pandu@poluan.info>  wrote:
> >>> Speaking of fsck, didn't someone lamented the fact that fsck can no
> 
> longer
> 
> >>> be statically linked, thus making initr* 'blew up' in size?
> >>> 
> >>> When more and more utilities go the non-statically-linked way...
> >>> congratulations! You now have an initr* that's practically a
> >>> cpio-ized
> >>> version of /
> >> 
> >> Now, common: that's an exaggeration. My dracut generated initramfs
> >> (with systemd, plymouth, udev, and I don't remember what many things
> >> more) is 5 Mb. That's a little less than my several-gigabytes /.
> >> 
> >> Regards.
> > 
> > Give it time.  Something will need /home on the root partition next. 
> > Like
> someone else posted, we are headed towards windows land with this.  I won't
> be surprised if /boot will have to be on / next too.
> 
> 
> Heh. If it's only limited to 'everything in /' it's still acceptable. MIGHTY
> annoying, and most likely an admin hell, but workable.

Would it? :)
If there would be a filesystem that reads from the "in-memory-part" and only 
accesses the disk for write-actions, then the / can be a ramdisk... :)

> Now, if everything needs to go into initr* (yes, I'm exaggerating, but...)

Like a live-dvd?

--
Joost

Re: [gentoo-user] udev + /usr

[Carlos Hendson]

On Fri, 2011-09-16 at 10:57 -0500, Dale wrote:
> Give it time.  Something will need /home on the root partition next.  
> Like someone else posted, we are headed towards windows land with
> this.  
> I won't be surprised if /boot will have to be on / next too.
> 
> Dale
> 
> :-)  :-) 

Funnily enough, Windows 7 implements a separate boot partition from the
default system partition.  The partition is not only a boot partition
but a has rescue environment also.

How the tables are turning ... go figure.

Carlos

-- 
Sent using GNU/Linux - Perpetuate Freedom.

Re: [gentoo-user] udev + /usr

[Walter Dnes]

On Thu, Sep 15, 2011 at 06:59:44PM +0100, Mick wrote

> The only drawback is the 2 minutes it will take a user the first time this 
> change is introduced to build the initramfs and change the kernel line in 
> grub.conf.  I am warming up to this proposal because it seems to me that it 
> will end up being less painful that I originally thought.

  Good for GRUB.  But what about those of us who use lilo?

-- 
Walter Dnes <waltdnes@waltdnes.org>

Re: [gentoo-user] udev + /usr

[Canek Peláez Valdés]

On Thu, Sep 15, 2011 at 10:32 AM, Michael Mol <mikemol@gmail.com> wrote:
> On Thu, Sep 15, 2011 at 10:11 AM, Joost Roeleveld <joost@antarean.org> wrote:
>>> I'm not entirely convinced this is the case, because it feels like
>>> some situations like network devices (nbd, iSCSI) or loopback would
>>> require userland tools to bring up once networking is up.
>>
>> Yes, but the kernel-events referencing those devices won't appear untill after
>> the networking is brought up.
>> The scripts that "udev" starts are run *after* a device-event is created. If
>> the device itself has not been spotted by the kernel (for instance, the
>> networking doesn't exist yet), the event won't be triggered yet.
>>
>> This situation does not require udev to start all these tools when network-
>> devices appear.
>>
>> I hope the following would make my thoughts a bit clearer:
>>
>> 1) kernel boots
>>
>> 2) kernel detects network device and places "network-device-event" in the
>> queue
>>
>> 3) further things happen and kernel places relevant events in the queue (some
>> other events may also already be in the queue before step 2)
>>
>> 4) udev starts and starts processing the queue
>>
>> 5) For each event, udev creates the corresponding device-entry and places
>> action-entries in a queue
>>
>> 6) system-init-scripts mount all local filesystems
>>
>> 7) udev-actions starts (I made up this name)
>>
>> 8) udev-actions processes all the entries in the action-queue
>>
>> From step 4, udev will keep processing further events it gets, which means
>> that if any action taken by "udev-actions" causes further devices to become
>> available, "udev" will create the device-entries and place the action in the
>> action-queue.
>
> So, if I read this correctly, there are two classes of processing
> events. kernel events and scripted actions. Here's rough pseudocode
> describing what I think you're saying. (Or perhaps what I'm hoping
> you're saying)
>
> while(wait_for_event())
> {
>  kevent* pkEvent = NULL;
>  if(get_waiting_kernel_event(pkEvent)) // returns true if an event was waiting
>  {
>    process_kernel_event(pkEvent);
>  }
>  else
>  {
>    aevent* pAction = NULL;
>    if(get_waiting_action(pAction)) // Returns true if there's an
> action waiting.
>    {
>      process_action(pAction);
>    }
>  }
> }
>
> So, udev processes one event at a time, and always processes kernel
> events with a higher priority than resulting scripts. This makes a
> certain amount of sense; an action could launch, e.g. nbdclient, which
> would cause a new kernel event to get queued.
>
>> If anyone has a setup where /usr can not be mounted easily, it won't work
>> currently either and a init* would be necessary anyway.
>> (Am thinking of NFS, CIFS, iSCSI, NBD, special raid-drivers,.... hosting /usr
>> or other required filesystems)
>
> I don't see how this is relevant to actually fixing udev. (See below)
>
>> But anyone with a currently working environment should be able to expect a
>> currently working environment. If it fails to boot with only updating
>> versions, it's a regression. And one of the worst kinds of all.
>
> I agree that the direction udev is going is a regression. There aren't
> very many people active in this thread who would disagree with that
> point. So let's just drop it and focus on what a good, general
> solution would look like. (And anyone who says something amounting to
> 'status quo' for udev needs another explanation of why the udev
> developer sees the current scenario as broken. And he's right; the
> current scenario is architecturally unsound. I just think he's wrong
> about the solution.)

Let me throw my own guess of how they came out with the corrent
proposed solution. I repeat: is my own guess: I am not the one calling
the shots, so maybe I'm completely wrong.

As many of you guys said, there are ways of solving the problem
without requiring an initramfs. Note that if you decide to use an
initramfs, every use case works: You can have a practically empty /,
throw everything in /usr, and have /usr in another partition, maybe
even an encrypted remote NFS share. With an initramfs you can have a
separate /var, you can even have a separated /etc, mounted even by NFS
too. You can do pretty much whatever you want, because you have a full
userspace *the moment you boot*. Bluetooth, network, LVM,
crypto-filesystems: Everything is available from the instant zero.

From that perspective, the problem then is trying to support the
initramfs-less setups. Putting myself in the shoes of the developers,
the smart solution is to simply force an initramfs. KISS is to force
an initramfs, because it solves everything. The Gentoo devs are
working in a minimal initramfs that works for most "normal" usecases.
Everything else will be handled by dracut or genkernel.

An initramfs is not an initrd. And is not a binary blob coming who
knows from where; with dracut, your initramfs is simply a subset of
your normal installation, and can be as simple (just mount /usr) or as
complicated (LVM+crypto+network+NFS+whatever) as you want.

Of course you can solve it differently, for example splitting udev as
Joost proposes. But then is more code to maintain, and the number of
possible setups is suddenly the double it was before. It. Is. Not.
KISS.

It's a lot like the CUPS/lprng situation we discussed before. CUPS can
do anything that lprng does, so it makes no sense to keep support for
lprng. It's the same: with an initramfs you will be able to do
anything, so it will make no sense to keep supporting initramfs-less
systems.

That's how I see it.

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

Re: [gentoo-user] udev + /usr

[Michael Mol]

On Thu, Sep 15, 2011 at 10:57 AM, Canek Peláez Valdés <caneko@gmail.com> wrote:
> Of course you can solve it differently, for example splitting udev as
> Joost proposes. But then is more code to maintain, and the number of
> possible setups is suddenly the double it was before. It. Is. Not.
> KISS.

If you want KISS by imposing rules on the many to make
responsibilities fewer for the few, build a walled garden. Building a
safe playground has never been what Linux has been about, or what it
has been advocated or marketed as, in the ten or so years I've been
using it.

>
> It's a lot like the CUPS/lprng situation we discussed before. CUPS can
> do anything that lprng does, so it makes no sense to keep support for
> lprng. It's the same: with an initramfs you will be able to do
> anything, so it will make no sense to keep supporting initramfs-less
> systems.

While I came down on the CUPS side of that argument, udev is a very
different beast.

-- 
:wq

Re: [gentoo-user] udev + /usr

[Joost Roeleveld]

On Thursday, September 15, 2011 10:57:27 AM Canek Peláez Valdés wrote:

<snipped to keep only the email from Canek>

> Let me throw my own guess of how they came out with the corrent
> proposed solution. I repeat: is my own guess: I am not the one calling
> the shots, so maybe I'm completely wrong.

Ok and I do actually think you are correct with your guess as to why the 
developer came up with his solution.

> As many of you guys said, there are ways of solving the problem
> without requiring an initramfs. Note that if you decide to use an
> initramfs, every use case works: You can have a practically empty /,
> throw everything in /usr, and have /usr in another partition, maybe
> even an encrypted remote NFS share. With an initramfs you can have a
> separate /var, you can even have a separated /etc, mounted even by NFS
> too. You can do pretty much whatever you want, because you have a full
> userspace *the moment you boot*. Bluetooth, network, LVM,
> crypto-filesystems: Everything is available from the instant zero.

For these specific custom environments, yes, I agree. An initramfs is 
mandatory.

> From that perspective, the problem then is trying to support the
> initramfs-less setups. Putting myself in the shoes of the developers,
> the smart solution is to simply force an initramfs. KISS is to force
> an initramfs, because it solves everything. The Gentoo devs are
> working in a minimal initramfs that works for most "normal" usecases.
> Everything else will be handled by dracut or genkernel.

Initramfs is already supported. so is initramfs-less.

> An initramfs is not an initrd. And is not a binary blob coming who
> knows from where; with dracut, your initramfs is simply a subset of
> your normal installation, and can be as simple (just mount /usr) or as
> complicated (LVM+crypto+network+NFS+whatever) as you want.

I haven't looked at dracut yet, but as far as I understand, it does create an 
initramfs with the script(s), libraries and binaries needed to start whatever 
is needed to get to the stage where udev is happy. 

> Of course you can solve it differently, for example splitting udev as
> Joost proposes. But then is more code to maintain, and the number of
> possible setups is suddenly the double it was before. It. Is. Not.
> KISS.

Depends on your definition of Simple.

> It's a lot like the CUPS/lprng situation we discussed before. CUPS can
> do anything that lprng does, so it makes no sense to keep support for
> lprng. It's the same: with an initramfs you will be able to do
> anything, so it will make no sense to keep supporting initramfs-less
> systems.

The situation with Cups and lprng is different.
If either of these fail, the system will still boot and then you can spend the 
time to fix the problem.

If this change continues, an initramfs failure, will mean the system will not 
boot correctly. And when all the tools needed to fix the system are moved to 
/usr, what options are there to actually analyse and solve the problem?

In my opinion, the simplest solution will be to make the tool(s) do what 
they're supposed to do.
udev should, in my opinion, create the devices in userspace.
That it also allows for programs/scripts to be executed when a device is 
created is a nice thing to have.
Unfortunately, this leads to chicken-and-egg style problems when the scripts 
are on a filesystem that hasn't been mounted yet.

There are 3 solutions for this:
1) The easy way out: the whole user-space must be available before udev
2) udev actually includes correct error-handling for this and retries
3) udev splits this into 2 seperate tools

Option 1 is what is currenty proposed and what you appear to be in favour off.
Except, what is the point of having "udev" when the entire user-space already 
exists before it starts?
You yourself said it's nice to have everything already available from the 
beginning. But isn't the problem that udev can't start bluetoothd because 
/usr/bin/bluetoothd can't be found when /usr doesn't exist yet?

How would udev handle a situation where I have /usr on my mobile phone which 
shares the filesystem over bluetooth?

Option 2 has been suggested and rejected. And I happen to agree with this as 
it would make udev, a vital part of the system, bigger and will increase the 
chances of problems/bugs.

Option 3, which I have proposed, would actually make the first part smaller 
and simpler.
The action-handling can then be run at a later stage, when /usr is available 
and could then easier implement a retry-queue. With this being a seperate 
tool, not needed for the /dev-tree creation, failure on this should not lead 
to an unusable system.

--
Joost

Re: [gentoo-user] udev + /usr

[Neil Bothwick]

[-- Attachment #1: Type: text/plain, Size: 1175 bytes --]

On Thu, 15 Sep 2011 17:37:53 +0200, Joost Roeleveld wrote:

> There are 3 solutions for this:
> 1) The easy way out: the whole user-space must be available before udev
> 2) udev actually includes correct error-handling for this and retries
> 3) udev splits this into 2 seperate tools

4) udev remains one tool but with two modes of operation. when in
early-boot mode, it can only run a restricted set of rules - such as
those using LVM, RAID, cryptsetup, network device naming. When switched
to "full" mode later in the boot process, it loads the rest of the rules.

Which rules it runs it early-boot mode could be decided by adding a flag
to the rule to mark it acceptable for early boot usage. That way,
existing rules would automatically be deferred  unless package
maintainers update the rules for those they know will work early in the
boot process.

It saves writing/learning/debugging a new tool and gives maximum
compatibility with existing configurations.

This is pretty similar in concept to your suggestion 3, but a different
approach to its implementation.


-- 
Neil Bothwick

No, you *can't* call 999 now. I'm downloading my mail.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-user] udev + /usr

[Joost Roeleveld]

On Thursday, September 15, 2011 07:15:27 PM Neil Bothwick wrote:
> On Thu, 15 Sep 2011 17:37:53 +0200, Joost Roeleveld wrote:
> > There are 3 solutions for this:
> > 1) The easy way out: the whole user-space must be available before udev
> > 2) udev actually includes correct error-handling for this and retries
> > 3) udev splits this into 2 seperate tools
> 
> 4) udev remains one tool but with two modes of operation. when in
> early-boot mode, it can only run a restricted set of rules - such as
> those using LVM, RAID, cryptsetup, network device naming. When switched
> to "full" mode later in the boot process, it loads the rest of the rules.

Yes, I've been thinking about this option as well, after some comments on the 
gentoo-dev list.

> Which rules it runs it early-boot mode could be decided by adding a flag
> to the rule to mark it acceptable for early boot usage. That way,
> existing rules would automatically be deferred  unless package
> maintainers update the rules for those they know will work early in the
> boot process.
> 
> It saves writing/learning/debugging a new tool and gives maximum
> compatibility with existing configurations.
> 
> This is pretty similar in concept to your suggestion 3, but a different
> approach to its implementation.

And might be the "simpler" option.
Currently, I'm planning on checking if the "retry"-queue can be abused for 
this purpose.

--
Joost

Re: [gentoo-user] udev + /usr

[pk]

On 2011-09-15 16:57, Canek Peláez Valdés wrote:

> Of course you can solve it differently, for example splitting udev as
> Joost proposes. But then is more code to maintain, and the number of
> possible setups is suddenly the double it was before. It. Is. Not.
> KISS.

https://secure.wikimedia.org/wikipedia/en/wiki/Unix_philosophy

I can especially point out:
Rule of Modularity
Rule of Parsimony
Rule of Diversity

> It's a lot like the CUPS/lprng situation we discussed before. CUPS can
> do anything that lprng does, so it makes no sense to keep support for
> lprng. It's the same: with an initramfs you will be able to do
> anything, so it will make no sense to keep supporting initramfs-less
> systems.

"... one ring to rule them all..."

Best regards

Peter K

Re: [gentoo-user] udev + /usr

[Joost Roeleveld]

On Thursday, September 15, 2011 07:37:17 PM pk wrote:
> On 2011-09-15 16:57, Canek Peláez Valdés wrote:
> > Of course you can solve it differently, for example splitting udev as
> > Joost proposes. But then is more code to maintain, and the number of
> > possible setups is suddenly the double it was before. It. Is. Not.
> > KISS.
> 
> https://secure.wikimedia.org/wikipedia/en/wiki/Unix_philosophy
> 
> I can especially point out:
> Rule of Modularity
> Rule of Parsimony
> Rule of Diversity

I like those :)

> > It's a lot like the CUPS/lprng situation we discussed before. CUPS can
> > do anything that lprng does, so it makes no sense to keep support for
> > lprng. It's the same: with an initramfs you will be able to do
> > anything, so it will make no sense to keep supporting initramfs-less
> > systems.
> 
> "... one ring to rule them all..."

"...My Precious..." :)

--
Joost

Re: [gentoo-user] udev + /usr

[Sebastian Beßler]

[-- Attachment #1: Type: text/plain, Size: 580 bytes --]

Am 15.09.2011 16:57, schrieb Canek Peláez Valdés:

> with an initramfs you will be able to do anything, so it will make no
> sense to keep supporting initramfs-less systems.

With "Microsoft Windows" you will be able to do anything, so it will
make no sense to keep supporting "Microsoft Windows"-less systems.

With Gnome you will be able to do anything, so it will make no sense to
keep supporting Gnome-less systems.

With Emacs you will be able to do anything, so it will make no sense to
keep supporting Emacs-less systems.

Greetings

Sebastian Beßler


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 900 bytes --]

Re: [gentoo-user] udev + /usr

[Canek Peláez Valdés]

On Thu, Sep 15, 2011 at 4:05 PM, Sebastian Beßler
<sebastian@darkmetatron.de> wrote:
> Am 15.09.2011 16:57, schrieb Canek Peláez Valdés:
>
>> with an initramfs you will be able to do anything, so it will make no
>> sense to keep supporting initramfs-less systems.
>
> With "Microsoft Windows" you will be able to do anything, so it will
> make no sense to keep supporting "Microsoft Windows"-less systems.

Irrelevant: see the name on the list? It's called Gentoo Linux. I know
you are trying to be witty, but only shows you are comparing apples
and oranges.

> With Gnome you will be able to do anything, so it will make no sense to
> keep supporting Gnome-less systems.
>
> With Emacs you will be able to do anything, so it will make no sense to
> keep supporting Emacs-less systems.

Last time I checked, neither GNOME nor Emacs demanded that Gentoo
developers or users had to write a fork/replacement for a core
component of the system. GNOME and Emacs just need ebuilds and
adapting their configuration to Gentoo-isms. Testing and bug
reporting, as usual. The only code needed is some small patches for
both and around 200 lines of emacslisp for site-gentoo.el.

Again, not witty, just not very informed.

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

Re: [gentoo-user] udev + /usr

[Sebastian Beßler]

[-- Attachment #1: Type: text/plain, Size: 952 bytes --]

Am 15.09.2011 22:27, schrieb Canek Peláez Valdés:
> On Thu, Sep 15, 2011 at 4:05 PM, Sebastian Beßler
> <sebastian@darkmetatron.de> wrote:
>> Am 15.09.2011 16:57, schrieb Canek Peláez Valdés:
>>
>>> with an initramfs you will be able to do anything, so it will make no
>>> sense to keep supporting initramfs-less systems.
>>
>> With "Microsoft Windows" you will be able to do anything, so it will
>> make no sense to keep supporting "Microsoft Windows"-less systems.
> 
> Irrelevant: see the name on the list? It's called Gentoo Linux. I know
> you are trying to be witty, but only shows you are comparing apples
> and oranges.

No, because first it was sarcasm and second it shows that your argument
is invalid. For near to every X there is some Y that can do what X can
do, but there are still many good and valid reasons to have X. So it
will make sense to keep supporting Y-less systems.

Greetings

Sebastian Beßler


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 900 bytes --]

Re: [gentoo-user] udev + /usr

[Canek Peláez Valdés]

On Thu, Sep 15, 2011 at 4:53 PM, Sebastian Beßler
<sebastian@darkmetatron.de> wrote:
> Am 15.09.2011 22:27, schrieb Canek Peláez Valdés:
>> On Thu, Sep 15, 2011 at 4:05 PM, Sebastian Beßler
>> <sebastian@darkmetatron.de> wrote:
>>> Am 15.09.2011 16:57, schrieb Canek Peláez Valdés:
>>>
>>>> with an initramfs you will be able to do anything, so it will make no
>>>> sense to keep supporting initramfs-less systems.
>>>
>>> With "Microsoft Windows" you will be able to do anything, so it will
>>> make no sense to keep supporting "Microsoft Windows"-less systems.
>>
>> Irrelevant: see the name on the list? It's called Gentoo Linux. I know
>> you are trying to be witty, but only shows you are comparing apples
>> and oranges.
>
> No, because first it was sarcasm and second it shows that your argument
> is invalid. For near to every X there is some Y that can do what X can
> do, but there are still many good and valid reasons to have X. So it
> will make sense to keep supporting Y-less systems.

And you conveniently skipped my answer to your last two examples. No
problem, here it goes again:

"Last time I checked, neither GNOME nor Emacs demanded that Gentoo
developers or users had to write a fork/replacement for a core
component of the system. GNOME and Emacs just need ebuilds and
adapting their configuration to Gentoo-isms. Testing and bug
reporting, as usual. The only code needed is some small patches for
both and around 200 lines of emacslisp for site-gentoo.el."

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

Re: [gentoo-user] udev + /usr

[Joost Roeleveld]

On Thursday, September 15, 2011 05:05:00 PM Canek Peláez Valdés wrote:
> On Thu, Sep 15, 2011 at 4:53 PM, Sebastian Beßler
> 
> <sebastian@darkmetatron.de> wrote:
> > Am 15.09.2011 22:27, schrieb Canek Peláez Valdés:
> >> On Thu, Sep 15, 2011 at 4:05 PM, Sebastian Beßler
> >> 
> >> <sebastian@darkmetatron.de> wrote:
> >>> Am 15.09.2011 16:57, schrieb Canek Peláez Valdés:
> >>>> with an initramfs you will be able to do anything, so it will make
> >>>> no
> >>>> sense to keep supporting initramfs-less systems.
> >>> 
> >>> With "Microsoft Windows" you will be able to do anything, so it will
> >>> make no sense to keep supporting "Microsoft Windows"-less systems.
> >> 
> >> Irrelevant: see the name on the list? It's called Gentoo Linux. I know
> >> you are trying to be witty, but only shows you are comparing apples
> >> and oranges.
> > 
> > No, because first it was sarcasm and second it shows that your argument
> > is invalid. For near to every X there is some Y that can do what X can
> > do, but there are still many good and valid reasons to have X. So it
> > will make sense to keep supporting Y-less systems.
> 
> And you conveniently skipped my answer to your last two examples. No
> problem, here it goes again:
> 
> "Last time I checked, neither GNOME nor Emacs demanded that Gentoo
> developers or users had to write a fork/replacement for a core
> component of the system. GNOME and Emacs just need ebuilds and
> adapting their configuration to Gentoo-isms. Testing and bug
> reporting, as usual. The only code needed is some small patches for
> both and around 200 lines of emacslisp for site-gentoo.el."

Funny that you mention this. There might be something similar brewing for 
users of Gnome where quite a few low-level parts will end up being mandatory 
for Gnome:

"...but I'm increasingly seeing talk on the 
gnome side of the "Gnome OS", to include pulse-audio, systemd, policykit, 
udev/u* (thus forcing lvm as well, at least lvm installation tho nothing 
forces one to use it... yet, since lvm is required for udisks), etc."

It's a reply in the gentoo-dev thread I started.

Requiring pulse-audio and policykit, I can understand. But requiring a 
specific init-system for the desktop seems a bit overkill.

I'm not a gnome user and am happy with my KDE-desktop. But the same post also 
mentions KDE seems to be headed in a similar direction. Just slower.

Mind you, I do think systemd is nice and usefull on a desktop machine, but I 
don't see much need for this on a server where the sysadmins generally prefer 
to have a much more detailed control of what is happening.

Then again, I don't feel Gnome or KDE have any reason to be installed on a 
server, but that's just how I see it.

--
Joost

Re: [gentoo-user] udev + /usr

[Canek Peláez Valdés]

On Fri, Sep 16, 2011 at 5:08 AM, Joost Roeleveld <joost@antarean.org> wrote:
> On Thursday, September 15, 2011 05:05:00 PM Canek Peláez Valdés wrote:
>> On Thu, Sep 15, 2011 at 4:53 PM, Sebastian Beßler
>>
>> <sebastian@darkmetatron.de> wrote:
>> > Am 15.09.2011 22:27, schrieb Canek Peláez Valdés:
>> >> On Thu, Sep 15, 2011 at 4:05 PM, Sebastian Beßler
>> >>
>> >> <sebastian@darkmetatron.de> wrote:
>> >>> Am 15.09.2011 16:57, schrieb Canek Peláez Valdés:
>> >>>> with an initramfs you will be able to do anything, so it will make
>> >>>> no
>> >>>> sense to keep supporting initramfs-less systems.
>> >>>
>> >>> With "Microsoft Windows" you will be able to do anything, so it will
>> >>> make no sense to keep supporting "Microsoft Windows"-less systems.
>> >>
>> >> Irrelevant: see the name on the list? It's called Gentoo Linux. I know
>> >> you are trying to be witty, but only shows you are comparing apples
>> >> and oranges.
>> >
>> > No, because first it was sarcasm and second it shows that your argument
>> > is invalid. For near to every X there is some Y that can do what X can
>> > do, but there are still many good and valid reasons to have X. So it
>> > will make sense to keep supporting Y-less systems.
>>
>> And you conveniently skipped my answer to your last two examples. No
>> problem, here it goes again:
>>
>> "Last time I checked, neither GNOME nor Emacs demanded that Gentoo
>> developers or users had to write a fork/replacement for a core
>> component of the system. GNOME and Emacs just need ebuilds and
>> adapting their configuration to Gentoo-isms. Testing and bug
>> reporting, as usual. The only code needed is some small patches for
>> both and around 200 lines of emacslisp for site-gentoo.el."
>
> Funny that you mention this. There might be something similar brewing for
> users of Gnome where quite a few low-level parts will end up being mandatory
> for Gnome:
>
> "...but I'm increasingly seeing talk on the
> gnome side of the "Gnome OS", to include pulse-audio, systemd, policykit,
> udev/u* (thus forcing lvm as well, at least lvm installation tho nothing
> forces one to use it... yet, since lvm is required for udisks), etc."

I'm pretty sure the last part is false. I certainly have udisk
installet (it's pulled by gnome-disk-utility), but I don't use LVM. So
there.

> It's a reply in the gentoo-dev thread I started.
>
> Requiring pulse-audio and policykit, I can understand. But requiring a
> specific init-system for the desktop seems a bit overkill.

I don't think that will happen, although certainly is what Lennart
(and probably Kay) wants. What I think will happen is that, if
available, GNOME will use systemd. FreeBSD does not have udev, and
GNOME works there (with diminished functionality).

That's the future, I believe: you will be able to use GNOME without
systemd, but it will be like more awesomer with systemd.

> I'm not a gnome user and am happy with my KDE-desktop. But the same post also
> mentions KDE seems to be headed in a similar direction. Just slower.

Because it makes sense for the full-fledge desktop. Notice that
Gustavo Barbieri (who works a lot on e17) is a heavy promoter of
systemd. Maybe even makes sense for Xfce, but that I don't know.

At the end of the day, systemd manages how to start and stop
processes. Which is basically the task of gnome-session-manager (and
whatever is the equivalent in KDE).

> Mind you, I do think systemd is nice and usefull on a desktop machine, but I
> don't see much need for this on a server where the sysadmins generally prefer
> to have a much more detailed control of what is happening.

I think systemd gives you that in servers. With OpenRC and Apache with
user CGI scripts, ¿do you know how to list the httpd daemon spawned
processes, and only those? Remember that a CGI script can double fork.

With systemd is a matter of:

systemctl status apache-httpd.service

And you can kill every process related to a daemon, no matter how many
forks its children process make. That alone makes systemd more usefull
for servers thatn SysV+OpenRC, I think.

> Then again, I don't feel Gnome or KDE have any reason to be installed on a
> server, but that's just how I see it.

Dear evolution, of course not. Why would you install GNOME or KDE in a
server? My two servers run with systemd, and not a single GUI library
is installed in them.

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

Re: [gentoo-user] udev + /usr

[Joost Roeleveld]

On Friday, September 16, 2011 10:53:47 AM Canek Peláez Valdés wrote:
> On Fri, Sep 16, 2011 at 5:08 AM, Joost Roeleveld <joost@antarean.org> wrote:
> > On Thursday, September 15, 2011 05:05:00 PM Canek Peláez Valdés wrote:
> >> "Last time I checked, neither GNOME nor Emacs demanded that Gentoo
> >> developers or users had to write a fork/replacement for a core
> >> component of the system. GNOME and Emacs just need ebuilds and
> >> adapting their configuration to Gentoo-isms. Testing and bug
> >> reporting, as usual. The only code needed is some small patches for
> >> both and around 200 lines of emacslisp for site-gentoo.el."
> > 
> > Funny that you mention this. There might be something similar brewing
> > for
> > users of Gnome where quite a few low-level parts will end up being
> > mandatory for Gnome:
> > 
> > "...but I'm increasingly seeing talk on the
> > gnome side of the "Gnome OS", to include pulse-audio, systemd,
> > policykit,
> > udev/u* (thus forcing lvm as well, at least lvm installation tho nothing
> > forces one to use it... yet, since lvm is required for udisks), etc."
> 
> I'm pretty sure the last part is false. I certainly have udisk
> installet (it's pulled by gnome-disk-utility), but I don't use LVM. So
> there.

I don't use Gnome and haven't looked into all this. Udev also doesn't appear 
to have a LVM-useflag. But as I do use LVM, I can't actually check.
Do you have "sys-fs/lvm2" on your system?

The ebuild does list it as "RDEPEND".

> > It's a reply in the gentoo-dev thread I started.
> > 
> > Requiring pulse-audio and policykit, I can understand. But requiring a
> > specific init-system for the desktop seems a bit overkill.
> 
> I don't think that will happen, although certainly is what Lennart
> (and probably Kay) wants. What I think will happen is that, if
> available, GNOME will use systemd. FreeBSD does not have udev, and
> GNOME works there (with diminished functionality).
> 
> That's the future, I believe: you will be able to use GNOME without
> systemd, but it will be like more awesomer with systemd.

I still think Gnome (or any other desktop environment) should not care about 
which init-system is being used.

> > I'm not a gnome user and am happy with my KDE-desktop. But the same post
> > also mentions KDE seems to be headed in a similar direction. Just
> > slower.
> Because it makes sense for the full-fledge desktop. Notice that
> Gustavo Barbieri (who works a lot on e17) is a heavy promoter of
> systemd. Maybe even makes sense for Xfce, but that I don't know.
> 
> At the end of the day, systemd manages how to start and stop
> processes. Which is basically the task of gnome-session-manager (and
> whatever is the equivalent in KDE).

systemd, like any init-system, should start services.
KDE has some "kde-services" like akonadi, nepomuk,... that get controlled by 
the kde-system internally. I would NOT want to see these controlled by 
systemd.
These are running for the user that is logged in. Having these running for all 
users at once leads to the multi-user-kludge that MS Windows tries to have and 
for which Citrix was invented ontop of MS Windows....

We already have a decent multi-user environment, why would we want to kill 
that? If I wanted a single-user system, I'd be running MS Windows.

> > Mind you, I do think systemd is nice and usefull on a desktop machine,
> > but I don't see much need for this on a server where the sysadmins
> > generally prefer to have a much more detailed control of what is
> > happening.
> 
> I think systemd gives you that in servers. With OpenRC and Apache with
> user CGI scripts, ¿do you know how to list the httpd daemon spawned
> processes, and only those? Remember that a CGI script can double fork.
> 
> With systemd is a matter of:
> 
> systemctl status apache-httpd.service

Did you look at the output of pstree?
Try "pstree -pu" and you see all the PIDs and whenever there is a "user-
switch", it also lists the new user.

> And you can kill every process related to a daemon, no matter how many
> forks its children process make. That alone makes systemd more usefull
> for servers thatn SysV+OpenRC, I think.

Systemd handles this through process-groups. This can be done in different 
ways.

> > Then again, I don't feel Gnome or KDE have any reason to be installed on
> > a server, but that's just how I see it.
> 
> Dear evolution, of course not. Why would you install GNOME or KDE in a
> server? My two servers run with systemd, and not a single GUI library
> is installed in them.

I consider dbus to be part of the GUI as I don't see a reason for apache, 
syslog, nfs, samba,.... to be using dbus to communicate with each other.

There are already well-tested and working mechanisms for communication where 
needed.

--
Joost

Re: [gentoo-user] udev + /usr

[Joost Roeleveld]

On Saturday, September 17, 2011 08:45:15 AM Joost Roeleveld wrote:
> On Friday, September 16, 2011 10:53:47 AM Canek Peláez Valdés wrote:
> > I think systemd gives you that in servers. With OpenRC and Apache with
> > user CGI scripts, ¿do you know how to list the httpd daemon spawned
> > processes, and only those? Remember that a CGI script can double fork.
> > 
> > With systemd is a matter of:
> > 
> > systemctl status apache-httpd.service
> 
> Did you look at the output of pstree?
> Try "pstree -pu" and you see all the PIDs and whenever there is a "user-
> switch", it also lists the new user.
>

Had a quick look to get a more detailed list:

Specifically only for apache:
# pstree -pu `cat /var/run/apache2.pid`

"/var/run/apache2.pid" gets the PID for the parent process automatically.

With this list, I can get a more detailed picture of which process calls which 
child-process / thread and which user(s) are used for which process.

--
Joost

Re: [gentoo-user] udev + /usr

[Canek Peláez Valdés]

On Sat, Sep 17, 2011 at 3:04 AM, Joost Roeleveld <joost@antarean.org> wrote:
> On Saturday, September 17, 2011 08:45:15 AM Joost Roeleveld wrote:
>> On Friday, September 16, 2011 10:53:47 AM Canek Peláez Valdés wrote:
>> > I think systemd gives you that in servers. With OpenRC and Apache with
>> > user CGI scripts, ¿do you know how to list the httpd daemon spawned
>> > processes, and only those? Remember that a CGI script can double fork.
>> >
>> > With systemd is a matter of:
>> >
>> > systemctl status apache-httpd.service
>>
>> Did you look at the output of pstree?
>> Try "pstree -pu" and you see all the PIDs and whenever there is a "user-
>> switch", it also lists the new user.
>>
>
> Had a quick look to get a more detailed list:
>
> Specifically only for apache:
> # pstree -pu `cat /var/run/apache2.pid`
>
> "/var/run/apache2.pid" gets the PID for the parent process automatically.
>
> With this list, I can get a more detailed picture of which process calls which
> child-process / thread and which user(s) are used for which process.

Yeah, but apparently you have never had a rogue (or just poorly
written) CGI script. If inside a CGI script you do a double fork, and
kill the first child, the second child (the "grandchild" of apache)
will get reattached to PID 1. This is the POSIX defined behaviour.

But then your pstree -pu $(cat /var/run/apache2.pid) doesn't work.

Again, with cgroups (and without systemd) you can handle it. But then
you need to do it manually for every daemon in the system. systemd
allows you to do it for you.

And it will be the same with user sessions, because is (for all that
matters) the same problem. Your desktop session will have its own
cgroup, and every application run by the user will be a subgroup of
the session group.

With systemd, my slow laptop boots from GRUB2 to GDM in 15 seconds.
That's almost three times better than with OpenRC. But from GDM to
full started desktop (before lauching applications) it takes almost 45
seconds. If I get to shave 15 seconds of it (and I am sure it will be
more) by using systemd --user, I will be a really, really happy man.

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

Re: [gentoo-user] udev + /usr

[Alan McKinnon]

On Sat, 17 Sep 2011 08:45:15 +0200
Joost Roeleveld <joost@antarean.org> wrote:

> I consider dbus to be part of the GUI as I don't see a reason for
> apache, syslog, nfs, samba,.... to be using dbus to communicate with
> each other.

To be fair, dbus could be useful for service apps too. It provides a
standard message bus that everything can understand, it's small, light,
with a clearly defined focus and even better, could be entirely
optional.


-- 
Alan McKinnnon
alan.mckinnon@gmail.com

Re: [gentoo-user] udev + /usr

[Canek Peláez Valdés]

On Sat, Sep 17, 2011 at 2:45 AM, Joost Roeleveld <joost@antarean.org> wrote:
> On Friday, September 16, 2011 10:53:47 AM Canek Peláez Valdés wrote:
>> On Fri, Sep 16, 2011 at 5:08 AM, Joost Roeleveld <joost@antarean.org> wrote:
>> > On Thursday, September 15, 2011 05:05:00 PM Canek Peláez Valdés wrote:
>> >> "Last time I checked, neither GNOME nor Emacs demanded that Gentoo
>> >> developers or users had to write a fork/replacement for a core
>> >> component of the system. GNOME and Emacs just need ebuilds and
>> >> adapting their configuration to Gentoo-isms. Testing and bug
>> >> reporting, as usual. The only code needed is some small patches for
>> >> both and around 200 lines of emacslisp for site-gentoo.el."
>> >
>> > Funny that you mention this. There might be something similar brewing
>> > for
>> > users of Gnome where quite a few low-level parts will end up being
>> > mandatory for Gnome:
>> >
>> > "...but I'm increasingly seeing talk on the
>> > gnome side of the "Gnome OS", to include pulse-audio, systemd,
>> > policykit,
>> > udev/u* (thus forcing lvm as well, at least lvm installation tho nothing
>> > forces one to use it... yet, since lvm is required for udisks), etc."
>>
>> I'm pretty sure the last part is false. I certainly have udisk
>> installet (it's pulled by gnome-disk-utility), but I don't use LVM. So
>> there.
>
> I don't use Gnome and haven't looked into all this. Udev also doesn't appear
> to have a LVM-useflag. But as I do use LVM, I can't actually check.
> Do you have "sys-fs/lvm2" on your system?
>
> The ebuild does list it as "RDEPEND".

Yes, I got it installed. I didn't noticed until now. Then again, it
takes 1 minute to install in my puny laptop, and uses 7 Mb of hard
drive. But anyhow, I was mistaken: it is forced by udisks.

>> > It's a reply in the gentoo-dev thread I started.
>> >
>> > Requiring pulse-audio and policykit, I can understand. But requiring a
>> > specific init-system for the desktop seems a bit overkill.
>>
>> I don't think that will happen, although certainly is what Lennart
>> (and probably Kay) wants. What I think will happen is that, if
>> available, GNOME will use systemd. FreeBSD does not have udev, and
>> GNOME works there (with diminished functionality).
>>
>> That's the future, I believe: you will be able to use GNOME without
>> systemd, but it will be like more awesomer with systemd.
>
> I still think Gnome (or any other desktop environment) should not care about
> which init-system is being used.

And they will not. They will only use some capabilities that a system
provides, and use it if available. It's the exact same thing as udev.

>> > I'm not a gnome user and am happy with my KDE-desktop. But the same post
>> > also mentions KDE seems to be headed in a similar direction. Just
>> > slower.
>> Because it makes sense for the full-fledge desktop. Notice that
>> Gustavo Barbieri (who works a lot on e17) is a heavy promoter of
>> systemd. Maybe even makes sense for Xfce, but that I don't know.
>>
>> At the end of the day, systemd manages how to start and stop
>> processes. Which is basically the task of gnome-session-manager (and
>> whatever is the equivalent in KDE).
>
> systemd, like any init-system, should start services.
> KDE has some "kde-services" like akonadi, nepomuk,... that get controlled by
> the kde-system internally. I would NOT want to see these controlled by
> systemd.

It would be a different process from PID 1. systemd call be called
with --user: every user will get it's own instance (replacing what now
is controlled by gnome-session-manager and [I presume] kde-system),
but that instance will be able to use all the plumbing that systemd
provides.

> These are running for the user that is logged in. Having these running for all
> users at once leads to the multi-user-kludge that MS Windows tries to have and
> for which Citrix was invented ontop of MS Windows....

As I explained, it will be an instance per user. Nothing like Windows.

> We already have a decent multi-user environment, why would we want to kill
> that? If I wanted a single-user system, I'd be running MS Windows.

See above, you are wrong on how systemd will handle it.

>> > Mind you, I do think systemd is nice and usefull on a desktop machine,
>> > but I don't see much need for this on a server where the sysadmins
>> > generally prefer to have a much more detailed control of what is
>> > happening.
>>
>> I think systemd gives you that in servers. With OpenRC and Apache with
>> user CGI scripts, ¿do you know how to list the httpd daemon spawned
>> processes, and only those? Remember that a CGI script can double fork.
>>
>> With systemd is a matter of:
>>
>> systemctl status apache-httpd.service
>
> Did you look at the output of pstree?
> Try "pstree -pu" and you see all the PIDs and whenever there is a "user-
> switch", it also lists the new user.

Yeah, and I specifically said: "do you know how to list the httpd
daemon spawned processes, **and only those**?" (emphasis mine). pstree
(or ps) will show the processes with **user** apache, not those
spawned by httpd.

>> And you can kill every process related to a daemon, no matter how many
>> forks its children process make. That alone makes systemd more usefull
>> for servers thatn SysV+OpenRC, I think.
>
> Systemd handles this through process-groups. This can be done in different
> ways.

Of course it can. Only systemd does it for you, including setting OOM
score, IO scheduling, CPU scheduling, permissions. Everything can be
done manually; and it will be possible to do it manually with systemd
also.

But you can manage all of that in a single well documented way using systemd.

>> > Then again, I don't feel Gnome or KDE have any reason to be installed on
>> > a server, but that's just how I see it.
>>
>> Dear evolution, of course not. Why would you install GNOME or KDE in a
>> server? My two servers run with systemd, and not a single GUI library
>> is installed in them.
>
> I consider dbus to be part of the GUI as I don't see a reason for apache,
> syslog, nfs, samba,.... to be using dbus to communicate with each other.

a) dbus is not part of the GUI, b) like it or not, it's the
standardized IPC mechanism in Linux. If it's available, let's use it.

> There are already well-tested and working mechanisms for communication where
> needed.

I would like for you to be more specific about them.

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

Re: [gentoo-user] udev + /usr

[Michael Mol]

On Sat, Sep 17, 2011 at 10:50 AM, Canek Peláez Valdés <caneko@gmail.com> wrote:
> On Sat, Sep 17, 2011 at 2:45 AM, Joost Roeleveld <joost@antarean.org> wrote:
[[snippage]]
>> I still think Gnome (or any other desktop environment) should not care about
>> which init-system is being used.
>
> And they will not. They will only use some capabilities that a system
> provides, and use it if available. It's the exact same thing as udev.
>

[[snippage]]

> a) dbus is not part of the GUI, b) like it or not, it's the
> standardized IPC mechanism in Linux. If it's available, let's use it.

This is exactly the same attitude of convenience that led to udev
being abused, and then to the very decisions by udev's maintainer that
started off the firestorm on this list over the last couple weeks. The
system is *bloating* at an incredible rate.

>
>> There are already well-tested and working mechanisms for communication where
>> needed.
>
> I would like for you to be more specific about them.

Sockets, be they UNIX domain sockets, IPv4 or IPv6.
* Very common, very stable, very standard interface.
* IPv4 sockets exist on every major operating system.
* The sockets API has a common, portable C-level API going back to the
1980s, thanks to BSD 4.2.
* IP sockets support multicast, both host-local and as part of networking.
* Protocols implemented on top of IP make up the largest continual IPC
environment in existence...the Internet itself.
* IP sockets may have ACLs applied by kernel firewall rules.
* UNIX domain sockets get the full benefit of filesystem ACLs.

Shared memory:
* Exists in various forms.

Pipes:
* Exist in named and anonymous forms.
* If you use the command-line much, you might use them so much you've
taken them for granted.
* Some platforms support opening named pipes on remote systems. (I
know Windows can do this. I don't know about Linux.)
* 'nc' makes for an incredibly simple adapter to work with IP sockets.

Not sure what others there are, but those have existed longer than
I've been alive, and been standard since the early 1990s. Progress is
adding new functionality, not reimplementing existing functionality as
new APIs on top of the existing functionality. That's little better
than busywork for people who could be building something actually new.

-- 
:wq

Re: [gentoo-user] udev + /usr

[Canek Peláez Valdés]

On Sat, Sep 17, 2011 at 11:41 AM, Michael Mol <mikemol@gmail.com> wrote:
> On Sat, Sep 17, 2011 at 10:50 AM, Canek Peláez Valdés <caneko@gmail.com> wrote:
>> On Sat, Sep 17, 2011 at 2:45 AM, Joost Roeleveld <joost@antarean.org> wrote:
> [[snippage]]
>>> I still think Gnome (or any other desktop environment) should not care about
>>> which init-system is being used.
>>
>> And they will not. They will only use some capabilities that a system
>> provides, and use it if available. It's the exact same thing as udev.
>>
>
> [[snippage]]
>
>> a) dbus is not part of the GUI, b) like it or not, it's the
>> standardized IPC mechanism in Linux. If it's available, let's use it.
>
> This is exactly the same attitude of convenience that led to udev
> being abused, and then to the very decisions by udev's maintainer that
> started off the firestorm on this list over the last couple weeks. The
> system is *bloating* at an incredible rate.
>
>>
>>> There are already well-tested and working mechanisms for communication where
>>> needed.
>>
>> I would like for you to be more specific about them.
>
> Sockets, be they UNIX domain sockets, IPv4 or IPv6.
[snip]
> Shared memory:
[snip]
> Pipes:
[snip]

Yeah, but then you need to design, implement and debug a protocol
communication: what part of the wire speaks first, what does it says,
what are the valid responses, etc.

And then, if other component wants to communicate, it has to learn
your little protocol. dbus standardize this. And it uses sockets,
shared memory and pipes as building blocks, I believe,

> Not sure what others there are, but those have existed longer than
> I've been alive, and been standard since the early 1990s.

They are standard in the sense that they are a low level communication
standard API. An IPC is *way* more than that;  dbus is an IPC, because
then you have high level "objects" and "methods", no matter the
language of the two sides of the wire communicating, or even if the
objects live in the same computer or not.

BTW, there *was* an standard that did everything dbus does: ORB, the
Object Request Broker. They tried to use that as IPC years ago, but is
so damn complicated to implement right they decided to better
implement a new standard. The standard is dbus.

> Progress is
> adding new functionality, not reimplementing existing functionality as
> new APIs on top of the existing functionality.

I think you are wrong if you believe that dbus is just "existing
functionality as new APIs on top of the existing functionality". dbus
is a complete IPC system. Neither sockets, shared memory nor pipes are
an IPC, because they lack a well defined protocol. You *can* do the
same you do with dbus if you only use sockets/sharedmem/pipes, but
then you need to do it over and over and over again. Is like the
difference between assembler and C: you *can* do the same with both,
but that does not mean that is actually a good idea to only use
assembler.

> That's little better
> than busywork for people who could be building something actually new.

dbus offers new functionality, like I said.

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

Re: [gentoo-user] udev + /usr

[Michael Mol]

On Sat, Sep 17, 2011 at 2:36 PM, Canek Peláez Valdés <caneko@gmail.com> wrote:
> On Sat, Sep 17, 2011 at 11:41 AM, Michael Mol <mikemol@gmail.com> wrote:
>> On Sat, Sep 17, 2011 at 10:50 AM, Canek Peláez Valdés >>> I would like for you to be more specific about them.
>>
>> Sockets, be they UNIX domain sockets, IPv4 or IPv6.
> [snip]
>> Shared memory:
> [snip]
>> Pipes:
> [snip]
>
> Yeah, but then you need to design, implement and debug a protocol
> communication: what part of the wire speaks first, what does it says,
> what are the valid responses, etc.
>
> And then, if other component wants to communicate, it has to learn
> your little protocol. dbus standardize this. And it uses sockets,
> shared memory and pipes as building blocks, I believe,

Reasonable points, all, up to the term 'standardize'. How stable is the API?

Apart from our discussions of dbus from a few weeks ago, that's most
of what I know about it, quoted from the gpsd man page:

USE WITH D-BUS
       On operating systems that support D-BUS, gpsd can be built to broadcast
       GPS fixes to D-BUS-aware applications. As D-BUS is still at a pre-1.0
       stage, we will not attempt to document this interface here. Read the gpsd
       source code to learn more.

>
>> Not sure what others there are, but those have existed longer than
>> I've been alive, and been standard since the early 1990s.
>
> They are standard in the sense that they are a low level communication
> standard API. An IPC is *way* more than that;  dbus is an IPC, because
> then you have high level "objects" and "methods", no matter the
> language of the two sides of the wire communicating, or even if the
> objects live in the same computer or not.
>
> BTW, there *was* an standard that did everything dbus does: ORB, the
> Object Request Broker. They tried to use that as IPC years ago, but is
> so damn complicated to implement right they decided to better
> implement a new standard. The standard is dbus.

Interesting. I'd heard of ORB, even tried to play with it a bit, but
the documentation I've found is terrible. Like a number of fields I've
poked at, if you wan to understand how to do something, you have to do
it, making for a tricky.

That said, who is They, and who decided that The standard is D-Bus?

>
>> Progress is
>> adding new functionality, not reimplementing existing functionality as
>> new APIs on top of the existing functionality.
>
> I think you are wrong if you believe that dbus is just "existing
> functionality as new APIs on top of the existing functionality". dbus
> is a complete IPC system. Neither sockets, shared memory nor pipes are
> an IPC, because they lack a well defined protocol. You *can* do the
> same you do with dbus if you only use sockets/sharedmem/pipes, but
> then you need to do it over and over and over again. Is like the
> difference between assembler and C: you *can* do the same with both,
> but that does not mean that is actually a good idea to only use
> assembler.

I take (and even accept) your points on D-Bus having more
functionality than the three other IPC mechanisms I described.

That said, I disagree that D-Bus is an inter-process control
mechansim, but sockets, shm and pipes are not. To draw from networking
terminology, sockets, shm and pipes could be seen as being on layers 2
and/or 3 of the OSI stack (shm and unix domain sockets being a
definite layer 2, IP sockets being layer 3), and D-Bus represents a
mixture of layers 3-5.

An application may choose to use only layers 2-3 for IPC, or it may
choose to use D-Bus.

-- 
:wq

Re: [gentoo-user] udev + /usr

[Canek Peláez Valdés]

On Sat, Sep 17, 2011 at 3:24 PM, Michael Mol <mikemol@gmail.com> wrote:
> On Sat, Sep 17, 2011 at 2:36 PM, Canek Peláez Valdés <caneko@gmail.com> wrote:
>> On Sat, Sep 17, 2011 at 11:41 AM, Michael Mol <mikemol@gmail.com> wrote:
>>> On Sat, Sep 17, 2011 at 10:50 AM, Canek Peláez Valdés >>> I would like for you to be more specific about them.
>>>
>>> Sockets, be they UNIX domain sockets, IPv4 or IPv6.
>> [snip]
>>> Shared memory:
>> [snip]
>>> Pipes:
>> [snip]
>>
>> Yeah, but then you need to design, implement and debug a protocol
>> communication: what part of the wire speaks first, what does it says,
>> what are the valid responses, etc.
>>
>> And then, if other component wants to communicate, it has to learn
>> your little protocol. dbus standardize this. And it uses sockets,
>> shared memory and pipes as building blocks, I believe,
>
> Reasonable points, all, up to the term 'standardize'. How stable is the API?

Between major releases, pretty stable. And new releases usually add
functionality; I haven't used that much dbus, but I don't think the
developers had deprecated much.

> Apart from our discussions of dbus from a few weeks ago, that's most
> of what I know about it, quoted from the gpsd man page:
>
> USE WITH D-BUS
>       On operating systems that support D-BUS, gpsd can be built to broadcast
>       GPS fixes to D-BUS-aware applications. As D-BUS is still at a pre-1.0
>       stage, we will not attempt to document this interface here. Read the gpsd
>       source code to learn more.

That's old, obviously. I have dbus 1.4.12, pretty much "post-1.0".
gpsd should update its documentation.

>>
>>> Not sure what others there are, but those have existed longer than
>>> I've been alive, and been standard since the early 1990s.
>>
>> They are standard in the sense that they are a low level communication
>> standard API. An IPC is *way* more than that;  dbus is an IPC, because
>> then you have high level "objects" and "methods", no matter the
>> language of the two sides of the wire communicating, or even if the
>> objects live in the same computer or not.
>>
>> BTW, there *was* an standard that did everything dbus does: ORB, the
>> Object Request Broker. They tried to use that as IPC years ago, but is
>> so damn complicated to implement right they decided to better
>> implement a new standard. The standard is dbus.
>
> Interesting. I'd heard of ORB, even tried to play with it a bit, but
> the documentation I've found is terrible. Like a number of fields I've
> poked at, if you wan to understand how to do something, you have to do
> it, making for a tricky.

ORBit was the GNOME implementation of ORB; I don't remember what KDE
used, but I believe it was also ORB based.

> That said, who is They, and who decided that The standard is D-Bus?

The desktop developers. They needed an IPC (because, even if you don't
agree, sockets/shrmem/pipes is not an IPC), and they settled on dbus,
hosted in freedesktop. Almost everybody else then jumped on dbus,
because is light, it works, and is an standard. From
http://dbus.freedesktop.org:

"D-Bus is a message bus system, a simple way for applications to talk
to one another. In addition to interprocess communication, D-Bus helps
coordinate process lifecycle; it makes it simple and reliable to code
a "single instance" application or daemon, and to launch applications
and daemons on demand when their services are needed."

>>
>>> Progress is
>>> adding new functionality, not reimplementing existing functionality as
>>> new APIs on top of the existing functionality.
>>
>> I think you are wrong if you believe that dbus is just "existing
>> functionality as new APIs on top of the existing functionality". dbus
>> is a complete IPC system. Neither sockets, shared memory nor pipes are
>> an IPC, because they lack a well defined protocol. You *can* do the
>> same you do with dbus if you only use sockets/sharedmem/pipes, but
>> then you need to do it over and over and over again. Is like the
>> difference between assembler and C: you *can* do the same with both,
>> but that does not mean that is actually a good idea to only use
>> assembler.
>
> I take (and even accept) your points on D-Bus having more
> functionality than the three other IPC mechanisms I described.
>
> That said, I disagree that D-Bus is an inter-process control
> mechansim, but sockets, shm and pipes are not. To draw from networking
> terminology, sockets, shm and pipes could be seen as being on layers 2
> and/or 3 of the OSI stack (shm and unix domain sockets being a
> definite layer 2, IP sockets being layer 3), and D-Bus represents a
> mixture of layers 3-5.

Technically you are right. But in that case, a file written in /tmp
with permissions 777 and file locking can be used as IPC.

In practice, sockets/pipes/shrmem is not an IPC, because they lack a
standard protocol.

> An application may choose to use only layers 2-3 for IPC, or it may
> choose to use D-Bus.

Yeah, and they can choose to use assembler. Doesn't mean it actually
makes sense to use it.

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

Re: [gentoo-user] udev + /usr

[Neil Bothwick]

[-- Attachment #1: Type: text/plain, Size: 428 bytes --]

On Sat, 17 Sep 2011 17:13:36 -0400, Canek Peláez Valdés wrote:

> ORBit was the GNOME implementation of ORB; I don't remember what KDE
> used, but I believe it was also ORB based.

KDE 2/3 used DCOP, their own IPC as there was no decent standard system
at the time. DBus was heavily influenced by DCOP and is used by KDE4.


-- 
Neil Bothwick

Q:  Why is top-posting evil?
A: backwards read don't humans because

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-user] udev + /usr

[Alan McKinnon]

On Sat, 17 Sep 2011 15:24:39 -0400
Michael Mol <mikemol@gmail.com> wrote:

> > BTW, there *was* an standard that did everything dbus does: ORB, the
> > Object Request Broker. They tried to use that as IPC years ago, but
> > is so damn complicated to implement right they decided to better
> > implement a new standard. The standard is dbus.  
> 
> Interesting. I'd heard of ORB, even tried to play with it a bit, but
> the documentation I've found is terrible. Like a number of fields I've
> poked at, if you wan to understand how to do something, you have to do
> it, making for a tricky.

You did well to walk away from ORB and it's implementation layer CORBA.

It was one of those things not designed by real engineers but by
bloated committees. It tried to be all things to all systems and ended
up being useable by none, much like XML and Java.

There was a standards body tracking ORB, I forget which one, but none
of that matters as the folks who should use it - system builders - saw
it's flaws quite quickly. Even Gnome has dropped it and are now moving
over to dbus.

Dbus is an interesting piece of technology and rather useful, it does
it a disservice to knock it. As Canek posted a few mails higher up, it
implements a standard messaging layer on top of existing mechanisms.
You know about the existing mechanisms so you also know that they only
provide a means for communication, not the language used for the
communication. And developing a language for every IPC you want to do
becomes tiresome very quickly.

As an analogy (albeit a poor one) dbus relates to IPC as TCP relates to
IP - all the boring plumbing underneath your communication that makes it
work at all is already there. It would work best if dbus doesn't become
yet another way to do IPC, but replaces many of them. Imagine how
much unbloat you could accomplish if you could remove all the little
bits of IPC plumbing scattered throughout the average Unix system's
codebase.

There are many code projects out there that deserves to be maligned to
the point of painful death, then killed. But I honestly beleive dbus is
not one of them.


-- 
Alan McKinnnon
alan.mckinnon@gmail.com

Re: [gentoo-user] udev + /usr

[Michael Mol]

On Sat, Sep 17, 2011 at 7:00 PM, Alan McKinnon <alan.mckinnon@gmail.com> wrote:
> On Sat, 17 Sep 2011 15:24:39 -0400
> Michael Mol <mikemol@gmail.com> wrote:
> Dbus is an interesting piece of technology and rather useful, it does
> it a disservice to knock it.

Honestly, I really only want to provide reasonable criticism. I just
tend to get hung up on the nitty gritty details and where I think I
see something illogical.

> As Canek posted a few mails higher up, it
> implements a standard messaging layer on top of existing mechanisms.
> You know about the existing mechanisms so you also know that they only
> provide a means for communication, not the language used for the
> communication. And developing a language for every IPC you want to do
> becomes tiresome very quickly.

Don't I know it. I have to maintain proprietary, network binary
protocols passing data between propriety applications I also maintain.
I don't _like_ that architecture in the slightest, but it's what I get
paid for.

>
> As an analogy (albeit a poor one) dbus relates to IPC as TCP relates to
> IP - all the boring plumbing underneath your communication that makes it
> work at all is already there. It would work best if dbus doesn't become
> yet another way to do IPC, but replaces many of them. Imagine how
> much unbloat you could accomplish if you could remove all the little
> bits of IPC plumbing scattered throughout the average Unix system's
> codebase.

There's the terminology confusion that I got hung up on in the last
email; D-Bus is a higher-level IPC mechanism than the ones it's
implemented on top of.

> There are many code projects out there that deserves to be maligned to
> the point of painful death, then killed. But I honestly beleive dbus is
> not one of them.

There are two principle things I dislike about D-Bus.

1) It doesn't support live upgrading of the daemon. We discussed the
reasons behind this several weeks ago, as I recall. Transparent
session control handoff is, of course, complicated, and nobody has
seen the work as worthwhile.

2) It comes with (or appears to come with) a Linux-centric (sometimes
even a Linux-only) view. I love Linux, and I would love to see Linux
grow and improve. I also use (and am comfortable with) Windows and
Android (which I would consider Not Really Linux) and other
platforms*. Attitudes and actions which push Linux as the One Ring
smack of 'Embrace, Extend, Extinguish'.

That latter point, really, bothers me greatly. Market disruption
happens, and sometimes it's even necessary for advancement, sure.

Other than those two things, D-Bus seems interesting and useful. If it
manages to obsolete system-local IPC mechanisms, that's great. If it
manages to get out into the local network and be used to pass messages
back and forth between my local systems? That's awesome. If it manages
to allow applications to talk back and forth in a secure fashion
between Linux and non-Linux systems? Now we're talking about some real
improvement on the status quo.

* I think I could get by on a Mac, but it's difficult getting past
some prejudices and annoying fanboys I know IRL. It's also difficult
getting past the price tag; I don't see myself buying the hardware or
software unless I intend to develop for them. As for what I use? All
five computers at home run Linux; one Debian, three Ubuntu, one
Gentoo. My fiancee and I both have Android phones.

-- 
:wq

Re: [gentoo-user] udev + /usr

[Canek Peláez Valdés]

On Sat, Sep 17, 2011 at 7:31 PM, Michael Mol <mikemol@gmail.com> wrote:
> On Sat, Sep 17, 2011 at 7:00 PM, Alan McKinnon <alan.mckinnon@gmail.com> wrote:
>> On Sat, 17 Sep 2011 15:24:39 -0400
>> Michael Mol <mikemol@gmail.com> wrote:
>> Dbus is an interesting piece of technology and rather useful, it does
>> it a disservice to knock it.
>
> Honestly, I really only want to provide reasonable criticism. I just
> tend to get hung up on the nitty gritty details and where I think I
> see something illogical.
>
>> As Canek posted a few mails higher up, it
>> implements a standard messaging layer on top of existing mechanisms.
>> You know about the existing mechanisms so you also know that they only
>> provide a means for communication, not the language used for the
>> communication. And developing a language for every IPC you want to do
>> becomes tiresome very quickly.
>
> Don't I know it. I have to maintain proprietary, network binary
> protocols passing data between propriety applications I also maintain.
> I don't _like_ that architecture in the slightest, but it's what I get
> paid for.
>
>>
>> As an analogy (albeit a poor one) dbus relates to IPC as TCP relates to
>> IP - all the boring plumbing underneath your communication that makes it
>> work at all is already there. It would work best if dbus doesn't become
>> yet another way to do IPC, but replaces many of them. Imagine how
>> much unbloat you could accomplish if you could remove all the little
>> bits of IPC plumbing scattered throughout the average Unix system's
>> codebase.
>
> There's the terminology confusion that I got hung up on in the last
> email; D-Bus is a higher-level IPC mechanism than the ones it's
> implemented on top of.
>
>> There are many code projects out there that deserves to be maligned to
>> the point of painful death, then killed. But I honestly beleive dbus is
>> not one of them.
>
> There are two principle things I dislike about D-Bus.
>
> 1) It doesn't support live upgrading of the daemon. We discussed the
> reasons behind this several weeks ago, as I recall. Transparent
> session control handoff is, of course, complicated, and nobody has
> seen the work as worthwhile.
>
> 2) It comes with (or appears to come with) a Linux-centric (sometimes
> even a Linux-only) view.

I think you got it wrong. dbus runs in every single Unix, I believe:
it certainly runs on *BSD, Solaris, and Mac OS X. On top of that, dbus
works (albeit with some differences) on Windows.

As I said, dbus works on top of Unix sockets, and that works in every
OS in the planet, I believe.

It is one of the pieces of code most portable ever.

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

Re: [gentoo-user] udev + /usr

[Michael Mol]

On Sat, Sep 17, 2011 at 7:45 PM, Canek Peláez Valdés <caneko@gmail.com> wrote:
> On Sat, Sep 17, 2011 at 7:31 PM, Michael Mol <mikemol@gmail.com> wrote:
>> 2) It comes with (or appears to come with) a Linux-centric (sometimes
>> even a Linux-only) view.
>
> I think you got it wrong. dbus runs in every single Unix, I believe:
> it certainly runs on *BSD, Solaris, and Mac OS X. On top of that, dbus
> works (albeit with some differences) on Windows.
>
> As I said, dbus works on top of Unix sockets, and that works in every
> OS in the planet, I believe.
>
> It is one of the pieces of code most portable ever.

That's actually very good to hear.

-- 
:wq

Re: [gentoo-user] udev + /usr

[Alan McKinnon]

On Sat, 17 Sep 2011 19:31:31 -0400
Michael Mol <mikemol@gmail.com> wrote:

> There are two principle things I dislike about D-Bus.
> 
> 1) It doesn't support live upgrading of the daemon. We discussed the
> reasons behind this several weeks ago, as I recall. Transparent
> session control handoff is, of course, complicated, and nobody has
> seen the work as worthwhile.

If your 2nd objection changes, this one will probably get looked at.

> 2) It comes with (or appears to come with) a Linux-centric (sometimes
> even a Linux-only) view. I love Linux, and I would love to see Linux
> grow and improve. I also use (and am comfortable with) Windows and
> Android (which I would consider Not Really Linux) and other
> platforms*. Attitudes and actions which push Linux as the One Ring
> smack of 'Embrace, Extend, Extinguish'.

dbus is a freedesktop project so will live or die by it's merits.

Other systems may start to use it if it proves itself useful. Lucky for
us, it doesn't obsolete anything else, just adds functionality to what
is already there. 

-- 
Alan McKinnnon
alan.mckinnon@gmail.com

Re: [gentoo-user] [OT rant] udev + /usr

[pk]

On 2011-09-18 09:37, Alan McKinnon wrote:

> Other systems may start to use it if it proves itself useful. Lucky for
> us, it doesn't obsolete anything else, just adds functionality to what
> is already there. 

Although, one thing which I find very annoying is that the things that
depend on it starts dbus-launch/daemon no matter if I don't want to run
it or not (it's not running acc. to rc-update show but ps -ef shows both
dbus-launch and dbus-daemon running). I'm using Xfce4 and have Audacious
installed which depends on dbus-glib, which of course depends on dbus
itself. No other packages uses it (USE= -dbus). Xfce4 and Audacious
hasn't used dbus before a certain version (at least it has not been
mandatory) and I've been using them for years (haven't had the time to
look for alternatives yet).
 In general I have a problem with packages that pulls in *something*
which in turn depends on *something else* which in turn... overlapping
functionality etc. It's quite troublesome to keep, for instance, gconf
out of my system (masked by me to detect any "upgrades" that tries to
pull it in)...

In my "world" software (in general) should not become an "obstacle"; it
is just a tool to accomplish whatever you want it to do. Ideally the OS
(and whatever interfaces the user) shouldn't consume _any_ resources at
all (yes, I'm well aware that it's not possible). Resource usage should
at least be kept to a minimum, otherwise I have to buy new faster
hardware for each "upgrade" (be it for security, for functionality etc.)
and if I liked that I could just go with Windows. My whole complaint
about this udev business is that we're "ballooning" out of control, IMO,
becoming the "monster" that, I assume, most of us wanted to avoid.

PS. My animosity towards dbus is "historical"; I did use it years ago
(together with gnome, gconf etc.) which caused me nothing but trouble.
I've avoided that crap ever since. I do agree that the idea _behind_
dbus seems sensible but I'm not so sure about the implementation.

Best regards

Peter K

Re: [gentoo-user] [OT rant] udev + /usr

[Volker Armin Hemmann]

Am Sonntag 18 September 2011, 11:23:43 schrieb pk:
> On 2011-09-18 09:37, Alan McKinnon wrote:
> > Other systems may start to use it if it proves itself useful. Lucky for
> > us, it doesn't obsolete anything else, just adds functionality to what
> > is already there.
> 
> Although, one thing which I find very annoying is that the things that
> depend on it starts dbus-launch/daemon no matter if I don't want to run
> it or not (it's not running acc. to rc-update show but ps -ef shows both
> dbus-launch and dbus-daemon running). I'm using Xfce4 and have Audacious
> installed which depends on dbus-glib, which of course depends on dbus
> itself. No other packages uses it (USE= -dbus). Xfce4 and Audacious
> hasn't used dbus before a certain version (at least it has not been
> mandatory) and I've been using them for years (haven't had the time to
> look for alternatives yet).
>  In general I have a problem with packages that pulls in *something*
> which in turn depends on *something else* which in turn... overlapping
> functionality etc. It's quite troublesome to keep, for instance, gconf
> out of my system (masked by me to detect any "upgrades" that tries to
> pull it in)...
> 
> In my "world" software (in general) should not become an "obstacle"; it
> is just a tool to accomplish whatever you want it to do. Ideally the OS
> (and whatever interfaces the user) shouldn't consume _any_ resources at
> all (yes, I'm well aware that it's not possible). Resource usage should
> at least be kept to a minimum, otherwise I have to buy new faster
> hardware for each "upgrade" (be it for security, for functionality etc.)
> and if I liked that I could just go with Windows. My whole complaint
> about this udev business is that we're "ballooning" out of control, IMO,
> becoming the "monster" that, I assume, most of us wanted to avoid.
> 
> PS. My animosity towards dbus is "historical"; I did use it years ago
> (together with gnome, gconf etc.) which caused me nothing but trouble.
> I've avoided that crap ever since. I do agree that the idea _behind_
> dbus seems sensible but I'm not so sure about the implementation.
> 
> Best regards
> 
> Peter K

years ago? is gnome even using dbus for years? They had their broken 
corba/orbit/bonobo stuff.

And what is your problem with dbus anyway? I bet you can't even measure a 
difference between dbus running and dbus not running in speed or 
responsiveness of your gui.

-- 
#163933

Re: [gentoo-user] [OT rant] udev + /usr

[pk]

On 2011-09-18 12:03, Volker Armin Hemmann wrote:

> And what is your problem with dbus anyway? I bet you can't even measure a 
> difference between dbus running and dbus not running in speed or 
> responsiveness of your gui.

Not my specific case(s) but a quick google gave this:
https://bugs.launchpad.net/ubuntu/+source/dbus/+bug/737170

Best regards

Peter K

Re: [gentoo-user] [OT rant] udev + /usr

[Volker Armin Hemmann]

Am Sonntag 18 September 2011, 12:44:04 schrieb pk:
> On 2011-09-18 12:03, Volker Armin Hemmann wrote:
> > And what is your problem with dbus anyway? I bet you can't even measure
> > a
> > difference between dbus running and dbus not running in speed or
> > responsiveness of your gui.
> 
> Not my specific case(s) but a quick google gave this:
> https://bugs.launchpad.net/ubuntu/+source/dbus/+bug/737170
> 
> Best regards
> 
> Peter K

so a single bug is all you got? OH MY GOD! Firefox uses 100% of a core. or OH 
MY GOD compiz makes my CPU and GPU running hot and noisy! OH MY GOD udev 
update killed dvb-s!.

So you are going from a single bug to 'it must be evil'. If you do that all 
the time there isn't much software left.
-- 
#163933

Re: [gentoo-user] [OT rant] udev + /usr

[Alan McKinnon]

On Sun, 18 Sep 2011 14:32:11 +0200
Volker Armin Hemmann <volkerarmin@googlemail.com> wrote:

> Am Sonntag 18 September 2011, 12:44:04 schrieb pk:
> > On 2011-09-18 12:03, Volker Armin Hemmann wrote:
> > > And what is your problem with dbus anyway? I bet you can't even
> > > measure a
> > > difference between dbus running and dbus not running in speed or
> > > responsiveness of your gui.
> > 
> > Not my specific case(s) but a quick google gave this:
> > https://bugs.launchpad.net/ubuntu/+source/dbus/+bug/737170
> > 
> > Best regards
> > 
> > Peter K
> 
> so a single bug is all you got? OH MY GOD! Firefox uses 100% of a
> core. or OH MY GOD compiz makes my CPU and GPU running hot and noisy!
> OH MY GOD udev update killed dvb-s!.
> 
> So you are going from a single bug to 'it must be evil'. If you do
> that all the time there isn't much software left.

And he's using Audacious - a fork of a gigantic bug nest (mms) .
According to his earlier post, it forces dbus to run.

Now, that can hardly be dbus's fault if some other app has a hardcoded
RUNTIME dep on dbus. The fault lies entirely with Audacious, not with
dbus.



-- 
Alan McKinnnon
alan.mckinnon@gmail.com

Re: [gentoo-user] [OT rant] udev + /usr

[pk]

On 2011-09-18 14:56, Alan McKinnon wrote:

> And he's using Audacious - a fork of a gigantic bug nest (mms) .
> According to his earlier post, it forces dbus to run.

Xmms, I believe it's called. And it's been working fine for quite a
while (I've actually have never encountered a bug with Audacious), for
me. Now, when I upgraded to 2.4.x dbus was forced on me (well, that and
Xfce4)... I'm used to Audacious because I like the simple interface
(non-gtk+). But if you have another player you would like to recommend
I'll gladly try it. Requirements: no gconf/gnome/udev/udisk(etc.)
dependency (only sane dependencies like libogg/flac etc., possibly gtk
or qt for ui but nothing else), simple UI (like Audacious legacy mode),
no singin' and dancing crap (simplicity over "features")...

> Now, that can hardly be dbus's fault if some other app has a hardcoded
> RUNTIME dep on dbus. The fault lies entirely with Audacious, not with
> dbus.

I fully agree to that last sentiment, which is why I'm whining... I
thought that was what we were doing here? ;-)
But to be fair, it's actually Xfce4 that starts dbus-daemon/launch (I
haven't started Audacious yet and I always turn off my computer when not
in use).

Best regards

Peter K

Re: [gentoo-user] [OT rant] udev + /usr

[Indi]

On Sun, 18 Sep 2011 18:55:01 +0200
pk <peterk2@coolmail.se> wrote:


> Xmms, I believe it's called. And it's been working fine for quite a
> while (I've actually have never encountered a bug with Audacious), for
> me. Now, when I upgraded to 2.4.x dbus was forced on me (well, that
> and Xfce4)... I'm used to Audacious because I like the simple
> interface (non-gtk+). But if you have another player you would like
> to recommend I'll gladly try it. Requirements: no
> gconf/gnome/udev/udisk(etc.) dependency (only sane dependencies like
> libogg/flac etc., possibly gtk or qt for ui but nothing else), simple
> UI (like Audacious legacy mode), no singin' and dancing crap
> (simplicity over "features")...
> 

Install mpd, mpc, and ncmpc. Read the man pages, live happily ever
after.

-- 
caveat utilitor

Re: [gentoo-user] [OT rant] udev + /usr

[pk]

On 2011-09-18 19:41, Indi wrote:

> Install mpd, mpc, and ncmpc. Read the man pages, live happily ever
> after.

Ok, I'll look into it. Thanks!

Best regards

Peter K

Re: [gentoo-user] [OT rant] udev + /usr

[Alan McKinnon]

On Sun, 18 Sep 2011 18:55:01 +0200
pk <peterk2@coolmail.se> wrote:

> > And he's using Audacious - a fork of a gigantic bug nest (mms) .
> > According to his earlier post, it forces dbus to run.  
> 
> Xmms, I believe it's called. And it's been working fine for quite a
> while (I've actually have never encountered a bug with Audacious), for
> me. Now, when I upgraded to 2.4.x dbus was forced on me (well, that
> and Xfce4)... I'm used to Audacious because I like the simple
> interface (non-gtk+). But if you have another player you would like
> to recommend I'll gladly try it.

No, I'm not doing your homework for you. Try them all, and settle on
the one YOU like.

Maybe you could start with alsa-player and bash

-- 
Alan McKinnnon
alan.mckinnon@gmail.com

Re: [gentoo-user] [OT rant] udev + /usr

[Volker Armin Hemmann]

Am Sonntag 18 September 2011, 18:55:01 schrieb pk:
> On 2011-09-18 14:56, Alan McKinnon wrote:
> > And he's using Audacious - a fork of a gigantic bug nest (mms) .
> > According to his earlier post, it forces dbus to run.
> 
> Xmms, I believe it's called. And it's been working fine for quite a
> while (I've actually have never encountered a bug with Audacious), for
> me. Now, when I upgraded to 2.4.x dbus was forced on me (well, that and
> Xfce4)... I'm used to Audacious because I like the simple interface
> (non-gtk+). But if you have another player you would like to recommend
> I'll gladly try it. Requirements: no gconf/gnome/udev/udisk(etc.)
> dependency (only sane dependencies like libogg/flac etc., possibly gtk
> or qt for ui but nothing else), simple UI (like Audacious legacy mode),
> no singin' and dancing crap (simplicity over "features")...

alsaplayer. Can't even get more simplistic. You don't even have to run a 
daemon or server. Just playing music.

--
#163933

Re: [gentoo-user] [OT rant] udev + /usr

[Walter Dnes]

On Sun, Sep 18, 2011 at 10:48:10PM +0200, Volker Armin Hemmann wrote

> alsaplayer. Can't even get more simplistic. You don't even have to run a 
> daemon or server. Just playing music.

  Or mpg321 or mpg123, both of which are commandline programs.

-- 
Walter Dnes <waltdnes@waltdnes.org>

Re: [gentoo-user] [OT rant] udev + /usr

[Volker Armin Hemmann]

Am Montag 19 September 2011, 20:20:35 schrieb Walter Dnes:
> On Sun, Sep 18, 2011 at 10:48:10PM +0200, Volker Armin Hemmann wrote
> 
> > alsaplayer. Can't even get more simplistic. You don't even have to run a
> > daemon or server. Just playing music.
> 
>   Or mpg321 or mpg123, both of which are commandline programs.

well, both can't do playlists - and there ability to play sound very slow or 
backwards is limited ;)

-- 
#163933

Re: [gentoo-user] [OT rant] udev + /usr

[Alex Schuster]

Volker Armin Hemmann writes:

> Am Montag 19 September 2011, 20:20:35 schrieb Walter Dnes:
> > On Sun, Sep 18, 2011 at 10:48:10PM +0200, Volker Armin Hemmann wrote
> > 
> > > alsaplayer. Can't even get more simplistic. You don't even have to
> > > run a daemon or server. Just playing music.
> > 
> >   Or mpg321 or mpg123, both of which are commandline programs.
> 
> well, both can't do playlists

They do, with option -@ <file>.

> and there ability to play sound very slow or backwards is limited ;)

Well... but I'd miss stopping sound (okaaayy... Ctrl-Z and fg), skipping
tracks, or going back in the playlist.

And, as an Amarok user... searching my collection, finding song texts,
rating songs, wikipedia information for artist, album or a specfic song,
tagging, easy sorting of playlists, bookmarks, saving streams to disk,
global shortcuts.

	Wonko

Re: [gentoo-user] [OT rant] udev + /usr

[Michael Mol]

On Tue, Sep 20, 2011 at 1:10 PM, Alex Schuster <wonko@wonkology.org> wrote:
> Volker Armin Hemmann writes:
>
>> Am Montag 19 September 2011, 20:20:35 schrieb Walter Dnes:
>> > On Sun, Sep 18, 2011 at 10:48:10PM +0200, Volker Armin Hemmann wrote
>> >
>> > > alsaplayer. Can't even get more simplistic. You don't even have to
>> > > run a daemon or server. Just playing music.
>> >
>> >   Or mpg321 or mpg123, both of which are commandline programs.
>>
>> well, both can't do playlists
>
> They do, with option -@ <file>.
>
>> and there ability to play sound very slow or backwards is limited ;)
>
> Well... but I'd miss stopping sound (okaaayy... Ctrl-Z and fg), skipping
> tracks, or going back in the playlist.
>
> And, as an Amarok user... searching my collection, finding song texts,
> rating songs, wikipedia information for artist, album or a specfic song,
> tagging, easy sorting of playlists, bookmarks, saving streams to disk,
> global shortcuts.

I've never had good success with amarok. (Or any other rich-featured
past a gnome one I can't recall the name of right now)


-- 
:wq

Re: [gentoo-user] [OT rant] udev + /usr

[Mark Knecht]

On Tue, Sep 20, 2011 at 10:28 AM, Michael Mol <mikemol@gmail.com> wrote:
> On Tue, Sep 20, 2011 at 1:10 PM, Alex Schuster <wonko@wonkology.org> wrote:
>> Volker Armin Hemmann writes:
>>
>>> Am Montag 19 September 2011, 20:20:35 schrieb Walter Dnes:
>>> > On Sun, Sep 18, 2011 at 10:48:10PM +0200, Volker Armin Hemmann wrote
>>> >
>>> > > alsaplayer. Can't even get more simplistic. You don't even have to
>>> > > run a daemon or server. Just playing music.
>>> >
>>> >   Or mpg321 or mpg123, both of which are commandline programs.
>>>
>>> well, both can't do playlists
>>
>> They do, with option -@ <file>.
>>
>>> and there ability to play sound very slow or backwards is limited ;)
>>
>> Well... but I'd miss stopping sound (okaaayy... Ctrl-Z and fg), skipping
>> tracks, or going back in the playlist.
>>
>> And, as an Amarok user... searching my collection, finding song texts,
>> rating songs, wikipedia information for artist, album or a specfic song,
>> tagging, easy sorting of playlists, bookmarks, saving streams to disk,
>> global shortcuts.
>
> I've never had good success with amarok. (Or any other rich-featured
> past a gnome one I can't recall the name of right now)
>

I used Aqualung for a long time, and it worked well, but it eventually
became fairly difficult for me to keep up. I'm now ashamed to say I'm
completely converted to iTunes in a Windows XP VM. Well supported by
Apple and interfaces with external hardware things around the house.

- Mark

Re: [gentoo-user] [OT rant] udev + /usr

[Alex Schuster]

Michael Mol writes:

> On Tue, Sep 20, 2011 at 1:10 PM, Alex Schuster <wonko@wonkology.org>
> wrote:

> > And, as an Amarok user... searching my collection, finding song texts,
> > rating songs, wikipedia information for artist, album or a specfic
> > song, tagging, easy sorting of playlists, bookmarks, saving streams
> > to disk, global shortcuts.
> 
> I've never had good success with amarok. (Or any other rich-featured
> past a gnome one I can't recall the name of right now)

I was a happy user in the KDE 3.5 days, but in KDE4 I also had big
trouble, mainly with huuuge startup times and corruption of the
collection. And lots of crashes and small annoyances. But for about a
year now, it is much more stable, and works quite well for me. Little
problems happen from time to time, but I really like this player, so I
live with them. I got used to many features, and would not like to change
to another player.

	Wonko

Re: [gentoo-user] [OT rant] udev + /usr

[Thanasis]

on 09/20/2011 07:50 PM Volker Armin Hemmann wrote the following:
> Am Montag 19 September 2011, 20:20:35 schrieb Walter Dnes:
>> On Sun, Sep 18, 2011 at 10:48:10PM +0200, Volker Armin Hemmann wrote
>>
>>> alsaplayer. Can't even get more simplistic. You don't even have to run a
>>> daemon or server. Just playing music.
>>
>>   Or mpg321 or mpg123, both of which are commandline programs.
> 
> well, both can't do playlists - and there ability to play sound very slow or 
> backwards is limited ;)
> 

I know mpg321 can do playlists like so:

mpg123 --list file

quote from its man page:
-@ file, --list file
              Read filenames and/or URLs of MPEG audio streams from the
specified file in addition to the ones specified on the command  line
(if  any).  Note that file can be either an ordinary file, a dash ``-''
to indicate that a list of filenames/URLs is to be read from the
standard input, or an URL pointing to a an appropriate list file.  Note:
only one -@ option can be used (if more  than one is specified, only the
last one will be recognized).

Re: [gentoo-user] [OT rant] udev + /usr

[Volker Armin Hemmann]

Am Dienstag 20 September 2011, 20:19:44 schrieb Thanasis:
> on 09/20/2011 07:50 PM Volker Armin Hemmann wrote the following:
> > Am Montag 19 September 2011, 20:20:35 schrieb Walter Dnes:
> >> On Sun, Sep 18, 2011 at 10:48:10PM +0200, Volker Armin Hemmann wrote
> >> 
> >>> alsaplayer. Can't even get more simplistic. You don't even have to
> >>> run a daemon or server. Just playing music.
> >>> 
> >>   Or mpg321 or mpg123, both of which are commandline programs.
> > 
> > well, both can't do playlists - and there ability to play sound very
> > slow or backwards is limited ;)
> 
> I know mpg321 can do playlists like so:
> 
> mpg123 --list file
> 
> quote from its man page:
> -@ file, --list file
>               Read filenames and/or URLs of MPEG audio streams from the
> specified file in addition to the ones specified on the command  line
> (if  any).  Note that file can be either an ordinary file, a dash ``-''
> to indicate that a list of filenames/URLs is to be read from the
> standard input, or an URL pointing to a an appropriate list file.  Note:
> only one -@ option can be used (if more  than one is specified, only the
> last one will be recognized).

thanks, didn't know that - but... I never found any need for that. 
alsaplayer/vlc/amarok are pretty much all I need.

-- 
#163933

Re: [gentoo-user] [OT rant] udev + /usr

[Roman Dobosz]

On Sun, 18 Sep 2011 18:55:01 +0200
pk <peterk2@coolmail.se> wrote:

> Xmms, I believe it's called. And it's been working fine for quite a
> while (I've actually have never encountered a bug with Audacious), for
> me. Now, when I upgraded to 2.4.x dbus was forced on me (well, that and
> Xfce4)... I'm used to Audacious because I like the simple interface
> (non-gtk+). But if you have another player you would like to recommend
> I'll gladly try it. Requirements: no gconf/gnome/udev/udisk(etc.)
> dependency (only sane dependencies like libogg/flac etc., possibly gtk
> or qt for ui but nothing else), simple UI (like Audacious legacy mode),
> no singin' and dancing crap (simplicity over "features")...

For "just playing music" task I'm using moc[1] or deadbeef[2]. First
one is cute little player with ncurses interface, other is simple
foobar-like GTK player. Outside my headphones there can be heard
what mpd[3] is currently playing (on second sound card).

[1] http://moc.daper.net
[2] http://deadbeef.sourceforge.net
[3] http://mpd.wikia.com

-- 
      -^-  _        coś tam w tle sobie gra, np:
   _ /O)_\//        Suicide Commando
  (_(|__(_(_) grf.   - Stored Images (1995) - Actions Of The Mind

Re: [gentoo-user] [OT rant] udev + /usr

[pk]

On 2011-09-18 14:32, Volker Armin Hemmann wrote:

> So you are going from a single bug to 'it must be evil'. If you do that all 
> the time there isn't much software left.

You said: "I bet you can't even measure a
difference between dbus running and dbus not running in speed or
responsiveness of your gui."

I only pointed out that that was not always correct (I don't run
Ubuntu). And I have had a _lot_ of problems with dbus (again, this was
years ago, running binary distros - it's only recently that I had dbus
installed again due to Xfce4 requiring it); if I get burnt by some piece
of software (usually it's gnome/freedesktop related - seems a lot of bad
ideas/implementations come from that "place") I try to go "elsewhere".
So if your experience with dbus is different, then fine, by all means
use it; it is your choice. But I choose to avoid it, if possible.

And yes, it seems no matter how hard I try the "gnome" paradigm ('evil'
software) seems to be inching ever closer... I think developers, in
general, should take some hints from this guy:
http://www.sics.se/~adam/
... he created this:
http://www.contiki-os.org/p/about-contiki.html
... running this:
http://www.c64web.com/

Best regards

Peter k

Re: [gentoo-user] [OT rant] udev + /usr

[Canek Peláez Valdés]

On Sun, Sep 18, 2011 at 9:19 AM, pk <peterk2@coolmail.se> wrote:
> On 2011-09-18 14:32, Volker Armin Hemmann wrote:
>
>> So you are going from a single bug to 'it must be evil'. If you do that all
>> the time there isn't much software left.
>
> You said: "I bet you can't even measure a
> difference between dbus running and dbus not running in speed or
> responsiveness of your gui."
>
> I only pointed out that that was not always correct (I don't run
> Ubuntu). And I have had a _lot_ of problems with dbus (again, this was
> years ago, running binary distros - it's only recently that I had dbus
> installed again due to Xfce4 requiring it); if I get burnt by some piece
> of software (usually it's gnome/freedesktop related - seems a lot of bad
> ideas/implementations come from that "place") I try to go "elsewhere".
> So if your experience with dbus is different, then fine, by all means
> use it; it is your choice. But I choose to avoid it, if possible.
>
> And yes, it seems no matter how hard I try the "gnome" paradigm ('evil'
> software) seems to be inching ever closer... I think developers, in
> general, should take some hints from this guy:
> http://www.sics.se/~adam/
> ... he created this:
> http://www.contiki-os.org/p/about-contiki.html
> ... running this:
> http://www.c64web.com/

Hey, that's really cool.

Just don't expect everybody to run our systems without the modern
parts of the stack just because a Commodore 64 cannot run it.

Many of us actually like the modern features of the kernel, glibc,
udev, dbus, systemd, pulseaudio, glib, X.org, GStreamer, Gtk+ and
GNOME (or Qt and KDE). In my case (and I have used Linux for a long
time), the whole stack looks full of awsomeness, and stuff just works
most of the time.

So yeah, we use more CPU cycles, more memory and more hard drive. From
my POV, we get more than that in new and improved functionality.


> Best regards

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

Re: [gentoo-user] [OT rant] udev + /usr

[pk]

On 2011-09-18 15:31, Canek Peláez Valdés wrote:

> Hey, that's really cool.

I agree.

> Just don't expect everybody to run our systems without the modern
> parts of the stack just because a Commodore 64 cannot run it.

I think you need to take a closer look; it does support a lot of
"modern" parts of the "stack" (as you call it); it's just focused on the
things that matters (for an embedded system). It is the mindset that I'm
after; it seems even kernel developers are thinking "oh, we have so much
memory here so it doesn't matter if we use a few GB here" (yes, I'm
exaggerating). Intel and AMD can't increase the clocks anymore so
they've started to throw more hardware on the ever increasing demand for
computing power... there will be a time when the "bloat" will take it's
toll on more users.

> Many of us actually like the modern features of the kernel, glibc,
> udev, dbus, systemd, pulseaudio, glib, X.org, GStreamer, Gtk+ and

There's a lot of people that like Windows 7 and MacOS X too, I hear.
What the ultimate goal (in my view) for systemd, pulseaudio etc. seems
to be is to mimic (poorly) the mentioned OS's. Why go through all that
trouble when they can just go out and buy what they want?

The Linux kernel, glibc and X I "like", udev used to be nice (well, my
currently installed version works fine), the rest is redundant (more or
less) - in my view (particularly pulseaudio & systemd); I really don't
understand what problems they are solving.

> GNOME (or Qt and KDE). In my case (and I have used Linux for a long

I also have used GNU/Linux for quite a while (1995) and have seen "it"
grow from quite humble (but capable) beginnings to what it is today
(even Linus Torvalds thinks the kernel is bloated) and I'll refrain from
commenting on gnome (and to a lesser extent KDE). The best install I've
ever had was a LFS install around 2000 running on a Abit BP6 with two
celeron CPUs and a scsi harddrive (9GB)... :-)

> time), the whole stack looks full of awsomeness, and stuff just works
> most of the time.

No comment. :-/

Best regards

Peter K

Re: [gentoo-user] [OT rant] udev + /usr

[Michael Mol]

On Sun, Sep 18, 2011 at 1:43 PM, pk <peterk2@coolmail.se> wrote:
> I think you need to take a closer look; it does support a lot of
> "modern" parts of the "stack" (as you call it); it's just focused on the
> things that matters (for an embedded system). It is the mindset that I'm
> after; it seems even kernel developers are thinking "oh, we have so much
> memory here so it doesn't matter if we use a few GB here" (yes, I'm
> exaggerating). Intel and AMD can't increase the clocks anymore so
> they've started to throw more hardware on the ever increasing demand for
> computing power... there will be a time when the "bloat" will take it's
> toll on more users.

The kernel configuration process is actually very nice and very easy.
You an remove any features you don't want or need. (I'm referring to,
e.g. menuconfig. I haven't really used genkernel)

The first time's the hardest. After you know what parts you need for a
given box, it's easy.

>> Many of us actually like the modern features of the kernel, glibc,
>> udev, dbus, systemd, pulseaudio, glib, X.org, GStreamer, Gtk+ and
>
> There's a lot of people that like Windows 7 and MacOS X too, I hear.
> What the ultimate goal (in my view) for systemd, pulseaudio etc. seems
> to be is to mimic (poorly) the mentioned OS's.

FWIW, PulseAudio predates Windows Vista, Windows 7, even MacOS X. I
ran it on a 200MHz machine back when it was called Enlightenment Sound
Daemon.

With as much as I've poked at PulseAudio, I'd have to say I like it
better than I like the Vista/Win7 implementation of sound daemons.

There's probably not much one can do with PA that one couldn't do with
jackd, which is probably better in terms of latency, but I never got
around to learning jackd.

> The Linux kernel, glibc and X I "like", udev used to be nice (well, my
> currently installed version works fine), the rest is redundant (more or
> less) - in my view (particularly pulseaudio & systemd); I really don't
> understand what problems they are solving.

While I was using PA (I'm not, currently), it was nice for being able
to monitor and tune the volume levels of individual programs. That can
be important when trying to manage two different VOIP apps, video
games and Pandora at the same time.

-- 
:wq

Re: [gentoo-user] [OT rant] udev + /usr

[Volker Armin Hemmann]

Am Sonntag 18 September 2011, 15:52:16 schrieb Michael Mol:
> On Sun, Sep 18, 2011 at 1:43 PM, pk <peterk2@coolmail.se> wrote:
> > I think you need to take a closer look; it does support a lot of
> > "modern" parts of the "stack" (as you call it); it's just focused on the
> > things that matters (for an embedded system). It is the mindset that I'm
> > after; it seems even kernel developers are thinking "oh, we have so much
> > memory here so it doesn't matter if we use a few GB here" (yes, I'm
> > exaggerating). Intel and AMD can't increase the clocks anymore so
> > they've started to throw more hardware on the ever increasing demand for
> > computing power... there will be a time when the "bloat" will take it's
> > toll on more users.
> 
> The kernel configuration process is actually very nice and very easy.
> You an remove any features you don't want or need. (I'm referring to,
> e.g. menuconfig. I haven't really used genkernel)
> 
> The first time's the hardest. After you know what parts you need for a
> given box, it's easy.
> 
> >> Many of us actually like the modern features of the kernel, glibc,
> >> udev, dbus, systemd, pulseaudio, glib, X.org, GStreamer, Gtk+ and
> > 
> > There's a lot of people that like Windows 7 and MacOS X too, I hear.
> > What the ultimate goal (in my view) for systemd, pulseaudio etc. seems
> > to be is to mimic (poorly) the mentioned OS's.
> 
> FWIW, PulseAudio predates Windows Vista, Windows 7, even MacOS X. I
> ran it on a 200MHz machine back when it was called Enlightenment Sound
> Daemon.

Pulseaudio was meant to be a drop in replacement for ESD but AFAIK that is 
where the common grounds end. Pulseaudio was not ESD and ESD is not 
Pulseaudio.

Plus ESD has/had a less than good reputation to say it politely.

-- 
#163933

Re: [gentoo-user] [OT rant] udev + /usr

[Alan McKinnon]

On Sun, 18 Sep 2011 23:06:18 +0200
Volker Armin Hemmann <volkerarmin@googlemail.com> wrote:

> > FWIW, PulseAudio predates Windows Vista, Windows 7, even MacOS X. I
> > ran it on a 200MHz machine back when it was called Enlightenment
> > Sound Daemon.  
> 
> Pulseaudio was meant to be a drop in replacement for ESD but AFAIK
> that is where the common grounds end. Pulseaudio was not ESD and ESD
> is not Pulseaudio.
> 
> Plus ESD has/had a less than good reputation to say it politely.

And that brings us to today's trick question of the day, boys and girls:

Which is worse? ESD or aRTS?


I swear, with each passing day I become more and more convinced that
audio and printing are the two ultimately unsolveable computer science
problems. They only seem to ever work at all in a walled garden.


-- 
Alan McKinnnon
alan.mckinnon@gmail.com

Re: [gentoo-user] [OT rant] udev + /usr

[pk]

On 2011-09-18 21:52, Michael Mol wrote:

> The kernel configuration process is actually very nice and very easy.
> You an remove any features you don't want or need. (I'm referring to,
> e.g. menuconfig. I haven't really used genkernel)

I've never used genkernel and always compile my own kernels...

> FWIW, PulseAudio predates Windows Vista, Windows 7, even MacOS X. I
> ran it on a 200MHz machine back when it was called Enlightenment Sound
> Daemon.

Hm... I've used ESD (years and years ago :-) ) in OSS times. Not sure
where the connection between ESD and Pulseaudio is though[1]... Well,
anywho, Gentoo stopped supporting both the ESD and arts server years ago
for security reasons IIRC.

> With as much as I've poked at PulseAudio, I'd have to say I like it
> better than I like the Vista/Win7 implementation of sound daemons.

I've no experience with Vista/Win7 (I've got an XP machine for gaming).

> There's probably not much one can do with PA that one couldn't do with
> jackd, which is probably better in terms of latency, but I never got
> around to learning jackd.

Yes, tried jack a few years ago but couldn't get it working right. Not
that I got "burnt" by it (as dbus etc.) and if the need arise, I'll look
into it again... Thing is, ALSA already have a (simple) sound server
"built" in called dmix so why one would bother with Pulseaudio is beyond
me (but as long as it's not "forced" onto users I don't care much about it).

> While I was using PA (I'm not, currently), it was nice for being able
> to monitor and tune the volume levels of individual programs. That can
> be important when trying to manage two different VOIP apps, video
> games and Pandora at the same time.

If you wish to use it then do so... :-)

The thing (idea) I was trying to convey but seems to escape most people
is this:
"Cut out the fat!" - "Less is more/do more with less [resources]" etc...
in a general sense. That's what Contiki is doing and what I think
software in general should be doing (yes, in Utopia)... When adding
layer upon layer, we are going in the wrong direction (unless the sum is
less, which it, in my "eyes", seems not to be).

[1] https://secure.wikimedia.org/wikipedia/en/wiki/Enlightened_Sound_Daemon

Best regards

Peter K

Re: [gentoo-user] [OT rant] udev + /usr

[Michael Mol]

On Mon, Sep 19, 2011 at 12:23 PM, pk <peterk2@coolmail.se> wrote:
> On 2011-09-18 21:52, Michael Mol wrote:
>
>> The kernel configuration process is actually very nice and very easy.
>> You an remove any features you don't want or need. (I'm referring to,
>> e.g. menuconfig. I haven't really used genkernel)
>
> I've never used genkernel and always compile my own kernels...
>
>> FWIW, PulseAudio predates Windows Vista, Windows 7, even MacOS X. I
>> ran it on a 200MHz machine back when it was called Enlightenment Sound
>> Daemon.
>
> Hm... I've used ESD (years and years ago :-) ) in OSS times. Not sure
> where the connection between ESD and Pulseaudio is though[1]... Well,
> anywho, Gentoo stopped supporting both the ESD and arts server years ago
> for security reasons IIRC.
> [1] https://secure.wikimedia.org/wikipedia/en/wiki/Enlightened_Sound_Daemon

My recollection at the time PA started showing up was that PA was the
descendant of ESD. I assumed it was a fork. I may be wrong.

>> With as much as I've poked at PulseAudio, I'd have to say I like it
>> better than I like the Vista/Win7 implementation of sound daemons.
>
> I've no experience with Vista/Win7 (I've got an XP machine for gaming).

Windows coding is my day job. Workstation is Win7 Ultimate x64.

>
>> There's probably not much one can do with PA that one couldn't do with
>> jackd, which is probably better in terms of latency, but I never got
>> around to learning jackd.
>
> Yes, tried jack a few years ago but couldn't get it working right. Not
> that I got "burnt" by it (as dbus etc.) and if the need arise, I'll look
> into it again... Thing is, ALSA already have a (simple) sound server
> "built" in called dmix so why one would bother with Pulseaudio is beyond
> me (but as long as it's not "forced" onto users I don't care much about it).

I recall reading about dmix in LinuxJournal years ago, but I don't
think I ever got around to setting it up; ALSA was just going through
a major API change around 0.9, and I didn't have the resources to stay
up-to-date. (Dial-up was a pain. I imagine it's worse today) I did
have fantasies about using it to set up a fake sound device to get
spatial audio over headphones. I couldn't find the data set I'd needed
for calculating delays, though.

>
>> While I was using PA (I'm not, currently), it was nice for being able
>> to monitor and tune the volume levels of individual programs. That can
>> be important when trying to manage two different VOIP apps, video
>> games and Pandora at the same time.
>
> If you wish to use it then do so... :-)
>
> The thing (idea) I was trying to convey but seems to escape most people
> is this:
> "Cut out the fat!" - "Less is more/do more with less [resources]" etc...
> in a general sense. That's what Contiki is doing and what I think
> software in general should be doing (yes, in Utopia)... When adding
> layer upon layer, we are going in the wrong direction (unless the sum is
> less, which it, in my "eyes", seems not to be).

Oh, certainly. That's one of the reasons I love Linux's (and
especially Gentoo's) modularity so much; there's often a nearly-ideal
tool for any given use case. That's part of why I don't like to see
things which break that modularity become mandatory.


-- 
:wq

Re: [gentoo-user] [OT rant] udev + /usr

[Volker Armin Hemmann]

Am Montag 19 September 2011, 12:37:16 schrieb Michael Mol:

> I recall reading about dmix in LinuxJournal years ago, but I don't
> think I ever got around to setting it up; 

you don't set it up. It just works. If your sound card does not do hardware 
mixing (onboard sound doesn't) you are using dmix.

-- 
#163933

Re: [gentoo-user] [OT rant] udev + /usr

[Michael Mol]

On Mon, Sep 19, 2011 at 1:42 PM, Volker Armin Hemmann
<volkerarmin@googlemail.com> wrote:
> Am Montag 19 September 2011, 12:37:16 schrieb Michael Mol:
>
>> I recall reading about dmix in LinuxJournal years ago, but I don't
>> think I ever got around to setting it up;
>
> you don't set it up. It just works. If your sound card does not do hardware
> mixing (onboard sound doesn't) you are using dmix.

Ah. As I said, I hadn't poked or researched dmix since I read about it
in LinuxJournal. Pretty sure that particular issue came out over ten
years ago.

That doesn't quite jive with my experience with apps some apps
managing to take exclusive control over sound devices. In particular,
if, e.g. Flash were run under Firefox before WINE or PulseAudio, then
the latter two didn't get to play.*



* Yes, I know (and have used) the solutions to these kinds of problems
when using PA. That's beside the point.

-- 
:wq

Re: [gentoo-user] [OT rant] udev + /usr

[Alan McKinnon]

On Mon, 19 Sep 2011 14:02:39 -0400
Michael Mol <mikemol@gmail.com> wrote:

> On Mon, Sep 19, 2011 at 1:42 PM, Volker Armin Hemmann
> <volkerarmin@googlemail.com> wrote:
> > Am Montag 19 September 2011, 12:37:16 schrieb Michael Mol:
> >
> >> I recall reading about dmix in LinuxJournal years ago, but I don't
> >> think I ever got around to setting it up;
> >
> > you don't set it up. It just works. If your sound card does not do
> > hardware mixing (onboard sound doesn't) you are using dmix.
> 
> Ah. As I said, I hadn't poked or researched dmix since I read about it
> in LinuxJournal. Pretty sure that particular issue came out over ten
> years ago.
> 
> That doesn't quite jive with my experience with apps some apps
> managing to take exclusive control over sound devices. In particular,
> if, e.g. Flash were run under Firefox before WINE or PulseAudio, then
> the latter two didn't get to play.*

Flash isn't a good example though. It just assumes that it is the most
important (only?) thing in the universe, and tries to take over the
hardware for itself. If I read recent blogs correctly, even Windows
users suffer from the same thing with Flash.

I think the presumption in this thread in that sound apps make *some*
attempt to play nicely - Flash doesn't fit that category. The only
category it fits is "useless crap that should either be deleted or only
used when absolutely necessary"





-- 
Alan McKinnnon
alan.mckinnon@gmail.com

Re: [gentoo-user] [OT rant] udev + /usr

[Michael Mol]

On Mon, Sep 19, 2011 at 3:20 PM, Alan McKinnon <alan.mckinnon@gmail.com> wrote:
> On Mon, 19 Sep 2011 14:02:39 -0400
> Michael Mol <mikemol@gmail.com> wrote:
>> On Mon, Sep 19, 2011 at 1:42 PM, Volker Armin Hemmann
>> <volkerarmin@googlemail.com> wrote:
>> > Am Montag 19 September 2011, 12:37:16 schrieb Michael Mol:
>> >
>> >> I recall reading about dmix in LinuxJournal years ago, but I don't
>> >> think I ever got around to setting it up;
>> >
>> > you don't set it up. It just works. If your sound card does not do
>> > hardware mixing (onboard sound doesn't) you are using dmix.
>>
>> Ah. As I said, I hadn't poked or researched dmix since I read about it
>> in LinuxJournal. Pretty sure that particular issue came out over ten
>> years ago.
>>
>> That doesn't quite jive with my experience with apps some apps
>> managing to take exclusive control over sound devices. In particular,
>> if, e.g. Flash were run under Firefox before WINE or PulseAudio, then
>> the latter two didn't get to play.*
>
> Flash isn't a good example though. It just assumes that it is the most
> important (only?) thing in the universe, and tries to take over the
> hardware for itself. If I read recent blogs correctly, even Windows
> users suffer from the same thing with Flash.

Audio, I don't *think* so. At the very least, Vista and 7 allow you to
configure whether or not applications are allowed to take exclusive
control over a device.

Video inputs, yes.

>
> I think the presumption in this thread in that sound apps make *some*
> attempt to play nicely - Flash doesn't fit that category. The only
> category it fits is "useless crap that should either be deleted or only
> used when absolutely necessary"

That actually makes for a really good argument to use something like
PA's ALSA wrapper when you can't do without Flash. I hear recent
versions of Flash support PA directly.

I can see an argument for Flash wanting control over A/V hardware;
audio and video recorders have been implemented in it. Flash, IME,
doesn't grab A/V until a Flash applet access them, but it also doesn't
let them go. Perhaps their internal VM is poorly defined such that
it's OK for apps to assume that once they have a resource, it's always
there, and they're stuck maintaining that VM model for compatibility.

-- 
:wq

Re: [gentoo-user] [OT rant] udev + /usr

[Volker Armin Hemmann]

Am Montag 19 September 2011, 21:20:30 schrieb Alan McKinnon:
> On Mon, 19 Sep 2011 14:02:39 -0400
> 
> Michael Mol <mikemol@gmail.com> wrote:
> > On Mon, Sep 19, 2011 at 1:42 PM, Volker Armin Hemmann
> > 
> > <volkerarmin@googlemail.com> wrote:
> > > Am Montag 19 September 2011, 12:37:16 schrieb Michael Mol:
> > >> I recall reading about dmix in LinuxJournal years ago, but I don't
> > >> think I ever got around to setting it up;
> > > 
> > > you don't set it up. It just works. If your sound card does not do
> > > hardware mixing (onboard sound doesn't) you are using dmix.
> > 
> > Ah. As I said, I hadn't poked or researched dmix since I read about it
> > in LinuxJournal. Pretty sure that particular issue came out over ten
> > years ago.
> > 
> > That doesn't quite jive with my experience with apps some apps
> > managing to take exclusive control over sound devices. In particular,
> > if, e.g. Flash were run under Firefox before WINE or PulseAudio, then
> > the latter two didn't get to play.*
> 
> Flash isn't a good example though. It just assumes that it is the most
> important (only?) thing in the universe, and tries to take over the
> hardware for itself. If I read recent blogs correctly, even Windows
> users suffer from the same thing with Flash.
> 
> I think the presumption in this thread in that sound apps make *some*
> attempt to play nicely - Flash doesn't fit that category. The only
> category it fits is "useless crap that should either be deleted or only
> used when absolutely necessary"

I am sure that I am able to listen to sound from flash and vlc at the same 
time.

I am using a sound card with hardware mixing tho.
-- 
#163933

Re: [gentoo-user] [OT rant] udev + /usr

[Neil Bothwick]

[-- Attachment #1: Type: text/plain, Size: 554 bytes --]

On Mon, 19 Sep 2011 14:02:39 -0400, Michael Mol wrote:

> > you don't set it up. It just works. If your sound card does not do
> > hardware mixing (onboard sound doesn't) you are using dmix.  
> 
> Ah. As I said, I hadn't poked or researched dmix since I read about it
> in LinuxJournal. Pretty sure that particular issue came out over ten
> years ago.

Ten years ago, you did have to set up software mixing in ALSA manually.


-- 
Neil Bothwick

What did the first man to discover you can get milk from cows think he
was doing? - anon.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-user] [OT rant] udev + /usr

[Paul Colquhoun]

On Sun, 18 Sep 2011 09:31:56 AM Canek Peláez Valdés wrote:


> Just don't expect everybody to run our systems without the modern
> parts of the stack just because a Commodore 64 cannot run it.
> 
> Many of us actually like the modern features of the kernel, glibc,
> udev, dbus, systemd, pulseaudio, glib, X.org, GStreamer, Gtk+ and
> GNOME (or Qt and KDE). In my case (and I have used Linux for a long
> time), the whole stack looks full of awsomeness, and stuff just works
> most of the time.
> 
> So yeah, we use more CPU cycles, more memory and more hard drive. From
> my POV, we get more than that in new and improved functionality.


Just don't forget that the desktop isn't the whole world, and allow the 
backroom server guys to turn off all the bells, whistles and pretty lights so 
they can get the best performance from their web servers, mail servers, DNS 
servers, etc.


-- 
Reverend Paul Colquhoun, ULC.    http://andor.dropbear.id.au/~paulcol
 Before you criticize someone, you should walk a mile in their shoes.
Then, when you do, you'll be a mile away, and you'll have their shoes.

Re: [gentoo-user] [OT rant] udev + /usr

[Volker Armin Hemmann]

Am Montag 19 September 2011, 16:21:08 schrieb Paul Colquhoun:
> On Sun, 18 Sep 2011 09:31:56 AM Canek Peláez Valdés wrote:
> > Just don't expect everybody to run our systems without the modern
> > parts of the stack just because a Commodore 64 cannot run it.
> > 
> > Many of us actually like the modern features of the kernel, glibc,
> > udev, dbus, systemd, pulseaudio, glib, X.org, GStreamer, Gtk+ and
> > GNOME (or Qt and KDE). In my case (and I have used Linux for a long
> > time), the whole stack looks full of awsomeness, and stuff just works
> > most of the time.
> > 
> > So yeah, we use more CPU cycles, more memory and more hard drive. From
> > my POV, we get more than that in new and improved functionality.
> 
> Just don't forget that the desktop isn't the whole world, and allow the
> backroom server guys to turn off all the bells, whistles and pretty lights
> so they can get the best performance from their web servers, mail servers,
> DNS servers, etc.

there are at least two kinds of servers - those who don't need bells and 
whistles and run happily on an intel atom.

And those who really do need bells and whistles. I am sure you wouldn't want 
to build such from scratch.

Luckily as a desktop linux user I do not have to care about those guys. And 
these guys don't have to care about me. Isn't that great?

-- 
#163933

Re: [gentoo-user] [OT rant] udev + /usr

[Volker Armin Hemmann]

Am Sonntag 18 September 2011, 15:19:29 schrieb pk:
> On 2011-09-18 14:32, Volker Armin Hemmann wrote:
> > So you are going from a single bug to 'it must be evil'. If you do that
> > all the time there isn't much software left.
> 
> You said: "I bet you can't even measure a
> difference between dbus running and dbus not running in speed or
> responsiveness of your gui."
> 
> I only pointed out that that was not always correct (I don't run
> Ubuntu). And I have had a _lot_ of problems with dbus (again, this was
> years ago, running binary distros - it's only recently that I had dbus
> installed again due to Xfce4 requiring it); if I get burnt by some piece
> of software (usually it's gnome/freedesktop related - seems a lot of bad
> ideas/implementations come from that "place") I try to go "elsewhere".
> So if your experience with dbus is different, then fine, by all means
> use it; it is your choice. But I choose to avoid it, if possible.
> 
> And yes, it seems no matter how hard I try the "gnome" paradigm ('evil'
> software) seems to be inching ever closer... I think developers, in
> general, should take some hints from this guy:
> http://www.sics.se/~adam/
> ... he created this:
> http://www.contiki-os.org/p/about-contiki.html
> ... running this:
> http://www.c64web.com/
> 
> Best regards
> 
> Peter k

well, I haven't run in that dbus-uses-100%-cpu bug. But I also take every and 
all ubuntu bug reports with a huge amount of salt because of all the patches 
they include.

But:

106       2740  0.0  0.0  20296  1484 ?        Ss   Sep11   0:20 
/usr/bin/dbus-daemon --system
1000      4852  0.0  0.0  18124   420 ?        S    Sep11   0:00 
/usr/bin/dbus-launch --sh-syntax --exit-with-session
1000      4853  0.1  0.0  16576  4916 ?        Ss   Sep11  11:20 
/usr/bin/dbus-daemon --fork --print-pid 5 --print-address 7 --session
root      5535  0.0  0.0  18268   560 pts/0    S    Sep11   0:00 dbus-launch 
--autolaunch bd5372f2e9f3742ccd79bd310000000a --binary-syntax --close-stderr
root      5536  0.0  0.0  11268   624 ?        Ss   Sep11   0:00 
/usr/bin/dbus-daemon --fork --print-pid 5 --print-address 7 --session
1000     21585  0.0  0.0 106240   912 pts/5    S+   15:34   0:00 grep dbus

uptime
 15:35:37 up 7 days, 14:37, 11 users,  load average: 0.14, 0.06, 0.05

again, if it you say 'it must be bad because there is a bug in it' you can 
disregard all software ever written. On a normal, not ubuntu system you won't 
notice dbus running.

And since you have one standardized IPC system in place, all the apps don't 
need to invent another one resulting in less code executed, less code in ram 
and less code on your harddisk.


-- 
#163933

Re: [gentoo-user] [OT rant] udev + /usr

[Michael Mol]

On Sun, Sep 18, 2011 at 9:37 AM, Volker Armin Hemmann
<volkerarmin@googlemail.com> wrote:
> Am Sonntag 18 September 2011, 15:19:29 schrieb pk:
> again, if it you say 'it must be bad because there is a bug in it' you can
> disregard all software ever written.

This is why, when designing systems, you want as little complexity as
possible; the greater the complexity, the greater the incidence of
bugs. Yes, it's unavoidable that there are bugs, but lower bug counts
are better.

(Not making a specific argument against D-Bus here, just the rhetorical device.)

-- 
:wq

Re: [gentoo-user] [OT rant] udev + /usr

[Volker Armin Hemmann]

Am Sonntag 18 September 2011, 09:58:10 schrieb Michael Mol:
> On Sun, Sep 18, 2011 at 9:37 AM, Volker Armin Hemmann
> 
> <volkerarmin@googlemail.com> wrote:
> > Am Sonntag 18 September 2011, 15:19:29 schrieb pk:
> > again, if it you say 'it must be bad because there is a bug in it' you
> > can disregard all software ever written.
> 
> This is why, when designing systems, you want as little complexity as
> possible; the greater the complexity, the greater the incidence of
> bugs. Yes, it's unavoidable that there are bugs, but lower bug counts
> are better.
> 
> (Not making a specific argument against D-Bus here, just the rhetorical
> device.)

yeah and if you simplified your system enough it is so hard to use it is not 
worth the time you waste on it.

Every problem can be solved by another layer of abstraction

A similar good sounding quote - but.....
-- 
#163933

Re: [gentoo-user] [OT rant] udev + /usr

[Michael Mol]

On Sun, Sep 18, 2011 at 5:07 PM, Volker Armin Hemmann
<volkerarmin@googlemail.com> wrote:
> Am Sonntag 18 September 2011, 09:58:10 schrieb Michael Mol:
>> On Sun, Sep 18, 2011 at 9:37 AM, Volker Armin Hemmann
>>
>> <volkerarmin@googlemail.com> wrote:
>> > Am Sonntag 18 September 2011, 15:19:29 schrieb pk:
>> > again, if it you say 'it must be bad because there is a bug in it' you
>> > can disregard all software ever written.
>>
>> This is why, when designing systems, you want as little complexity as
>> possible; the greater the complexity, the greater the incidence of
>> bugs. Yes, it's unavoidable that there are bugs, but lower bug counts
>> are better.
>>
>> (Not making a specific argument against D-Bus here, just the rhetorical
>> device.)
>
> yeah and if you simplified your system enough it is so hard to use it is not
> worth the time you waste on it.

And if you solve every problem with another layer or patch to mask
complexity cases, you haven't usually eliminated edge cases, you've
only moved them to somewhere discounted or (worse) undiscovered. You
*certainly* haven't reduced system complexity.

>
> Every problem can be solved by another layer of abstraction

"Any problem in computer science can be solved with another layer of
indirection, but that usually will create another problem." - David
Wheeler

-- 
:wq

Re: [gentoo-user] [OT rant] udev + /usr

[Canek Peláez Valdés]

On Sun, Sep 18, 2011 at 6:03 AM, Volker Armin Hemmann
<volkerarmin@googlemail.com> wrote:
> Am Sonntag 18 September 2011, 11:23:43 schrieb pk:
>> On 2011-09-18 09:37, Alan McKinnon wrote:
>> > Other systems may start to use it if it proves itself useful. Lucky for
>> > us, it doesn't obsolete anything else, just adds functionality to what
>> > is already there.
>>
>> Although, one thing which I find very annoying is that the things that
>> depend on it starts dbus-launch/daemon no matter if I don't want to run
>> it or not (it's not running acc. to rc-update show but ps -ef shows both
>> dbus-launch and dbus-daemon running). I'm using Xfce4 and have Audacious
>> installed which depends on dbus-glib, which of course depends on dbus
>> itself. No other packages uses it (USE= -dbus). Xfce4 and Audacious
>> hasn't used dbus before a certain version (at least it has not been
>> mandatory) and I've been using them for years (haven't had the time to
>> look for alternatives yet).
>>  In general I have a problem with packages that pulls in *something*
>> which in turn depends on *something else* which in turn... overlapping
>> functionality etc. It's quite troublesome to keep, for instance, gconf
>> out of my system (masked by me to detect any "upgrades" that tries to
>> pull it in)...
>>
>> In my "world" software (in general) should not become an "obstacle"; it
>> is just a tool to accomplish whatever you want it to do. Ideally the OS
>> (and whatever interfaces the user) shouldn't consume _any_ resources at
>> all (yes, I'm well aware that it's not possible). Resource usage should
>> at least be kept to a minimum, otherwise I have to buy new faster
>> hardware for each "upgrade" (be it for security, for functionality etc.)
>> and if I liked that I could just go with Windows. My whole complaint
>> about this udev business is that we're "ballooning" out of control, IMO,
>> becoming the "monster" that, I assume, most of us wanted to avoid.
>>
>> PS. My animosity towards dbus is "historical"; I did use it years ago
>> (together with gnome, gconf etc.) which caused me nothing but trouble.
>> I've avoided that crap ever since. I do agree that the idea _behind_
>> dbus seems sensible but I'm not so sure about the implementation.
>>
>> Best regards
>>
>> Peter K
>
> years ago? is gnome even using dbus for years? They had their broken
> corba/orbit/bonobo stuff.

They used ORBit/bonobo during 1.0 and 1.2 series. With GNOME 2.0, and
when dbus got stable (1.0), they started migrating stuff to it, but
they keep bonobo around for compatibility reasons. With GNOME 3,
bonobo is completely deprecated, and everything needing IPC should use
dbus.

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

Re: [gentoo-user] [OT rant] udev + /usr

[Volker Armin Hemmann]

Am Sonntag 18 September 2011, 09:15:25 schrieb Canek Peláez Valdés:
> On Sun, Sep 18, 2011 at 6:03 AM, Volker Armin Hemmann
> 
> <volkerarmin@googlemail.com> wrote:
> > Am Sonntag 18 September 2011, 11:23:43 schrieb pk:
> >> On 2011-09-18 09:37, Alan McKinnon wrote:
> >> > Other systems may start to use it if it proves itself useful.
> >> > Lucky for us, it doesn't obsolete anything else, just adds
> >> > functionality to what is already there.
> >> 
> >> Although, one thing which I find very annoying is that the things that
> >> depend on it starts dbus-launch/daemon no matter if I don't want to
> >> run
> >> it or not (it's not running acc. to rc-update show but ps -ef shows
> >> both
> >> dbus-launch and dbus-daemon running). I'm using Xfce4 and have
> >> Audacious
> >> installed which depends on dbus-glib, which of course depends on dbus
> >> itself. No other packages uses it (USE= -dbus). Xfce4 and Audacious
> >> hasn't used dbus before a certain version (at least it has not been
> >> mandatory) and I've been using them for years (haven't had the time to
> >> look for alternatives yet).
> >>  In general I have a problem with packages that pulls in *something*
> >> which in turn depends on *something else* which in turn... overlapping
> >> functionality etc. It's quite troublesome to keep, for instance, gconf
> >> out of my system (masked by me to detect any "upgrades" that tries to
> >> pull it in)...
> >> 
> >> In my "world" software (in general) should not become an "obstacle";
> >> it
> >> is just a tool to accomplish whatever you want it to do. Ideally the
> >> OS
> >> (and whatever interfaces the user) shouldn't consume _any_ resources
> >> at
> >> all (yes, I'm well aware that it's not possible). Resource usage
> >> should
> >> at least be kept to a minimum, otherwise I have to buy new faster
> >> hardware for each "upgrade" (be it for security, for functionality
> >> etc.)
> >> and if I liked that I could just go with Windows. My whole complaint
> >> about this udev business is that we're "ballooning" out of control,
> >> IMO,
> >> becoming the "monster" that, I assume, most of us wanted to avoid.
> >> 
> >> PS. My animosity towards dbus is "historical"; I did use it years ago
> >> (together with gnome, gconf etc.) which caused me nothing but trouble.
> >> I've avoided that crap ever since. I do agree that the idea _behind_
> >> dbus seems sensible but I'm not so sure about the implementation.
> >> 
> >> Best regards
> >> 
> >> Peter K
> > 
> > years ago? is gnome even using dbus for years? They had their broken
> > corba/orbit/bonobo stuff.
> 
> They used ORBit/bonobo during 1.0 and 1.2 series. With GNOME 2.0, and
> when dbus got stable (1.0), they started migrating stuff to it, but
> they keep bonobo around for compatibility reasons. With GNOME 3,
> bonobo is completely deprecated, and everything needing IPC should use
> dbus.
> 
> Regards.

ah, didn't know that. I read about some dbus problems when KDE was moving over 
caused by dbus being to gnome-centric. But I never cared to much about it.
-- 
#163933

Re: [gentoo-user] udev + /usr

[Michael Orlitzky]

On 09/17/2011 07:00 PM, Alan McKinnon wrote:
> 
> There was a standards body tracking ORB, I forget which one, but none
> of that matters as the folks who should use it - system builders - saw
> it's flaws quite quickly. Even Gnome has dropped it and are now moving
> over to dbus.

Ooh, I know this one, because it's my all-time favorite website:

  http://www.omg.org/

Re: [gentoo-user] udev + /usr

[pk]

On 2011-09-17 20:36, Canek Peláez Valdés wrote:

> They are standard in the sense that they are a low level communication
> standard API. An IPC is *way* more than that;  dbus is an IPC, because

https://secure.wikimedia.org/wikipedia/en/wiki/Inter-process_communication

> then you have high level "objects" and "methods", no matter the
> language of the two sides of the wire communicating, or even if the
> objects live in the same computer or not.

Acc. to this link, dbus currently only uses unix sockets (so the
"objects" must live on the same computer)...
https://secure.wikimedia.org/wikipedia/en/wiki/D-Bus

> is a complete IPC system. Neither sockets, shared memory nor pipes are
> an IPC, because they lack a well defined protocol. You *can* do the

See above.

Also:
https://www.ibm.com/developerworks/aix/library/au-ipc/

dbus is installed in my system, but only because I run Xfce4 (I am
thinking of installing something else due to it's becoming bloated just
like gnome). And I have "-dbus" in my global make.conf.

PS. I am quite astonished at the fact that I have a computer that is
_way_ faster than the first machine I installed GNU/Linux (an Amiga 4000
with a 68040 cpu at 40Mhz) on but the "experience" is still the same; it
takes about the same time to boot, the same time (or even slower) to
load a program. It seems the faster the computer the more I have to wait
for it to finish some task. Contradictory, no? Wonder why that is...
(bloat?).

Best regards

Peter K

Re: [gentoo-user] udev + /usr

[Canek Peláez Valdés]

On Sat, Sep 17, 2011 at 5:03 PM, pk <peterk2@coolmail.se> wrote:
> On 2011-09-17 20:36, Canek Peláez Valdés wrote:
>
>> They are standard in the sense that they are a low level communication
>> standard API. An IPC is *way* more than that;  dbus is an IPC, because
>
> https://secure.wikimedia.org/wikipedia/en/wiki/Inter-process_communication
>
>> then you have high level "objects" and "methods", no matter the
>> language of the two sides of the wire communicating, or even if the
>> objects live in the same computer or not.
>
> Acc. to this link, dbus currently only uses unix sockets (so the
> "objects" must live on the same computer)...
> https://secure.wikimedia.org/wikipedia/en/wiki/D-Bus

You can use AF_INET and AF_INET6 sockets for dbus messages (I *think*
I even remember seeing an implementation), but in practive I believe
nobody actually has done it.

>> is a complete IPC system. Neither sockets, shared memory nor pipes are
>> an IPC, because they lack a well defined protocol. You *can* do the
>
> See above.
>
> Also:
> https://www.ibm.com/developerworks/aix/library/au-ipc/
>
> dbus is installed in my system, but only because I run Xfce4 (I am
> thinking of installing something else due to it's becoming bloated just
> like gnome). And I have "-dbus" in my global make.conf.
>
> PS. I am quite astonished at the fact that I have a computer that is
> _way_ faster than the first machine I installed GNU/Linux (an Amiga 4000
> with a 68040 cpu at 40Mhz) on but the "experience" is still the same; it
> takes about the same time to boot, the same time (or even slower) to
> load a program. It seems the faster the computer the more I have to wait
> for it to finish some task. Contradictory, no? Wonder why that is...
> (bloat?).

I like to call them "new features", but I see your point. I myself
prefer the new features. I gladly sacrifice a few cycles from my CPU
and a few megabytes from my harddrive to run my GNOME 3 desktop.

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

[gentoo-user] Re: udev + /usr

[Nicolas Sebrecht]

The 17/09/11, pk wrote:

> dbus is installed in my system, but only because I run Xfce4 (I am
> thinking of installing something else due to it's becoming bloated just
> like gnome). And I have "-dbus" in my global make.conf.
> 
> PS. I am quite astonished at the fact that I have a computer that is
> _way_ faster than the first machine I installed GNU/Linux (an Amiga 4000
> with a 68040 cpu at 40Mhz) on but the "experience" is still the same; it
> takes about the same time to boot, the same time (or even slower) to
> load a program. It seems the faster the computer the more I have to wait
> for it to finish some task. Contradictory, no? Wonder why that is...
> (bloat?).

Believe it or not but I bet you're not doing the same tasks with your
modern machine and could just not run the user-end software you use
today on a Amiga 4000 with a 68040 cpu at 40Mhz because they learn new
feature since then.

Bloat?

-- 
Nicolas Sebrecht

Re: [gentoo-user] Re: udev + /usr

[Alan McKinnon]

On Mon, 19 Sep 2011 10:30:41 +0200
Nicolas Sebrecht <nsebrecht@piing.fr> wrote:

> The 17/09/11, pk wrote:
> 
> > dbus is installed in my system, but only because I run Xfce4 (I am
> > thinking of installing something else due to it's becoming bloated
> > just like gnome). And I have "-dbus" in my global make.conf.
> > 
> > PS. I am quite astonished at the fact that I have a computer that is
> > _way_ faster than the first machine I installed GNU/Linux (an Amiga
> > 4000 with a 68040 cpu at 40Mhz) on but the "experience" is still
> > the same; it takes about the same time to boot, the same time (or
> > even slower) to load a program. It seems the faster the computer
> > the more I have to wait for it to finish some task. Contradictory,
> > no? Wonder why that is... (bloat?).
> 
> Believe it or not but I bet you're not doing the same tasks with your
> modern machine and could just not run the user-end software you use
> today on a Amiga 4000 with a 68040 cpu at 40Mhz because they learn new
> feature since then.

:-)  Example:

Try run a browser on that Amiga. I doubt it would even manage to
display the Gentoo logo at http://www.gentoo.org.

And forget all about playing music.


-- 
Alan McKinnnon
alan.mckinnon@gmail.com

Re: [gentoo-user] Re: udev + /usr

[Michael Schreckenbauer]

On Monday, 19. September 2011 16:22:31 Alan McKinnon wrote:
> On Mon, 19 Sep 2011 10:30:41 +0200
> 
> Nicolas Sebrecht <nsebrecht@piing.fr> wrote:
> > The 17/09/11, pk wrote:
> > > dbus is installed in my system, but only because I run Xfce4 (I am
> > > thinking of installing something else due to it's becoming bloated
> > > just like gnome). And I have "-dbus" in my global make.conf.
> > > 
> > > PS. I am quite astonished at the fact that I have a computer that is
> > > _way_ faster than the first machine I installed GNU/Linux (an Amiga
> > > 4000 with a 68040 cpu at 40Mhz) on but the "experience" is still
> > > the same; it takes about the same time to boot, the same time (or
> > > even slower) to load a program. It seems the faster the computer
> > > the more I have to wait for it to finish some task. Contradictory,
> > > no? Wonder why that is... (bloat?).
> > 
> > Believe it or not but I bet you're not doing the same tasks with your
> > modern machine and could just not run the user-end software you use
> > today on a Amiga 4000 with a 68040 cpu at 40Mhz because they learn new
> > feature since then.
> :
> :-)  Example:
> Try run a browser on that Amiga. I doubt it would even manage to
> display the Gentoo logo at http://www.gentoo.org.

http://en.wikipedia.org/wiki/Origyn_Web_Browser

> And forget all about playing music.

Best,
Michael

Re: [gentoo-user] Re: udev + /usr

[Volker Armin Hemmann]

Am Montag 19 September 2011, 16:41:08 schrieb Michael Schreckenbauer:
> On Monday, 19. September 2011 16:22:31 Alan McKinnon wrote:
> > On Mon, 19 Sep 2011 10:30:41 +0200
> > 
> > Nicolas Sebrecht <nsebrecht@piing.fr> wrote:
> > > The 17/09/11, pk wrote:
> > > > dbus is installed in my system, but only because I run Xfce4 (I
> > > > am
> > > > thinking of installing something else due to it's becoming
> > > > bloated
> > > > just like gnome). And I have "-dbus" in my global make.conf.
> > > > 
> > > > PS. I am quite astonished at the fact that I have a computer
> > > > that is
> > > > _way_ faster than the first machine I installed GNU/Linux (an
> > > > Amiga
> > > > 4000 with a 68040 cpu at 40Mhz) on but the "experience" is still
> > > > the same; it takes about the same time to boot, the same time
> > > > (or
> > > > even slower) to load a program. It seems the faster the computer
> > > > the more I have to wait for it to finish some task.
> > > > Contradictory,
> > > > no? Wonder why that is... (bloat?).
> > > 
> > > Believe it or not but I bet you're not doing the same tasks with
> > > your
> > > modern machine and could just not run the user-end software you use
> > > today on a Amiga 4000 with a 68040 cpu at 40Mhz because they learn
> > > new
> > > feature since then.
> > :
> > :-)  Example:
> > Try run a browser on that Amiga. I doubt it would even manage to
> > display the Gentoo logo at http://www.gentoo.org.
> 
> http://en.wikipedia.org/wiki/Origyn_Web_Browser

and I am sure that it will display pngs and jpegs with full colours just fine.
I am sure displaying 2 or 4 MP pictures will be working great. Just like the 
mpeg4 you are trying to watch. Or the ogv.

> 
> > And forget all about playing music.

well, the amiga can play mp3. But don't expect it to be usable for anything 
else while doing so.

So watching a music video while having a douzend wikipedia-tabs open and a 
mailbox with 60000 mails replying to one?

No, not really.


-- 
#163933

Re: [gentoo-user] Re: udev + /usr

[Michael Schreckenbauer]

On Monday, 19. September 2011 18:36:18 Volker Armin Hemmann wrote:
> Am Montag 19 September 2011, 16:41:08 schrieb Michael Schreckenbauer:
> > On Monday, 19. September 2011 16:22:31 Alan McKinnon wrote:
> > > On Mon, 19 Sep 2011 10:30:41 +0200
> > > 
> > > Nicolas Sebrecht <nsebrecht@piing.fr> wrote:
> > > > The 17/09/11, pk wrote:
> > > > > dbus is installed in my system, but only because I run Xfce4
> > > > > (I
> > > > > am
> > > > > thinking of installing something else due to it's becoming
> > > > > bloated
> > > > > just like gnome). And I have "-dbus" in my global make.conf.
> > > > > 
> > > > > PS. I am quite astonished at the fact that I have a computer
> > > > > that is
> > > > > _way_ faster than the first machine I installed GNU/Linux
> > > > > (an
> > > > > Amiga
> > > > > 4000 with a 68040 cpu at 40Mhz) on but the "experience" is
> > > > > still
> > > > > the same; it takes about the same time to boot, the same
> > > > > time
> > > > > (or
> > > > > even slower) to load a program. It seems the faster the
> > > > > computer
> > > > > the more I have to wait for it to finish some task.
> > > > > Contradictory,
> > > > > no? Wonder why that is... (bloat?).
> > > > 
> > > > Believe it or not but I bet you're not doing the same tasks with
> > > > your
> > > > modern machine and could just not run the user-end software you
> > > > use
> > > > today on a Amiga 4000 with a 68040 cpu at 40Mhz because they
> > > > learn
> > > > new
> > > > feature since then.
> > > :
> > > :-)  Example:
> > > Try run a browser on that Amiga. I doubt it would even manage to
> > > display the Gentoo logo at http://www.gentoo.org.
> > 
> > http://en.wikipedia.org/wiki/Origyn_Web_Browser
> 
> and I am sure that it will display pngs and jpegs with full colours just
> fine. I am sure displaying 2 or 4 MP pictures will be working great. Just
> like the mpeg4 you are trying to watch. Or the ogv.

I don't think so :)
But it is a web-browser, that runs on classic amiga os and I really think, 
that it can display http://www.gentoo.org just fine.

Best,
Michael

Re: [gentoo-user] Re: udev + /usr

[Volker Armin Hemmann]

Am Montag 19 September 2011, 19:25:28 schrieb Michael Schreckenbauer:
> On Monday, 19. September 2011 18:36:18 Volker Armin Hemmann wrote:
> > Am Montag 19 September 2011, 16:41:08 schrieb Michael Schreckenbauer:
> > > On Monday, 19. September 2011 16:22:31 Alan McKinnon wrote:
> > > > On Mon, 19 Sep 2011 10:30:41 +0200
> > > > 
> > > > Nicolas Sebrecht <nsebrecht@piing.fr> wrote:
> > > > > The 17/09/11, pk wrote:
> > > > > > dbus is installed in my system, but only because I run
> > > > > > Xfce4
> > > > > > (I
> > > > > > am
> > > > > > thinking of installing something else due to it's
> > > > > > becoming
> > > > > > bloated
> > > > > > just like gnome). And I have "-dbus" in my global
> > > > > > make.conf.
> > > > > > 
> > > > > > PS. I am quite astonished at the fact that I have a
> > > > > > computer
> > > > > > that is
> > > > > > _way_ faster than the first machine I installed
> > > > > > GNU/Linux
> > > > > > (an
> > > > > > Amiga
> > > > > > 4000 with a 68040 cpu at 40Mhz) on but the "experience"
> > > > > > is
> > > > > > still
> > > > > > the same; it takes about the same time to boot, the same
> > > > > > time
> > > > > > (or
> > > > > > even slower) to load a program. It seems the faster the
> > > > > > computer
> > > > > > the more I have to wait for it to finish some task.
> > > > > > Contradictory,
> > > > > > no? Wonder why that is... (bloat?).
> > > > > 
> > > > > Believe it or not but I bet you're not doing the same tasks
> > > > > with
> > > > > your
> > > > > modern machine and could just not run the user-end software
> > > > > you
> > > > > use
> > > > > today on a Amiga 4000 with a 68040 cpu at 40Mhz because they
> > > > > learn
> > > > > new
> > > > > feature since then.
> > > > :
> > > > :-)  Example:
> > > > Try run a browser on that Amiga. I doubt it would even manage to
> > > > display the Gentoo logo at http://www.gentoo.org.
> > > 
> > > http://en.wikipedia.org/wiki/Origyn_Web_Browser
> > 
> > and I am sure that it will display pngs and jpegs with full colours just
> > fine. I am sure displaying 2 or 4 MP pictures will be working great.
> > Just
> > like the mpeg4 you are trying to watch. Or the ogv.
> 
> I don't think so :)
> But it is a web-browser, that runs on classic amiga os and I really think,
> that it can display http://www.gentoo.org just fine.

so can lynx. Does it make it usefull with todays internet? There are more 
pages than just gentoo.org - The Sun for example or CNN or other high quality 
sites.


-- 
#163933

Re: [gentoo-user] Re: udev + /usr

[Michael Schreckenbauer]

On Monday, 19. September 2011 19:43:50 Volker Armin Hemmann wrote:
> Am Montag 19 September 2011, 19:25:28 schrieb Michael Schreckenbauer:
> > On Monday, 19. September 2011 18:36:18 Volker Armin Hemmann wrote:
> > > Am Montag 19 September 2011, 16:41:08 schrieb Michael Schreckenbauer:
> > > > On Monday, 19. September 2011 16:22:31 Alan McKinnon wrote:
> > > > > On Mon, 19 Sep 2011 10:30:41 +0200
> > > > > 
> > > > > Nicolas Sebrecht <nsebrecht@piing.fr> wrote:
> > > > > > The 17/09/11, pk wrote:
> > > > > > > dbus is installed in my system, but only because I
> > > > > > > run
> > > > > > > Xfce4
> > > > > > > (I
> > > > > > > am
> > > > > > > thinking of installing something else due to it's
> > > > > > > becoming
> > > > > > > bloated
> > > > > > > just like gnome). And I have "-dbus" in my global
> > > > > > > make.conf.
> > > > > > > 
> > > > > > > PS. I am quite astonished at the fact that I have a
> > > > > > > computer
> > > > > > > that is
> > > > > > > _way_ faster than the first machine I installed
> > > > > > > GNU/Linux
> > > > > > > (an
> > > > > > > Amiga
> > > > > > > 4000 with a 68040 cpu at 40Mhz) on but the
> > > > > > > "experience"
> > > > > > > is
> > > > > > > still
> > > > > > > the same; it takes about the same time to boot, the
> > > > > > > same
> > > > > > > time
> > > > > > > (or
> > > > > > > even slower) to load a program. It seems the faster
> > > > > > > the
> > > > > > > computer
> > > > > > > the more I have to wait for it to finish some task.
> > > > > > > Contradictory,
> > > > > > > no? Wonder why that is... (bloat?).
> > > > > > 
> > > > > > Believe it or not but I bet you're not doing the same
> > > > > > tasks
> > > > > > with
> > > > > > your
> > > > > > modern machine and could just not run the user-end
> > > > > > software
> > > > > > you
> > > > > > use
> > > > > > today on a Amiga 4000 with a 68040 cpu at 40Mhz because
> > > > > > they
> > > > > > learn
> > > > > > new
> > > > > > feature since then.
> > > > > :
> > > > > :-)  Example:
> > > > > Try run a browser on that Amiga. I doubt it would even
> > > > > manage to
> > > > > display the Gentoo logo at http://www.gentoo.org.
> > > > 
> > > > http://en.wikipedia.org/wiki/Origyn_Web_Browser
> > > 
> > > and I am sure that it will display pngs and jpegs with full colours
> > > just fine. I am sure displaying 2 or 4 MP pictures will be working
> > > great. Just
> > > like the mpeg4 you are trying to watch. Or the ogv.
> > 
> > I don't think so :)
> > But it is a web-browser, that runs on classic amiga os and I really
> > think, that it can display http://www.gentoo.org just fine.
> 
> so can lynx. Does it make it usefull with todays internet? There are more
> pages than just gentoo.org - The Sun for example or CNN or other high
> quality sites.

Yes, I agree. You seem to miss the point of my post completely.

Best,
Michael

Re: [gentoo-user] Re: udev + /usr

[Michael Mol]

On Mon, Sep 19, 2011 at 1:43 PM, Volker Armin Hemmann
<volkerarmin@googlemail.com> wrote:
> Am Montag 19 September 2011, 19:25:28 schrieb Michael Schreckenbauer:
>> On Monday, 19. September 2011 18:36:18 Volker Armin Hemmann wrote:
>> > Am Montag 19 September 2011, 16:41:08 schrieb Michael Schreckenbauer:
>> > > On Monday, 19. September 2011 16:22:31 Alan McKinnon wrote:
>> > > > On Mon, 19 Sep 2011 10:30:41 +0200
>> > > >
>> > > > Nicolas Sebrecht <nsebrecht@piing.fr> wrote:
>> > > > > The 17/09/11, pk wrote:
>> > > > > > dbus is installed in my system, but only because I run
>> > > > > > Xfce4
>> > > > > > (I
>> > > > > > am
>> > > > > > thinking of installing something else due to it's
>> > > > > > becoming
>> > > > > > bloated
>> > > > > > just like gnome). And I have "-dbus" in my global
>> > > > > > make.conf.
>> > > > > >
>> > > > > > PS. I am quite astonished at the fact that I have a
>> > > > > > computer
>> > > > > > that is
>> > > > > > _way_ faster than the first machine I installed
>> > > > > > GNU/Linux
>> > > > > > (an
>> > > > > > Amiga
>> > > > > > 4000 with a 68040 cpu at 40Mhz) on but the "experience"
>> > > > > > is
>> > > > > > still
>> > > > > > the same; it takes about the same time to boot, the same
>> > > > > > time
>> > > > > > (or
>> > > > > > even slower) to load a program. It seems the faster the
>> > > > > > computer
>> > > > > > the more I have to wait for it to finish some task.
>> > > > > > Contradictory,
>> > > > > > no? Wonder why that is... (bloat?).
>> > > > >
>> > > > > Believe it or not but I bet you're not doing the same tasks
>> > > > > with
>> > > > > your
>> > > > > modern machine and could just not run the user-end software
>> > > > > you
>> > > > > use
>> > > > > today on a Amiga 4000 with a 68040 cpu at 40Mhz because they
>> > > > > learn
>> > > > > new
>> > > > > feature since then.
>> > > > :
>> > > > :-)  Example:
>> > > > Try run a browser on that Amiga. I doubt it would even manage to
>> > > > display the Gentoo logo at http://www.gentoo.org.
>> > >
>> > > http://en.wikipedia.org/wiki/Origyn_Web_Browser
>> >
>> > and I am sure that it will display pngs and jpegs with full colours just
>> > fine. I am sure displaying 2 or 4 MP pictures will be working great.
>> > Just
>> > like the mpeg4 you are trying to watch. Or the ogv.
>>
>> I don't think so :)
>> But it is a web-browser, that runs on classic amiga os and I really think,
>> that it can display http://www.gentoo.org just fine.
>
> so can lynx. Does it make it usefull with todays internet? There are more
> pages than just gentoo.org - The Sun for example or CNN or other high quality
> sites.

Did you even read the WP link noted?

-- 
:wq

Re: [gentoo-user] Re: udev + /usr

[Alan McKinnon]

On Mon, 19 Sep 2011 19:43:50 +0200
Volker Armin Hemmann <volkerarmin@googlemail.com> wrote:

> > But it is a web-browser, that runs on classic amiga os and I really
> > think, that it can display http://www.gentoo.org just fine.  
> 
> so can lynx. Does it make it usefull with todays internet? There are
> more pages than just gentoo.org - The Sun for example or CNN or other
> high quality sites.

"The Sun", "CNN" and "high quality site" do not belong in the same
sentence. Unless you were juxtaposing the first two against the third

-- 
Alan McKinnnon
alan.mckinnon@gmail.com

Re: [gentoo-user] Re: udev + /usr

[Volker Armin Hemmann]

Am Montag 19 September 2011, 21:12:57 schrieb Alan McKinnon:
> On Mon, 19 Sep 2011 19:43:50 +0200
> 
> Volker Armin Hemmann <volkerarmin@googlemail.com> wrote:
> > > But it is a web-browser, that runs on classic amiga os and I really
> > > think, that it can display http://www.gentoo.org just fine.
> > 
> > so can lynx. Does it make it usefull with todays internet? There are
> > more pages than just gentoo.org - The Sun for example or CNN or other
> > high quality sites.
> 
> "The Sun", "CNN" and "high quality site" do not belong in the same
> sentence. Unless you were juxtaposing the first two against the third

see them as prime examples of how fucked up a 'news' web site can be. Just to 
be 'great' they generate a lot of load - for no valuable content whatsoever. 
But they have their readership so either there are billions of idiots out 
there or there is some hidden joke in this mess that I am unable to grasp. 

-- 
#163933

Re: [gentoo-user] Re: udev + /usr

[Alan McKinnon]

On Mon, 19 Sep 2011 22:46:33 +0200
Volker Armin Hemmann <volkerarmin@googlemail.com> wrote:

> Am Montag 19 September 2011, 21:12:57 schrieb Alan McKinnon:
> > On Mon, 19 Sep 2011 19:43:50 +0200
> > 
> > Volker Armin Hemmann <volkerarmin@googlemail.com> wrote:
> > > > But it is a web-browser, that runs on classic amiga os and I
> > > > really think, that it can display http://www.gentoo.org just
> > > > fine.
> > > 
> > > so can lynx. Does it make it usefull with todays internet? There
> > > are more pages than just gentoo.org - The Sun for example or CNN
> > > or other high quality sites.
> > 
> > "The Sun", "CNN" and "high quality site" do not belong in the same
> > sentence. Unless you were juxtaposing the first two against the
> > third
> 
> see them as prime examples of how fucked up a 'news' web site can be.
> Just to be 'great' they generate a lot of load - for no valuable
> content whatsoever. But they have their readership so either there
> are billions of idiots out there or there is some hidden joke in this
> mess that I am unable to grasp. 
> 

Or you're wired different, just like 3 out of 4 (at least) folks on
this here mailing list.

-- 
Alan McKinnnon
alan.mckinnon@gmail.com

Re: [gentoo-user] Re: udev + /usr

[Indi]

On Mon, 19 Sep 2011 19:43:50 +0200
Volker Armin Hemmann <volkerarmin@googlemail.com> wrote:

> Am Montag 19 September 2011, 19:25:28 schrieb Michael Schreckenbauer:
> > On Monday, 19. September 2011 18:36:18 Volker Armin Hemmann wrote:
> > > Am Montag 19 September 2011, 16:41:08 schrieb Michael
> > > Schreckenbauer:
> > > > On Monday, 19. September 2011 16:22:31 Alan McKinnon wrote:
> > > > > On Mon, 19 Sep 2011 10:30:41 +0200
> > > > > 
> > > > > Nicolas Sebrecht <nsebrecht@piing.fr> wrote:
> > > > > > The 17/09/11, pk wrote:
> > > > > > > dbus is installed in my system, but only because I run
> > > > > > > Xfce4
> > > > > > > (I
> > > > > > > am
> > > > > > > thinking of installing something else due to it's
> > > > > > > becoming
> > > > > > > bloated
> > > > > > > just like gnome). And I have "-dbus" in my global
> > > > > > > make.conf.
> > > > > > > 
> > > > > > > PS. I am quite astonished at the fact that I have a
> > > > > > > computer
> > > > > > > that is
> > > > > > > _way_ faster than the first machine I installed
> > > > > > > GNU/Linux
> > > > > > > (an
> > > > > > > Amiga
> > > > > > > 4000 with a 68040 cpu at 40Mhz) on but the "experience"
> > > > > > > is
> > > > > > > still
> > > > > > > the same; it takes about the same time to boot, the same
> > > > > > > time
> > > > > > > (or
> > > > > > > even slower) to load a program. It seems the faster the
> > > > > > > computer
> > > > > > > the more I have to wait for it to finish some task.
> > > > > > > Contradictory,
> > > > > > > no? Wonder why that is... (bloat?).
> > > > > > 
> > > > > > Believe it or not but I bet you're not doing the same tasks
> > > > > > with
> > > > > > your
> > > > > > modern machine and could just not run the user-end software
> > > > > > you
> > > > > > use
> > > > > > today on a Amiga 4000 with a 68040 cpu at 40Mhz because they
> > > > > > learn
> > > > > > new
> > > > > > feature since then.
> > > > > :
> > > > > :-)  Example:
> > > > > Try run a browser on that Amiga. I doubt it would even manage
> > > > > to display the Gentoo logo at http://www.gentoo.org.
> > > > 
> > > > http://en.wikipedia.org/wiki/Origyn_Web_Browser
> > > 
> > > and I am sure that it will display pngs and jpegs with full
> > > colours just fine. I am sure displaying 2 or 4 MP pictures will
> > > be working great. Just
> > > like the mpeg4 you are trying to watch. Or the ogv.
> > 
> > I don't think so :)
> > But it is a web-browser, that runs on classic amiga os and I really
> > think, that it can display http://www.gentoo.org just fine.
> 
> so can lynx. Does it make it usefull with todays internet? There are
> more pages than just gentoo.org - The Sun for example or CNN or other
> high quality sites.
> 

I still find lynx quite useful, though obviously not useful enough to
use as my only browser. Until they got bought out by Wells Fargo,
Wachovia's banking site worked in lynx. It was the reason I chose to
bank with them.
:)

-- 
caveat utilitor
 

Re: [gentoo-user] Re: udev + /usr

[pk]

On 2011-09-19 16:22, Alan McKinnon wrote:

> Try run a browser on that Amiga. I doubt it would even manage to
> display the Gentoo logo at http://www.gentoo.org.

Actually, I used Mosaic to surf the web and then moved on to a browser
called IBrowse (then Voyager...). Worked like a charm (esp. considering
the relatively low intensity home pages at the time in the beginning of
the 90'ies - via a 14400 bit modem...). Of course flash can bring even
modern hardware to it's knees (yes, I'm allergic to that too).

> And forget all about playing music.

Actually, it did play music surprisingly well considering it's
capabilities (8-bit sound, 4 channels etc.)... I could even play videos
(though very low resolution compared to todays standards). :-)

Best regards

Peter K

Re: [gentoo-user] Re: udev + /usr

[James Broadhead]

On 19 September 2011 15:22, Alan McKinnon <alan.mckinnon@gmail.com> wrote:
> :-)  Example:
>
> Try run a browser on that Amiga. I doubt it would even manage to
> display the Gentoo logo at http://www.gentoo.org.
>
> And forget all about playing music.

As requested: http://i.imgur.com/WbQHa.jpg

Re: [gentoo-user] Re: udev + /usr

[Alan McKinnon]

On Tue, 20 Sep 2011 11:13:36 +0100
James Broadhead <jamesbroadhead@gmail.com> wrote:

> On 19 September 2011 15:22, Alan McKinnon <alan.mckinnon@gmail.com>
> wrote:
> > :-)  Example:
> >
> > Try run a browser on that Amiga. I doubt it would even manage to
> > display the Gentoo logo at http://www.gentoo.org.
> >
> > And forget all about playing music.
> 
> As requested: http://i.imgur.com/WbQHa.jpg
> 

Wise-ass :-)

But, that keyboard. As battered as it is, it still has a suspiciously
Model M look about it....

-- 
Alan McKinnnon
alan.mckinnon@gmail.com

Re: [gentoo-user] Re: udev + /usr

[Dale]

Alan McKinnon wrote:
> On Tue, 20 Sep 2011 11:13:36 +0100
> James Broadhead<jamesbroadhead@gmail.com>  wrote:
>
>> On 19 September 2011 15:22, Alan McKinnon<alan.mckinnon@gmail.com>
>> wrote:
>>> :-)  Example:
>>>
>>> Try run a browser on that Amiga. I doubt it would even manage to
>>> display the Gentoo logo at http://www.gentoo.org.
>>>
>>> And forget all about playing music.
>> As requested: http://i.imgur.com/WbQHa.jpg
>>
> Wise-ass :-)
>
> But, that keyboard. As battered as it is, it still has a suspiciously
> Model M look about it....
>

Is that a old timey typewriter under there?  It sure looks like one.  
20th century anyone?  lol

I'm talking about under the desktop itself not the keyboard on the older 
puter.

Dale

:-)  :-)

Re: [gentoo-user] Re: udev + /usr

[Mick]

[-- Attachment #1: Type: Text/Plain, Size: 946 bytes --]

On Wednesday 21 Sep 2011 00:47:50 Dale wrote:
> Alan McKinnon wrote:
> > On Tue, 20 Sep 2011 11:13:36 +0100
> > 
> > James Broadhead<jamesbroadhead@gmail.com>  wrote:
> >> On 19 September 2011 15:22, Alan McKinnon<alan.mckinnon@gmail.com>
> >> 
> >> wrote:
> >>> :-)  Example:
> >>> Try run a browser on that Amiga. I doubt it would even manage to
> >>> display the Gentoo logo at http://www.gentoo.org.
> >>> 
> >>> And forget all about playing music.
> >> 
> >> As requested: http://i.imgur.com/WbQHa.jpg
> > 
> > Wise-ass :-)
> > 
> > But, that keyboard. As battered as it is, it still has a suspiciously
> > Model M look about it....
> 
> Is that a old timey typewriter under there?  It sure looks like one.
> 20th century anyone?  lol
> 
> I'm talking about under the desktop itself not the keyboard on the older
> puter.

It's called a "back up", for use when the Amiga starts playing up!

-- 
Regards,
Mick

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-user] udev + /usr

[Canek Peláez Valdés]

On Sat, Sep 17, 2011 at 10:50 AM, Canek Peláez Valdés <caneko@gmail.com> wrote:
> On Sat, Sep 17, 2011 at 2:45 AM, Joost Roeleveld <joost@antarean.org> wrote:
>> On Friday, September 16, 2011 10:53:47 AM Canek Peláez Valdés wrote:
>>> On Fri, Sep 16, 2011 at 5:08 AM, Joost Roeleveld <joost@antarean.org> wrote:
>>> > On Thursday, September 15, 2011 05:05:00 PM Canek Peláez Valdés wrote:
>>> >> "Last time I checked, neither GNOME nor Emacs demanded that Gentoo
>>> >> developers or users had to write a fork/replacement for a core
>>> >> component of the system. GNOME and Emacs just need ebuilds and
>>> >> adapting their configuration to Gentoo-isms. Testing and bug
>>> >> reporting, as usual. The only code needed is some small patches for
>>> >> both and around 200 lines of emacslisp for site-gentoo.el."
>>> >
>>> > Funny that you mention this. There might be something similar brewing
>>> > for
>>> > users of Gnome where quite a few low-level parts will end up being
>>> > mandatory for Gnome:
>>> >
>>> > "...but I'm increasingly seeing talk on the
>>> > gnome side of the "Gnome OS", to include pulse-audio, systemd,
>>> > policykit,
>>> > udev/u* (thus forcing lvm as well, at least lvm installation tho nothing
>>> > forces one to use it... yet, since lvm is required for udisks), etc."
>>>
>>> I'm pretty sure the last part is false. I certainly have udisk
>>> installet (it's pulled by gnome-disk-utility), but I don't use LVM. So
>>> there.
>>
>> I don't use Gnome and haven't looked into all this. Udev also doesn't appear
>> to have a LVM-useflag. But as I do use LVM, I can't actually check.
>> Do you have "sys-fs/lvm2" on your system?
>>
>> The ebuild does list it as "RDEPEND".
>
> Yes, I got it installed. I didn't noticed until now. Then again, it
> takes 1 minute to install in my puny laptop, and uses 7 Mb of hard
> drive. But anyhow, I was mistaken: it is forced by udisks.

I think udisks depending on LVM is an error, so I decided I would took
this Saturday and see if I was able to write a patch that makes it
optional. However, as per free software rules, I first visited the
Freedesktop.org bugzilla.

Gustavo Barbieri (who I mentioned before) got there first:

https://bugs.freedesktop.org/show_bug.cgi?id=37647

As I said before, Gustavo has contributed a lot to systemd, usually
making stuff optional. I'm sure his patch (or a similar version of it)
will be accepted.

As I keep saying: code talks.

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

Re: [gentoo-user] udev + /usr

[Joost Roeleveld]

On Saturday, September 17, 2011 02:43:00 PM Canek Peláez Valdés wrote:
> On Sat, Sep 17, 2011 at 10:50 AM, Canek Peláez Valdés <caneko@gmail.com> 
wrote:
> > On Sat, Sep 17, 2011 at 2:45 AM, Joost Roeleveld <joost@antarean.org> 
wrote:
> >> On Friday, September 16, 2011 10:53:47 AM Canek Peláez Valdés wrote:
> >>> On Fri, Sep 16, 2011 at 5:08 AM, Joost Roeleveld <joost@antarean.org> 
wrote:
> >>> > On Thursday, September 15, 2011 05:05:00 PM Canek Peláez Valdés wrote:
> >>> >> "Last time I checked, neither GNOME nor Emacs demanded that
> >>> >> Gentoo
> >>> >> developers or users had to write a fork/replacement for a core
> >>> >> component of the system. GNOME and Emacs just need ebuilds and
> >>> >> adapting their configuration to Gentoo-isms. Testing and bug
> >>> >> reporting, as usual. The only code needed is some small
> >>> >> patches for
> >>> >> both and around 200 lines of emacslisp for site-gentoo.el."
> >>> > 
> >>> > Funny that you mention this. There might be something similar
> >>> > brewing
> >>> > for
> >>> > users of Gnome where quite a few low-level parts will end up
> >>> > being
> >>> > mandatory for Gnome:
> >>> > 
> >>> > "...but I'm increasingly seeing talk on the
> >>> > gnome side of the "Gnome OS", to include pulse-audio, systemd,
> >>> > policykit,
> >>> > udev/u* (thus forcing lvm as well, at least lvm installation tho
> >>> > nothing forces one to use it... yet, since lvm is required for
> >>> > udisks), etc.">>> 
> >>> I'm pretty sure the last part is false. I certainly have udisk
> >>> installet (it's pulled by gnome-disk-utility), but I don't use LVM.
> >>> So
> >>> there.
> >> 
> >> I don't use Gnome and haven't looked into all this. Udev also doesn't
> >> appear to have a LVM-useflag. But as I do use LVM, I can't actually
> >> check. Do you have "sys-fs/lvm2" on your system?
> >> 
> >> The ebuild does list it as "RDEPEND".
> > 
> > Yes, I got it installed. I didn't noticed until now. Then again, it
> > takes 1 minute to install in my puny laptop, and uses 7 Mb of hard
> > drive. But anyhow, I was mistaken: it is forced by udisks.
> 
> I think udisks depending on LVM is an error, so I decided I would took
> this Saturday and see if I was able to write a patch that makes it
> optional. However, as per free software rules, I first visited the
> Freedesktop.org bugzilla.
> 
> Gustavo Barbieri (who I mentioned before) got there first:
> 
> https://bugs.freedesktop.org/show_bug.cgi?id=37647
> 
> As I said before, Gustavo has contributed a lot to systemd, usually
> making stuff optional. I'm sure his patch (or a similar version of it)
> will be accepted.

I hope so too. I do use LVM, so having LVM used by "udisks" is logical. But if 
LVM isn't used, the tools shouldn't have to be present.

I did notice on that bug-link that it was raised nearly 4 months ago with no 
response from the developers even though a patch exists was provided.

> As I keep saying: code talks.

Yes, but the developers are quiet with regards to that patch.
I can understand if it takes some time to analyse a patch, but 4 months with 
no response is, in my view, similar to the devs saying they don't care.

--
Joost

Re: [gentoo-user] udev + /usr

[Pandu Poluan]

[-- Attachment #1: Type: text/plain, Size: 528 bytes --]

On Sep 18, 2011 9:50 PM, "Joost Roeleveld" <joost@antarean.org> wrote:
>
> On Saturday, September 17, 2011 02:43:00 PM Canek Peláez Valdés wrote:
>
> > As I keep saying: code talks.
>
> Yes, but the developers are quiet with regards to that patch.
> I can understand if it takes some time to analyse a patch, but 4 months
with
> no response is, in my view, similar to the devs saying they don't care.
>

Code talks. Except when it runs counter to the devs'/upstream's wishes,
where it will be silenced.

Rgds,

[-- Attachment #2: Type: text/html, Size: 689 bytes --]

Re: [gentoo-user] udev + /usr

[Alan McKinnon]

On Thu, 15 Sep 2011 09:47:34 -0400
Michael Mol <mikemol@gmail.com> wrote:

> > The main purpose of udev is to populate the /dev-tree.
> > The running of scripts based on /dev-tree events should be in a
> > seperate tool that starts later in the boot-process.  
> 
> I'm not *entirely* convinced this is the case, because it feels like
> some situations like network devices (nbd, iSCSI) or loopback would
> require userland tools to bring up once networking is up.

I'd say you are both right.

Joost gave the correct (in my view) overriding principle.
You gave what to do when that just doesn't cut it.

Real-world systems involve exceptions for unusual (but valid)
conditions. The best solution is to deal with the exception within a
narrow focus, instead of just allowing everything like udev seems
determined to go to.

-- 
Alan McKinnnon
alan.mckinnon@gmail.com

Re: [gentoo-user] udev + /usr

[Neil Bothwick]

[-- Attachment #1: Type: text/plain, Size: 553 bytes --]

On Tue, 13 Sep 2011 17:10:40 -0400, Canek Peláez Valdés wrote:

> No, by "you know what needs to be done" I mean: code. Contribute.
> Become a developer. Make shit happens the way you think it should
> happen.

You're happy to run an important system service coded by someone with
less experience than their dislike of the way things are going.

Trust me, you would want to run a udev that contained any code written by
me!


-- 
Neil Bothwick

Programmer (n): A red-eyed, mumbling mammal capable of conversing
with inanimate objects.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-user] udev + /usr

[Canek Peláez Valdés]

On Wed, Sep 14, 2011 at 5:06 AM, Neil Bothwick <neil@digimed.co.uk> wrote:
> On Tue, 13 Sep 2011 17:10:40 -0400, Canek Peláez Valdés wrote:
>
>> No, by "you know what needs to be done" I mean: code. Contribute.
>> Become a developer. Make shit happens the way you think it should
>> happen.
>
> You're happy to run an important system service coded by someone with
> less experience than their dislike of the way things are going.

Someone with "less experience"? As I said before, Kay has been working
in udev for more than eight years. I think he's entitle to receive the
acknowledge of his experience.

> Trust me, you would want to run a udev that contained any code written by
> me!

No offense man, but I don't know you enough so I "would want to run a
udev that contained any code written by" you.

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

Re: [gentoo-user] udev + /usr

[Michael Mol]

On Wed, Sep 14, 2011 at 10:37 AM, Canek Peláez Valdés <caneko@gmail.com> wrote:
>
> On Wed, Sep 14, 2011 at 5:06 AM, Neil Bothwick <neil@digimed.co.uk> wrote:
> > On Tue, 13 Sep 2011 17:10:40 -0400, Canek Peláez Valdés wrote:
> >
> >> No, by "you know what needs to be done" I mean: code. Contribute.
> >> Become a developer. Make shit happens the way you think it should
> >> happen.
> >
> > You're happy to run an important system service coded by someone with
> > less experience than their dislike of the way things are going.
>
> Someone with "less experience"? As I said before, Kay has been working
> in udev for more than eight years. I think he's entitle to receive the
> acknowledge of his experience.

https://secure.wikimedia.org/wikipedia/en/wiki/Argument_from_authority

>
> > Trust me, you would want to run a udev that contained any code written by
> > me!
>
> No offense man, but I don't know you enough so I "would want to run a
> udev that contained any code written by" you.

He forgot to include <sarcasm/> tags.

--
:wq

Re: [gentoo-user] udev + /usr

[Neil Bothwick]

[-- Attachment #1: Type: text/plain, Size: 477 bytes --]

On Wed, 14 Sep 2011 10:49:29 -0400, Michael Mol wrote:

> > > Trust me, you would want to run a udev that contained any code
> > > written by me!  
> >
> > No offense man, but I don't know you enough so I "would want to run a
> > udev that contained any code written by" you.  
> 
> He forgot to include <sarcasm/> tags.

No I didn't. You truly would not want to run anything coded by me :(


-- 
Neil Bothwick

Consciousness: that annoying time between naps.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-user] udev + /usr

[Michael Mol]

On Wed, Sep 14, 2011 at 11:36 AM, Neil Bothwick <neil@digimed.co.uk> wrote:
> On Wed, 14 Sep 2011 10:49:29 -0400, Michael Mol wrote:
>
>> > > Trust me, you would want to run a udev that contained any code
>> > > written by me!
>> >
>> > No offense man, but I don't know you enough so I "would want to run a
>> > udev that contained any code written by" you.
>>
>> He forgot to include <sarcasm/> tags.
>
> No I didn't. You truly would not want to run anything coded by me :(

Ok, then you left out the <irony/> tags. :)

-- 
:wq

Re: [gentoo-user] udev + /usr

[Allan Gottlieb]

On Wed, Sep 14 2011, Michael Mol wrote:

> On Wed, Sep 14, 2011 at 11:36 AM, Neil Bothwick <neil@digimed.co.uk> wrote:
>> On Wed, 14 Sep 2011 10:49:29 -0400, Michael Mol wrote:
>>
>>> > > Trust me, you would want to run a udev that contained any code
>>> > > written by me!
>>> >
>>> > No offense man, but I don't know you enough so I "would want to run a
>>> > udev that contained any code written by" you.
>>>
>>> He forgot to include <sarcasm/> tags.
>>
>> No I didn't. You truly would not want to run anything coded by me :(
>
> Ok, then you left out the <irony/> tags. :)

To continue the analysis of "the words of neil" :-) I believe he simply
forgot a "not".  Instead of

  Trust me, you would want to run a udev that contained any code written
  by me!

neil probably meant

  Trust me, you would not want to run a udev that contained any code
  written by me!

allan

Re: [gentoo-user] udev + /usr

[Canek Peláez Valdés]

On Wed, Sep 14, 2011 at 12:05 PM, Allan Gottlieb <gottlieb@nyu.edu> wrote:
> On Wed, Sep 14 2011, Michael Mol wrote:
>
>> On Wed, Sep 14, 2011 at 11:36 AM, Neil Bothwick <neil@digimed.co.uk> wrote:
>>> On Wed, 14 Sep 2011 10:49:29 -0400, Michael Mol wrote:
>>>
>>>> > > Trust me, you would want to run a udev that contained any code
>>>> > > written by me!
>>>> >
>>>> > No offense man, but I don't know you enough so I "would want to run a
>>>> > udev that contained any code written by" you.
>>>>
>>>> He forgot to include <sarcasm/> tags.
>>>
>>> No I didn't. You truly would not want to run anything coded by me :(
>>
>> Ok, then you left out the <irony/> tags. :)
>
> To continue the analysis of "the words of neil" :-) I believe he simply
> forgot a "not".  Instead of
>
>  Trust me, you would want to run a udev that contained any code written
>  by me!
>
> neil probably meant
>
>  Trust me, you would not want to run a udev that contained any code
>  written by me!

Oh, didn't see that. Thanks.

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

Re: [gentoo-user] udev + /usr

[Neil Bothwick]

[-- Attachment #1: Type: text/plain, Size: 610 bytes --]

On Wed, 14 Sep 2011 12:05:37 -0400, Allan Gottlieb wrote:

> To continue the analysis of "the words of neil" :-) I believe he simply
> forgot a "not".  Instead of
> 
>   Trust me, you would want to run a udev that contained any code written
>   by me!
> 
> neil probably meant
> 
>   Trust me, you would not want to run a udev that contained any code
>   written by me!

Spot on!

If I can't even be trusted to write English correctly, which is my day
job, you certainly don't want to see my code ;-)


-- 
Neil Bothwick

The severity of the itch is inversely proportional to the reach.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-user] udev + /usr

[Peter Humphrey]

On Wednesday 14 September 2011 19:59:18 Neil Bothwick wrote:

> If I can't even be trusted to write English correctly, which is my day
> job, you certainly don't want to see my code ;-)

I used to think Linux Format needed a sub-editor. Now I know they have a 
pretty good one!

:-)

-- 
Rgds
Peter		Linux Counter 5290, 1994-04-23

Re: [gentoo-user] udev + /usr

[Neil Bothwick]

[-- Attachment #1: Type: text/plain, Size: 415 bytes --]

On Wed, 14 Sep 2011 23:37:38 +0100, Peter Humphrey wrote:

> > If I can't even be trusted to write English correctly, which is my day
> > job, you certainly don't want to see my code ;-)  
> 
> I used to think Linux Format needed a sub-editor. Now I know they have
> a pretty good one!

r u dissin the way what I right?


-- 
Neil Bothwick

ERROR #0915: MONITOR NOT PRESENT. CLICK ON OK TO CONTINUE.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-user] udev + /usr

[Peter Humphrey]

On Thursday 15 September 2011 00:43:08 Neil Bothwick wrote:
> On Wed, 14 Sep 2011 23:37:38 +0100, Peter Humphrey wrote:
> > > If I can't even be trusted to write English correctly, which is my
> > > day job, you certainly don't want to see my code ;-)
> > 
> > I used to think Linux Format needed a sub-editor. Now I know they have
> > a pretty good one!
> 
> r u dissin the way what I right?

Hoo me? Perish the thought!

-- 
Rgds
Peter		Linux Counter 5290, 1994-04-23

Re: [gentoo-user] udev + /usr

[Neil Bothwick]

[-- Attachment #1: Type: text/plain, Size: 1331 bytes --]

On Wed, 14 Sep 2011 10:37:14 -0400, Canek Peláez Valdés wrote:

> >> No, by "you know what needs to be done" I mean: code. Contribute.
> >> Become a developer. Make shit happens the way you think it should
> >> happen.
> >
> > You're happy to run an important system service coded by someone with
> > less experience than their dislike of the way things are going.
> 
> Someone with "less experience"? As I said before, Kay has been working
> in udev for more than eight years. I think he's entitle to receive the
> acknowledge of his experience.

Yet you are suggesting that others code the solutions. I'm sorry, but
being pissed off with the current trend in udev is not sufficient
qualification to write a replacement.

> > Trust me, you would want to run a udev that contained any code
> > written by me!
> 
> No offense man, but I don't know you enough so I "would want to run a
> udev that contained any code written by" you.

Then why have you repeatedly suggested that I and others in these threads
"code it yourself".

The solution is not to spit the dummy and write a poorly coded fork,
discarding years of experience. The solution is rational debate so that
those who can and do write the code can do a better job.


-- 
Neil Bothwick

Always be sincere... whether you mean it or not!

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-user] udev + /usr

[Canek Peláez Valdés]

On Wed, Sep 14, 2011 at 11:35 AM, Neil Bothwick <neil@digimed.co.uk> wrote:
> On Wed, 14 Sep 2011 10:37:14 -0400, Canek Peláez Valdés wrote:
>
>> >> No, by "you know what needs to be done" I mean: code. Contribute.
>> >> Become a developer. Make shit happens the way you think it should
>> >> happen.
>> >
>> > You're happy to run an important system service coded by someone with
>> > less experience than their dislike of the way things are going.
>>
>> Someone with "less experience"? As I said before, Kay has been working
>> in udev for more than eight years. I think he's entitle to receive the
>> acknowledge of his experience.
>
> Yet you are suggesting that others code the solutions.

No, I am suggesting that, if something in the direction of
usev/Gentoo/Linux bother someone, that someone has to code up
something in the direction s/he would like things to go, or accept
what the developers decide.

> I'm sorry, but
> being pissed off with the current trend in udev is not sufficient
> qualification to write a replacement.

I agree. I am not "pissed off" by any of the developments in Linux in
general and Gentoo in particular in the last few years: on the
contrary, I am quite happy with them.

>> > Trust me, you would want to run a udev that contained any code
>> > written by me!
>>
>> No offense man, but I don't know you enough so I "would want to run a
>> udev that contained any code written by" you.
>
> Then why have you repeatedly suggested that I and others in these threads
> "code it yourself".

Because nobody else is going to do it for you or them. That's the
point. Either convince the developers to code the stuff to work like
you want, or do it youtself.

And if you do it yourself, don't necessarily expect the rest of the
world will run to use your code.

> The solution is not to spit the dummy and write a poorly coded fork,
> discarding years of experience. The solution is rational debate so that
> those who can and do write the code can do a better job.

Mmmh. Not exactly.

The "rational debate" happens in the Open Source conferences,
developer mailing lists and IRC. The proposed changes are not a sudden
outbreak of craziness by one or more developers: is the result of the
"rational debate" among them, and of the code they produce.

If you don't write code, you can "rational debate" as much as you
want, but as long as the ones writing the code are not involved, it's
not very useful. And even if the developers are involved, be ready for
them to maybe disagree with you.

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

Re: [gentoo-user] udev + /usr

[Sebastian Beßler]

[-- Attachment #1: Type: text/plain, Size: 573 bytes --]

This thread goes in endless circles, round and round and round.
In the last 20 posts or so is not one new argument pro or con can be
found, both sides only repeating their pov over and over again.

Nothing will be achieved by that, it is only a big waste of time and
energy that could be used better. Create documents with all your
arguments, maybe a reply to that blog post that claims that split of
/usr is broken.

Flameing here on -user helps noone, because the devs must be convinced
not the users.

Just my 2 €-cent

Greetings

Sebastian Beßler


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 900 bytes --]

Re: [gentoo-user] udev + /usr

[Joost Roeleveld]

On Wednesday, September 14, 2011 06:40:44 PM Sebastian Beßler wrote:
> This thread goes in endless circles, round and round and round.
> In the last 20 posts or so is not one new argument pro or con can be
> found, both sides only repeating their pov over and over again.
> 
> Nothing will be achieved by that, it is only a big waste of time and
> energy that could be used better. Create documents with all your
> arguments, maybe a reply to that blog post that claims that split of
> /usr is broken.
> 
> Flameing here on -user helps noone, because the devs must be convinced
> not the users.
> 
> Just my 2 €-cent
> 
> Greetings
> 
> Sebastian Beßler

I agree, I also wanted to leave a comment on that page about systemd and /usr 
written by the same guy who is making this decision for udev.

Comments and changes are not possible on that page at all.

--
Joost

Re: [gentoo-user] udev + /usr

[Joost Roeleveld]

On Wednesday, September 14, 2011 10:37:14 AM Canek Peláez Valdés wrote:
> On Wed, Sep 14, 2011 at 5:06 AM, Neil Bothwick <neil@digimed.co.uk> wrote:
> > On Tue, 13 Sep 2011 17:10:40 -0400, Canek Peláez Valdés wrote:
> >> No, by "you know what needs to be done" I mean: code. Contribute.
> >> Become a developer. Make shit happens the way you think it should
> >> happen.
> > 
> > You're happy to run an important system service coded by someone with
> > less experience than their dislike of the way things are going.
> 
> Someone with "less experience"? As I said before, Kay has been working
> in udev for more than eight years. I think he's entitle to receive the
> acknowledge of his experience.

A certain amount of years of experience doesn't mean the person can not make 
mistakes. Kay has done a lot of good work with udev, but he should rethink his 
design and breaking a lot of systems just to satisfy his insane desire to make 
everyone do whatever he dreamed up is simply wrong.

--
Joost

Re: [gentoo-user] udev + /usr

[Alan Mackenzie]

On Tue, Sep 13, 2011 at 05:10:40PM -0400, Canek Peláez Valdés wrote:

> > Is it simply subscribing to -dev and voicing the conversation there?

> Of course not. But please, do that if you think it will help to steer
> Gentoo to whatever direction do you think is the correct one.
> Personaly I don't think the devs (who, AFAIK, do not receive a single
> dime for working on Gentoo) will appreciate anybody telling them how
> they should do their jobs, the one they do for free. But that's just
> me.

I think so.  Most devs are grateful for (polite) feedback, and take it
into account when doing their work.  I suspect they're unaware of just
how much this change to booting is disliked by Gentoo users.

> No, by "you know what needs to be done" I mean: code. Contribute.
> Become a developer. Make shit happens the way you think it should
> happen.

> Shut up and code. Google it, I didn't come with the phrase.

Just as a matter of interest, how much coding have you done for open
source or free software?  It was conspicuously absent from the CV you
posted here a few days ago.

> Regards.
> -- 
> Canek Peláez Valdés

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: [gentoo-user] udev + /usr

[Mick]

[-- Attachment #1: Type: Text/Plain, Size: 1854 bytes --]

On Wednesday 14 Sep 2011 11:25:23 Alan Mackenzie wrote:
> On Tue, Sep 13, 2011 at 05:10:40PM -0400, Canek Peláez Valdés wrote:
> > > Is it simply subscribing to -dev and voicing the conversation there?
> > 
> > Of course not. But please, do that if you think it will help to steer
> > Gentoo to whatever direction do you think is the correct one.
> > Personaly I don't think the devs (who, AFAIK, do not receive a single
> > dime for working on Gentoo) will appreciate anybody telling them how
> > they should do their jobs, the one they do for free. But that's just
> > me.
> 
> I think so.  Most devs are grateful for (polite) feedback, and take it
> into account when doing their work.  I suspect they're unaware of just
> how much this change to booting is disliked by Gentoo users.

Could someone please nudge them this way for them to get first hand feedback 
on their decision.


> > No, by "you know what needs to be done" I mean: code. Contribute.
> > Become a developer. Make shit happens the way you think it should
> > happen.
> > 
> > Shut up and code. Google it, I didn't come with the phrase.

Not all of us have the capability to code, although all of us are grateful for 
good code devs produce and often express our user needs and wants in this M/L.


> Just as a matter of interest, how much coding have you done for open
> source or free software?  It was conspicuously absent from the CV you
> posted here a few days ago.

Canek may wish to keep his reply off list because it wouldn't be of particular 
interest to many and is not relevant with Gentoo being aligned with a flawed 
(IMHO) design principle.

Better we focus our efforts instead on influencing Gentoo devs and upstream 
decision making on this matter before it defaults into a design orthodoxy for 
Linux.
-- 
Regards,
Mick

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-user] udev + /usr

[Michael Mol]

On Wed, Sep 14, 2011 at 10:10 AM, Mick <michaelkintzios@gmail.com> wrote:
> On Wednesday 14 Sep 2011 11:25:23 Alan Mackenzie wrote:
>> On Tue, Sep 13, 2011 at 05:10:40PM -0400, Canek Peláez Valdés wrote:
>> > > Is it simply subscribing to -dev and voicing the conversation there?
>> >
>> > Of course not. But please, do that if you think it will help to steer
>> > Gentoo to whatever direction do you think is the correct one.
>> > Personaly I don't think the devs (who, AFAIK, do not receive a single
>> > dime for working on Gentoo) will appreciate anybody telling them how
>> > they should do their jobs, the one they do for free. But that's just
>> > me.
>>
>> I think so.  Most devs are grateful for (polite) feedback, and take it
>> into account when doing their work.  I suspect they're unaware of just
>> how much this change to booting is disliked by Gentoo users.
>
> Could someone please nudge them this way for them to get first hand feedback
> on their decision.
>
>
>> > No, by "you know what needs to be done" I mean: code. Contribute.
>> > Become a developer. Make shit happens the way you think it should
>> > happen.
>> >
>> > Shut up and code. Google it, I didn't come with the phrase.
>
> Not all of us have the capability to code, although all of us are grateful for
> good code devs produce and often express our user needs and wants in this M/L.
>
>
>> Just as a matter of interest, how much coding have you done for open
>> source or free software?  It was conspicuously absent from the CV you
>> posted here a few days ago.
>
> Canek may wish to keep his reply off list because it wouldn't be of particular
> interest to many and is not relevant with Gentoo being aligned with a flawed
> (IMHO) design principle.
>
> Better we focus our efforts instead on influencing Gentoo devs and upstream
> decision making on this matter before it defaults into a design orthodoxy for
> Linux.

Rather than flooding the gentoo devs with a bunch of outrage, maybe
it'd be better to build a document detailing the reasoning of the
opinions and discussed potential solutions? It'd probably be received
a lot better than starting over with a new heated argument, feeling
around how much the various parties know and understand about the
issue.

-- 
:wq

Re: [gentoo-user] udev + /usr

[Canek Peláez Valdés]

On Wed, Sep 14, 2011 at 10:19 AM, Michael Mol <mikemol@gmail.com> wrote:
> On Wed, Sep 14, 2011 at 10:10 AM, Mick <michaelkintzios@gmail.com> wrote:
>> On Wednesday 14 Sep 2011 11:25:23 Alan Mackenzie wrote:
>>> On Tue, Sep 13, 2011 at 05:10:40PM -0400, Canek Peláez Valdés wrote:
>>> > > Is it simply subscribing to -dev and voicing the conversation there?
>>> >
>>> > Of course not. But please, do that if you think it will help to steer
>>> > Gentoo to whatever direction do you think is the correct one.
>>> > Personaly I don't think the devs (who, AFAIK, do not receive a single
>>> > dime for working on Gentoo) will appreciate anybody telling them how
>>> > they should do their jobs, the one they do for free. But that's just
>>> > me.
>>>
>>> I think so.  Most devs are grateful for (polite) feedback, and take it
>>> into account when doing their work.  I suspect they're unaware of just
>>> how much this change to booting is disliked by Gentoo users.
>>
>> Could someone please nudge them this way for them to get first hand feedback
>> on their decision.
>>
>>
>>> > No, by "you know what needs to be done" I mean: code. Contribute.
>>> > Become a developer. Make shit happens the way you think it should
>>> > happen.
>>> >
>>> > Shut up and code. Google it, I didn't come with the phrase.
>>
>> Not all of us have the capability to code, although all of us are grateful for
>> good code devs produce and often express our user needs and wants in this M/L.
>>
>>
>>> Just as a matter of interest, how much coding have you done for open
>>> source or free software?  It was conspicuously absent from the CV you
>>> posted here a few days ago.
>>
>> Canek may wish to keep his reply off list because it wouldn't be of particular
>> interest to many and is not relevant with Gentoo being aligned with a flawed
>> (IMHO) design principle.
>>
>> Better we focus our efforts instead on influencing Gentoo devs and upstream
>> decision making on this matter before it defaults into a design orthodoxy for
>> Linux.
>
> Rather than flooding the gentoo devs with a bunch of outrage, maybe
> it'd be better to build a document detailing the reasoning of the
> opinions and discussed potential solutions? It'd probably be received
> a lot better than starting over with a new heated argument, feeling
> around how much the various parties know and understand about the
> issue.

Please, somebody do that. Then the users (like me) who support the
changes could make another document arguing point by point your
document. That will centralize the reasons for and against the
proposed changes, so it would help people to better understand the
issue.

Maybe some developers for the change will change their mind. And maybe
some of the developers against it will change theirs.

And in the end, whoever wants to actually write the code and implement
the idea (any idea) will, you know, write the code and implement the
idea.

For sure this proposal for a document for the developers would help to
clear the air with regards of how "aware" or "unaware" they are.

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

Re: [gentoo-user] udev + /usr

[Canek Peláez Valdés]

On Wed, Sep 14, 2011 at 10:10 AM, Mick <michaelkintzios@gmail.com> wrote:
> On Wednesday 14 Sep 2011 11:25:23 Alan Mackenzie wrote:
>> On Tue, Sep 13, 2011 at 05:10:40PM -0400, Canek Peláez Valdés wrote:
>> > > Is it simply subscribing to -dev and voicing the conversation there?
>> >
>> > Of course not. But please, do that if you think it will help to steer
>> > Gentoo to whatever direction do you think is the correct one.
>> > Personaly I don't think the devs (who, AFAIK, do not receive a single
>> > dime for working on Gentoo) will appreciate anybody telling them how
>> > they should do their jobs, the one they do for free. But that's just
>> > me.
>>
>> I think so.  Most devs are grateful for (polite) feedback, and take it
>> into account when doing their work.  I suspect they're unaware of just
>> how much this change to booting is disliked by Gentoo users.
>
> Could someone please nudge them this way for them to get first hand feedback
> on their decision.

That's actually something I wonder. Why, if this change seems to stir
so many, nobody has actually showed up in -dev?

>> > No, by "you know what needs to be done" I mean: code. Contribute.
>> > Become a developer. Make shit happens the way you think it should
>> > happen.
>> >
>> > Shut up and code. Google it, I didn't come with the phrase.
>
> Not all of us have the capability to code,

Exactly my point. And that's why I've been saying the decision is
going to be made by the people who code.

> although all of us are grateful for
> good code devs produce and often express our user needs and wants in this M/L.
>
>
>> Just as a matter of interest, how much coding have you done for open
>> source or free software?  It was conspicuously absent from the CV you
>> posted here a few days ago.
>
> Canek may wish to keep his reply off list because it wouldn't be of particular
> interest to many and is not relevant with Gentoo being aligned with a flawed
> (IMHO) design principle.

Well said.

> Better we focus our efforts instead on influencing Gentoo devs and upstream
> decision making on this matter before it defaults into a design orthodoxy for
> Linux.

That would be a much more sensible thing to do, I would think.

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

Re: [gentoo-user] udev + /usr

[Canek Peláez Valdés]

On Wed, Sep 14, 2011 at 6:25 AM, Alan Mackenzie <acm@muc.de> wrote:
> On Tue, Sep 13, 2011 at 05:10:40PM -0400, Canek Peláez Valdés wrote:
>
>> > Is it simply subscribing to -dev and voicing the conversation there?
>
>> Of course not. But please, do that if you think it will help to steer
>> Gentoo to whatever direction do you think is the correct one.
>> Personaly I don't think the devs (who, AFAIK, do not receive a single
>> dime for working on Gentoo) will appreciate anybody telling them how
>> they should do their jobs, the one they do for free. But that's just
>> me.
>
> I think so.  Most devs are grateful for (polite) feedback, and take it
> into account when doing their work.  I suspect they're unaware of just
> how much this change to booting is disliked by Gentoo users.

Then, by all means, do it. I would think is a little silly to think
that the devs are "unaware" of the huge threads this change has
generated on -user, but maybe I'm wrong. Maybe someone should tell
them.

>> No, by "you know what needs to be done" I mean: code. Contribute.
>> Become a developer. Make shit happens the way you think it should
>> happen.
>
>> Shut up and code. Google it, I didn't come with the phrase.
>
> Just as a matter of interest, how much coding have you done for open
> source or free software?  It was conspicuously absent from the CV you
> posted here a few days ago.

Well, it wasn't really my CV (I would not bore to death the list with
it), and I don't think it has nothing to do with the dicussion at
hand, but the answer is: "not that much". There is code of mine in
several projects in the stack, but it's usually simple things or
one-liners. I have (like many on this list) my share of bug reports,
first versions of ebuilds and testing, but nothing out of the
ordinary. I enjoy too much so many other pleasures to be able to give
so much of my free time to free software development.

And that's exactly why I respect so much the devs. They actually do
it. It's not only pragmatism to say that whatever happens it will
happen because of the people coding whatever is necessary for it to
happen. It's also because they actually *deserve* to be the ones that
decide what should happen.

Code talks.

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

Re: [gentoo-user] udev + /usr

[Stroller]

On 14 September 2011, at 11:25, Alan Mackenzie wrote:
> ...
>> No, by "you know what needs to be done" I mean: code. Contribute.
>> Become a developer. Make shit happens the way you think it should
>> happen.
> 
>> Shut up and code. Google it, I didn't come with the phrase.
> 
> Just as a matter of interest, how much coding have you done for open
> source or free software?  It was conspicuously absent from the CV you
> posted here a few days ago.

That's got nothing to do with it, and it's rude of you to make this about Canek, IMO.

It's YOU who wants things differently from the planned roadmap, so why shouldn't YOU code the features?


There have been a couple of posts in this thread, I don't recall who made them, who talked of the "1% of users forcing this change on the other 99%". This is an exceedingly disingenuous argument - it's the Gentoo users, the objectors, who are the 1%. 99% of users won't even notice this, because they're using binary distros. 


My inclination is to agree with you. I detest initramfs, but I don't significantly partition my disks, so I'm unaffected. But if you care you'd better stop whining and get coding.

It's inexcusable of you to try and turn the problem around and question Canek's contributions to OSS if you're unprepared to make any yourself.

Stroller.

Re: [gentoo-user] udev + /usr

[Alan Mackenzie]

Hello Stroller.

On Wed, Sep 14, 2011 at 04:04:29PM +0100, Stroller wrote:

> On 14 September 2011, at 11:25, Alan Mackenzie wrote:
> > ...
> >> No, by "you know what needs to be done" I mean: code. Contribute.
> >> Become a developer. Make shit happens the way you think it should
> >> happen.

> >> Shut up and code. Google it, I didn't come with the phrase.

> > Just as a matter of interest, how much coding have you done for open
> > source or free software?  It was conspicuously absent from the CV you
> > posted here a few days ago.

> That's got nothing to do with it, and it's rude of you to make this
> about Canek, IMO.

Given how much Canek has been saying about free/open source recently, the
attitudes he's been attributing to its developers (which don't accord
with my experience of them), and the number of times he's told people,
in a manner I find very rude, to "stop moaning and code it yourself" -
given all of this, I find it reasonable to question Canek's background.
I'm not the only one of us getting irritated by him.

I think the word you accidentally left out of your last sentence was
"insinuation".  I hope, on reading this post of mine, you'll change your
attitude.

> It's YOU who wants things differently from the planned roadmap, so why
> shouldn't YOU code the features?

No reason whatsoever.  Go back to the earlier posts in this thread, and
you'll see this is what I proposed doing, before somebody (I think it was
Michael) educated me on what the problem actually was.

> There have been a couple of posts in this thread, I don't recall who
> made them, who talked of the "1% of users forcing this change on the
> other 99%". This is an exceedingly disingenuous argument - it's the
> Gentoo users, the objectors, who are the 1%. 99% of users won't even
> notice this, because they're using binary distros. 

I asked if the person causing us the grief had consulted the wider world
before making such far reaching changes.  The answer to this question
was nobody's been able to find out.  Of the people who care about things
like booting sequences, it would seem the vast majority don't like what's
happening.

> My inclination is to agree with you. I detest initramfs, but I don't
> significantly partition my disks, so I'm unaffected. But if you care
> you'd better stop whining and get coding.

> It's inexcusable of you to try and turn the problem around and question
> Canek's contributions to OSS if you're unprepared to make any yourself.

I've been contributing to Emacs in general and CC Mode in particular for
10 years.  I've been the sole maintainer of CC Mode (the mode used for
coding in C, C++, Objective C, Java, Awk, and a couple of others, and an
unknown number of derived modes) for around 5 years.  Over that time I've
spent thousands of hours on the project.  My latest release was on
Monday, and you can find it at
<http://cc-mode.sourceforge.net/release.php>.  If you use {,X}Emacs to
hack in any these languages, I recommend you to download and install it.

Several or many of CC Mode's features have come about through request's
from users.  They are gratefully received.  Some requests, for features
which aren't really suitable for the mode, get answered by personal
patches to the requesters.  Some requests get gently turned down.  The
idea of slagging off users with "IMPLEMENT IT YOURSELF!!!" is completely
outside my experiece.

Normally I get credit and respect for this work.

> Stroller.

-- 
Alan Mackenzie (Nuremberg, Germany).

Really OT now (Re: [gentoo-user] udev + /usr)

[Michael Schreckenbauer]

Hi Alan,

On Wednesday, 14. September 2011 21:34:01 Alan Mackenzie wrote:
> I've been contributing to Emacs in general and CC Mode in particular for
> 10 years.  I've been the sole maintainer of CC Mode (the mode used for
> coding in C, C++, Objective C, Java, Awk, and a couple of others, and an
> unknown number of derived modes) for around 5 years.  Over that time I've
> spent thousands of hours on the project.  My latest release was on
> Monday, and you can find it at
> <http://cc-mode.sourceforge.net/release.php>.  If you use {,X}Emacs to
> hack in any these languages, I recommend you to download and install it.

although I'm a vim-using guy, and that only if no kate is available, I have 
emacs and cc-mode installed on every machine I use for coding. At times I even 
use it :) 
Really cool stuff you do there and thanks for the work.

Best,
Michael

Re: Really OT now (Re: [gentoo-user] udev + /usr)

[Michael Mol]

On Wed, Sep 14, 2011 at 6:05 PM, Michael Schreckenbauer <grimlog@gmx.de> wrote:
> Hi Alan,
>
> On Wednesday, 14. September 2011 21:34:01 Alan Mackenzie wrote:
>> I've been contributing to Emacs in general and CC Mode in particular for
>> 10 years.  I've been the sole maintainer of CC Mode (the mode used for
>> coding in C, C++, Objective C, Java, Awk, and a couple of others, and an
>> unknown number of derived modes) for around 5 years.  Over that time I've
>> spent thousands of hours on the project.  My latest release was on
>> Monday, and you can find it at
>> <http://cc-mode.sourceforge.net/release.php>.  If you use {,X}Emacs to
>> hack in any these languages, I recommend you to download and install it.
>
> although I'm a vim-using guy, and that only if no kate is available, I have
> emacs and cc-mode installed on every machine I use for coding. At times I even
> use it :)
> Really cool stuff you do there and thanks for the work.

It occurred to me that having a decent C and C++ editing environment
might ease some of my of the spoilage I've experienced in Visual
Studio for C++. I'll be checking it out. It'll mean learning emacs,
though...

-- 
:wq

IDE for C/C++ (Was: Really OT now (Re: [gentoo-user] udev + /usr)

[David W Noon]

[-- Attachment #1: Type: text/plain, Size: 983 bytes --]

On Wed, 14 Sep 2011 18:35:37 -0400, Michael Mol wrote about Re: Really
OT now (Re: [gentoo-user] udev + /usr):

> It occurred to me that having a decent C and C++ editing environment
> might ease some of my of the spoilage I've experienced in Visual
> Studio for C++. I'll be checking it out. It'll mean learning emacs,
> though...

If you like Visual Studio, try Geany or KDevelop.  The former is a Gtk+
program, so runs natively under GNOME, Xfce and LXDE, while the latter
is a Qt suite that runs natively under KDE.  Both are *way* slicker
than Emacs or vim, but do require a graphical desktop. [Both vim and
Emacs can run in a text console.]

You might also start reading comp.os.linux.development.apps on Usenet,
if you don't already do so.
-- 
Regards,

Dave  [RLU #314465]
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
dwnoon@ntlworld.com (David W Noon)
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: IDE for C/C++ (Was: Really OT now (Re: [gentoo-user] udev + /usr)

[Michael Mol]

On Thu, Sep 15, 2011 at 2:58 PM, David W Noon <dwnoon@ntlworld.com> wrote:
> On Wed, 14 Sep 2011 18:35:37 -0400, Michael Mol wrote about Re: Really
> OT now (Re: [gentoo-user] udev + /usr):
>
>> It occurred to me that having a decent C and C++ editing environment
>> might ease some of my of the spoilage I've experienced in Visual
>> Studio for C++. I'll be checking it out. It'll mean learning emacs,
>> though...
>
> If you like Visual Studio, try Geany or KDevelop.  The former is a Gtk+
> program, so runs natively under GNOME, Xfce and LXDE, while the latter
> is a Qt suite that runs natively under KDE.  Both are *way* slicker
> than Emacs or vim, but do require a graphical desktop. [Both vim and
> Emacs can run in a text console.]

I'm not touching KDE again for a while. I got nailed pretty bad with a
NVidia/Konsole/KWin, and I really wasn't using much of KDE.

That said, I might poke KDevelop again; I haven't poked it in years.
Geany is new since I last dug around.

I do like text environments, though.

>
> You might also start reading comp.os.linux.development.apps on Usenet,
> if you don't already do so.

Keeping up with this list is hard enough! But, thanks. :)



-- 
:wq

Re: IDE for C/C++ (Was: Really OT now (Re: [gentoo-user] udev + /usr)

[Leonardo Guilherme]

[-- Attachment #1: Type: text/plain, Size: 1740 bytes --]

2011/9/15 Michael Mol <mikemol@gmail.com>

> On Thu, Sep 15, 2011 at 2:58 PM, David W Noon <dwnoon@ntlworld.com> wrote:
> > On Wed, 14 Sep 2011 18:35:37 -0400, Michael Mol wrote about Re: Really
> > OT now (Re: [gentoo-user] udev + /usr):
> >
> >> It occurred to me that having a decent C and C++ editing environment
> >> might ease some of my of the spoilage I've experienced in Visual
> >> Studio for C++. I'll be checking it out. It'll mean learning emacs,
> >> though...
> >
> > If you like Visual Studio, try Geany or KDevelop.  The former is a Gtk+
> > program, so runs natively under GNOME, Xfce and LXDE, while the latter
> > is a Qt suite that runs natively under KDE.  Both are *way* slicker
> > than Emacs or vim, but do require a graphical desktop. [Both vim and
> > Emacs can run in a text console.]
>
> I'm not touching KDE again for a while. I got nailed pretty bad with a
> NVidia/Konsole/KWin, and I really wasn't using much of KDE.
>
> That said, I might poke KDevelop again; I haven't poked it in years.
> Geany is new since I last dug around.
>
> I do like text environments, though.
>
> >
> > You might also start reading comp.os.linux.development.apps on Usenet,
> > if you don't already do so.
>
> Keeping up with this list is hard enough! But, thanks. :)
>
>
>
> --
> :wq
>
>
I do not know the state of Geanny since I last checked (couple of years
ago), but the highlight capabilites of KDevelop got my eye. It highlights
local variables in different colors in the same context, so something like

int foo(float bar, float baz) {
}

will have bar and baz in different colors. Also, support for CMake in
KDevelop got really great and useful. Plus, it supports debugging inside the
editor. Its awesome.

-- 

Leonardo

[-- Attachment #2: Type: text/html, Size: 2396 bytes --]

Re: IDE for C/C++ (Was: Really OT now (Re: [gentoo-user] udev + /usr)

[Chris Brennan]

[-- Attachment #1: Type: text/plain, Size: 986 bytes --]

On Thu, Sep 15, 2011 at 3:47 PM, Leonardo Guilherme
<leonardo.guilherme@gmail.com> wrote:

I do not know the state of Geanny since I last checked (couple of years
> ago), but the highlight capabilites of KDevelop got my eye. It highlights
> local variables in different colors in the same context, so something like
>
> int foo(float bar, float baz) {
> }
>
> will have bar and baz in different colors. Also, support for CMake in
> KDevelop got really great and useful. Plus, it supports debugging inside the
> editor. Its awesome.
>

If you want something in a gui, what about Code::Blocks? It's also
multi-platform....

> --
> Chris Brennan
> A: Yes.
> >Q: Are you sure?
> >>A: Because it reverses the logical flow of conversation.
> >>>Q: Why is top posting frowned upon?
> http://xkcd.com/84/ | http://xkcd.com/149/ | http://xkcd.com/549/
> GPG: D5B20C0C (6741 8EE4 6C7D 11FB 8DA8  9E4A EECD 9A84 D5B2 0C0C)

------------------------------------------------------------------------

[-- Attachment #2: Type: text/html, Size: 1944 bytes --]

Re: IDE for C/C++ (Was: Really OT now (Re: [gentoo-user] udev + /usr)

[Michael Mol]

On Thu, Sep 15, 2011 at 3:59 PM, Chris Brennan <xaero@xaerolimit.net> wrote:
> On Thu, Sep 15, 2011 at 3:47 PM, Leonardo Guilherme
> <leonardo.guilherme@gmail.com> wrote:
>>
>> I do not know the state of Geanny since I last checked (couple of years
>> ago), but the highlight capabilites of KDevelop got my eye. It highlights
>> local variables in different colors in the same context, so something like
>> int foo(float bar, float baz) {
>> }
>> will have bar and baz in different colors. Also, support for CMake in
>> KDevelop got really great and useful. Plus, it supports debugging inside the
>> editor. Its awesome.
>
> If you want something in a gui, what about Code::Blocks? It's also
> multi-platform....

Ok, what are the atom names for all these? I'll start them building,
and they should be done before I get home. (Not so likely if I have to
build all of KDE, but I've got some Qt apps installed, so...)

-- 
:wq

Re: IDE for C/C++ (Was: Really OT now (Re: [gentoo-user] udev + /usr)

[Joost Roeleveld]

On Thursday, September 15, 2011 04:05:29 PM Michael Mol wrote:
> On Thu, Sep 15, 2011 at 3:59 PM, Chris Brennan <xaero@xaerolimit.net> wrote:
> > On Thu, Sep 15, 2011 at 3:47 PM, Leonardo Guilherme
> > 
> > <leonardo.guilherme@gmail.com> wrote:
> >> I do not know the state of Geanny since I last checked (couple of
> >> years
> >> ago), but the highlight capabilites of KDevelop got my eye. It
> >> highlights local variables in different colors in the same context,
> >> so something like int foo(float bar, float baz) {
> >> }
> >> will have bar and baz in different colors. Also, support for CMake in
> >> KDevelop got really great and useful. Plus, it supports debugging
> >> inside the editor. Its awesome.
> > 
> > If you want something in a gui, what about Code::Blocks? It's also
> > multi-platform....
> 
> Ok, what are the atom names for all these? I'll start them building,
> and they should be done before I get home. (Not so likely if I have to
> build all of KDE, but I've got some Qt apps installed, so...)

As Nikos mentioned, I would try qtcreator (dev-util/qt-creator) before 
kdevelop (dev-util/kdevelop).

--
Joost

Re: IDE for C/C++ (Was: Really OT now (Re: [gentoo-user] udev + /usr)

[Michael Mol]

On Thu, Sep 15, 2011 at 3:59 PM, Chris Brennan <xaero@xaerolimit.net> wrote:
> On Thu, Sep 15, 2011 at 3:47 PM, Leonardo Guilherme
> <leonardo.guilherme@gmail.com> wrote:
>>
>> I do not know the state of Geanny since I last checked (couple of years
>> ago), but the highlight capabilites of KDevelop got my eye. It highlights
>> local variables in different colors in the same context, so something like
>> int foo(float bar, float baz) {
>> }
>> will have bar and baz in different colors. Also, support for CMake in
>> KDevelop got really great and useful. Plus, it supports debugging inside the
>> editor. Its awesome.
>
> If you want something in a gui, what about Code::Blocks? It's also
> multi-platform....

dev-util/codeblocks is masked. How well (or poorly) does it work on
Gentoo AMD64?

I did an emerge -p kdevelop...that'd pull back in the large bulk of
KDE. I'm going to have to pass for now. qt-creator has some use flag
changes, but only requires bits of KDE I already have, so I'll be
trying it.

I don't show an ebuild for eclipse (I see dev-java/ant-eclipse-ecj,
dev-java/eclipse-ecj and dev-util/eclipse-sdk). Last time I poked
eclipse, it was a royal pain using any *DT unless one downloaded it as
a packaged deal. Version dependencies were a pain. (That said, I
settled into it fairly quickly. But that was a long time ago)

I don't see an ebuild for Emacs CC-Mode.

-- 
:wq

Re: IDE for C/C++ (Was: Really OT now (Re: [gentoo-user] udev + /usr)

[Michael Schreckenbauer]

On Thursday, 15. September 2011 20:22:17 Michael Mol wrote:
> On Thu, Sep 15, 2011 at 3:59 PM, Chris Brennan <xaero@xaerolimit.net> wrote:
> > On Thu, Sep 15, 2011 at 3:47 PM, Leonardo Guilherme
> > 
> > <leonardo.guilherme@gmail.com> wrote:
> >> I do not know the state of Geanny since I last checked (couple of
> >> years
> >> ago), but the highlight capabilites of KDevelop got my eye. It
> >> highlights local variables in different colors in the same context,
> >> so something like int foo(float bar, float baz) {
> >> }
> >> will have bar and baz in different colors. Also, support for CMake in
> >> KDevelop got really great and useful. Plus, it supports debugging
> >> inside the editor. Its awesome.
> > 
> > If you want something in a gui, what about Code::Blocks? It's also
> > multi-platform....
> 
> dev-util/codeblocks is masked. How well (or poorly) does it work on
> Gentoo AMD64?
> 
> I did an emerge -p kdevelop...that'd pull back in the large bulk of
> KDE. I'm going to have to pass for now.

I' using kdevelop a lot. It's a nice IDE. At least, if you already use KDE as 
I am :)

> qt-creator has some use flag
> changes, but only requires bits of KDE I already have, so I'll be
> trying it.
> 
> I don't show an ebuild for eclipse (I see dev-java/ant-eclipse-ecj,
> dev-java/eclipse-ecj and dev-util/eclipse-sdk). Last time I poked
> eclipse, it was a royal pain using any *DT unless one downloaded it as
> a packaged deal.

Same as my experience. But it's nice, if you do java.

> Version dependencies were a pain. (That said, I
> settled into it fairly quickly. But that was a long time ago)


> I don't see an ebuild for Emacs CC-Mode.

app-xemacs/cc-mode

Regards,
Michael

Re: IDE for C/C++ (Was: Really OT now (Re: [gentoo-user] udev + /usr)

[Mike Edenfield]

On 9/15/2011 8:22 PM, Michael Mol wrote:

> I don't show an ebuild for eclipse (I see dev-java/ant-eclipse-ecj,
> dev-java/eclipse-ecj and dev-util/eclipse-sdk). Last time I poked
> eclipse, it was a royal pain using any *DT unless one downloaded it as
> a packaged deal. Version dependencies were a pain. (That said, I
> settled into it fairly quickly. But that was a long time ago)

You want the one called eclipse-sdk. The actual Eclipse 
product is just a shell that you can then plug in 
development environments -- the JDT (for Java) is the 
"default" but you can also install the CDT (for C/C++) or 
tons of others.

If you want the latest release of Eclipse you'll have to 
download or build it yourself; the "Ganymeade" (3.5) in the 
ebuild works fine but it doesn't support some of the newer 
plug-ins built for "Helios" (3.6) or "Indigo" (3.7). But 3.6 
introduced a *ton* of new dependencies that the Gentoo folks 
haven't been able to work out properly in portage.[1]

Of course, that's also likely an indication that Eclipse is 
getting way to big for it's own good, especially if you 
don't want to do any Java development, so you may just want 
to pass :)

--Mike

[1] https://bugs.gentoo.org/325271?id=325271

Re: IDE for C/C++ (Was: Really OT now (Re: [gentoo-user] udev + /usr)

[Michael Mol]

On Fri, Sep 16, 2011 at 8:30 AM, Mike Edenfield <kutulu@kutulu.org> wrote:
> On 9/15/2011 8:22 PM, Michael Mol wrote:
>
> But 3.6 introduced a *ton* of new dependencies that the Gentoo folks
> haven't been able to work out properly in portage.[1]
>
> Of course, that's also likely an indication that Eclipse is getting way to
> big for it's own good, especially if you don't want to do any Java
> development, so you may just want to pass :)

I feel like there's an "Eclipse is the new Emacs" joke in there somewhere. ;P

-- 
:wq

Re: IDE for C/C++ (Was: Really OT now (Re: [gentoo-user] udev + /usr)

[Alan Mackenzie]

Hi, Michael.

On Thu, Sep 15, 2011 at 08:22:17PM -0400, Michael Mol wrote:

> I don't see an ebuild for Emacs CC-Mode.

CC Mode is distributed along with the rest of {,X}Emacs (although I think
XEmacs half-splits all its packages off from its cord).

Those version of CC Mode are somewhat out of date, as the newer versions
have not yet percolated their way through to {,X}Emacs themselves.  The
most recent version is available from
<http://cc-mode.sourceforge.net/release.php>

> -- 
> :wq

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: IDE for C/C++ (Was: Really OT now (Re: [gentoo-user] udev + /usr)

[Alexander Tanyukevich]

On Thu, Sep 15, 2011 at 9:16 PM, Michael Mol <mikemol@gmail.com> wrote:
>
> I'm not touching KDE again for a while. I got nailed pretty bad with a
> NVidia/Konsole/KWin, and I really wasn't using much of KDE.
>
> That said, I might poke KDevelop again; I haven't poked it in years.
> Geany is new since I last dug around.
>
> I do like text environments, though.

Try eclipse with cdk (C/C++ developr kit). Last time I've used it 3
years ago, but it was really good...

-- 
Alexander Tanyukevich
atanyukevich@gmail.com

Re: IDE for C/C++ (Was: Really OT now (Re: [gentoo-user] udev + /usr)

[Alexander Tanyukevich]

On Thu, Sep 15, 2011 at 11:37 PM, Alexander Tanyukevich
<atanyukevich@gmail.com> wrote:
> Try eclipse with cdk (C/C++ developr kit). Last time I've used it 3
> years ago, but it was really good...

Sorry it's called CDT.

-- 
Alexander Tanyukevich
atanyukevich@gmail.com

[gentoo-user] Re: Really OT now (Re: udev + /usr)

[Nikos Chantziaras]

On 09/15/2011 01:35 AM, Michael Mol wrote:
> On Wed, Sep 14, 2011 at 6:05 PM, Michael Schreckenbauer<grimlog@gmx.de>  wrote:
>> Hi Alan,
>>
>> On Wednesday, 14. September 2011 21:34:01 Alan Mackenzie wrote:
>>> I've been contributing to Emacs in general and CC Mode in particular for
>>> 10 years.  I've been the sole maintainer of CC Mode (the mode used for
>>> coding in C, C++, Objective C, Java, Awk, and a couple of others, and an
>>> unknown number of derived modes) for around 5 years.  Over that time I've
>>> spent thousands of hours on the project.  My latest release was on
>>> Monday, and you can find it at
>>> <http://cc-mode.sourceforge.net/release.php>.  If you use {,X}Emacs to
>>> hack in any these languages, I recommend you to download and install it.
>>
>> although I'm a vim-using guy, and that only if no kate is available, I have
>> emacs and cc-mode installed on every machine I use for coding. At times I even
>> use it :)
>> Really cool stuff you do there and thanks for the work.
>
> It occurred to me that having a decent C and C++ editing environment
> might ease some of my of the spoilage I've experienced in Visual
> Studio for C++. I'll be checking it out. It'll mean learning emacs,
> though...

Qt Creator is the best IDE I've ever used.  The main strength is that 
it's very simple and easy to use, and yet very powerful.

I've used a lot others too, from DevC++ to Visual Studio, Eclipse and 
KDevelop.  Qt Creator is the only one I actually enjoy working with. 
With the other, I usually utter some swear word every other minute.

Re: [gentoo-user] udev + /usr

[Stroller]

On 14 September 2011, at 22:34, Alan Mackenzie wrote:
> …
>> That's got nothing to do with it, and it's rude of you to make this
>> about Canek, IMO.
> 
> Given how much Canek has been saying about free/open source recently, the
> attitudes he's been attributing to its developers (which don't accord
> with my experience of them), and the number of times he's told people,
> in a manner I find very rude, to "stop moaning and code it yourself" -
> given all of this, I find it reasonable to question Canek's background.
> I'm not the only one of us getting irritated by him.

Personally, I'm getting really irritated with all the people who expect someone else to fix their problems.

It's a fact of open-source software that you can write the dev a polite note saying "have you considered this approach?" and if you don't like the answer then you can code it yourself. Use BSD, write your own kernel, buy a copy of Windows - those are your other alternatives. 

Bitching about the author on here, 100 posts of complaining, does naff all good. That doesn't solve the problem. The only people who are listening are your mates, who already agree with you. You're not trying to persuade anyone to your point of view in accusing the software authors of being stupid or short-sighted. 

Yes, I *still* think it was rude of you to try to make this issue about Canek. 

I don't know what "attitude" you think Canek is attributing to OSS developers, because what I'm mostly seeing is those on your side of the field accusing the udev devs of being "shallow" and "single-distro orientated". Of "not talking to anyone". 

This is not about Canek. Or me. Or you. This is about udev, a piece of software.
If you don't like it, you have the source code. 

I'm not going to respond in detail to the rest of your post. 

It sounds like you have an excellent background to go fixing the problems. 

If you've got questions for the udev authors, ask them, but they're probably not reading this list.

Note that you're not required to talk to anyone else before coding your solution. If people like it, they'll use it. If you go talking to other people first you'll probably get a thousand different answers and options and a thousand different people telling you to do it some other way. So it's probably better if you get your code into some kind of working state and just worry about it solving your problem.

Stroller.

Re: [gentoo-user] udev + /usr

[David W Noon]

[-- Attachment #1: Type: text/plain, Size: 489 bytes --]

On Tue, 13 Sep 2011 15:38:41 +0000, Alan Mackenzie wrote about Re:
[gentoo-user] udev + /usr:

> Still, there's one program that can't be
> moved, and that's /sbin/init.  :-)

Says you! ... :-)

  man 8 switch_root

The second parameter is the revised init.
-- 
Regards,

Dave  [RLU #314465]
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
dwnoon@ntlworld.com (David W Noon)
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-user] udev + /usr

[Mike Edenfield]

On 9/13/2011 10:40 AM, Alan Mackenzie wrote:
> On Mon, Sep 12, 2011 at 07:50:13PM +0200, Michael Schreckenbauer wrote:

>> it works for you, because your udev-rules need nothing from /usr/*
>> It's *not* udev requiring /usr, it's the scripts triggered by the rules.
>
> Ah.  OK.  Maybe I've misunderstood the whole thing.  Could it be that
> there's no explicit requirement for early mounting of /usr, providing one
> has the discipline to keep everything needed for booting in the /
> partition?

I don't think you are misunderstanding things. According to 
the originally referenced email thread:

---
(From KS@Fedora):

We are actually currently planning to move all tools from 
the rootfs to /usr, where they belong and sort out the 
chaotic split of install locations. There will be only 
compat symlinks left in / then.
---

The udev package (and, apparently, everything else from 
Fedora) will, as distributed by the upstream developers, 
install itself to /usr instead of /. *Right now* udev fails 
to load a specific device if /usr is not mounted and the 
udev rule tries to access something in /usr. *In the future* 
udev will fail to load at all if /usr is not mounted, if the 
changes progress as they are being proposed.

--Mike

Re: [gentoo-user] udev + /usr

[Mike Edenfield]

On 9/12/2011 1:17 PM, Alan Mackenzie wrote:

> Well, I'm a hacker.  udev is free source, therefore fair game.  I don't
> intend to put up with this nonsense without a fight.  As far as I can
> make out, this is just one guy, Kay Sievers, who's on a power trip.  Are
> there any indications at all that he actually talked to anybody in the
> wide world before making such a far reaching decision?

http://www.freedesktop.org/wiki/Software/systemd/separate-usr-is-broken

Re: [gentoo-user] udev + /usr

[Neil Bothwick]

[-- Attachment #1: Type: text/plain, Size: 859 bytes --]

On Tue, 13 Sep 2011 08:38:30 -0400, Mike Edenfield wrote:

> > Well, I'm a hacker.  udev is free source, therefore fair game.  I
> > don't intend to put up with this nonsense without a fight.  As far as
> > I can make out, this is just one guy, Kay Sievers, who's on a power
> > trip.  Are there any indications at all that he actually talked to
> > anybody in the wide world before making such a far reaching
> > decision?  
> 
> http://www.freedesktop.org/wiki/Software/systemd/separate-usr-is-broken

Apart from vague references to "us" and "many upstream developers" there
is no real indication that this is motivated by any more than the one
individual, from his RedHatesque perspective.


-- 
Neil Bothwick

When you go to court you are putting yourself in the hands of 12 people
that were not smart enough to get out of jury duty.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-user] udev + /usr

[Stroller]

On 13 September 2011, at 13:45, Neil Bothwick wrote:
>> ...
>> http://www.freedesktop.org/wiki/Software/systemd/separate-usr-is-broken
> 
> Apart from vague references to "us" and "many upstream developers" there
> is no real indication that this is motivated by any more than the one
> individual, from his RedHatesque perspective.

Doesn't like conclusions of expert.

<meme image>

Accuses expert of fabricating their experiences.

Re: [gentoo-user] udev + /usr

[Neil Bothwick]

[-- Attachment #1: Type: text/plain, Size: 1088 bytes --]

On Tue, 13 Sep 2011 16:09:59 +0100, Stroller wrote:

> >> http://www.freedesktop.org/wiki/Software/systemd/separate-usr-is-broken  
> > 
> > Apart from vague references to "us" and "many upstream developers"
> > there is no real indication that this is motivated by any more than
> > the one individual, from his RedHatesque perspective.  
> 
> Doesn't like conclusions of expert.
> 
> <meme image>
> 
> Accuses expert of fabricating their experiences.
> 

Disagrees with perceived meaning

Takes post out of context.

I gave no opinion on the content of the post, but that link was the
(only) response to the question " Are there any indications at all that
he actually talked to anybody in the wide world before making such a far
reaching decision?". The link gives no such indications because it is
written by the same person and only makes vague references to others.

My agreement or otherwise with the dev's decisions and opinions has no
bearing on that.


-- 
Neil Bothwick

"Time is the best teacher....., unfortunately it kills all the students"

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-user] udev + /usr

[Mike Edenfield]

On 9/13/2011 8:45 AM, Neil Bothwick wrote:
> On Tue, 13 Sep 2011 08:38:30 -0400, Mike Edenfield wrote:
>
>>> Well, I'm a hacker.  udev is free source, therefore fair game.  I
>>> don't intend to put up with this nonsense without a fight.  As far as
>>> I can make out, this is just one guy, Kay Sievers, who's on a power
>>> trip.  Are there any indications at all that he actually talked to
>>> anybody in the wide world before making such a far reaching
>>> decision?
>>
>> http://www.freedesktop.org/wiki/Software/systemd/separate-usr-is-broken
>
> Apart from vague references to "us" and "many upstream developers" there
> is no real indication that this is motivated by any more than the one
> individual, from his RedHatesque perspective.

To be fair, there are *two* names in the wiki edit history :)

Though I also recall Mr. Poettering's name being mentioned 
elsewhere in this thread, also in an 
"anti-everything-thats-not-Fedora" context, though I have no 
personal experience in that arena.

--Mike

Re: [gentoo-user] udev + /usr

[Michael Mol]

On Tue, Sep 13, 2011 at 8:38 AM, Mike Edenfield <kutulu@kutulu.org> wrote:
> On 9/12/2011 1:17 PM, Alan Mackenzie wrote:
>
>> Well, I'm a hacker.  udev is free source, therefore fair game.  I don't
>> intend to put up with this nonsense without a fight.  As far as I can
>> make out, this is just one guy, Kay Sievers, who's on a power trip.  Are
>> there any indications at all that he actually talked to anybody in the
>> wide world before making such a far reaching decision?
>
> http://www.freedesktop.org/wiki/Software/systemd/separate-usr-is-broken

I think this link has been mentioned somewhere between 3 and 5 times,
now. This _thread_ needs a FAQ.

-- 
:wq

Re: [gentoo-user] udev + /usr

[pk]

On 2011-09-13 14:38, Mike Edenfield wrote:

> http://www.freedesktop.org/wiki/Software/systemd/separate-usr-is-broken

Yes, udev _needs_ to change to fit systemd; a tool looking for a
non-existant problem to solve (me notes that this is exactly the same
for pulseaudio). Well, isn't that nice...

PS. If it isn't obvious that I'm trying to be sarcastic, then I'll blame
it on me not being an english native speaker... :-)

Best regards

Peter K

Re: [gentoo-user] udev + /usr

[Alan McKinnon]

On Mon, 12 Sep 2011 17:33:34 +0200
Michael Schreckenbauer <grimlog@gmx.de> wrote:

> Every udev version works this way.
> Fixing udev to continue working with separate /usr is far from
> trivial imo. Changing some paths is not the way to go for sure.
> First of all, udev has to distinguish between "device not present"
> and "script error of some kind". Failing scripts have to be queued
> somehow for later execution. If a script keeps failing, it has to be
> removed from that queue, with a message to syslog or something like
> that. If udev needs a script in /usr/* to mount /usr then there's a
> chicken-egg-problem, which could be hard to solve (if possible at all
> without moving things from /usr/ to /). Note, that I am wild guessing
> here, I did not study the udev sources or any related script/rule :)

To expand on that:

udev running at early boot time and udev running later with a full
userspace mounted are very different things. udev should be able to
differentiate between these two phases and modify it's behaviour. Put
another way:

The thing that lays the foundation for the full userspace to be in
place *CANNOT* assume the existence of the full userspace. That's like
the wall assuming the roof must exist.

Furthermore, it's not at all a case that /usr must be mounted - that's
just an interesting artifact, and expression of where stuff is. The
correct description is more like "the script that udev launches must be
available to udev *when* udev launches it". I think concentrating on
the problem expressed in this wise would open the door to better
solutions.

I do like the idea of a phase 1 and phase 2 approach by udev - early
boot and full userspace running.

-- 
Alan McKinnnon
alan.mckinnon@gmail.com

Re: [gentoo-user] udev + /usr

[Canek Peláez Valdés]

On Mon, Sep 12, 2011 at 11:02 AM, Alan Mackenzie <acm@muc.de> wrote:
> Hi, everybody.
>
> Hope nobody minds me starting a new thread with an accurate name.
>
> Which version of udev is it that has this nauseating feature of needing
> /usr loaded to boot?
>
> Somewhere in that version's source will be several (or lots of) "/usr".
> Just how difficult is it going to be to replace "/usr/bin" with "/bin"
> throughout the source?
>
> udev is part of the kernel.  How come the kernel hackers aren't up in
> arms about this as much as we are?  Or are they, maybe?  In which case,
> maybe the kernel people would welcome an option to disrequire the early
> mounting of /usr as much as we would.
>
> Anyhow, I'd like to take a peek at the source code which does this evil
> thing.  Would somebody please tell me which version of udev is involved.
>
> Thanks.

(This would be my only post in this new thread: I think I have made my
point of view clear in the other thread).

I have seen a lot of disinformation going on in the other threads
(like some people suggesting that /var would not be able to be on its
own partition at some point in the future). Just before everyone start
to wildy conjecture, please take a look at this:

http://www.freedesktop.org/wiki/Software/systemd/separate-usr-is-broken

Also, a look at this thread is maybe justified:

http://thread.gmane.org/gmane.comp.sysutils.systemd.devel/1728/

Both things are in the context of systemd, but it's related to the
discussion at hand. I know not everybody wants to use systemd, and
think Lennart and Kay are the root of all that is wrong and evil on
the world, but I will recommend everyone interested in the reasons of
the push for a recommended initramfs to take a look at the page in
fd.org, and the thread in the systemd mailing list. Even if you don't
agree with the reasoning, it is worth to take a look at it.

As for me, I would say one last time my POV: Linux strives to be much
more than Unix, and that means do things differently. It will always
be capable of do anything that Unix does, and most of the time it will
do it better. But that doesn't (necessarily) means that it will do it
in the same way.

And many of us don't take "but my config/setup/partition works now" as
a valid argument to restrain progress.

Change happens.

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

Re: [gentoo-user] udev + /usr

[Michael Schreckenbauer]

Hi Canek,

On Monday, 12. September 2011 11:35:13 Canek Peláez Valdés wrote:
> (This would be my only post in this new thread: I think I have made my
> point of view clear in the other thread).
> 
> I have seen a lot of disinformation going on in the other threads
> (like some people suggesting that /var would not be able to be on its
> own partition at some point in the future). Just before everyone start
> to wildy conjecture, please take a look at this:
> 
> http://www.freedesktop.org/wiki/Software/systemd/separate-usr-is-broken

well, the culprit here is:
"The binaries called from these rules are sometimes located on /usr/bin, or 
link against libraries in /usr/lib, or use data files from /usr/share. If these 
rules fail udev will proceed with the next one, however later on applications 
will then not properly detect these udev devices or features of these 
devices."

Why doesn't udev queue failing scripts for later execution? It just assumes 
everything is in place in the moment it needs it. This is bad design for a 
tool, coming in so early in the boot process.

> Also, a look at this thread is maybe justified:
> http://thread.gmane.org/gmane.comp.sysutils.systemd.devel/1728/

Same thing here. This all basically reads "We did some really bad design 
choices, now let's fix the surroundings."
The following sentence really made me laugh:

"> If so, what does LSB say to this new directory?

Nothing really, they just document current common practice. We might
request an update to LSB after it is used for a while and has shown
that it is what we want."

He does not know, if the thing he designed is the thing he wants.
That's ridiculous!

> Change happens.

We already know this.

> Regards everyone.

Best,
Michael

Re: [gentoo-user] udev + /usr

[Paul Colquhoun]

On Mon, 12 Sep 2011 05:59:29 PM Michael Schreckenbauer wrote:
> Hi Canek,
> 
> On Monday, 12. September 2011 11:35:13 Canek Peláez Valdés wrote:
> > (This would be my only post in this new thread: I think I have made my
> > point of view clear in the other thread).
> > 
> > I have seen a lot of disinformation going on in the other threads
> > (like some people suggesting that /var would not be able to be on its
> > own partition at some point in the future). Just before everyone start
> > to wildy conjecture, please take a look at this:
> > 
> > http://www.freedesktop.org/wiki/Software/systemd/separate-usr-is-broken
> 
> well, the culprit here is:
> "The binaries called from these rules are sometimes located on /usr/bin, or
> link against libraries in /usr/lib, or use data files from /usr/share. If
> these rules fail udev will proceed with the next one, however later on
> applications will then not properly detect these udev devices or features
> of these devices."


My major worry is that udev is happily running arbitrary scripts from 
arbitrary locations early in the boot process, and is actively trying to make 
this easier.

How much more Microsoft-security-ish do we want Linux to get?

From a paranoid-security point of view, I think the proper solution is to just 
*insist* that all scripts/executables run from udev be located in /{s}bin * 
/lib  (or even in /udev_libexec) and run all scripts from a restricted shell 
to stop them just redirecting to somplace less secure.

Does udev even check to see if the scripts/executables are owned by root (a 
plus) or world writable (a big minus)?

I hope it doesn't take a Linux virus/worm using udev as a vector to prompt a 
review.

 
> Why doesn't udev queue failing scripts for later execution? It just assumes
> everything is in place in the moment it needs it. This is bad design for a
> tool, coming in so early in the boot process.
> 
> > Also, a look at this thread is maybe justified:
> > http://thread.gmane.org/gmane.comp.sysutils.systemd.devel/1728/
> 
> Same thing here. This all basically reads "We did some really bad design
> choices, now let's fix the surroundings."
> The following sentence really made me laugh:
> 
> "> If so, what does LSB say to this new directory?
> 
> Nothing really, they just document current common practice. We might
> request an update to LSB after it is used for a while and has shown
> that it is what we want."
> 
> He does not know, if the thing he designed is the thing he wants.
> That's ridiculous!
> 
> > Change happens.
> 
> We already know this.
> 
> > Regards everyone.
> 
> Best,
> Michael
-- 
Reverend Paul Colquhoun, ULC.    http://andor.dropbear.id.au/~paulcol
 Before you criticize someone, you should walk a mile in their shoes.
Then, when you do, you'll be a mile away, and you'll have their shoes.

Re: [gentoo-user] udev + /usr

[Dale]

Canek Peláez Valdés wrote:
> On Mon, Sep 12, 2011 at 11:02 AM, Alan Mackenzie<acm@muc.de>  wrote:
>> Hi, everybody.
>>
>> Hope nobody minds me starting a new thread with an accurate name.
>>
>> Which version of udev is it that has this nauseating feature of needing
>> /usr loaded to boot?
>>
>> Somewhere in that version's source will be several (or lots of) "/usr".
>> Just how difficult is it going to be to replace "/usr/bin" with "/bin"
>> throughout the source?
>>
>> udev is part of the kernel.  How come the kernel hackers aren't up in
>> arms about this as much as we are?  Or are they, maybe?  In which case,
>> maybe the kernel people would welcome an option to disrequire the early
>> mounting of /usr as much as we would.
>>
>> Anyhow, I'd like to take a peek at the source code which does this evil
>> thing.  Would somebody please tell me which version of udev is involved.
>>
>> Thanks.
> (This would be my only post in this new thread: I think I have made my
> point of view clear in the other thread).
>
> I have seen a lot of disinformation going on in the other threads
> (like some people suggesting that /var would not be able to be on its
> own partition at some point in the future). Just before everyone start
> to wildy conjecture, please take a look at this:
>
> http://www.freedesktop.org/wiki/Software/systemd/separate-usr-is-broken
>
> Also, a look at this thread is maybe justified:
>
> http://thread.gmane.org/gmane.comp.sysutils.systemd.devel/1728/
>
> Both things are in the context of systemd, but it's related to the
> discussion at hand. I know not everybody wants to use systemd, and
> think Lennart and Kay are the root of all that is wrong and evil on
> the world, but I will recommend everyone interested in the reasons of
> the push for a recommended initramfs to take a look at the page in
> fd.org, and the thread in the systemd mailing list. Even if you don't
> agree with the reasoning, it is worth to take a look at it.
>
> As for me, I would say one last time my POV: Linux strives to be much
> more than Unix, and that means do things differently. It will always
> be capable of do anything that Unix does, and most of the time it will
> do it better. But that doesn't (necessarily) means that it will do it
> in the same way.
>
> And many of us don't take "but my config/setup/partition works now" as
> a valid argument to restrain progress.
>
> Change happens.
>
> Regards everyone.

You say it was disinformation about /var.  Care to explain why me and 
one other person read the same thing?  It was mentioned on -dev.  I was 
pretty sure it was and then another person posted they read the same.  
So, I'm almost certain it was said at this point.  Surely we can't both 
be wrong.

Dale

:-)  :-)

Re: [gentoo-user] udev + /usr

[Canek Peláez Valdés]

On Mon, Sep 12, 2011 at 12:21 PM, Dale <rdalek1967@gmail.com> wrote:
> Canek Peláez Valdés wrote:
>>
>> On Mon, Sep 12, 2011 at 11:02 AM, Alan Mackenzie<acm@muc.de>  wrote:
>>>
>>> Hi, everybody.
>>>
>>> Hope nobody minds me starting a new thread with an accurate name.
>>>
>>> Which version of udev is it that has this nauseating feature of needing
>>> /usr loaded to boot?
>>>
>>> Somewhere in that version's source will be several (or lots of) "/usr".
>>> Just how difficult is it going to be to replace "/usr/bin" with "/bin"
>>> throughout the source?
>>>
>>> udev is part of the kernel.  How come the kernel hackers aren't up in
>>> arms about this as much as we are?  Or are they, maybe?  In which case,
>>> maybe the kernel people would welcome an option to disrequire the early
>>> mounting of /usr as much as we would.
>>>
>>> Anyhow, I'd like to take a peek at the source code which does this evil
>>> thing.  Would somebody please tell me which version of udev is involved.
>>>
>>> Thanks.
>>
>> (This would be my only post in this new thread: I think I have made my
>> point of view clear in the other thread).
>>
>> I have seen a lot of disinformation going on in the other threads
>> (like some people suggesting that /var would not be able to be on its
>> own partition at some point in the future). Just before everyone start
>> to wildy conjecture, please take a look at this:
>>
>> http://www.freedesktop.org/wiki/Software/systemd/separate-usr-is-broken
>>
>> Also, a look at this thread is maybe justified:
>>
>> http://thread.gmane.org/gmane.comp.sysutils.systemd.devel/1728/
>>
>> Both things are in the context of systemd, but it's related to the
>> discussion at hand. I know not everybody wants to use systemd, and
>> think Lennart and Kay are the root of all that is wrong and evil on
>> the world, but I will recommend everyone interested in the reasons of
>> the push for a recommended initramfs to take a look at the page in
>> fd.org, and the thread in the systemd mailing list. Even if you don't
>> agree with the reasoning, it is worth to take a look at it.
>>
>> As for me, I would say one last time my POV: Linux strives to be much
>> more than Unix, and that means do things differently. It will always
>> be capable of do anything that Unix does, and most of the time it will
>> do it better. But that doesn't (necessarily) means that it will do it
>> in the same way.
>>
>> And many of us don't take "but my config/setup/partition works now" as
>> a valid argument to restrain progress.
>>
>> Change happens.
>>
>> Regards everyone.
>
> You say it was disinformation about /var.  Care to explain why me and one
> other person read the same thing?  It was mentioned on -dev.  I was pretty
> sure it was and then another person posted they read the same.  So, I'm
> almost certain it was said at this point.  Surely we can't both be wrong.

Where did you guys read it? Who said /var could not be in its own
partition anymore? What piece of code stops working if /var it's in
its own partition? Who is proposing that a separated /var will not be
supported in the future?

The thread I post talks about /var/run and /var/lock needing to be
symbolic links to /run and /lock, but AFAIK (and I tend to follow this
sort of things) /var not only can be in its own partition, it is the
recommended setup.

Saying that proposing /run and /lock to be available at boot time
means that in the future a separated /var partition could be not
supported is, in my book, disinformation. /var/run and /var/lock (by
definition) are almost empty (in space). /var/lib usually stores whole
databases. The difference is important and relevant.

Damn, this list is like crack.

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

Re: [gentoo-user] udev + /usr

[Michael Schreckenbauer]

On Monday, 12. September 2011 12:42:00 Canek Peláez Valdés wrote:
> On Mon, Sep 12, 2011 at 12:21 PM, Dale <rdalek1967@gmail.com> wrote:
> > You say it was disinformation about /var.  Care to explain why me and
> > one
> > other person read the same thing?  It was mentioned on -dev.  I was
> > pretty sure it was and then another person posted they read the same.
> >  So, I'm almost certain it was said at this point.  Surely we can't
> > both be wrong.
> Where did you guys read it? Who said /var could not be in its own
> partition anymore? What piece of code stops working if /var it's in
> its own partition? Who is proposing that a separated /var will not be
> supported in the future?

Just have a look in /var/lib/* for example.
You guarantee, that nothing of this stuff is or will be needed by udev?

> The thread I post talks about /var/run and /var/lock needing to be
> symbolic links to /run and /lock, but AFAIK (and I tend to follow this
> sort of things) /var not only can be in its own partition, it is the
> recommended setup.

Yes. Until this dev has his next brilliant idea.

> Saying that proposing /run and /lock to be available at boot time
> Damn, this list is like crack.

For sure :)

> Regards everyone.

Best,
Michael

Re: [gentoo-user] udev + /usr

[Canek Peláez Valdés]

On Mon, Sep 12, 2011 at 12:52 PM, Michael Schreckenbauer <grimlog@gmx.de> wrote:
> On Monday, 12. September 2011 12:42:00 Canek Peláez Valdés wrote:
>> On Mon, Sep 12, 2011 at 12:21 PM, Dale <rdalek1967@gmail.com> wrote:
>> > You say it was disinformation about /var.  Care to explain why me and
>> > one
>> > other person read the same thing?  It was mentioned on -dev.  I was
>> > pretty sure it was and then another person posted they read the same.
>> >  So, I'm almost certain it was said at this point.  Surely we can't
>> > both be wrong.
>> Where did you guys read it? Who said /var could not be in its own
>> partition anymore? What piece of code stops working if /var it's in
>> its own partition? Who is proposing that a separated /var will not be
>> supported in the future?
>
> Just have a look in /var/lib/* for example.

I did mentioned /var/lib two paragraphs below. Do you guys respond an
email while you read it?

> You guarantee, that nothing of this stuff is or will be needed by udev?

I don't have to. Contrary to most of the guys here (I'm not saying you
are one of them), I don't see the proposed change as "irrational". It
makes complete sense (you actually mention several reasons why it
makes sense in others emails here to Alan and others).

Requiring /var to be on / would not make sense. Even more: then the
idea of /run and /lock on / would be completely insane, if eventually
they would require a non separated /var. The proposal of /run and
/lock on / is exactly to allow /var to be on its own partition on te
foreseeable future.

>> The thread I post talks about /var/run and /var/lock needing to be
>> symbolic links to /run and /lock, but AFAIK (and I tend to follow this
>> sort of things) /var not only can be in its own partition, it is the
>> recommended setup.
>
> Yes. Until this dev has his next brilliant idea.

Give them some credit. This whole lot of changes is not the imposition
of some crazy dev. Is the result of years of the Open Source stack
evolving, and writing the code that implements a design.

In particula Kay has been writing code in udev since 2003, with
version 003. I would think he actually knows the problem, and even if
you don't agree with his design, you got to recognize that he is the
most knowledgeable guy wrt the problem.

And I mean the *general* problem, not the "I have a server since 1964
and if the design I've been using since the Middle Ages has been
working all this time I don't see any reason to change it".

>> Saying that proposing /run and /lock to be available at boot time
>> Damn, this list is like crack.
>
> For sure :)

Yeah. I will need to break out cold turkey at some point.

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

Re: [gentoo-user] udev + /usr

[Michael Schreckenbauer]

On Monday, 12. September 2011 14:26:13 Canek Peláez Valdés wrote:
> On Mon, Sep 12, 2011 at 12:52 PM, Michael Schreckenbauer <grimlog@gmx.de> 
wrote:
> > On Monday, 12. September 2011 12:42:00 Canek Peláez Valdés wrote:
> >> On Mon, Sep 12, 2011 at 12:21 PM, Dale <rdalek1967@gmail.com> wrote:
> >> > You say it was disinformation about /var.  Care to explain why me
> >> > and
> >> > one
> >> > other person read the same thing?  It was mentioned on -dev.  I
> >> > was
> >> > pretty sure it was and then another person posted they read the
> >> > same.
> >> >  So, I'm almost certain it was said at this point.  Surely we
> >> > can't
> >> > both be wrong.
> >> 
> >> Where did you guys read it? Who said /var could not be in its own
> >> partition anymore? What piece of code stops working if /var it's in
> >> its own partition? Who is proposing that a separated /var will not be
> >> supported in the future?
> > 
> > Just have a look in /var/lib/* for example.
> 
> I did mentioned /var/lib two paragraphs below. Do you guys respond an
> email while you read it?

Of course I read the mails I answer!
You wrote:
"var/lib usually stores whole
databases."
And I said, have a look into it. You did?
Could you explain to me, what /var/lib/alsa has to do with databases?
Or /var/lib/dbus?

> > You guarantee, that nothing of this stuff is or will be needed by udev?
> 
> I don't have to. Contrary to most of the guys here (I'm not saying you
> are one of them), I don't see the proposed change as "irrational". It
> makes complete sense (you actually mention several reasons why it
> makes sense in others emails here to Alan and others).

No, I don't say, "it makes sense", because it does not.
I know, *why* this is done, that's something completly different from "making 
sense". What makes sense is fixing udev. Marking devices as "not present", 
because scripts are not available, is bad design.

> Requiring /var to be on / would not make sense.

Yes. Makes no sense. And now *look* into /var/lib.

You guarantee, nothing in there is or will be needed by udev?

> Even more: then the
> idea of /run and /lock on / would be completely insane, if eventually
> they would require a non separated /var. The proposal of /run and
> /lock on / is exactly to allow /var to be on its own partition on te
> foreseeable future.
> 
> >> The thread I post talks about /var/run and /var/lock needing to be
> >> symbolic links to /run and /lock, but AFAIK (and I tend to follow this
> >> sort of things) /var not only can be in its own partition, it is the
> >> recommended setup.
> > 
> > Yes. Until this dev has his next brilliant idea.
> 
> Give them some credit. This whole lot of changes is not the imposition
> of some crazy dev. Is the result of years of the Open Source stack
> evolving, and writing the code that implements a design.

I give him credits. I don't think, he is an idiot. But I really think, the 
design is bad and needs to be fixed.

Regards,
Michael

Re: [gentoo-user] udev + /usr

[Michael Mol]

On Mon, Sep 12, 2011 at 12:42 PM, Canek Peláez Valdés <caneko@gmail.com> wrote:
> On Mon, Sep 12, 2011 at 12:21 PM, Dale <rdalek1967@gmail.com> wrote:
>> Canek Peláez Valdés wrote:
>>>
>>> On Mon, Sep 12, 2011 at 11:02 AM, Alan Mackenzie<acm@muc.de>  wrote:
>>>>
>>>> Hi, everybody.
>>>>
>>>> Hope nobody minds me starting a new thread with an accurate name.
>>>>
>>>> Which version of udev is it that has this nauseating feature of needing
>>>> /usr loaded to boot?
>>>>
>>>> Somewhere in that version's source will be several (or lots of) "/usr".
>>>> Just how difficult is it going to be to replace "/usr/bin" with "/bin"
>>>> throughout the source?
>>>>
>>>> udev is part of the kernel.  How come the kernel hackers aren't up in
>>>> arms about this as much as we are?  Or are they, maybe?  In which case,
>>>> maybe the kernel people would welcome an option to disrequire the early
>>>> mounting of /usr as much as we would.
>>>>
>>>> Anyhow, I'd like to take a peek at the source code which does this evil
>>>> thing.  Would somebody please tell me which version of udev is involved.
>>>>
>>>> Thanks.
>>>
>>> (This would be my only post in this new thread: I think I have made my
>>> point of view clear in the other thread).
>>>
>>> I have seen a lot of disinformation going on in the other threads
>>> (like some people suggesting that /var would not be able to be on its
>>> own partition at some point in the future). Just before everyone start
>>> to wildy conjecture, please take a look at this:
>>>
>>> http://www.freedesktop.org/wiki/Software/systemd/separate-usr-is-broken
>>>
>>> Also, a look at this thread is maybe justified:
>>>
>>> http://thread.gmane.org/gmane.comp.sysutils.systemd.devel/1728/
>>>
>>> Both things are in the context of systemd, but it's related to the
>>> discussion at hand. I know not everybody wants to use systemd, and
>>> think Lennart and Kay are the root of all that is wrong and evil on
>>> the world, but I will recommend everyone interested in the reasons of
>>> the push for a recommended initramfs to take a look at the page in
>>> fd.org, and the thread in the systemd mailing list. Even if you don't
>>> agree with the reasoning, it is worth to take a look at it.
>>>
>>> As for me, I would say one last time my POV: Linux strives to be much
>>> more than Unix, and that means do things differently. It will always
>>> be capable of do anything that Unix does, and most of the time it will
>>> do it better. But that doesn't (necessarily) means that it will do it
>>> in the same way.
>>>
>>> And many of us don't take "but my config/setup/partition works now" as
>>> a valid argument to restrain progress.
>>>
>>> Change happens.
>>>
>>> Regards everyone.
>>
>> You say it was disinformation about /var.  Care to explain why me and one
>> other person read the same thing?  It was mentioned on -dev.  I was pretty
>> sure it was and then another person posted they read the same.  So, I'm
>> almost certain it was said at this point.  Surely we can't both be wrong.
>
> Where did you guys read it? Who said /var could not be in its own
> partition anymore? What piece of code stops working if /var it's in
> its own partition? Who is proposing that a separated /var will not be
> supported in the future?
>
> The thread I post talks about /var/run and /var/lock needing to be
> symbolic links to /run and /lock, but AFAIK (and I tend to follow this
> sort of things) /var not only can be in its own partition, it is the
> recommended setup.
>
> Saying that proposing /run and /lock to be available at boot time
> means that in the future a separated /var partition could be not
> supported is, in my book, disinformation. /var/run and /var/lock (by
> definition) are almost empty (in space). /var/lib usually stores whole
> databases. The difference is important and relevant.
>
> Damn, this list is like crack.

http://xkcd.com/386/


-- 
:wq

Re: [gentoo-user] udev + /usr

[Alan McKinnon]

On Mon, 12 Sep 2011 12:42:00 -0400
Canek Peláez Valdés <caneko@gmail.com> wrote:

> On Mon, Sep 12, 2011 at 12:21 PM, Dale <rdalek1967@gmail.com> wrote:
> > Canek Peláez Valdés wrote:
> >>
> >> On Mon, Sep 12, 2011 at 11:02 AM, Alan Mackenzie<acm@muc.de>
> >>  wrote:
> >>>
> >>> Hi, everybody.
> >>>
> >>> Hope nobody minds me starting a new thread with an accurate name.
> >>>
> >>> Which version of udev is it that has this nauseating feature of
> >>> needing /usr loaded to boot?
> >>>
> >>> Somewhere in that version's source will be several (or lots of)
> >>> "/usr". Just how difficult is it going to be to replace
> >>> "/usr/bin" with "/bin" throughout the source?
> >>>
> >>> udev is part of the kernel.  How come the kernel hackers aren't
> >>> up in arms about this as much as we are?  Or are they, maybe?  In
> >>> which case, maybe the kernel people would welcome an option to
> >>> disrequire the early mounting of /usr as much as we would.
> >>>
> >>> Anyhow, I'd like to take a peek at the source code which does
> >>> this evil thing.  Would somebody please tell me which version of
> >>> udev is involved.
> >>>
> >>> Thanks.
> >>
> >> (This would be my only post in this new thread: I think I have
> >> made my point of view clear in the other thread).
> >>
> >> I have seen a lot of disinformation going on in the other threads
> >> (like some people suggesting that /var would not be able to be on
> >> its own partition at some point in the future). Just before
> >> everyone start to wildy conjecture, please take a look at this:
> >>
> >> http://www.freedesktop.org/wiki/Software/systemd/separate-usr-is-broken
> >>
> >> Also, a look at this thread is maybe justified:
> >>
> >> http://thread.gmane.org/gmane.comp.sysutils.systemd.devel/1728/
> >>
> >> Both things are in the context of systemd, but it's related to the
> >> discussion at hand. I know not everybody wants to use systemd, and
> >> think Lennart and Kay are the root of all that is wrong and evil on
> >> the world, but I will recommend everyone interested in the reasons
> >> of the push for a recommended initramfs to take a look at the page
> >> in fd.org, and the thread in the systemd mailing list. Even if you
> >> don't agree with the reasoning, it is worth to take a look at it.
> >>
> >> As for me, I would say one last time my POV: Linux strives to be
> >> much more than Unix, and that means do things differently. It will
> >> always be capable of do anything that Unix does, and most of the
> >> time it will do it better. But that doesn't (necessarily) means
> >> that it will do it in the same way.
> >>
> >> And many of us don't take "but my config/setup/partition works
> >> now" as a valid argument to restrain progress.
> >>
> >> Change happens.
> >>
> >> Regards everyone.
> >
> > You say it was disinformation about /var.  Care to explain why me
> > and one other person read the same thing?  It was mentioned on
> > -dev.  I was pretty sure it was and then another person posted they
> > read the same.  So, I'm almost certain it was said at this point.
> >  Surely we can't both be wrong.

The issue is not /var, it is /var/run.
This dir can be needed early in the boot process, but cannot be mounted
before /var is mounted. The solution is /run.

$DEITY help us when people start finding needed crap in /var/lib and
other such insanities.


-- 
Alan McKinnnon
alan.mckinnon@gmail.com