[gentoo-user] Anyone switched to eudev yet?

[gentoo-user] Anyone switched to eudev yet?

[Dale]

Howdy,

I noticed eudev has hit the tree.  Has anyone used it yet?  If so, any
issues?  Did you just uninstall udev and install eudev in one step or
some other way?

I'm thinking of switching and getting rid of the init thingy but curious
as to what others may have ran into. 

Thanks much.

Dale

:-)  :-) 

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

[gentoo-user] Re: Anyone switched to eudev yet?

[Nikos Chantziaras]

On 14/12/12 14:19, Dale wrote:
> I'm thinking of switching and getting rid of the init thingy

Huh?

Re: [gentoo-user] Re: Anyone switched to eudev yet?

[Dale]

Nikos Chantziaras wrote:
> On 14/12/12 14:19, Dale wrote:
>> I'm thinking of switching and getting rid of the init thingy
>
> Huh

Right now, I have /usr on a separate partition so I would need a init
thingy to boot.  When I switch to eudev, that won't be required, from
what I have read anyway. 

I didn't want the init thingy to begin with either. 

Dale

:-)  :-) 

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

Re: [gentoo-user] Re: Anyone switched to eudev yet?

[Bruce Hill]

On Fri, Dec 14, 2012 at 07:41:45AM -0600, Dale wrote:
> 
> Right now, I have /usr on a separate partition so I would need a init
> thingy to boot.  When I switch to eudev, that won't be required, from
> what I have read anyway. 
> 
> I didn't want the init thingy to begin with either. 
> 
> Dale

Let me translate his "Mississippi English"...

define: init thingy

initrd: http://en.wikipedia.org/wiki/Initrd

My file server has /boot with / on /dev/md0 (well, see here:)

mingdao@server ~ $ egrep -v "(^#|^ *$)" /etc/fstab 
/dev/md0		/		xfs		inode64,logbsize=262144 0 1
/var/swapfile1		swap		swap		defaults		0 0
/dev/system/var		/var		xfs		defaults		0 0
/dev/system/usr		/usr		xfs		defaults		0 0
/dev/system/home	/home		xfs		defaults		0 0
/dev/storage/photos	/photos		xfs		users,rw		0 0
/dev/storage/backups	/backups	xfs		users,rw		0 0
/dev/storage/offload	/offload	ntfs		defaults		0 0
/dev/storage/peter	/peter		xfs		defaults		0 0
/dev/storage/jeremiah	/jeremiah	xfs		defaults		0 0

And no "init thingy" anywhere on this LAN. ;)
-- 
Happy Penguin Computers               >')
126 Fenco Drive                       ( \
Tupelo, MS 38801                       ^^
support@happypenguincomputers.com
662-269-2706 662-205-6424
http://happypenguincomputers.com/

Don't top-post: http://en.wikipedia.org/wiki/Top_post#Top-posting

Re: [gentoo-user] Re: Anyone switched to eudev yet?

[Dale]

Bruce Hill wrote:
> On Fri, Dec 14, 2012 at 07:41:45AM -0600, Dale wrote:
>> Right now, I have /usr on a separate partition so I would need a init
>> thingy to boot.  When I switch to eudev, that won't be required, from
>> what I have read anyway. 
>>
>> I didn't want the init thingy to begin with either. 
>>
>> Dale
> Let me translate his "Mississippi English"...
>
> define: init thingy
>
> initrd: http://en.wikipedia.org/wiki/Initrd
>
> My file server has /boot with / on /dev/md0 (well, see here:)
>
> mingdao@server ~ $ egrep -v "(^#|^ *$)" /etc/fstab 
> /dev/md0		/		xfs		inode64,logbsize=262144 0 1
> /var/swapfile1		swap		swap		defaults		0 0
> /dev/system/var		/var		xfs		defaults		0 0
> /dev/system/usr		/usr		xfs		defaults		0 0
> /dev/system/home	/home		xfs		defaults		0 0
> /dev/storage/photos	/photos		xfs		users,rw		0 0
> /dev/storage/backups	/backups	xfs		users,rw		0 0
> /dev/storage/offload	/offload	ntfs		defaults		0 0
> /dev/storage/peter	/peter		xfs		defaults		0 0
> /dev/storage/jeremiah	/jeremiah	xfs		defaults		0 0
>
> And no "init thingy" anywhere on this LAN. ;)


Pretty much yea.  I started making a init thing when they were talking
about not supporting /usr on a separate partition.  Then about a month
ago eudev was announced which means we can boot with /usr on a separate
partition and no init thingy, like it used to be.

My basic question is this, has anyone started using eudev yet?  From my
understanding it is basically udev with the files where they used to be
before they changed things.  I'm thinking about switching but wondering
what all is involved.  It appears to be as simple as unmerge udev and
emerge eudev and restart eudev.  Is it really THAT simple? 

Dale

:-)  :-) 

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

Re: [gentoo-user] Re: Anyone switched to eudev yet?

[Bruce Hill]

On Fri, Dec 14, 2012 at 08:25:08AM -0600, Dale wrote:
> 
> Pretty much yea.  I started making a init thing when they were talking
> about not supporting /usr on a separate partition.  Then about a month
> ago eudev was announced which means we can boot with /usr on a separate
> partition and no init thingy, like it used to be.
> 
> My basic question is this, has anyone started using eudev yet?  From my
> understanding it is basically udev with the files where they used to be
> before they changed things.  I'm thinking about switching but wondering
> what all is involved.  It appears to be as simple as unmerge udev and
> emerge eudev and restart eudev.  Is it really THAT simple? 
> 
> Dale

What Mark wrote you is golden. I might only add that if you put:

 >=sys-fs/udev-181

into

/etc/portage/package.mask

you will have the present stable udev from *before* those weirdos starting
messing it up, forcing systemd to take over udev. And, you won't be required
to have an initrd image. (At sys-fs/udev-171-r9 as of Fri Dec 14 09:37:06 CST
2012). And the only USE flag you *need* for that version of udev would be
rule_generator. If you don't know that you need another, you probably don't.

Bruce
-- 
Happy Penguin Computers               >')
126 Fenco Drive                       ( \
Tupelo, MS 38801                       ^^
support@happypenguincomputers.com
662-269-2706 662-205-6424
http://happypenguincomputers.com/

Don't top-post: http://en.wikipedia.org/wiki/Top_post#Top-posting

Re: [gentoo-user] Re: Anyone switched to eudev yet?

[Tanstaafl]

On 2012-12-14 10:39 AM, Bruce Hill <daddy@happypenguincomputers.com> wrote:
> What Mark wrote you is golden. I might only add that if you put:
>
>   >=sys-fs/udev-181
>
> into
>
> /etc/portage/package.mask
>
> you will have the present stable udev from*before*  those weirdos starting
> messing it up, forcing systemd to take over udev.

Hmmm...

For some reason I have masked my udev at 171...

Are you saying I can change the mask to 181 and not have to worry about 
having an unbootable system due to my /usr being on a separate partition?

Thanks

Re: [gentoo-user] Re: Anyone switched to eudev yet?

[Bruce Hill]

On Fri, Dec 14, 2012 at 11:20:05AM -0500, Tanstaafl wrote:
> On 2012-12-14 10:39 AM, Bruce Hill <daddy@happypenguincomputers.com> wrote:
> > What Mark wrote you is golden. I might only add that if you put:
> >
> >   >=sys-fs/udev-181
> >
> > into
> >
> > /etc/portage/package.mask
> >
> > you will have the present stable udev from*before*  those weirdos starting
> > messing it up, forcing systemd to take over udev.
> 
> Hmmm...
> 
> For some reason I have masked my udev at 171...
> 
> Are you saying I can change the mask to 181 and not have to worry about 
> having an unbootable system due to my /usr being on a separate partition?

The >=sys-fs/udev-181 in /etc/portage/package.mask means that any udev version
equal to or greater than udev-181 is masked from the system. Therefore, the
latest version under 181 will be used (stable or unstable depending upon
/etc/portage/package.accept_keywords). You can see versions/slots easily by:

mingdao@workstation ~ $ eshowkw sys-fs/udev
Keywords for sys-fs/udev:
          |                           | u   |  
          | a a             p     s   | n   |  
          | l m   h i m m   p s   p   | u s | r
          | p d a p a 6 i p c 3   a x | s l | e
          | h 6 r p 6 8 p p 6 9 s r 8 | e o | p
          | a 4 m a 4 k s c 4 0 h c 6 | d t | o
----------+---------------------------+-----+-------
   141-r1 | ~ ~ ~ + ~ ~ ~ ~ ~ ~ ~ ~ ~ | # 0 | gentoo
   146-r1 | ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ | #   | gentoo
   149    | ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ | #   | gentoo
   151-r4 | ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ | #   | gentoo
   164-r2 | ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ | #   | gentoo
[I]171-r9 | + + + + + + ~ + + + + + + | o   | gentoo
   195    | ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ | #   | gentoo
   196-r1 | ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ | o   | gentoo
  9999    | o o o o o o o o o o o o o | o   | gentoo
-- 
Happy Penguin Computers               >')
126 Fenco Drive                       ( \
Tupelo, MS 38801                       ^^
support@happypenguincomputers.com
662-269-2706 662-205-6424
http://happypenguincomputers.com/

Don't top-post: http://en.wikipedia.org/wiki/Top_post#Top-posting

Re: [gentoo-user] Re: Anyone switched to eudev yet?

[Tanstaafl]

Sorry, you're right, I'll go back to sleep now... ;)

I spoke without looking, and indeed my mask is set to >=181

On 2012-12-14 12:34 PM, Bruce Hill <daddy@happypenguincomputers.com> wrote:
> On Fri, Dec 14, 2012 at 11:20:05AM -0500, Tanstaafl wrote:
>> >On 2012-12-14 10:39 AM, Bruce Hill<daddy@happypenguincomputers.com>  wrote:
>>> > >What Mark wrote you is golden. I might only add that if you put:
>>> > >
>>> > >   >=sys-fs/udev-181
>>> > >
>>> > >into
>>> > >
>>> > >/etc/portage/package.mask
>>> > >
>>> > >you will have the present stable udev from*before*  those weirdos starting
>>> > >messing it up, forcing systemd to take over udev.
>> >
>> >Hmmm...
>> >
>> >For some reason I have masked my udev at 171...
>> >
>> >Are you saying I can change the mask to 181 and not have to worry about
>> >having an unbootable system due to my /usr being on a separate partition?
> The >=sys-fs/udev-181 in /etc/portage/package.mask means that any udev version
> equal to or greater than udev-181 is masked from the system.

Re: [gentoo-user] Re: Anyone switched to eudev yet?

[Alan McKinnon]

On Fri, 14 Dec 2012 15:26:25 +0200
Nikos Chantziaras <realnc@gmail.com> wrote:

> On 14/12/12 14:19, Dale wrote:
> > I'm thinking of switching and getting rid of the init thingy
> 
> Huh?

Once upon a time, not so long ago, Dale happened to try and make an
initrd. He followed the rules and the docs and it blew up in his face.
It blew up more in his face than HAL did even longer ago (and that was
pretty spectacular).

Somewhere in that thread the words "init thingy" were used in
frustration, and it's since become a meme, a disparaging reference to
initrd for those who don't like the idea of them.

Dale is getting famous at this, if ever we need someone to find the
really bad bugs in basic software, just mark it stable enough so that
Dale will use it. He will find the bugs that no-one else ever could,
it's just a knack he has.

Long live Dale.

:-)

-- 
Alan McKinnon
alan.mckinnon@gmail.com

Re: [gentoo-user] Re: Anyone switched to eudev yet?

[Mark Knecht]

On Fri, Dec 14, 2012 at 8:23 AM, Alan McKinnon <alan.mckinnon@gmail.com> wrote:
<SNIP>
>
> Long live Dale.
>


+1

Re: [gentoo-user] Re: Anyone switched to eudev yet?

[Michael Mol]

On Fri, Dec 14, 2012 at 11:23 AM, Alan McKinnon <alan.mckinnon@gmail.com> wrote:
> On Fri, 14 Dec 2012 15:26:25 +0200
> Nikos Chantziaras <realnc@gmail.com> wrote:
>
>> On 14/12/12 14:19, Dale wrote:
>> > I'm thinking of switching and getting rid of the init thingy
>>
>> Huh?
>
> Once upon a time, not so long ago, Dale happened to try and make an
> initrd. He followed the rules and the docs and it blew up in his face.
> It blew up more in his face than HAL did even longer ago (and that was
> pretty spectacular).
>
> Somewhere in that thread the words "init thingy" were used in
> frustration, and it's since become a meme, a disparaging reference to
> initrd for those who don't like the idea of them.
>
> Dale is getting famous at this, if ever we need someone to find the
> really bad bugs in basic software, just mark it stable enough so that
> Dale will use it. He will find the bugs that no-one else ever could,
> it's just a knack he has.
>
> Long live Dale.

Hear! Hear!

Dale, would you be interested in jobs doing software testing? If I see
openings, I'd be happy to forward them your way...


--
:wq

Re: [gentoo-user] Re: Anyone switched to eudev yet?

[Dale]

Michael Mol wrote:
> On Fri, Dec 14, 2012 at 11:23 AM, Alan McKinnon <alan.mckinnon@gmail.com> wrote:
>> On Fri, 14 Dec 2012 15:26:25 +0200
>> Nikos Chantziaras <realnc@gmail.com> wrote:
>>
>>> On 14/12/12 14:19, Dale wrote:
>>>> I'm thinking of switching and getting rid of the init thingy
>>> Huh?
>> Once upon a time, not so long ago, Dale happened to try and make an
>> initrd. He followed the rules and the docs and it blew up in his face.
>> It blew up more in his face than HAL did even longer ago (and that was
>> pretty spectacular).
>>
>> Somewhere in that thread the words "init thingy" were used in
>> frustration, and it's since become a meme, a disparaging reference to
>> initrd for those who don't like the idea of them.
>>
>> Dale is getting famous at this, if ever we need someone to find the
>> really bad bugs in basic software, just mark it stable enough so that
>> Dale will use it. He will find the bugs that no-one else ever could,
>> it's just a knack he has.
>>
>> Long live Dale.
> Hear! Hear!
>
> Dale, would you be interested in jobs doing software testing? If I see
> openings, I'd be happy to forward them your way...
>
>
> --
> :wq
>
>


I thought I did that already.  ROFL

Dale

:-)  :-) 

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

Re: [gentoo-user] Re: Anyone switched to eudev yet?

[Dale]

Alan McKinnon wrote:
> On Fri, 14 Dec 2012 15:26:25 +0200
> Nikos Chantziaras <realnc@gmail.com> wrote:
>
>> On 14/12/12 14:19, Dale wrote:
>>> I'm thinking of switching and getting rid of the init thingy
>> Huh?
> Once upon a time, not so long ago, Dale happened to try and make an
> initrd. He followed the rules and the docs and it blew up in his face.
> It blew up more in his face than HAL did even longer ago (and that was
> pretty spectacular).
>
> Somewhere in that thread the words "init thingy" were used in
> frustration, and it's since become a meme, a disparaging reference to
> initrd for those who don't like the idea of them.
>
> Dale is getting famous at this, if ever we need someone to find the
> really bad bugs in basic software, just mark it stable enough so that
> Dale will use it. He will find the bugs that no-one else ever could,
> it's just a knack he has.
>
> Long live Dale.
>
> :-)
>


You would mention hal wouldn't you?  :-@  :-@ 

I have the flu, nasty one at that, and I really don't need to add hal to
my list right now.  That said, the Doctor called and the blood tests
said I was healthy as a horse, other than being sick as a dog.  :/  
Sort of like software, supposed to work great out of the box but usually
doesn't.  Imagine me on windoze.  O_O 

Dale

:-)  :-) 

P. S.  I'm not sure about the living part yet.  It's a theory that is
yet to be proven. 

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

Re: [gentoo-user] Re: Anyone switched to eudev yet?

[Bruce Hill]

On Fri, Dec 14, 2012 at 10:52:12AM -0600, Dale wrote:
> 
> I have the flu, nasty one at that, and I really don't need to add hal to
> my list right now.  That said, the Doctor called and the blood tests
> said I was healthy as a horse, other than being sick as a dog.  :/  
> Sort of like software, supposed to work great out of the box but usually
> doesn't.  Imagine me on windoze.  O_O 
> 
> Dale
> 
> :-)  :-) 
> 
> P. S.  I'm not sure about the living part yet.  It's a theory that is
> yet to be proven. 

Maybe I can give you a "run for your money". I hit most corner cases head on.
See this bug https://bugs.gentoo.org/show_bug.cgi?id=447184

Today we have major things going on, for which I need my printer to print. And
yesterday it stopped printing. It will crash FF when Print is selected, and
won't print from Inkscape, LibreOffice, or Evince. There were already problems
but now it just rolled over and died.

And, no, it's not the printer ... workstation CAN print with this command:
lp -d HP_Officejet_Pro_8500_A910 -o scaling=75 Happy-Penguin-Gymnastics/offers/Drop-and-Shop-text

and baruch can print to the printer (192.168.100.10:9100)

Hill's Law: it works best when you don't need it
-- 
Happy Penguin Computers               >')
126 Fenco Drive                       ( \
Tupelo, MS 38801                       ^^
support@happypenguincomputers.com
662-269-2706 662-205-6424
http://happypenguincomputers.com/

Don't top-post: http://en.wikipedia.org/wiki/Top_post#Top-posting

Re: [gentoo-user] Re: Anyone switched to eudev yet?

[Dale]

Bruce Hill wrote:
> On Fri, Dec 14, 2012 at 10:52:12AM -0600, Dale wrote:
>> I have the flu, nasty one at that, and I really don't need to add hal to
>> my list right now.  That said, the Doctor called and the blood tests
>> said I was healthy as a horse, other than being sick as a dog.  :/  
>> Sort of like software, supposed to work great out of the box but usually
>> doesn't.  Imagine me on windoze.  O_O 
>>
>> Dale
>>
>> :-)  :-) 
>>
>> P. S.  I'm not sure about the living part yet.  It's a theory that is
>> yet to be proven. 
> Maybe I can give you a "run for your money". I hit most corner cases head on.
> See this bug https://bugs.gentoo.org/show_bug.cgi?id=447184
>
> Today we have major things going on, for which I need my printer to print. And
> yesterday it stopped printing. It will crash FF when Print is selected, and
> won't print from Inkscape, LibreOffice, or Evince. There were already problems
> but now it just rolled over and died.
>
> And, no, it's not the printer ... workstation CAN print with this command:
> lp -d HP_Officejet_Pro_8500_A910 -o scaling=75 Happy-Penguin-Gymnastics/offers/Drop-and-Shop-text
>
> and baruch can print to the printer (192.168.100.10:9100)
>
> Hill's Law: it works best when you don't need it


I just depend on Murphy's law.  It always works for me.  lol 

Dale

:-)  :-) 

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

Re: [gentoo-user] Anyone switched to eudev yet?

[Mark Knecht]

On Fri, Dec 14, 2012 at 4:19 AM, Dale <rdalek1967@gmail.com> wrote:
> Howdy,
>
> I noticed eudev has hit the tree.  Has anyone used it yet?  If so, any
> issues?  Did you just uninstall udev and install eudev in one step or
> some other way?
>
> I'm thinking of switching and getting rid of the init thingy but curious
> as to what others may have ran into.
>
> Thanks much.
>
> Dale


Even if someone has, and clearly _someone_ out there has or it likely
wouldn't even be visible yet, but even if 10 or 20 people have, and
even if all of their results are fine because they are high skill set
folks, why would that change how you are running your machines?

I suspect this is about your (and my) dislike for dealing with initrd
on a box at home. Gentoo doesn't make it at all easy so we're in that
together. However so what if someone has used it? Let it get used for
6 months. Let it go stable. Why bother with a piece of software that
won't really improve your life now that you do have your 'init
thingy'?

Just my view,
Mark

Re: [gentoo-user] Anyone switched to eudev yet?

[Dale]

Mark Knecht wrote:
> On Fri, Dec 14, 2012 at 4:19 AM, Dale <rdalek1967@gmail.com> wrote:
>> Howdy,
>>
>> I noticed eudev has hit the tree.  Has anyone used it yet?  If so, any
>> issues?  Did you just uninstall udev and install eudev in one step or
>> some other way?
>>
>> I'm thinking of switching and getting rid of the init thingy but curious
>> as to what others may have ran into.
>>
>> Thanks much.
>>
>> Dale
>
> Even if someone has, and clearly _someone_ out there has or it likely
> wouldn't even be visible yet, but even if 10 or 20 people have, and
> even if all of their results are fine because they are high skill set
> folks, why would that change how you are running your machines?
>
> I suspect this is about your (and my) dislike for dealing with initrd
> on a box at home. Gentoo doesn't make it at all easy so we're in that
> together. However so what if someone has used it? Let it get used for
> 6 months. Let it go stable. Why bother with a piece of software that
> won't really improve your life now that you do have your 'init
> thingy'?
>
> Just my view,
> Mark
>
>


Well, it appears that one version is stable:

root@fireball / # equery list -p eudev
 * Searching for eudev ...
[-P-] [  ] sys-fs/eudev-0:0
[-P-] [ ~] sys-fs/eudev-1_beta1-r1:0
[-P-] [ -] sys-fs/eudev-9999:0
root@fireball / #

The first one is not keyworded or masked. 

You are right, I don't like the init fix because when I used Mandrake,
it caused me all sorts of problems.  That and the upgrade process for
Mandrake is the reason I switched to Gentoo.  If eudev is ready, then so
am I. 

Dale

:-)  :-) 

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

Re: [gentoo-user] Anyone switched to eudev yet?

[Mark Knecht]

On Fri, Dec 14, 2012 at 7:48 AM, Dale <rdalek1967@gmail.com> wrote:
> Mark Knecht wrote:
>> On Fri, Dec 14, 2012 at 4:19 AM, Dale <rdalek1967@gmail.com> wrote:
>>> Howdy,
>>>
>>> I noticed eudev has hit the tree.  Has anyone used it yet?  If so, any
>>> issues?  Did you just uninstall udev and install eudev in one step or
>>> some other way?
>>>
>>> I'm thinking of switching and getting rid of the init thingy but curious
>>> as to what others may have ran into.
>>>
>>> Thanks much.
>>>
>>> Dale
>>
>> Even if someone has, and clearly _someone_ out there has or it likely
>> wouldn't even be visible yet, but even if 10 or 20 people have, and
>> even if all of their results are fine because they are high skill set
>> folks, why would that change how you are running your machines?
>>
>> I suspect this is about your (and my) dislike for dealing with initrd
>> on a box at home. Gentoo doesn't make it at all easy so we're in that
>> together. However so what if someone has used it? Let it get used for
>> 6 months. Let it go stable. Why bother with a piece of software that
>> won't really improve your life now that you do have your 'init
>> thingy'?
>>
>> Just my view,
>> Mark

> Well, it appears that one version is stable:
>
> root@fireball / # equery list -p eudev
>  * Searching for eudev ...
> [-P-] [  ] sys-fs/eudev-0:0
> [-P-] [ ~] sys-fs/eudev-1_beta1-r1:0
> [-P-] [ -] sys-fs/eudev-9999:0
> root@fireball / #
>
> The first one is not keyworded or masked.
>
> You are right, I don't like the init fix because when I used Mandrake,
> it caused me all sorts of problems.  That and the upgrade process for
> Mandrake is the reason I switched to Gentoo.  If eudev is ready, then so
> am I.
>
> Dale

Well, OK, so if you want to call version 0.0 stable then I guess that
meets the rules of portage anyway. However version '0.0' doesn't sound
like anything that's seen the light of day, been used by lots of
people and proven robust and stable. At least to me it sounds like a
place holder...

This is just my view, but it goes something like this:

1) Unless someone tells me why a really new package helps me then I go
slow, most especially if it could have a large impact like a new
version of udev might.

2) Somewhere in the install guide, or elsewhere, I don't remember, it
says something like 'don't expect ~packages to work correctly. We do
what we can to check them but you should expect things to break'. And
then most importantly, again from memory and paraphrased 'If you don't
know how to fix things when they do break don't use ~packages'. I let
these few sentences guide a lot of my Gentoo maintenance here at home.
I mask packages (good info from Bruce about which to mask) and wait
for the heavy lifters to shake things out a bit before I update things
that might take more than 5 minutes to fix.

Again, all my systems are stable with ~amd64 only when required to get
an app, but that's just me.

Good luck with whatever path you take.

Cheers,
Mark

Re: [gentoo-user] Anyone switched to eudev yet?

[Dale]

Mark Knecht wrote:
> On Fri, Dec 14, 2012 at 7:48 AM, Dale <rdalek1967@gmail.com> wrote:
>> Mark Knecht wrote:
>>> On Fri, Dec 14, 2012 at 4:19 AM, Dale <rdalek1967@gmail.com> wrote:
>>>> Howdy,
>>>>
>>>> I noticed eudev has hit the tree.  Has anyone used it yet?  If so, any
>>>> issues?  Did you just uninstall udev and install eudev in one step or
>>>> some other way?
>>>>
>>>> I'm thinking of switching and getting rid of the init thingy but curious
>>>> as to what others may have ran into.
>>>>
>>>> Thanks much.
>>>>
>>>> Dale
>>> Even if someone has, and clearly _someone_ out there has or it likely
>>> wouldn't even be visible yet, but even if 10 or 20 people have, and
>>> even if all of their results are fine because they are high skill set
>>> folks, why would that change how you are running your machines?
>>>
>>> I suspect this is about your (and my) dislike for dealing with initrd
>>> on a box at home. Gentoo doesn't make it at all easy so we're in that
>>> together. However so what if someone has used it? Let it get used for
>>> 6 months. Let it go stable. Why bother with a piece of software that
>>> won't really improve your life now that you do have your 'init
>>> thingy'?
>>>
>>> Just my view,
>>> Mark
>> Well, it appears that one version is stable:
>>
>> root@fireball / # equery list -p eudev
>>  * Searching for eudev ...
>> [-P-] [  ] sys-fs/eudev-0:0
>> [-P-] [ ~] sys-fs/eudev-1_beta1-r1:0
>> [-P-] [ -] sys-fs/eudev-9999:0
>> root@fireball / #
>>
>> The first one is not keyworded or masked.
>>
>> You are right, I don't like the init fix because when I used Mandrake,
>> it caused me all sorts of problems.  That and the upgrade process for
>> Mandrake is the reason I switched to Gentoo.  If eudev is ready, then so
>> am I.
>>
>> Dale
> Well, OK, so if you want to call version 0.0 stable then I guess that
> meets the rules of portage anyway. However version '0.0' doesn't sound
> like anything that's seen the light of day, been used by lots of
> people and proven robust and stable. At least to me it sounds like a
> place holder...
>
> This is just my view, but it goes something like this:
>
> 1) Unless someone tells me why a really new package helps me then I go
> slow, most especially if it could have a large impact like a new
> version of udev might.
>
> 2) Somewhere in the install guide, or elsewhere, I don't remember, it
> says something like 'don't expect ~packages to work correctly. We do
> what we can to check them but you should expect things to break'. And
> then most importantly, again from memory and paraphrased 'If you don't
> know how to fix things when they do break don't use ~packages'. I let
> these few sentences guide a lot of my Gentoo maintenance here at home.
> I mask packages (good info from Bruce about which to mask) and wait
> for the heavy lifters to shake things out a bit before I update things
> that might take more than 5 minutes to fix.
>
> Again, all my systems are stable with ~amd64 only when required to get
> an app, but that's just me.
>
> Good luck with whatever path you take.
>
> Cheers,
> Mark
>
>


That's all true, hence my question.  I'm not sure I want to use the very
first version so I thought it worth asking first.  Since it is a fork,
one could think it would be safe enough but then again, it is the very
first one.  It is stable according to that but is it really? 

That is why I asked.  It seems no one has used it yet tho since no one
has fessed up to installing it, other than testers and such I guess.  ;-)

Guess I'll wait a bit and see what else changes.  Current udev is
working for the moment at least.  I do plan to abandon udev as soon as I
think it is safe tho. 

Dale

:-)  :-) 

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

Re: [gentoo-user] Anyone switched to eudev yet?

[Mark Knecht]

On Fri, Dec 14, 2012 at 8:29 AM, Dale <rdalek1967@gmail.com> wrote:
>
> That's all true, hence my question.  I'm not sure I want to use the very
> first version so I thought it worth asking first.  Since it is a fork,
> one could think it would be safe enough but then again, it is the very
> first one.  It is stable according to that but is it really?
>

But portage isn't telling you to use it. It's a decision you're taking
in reaction to how your machine is configured, correct? I think the
reason I'm not understanding even asking the question is that portage
hasn't _told_ you that you need to use it. I may well be wrong but
aren't you a stable user? Or are you running bleeding edge?

It's likely to be 6 months and probably far longer before there's any
push from portage to tell us switch to eudev, if ever.

I guess the other question that's lurking here for me is why do you
have /usr on a separate partition? What's the usage model that drives
a person to do that? The most I've ever done is move /usr/portage and
/usr/src to other places. My /usr never has all that much in it beyond
those two directories, along with maybe /usr/share. Would it not be
easier for you in the long run to move /usr back to / and not have to
deal with this question at all?

Just my 2 questioning cents,
Mark

Re: [gentoo-user] Anyone switched to eudev yet?

[Dale]

Mark Knecht wrote:
> On Fri, Dec 14, 2012 at 8:29 AM, Dale <rdalek1967@gmail.com> wrote:
>> That's all true, hence my question.  I'm not sure I want to use the very
>> first version so I thought it worth asking first.  Since it is a fork,
>> one could think it would be safe enough but then again, it is the very
>> first one.  It is stable according to that but is it really?
>>
> But portage isn't telling you to use it. It's a decision you're taking
> in reaction to how your machine is configured, correct? I think the
> reason I'm not understanding even asking the question is that portage
> hasn't _told_ you that you need to use it. I may well be wrong but
> aren't you a stable user? Or are you running bleeding edge?
>
> It's likely to be 6 months and probably far longer before there's any
> push from portage to tell us switch to eudev, if ever.
>
> I guess the other question that's lurking here for me is why do you
> have /usr on a separate partition? What's the usage model that drives
> a person to do that? The most I've ever done is move /usr/portage and
> /usr/src to other places. My /usr never has all that much in it beyond
> those two directories, along with maybe /usr/share. Would it not be
> easier for you in the long run to move /usr back to / and not have to
> deal with this question at all?
>
> Just my 2 questioning cents,
> Mark
>
>

Portage doesn't tell me to use a lot of things but I do because it makes
things easier for me.  I don't always wait for portage to tell me
something is about to break before I try to switch.  It's just like the
init thingy.  Right now, I'm not required to use it but I do because
when the newer udev comes along, I would then be forced too.  I didn't
want to wait until the last minute then have to scramble around to get
my ducks in a row.   Sort of learning to prepare better to avoid problems. 

I have / and /boot on regular partitions but everything else is on LVM
including /usr.  I got tired of having to move things around for space
issues.  So, I switched to LVM but not to the point where I needed a
init thingy.  THAT I wanted to avoid and was until udev threw a wrench
into the works. 

As long as we stick with the current udev I should be fine.  If they
start moving up to the newer ones tho, I'll be looking into what to do. 
I'm hoping to switch to eudev and that cure my issues. 

Dale

:-)  :-) 

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

Re: [gentoo-user] Anyone switched to eudev yet?

[Kevin Chadwick]

On Fri, 14 Dec 2012 08:53:35 -0800
Mark Knecht <markknecht@gmail.com> wrote:

> I guess the other question that's lurking here for me is why do you
> have /usr on a separate partition? What's the usage model that drives
> a person to do that? The most I've ever done is move /usr/portage and
> /usr/src to other places. My /usr never has all that much in it beyond
> those two directories, along with maybe /usr/share. Would it not be
> easier for you in the long run to move /usr back to / and not have to
> deal with this question at all?

It should be moving in the other direction for stability reasons and
busybox is no full answer.

On OpenBSD which has the benefit of userland being part of it. All the
critical single user binaries are in root and built statically as much
as possible, maximising system reliability no matter the custom
requirements or packages.

The way I have it on OpenBSD

/ ro

100 megabytes and I never need to fsck and can reliably fix all
but the most likely problem and snapshot quickly, though there is no
need as the kernel is rock solid.

/usr ro,nodev
~600 megabytes that I almost never need to fsck even when I pull the
plug

/usr/local ro,nodev,nosuid
All installed packages go here and I can give users the ability to only
mount writeable this location. There are other plusses I won't bother
going into.


All the BSDs and debian stable (old and initramfs) still get's this
right with debian suggesting a seperate /usr during install in
compliance with the filesystem hiearchical standard and the upcoming
draft/version 3, which states the real technical and uptime benefits of
a seperate /usr.

https://wiki.linuxfoundation.org/en/FHS

Unfortunately stability and security often only get's noticed and
chosen over other function when it's completely obliterated and has
stopped functioning alltogether.

When hard worked (including rusty russel) documents like this get
ignored when freedesktop.org is given so much credence even though
freedesktop.org is actually simply stating opinion without having
debate/comments on it's site and in contrast a combined root/usr has no
technical benefit not addressed elsewhere (grub etc..) and when the
issues in userland are far from insurmountable it is quite worrying and
I am grateful to those who have stood up against this and the trend
of added complexity into pid1/systemd and early boot.

What is also worrying is the recent trends of the kits, udisks
dropping features for months to get multiseat and dbus getting
everywhere like Windows and RPC.

I can take spread out documentation compared to OpenBSD but some of
these issues are quite rediculous, I just wish OpenBSD had more devs for
KMS and stable updates as it is perhaps due to being a smaller project
involving both core userland and kernel and with hard fast goals, far
better managed.

Re: [gentoo-user] Anyone switched to eudev yet?

[Volker Armin Hemmann]

Am Freitag, 14. Dezember 2012, 21:34:54 schrieb Kevin Chadwick:
> On Fri, 14 Dec 2012 08:53:35 -0800
> 
> Mark Knecht <markknecht@gmail.com> wrote:
> > I guess the other question that's lurking here for me is why do you
> > have /usr on a separate partition? What's the usage model that drives
> > a person to do that? The most I've ever done is move /usr/portage and
> > /usr/src to other places. My /usr never has all that much in it beyond
> > those two directories, along with maybe /usr/share. Would it not be
> > easier for you in the long run to move /usr back to / and not have to
> > deal with this question at all?
> 
> It should be moving in the other direction for stability reasons and
> busybox is no full answer.
> 
> On OpenBSD which has the benefit of userland being part of it. All the
> critical single user binaries are in root and built statically as much
> as possible, maximising system reliability no matter the custom
> requirements or packages.

until a flaw is found in one of the libs used and all those statically linked 
binaries are in danger.  Well done!

-- 
#163933

Re: [gentoo-user] Anyone switched to eudev yet?

[Kevin Chadwick]

On Sat, 15 Dec 2012 11:18:25 +0100
Volker Armin Hemmann <volkerarmin@googlemail.com> wrote:

> > It should be moving in the other direction for stability reasons and
> > busybox is no full answer.
> > 
> > On OpenBSD which has the benefit of userland being part of it. All
> > the critical single user binaries are in root and built statically
> > as much as possible, maximising system reliability no matter the
> > custom requirements or packages.  
> 
> until a flaw is found in one of the libs used and all those
> statically linked binaries are in danger.  Well done!

How unlikely and is why you have test systems. Other problem this
protects against are far less predictable. There is even a distro that
attempts to statically build everything. It's worth reading
that distros arguments for doing so in any case.

Ch3.1 of fhs-2.3.

_______________________________________________________________________
Rationale
The primary concern used to balance these considerations, which favor
placing many things on the root filesystem, is the goal of keeping root
as small as reasonably possible. For several reasons, it is desirable
to keep the root filesystem small:

....
Disk errors that corrupt data on the root filesystem are a greater
problem than errors on any other partition. A small root filesystem is
less prone to corruption as the result of a system crash.

________________________________________________________________________

Re: [gentoo-user] Anyone switched to eudev yet?

[Volker Armin Hemmann]

Am Samstag, 15. Dezember 2012, 17:43:05 schrieb Kevin Chadwick:
> On Sat, 15 Dec 2012 11:18:25 +0100
> 
> Volker Armin Hemmann <volkerarmin@googlemail.com> wrote:
> > > It should be moving in the other direction for stability reasons and
> > > busybox is no full answer.
> > > 
> > > On OpenBSD which has the benefit of userland being part of it. All
> > > the critical single user binaries are in root and built statically
> > > as much as possible, maximising system reliability no matter the
> > > custom requirements or packages.
> > 
> > until a flaw is found in one of the libs used and all those
> > statically linked binaries are in danger.  Well done!
> 
> How unlikely and is why you have test systems. 

wow, so how many vulnerabilities have you found with your test systems? Just a 
question. And how do they help mitigate the problem? Really? Having lots of 
test systems help you in which way if there is a root exploit in some lib that 
was wisely statically linked into half of your installed apps? Please explain. 
Without bullshit this time. Thank you very much.

At least the 'no security hole in the default install' bullshit is gone. Easy 
to have a 'secure' default installation if it only contains ed, tar, cp, cat 
and a shell. 

-- 
#163933

[gentoo-user] Re: Anyone switched to eudev yet?

[Nikos Chantziaras]

On 15/12/12 12:18, Volker Armin Hemmann wrote:
> Am Freitag, 14. Dezember 2012, 21:34:54 schrieb Kevin Chadwick:
>> On Fri, 14 Dec 2012 08:53:35 -0800
>>
>> Mark Knecht <markknecht@gmail.com> wrote:
>>> I guess the other question that's lurking here for me is why do you
>>> have /usr on a separate partition? What's the usage model that drives
>>> a person to do that? The most I've ever done is move /usr/portage and
>>> /usr/src to other places. My /usr never has all that much in it beyond
>>> those two directories, along with maybe /usr/share. Would it not be
>>> easier for you in the long run to move /usr back to / and not have to
>>> deal with this question at all?
>>
>> It should be moving in the other direction for stability reasons and
>> busybox is no full answer.
>>
>> On OpenBSD which has the benefit of userland being part of it. All the
>> critical single user binaries are in root and built statically as much
>> as possible, maximising system reliability no matter the custom
>> requirements or packages.
>
> until a flaw is found in one of the libs used and all those statically linked
> binaries are in danger.  Well done!

I don't see why this would only affect statically linked executables. 
If a bug is found in a library, all dynamically linked executables are 
affected as well.  When the BSD packagers put out an update for the 
library, they'll also put updates for the static binaries that use it.

I don't see any security issue here.

[gentoo-user] Re: Anyone switched to eudev yet?

[Nuno J. Silva]

On 2012-12-16, Nikos Chantziaras wrote:

> On 15/12/12 12:18, Volker Armin Hemmann wrote:
>> Am Freitag, 14. Dezember 2012, 21:34:54 schrieb Kevin Chadwick:
>>
>>> On OpenBSD which has the benefit of userland being part of it. All the
>>> critical single user binaries are in root and built statically as much
>>> as possible, maximising system reliability no matter the custom
>>> requirements or packages.
>>
>> until a flaw is found in one of the libs used and all those statically linked
>> binaries are in danger.  Well done!
>
> I don't see why this would only affect statically linked
> executables. If a bug is found in a library, all dynamically linked
> executables are affected as well.  When the BSD packagers put out an
> update for the library, they'll also put updates for the static
> binaries that use it.
>
> I don't see any security issue here.

Even more than that, if a flaw is found, no matter if those are
statically or dinamically linked, the flaw exists both ways, and can be
exploited in both scenarios. About replacing, you can just replace all
those binaries like you would replace the dynamically linkable one. But
you'd have to consider that the flaw may have been exploited in both
scenarios.

-- 
Nuno Silva (aka njsg)
http://njsg.sdf-eu.org/

Re: [gentoo-user] Re: Anyone switched to eudev yet?

[Volker Armin Hemmann]

Am Sonntag, 16. Dezember 2012, 23:19:46 schrieb Nikos Chantziaras:
> On 15/12/12 12:18, Volker Armin Hemmann wrote:
> > Am Freitag, 14. Dezember 2012, 21:34:54 schrieb Kevin Chadwick:
> >> On Fri, 14 Dec 2012 08:53:35 -0800
> >> 
> >> Mark Knecht <markknecht@gmail.com> wrote:
> >>> I guess the other question that's lurking here for me is why do you
> >>> have /usr on a separate partition? What's the usage model that drives
> >>> a person to do that? The most I've ever done is move /usr/portage and
> >>> /usr/src to other places. My /usr never has all that much in it beyond
> >>> those two directories, along with maybe /usr/share. Would it not be
> >>> easier for you in the long run to move /usr back to / and not have to
> >>> deal with this question at all?
> >> 
> >> It should be moving in the other direction for stability reasons and
> >> busybox is no full answer.
> >> 
> >> On OpenBSD which has the benefit of userland being part of it. All the
> >> critical single user binaries are in root and built statically as much
> >> as possible, maximising system reliability no matter the custom
> >> requirements or packages.
> > 
> > until a flaw is found in one of the libs used and all those statically
> > linked binaries are in danger.  Well done!
> 
> I don't see why this would only affect statically linked executables.
> If a bug is found in a library, all dynamically linked executables are
> affected as well.  When the BSD packagers put out an update for the
> library, they'll also put updates for the static binaries that use it.
> 
> I don't see any security issue here.

with dynamically linked libs you can change just the lib, you can even just 
use some LD_PRELOAD workaround. 

As you said yourself - with statically linked libs you have to replace half of 
your system.. and until the binaries are ready for distribution you can't even 
work around it.

-- 
#163933

[gentoo-user] Re: Anyone switched to eudev yet?

[Nikos Chantziaras]

On 17/12/12 00:14, Volker Armin Hemmann wrote:
> Am Sonntag, 16. Dezember 2012, 23:19:46 schrieb Nikos Chantziaras:
>> On 15/12/12 12:18, Volker Armin Hemmann wrote:
>>> Am Freitag, 14. Dezember 2012, 21:34:54 schrieb Kevin Chadwick:
>>>> On Fri, 14 Dec 2012 08:53:35 -0800
>>>>
>>>> Mark Knecht <markknecht@gmail.com> wrote:
>>>>> I guess the other question that's lurking here for me is why do you
>>>>> have /usr on a separate partition? [...]
>>>>
>>>> It should be moving in the other direction for stability reasons and
>>>> busybox is no full answer.
>>>>
>>>> On OpenBSD which has the benefit of userland being part of it. All the
>>>> critical single user binaries are in root and built statically as much
>>>> as possible, maximising system reliability no matter the custom
>>>> requirements or packages.
>>>
>>> until a flaw is found in one of the libs used and all those statically
>>> linked binaries are in danger.  Well done!
>>
>> I don't see why this would only affect statically linked executables.
>> If a bug is found in a library, all dynamically linked executables are
>> affected as well.  When the BSD packagers put out an update for the
>> library, they'll also put updates for the static binaries that use it.
>>
>> I don't see any security issue here.
>
> with dynamically linked libs you can change just the lib, you can even just
> use some LD_PRELOAD workaround.
>
> As you said yourself - with statically linked libs you have to replace half of
> your system.. and until the binaries are ready for distribution you can't even
> work around it.

Or you wait for the update by the vendor of your OS, which is what 
people do.  Also, the few critical system binaries that are required to 
just get a shell and fix the system, are not "half of your system."

[gentoo-user] Re: Anyone switched to eudev yet?

[Nuno J. Silva]

On 2012-12-14, Mark Knecht wrote:

> I guess the other question that's lurking here for me is why do you
> have /usr on a separate partition? What's the usage model that drives
> a person to do that? The most I've ever done is move /usr/portage and
> /usr/src to other places. My /usr never has all that much in it beyond
> those two directories, along with maybe /usr/share. Would it not be
> easier for you in the long run to move /usr back to / and not have to
> deal with this question at all?

I may be wrong in this one, but the idea I have is that your regular
applications (so, most of them) all lie under /usr/ -- /lib /bin and
others are for essential system tools.

-- 
Nuno Silva (aka njsg)
http://njsg.sdf-eu.org/

Re: [gentoo-user] Re: Anyone switched to eudev yet?

[Alan McKinnon]

On Sat, 15 Dec 2012 10:16:05 +0200
nunojsilva@ist.utl.pt (Nuno J. Silva) wrote:

> On 2012-12-14, Mark Knecht wrote:
> 
> > I guess the other question that's lurking here for me is why do you
> > have /usr on a separate partition? What's the usage model that
> > drives a person to do that? The most I've ever done is
> > move /usr/portage and /usr/src to other places. My /usr never has
> > all that much in it beyond those two directories, along with
> > maybe /usr/share. Would it not be easier for you in the long run to
> > move /usr back to / and not have to deal with this question at all?
> 
> I may be wrong in this one, but the idea I have is that your regular
> applications (so, most of them) all lie under /usr/ -- /lib /bin and
> others are for essential system tools.
> 

That was the original reason for having / and /usr separate, and it
dates back to the early 70s. The other reason that stems from that time
period is the size of disks we had back then - they were tiny and often
a minimal / was all that could really fit on the primary system drive.

Gradually over time this setup became the norm and people started to
depend on it, and more importantly, started to believe it was important
to retain it. It's their right to believe that. 

Recently I decided to measure if I still needed a separate /usr (I was
a long time advocate of retaining it). I'm in the lucky position of
having ~200 Linux machines, all distinctly different, at my disposal,
so I trawled through memory and incident logs looking for cases where a
separate /usr was crucial to recovery after any form of error. To my
surprise, I found none at all and those logs go back 5 years.

So I got to change my mind (not something I do very often I admit) and
concluded that separate base and user systems (/ and /usr) was no
longer something I needed to do - the "system" - disks, hardware and
the software on the disks - was very reliable, and what I really needed
was ability to boot from USB rescue disks. I did find, not
unsurprisingly, that I also really needed /usr/local on a separate
partition but that's because of how we install our in-house software
here, plus our backup policies.

It also goes without saying that these days we
need /home, /var, /var/log and /tmp to all be on their own filesystem,
and we need that more than ever.

I thought I should just toss that in the ring for people who are
undecided where they stand on the debate of separate / vs /usr. It's
what I found on our production, dev and staging servers, plus a whole
lot of people's personal workstations (sysadmins and devs). The
environment is a large corporate ISP that defies categorization, we
almost have at least one of every imaginable use-case for running on
Linux except something in the Top 100 SuperComputer list. I reckon it's
about as representative as I'm ever gonna see.

People are free to draw their own conclusions as always, and real data
is valuable in arriving at those conclusions. YMMV.


-- 
Alan McKinnon
alan.mckinnon@gmail.com

Re: [gentoo-user] Re: Anyone switched to eudev yet?

[Bruce Hill]

On Sun, Dec 16, 2012 at 05:10:43PM +0200, Alan McKinnon wrote:
> 
> That was the original reason for having / and /usr separate, and it
> dates back to the early 70s. The other reason that stems from that time
> period is the size of disks we had back then - they were tiny and often
> a minimal / was all that could really fit on the primary system drive.
> 
> Gradually over time this setup became the norm and people started to
> depend on it, and more importantly, started to believe it was important
> to retain it. It's their right to believe that. 
> 
> Recently I decided to measure if I still needed a separate /usr (I was
> a long time advocate of retaining it). I'm in the lucky position of
> having ~200 Linux machines, all distinctly different, at my disposal,
> so I trawled through memory and incident logs looking for cases where a
> separate /usr was crucial to recovery after any form of error. To my
> surprise, I found none at all and those logs go back 5 years.
> 
> So I got to change my mind (not something I do very often I admit) and
> concluded that separate base and user systems (/ and /usr) was no
> longer something I needed to do - the "system" - disks, hardware and
> the software on the disks - was very reliable, and what I really needed
> was ability to boot from USB rescue disks. I did find, not
> unsurprisingly, that I also really needed /usr/local on a separate
> partition but that's because of how we install our in-house software
> here, plus our backup policies.
> 
> It also goes without saying that these days we
> need /home, /var, /var/log and /tmp to all be on their own filesystem,
> and we need that more than ever.
> 
> I thought I should just toss that in the ring for people who are
> undecided where they stand on the debate of separate / vs /usr. It's
> what I found on our production, dev and staging servers, plus a whole
> lot of people's personal workstations (sysadmins and devs). The
> environment is a large corporate ISP that defies categorization, we
> almost have at least one of every imaginable use-case for running on
> Linux except something in the Top 100 SuperComputer list. I reckon it's
> about as representative as I'm ever gonna see.
> 
> People are free to draw their own conclusions as always, and real data
> is valuable in arriving at those conclusions. YMMV.

Thanks for sharing your experience, and not just your emotions. One of my
favorite quotes is, "A man with an experience is not subject to a man with an
argument."
-- 
Happy Penguin Computers               >')
126 Fenco Drive                       ( \
Tupelo, MS 38801                       ^^
support@happypenguincomputers.com
662-269-2706 662-205-6424
http://happypenguincomputers.com/

Don't top-post: http://en.wikipedia.org/wiki/Top_post#Top-posting

[gentoo-user] Re: Anyone switched to eudev yet?

[Nuno J. Silva]

On 2012-12-16, Bruce Hill wrote:

> On Sun, Dec 16, 2012 at 05:10:43PM +0200, Alan McKinnon wrote:
>> 
>> That was the original reason for having / and /usr separate, and it
>> dates back to the early 70s. The other reason that stems from that time
>> period is the size of disks we had back then - they were tiny and often
>> a minimal / was all that could really fit on the primary system drive.
>> 
>> Gradually over time this setup became the norm and people started to
>> depend on it, and more importantly, started to believe it was important
>> to retain it. It's their right to believe that. 
>> 
>> Recently I decided to measure if I still needed a separate /usr (I was
>> a long time advocate of retaining it). I'm in the lucky position of
>> having ~200 Linux machines, all distinctly different, at my disposal,
>> so I trawled through memory and incident logs looking for cases where a
>> separate /usr was crucial to recovery after any form of error. To my
>> surprise, I found none at all and those logs go back 5 years.
>> 
>> So I got to change my mind (not something I do very often I admit) and
>> concluded that separate base and user systems (/ and /usr) was no
>> longer something I needed to do - the "system" - disks, hardware and
>> the software on the disks - was very reliable, and what I really needed
>> was ability to boot from USB rescue disks. I did find, not
>> unsurprisingly, that I also really needed /usr/local on a separate
>> partition but that's because of how we install our in-house software
>> here, plus our backup policies.
>> 
>> It also goes without saying that these days we
>> need /home, /var, /var/log and /tmp to all be on their own filesystem,
>> and we need that more than ever.
>> 
>> I thought I should just toss that in the ring for people who are
>> undecided where they stand on the debate of separate / vs /usr. It's
>> what I found on our production, dev and staging servers, plus a whole
>> lot of people's personal workstations (sysadmins and devs). The
>> environment is a large corporate ISP that defies categorization, we
>> almost have at least one of every imaginable use-case for running on
>> Linux except something in the Top 100 SuperComputer list. I reckon it's
>> about as representative as I'm ever gonna see.
>> 
>> People are free to draw their own conclusions as always, and real data
>> is valuable in arriving at those conclusions. YMMV.
>
> Thanks for sharing your experience, and not just your emotions. One of my
> favorite quotes is, "A man with an experience is not subject to a man with an
> argument."

My thanks, too! There's nothing like reading on some actual experience
with this. So this was once the reason to keep / separate. Not that
important anymore (but this is still no excuse to force people to keep
/usr in the same filesystem).

-- 
Nuno Silva (aka njsg)
http://njsg.sdf-eu.org/

Re: [gentoo-user] Re: Anyone switched to eudev yet?

[Dale]

Nuno J. Silva wrote:
> My thanks, too! There's nothing like reading on some actual experience
> with this. So this was once the reason to keep / separate. Not that
> important anymore (but this is still no excuse to force people to keep
> /usr in the same filesystem). 

Mines on a separate partition because it is on LVM instead of a regular
partition.  Actually, only / and /boot is on a regular partition. 
Everything else is on LVM.  I don't have / on LVM because I don't want
to use a init thingy. 

I just wonder, how many people still have /usr on a separate partition.
Like most things, there is no way to really know. 

Dale

:-)  :-) 

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

Re: [gentoo-user] Re: Anyone switched to eudev yet?

[Kevin Chadwick]

On Sun, 16 Dec 2012 22:32:24 +0200
nunojsilva@ist.utl.pt (Nuno J. Silva) wrote:

> My thanks, too! There's nothing like reading on some actual experience
> with this. So this was once the reason to keep / separate. Not that
> important anymore (but this is still no excuse to force people to keep
> /usr in the same filesystem).

Sorry but real world data is important and I am fully aware of the
academic theorist problems compared to practical experience but this
simply doesn't apply here. I didn't see any evidence or
argument that a larger root conducting millions more writes is as safe
as a smaller read only one perhaos not touched for months.

The testing criteria were very generally put and just because an
earthquake hasn't hit 200 building in the last 50 years is no reason to
remove shock absorbers or other measures from sky scrapers.

Re: [gentoo-user] Re: Anyone switched to eudev yet?

[Dale]

Kevin Chadwick wrote:
> On Sun, 16 Dec 2012 22:32:24 +0200
> nunojsilva@ist.utl.pt (Nuno J. Silva) wrote:
>
>> My thanks, too! There's nothing like reading on some actual experience
>> with this. So this was once the reason to keep / separate. Not that
>> important anymore (but this is still no excuse to force people to keep
>> /usr in the same filesystem).
> Sorry but real world data is important and I am fully aware of the
> academic theorist problems compared to practical experience but this
> simply doesn't apply here. I didn't see any evidence or
> argument that a larger root conducting millions more writes is as safe
> as a smaller read only one perhaos not touched for months.
>
> The testing criteria were very generally put and just because an
> earthquake hasn't hit 200 building in the last 50 years is no reason to
> remove shock absorbers or other measures from sky scrapers.
>
>


Question.  A file system, /usr for example, is mounted read only.  The
system crashes for whatever reason such as a power failure.  Since it is
mounted read only, would there be a larger or smaller risk of corrupted
data on that partition?  From what I understand, the possible corruption
is from files not being written to the drive but since it is mounted
read only, then that removes that possibility. 

Just checking on a thought here.

Dale

:-)  :-) 

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

Re: [gentoo-user] Re: Anyone switched to eudev yet?

[Michael Orlitzky]

On 12/17/2012 12:44 AM, Dale wrote:
>>
> 
> 
> Question.  A file system, /usr for example, is mounted read only.  The
> system crashes for whatever reason such as a power failure.  Since it is
> mounted read only, would there be a larger or smaller risk of corrupted
> data on that partition?  From what I understand, the possible corruption
> is from files not being written to the drive but since it is mounted
> read only, then that removes that possibility. 
> 
> Just checking on a thought here.
> 

Power failure? Your data is fine.

But "whatever reason?" Think of the possibilities!

  * The Earth stops rotating and your hard drive is flung at 67,000
    miles per hour directly into the sun.

  * Today is backwards day, and your ones and zeros have been switched.
    Fsck should be able to handle this, somebody file a bug.

  * The system never really existed, it was all in your imagination.
    Fade to credits.

Re: [gentoo-user] Re: Anyone switched to eudev yet?

[Dale]

Michael Orlitzky wrote:
> On 12/17/2012 12:44 AM, Dale wrote:
>>
>> Question.  A file system, /usr for example, is mounted read only.  The
>> system crashes for whatever reason such as a power failure.  Since it is
>> mounted read only, would there be a larger or smaller risk of corrupted
>> data on that partition?  From what I understand, the possible corruption
>> is from files not being written to the drive but since it is mounted
>> read only, then that removes that possibility. 
>>
>> Just checking on a thought here.
>>
> Power failure? Your data is fine.
>
> But "whatever reason?" Think of the possibilities!
>
>   * The Earth stops rotating and your hard drive is flung at 67,000
>     miles per hour directly into the sun.
>
>   * Today is backwards day, and your ones and zeros have been switched.
>     Fsck should be able to handle this, somebody file a bug.
>
>   * The system never really existed, it was all in your imagination.
>     Fade to credits.
>
>

So, since I have /usr separate from the rest, I could mount it read only
and reduce the chance of corruption if say my UPS failed?  I already do
this for /boot.  Interesting.  Very interesting indeed. 

If the other issues happen, computers is likely the least of our
problems.  ;-) 

Dale

:-)  :-) 

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

Re: [gentoo-user] Re: Anyone switched to eudev yet?

[Michael Orlitzky]

On 12/17/2012 01:09 AM, Dale wrote:
> 
> So, since I have /usr separate from the rest, I could mount it read only
> and reduce the chance of corruption if say my UPS failed?  I already do
> this for /boot.  Interesting.  Very interesting indeed. 
> 
> If the other issues happen, computers is likely the least of our
> problems.  ;-) 
> 

Yes, although it's unlikely that any corruption would occur in the first
place if you're not writing to the filesystem during the crash.

Re: [gentoo-user] Re: Anyone switched to eudev yet?

[Dale]

Michael Orlitzky wrote:
> On 12/17/2012 01:09 AM, Dale wrote:
>> So, since I have /usr separate from the rest, I could mount it read only
>> and reduce the chance of corruption if say my UPS failed?  I already do
>> this for /boot.  Interesting.  Very interesting indeed. 
>>
>> If the other issues happen, computers is likely the least of our
>> problems.  ;-) 
>>
> Yes, although it's unlikely that any corruption would occur in the first
> place if you're not writing to the filesystem during the crash.
>
>


But unlikely is not equal to zero.  Murphy's law.  o_O 

Dale

:-)  :-) 

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

Re: [gentoo-user] Re: Anyone switched to eudev yet?

[Kevin Chadwick]

> So, since I have /usr separate from the rest, I could mount it read only
> and reduce the chance of corruption if say my UPS failed?  I already do
> this for /boot.  Interesting.  Very interesting indeed. 
> 
> If the other issues happen, computers is likely the least of our
> problems.  ;-) 

Or if the bulk of the user data is under /usr perhaps with
further partitions for even more highly written locations
then you can have a more trusted ro root though in fact all the
partitions gain. It's not just power failure this covers and less so
these days with journaling, (though remember, journaling may not apply
to your system such as some embedded). I guess also the system crash
term may have been used in the FHS to cover more than just power
failure, filesystem bugs (less code used), hardware failure etc..

There are other plus points in the FHS too.

A counter point is head movement though that could be improved at the
same time due to a reduced fragmentation (I know it's much lower on unix
but still applies) depending on a few obvious things and removed with
ssd.

p.s. I'm 30 in January, so I hope I wouldn't be thought of as an old
fart already. Just because I agree with the /bin/grep /usr/bin/grep
consolidation but not the data consolidation.

-- 
_______________________________________________________________________

'Write programs that do one thing and do it well. Write programs to work
together. Write programs to handle text streams, because that is a
universal interface'

(Doug McIlroy)
_______________________________________________________________________

Re: [gentoo-user] Re: Anyone switched to eudev yet?

[Pandu Poluan]

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

On Dec 17, 2012 7:31 AM, "Kevin Chadwick" <ma1l1ists@yahoo.co.uk> wrote:
>
> On Sun, 16 Dec 2012 22:32:24 +0200
> nunojsilva@ist.utl.pt (Nuno J. Silva) wrote:
>
> > My thanks, too! There's nothing like reading on some actual experience
> > with this. So this was once the reason to keep / separate. Not that
> > important anymore (but this is still no excuse to force people to keep
> > /usr in the same filesystem).
>
> Sorry but real world data is important and I am fully aware of the
> academic theorist problems compared to practical experience but this
> simply doesn't apply here. I didn't see any evidence or
> argument that a larger root conducting millions more writes is as safe
> as a smaller read only one perhaos not touched for months.
>
> The testing criteria were very generally put and just because an
> earthquake hasn't hit 200 building in the last 50 years is no reason to
> remove shock absorbers or other measures from sky scrapers.
>

This.

My desire to separate / and /usr are more for minimizing possible problems
with the filesystem. Yes, I can mount /usr ro, but sooner or later I have
to mount it rw, and as Murphy's Law dictates, it's exactly at that moment
something bad will happen.

Rgds,
--

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

Re: [gentoo-user] Re: Anyone switched to eudev yet?

[Alan McKinnon]

On Mon, 17 Dec 2012 00:26:13 +0000
Kevin Chadwick <ma1l1ists@yahoo.co.uk> wrote:

> On Sun, 16 Dec 2012 22:32:24 +0200
> nunojsilva@ist.utl.pt (Nuno J. Silva) wrote:
> 
> > My thanks, too! There's nothing like reading on some actual
> > experience with this. So this was once the reason to keep /
> > separate. Not that important anymore (but this is still no excuse
> > to force people to keep /usr in the same filesystem).
> 
> Sorry but real world data is important and I am fully aware of the
> academic theorist problems compared to practical experience but this
> simply doesn't apply here. I didn't see any evidence or
> argument that a larger root conducting millions more writes is as safe
> as a smaller read only one perhaos not touched for months.
> 
> The testing criteria were very generally put and just because an
> earthquake hasn't hit 200 building in the last 50 years is no reason
> to remove shock absorbers or other measures from sky scrapers.
> 

I thought I was clear in that - I was my survey of my machines for my
purposes only, not a formal study in any way.

-- 
Alan McKinnon
alan.mckinnon@gmail.com

Re: [gentoo-user] Re: Anyone switched to eudev yet?

[Alan McKinnon]

On Sun, 16 Dec 2012 22:32:24 +0200
nunojsilva@ist.utl.pt (Nuno J. Silva) wrote:


> > Thanks for sharing your experience, and not just your emotions. One
> > of my favorite quotes is, "A man with an experience is not subject
> > to a man with an argument."
> 
> My thanks, too! There's nothing like reading on some actual experience
> with this. So this was once the reason to keep / separate. Not that
> important anymore (but this is still no excuse to force people to keep
> /usr in the same filesystem).
> 

A rescue/maintainer mode was *very* useful in days gone by. Lately I
feel that this is better served with properly built tool (SysrescueCD
and friends) can be stored on disk and launched from grub. Besides,
these tools do the job so much better than just about anything you
would put in a production /. Just keep your tools up to date, nothing
worse than finding your brand new shiny LVM is not mountable as the
metadata format is too new :-)

-- 
Alan McKinnon
alan.mckinnon@gmail.com

Re: [gentoo-user] Re: Anyone switched to eudev yet?

[Alan McKinnon]

On Sun, 16 Dec 2012 12:49:53 -0600
Bruce Hill <daddy@happypenguincomputers.com> wrote:

> On Sun, Dec 16, 2012 at 05:10:43PM +0200, Alan McKinnon wrote:
> > 
> > That was the original reason for having / and /usr separate, and it
> > dates back to the early 70s. The other reason that stems from that
> > time period is the size of disks we had back then - they were tiny
> > and often a minimal / was all that could really fit on the primary
> > system drive.
> > 
> > Gradually over time this setup became the norm and people started to
> > depend on it, and more importantly, started to believe it was
> > important to retain it. It's their right to believe that. 
> > 
> > Recently I decided to measure if I still needed a separate /usr (I
> > was a long time advocate of retaining it). I'm in the lucky
> > position of having ~200 Linux machines, all distinctly different,
> > at my disposal, so I trawled through memory and incident logs
> > looking for cases where a separate /usr was crucial to recovery
> > after any form of error. To my surprise, I found none at all and
> > those logs go back 5 years.
> > 
> > So I got to change my mind (not something I do very often I admit)
> > and concluded that separate base and user systems (/ and /usr) was
> > no longer something I needed to do - the "system" - disks, hardware
> > and the software on the disks - was very reliable, and what I
> > really needed was ability to boot from USB rescue disks. I did
> > find, not unsurprisingly, that I also really needed /usr/local on a
> > separate partition but that's because of how we install our
> > in-house software here, plus our backup policies.
> > 
> > It also goes without saying that these days we
> > need /home, /var, /var/log and /tmp to all be on their own
> > filesystem, and we need that more than ever.
> > 
> > I thought I should just toss that in the ring for people who are
> > undecided where they stand on the debate of separate / vs /usr. It's
> > what I found on our production, dev and staging servers, plus a
> > whole lot of people's personal workstations (sysadmins and devs).
> > The environment is a large corporate ISP that defies
> > categorization, we almost have at least one of every imaginable
> > use-case for running on Linux except something in the Top 100
> > SuperComputer list. I reckon it's about as representative as I'm
> > ever gonna see.
> > 
> > People are free to draw their own conclusions as always, and real
> > data is valuable in arriving at those conclusions. YMMV.
> 
> Thanks for sharing your experience, and not just your emotions. One
> of my favorite quotes is, "A man with an experience is not subject to
> a man with an argument."

There's a few things I completely left out - /usr/portage
and /usr/distfiles - I forgot all about those.

For years now I manually move those to /var as I consider /usr to
be mostly read-only, plus the portage tree and distfiles are hungry.
They form two cases where separate mounts are highly desirable.

The other thing I didn't comment on is /usr mounted ro over NFS. The
only current valid case I've heard of is school and university labs,
and one of those is the only one I've ever seen. Not something I ever
work with to be honest. I would like to know how prevalent /usr as an
NFS mount is in the world out there.


-- 
Alan McKinnon
alan.mckinnon@gmail.com

Re: [gentoo-user] Re: Anyone switched to eudev yet?

[Mark David Dumlao]

On Sun, Dec 16, 2012 at 11:10 PM, Alan McKinnon <alan.mckinnon@gmail.com> wrote:
>
> On Sat, 15 Dec 2012 10:16:05 +0200
> nunojsilva@ist.utl.pt (Nuno J. Silva) wrote:
>
> > On 2012-12-14, Mark Knecht wrote:
> >
> > > I guess the other question that's lurking here for me is why do you
> > > have /usr on a separate partition? What's the usage model that
> > > drives a person to do that? The most I've ever done is
> > > move /usr/portage and /usr/src to other places. My /usr never has
> > > all that much in it beyond those two directories, along with
> > > maybe /usr/share. Would it not be easier for you in the long run to
> > > move /usr back to / and not have to deal with this question at all?
> >
> > I may be wrong in this one, but the idea I have is that your regular
> > applications (so, most of them) all lie under /usr/ -- /lib /bin and
> > others are for essential system tools.
> >
>
> That was the original reason for having / and /usr separate, and it
> dates back to the early 70s. The other reason that stems from that time
> period is the size of disks we had back then - they were tiny and often
> a minimal / was all that could really fit on the primary system drive.

I'm sorry, but I just can't let this one go. The reasons are
backwards. The limitation in free space was the original reason [1]
why / and /usr were separated. In fact, /usr was supposed to serve the
same purpose as /home - it was originally a directory for users. It's
only a quirk of history that served to keep most of the binaries in
/usr when the home directories were moved elsewhere to /home.

Long story short, Unix, too, has its share of old farts that are
unwilling to embrace change at anything faster than a glacier's pace.
Just ask the Plan 9 folks.

[1] http://lists.busybox.net/pipermail/busybox/2010-December/074114.html

--
This email is:    [ ] actionable   [x] fyi        [ ] social
Response needed:  [ ] yes          [ ] up to you  [x] no
Time-sensitive:   [ ] immediate    [ ] soon       [x] none

Re: [gentoo-user] Re: Anyone switched to eudev yet?

[Alan McKinnon]

On Mon, 17 Dec 2012 16:02:54 +0800
Mark David Dumlao <madumlao@gmail.com> wrote:

> > That was the original reason for having / and /usr separate, and it
> > dates back to the early 70s. The other reason that stems from that
> > time period is the size of disks we had back then - they were tiny
> > and often a minimal / was all that could really fit on the primary
> > system drive.  
> 
> I'm sorry, but I just can't let this one go. The reasons are
> backwards. The limitation in free space was the original reason [1]
> why / and /usr were separated. In fact, /usr was supposed to serve the
> same purpose as /home - it was originally a directory for users. It's
> only a quirk of history that served to keep most of the binaries in
> /usr when the home directories were moved elsewhere to /home.
> 
> Long story short, Unix, too, has its share of old farts that are
> unwilling to embrace change at anything faster than a glacier's pace.
> Just ask the Plan 9 folks.
> 
> [1]
> http://lists.busybox.net/pipermail/busybox/2010-December/074114.html

Well fair enough. This stuff is becoming more myth than fact as less
and less people are around to remember how it really went. There may
even have been to-ing and fro-ing moving bits around till Ken and
Dennis settled on the eventual outcome in that post.

Either way, we still agree. A separate /usr is, *for the most part*, a
tradition applied without much understanding of the reason (most
traditions are exactly like this). Most people do not actually need
it. 

Some people do need it and can clearly state why; I am not in that
group.

-- 
Alan McKinnon
alan.mckinnon@gmail.com

Re: [gentoo-user] Re: Anyone switched to eudev yet?

[Mark David Dumlao]

On Mon, Dec 17, 2012 at 4:46 PM, Alan McKinnon <alan.mckinnon@gmail.com> wrote:
> On Mon, 17 Dec 2012 16:02:54 +0800
> Mark David Dumlao <madumlao@gmail.com> wrote:
>
>> > That was the original reason for having / and /usr separate, and it
>> > dates back to the early 70s. The other reason that stems from that
>> > time period is the size of disks we had back then - they were tiny
>> > and often a minimal / was all that could really fit on the primary
>> > system drive.
>>
>> I'm sorry, but I just can't let this one go. The reasons are
>> backwards. The limitation in free space was the original reason [1]
>> why / and /usr were separated. In fact, /usr was supposed to serve the
>> same purpose as /home - it was originally a directory for users. It's
>> only a quirk of history that served to keep most of the binaries in
>> /usr when the home directories were moved elsewhere to /home.
>>
>> Long story short, Unix, too, has its share of old farts that are
>> unwilling to embrace change at anything faster than a glacier's pace.
>> Just ask the Plan 9 folks.
>>
>> [1]
>> http://lists.busybox.net/pipermail/busybox/2010-December/074114.html
>
> Well fair enough. This stuff is becoming more myth than fact as less
> and less people are around to remember how it really went. There may
> even have been to-ing and fro-ing moving bits around till Ken and
> Dennis settled on the eventual outcome in that post.
>
> Either way, we still agree. A separate /usr is, *for the most part*, a
> tradition applied without much understanding of the reason (most
> traditions are exactly like this). Most people do not actually need
> it.

The sweet irony here is that Poettering - the cause for all this mess
- likely understood the logistics and rationale of the / and /usr
split better than most of his detractors - I'm pretty sure I landed on
that link by starting from one of his systemd tutorial pages, though I
can't exactly remember which one. Thankfully, I've never had to
maintain systems whose disks were small and low performing enough that
it actually mattered to separate / from /usr.
--
This email is:    [ ] actionable   [ ] fyi        [x] social
Response needed:  [ ] yes          [x] up to you  [ ] no
Time-sensitive:   [ ] immediate    [ ] soon       [x] none

Re: [gentoo-user] Re: Anyone switched to eudev yet?

[Alan McKinnon]

On Tue, 18 Dec 2012 19:44:13 +0800
Mark David Dumlao <madumlao@gmail.com> wrote:

> >> http://lists.busybox.net/pipermail/busybox/2010-December/074114.html  
> >
> > Well fair enough. This stuff is becoming more myth than fact as less
> > and less people are around to remember how it really went. There may
> > even have been to-ing and fro-ing moving bits around till Ken and
> > Dennis settled on the eventual outcome in that post.
> >
> > Either way, we still agree. A separate /usr is, *for the most
> > part*, a tradition applied without much understanding of the reason
> > (most traditions are exactly like this). Most people do not
> > actually need it.  
> 
> The sweet irony here is that Poettering - the cause for all this mess
> - likely understood the logistics and rationale of the / and /usr
> split better than most of his detractors - I'm pretty sure I landed on
> that link by starting from one of his systemd tutorial pages, though I
> can't exactly remember which one. Thankfully, I've never had to
> maintain systems whose disks were small and low performing enough that
> it actually mattered to separate / from /usr.

Yes indeed :-)

The other sweet irony is that Lennart is quite often correct in what he
sets out to solve. He is the human equivalent of "disruptive
technology", but also has this knack of rubbing people up the wrong way
(or at least creating a circumstance where people believe he has rubbed
them up the wrong way). I have some measure of empathy for the man as I
tend to do similar things in my own sphere

-- 
Alan McKinnon
alan.mckinnon@gmail.com

Re: [Bulk] Re: [gentoo-user] Re: Anyone switched to eudev yet?

[Kevin Chadwick]

> Thankfully, I've never had to
> maintain systems whose disks were small and low performing enough that
> it actually mattered to separate / from /usr.

So you don't understand it much at all. Actually many of lennarts pages
such as his security.html are full of wildly incorrect claims and
innaccurate assumptions and feature plagiarism leading me to believe
he doesn't have much experience outside of coding. Going back in time
his claim of pulse audio being good for professional audio was also
completely off the mark. Seperating Gnome and pulse can now cause pro
audio users on binary distro's major headaches too. I pointed one
fellow in the direction of a pro audio on gentoo tutorial rather than
deal with some new problems a little after systemd hit Arch.

-- 
_______________________________________________________________________

'Write programs that do one thing and do it well. Write programs to work
together. Write programs to handle text streams, because that is a
universal interface'

(Doug McIlroy)
_______________________________________________________________________

Re: [Bulk] Re: [gentoo-user] Re: Anyone switched to eudev yet?

[Marc Joliet]

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

Am Tue, 18 Dec 2012 13:34:07 +0000
schrieb Kevin Chadwick <ma1l1ists@yahoo.co.uk>:

[...]
> Going back in time
> his claim of pulse audio being good for professional audio was also
> completely off the mark. Seperating Gnome and pulse can now cause pro
> audio users on binary distro's major headaches too. I pointed one
> fellow in the direction of a pro audio on gentoo tutorial rather than
> deal with some new problems a little after systemd hit Arch.

Holy cow, did he really? Link, please! I thought pulseaudio was only ever
advertised for desktop and some embedded use cases, and that Lennart is
perfectly aware of the fundamental differences between JACK and PA and that
they target a completely different range of applications [0]. I wouldn't
*dream* of using anything other than JACK (with LADISH) for pro-audio work
(well, more like "home recording" in my case, but close enough).

I actually like pulseaudio for desktop use, though. When you start JACK it will
kindly get out of the way, so the two aren't necessarily mutually exclusive
(actually, you can set it up to automatically set up ports in JACK2 with the
jackdbus-detect module, if you want that). After a few years of use I finally
ended up requiring one of its more "advanced" features: moving streams between
sound cards at runtime.

[0] http://0pointer.de/blog/projects/when-pa-and-when-not.html

-- 
Marc Joliet
--
"People who think they know everything really annoy those of us who know we
don't" - Bjarne Stroustrup

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

Re: [Bulk] Re: [gentoo-user] Re: Anyone switched to eudev yet?

[Volker Armin Hemmann]

Am Dienstag, 18. Dezember 2012, 23:02:41 schrieb Marc Joliet:
> Am Tue, 18 Dec 2012 13:34:07 +0000
> schrieb Kevin Chadwick <ma1l1ists@yahoo.co.uk>:
> 
> [...]
> 
> > Going back in time
> > his claim of pulse audio being good for professional audio was also
> > completely off the mark. Seperating Gnome and pulse can now cause pro
> > audio users on binary distro's major headaches too. I pointed one
> > fellow in the direction of a pro audio on gentoo tutorial rather than
> > deal with some new problems a little after systemd hit Arch.
> 
> Holy cow, did he really? Link, please! I thought pulseaudio was only ever
> advertised for desktop and some embedded use cases, and that Lennart is
> perfectly aware of the fundamental differences between JACK and PA and that
> they target a completely different range of applications [0]. I wouldn't
> *dream* of using anything other than JACK (with LADISH) for pro-audio work
> (well, more like "home recording" in my case, but close enough).
> 
> I actually like pulseaudio for desktop use, though. When you start JACK it
> will kindly get out of the way, so the two aren't necessarily mutually
> exclusive (actually, you can set it up to automatically set up ports in
> JACK2 with the jackdbus-detect module, if you want that). After a few years
> of use I finally ended up requiring one of its more "advanced" features:
> moving streams between sound cards at runtime.
> 
> [0] http://0pointer.de/blog/projects/when-pa-and-when-not.html

remember this? a solution without a problem to solve, making a lot of people's 
lifes harder, dropped onto them by the godlike Lennart P.?
http://lalists.stanford.edu/lad/2009/06/0218.html

-- 
#163933

Re: [Bulk] Re: [gentoo-user] Re: Anyone switched to eudev yet?

[Walter Dnes]

On Wed, Dec 19, 2012 at 07:48:45PM +0100, Volker Armin Hemmann wrote
> 
> remember this? a solution without a problem to solve, making a lot
> of people's lifes harder, dropped onto them by the godlike Lennart P.?
> http://lalists.stanford.edu/lad/2009/06/0218.html

  The thread was started by Lennart.  In the first message
http://lalists.stanford.edu/lad/2009/06/0191.html he says...

> If you don't do RT development or doing RT development only for
> embedded cases, or if you are a
> Gentoo-Build-It-All-Myself-Because-It-Is-So-Much-Faster-And-Need-To-Reinvent-The-Wheel-Daily-And-Configurating-Things-Is-Awesome-Guy
> then it doesn't mean anything for you.

  And people wonder why Gentoo-ers dislike the guy.

-- 
Walter Dnes <waltdnes@waltdnes.org>
I don't run "desktop environments"; I run useful applications

Re: [gentoo-user] Re: Anyone switched to eudev yet?

[Michael Mol]

On Mon, Dec 17, 2012 at 3:46 AM, Alan McKinnon <alan.mckinnon@gmail.com> wrote:
> On Mon, 17 Dec 2012 16:02:54 +0800
> Mark David Dumlao <madumlao@gmail.com> wrote:
>
>> > That was the original reason for having / and /usr separate, and it
>> > dates back to the early 70s. The other reason that stems from that
>> > time period is the size of disks we had back then - they were tiny
>> > and often a minimal / was all that could really fit on the primary
>> > system drive.
>>
>> I'm sorry, but I just can't let this one go. The reasons are
>> backwards. The limitation in free space was the original reason [1]
>> why / and /usr were separated. In fact, /usr was supposed to serve the
>> same purpose as /home - it was originally a directory for users. It's
>> only a quirk of history that served to keep most of the binaries in
>> /usr when the home directories were moved elsewhere to /home.
>>
>> Long story short, Unix, too, has its share of old farts that are
>> unwilling to embrace change at anything faster than a glacier's pace.
>> Just ask the Plan 9 folks.
>>
>> [1]
>> http://lists.busybox.net/pipermail/busybox/2010-December/074114.html
>
> Well fair enough. This stuff is becoming more myth than fact as less
> and less people are around to remember how it really went. There may
> even have been to-ing and fro-ing moving bits around till Ken and
> Dennis settled on the eventual outcome in that post.
>
> Either way, we still agree. A separate /usr is, *for the most part*, a
> tradition applied without much understanding of the reason (most
> traditions are exactly like this). Most people do not actually need
> it.
>
> Some people do need it and can clearly state why; I am not in that
> group.

Personally, that post on the busybox thread tends to infuriate me
every time I see someone reference it.

So, sure. The reason / and /usr were originally split is because their
disks on the machine they were evolving this on were insufficient for
the original layout.

Let's look at that again, reduced: They split / and /usr because
unforeseen operational requirements for a given system demanded it.

And again, reduced: They did something because unforeseen operational
requirements demanded it.

This, right there, is the reason for separate / and /usr; operational
requirements can place constraints on a system such that the initial
configuration is no longer sufficient. It's the same reason you might
have a separate /home. Or a separate /home/dad. Or a separate
/var/cache. Every now and again, taking a folder and putting it on its
own disk is the simplest, quickest and most straightforward way to
solve a problem with the resources available.

Now, why is /usr special? It's because it contains executable code the
system might require while launching. But this is _only_ a problem if
the code on /usr is required in order to mount /usr. What if /usr is
on a raw disk? No special code needed there. What if /usr is on its
own partition? No special code needed there. What if /usr is on
hardware raid? No special code needed there. What if /usr is on RAID5
with version 0.9 metadata? No special code needed there.

There are numerous circumstances where code on /usr should not be
required to mount /usr. And circumstances can and have led to a
separate /usr on numerous systems. Some people have set it up as
read-only for security purposes. Some people have mounted it over NFS.
Some people simply ran out of disk space and put it on a new disk.
And, yeah, that can still happen; I've had to pull similar stunts on
Windows in VMs (yay, junctions!) which grew larger than anticipated
due to software updates.

--
:wq

Re: [gentoo-user] Re: Anyone switched to eudev yet?

[Alan McKinnon]

On Tue, 18 Dec 2012 09:08:53 -0500
Michael Mol <mikemol@gmail.com> wrote:


This sentence summarizes my understanding of your post nicely:

> Now, why is /usr special? It's because it contains executable code the
> system might require while launching.

Now there are only two approaches that could solve that problem:

1. Avoid it entirely
2. Deal with it using any of a variety of bootstrap techniques

#1 is handled by policy, whereby any code the system might require
while launching is not in /usr.

#2 already has a solution, it's called an init*. Other solutions exist
but none are as elegant as a throwaway temporary filesystem in RAM.

I should be clear that I do not necessarily support Lennart's
solutions, but I do support his perception of the problem (at least
partially). We cannot support situations where *launch* code is
haphazardly scattered in location X and this must always work for all
values of X. We already have a remarkably parallel situation in /boot -
in order to boot at all, the code running at that point in time needs
to be able to find stuff, and it finds it (by policy) in what we will
later call /boot. I see this /usr debate as the same thing on a larger
scale.

-- 
Alan McKinnon
alan.mckinnon@gmail.com

Re: [gentoo-user] Re: Anyone switched to eudev yet?

[Michael Mol]

On Tue, Dec 18, 2012 at 9:33 AM, Alan McKinnon <alan.mckinnon@gmail.com> wrote:
> On Tue, 18 Dec 2012 09:08:53 -0500
> Michael Mol <mikemol@gmail.com> wrote:
>
>
> This sentence summarizes my understanding of your post nicely:
>
>> Now, why is /usr special? It's because it contains executable code the
>> system might require while launching.
>
> Now there are only two approaches that could solve that problem:
>
> 1. Avoid it entirely
> 2. Deal with it using any of a variety of bootstrap techniques
>
> #1 is handled by policy, whereby any code the system might require
> while launching is not in /usr.

This is the solution I favor. Systemic structure which allows
dependency leakage is indicative (to me) of lack of foresight and
proper component role limitation, and ought to be fought.

>
> #2 already has a solution, it's called an init*. Other solutions exist
> but none are as elegant as a throwaway temporary filesystem in RAM.

I find virtually nothing elegant about a temporary filesystem in RAM.
It duplicates code that already exists on the system, and it
represents and additional maintenance step in system upgrades. It
seems almost a given that if someone is keeping multiple kernel images
on a system, they're not updating the initr* for each when binaries
that would be found in each are upgraded or rebuilt.

In Debian, Ubuntu and others, this is handled by a post-install hook
where the initr* image is rebuilt. To me, this honestly feels like a
hack. In something like Gentoo, I'd rather see package placement
driven by whether or not it will be needed to get all mount points
mounted. If that means i18n databases under something like /boot/data,
that seems reasonable. To me, the only cases where initr* feels like
the right solution are things like netboot or booting from read-only
media.

>
> I should be clear that I do not necessarily support Lennart's
> solutions, but I do support his perception of the problem (at least
> partially). We cannot support situations where *launch* code is
> haphazardly scattered in location X and this must always work for all
> values of X. We already have a remarkably parallel situation in /boot -
> in order to boot at all, the code running at that point in time needs
> to be able to find stuff, and it finds it (by policy) in what we will
> later call /boot. I see this /usr debate as the same thing on a larger
> scale.

--
:wq

Re: [gentoo-user] Re: Anyone switched to eudev yet?

[Neil Bothwick]

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

On Tue, 18 Dec 2012 17:55:16 -0500, Michael Mol wrote:

> > #2 already has a solution, it's called an init*. Other solutions exist
> > but none are as elegant as a throwaway temporary filesystem in RAM.  
> 
> I find virtually nothing elegant about a temporary filesystem in RAM.
> It duplicates code that already exists on the system, and it
> represents and additional maintenance step in system upgrades. It
> seems almost a given that if someone is keeping multiple kernel images
> on a system, they're not updating the initr* for each when binaries
> that would be found in each are upgraded or rebuilt.

I don't use separate initr* files, the initramfs is built into the
kernel, using the latest versions of the tools installed at the time the
kernel was compiled. That gives a single bootable file that, if it works
now, should always work. Most changes to the component packages do not
affect the simple job they have to do to get a system ready to run init.
 
> In Debian, Ubuntu and others, this is handled by a post-install hook
> where the initr* image is rebuilt. To me, this honestly feels like a
> hack. In something like Gentoo, I'd rather see package placement
> driven by whether or not it will be needed to get all mount points
> mounted. If that means i18n databases under something like /boot/data,
> that seems reasonable. To me, the only cases where initr* feels like
> the right solution are things like netboot or booting from read-only

Or / on LVM, or / on an encrypted filesystem. or any other requirement
for a filesystem that cannot be used without adding code to the kernel.


-- 
Neil Bothwick

WinErr 002: No Error - Yet

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

Re: [gentoo-user] Re: Anyone switched to eudev yet?

[Michael Mol]

On Tue, Dec 18, 2012 at 6:07 PM, Neil Bothwick <neil@digimed.co.uk> wrote:
> On Tue, 18 Dec 2012 17:55:16 -0500, Michael Mol wrote:
>
>> > #2 already has a solution, it's called an init*. Other solutions exist
>> > but none are as elegant as a throwaway temporary filesystem in RAM.
>>
>> I find virtually nothing elegant about a temporary filesystem in RAM.
>> It duplicates code that already exists on the system, and it
>> represents and additional maintenance step in system upgrades. It
>> seems almost a given that if someone is keeping multiple kernel images
>> on a system, they're not updating the initr* for each when binaries
>> that would be found in each are upgraded or rebuilt.
>
> I don't use separate initr* files, the initramfs is built into the
> kernel, using the latest versions of the tools installed at the time the
> kernel was compiled. That gives a single bootable file that, if it works
> now, should always work. Most changes to the component packages do not
> affect the simple job they have to do to get a system ready to run init.

Just because it runs, doesn't mean it "works." For example, let's say
your network now requires an additional protocol for the host to
operate properly. Or let's say there's a security vulnerability in
some network-aware component in your initramfs. Or that some piece of
automounter code is vulnerable to corrupted filesystems on flash
drives.

>
>> In Debian, Ubuntu and others, this is handled by a post-install hook
>> where the initr* image is rebuilt. To me, this honestly feels like a
>> hack. In something like Gentoo, I'd rather see package placement
>> driven by whether or not it will be needed to get all mount points
>> mounted. If that means i18n databases under something like /boot/data,
>> that seems reasonable. To me, the only cases where initr* feels like
>> the right solution are things like netboot or booting from read-only
>
> Or / on LVM, or / on an encrypted filesystem. or any other requirement
> for a filesystem that cannot be used without adding code to the kernel.

/ on special filesystems is a good use case, yes. I should have said
"/ from an unusual source."

--
:wq

Re: [gentoo-user] Re: Anyone switched to eudev yet?

[Alan McKinnon]

On Tue, 18 Dec 2012 22:05:21 -0500
Michael Mol <mikemol@gmail.com> wrote:

> > I don't use separate initr* files, the initramfs is built into the
> > kernel, using the latest versions of the tools installed at the
> > time the kernel was compiled. That gives a single bootable file
> > that, if it works now, should always work. Most changes to the
> > component packages do not affect the simple job they have to do to
> > get a system ready to run init.  
> 
> Just because it runs, doesn't mean it "works." For example, let's say
> your network now requires an additional protocol for the host to
> operate properly. Or let's say there's a security vulnerability in
> some network-aware component in your initramfs. Or that some piece of
> automounter code is vulnerable to corrupted filesystems on flash
> drives.

To borrow your own term, all that falls fair and square under the
heading of "unforeseen operational requirements demanded it"

Things change, packagers and sysadmins must react.

-- 
Alan McKinnon
alan.mckinnon@gmail.com

Re: [gentoo-user] Re: Anyone switched to eudev yet?

[Neil Bothwick]

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

On Tue, 18 Dec 2012 22:05:21 -0500, Michael Mol wrote:

> > I don't use separate initr* files, the initramfs is built into the
> > kernel, using the latest versions of the tools installed at the time
> > the kernel was compiled. That gives a single bootable file that, if
> > it works now, should always work. Most changes to the component
> > packages do not affect the simple job they have to do to get a system
> > ready to run init.  
> 
> Just because it runs, doesn't mean it "works." For example, let's say
> your network now requires an additional protocol for the host to
> operate properly. Or let's say there's a security vulnerability in
> some network-aware component in your initramfs. Or that some piece of
> automounter code is vulnerable to corrupted filesystems on flash
> drives.

Those are unreasonable, if somewhat unlikely, scenarios. It would be
simple to add a post_install hook that checks if a package used by
your initramfs has been updated and uses einfo to advise you to rebuild
your initramfs/kernel.


-- 
Neil Bothwick

Man and mouse are alike, both end up in pussy :)

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

Re: [gentoo-user] Re: Anyone switched to eudev yet?

[Neil Bothwick]

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

On Wed, 19 Dec 2012 09:38:14 +0000, Neil Bothwick wrote:

> Those are unreasonable, if somewhat unlikely, scenarios

Ack! Too many uns

s/unreasonable/reasonable/


-- 
Neil Bothwick

With free advice you often get what you pay for.

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

Re: [gentoo-user] Re: Anyone switched to eudev yet?

[Alan McKinnon]

On Tue, 18 Dec 2012 17:55:16 -0500
Michael Mol <mikemol@gmail.com> wrote:

> On Tue, Dec 18, 2012 at 9:33 AM, Alan McKinnon
> <alan.mckinnon@gmail.com> wrote:
> > On Tue, 18 Dec 2012 09:08:53 -0500
> > Michael Mol <mikemol@gmail.com> wrote:
> >
> >
> > This sentence summarizes my understanding of your post nicely:
> >
> >> Now, why is /usr special? It's because it contains executable code
> >> the system might require while launching.
> >
> > Now there are only two approaches that could solve that problem:
> >
> > 1. Avoid it entirely
> > 2. Deal with it using any of a variety of bootstrap techniques
> >
> > #1 is handled by policy, whereby any code the system might require
> > while launching is not in /usr.
> 
> This is the solution I favor. Systemic structure which allows
> dependency leakage is indicative (to me) of lack of foresight and
> proper component role limitation, and ought to be fought.
> 
> >
> > #2 already has a solution, it's called an init*. Other solutions
> > exist but none are as elegant as a throwaway temporary filesystem
> > in RAM.
> 
> I find virtually nothing elegant about a temporary filesystem in RAM.
> It duplicates code that already exists on the system, and it
> represents and additional maintenance step in system upgrades. It
> seems almost a given that if someone is keeping multiple kernel images
> on a system, they're not updating the initr* for each when binaries
> that would be found in each are upgraded or rebuilt.

You could level the same criticism at boot loaders...

The also duplicate functionality in the main system they launch (albeit
read-only at least in legacy grub) in the fs drivers, are only used
briefly at boot-time and have to be maintained. True, the bootloader
doesn't contain a *copy* of the main system files which is where the
parallel breaks down.

init* may well suck, but they suck less than any other possible
solution. And they come with one more benefit - the community has
agreed on how they work so they form a standard of sorts

> 
> In Debian, Ubuntu and others, this is handled by a post-install hook
> where the initr* image is rebuilt. To me, this honestly feels like a
> hack. In something like Gentoo, I'd rather see package placement
> driven by whether or not it will be needed to get all mount points
> mounted. If that means i18n databases under something like /boot/data,
> that seems reasonable. To me, the only cases where initr* feels like
> the right solution are things like netboot or booting from read-only
> media.

Let's not forget the prime reason why init* exists - so that binary
distros can boot and still have all kernel modules required at launch
time compiled as modules.

Bootstrap code and operation is ugly, always has been and always will
be. It also tends to be inflexible unless you use a slipstreaming
technique (my invented description of how init* works). I still think
the solution is elegant given the real-world requirements imposed on
systems.

> 
> >
> > I should be clear that I do not necessarily support Lennart's
> > solutions, but I do support his perception of the problem (at least
> > partially). We cannot support situations where *launch* code is
> > haphazardly scattered in location X and this must always work for
> > all values of X. We already have a remarkably parallel situation
> > in /boot - in order to boot at all, the code running at that point
> > in time needs to be able to find stuff, and it finds it (by policy)
> > in what we will later call /boot. I see this /usr debate as the
> > same thing on a larger scale.
> 
> --
> :wq
> 



-- 
Alan McKinnon
alan.mckinnon@gmail.com

Re: [gentoo-user] Re: Anyone switched to eudev yet?

[Michael Mol]

On Wed, Dec 19, 2012 at 4:26 AM, Alan McKinnon <alan.mckinnon@gmail.com> wrote:
> On Tue, 18 Dec 2012 17:55:16 -0500
> Michael Mol <mikemol@gmail.com> wrote:
>
>> On Tue, Dec 18, 2012 at 9:33 AM, Alan McKinnon
>> <alan.mckinnon@gmail.com> wrote:
>> > On Tue, 18 Dec 2012 09:08:53 -0500
>> > Michael Mol <mikemol@gmail.com> wrote:

[snip]

>> > #2 already has a solution, it's called an init*. Other solutions
>> > exist but none are as elegant as a throwaway temporary filesystem
>> > in RAM.
>>
>> I find virtually nothing elegant about a temporary filesystem in RAM.
>> It duplicates code that already exists on the system, and it
>> represents and additional maintenance step in system upgrades. It
>> seems almost a given that if someone is keeping multiple kernel images
>> on a system, they're not updating the initr* for each when binaries
>> that would be found in each are upgraded or rebuilt.
>
> You could level the same criticism at boot loaders...
>
> The also duplicate functionality in the main system they launch (albeit
> read-only at least in legacy grub) in the fs drivers, are only used
> briefly at boot-time and have to be maintained. True, the bootloader
> doesn't contain a *copy* of the main system files which is where the
> parallel breaks down.

Bootloaders tend to be updated in a targeted or atomic fashion. This
remains true even as they become more and more like full operating
systems.

>
> init* may well suck, but they suck less than any other possible
> solution.

I disagree. I think defining boot stages, and fixing cross-stage
dependency errors, is a far better solution.

> And they come with one more benefit - the community has
> agreed on how they work so they form a standard of sorts
>
>>
>> In Debian, Ubuntu and others, this is handled by a post-install hook
>> where the initr* image is rebuilt. To me, this honestly feels like a
>> hack. In something like Gentoo, I'd rather see package placement
>> driven by whether or not it will be needed to get all mount points
>> mounted. If that means i18n databases under something like /boot/data,
>> that seems reasonable. To me, the only cases where initr* feels like
>> the right solution are things like netboot or booting from read-only
>> media.
>
> Let's not forget the prime reason why init* exists - so that binary
> distros can boot and still have all kernel modules required at launch
> time compiled as modules.

Another valid use case.

>
> Bootstrap code and operation is ugly, always has been and always will
> be. It also tends to be inflexible unless you use a slipstreaming
> technique (my invented description of how init* works). I still think
> the solution is elegant given the real-world requirements imposed on
> systems.

And I still think that, outside of scenarios where workarounds don't
exist, it's an ugly hack and a cop-out.

--
:wq

[gentoo-user] Re: Anyone switched to eudev yet?

[Nuno J. Silva]

On 2012-12-18, Alan McKinnon wrote:

> On Tue, 18 Dec 2012 09:08:53 -0500
> Michael Mol <mikemol@gmail.com> wrote:
>
>
> This sentence summarizes my understanding of your post nicely:
>
>> Now, why is /usr special? It's because it contains executable code the
>> system might require while launching.
>
> Now there are only two approaches that could solve that problem:
>
> 1. Avoid it entirely
> 2. Deal with it using any of a variety of bootstrap techniques
>
> #1 is handled by policy, whereby any code the system might require
> while launching is not in /usr.
>
> #2 already has a solution, it's called an init*. Other solutions exist
> but none are as elegant as a throwaway temporary filesystem in RAM.

What about just mounting /usr as soon as the system boots?

<snip/>

-- 
Nuno Silva (aka njsg)
http://njsg.sdf-eu.org/

Re: [gentoo-user] Re: Anyone switched to eudev yet?

[Alan McKinnon]

On Sun, 23 Dec 2012 12:22:24 +0200
nunojsilva@ist.utl.pt (Nuno J. Silva) wrote:

> On 2012-12-18, Alan McKinnon wrote:
> 
> > On Tue, 18 Dec 2012 09:08:53 -0500
> > Michael Mol <mikemol@gmail.com> wrote:
> >
> >
> > This sentence summarizes my understanding of your post nicely:
> >
> >> Now, why is /usr special? It's because it contains executable code
> >> the system might require while launching.
> >
> > Now there are only two approaches that could solve that problem:
> >
> > 1. Avoid it entirely
> > 2. Deal with it using any of a variety of bootstrap techniques
> >
> > #1 is handled by policy, whereby any code the system might require
> > while launching is not in /usr.
> >
> > #2 already has a solution, it's called an init*. Other solutions
> > exist but none are as elegant as a throwaway temporary filesystem
> > in RAM.
> 
> What about just mounting /usr as soon as the system boots?


Please read the thread next time. The topic under discussion is
solutions to the problem of not being able to do exactly that.


-- 
Alan McKinnon
alan.mckinnon@gmail.com

[gentoo-user] Re: Anyone switched to eudev yet?

[Nuno J. Silva]

On 2012-12-23, Alan McKinnon wrote:

> On Sun, 23 Dec 2012 12:22:24 +0200
> nunojsilva@ist.utl.pt (Nuno J. Silva) wrote:
>
>> On 2012-12-18, Alan McKinnon wrote:
>> 
>> > On Tue, 18 Dec 2012 09:08:53 -0500
>> > Michael Mol <mikemol@gmail.com> wrote:
>> >
>> >
>> > This sentence summarizes my understanding of your post nicely:
>> >
>> >> Now, why is /usr special? It's because it contains executable code
>> >> the system might require while launching.
>> >
>> > Now there are only two approaches that could solve that problem:
>> >
>> > 1. Avoid it entirely
>> > 2. Deal with it using any of a variety of bootstrap techniques
>> >
>> > #1 is handled by policy, whereby any code the system might require
>> > while launching is not in /usr.
>> >
>> > #2 already has a solution, it's called an init*. Other solutions
>> > exist but none are as elegant as a throwaway temporary filesystem
>> > in RAM.
>> 
>> What about just mounting /usr as soon as the system boots?
>
>
> Please read the thread next time. The topic under discussion is
> solutions to the problem of not being able to do exactly that.

Then I suppose you can surely explain in a nutshell why can't init
scripts simply do that?

-- 
Nuno Silva (aka njsg)
http://njsg.sdf-eu.org/

Re: [gentoo-user] Re: Anyone switched to eudev yet?

[Alan Mackenzie]

On Sun, Dec 23, 2012 at 07:03:25PM +0200, Nuno J. Silva wrote:
> On 2012-12-23, Alan McKinnon wrote:

> > On Sun, 23 Dec 2012 12:22:24 +0200
> > nunojsilva@ist.utl.pt (Nuno J. Silva) wrote:

> >> On 2012-12-18, Alan McKinnon wrote:

> >> > On Tue, 18 Dec 2012 09:08:53 -0500
> >> > Michael Mol <mikemol@gmail.com> wrote:


> >> > This sentence summarizes my understanding of your post nicely:

> >> >> Now, why is /usr special? It's because it contains executable code
> >> >> the system might require while launching.

> >> > Now there are only two approaches that could solve that problem:

> >> > 1. Avoid it entirely
> >> > 2. Deal with it using any of a variety of bootstrap techniques

> >> > #1 is handled by policy, whereby any code the system might require
> >> > while launching is not in /usr.

> >> > #2 already has a solution, it's called an init*. Other solutions
> >> > exist but none are as elegant as a throwaway temporary filesystem
> >> > in RAM.

> >> What about just mounting /usr as soon as the system boots?


> > Please read the thread next time. The topic under discussion is
> > solutions to the problem of not being able to do exactly that.

> Then I suppose you can surely explain in a nutshell why can't init
> scripts simply do that?

Because certain people with influence have rearranged the filesystem so
that programs within /usr are absolutely necessary for booting; they are
needed _before_ init has a chance to mount /usr.  So either /usr has to
be in the root partition, or crazy kludges need to be used to mount /usr
before the kernel runs init.

> -- 
> Nuno Silva (aka njsg)
> http://njsg.sdf-eu.org/

-- 
Alan Mackenzie (Nuremberg, Germany).

[gentoo-user] Re: Anyone switched to eudev yet?

[Nuno J. Silva]

On 2012-12-23, Alan Mackenzie wrote:

> On Sun, Dec 23, 2012 at 07:03:25PM +0200, Nuno J. Silva wrote:
>> On 2012-12-23, Alan McKinnon wrote:
>
>> > On Sun, 23 Dec 2012 12:22:24 +0200
>> > nunojsilva@ist.utl.pt (Nuno J. Silva) wrote:
>
>> >> On 2012-12-18, Alan McKinnon wrote:
>
>> >> > On Tue, 18 Dec 2012 09:08:53 -0500
>> >> > Michael Mol <mikemol@gmail.com> wrote:
>
>
>> >> > This sentence summarizes my understanding of your post nicely:
>
>> >> >> Now, why is /usr special? It's because it contains executable code
>> >> >> the system might require while launching.
>
>> >> > Now there are only two approaches that could solve that problem:
>
>> >> > 1. Avoid it entirely
>> >> > 2. Deal with it using any of a variety of bootstrap techniques
>
>> >> > #1 is handled by policy, whereby any code the system might require
>> >> > while launching is not in /usr.
>
>> >> > #2 already has a solution, it's called an init*. Other solutions
>> >> > exist but none are as elegant as a throwaway temporary filesystem
>> >> > in RAM.
>
>> >> What about just mounting /usr as soon as the system boots?
>
>
>> > Please read the thread next time. The topic under discussion is
>> > solutions to the problem of not being able to do exactly that.
>
>> Then I suppose you can surely explain in a nutshell why can't init
>> scripts simply do that?
>
> Because certain people with influence have rearranged the filesystem so
> that programs within /usr are absolutely necessary for booting; they are
> needed _before_ init has a chance to mount /usr.  So either /usr has to
> be in the root partition, or crazy kludges need to be used to mount /usr
> before the kernel runs init.

I surely don't know the udev architecture well enough, but if this is
all done by the udev daemon, can't we just "mount /usr" before the
daemon is started? The only needed things should be mount (which is
under /bin here) and /etc/fstab.

Or is something outside udev needing stuff under /usr?

-- 
Nuno Silva (aka njsg)
http://njsg.sdf-eu.org/

Re: [gentoo-user] Re: Anyone switched to eudev yet?

[Michael Mol]

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

On Dec 23, 2012 12:46 PM, "Nuno J. Silva" <nunojsilva@ist.utl.pt> wrote:
>
> On 2012-12-23, Alan Mackenzie wrote:
>
> > On Sun, Dec 23, 2012 at 07:03:25PM +0200, Nuno J. Silva wrote:
> >> On 2012-12-23, Alan McKinnon wrote:
> >
> >> > On Sun, 23 Dec 2012 12:22:24 +0200
> >> > nunojsilva@ist.utl.pt (Nuno J. Silva) wrote:
> >
> >> >> On 2012-12-18, Alan McKinnon wrote:
> >
> >> >> > On Tue, 18 Dec 2012 09:08:53 -0500
> >> >> > Michael Mol <mikemol@gmail.com> wrote:
> >
> >
> >> >> > This sentence summarizes my understanding of your post nicely:
> >
> >> >> >> Now, why is /usr special? It's because it contains executable
code
> >> >> >> the system might require while launching.
> >
> >> >> > Now there are only two approaches that could solve that problem:
> >
> >> >> > 1. Avoid it entirely
> >> >> > 2. Deal with it using any of a variety of bootstrap techniques
> >
> >> >> > #1 is handled by policy, whereby any code the system might require
> >> >> > while launching is not in /usr.
> >
> >> >> > #2 already has a solution, it's called an init*. Other solutions
> >> >> > exist but none are as elegant as a throwaway temporary filesystem
> >> >> > in RAM.
> >
> >> >> What about just mounting /usr as soon as the system boots?
> >
> >
> >> > Please read the thread next time. The topic under discussion is
> >> > solutions to the problem of not being able to do exactly that.
> >
> >> Then I suppose you can surely explain in a nutshell why can't init
> >> scripts simply do that?
> >
> > Because certain people with influence have rearranged the filesystem so
> > that programs within /usr are absolutely necessary for booting; they are
> > needed _before_ init has a chance to mount /usr.  So either /usr has to
> > be in the root partition, or crazy kludges need to be used to mount /usr
> > before the kernel runs init.
>
> I surely don't know the udev architecture well enough, but if this is
> all done by the udev daemon, can't we just "mount /usr" before the
> daemon is started? The only needed things should be mount (which is
> under /bin here) and /etc/fstab.
>
> Or is something outside udev needing stuff under /usr?

Yes. That's the pivot of the problem.

>
> --
> Nuno Silva (aka njsg)
> http://njsg.sdf-eu.org/
>
>

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

[gentoo-user] Re: Anyone switched to eudev yet?

[Nuno J. Silva]

On 2012-12-23, Michael Mol wrote:

> On Dec 23, 2012 12:46 PM, "Nuno J. Silva" <nunojsilva@ist.utl.pt> wrote:
>>
>> On 2012-12-23, Alan Mackenzie wrote:
>>
>> > On Sun, Dec 23, 2012 at 07:03:25PM +0200, Nuno J. Silva wrote:
>> >> On 2012-12-23, Alan McKinnon wrote:
>> >
>> >> > On Sun, 23 Dec 2012 12:22:24 +0200
>> >> > nunojsilva@ist.utl.pt (Nuno J. Silva) wrote:
>> >
>> >> >> On 2012-12-18, Alan McKinnon wrote:
>> >
>> >> >> > On Tue, 18 Dec 2012 09:08:53 -0500
>> >> >> > Michael Mol <mikemol@gmail.com> wrote:
>> >
>> >
>> >> >> > This sentence summarizes my understanding of your post nicely:
>> >
>> >> >> >> Now, why is /usr special? It's because it contains executable
> code
>> >> >> >> the system might require while launching.
>> >
>> >> >> > Now there are only two approaches that could solve that problem:
>> >
>> >> >> > 1. Avoid it entirely
>> >> >> > 2. Deal with it using any of a variety of bootstrap techniques
>> >
>> >> >> > #1 is handled by policy, whereby any code the system might require
>> >> >> > while launching is not in /usr.
>> >
>> >> >> > #2 already has a solution, it's called an init*. Other solutions
>> >> >> > exist but none are as elegant as a throwaway temporary filesystem
>> >> >> > in RAM.
>> >
>> >> >> What about just mounting /usr as soon as the system boots?
>> >
>> >
>> >> > Please read the thread next time. The topic under discussion is
>> >> > solutions to the problem of not being able to do exactly that.
>> >
>> >> Then I suppose you can surely explain in a nutshell why can't init
>> >> scripts simply do that?
>> >
>> > Because certain people with influence have rearranged the filesystem so
>> > that programs within /usr are absolutely necessary for booting; they are
>> > needed _before_ init has a chance to mount /usr.  So either /usr has to
>> > be in the root partition, or crazy kludges need to be used to mount /usr
>> > before the kernel runs init.
>>
>> I surely don't know the udev architecture well enough, but if this is
>> all done by the udev daemon, can't we just "mount /usr" before the
>> daemon is started? The only needed things should be mount (which is
>> under /bin here) and /etc/fstab.
>>
>> Or is something outside udev needing stuff under /usr?
>
> Yes. That's the pivot of the problem.

What is it?

I tried and I was able to mount a filesystem other than / shortly after
linux has passed control to init, in fact, with no udev stuff running.

-- 
Nuno Silva (aka njsg)
http://njsg.sdf-eu.org/

Re: [gentoo-user] Re: Anyone switched to eudev yet?

[Neil Bothwick]

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

On Sun, 23 Dec 2012 19:44:43 +0200, Nuno J. Silva wrote:

> > Because certain people with influence have rearranged the filesystem
> > so that programs within /usr are absolutely necessary for booting;
> > they are needed _before_ init has a chance to mount /usr.  So
> > either /usr has to be in the root partition, or crazy kludges need to
> > be used to mount /usr before the kernel runs init.  
> 
> I surely don't know the udev architecture well enough, but if this is
> all done by the udev daemon, can't we just "mount /usr" before the
> daemon is started? The only needed things should be mount (which is
> under /bin here) and /etc/fstab.

Because before we can mount thye block device containing the filesystem
for /usr, we have to make that block device available. You are
only considering the case of /usr being on a plain hard disk partition,
what if it in on an LVM volume, or encrypted (or both) of mounted over
the network? All of these require something to be run before they can be
mounted, and if that cannot be run until udev has started, we have been
painted into a corner.


-- 
Neil Bothwick

Top Oxymorons Number 43: Genuine imitation

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

Re: [gentoo-user] Re: Anyone switched to eudev yet?

[Walter Dnes]

On Sun, Dec 23, 2012 at 08:39:41PM +0000, Neil Bothwick wrote

> You are only considering the case of /usr being on a plain hard disk
> partition, what if it in on an LVM volume, or encrypted (or both)
> of mounted over the network? All of these require something to be
> run before they can be mounted, and if that cannot be run until udev
> has started, we have been painted into a corner.

  I agree that there will always be a small number of corner-cases where
an initr* is required.  What annoys me, and probably a lot of other
people, is the-dog-in-the-manger attitude
http://en.wikipedia.org/wiki/The_Dog_in_the_Manger where some people
seem to say "If my weirdo, corner-case system can't boot a separate /usr
without an initr* then, by-golly, I'll see to it that *NOBODY* can boot
a separate /usr without an initr*".

-- 
Walter Dnes <waltdnes@waltdnes.org>
I don't run "desktop environments"; I run useful applications

Re: [gentoo-user] Re: Anyone switched to eudev yet?

[Mark David Dumlao]

On Mon, Dec 24, 2012 at 9:27 AM, Walter Dnes <waltdnes@waltdnes.org> wrote:
> On Sun, Dec 23, 2012 at 08:39:41PM +0000, Neil Bothwick wrote
>
>> You are only considering the case of /usr being on a plain hard disk
>> partition, what if it in on an LVM volume, or encrypted (or both)
>> of mounted over the network? All of these require something to be
>> run before they can be mounted, and if that cannot be run until udev
>> has started, we have been painted into a corner.
>
>   I agree that there will always be a small number of corner-cases where
> an initr* is required.  What annoys me, and probably a lot of other
> people, is the-dog-in-the-manger attitude
> http://en.wikipedia.org/wiki/The_Dog_in_the_Manger where some people
> seem to say "If my weirdo, corner-case system can't boot a separate /usr
> without an initr* then, by-golly, I'll see to it that *NOBODY* can boot
> a separate /usr without an initr*".

This is misleading in two ways.

1) You're talking as if having a functionally merged /usr and / system
(i.e., many programs needed by the sysad to fix a non-booting system
are in /usr, and programs in /usr will break if /usr is not in sync
with /) is a weirdo corner case. It is NOT. It is very likely how the
vast majority of Linux systems on the planet work. Separate /usr is
itself the weirdo corner case. It was in fact a weirdo corner case
since day 1.
2) You're talking as if Lennart or whoever is breaking into your
systems and actively preventing you from customizing it to boot a
separate /usr. If this is the case you _really_ need to change your
ssh keys, they wiped that vulnerability a couple years ago.

Nobody's preventing you from building a custom system that cleanly
separates / and /usr. But hey, don't pretend that even Gentoo does it
correctly. Besides the equery tests in this thread, I've never
personally confirmed that any other distro does - and Fedora cleanly
admits that they don't.

Re: [gentoo-user] Re: Anyone switched to eudev yet?

[Alan McKinnon]

On Mon, 24 Dec 2012 16:06:27 +0800
Mark David Dumlao <madumlao@gmail.com> wrote:

> On Mon, Dec 24, 2012 at 9:27 AM, Walter Dnes <waltdnes@waltdnes.org>
> wrote:
> > On Sun, Dec 23, 2012 at 08:39:41PM +0000, Neil Bothwick wrote
> >
> >> You are only considering the case of /usr being on a plain hard
> >> disk partition, what if it in on an LVM volume, or encrypted (or
> >> both) of mounted over the network? All of these require something
> >> to be run before they can be mounted, and if that cannot be run
> >> until udev has started, we have been painted into a corner.
> >
> >   I agree that there will always be a small number of corner-cases
> > where an initr* is required.  What annoys me, and probably a lot of
> > other people, is the-dog-in-the-manger attitude
> > http://en.wikipedia.org/wiki/The_Dog_in_the_Manger where some people
> > seem to say "If my weirdo, corner-case system can't boot a
> > separate /usr without an initr* then, by-golly, I'll see to it that
> > *NOBODY* can boot a separate /usr without an initr*".
> 
> This is misleading in two ways.
> 
> 1) You're talking as if having a functionally merged /usr and / system
> (i.e., many programs needed by the sysad to fix a non-booting system
> are in /usr, and programs in /usr will break if /usr is not in sync
> with /) is a weirdo corner case. It is NOT. It is very likely how the
> vast majority of Linux systems on the planet work. Separate /usr is
> itself the weirdo corner case. It was in fact a weirdo corner case
> since day 1.
> 2) You're talking as if Lennart or whoever is breaking into your
> systems and actively preventing you from customizing it to boot a
> separate /usr. If this is the case you _really_ need to change your
> ssh keys, they wiped that vulnerability a couple years ago.
> 
> Nobody's preventing you from building a custom system that cleanly
> separates / and /usr. But hey, don't pretend that even Gentoo does it
> correctly. Besides the equery tests in this thread, I've never
> personally confirmed that any other distro does - and Fedora cleanly
> admits that they don't.
> 

The ultimate weird corner case is having a separate / and /usr so the
either of these two thing can happen:

a. there's enough $STUFF in / to fix large-scale errors
b. there's enough $STUFF in / to mount /usr ro over NFS (as in for a
terminal server)


a. is fixed by just using what all sysadmins use anyway - a proper
rescue disk built for that specific purposes (instead of trying to get
half a system to do it for you)

b. is resolved by mounting /, not /usr. It's a terminal server, so the
only thing not under full user control is ~. There is no point in
having half the system local and the rest of it remote, just mount
everything remotely. And if it's a terminal server, it will have a real
sysadmin, someone who can maintain the code needed to get NFS up at
boot time. If the mount of / breaks, the solution is a.

Are there any other cases, apart from emotional attachment based on
inertia, where a separate / and /usr are desirable? As I see it, there
is only the system, and it is an atomic unit.

-- 
Alan McKinnon
alan.mckinnon@gmail.com

Re: [gentoo-user] Re: Anyone switched to eudev yet?

[Kevin Chadwick]

> Are there any other cases, apart from emotional attachment based on
> inertia, where a separate / and /usr are desirable? As I see it, there
> is only the system, and it is an atomic unit.

You should really read the thread before posting.

-- 
_______________________________________________________________________

'Write programs that do one thing and do it well. Write programs to work
together. Write programs to handle text streams, because that is a
universal interface'

(Doug McIlroy)
_______________________________________________________________________

Re: [gentoo-user] Re: Anyone switched to eudev yet?

[Dale]

Kevin Chadwick wrote:
>> Are there any other cases, apart from emotional attachment based on
>> inertia, where a separate / and /usr are desirable? As I see it, there
>> is only the system, and it is an atomic unit.
> You should really read the thread before posting.
>

I suspect that Alan has.  Alan is not known to post without knowing what
he is talking about. 

Dale

:-)  :-) 

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

Re: [gentoo-user] Re: Anyone switched to eudev yet?

[William Kenworthy]

On 24/12/12 23:52, Dale wrote:
> Kevin Chadwick wrote:
>>> Are there any other cases, apart from emotional attachment based on
>>> inertia, where a separate / and /usr are desirable? As I see it, there
>>> is only the system, and it is an atomic unit.
>> You should really read the thread before posting.
>>
> I suspect that Alan has.  Alan is not known to post without knowing what
> he is talking about. 
>
> Dale
>
> :-)  :-) 
>
I used initrd's many years ago, and separate /usr and/ until on a redhat
system I rebooted with an out of sequence initrd and kernel on a
critical server (the sort of thing that puts your employment at risk
when there are 20 odd developers using it ...)

ok, eliminate that point of failure!  I then stopped using init*'s until
recently and surprise, never had an init* failure until this latest
fiasco has caused me to go back to using init*'s. I have had a couple of
failures - mostly to do with complexity and trying to juggle more
items..and missing something.  This is something binary distros are less
prone to than gentoo.  And my workload/system complexity is now higher
as well - all round loss ...

As far as the system being "atomic", that has been one of microsofts
Achilles heals for many years - so tightly integrated one minor failure
takes out everything.  I separate / and /usr, its for reliability AND
flexibility as far as I am concerned - yes I can change what I do, but
why change for something that gives me less?  I use LVM on everything
except laptops and at least a couple of times a year move things
around.  I have had major disasters in /usr that were insulated from the
rest of the system, I can have a system stay up while I do major
changes, so / and /usr as one will be a problem for me.

I can see where Lennart and co are coming from, but their target is not
reliability, flexibility or long term use ... its run on everything, and
throwaway and start again if you want a change - the microsoft approach
if you like.  It seems to be driven by the cloud and a more throwaway
mindset for computing than we are used to, or what gentoo is designed for.

Not all the proposed changes are bad ... a read only /usr would be nice,
but I object to being forced into what I regard as an unreliable
configuration (or use unreliable, crappy software, eg pulse audio!)
because of these changes - and for those who say I have a choice ...
thats correct, my choice will be eudev.

I can see a split coming with two design choices, eudev like with
reliably and flexibility at the core for servers, and a more MS like
desktop approach for RH and the other big distros as they find
themselves being abandoned in the server market.  I suspect the thing to
watch will be where RH Enterprise goes in its next few versions.

So roll on eudev!

(and happy Christmas to those celebrating!)
BillK

Re: [gentoo-user] Re: Anyone switched to eudev yet?

[Neil Bothwick]

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

On Tue, 25 Dec 2012 07:09:49 +0800, William Kenworthy wrote:

> I used initrd's many years ago, and separate /usr and/ until on a redhat
> system I rebooted with an out of sequence initrd and kernel on a
> critical server (the sort of thing that puts your employment at risk
> when there are 20 odd developers using it ...)

That's the main reason I build the initramfs into the kernel rather than
as a separate file. That way you know that each kernel will always
continue to work, you can't screw up the initramfs of a working kernel.


-- 
Neil Bothwick

If Bill Gates had a dime for every time a Windows box crashed...
 ...Oh, wait a minute, he already does.

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

Re: [gentoo-user] Re: Anyone switched to eudev yet?

[Dale]

Neil Bothwick wrote:
> On Tue, 25 Dec 2012 07:09:49 +0800, William Kenworthy wrote:
>
>> I used initrd's many years ago, and separate /usr and/ until on a redhat
>> system I rebooted with an out of sequence initrd and kernel on a
>> critical server (the sort of thing that puts your employment at risk
>> when there are 20 odd developers using it ...)
> That's the main reason I build the initramfs into the kernel rather than
> as a separate file. That way you know that each kernel will always
> continue to work, you can't screw up the initramfs of a working kernel.
>
>


That was my thinking too.  I never got it to work.  I went to plan B
which was dracut.

Dale

:-)  :-) 

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

Re: [gentoo-user] Re: Anyone switched to eudev yet?

[Kevin Chadwick]

On Tue, 25 Dec 2012 07:09:49 +0800
William Kenworthy <billk@iinet.net.au> wrote:

> Not all the proposed changes are bad ... a read only /usr would be
> nice, but I object to being forced into what I regard as an unreliable
> configuration (or use unreliable, crappy software, eg pulse audio!)
> because of these changes - and for those who say I have a choice ...
> thats correct, my choice will be eudev.

A read only /usr is perfectly possible in any case too, especially if
you choose to do things more correctly like avoiding dhcp and as a
bonus it's various security issues of the past.

Re: [gentoo-user] Re: Anyone switched to eudev yet?

[Alan McKinnon]

On Mon, 24 Dec 2012 15:14:11 +0000
Kevin Chadwick <ma1l1ists@yahoo.co.uk> wrote:

> > Are there any other cases, apart from emotional attachment based on
> > inertia, where a separate / and /usr are desirable? As I see it,
> > there is only the system, and it is an atomic unit.
> 
> You should really read the thread before posting.
> 

You quoted a hypothical question I posed[1] which follows directly on
from something I described in the previous paragraph. You should really
retain context in what you decide to snip, as you have changed the
entire meaning and intent of what I said and asked.



[1] The question was literally an RFC - a request for people to
comment. I have no strict engineering or configuration need for /
and /usr to be separate; I know of one setup configuration that
requires it, I asked who needs it for different reasons and
why - not as a debate point, but as a learning point.

Does that sufficiently answer the thought that prompted you to reply?

-- 
Alan McKinnon
alan.mckinnon@gmail.com

Re: [gentoo-user] Re: Anyone switched to eudev yet?

[Neil Bothwick]

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

On Mon, 24 Dec 2012 12:58:57 +0200, Alan McKinnon wrote:

> Are there any other cases, apart from emotional attachment based on
> inertia, where a separate / and /usr are desirable? As I see it, there
> is only the system, and it is an atomic unit.

Yes, you need to run an encrypted root but don't want all the overhead of
encrypting everything in /usr. Someone recently posted some benchmarks
showing how awful an atom's performance can be with encryption, so
this makes good sense with a netbook.

Of course, running an encrypted root means you need an init thingy[tm]
anyway, so there is no problem with mounting /usr from there too.


-- 
Neil Bothwick

There's no place like ~

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

Re: [Bulk] Re: [gentoo-user] Re: Anyone switched to eudev yet?

[Kevin Chadwick]

> It was in fact a weirdo corner case
> since day 1.

Right, a weirdo corner case that is part of best practice and the
default suggestion on debian stable used on many many servers and for
good reason.

-- 
_______________________________________________________________________

'Write programs that do one thing and do it well. Write programs to work
together. Write programs to handle text streams, because that is a
universal interface'

(Doug McIlroy)
_______________________________________________________________________

Re: [gentoo-user] Re: Anyone switched to eudev yet?

[Kevin Chadwick]

> > You are only considering the case of /usr being on a plain hard disk
> > partition, what if it in on an LVM volume, or encrypted (or both)
> > of mounted over the network? All of these require something to be
> > run before they can be mounted, and if that cannot be run until udev
> > has started, we have been painted into a corner.  
> 
>   I agree that there will always be a small number of corner-cases where
> an initr* is required.  What annoys me, and probably a lot of other
> people, is the-dog-in-the-manger attitude
> http://en.wikipedia.org/wiki/The_Dog_in_the_Manger where some people
> seem to say "If my weirdo, corner-case system can't boot a separate /usr
> without an initr* then, by-golly, I'll see to it that *NOBODY* can boot
> a separate /usr without an initr*"

Maybe they should swap names with eudev being for obviously functional
corner cases aka early udev and the current eudev becoming udev by
default as being most correct for most cases. Arguably all cases for a
well designed system.

-- 
_______________________________________________________________________

'Write programs that do one thing and do it well. Write programs to work
together. Write programs to handle text streams, because that is a
universal interface'

(Doug McIlroy)
_______________________________________________________________________

Re: [gentoo-user] Re: Anyone switched to eudev yet?

[Volker Armin Hemmann]

Am Sonntag, 23. Dezember 2012, 19:44:43 schrieb Nuno J. Silva:
> On 2012-12-23, Alan Mackenzie wrote:
> > On Sun, Dec 23, 2012 at 07:03:25PM +0200, Nuno J. Silva wrote:
> >> On 2012-12-23, Alan McKinnon wrote:
> >> > On Sun, 23 Dec 2012 12:22:24 +0200
> >> > 
> >> > nunojsilva@ist.utl.pt (Nuno J. Silva) wrote:
> >> >> On 2012-12-18, Alan McKinnon wrote:
> >> >> > On Tue, 18 Dec 2012 09:08:53 -0500
> >> >> > Michael Mol <mikemol@gmail.com> wrote:
> >> >> > 
> >> >> > This sentence summarizes my understanding of your post nicely:
> >> >> >> Now, why is /usr special? It's because it contains executable code
> >> >> >> the system might require while launching.
> >> >> > 
> >> >> > Now there are only two approaches that could solve that problem:
> >> >> > 
> >> >> > 1. Avoid it entirely
> >> >> > 2. Deal with it using any of a variety of bootstrap techniques
> >> >> > 
> >> >> > #1 is handled by policy, whereby any code the system might require
> >> >> > while launching is not in /usr.
> >> >> > 
> >> >> > #2 already has a solution, it's called an init*. Other solutions
> >> >> > exist but none are as elegant as a throwaway temporary filesystem
> >> >> > in RAM.
> >> >> 
> >> >> What about just mounting /usr as soon as the system boots?
> >> > 
> >> > Please read the thread next time. The topic under discussion is
> >> > solutions to the problem of not being able to do exactly that.
> >> 
> >> Then I suppose you can surely explain in a nutshell why can't init
> >> scripts simply do that?
> > 
> > Because certain people with influence have rearranged the filesystem so
> > that programs within /usr are absolutely necessary for booting; they are
> > needed _before_ init has a chance to mount /usr.  So either /usr has to
> > be in the root partition, or crazy kludges need to be used to mount /usr
> > before the kernel runs init.
> 
> I surely don't know the udev architecture well enough, but if this is
> all done by the udev daemon, can't we just "mount /usr" before the
> daemon is started? The only needed things should be mount (which is
> under /bin here) and /etc/fstab.
> 

and a device node in /dev - like /dev/sda2. And how do you get that one 
without udev?

oops?

-- 
#163933

Re: [gentoo-user] Re: Anyone switched to eudev yet?

[Neil Bothwick]

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

On Thu, 27 Dec 2012 20:43:12 +0100, Volker Armin Hemmann wrote:

> and a device node in /dev - like /dev/sda2. And how do you get that one 
> without udev?

CONFIG_DEVTMPFS=y

Of course, that only helps if /usr is on a plain old disk block device.


-- 
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] Re: Anyone switched to eudev yet?

[Michael Mol]

On Thu, Dec 27, 2012 at 2:43 PM, Volker Armin Hemmann
<volkerarmin@googlemail.com> wrote:
>
> Am Sonntag, 23. Dezember 2012, 19:44:43 schrieb Nuno J. Silva:
> > On 2012-12-23, Alan Mackenzie wrote:
> > > On Sun, Dec 23, 2012 at 07:03:25PM +0200, Nuno J. Silva wrote:
> > >> On 2012-12-23, Alan McKinnon wrote:
> > >> > On Sun, 23 Dec 2012 12:22:24 +0200
> > >> >
> > >> > nunojsilva@ist.utl.pt (Nuno J. Silva) wrote:
> > >> >> On 2012-12-18, Alan McKinnon wrote:
> > >> >> > On Tue, 18 Dec 2012 09:08:53 -0500
> > >> >> > Michael Mol <mikemol@gmail.com> wrote:
> > >> >> >
> > >> >> > This sentence summarizes my understanding of your post nicely:
> > >> >> >> Now, why is /usr special? It's because it contains executable code
> > >> >> >> the system might require while launching.
> > >> >> >
> > >> >> > Now there are only two approaches that could solve that problem:
> > >> >> >
> > >> >> > 1. Avoid it entirely
> > >> >> > 2. Deal with it using any of a variety of bootstrap techniques
> > >> >> >
> > >> >> > #1 is handled by policy, whereby any code the system might require
> > >> >> > while launching is not in /usr.
> > >> >> >
> > >> >> > #2 already has a solution, it's called an init*. Other solutions
> > >> >> > exist but none are as elegant as a throwaway temporary filesystem
> > >> >> > in RAM.
> > >> >>
> > >> >> What about just mounting /usr as soon as the system boots?
> > >> >
> > >> > Please read the thread next time. The topic under discussion is
> > >> > solutions to the problem of not being able to do exactly that.
> > >>
> > >> Then I suppose you can surely explain in a nutshell why can't init
> > >> scripts simply do that?
> > >
> > > Because certain people with influence have rearranged the filesystem so
> > > that programs within /usr are absolutely necessary for booting; they are
> > > needed _before_ init has a chance to mount /usr.  So either /usr has to
> > > be in the root partition, or crazy kludges need to be used to mount /usr
> > > before the kernel runs init.
> >
> > I surely don't know the udev architecture well enough, but if this is
> > all done by the udev daemon, can't we just "mount /usr" before the
> > daemon is started? The only needed things should be mount (which is
> > under /bin here) and /etc/fstab.
> >
>
> and a device node in /dev - like /dev/sda2. And how do you get that one
> without udev?
>
> oops?


Yeah, the "oops" is on the part of the udev team, which decided to put
a critical piece of software there. Which is the origin of this whole
uproar for the past year or so.

--
:wq

Re: [gentoo-user] Re: Anyone switched to eudev yet?

[Nuno J. Silva]

On 2012-12-27, Volker Armin Hemmann wrote:

> Am Sonntag, 23. Dezember 2012, 19:44:43 schrieb Nuno J. Silva:
>> On 2012-12-23, Alan Mackenzie wrote:
>> > On Sun, Dec 23, 2012 at 07:03:25PM +0200, Nuno J. Silva wrote:
>> >> On 2012-12-23, Alan McKinnon wrote:
>> >> > On Sun, 23 Dec 2012 12:22:24 +0200
>> >> > 
>> >> > nunojsilva@ist.utl.pt (Nuno J. Silva) wrote:
>> >> >> On 2012-12-18, Alan McKinnon wrote:
>> >> >> > On Tue, 18 Dec 2012 09:08:53 -0500
>> >> >> > Michael Mol <mikemol@gmail.com> wrote:
>> >> >> > 
>> >> >> > This sentence summarizes my understanding of your post nicely:
>> >> >> >> Now, why is /usr special? It's because it contains executable code
>> >> >> >> the system might require while launching.
>> >> >> > 
>> >> >> > Now there are only two approaches that could solve that problem:
>> >> >> > 
>> >> >> > 1. Avoid it entirely
>> >> >> > 2. Deal with it using any of a variety of bootstrap techniques
>> >> >> > 
>> >> >> > #1 is handled by policy, whereby any code the system might require
>> >> >> > while launching is not in /usr.
>> >> >> > 
>> >> >> > #2 already has a solution, it's called an init*. Other solutions
>> >> >> > exist but none are as elegant as a throwaway temporary filesystem
>> >> >> > in RAM.
>> >> >> 
>> >> >> What about just mounting /usr as soon as the system boots?
>> >> > 
>> >> > Please read the thread next time. The topic under discussion is
>> >> > solutions to the problem of not being able to do exactly that.
>> >> 
>> >> Then I suppose you can surely explain in a nutshell why can't init
>> >> scripts simply do that?
>> > 
>> > Because certain people with influence have rearranged the filesystem so
>> > that programs within /usr are absolutely necessary for booting; they are
>> > needed _before_ init has a chance to mount /usr.  So either /usr has to
>> > be in the root partition, or crazy kludges need to be used to mount /usr
>> > before the kernel runs init.
>> 
>> I surely don't know the udev architecture well enough, but if this is
>> all done by the udev daemon, can't we just "mount /usr" before the
>> daemon is started? The only needed things should be mount (which is
>> under /bin here) and /etc/fstab.
>> 
>
> and a device node in /dev - like /dev/sda2. And how do you get that one 
> without udev?
>
> oops?

Please try booting your system and getting to a shell before udevd gets
started.

Then, please do ls /dev.

-- 
Nuno Silva (aka njsg)
http://njsg.sdf-eu.org/

Re: [gentoo-user] Re: Anyone switched to eudev yet?

[Alan McKinnon]

On Sun, 23 Dec 2012 19:03:25 +0200
nunojsilva@ist.utl.pt (Nuno J. Silva) wrote:

> On 2012-12-23, Alan McKinnon wrote:
> 
> > On Sun, 23 Dec 2012 12:22:24 +0200
> > nunojsilva@ist.utl.pt (Nuno J. Silva) wrote:
> >
> >> On 2012-12-18, Alan McKinnon wrote:
> >> 
> >> > On Tue, 18 Dec 2012 09:08:53 -0500
> >> > Michael Mol <mikemol@gmail.com> wrote:
> >> >
> >> >
> >> > This sentence summarizes my understanding of your post nicely:
> >> >
> >> >> Now, why is /usr special? It's because it contains executable
> >> >> code the system might require while launching.
> >> >
> >> > Now there are only two approaches that could solve that problem:
> >> >
> >> > 1. Avoid it entirely
> >> > 2. Deal with it using any of a variety of bootstrap techniques
> >> >
> >> > #1 is handled by policy, whereby any code the system might
> >> > require while launching is not in /usr.
> >> >
> >> > #2 already has a solution, it's called an init*. Other solutions
> >> > exist but none are as elegant as a throwaway temporary filesystem
> >> > in RAM.
> >> 
> >> What about just mounting /usr as soon as the system boots?
> >
> >
> > Please read the thread next time. The topic under discussion is
> > solutions to the problem of not being able to do exactly that.
> 
> Then I suppose you can surely explain in a nutshell why can't init
> scripts simply do that?
> 

It is trivially easy to create a circular loop whereby code required to
mount /usr now resides on /usr.

Which is the entire thrust of this whole thread.

-- 
Alan McKinnon
alan.mckinnon@gmail.com

Re: [gentoo-user] Re: Anyone switched to eudev yet?

[Dale]

Alan McKinnon wrote:
> On Sun, 23 Dec 2012 19:03:25 +0200
> nunojsilva@ist.utl.pt (Nuno J. Silva) wrote:
>
>> On 2012-12-23, Alan McKinnon wrote:
>>
>>> On Sun, 23 Dec 2012 12:22:24 +0200
>>> nunojsilva@ist.utl.pt (Nuno J. Silva) wrote:
>>>
>>>> On 2012-12-18, Alan McKinnon wrote:
>>>>
>>>>> On Tue, 18 Dec 2012 09:08:53 -0500
>>>>> Michael Mol <mikemol@gmail.com> wrote:
>>>>>
>>>>>
>>>>> This sentence summarizes my understanding of your post nicely:
>>>>>
>>>>>> Now, why is /usr special? It's because it contains executable
>>>>>> code the system might require while launching.
>>>>> Now there are only two approaches that could solve that problem:
>>>>>
>>>>> 1. Avoid it entirely
>>>>> 2. Deal with it using any of a variety of bootstrap techniques
>>>>>
>>>>> #1 is handled by policy, whereby any code the system might
>>>>> require while launching is not in /usr.
>>>>>
>>>>> #2 already has a solution, it's called an init*. Other solutions
>>>>> exist but none are as elegant as a throwaway temporary filesystem
>>>>> in RAM.
>>>> What about just mounting /usr as soon as the system boots?
>>>
>>> Please read the thread next time. The topic under discussion is
>>> solutions to the problem of not being able to do exactly that.
>> Then I suppose you can surely explain in a nutshell why can't init
>> scripts simply do that?
>>
> It is trivially easy to create a circular loop whereby code required to
> mount /usr now resides on /usr.
>
> Which is the entire thrust of this whole thread.
>

When I reboot, I get a lot of errors about /var being empty, since it is
not mounted yet.  It appears it wants /var as well as /usr early on in
the boot process.  It boots regardless of the errors tho.

For the record Nuno, I have / and /boot on regular partitions.  I have
everything else, /home, /usr, /var and /usr/portage on LVM partitions. 
Until recently, I NEVER needed a init thingy and had zero errors while
booting.  Once this 'needing /usr on /' started a few months ago, I was
told I would need one to boot.  The claim being it was broken all the
time but odd that it worked for the last 9 years with no problem, might
add, I only been using Linux for the last 9 years but it also would have
worked before that. 

So, Nuno, everything was fine until they started moving things to a
place where it shouldn't be.  Now, we have people working on eudev which
will replace udev and allow us to boot with a separate /usr and no init
thingy either.  Basically, putting it back like it was, for many years I
might add.  

Dale

:-)  :-)

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

[gentoo-user] Re: Anyone switched to eudev yet?

[Nuno J. Silva]

On 2012-12-24, Dale wrote:

> Alan McKinnon wrote:
>> On Sun, 23 Dec 2012 19:03:25 +0200
>> nunojsilva@ist.utl.pt (Nuno J. Silva) wrote:
>>
>>> On 2012-12-23, Alan McKinnon wrote:
>>>
>>>> On Sun, 23 Dec 2012 12:22:24 +0200
>>>> nunojsilva@ist.utl.pt (Nuno J. Silva) wrote:
[...]
>>>>> What about just mounting /usr as soon as the system boots?
>>>>
>>>> Please read the thread next time. The topic under discussion is
>>>> solutions to the problem of not being able to do exactly that.
>>> Then I suppose you can surely explain in a nutshell why can't init
>>> scripts simply do that?
>>>
>> It is trivially easy to create a circular loop whereby code required to
>> mount /usr now resides on /usr.
>>
>> Which is the entire thrust of this whole thread.
>>
>
> When I reboot, I get a lot of errors about /var being empty, since it is
> not mounted yet.  It appears it wants /var as well as /usr early on in
> the boot process.  It boots regardless of the errors tho.
>
> For the record Nuno, I have / and /boot on regular partitions.  I have
> everything else, /home, /usr, /var and /usr/portage on LVM partitions. 
> Until recently, I NEVER needed a init thingy and had zero errors while
> booting.  Once this 'needing /usr on /' started a few months ago, I was
> told I would need one to boot.  The claim being it was broken all the
> time but odd that it worked for the last 9 years with no problem, might
> add, I only been using Linux for the last 9 years but it also would have
> worked before that. 
>

In your case, does it actually fail without an initrd now? It's just
that I see lots of people saying "it doesn't work" or "it will silently
fail", that's why I asked the question, I was looking for actual
examples of how can this go wrong (other than just because the init
scripts don't try to mount /usr before starting udev).

Also, how does an initrd help solving the chicken-and-the-egg problem
for a missing /usr?

I suppose the LVM drivers create additional device files that are only
created once udevd is up and running in order to process these events?
(With the case of a regular partition being no problem just because
linux apparently offers hardcoded files for some partitions in the first
ATA controllers.)

> So, Nuno, everything was fine until they started moving things to a
> place where it shouldn't be.  Now, we have people working on eudev which
> will replace udev and allow us to boot with a separate /usr and no init
> thingy either.  Basically, putting it back like it was, for many years I
> might add.  

-- 
Nuno Silva (aka njsg)
http://njsg.sdf-eu.org/

Re: [gentoo-user] Re: Anyone switched to eudev yet?

[Dale]

Nuno J. Silva wrote:
> On 2012-12-24, Dale wrote:
>
>> Alan McKinnon wrote:
>>> On Sun, 23 Dec 2012 19:03:25 +0200
>>> nunojsilva@ist.utl.pt (Nuno J. Silva) wrote:
>>>
>>>> On 2012-12-23, Alan McKinnon wrote:
>>>>
>>>>> On Sun, 23 Dec 2012 12:22:24 +0200
>>>>> nunojsilva@ist.utl.pt (Nuno J. Silva) wrote:
> [...]
>>>>>> What about just mounting /usr as soon as the system boots?
>>>>> Please read the thread next time. The topic under discussion is
>>>>> solutions to the problem of not being able to do exactly that.
>>>> Then I suppose you can surely explain in a nutshell why can't init
>>>> scripts simply do that?
>>>>
>>> It is trivially easy to create a circular loop whereby code required to
>>> mount /usr now resides on /usr.
>>>
>>> Which is the entire thrust of this whole thread.
>>>
>> When I reboot, I get a lot of errors about /var being empty, since it is
>> not mounted yet.  It appears it wants /var as well as /usr early on in
>> the boot process.  It boots regardless of the errors tho.
>>
>> For the record Nuno, I have / and /boot on regular partitions.  I have
>> everything else, /home, /usr, /var and /usr/portage on LVM partitions. 
>> Until recently, I NEVER needed a init thingy and had zero errors while
>> booting.  Once this 'needing /usr on /' started a few months ago, I was
>> told I would need one to boot.  The claim being it was broken all the
>> time but odd that it worked for the last 9 years with no problem, might
>> add, I only been using Linux for the last 9 years but it also would have
>> worked before that. 
>>
> In your case, does it actually fail without an initrd now? It's just
> that I see lots of people saying "it doesn't work" or "it will silently
> fail", that's why I asked the question, I was looking for actual
> examples of how can this go wrong (other than just because the init
> scripts don't try to mount /usr before starting udev).
>
> Also, how does an initrd help solving the chicken-and-the-egg problem
> for a missing /usr?
>
> I suppose the LVM drivers create additional device files that are only
> created once udevd is up and running in order to process these events?
> (With the case of a regular partition being no problem just because
> linux apparently offers hardcoded files for some partitions in the first
> ATA controllers.)
>

Well, so far I have stuck with the udev that works without a init
thingy.  I do have a init thingy for when the udev that requires it is
marked stable.  The devs are keeping the udev that requires /usr on /
masked and/or keyworded until everyone is ready.  That was until eudev
was announced.  Now they are also waiting on eudev to get stable so
people can switch to it.  I plan to switch too. 

The problem is this from my understanding.  For decades, any commands or
config files needed to boot Linux had to be in /bin, /sbin, /etc, and/or
/lib.  Those directories were what was needed to boot and anything
needed to boot a system should be installed into one or more of those
directories.  Then someone came up with the idea of putting things into
/usr instead.  When they did that, it broke things.  To me, this change
makes as much sense as putting the mount command is /usr/bin but that is
where some want Linux to go.  I have read where some want to basically
move about everything to /usr but not sure how much traction that is
getting. 

Basically, something that has worked for decades is declared to be
broken all that time and if it wasn't broken, we are going to break it. 

From my understanding, if I upgrade my system to the later version of
udev and bypass the init system, my system will not boot.  I have not
tested the theory but that is what people have been saying.  Not only is
my /usr separate but it is on LVM partitons too. 

Dale

:-)  :-) 

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

[gentoo-user] Re: Anyone switched to eudev yet?

[Nuno J. Silva]

On 2012-12-24, Dale wrote:

> Nuno J. Silva wrote:
>> On 2012-12-24, Dale wrote:
>>
>>> Alan McKinnon wrote:
>>>> On Sun, 23 Dec 2012 19:03:25 +0200
>>>> nunojsilva@ist.utl.pt (Nuno J. Silva) wrote:
>>>>
>>>>> On 2012-12-23, Alan McKinnon wrote:
>>>>>
>>>>>> On Sun, 23 Dec 2012 12:22:24 +0200
>>>>>> nunojsilva@ist.utl.pt (Nuno J. Silva) wrote:
>> [...]
>>>>>>> What about just mounting /usr as soon as the system boots?
>>>>>> Please read the thread next time. The topic under discussion is
>>>>>> solutions to the problem of not being able to do exactly that.
>>>>> Then I suppose you can surely explain in a nutshell why can't init
>>>>> scripts simply do that?
>>>>>
>>>> It is trivially easy to create a circular loop whereby code required to
>>>> mount /usr now resides on /usr.
>>>>
>>>> Which is the entire thrust of this whole thread.
>>>>
>>> When I reboot, I get a lot of errors about /var being empty, since it is
>>> not mounted yet.  It appears it wants /var as well as /usr early on in
>>> the boot process.  It boots regardless of the errors tho.
>>>
>>> For the record Nuno, I have / and /boot on regular partitions.  I have
>>> everything else, /home, /usr, /var and /usr/portage on LVM partitions. 
>>> Until recently, I NEVER needed a init thingy and had zero errors while
>>> booting.  Once this 'needing /usr on /' started a few months ago, I was
>>> told I would need one to boot.  The claim being it was broken all the
>>> time but odd that it worked for the last 9 years with no problem, might
>>> add, I only been using Linux for the last 9 years but it also would have
>>> worked before that. 
>>>
>> In your case, does it actually fail without an initrd now? It's just
>> that I see lots of people saying "it doesn't work" or "it will silently
>> fail", that's why I asked the question, I was looking for actual
>> examples of how can this go wrong (other than just because the init
>> scripts don't try to mount /usr before starting udev).
>>
>> Also, how does an initrd help solving the chicken-and-the-egg problem
>> for a missing /usr?
>>
>> I suppose the LVM drivers create additional device files that are only
>> created once udevd is up and running in order to process these events?
>> (With the case of a regular partition being no problem just because
>> linux apparently offers hardcoded files for some partitions in the first
>> ATA controllers.)
>>
>
> Well, so far I have stuck with the udev that works without a init
> thingy.  I do have a init thingy for when the udev that requires it is
> marked stable.  The devs are keeping the udev that requires /usr on /
> masked and/or keyworded until everyone is ready.  That was until eudev
> was announced.  Now they are also waiting on eudev to get stable so
> people can switch to it.  I plan to switch too. 
>
> The problem is this from my understanding.  For decades, any commands or
> config files needed to boot Linux had to be in /bin, /sbin, /etc, and/or
> /lib.  Those directories were what was needed to boot and anything
> needed to boot a system should be installed into one or more of those
> directories.  Then someone came up with the idea of putting things into
> /usr instead.  When they did that, it broke things.  To me, this change
> makes as much sense as putting the mount command is /usr/bin but that is
> where some want Linux to go.  I have read where some want to basically
> move about everything to /usr but not sure how much traction that is
> getting. 

From my understanding, the problem with udev was that the rules used to
process events may require stuff from /usr. Which is OK, as I think the
rules may even end up executing random executables. And the sole problem
with this is that udev will not wait, it will simply fail in a silent
way when applying rules that require stuff from /usr.

Now, also, from my understanding, this was already the case for some
time (maybe even years?). And that's why I've asked for more details.

So, if the udev you use is OK with no initrd, what is in the new udev
that actually requires the initrd?

Meanwhile, I found https://bugs.gentoo.org/show_bug.cgi?id=446372, which
would explain why, all of a sudden, there is a bigger problem. Now, I
wonder how is this solved with an initrd, by copying udevd there? If so,
why don't we simply install udevd under (or copy its stuff to) / instead
of using /usr as $PREFIX?

> Basically, something that has worked for decades is declared to be
> broken all that time and if it wasn't broken, we are going to break it. 

... yeah... the thing here is that I'm just trying to separate the
upstream comments on "separate /usr is broken" from the actual thing
that breaks the boot process. So far, even the stuff from freedesktop
I've read stating that "separate /usr is broken" do not seem to mention
that udevd is moving to /usr.

> From my understanding, if I upgrade my system to the later version of
> udev and bypass the init system, my system will not boot.  I have not
> tested the theory but that is what people have been saying.  Not only is
> my /usr separate but it is on LVM partitons too. 

Your problem would be LVM (if that's an issue at all, as I said I don't
know LVM), you'd not need udevd to mount /usr if it were a regular
partition.

-- 
Nuno Silva (aka njsg)
http://njsg.sdf-eu.org/

Re: [gentoo-user] Re: Anyone switched to eudev yet?

[Michael Mol]

On Mon, Dec 24, 2012 at 10:06 AM, Nuno J. Silva <nunojsilva@ist.utl.pt> wrote:
> On 2012-12-24, Dale wrote:
>

[snip]

>> Well, so far I have stuck with the udev that works without a init
>> thingy.  I do have a init thingy for when the udev that requires it is
>> marked stable.  The devs are keeping the udev that requires /usr on /
>> masked and/or keyworded until everyone is ready.  That was until eudev
>> was announced.  Now they are also waiting on eudev to get stable so
>> people can switch to it.  I plan to switch too.
>>
>> The problem is this from my understanding.  For decades, any commands or
>> config files needed to boot Linux had to be in /bin, /sbin, /etc, and/or
>> /lib.  Those directories were what was needed to boot and anything
>> needed to boot a system should be installed into one or more of those
>> directories.  Then someone came up with the idea of putting things into
>> /usr instead.  When they did that, it broke things.  To me, this change
>> makes as much sense as putting the mount command is /usr/bin but that is
>> where some want Linux to go.  I have read where some want to basically
>> move about everything to /usr but not sure how much traction that is
>> getting.
>
> From my understanding, the problem with udev was that the rules used to
> process events may require stuff from /usr. Which is OK, as I think the
> rules may even end up executing random executables. And the sole problem
> with this is that udev will not wait, it will simply fail in a silent
> way when applying rules that require stuff from /usr.
>
> Now, also, from my understanding, this was already the case for some
> time (maybe even years?). And that's why I've asked for more details.
>
> So, if the udev you use is OK with no initrd, what is in the new udev
> that actually requires the initrd?
>
> Meanwhile, I found https://bugs.gentoo.org/show_bug.cgi?id=446372, which
> would explain why, all of a sudden, there is a bigger problem.

You found the answer to your own question.

> Now, I
> wonder how is this solved with an initrd, by copying udevd there? If so,
> why don't we simply install udevd under (or copy its stuff to) / instead
> of using /usr as $PREFIX?

An initr* "solves" the problem by copying all tools necessary to
reliably mount /usr to a temporary filesystem loaded at boot (and then
discarded).

As a solution, this 'works'. Opinions differ strongly on:

* The weight of the burden it places on system administrators
* The weight of reliability and security concerns which can arise from
** Increased maintenance complexity
** Having separate copies of tools
** Complications arising from maintaining multiple kernel versions on
a system, and their corresponding supporting initr* tools.
* The elegance of the solution

>
>> Basically, something that has worked for decades is declared to be
>> broken all that time and if it wasn't broken, we are going to break it.
>
> ... yeah... the thing here is that I'm just trying to separate the
> upstream comments on "separate /usr is broken" from the actual thing
> that breaks the boot process. So far, even the stuff from freedesktop
> I've read stating that "separate /usr is broken" do not seem to mention
> that udevd is moving to /usr.

Based on one or two emails on the -dev list (I'm really not sure; that
list has been flying lately, and it's difficult for me to keep up
right now), this may have been an individual action taken by the
gentoo maintainer of udevd based on upstreams declaration that they
don't give a flying frell about separate /usr contexts, and expect
those scenarios to become more and more difficult.

If that's the case, I can understand the maintainer's action; upstream
mailing lists would let things break over time and respond to reports
with "we don't support that configuration". The maintainer, not being
superhuman, brought the problem to the foreground by putting udevd in
a place such that the breakage is more up-front, concentrated and
easier for him to mark reports as WONTFIX.

The eudevd fork is intended to give people whose separate /usr
configurations would fall under WONTFIX territory in udev a place to
go. While there are certain to that cases where separate /usr without
an initr* is fundamentally impossible, there's still a large number of
cases where it ought to work, and more where its failure is the result
of software bugs (either in code or in design).

>
>> From my understanding, if I upgrade my system to the later version of
>> udev and bypass the init system, my system will not boot.  I have not
>> tested the theory but that is what people have been saying.  Not only is
>> my /usr separate but it is on LVM partitons too.
>
> Your problem would be LVM (if that's an issue at all, as I said I don't
> know LVM), you'd not need udevd to mount /usr if it were a regular
> partition.

"you wouldn't have this problem if you did *something else*" is a
terrible response. There are very good reasons to use LVM. There are
good (IMO, at least) reasons to avoid using an initr* on Gentoo.
(Those reasons are sprinkled through the thread, some spoken by me,
some spoken by others.)

You'll find most of the people in the discussion so far aren't against
initr* in all cases. It's the increase in number of cases where it
becomes technically required that's a problem.

--
:wq

[gentoo-user] Re: Anyone switched to eudev yet?

[Nuno J. Silva]

On 2012-12-24, Michael Mol wrote:

> On Mon, Dec 24, 2012 at 10:06 AM, Nuno J. Silva <nunojsilva@ist.utl.pt> wrote:
>> On 2012-12-24, Dale wrote:
>>
[...]
>>> From my understanding, if I upgrade my system to the later version of
>>> udev and bypass the init system, my system will not boot.  I have not
>>> tested the theory but that is what people have been saying.  Not only is
>>> my /usr separate but it is on LVM partitons too.
>>
>> Your problem would be LVM (if that's an issue at all, as I said I don't
>> know LVM), you'd not need udevd to mount /usr if it were a regular
>> partition.
>
> "you wouldn't have this problem if you did *something else*" is a
> terrible response. There are very good reasons to use LVM. There are
> good (IMO, at least) reasons to avoid using an initr* on Gentoo.
> (Those reasons are sprinkled through the thread, some spoken by me,
> some spoken by others.)

A shame that was not what I meant at all, the only thing I said was
"yes, the problem is probably caused by it being on LVM, not because of
/usr being separate". Just pointing the specific part of Dale's config
that would be the problem.

> You'll find most of the people in the discussion so far aren't against
> initr* in all cases. It's the increase in number of cases where it
> becomes technically required that's a problem.

-- 
Nuno Silva (aka njsg)
http://njsg.sdf-eu.org/

Re: [gentoo-user] Re: Anyone switched to eudev yet?

[Michael Mol]

On Mon, Dec 24, 2012 at 10:56 AM, Nuno J. Silva <nunojsilva@ist.utl.pt> wrote:
> On 2012-12-24, Michael Mol wrote:
>
>> On Mon, Dec 24, 2012 at 10:06 AM, Nuno J. Silva <nunojsilva@ist.utl.pt> wrote:
>>> On 2012-12-24, Dale wrote:
>>>
> [...]
>>>> From my understanding, if I upgrade my system to the later version of
>>>> udev and bypass the init system, my system will not boot.  I have not
>>>> tested the theory but that is what people have been saying.  Not only is
>>>> my /usr separate but it is on LVM partitons too.
>>>
>>> Your problem would be LVM (if that's an issue at all, as I said I don't
>>> know LVM), you'd not need udevd to mount /usr if it were a regular
>>> partition.
>>
>> "you wouldn't have this problem if you did *something else*" is a
>> terrible response. There are very good reasons to use LVM. There are
>> good (IMO, at least) reasons to avoid using an initr* on Gentoo.
>> (Those reasons are sprinkled through the thread, some spoken by me,
>> some spoken by others.)
>
> A shame that was not what I meant at all, the only thing I said was
> "yes, the problem is probably caused by it being on LVM, not because of
> /usr being separate". Just pointing the specific part of Dale's config
> that would be the problem.

Miscommunication, then. Happens. :)




--
:wq

Re: [gentoo-user] Re: Anyone switched to eudev yet?

[Dale]

Michael Mol wrote:
> "you wouldn't have this problem if you did *something else*" is a
> terrible response. There are very good reasons to use LVM. There are
> good (IMO, at least) reasons to avoid using an initr* on Gentoo.
> (Those reasons are sprinkled through the thread, some spoken by me,
> some spoken by others.) You'll find most of the people in the
> discussion so far aren't against initr* in all cases. It's the
> increase in number of cases where it becomes technically required
> that's a problem. -- :wq 

You are right on LVM.  I put / on a normal partition specifically
because I wanted to avoid a init thingy.  Only / and /boot are on normal
partitions, everything else is on LVM.  LVM takes a bit to get used to
but when you run out of space or have way to much space, you can move
things around easily. 

LVM is the best move I made in a good while.  Thanks to all the folks
who helped be convert too.  :-D 

Dale

:-)  :-) 

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

Re: [gentoo-user] Re: Anyone switched to eudev yet?

[Dale]

Dale wrote:
> Michael Mol wrote:
>> "you wouldn't have this problem if you did *something else*" is a
>> terrible response. There are very good reasons to use LVM. There are
>> good (IMO, at least) reasons to avoid using an initr* on Gentoo.
>> (Those reasons are sprinkled through the thread, some spoken by me,
>> some spoken by others.) You'll find most of the people in the
>> discussion so far aren't against initr* in all cases. It's the
>> increase in number of cases where it becomes technically required
>> that's a problem. -- :wq 
> You are right on LVM.  I put / on a normal partition specifically
> because I wanted to avoid a init thingy.  Only / and /boot are on normal
> partitions, everything else is on LVM.  LVM takes a bit to get used to
> but when you run out of space or have way to much space, you can move
> things around easily. 
>
> LVM is the best move I made in a good while.  Thanks to all the folks
> who helped be convert too.  :-D 
>
> Dale
>
> :-)  :-) 
>

*me* convert.  I proofed it three times and still missed that.  I'm a
awful typer and getting to be a bad proof reader too.  :/

Dale

:-)  :-) 

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

Re: [gentoo-user] Re: Anyone switched to eudev yet?

[Michael Mol]

On Mon, Dec 24, 2012 at 11:14 AM, Dale <rdalek1967@gmail.com> wrote:
> Dale wrote:
>> Michael Mol wrote:
>>> "you wouldn't have this problem if you did *something else*" is a
>>> terrible response. There are very good reasons to use LVM. There are
>>> good (IMO, at least) reasons to avoid using an initr* on Gentoo.
>>> (Those reasons are sprinkled through the thread, some spoken by me,
>>> some spoken by others.) You'll find most of the people in the
>>> discussion so far aren't against initr* in all cases. It's the
>>> increase in number of cases where it becomes technically required
>>> that's a problem. -- :wq
>> You are right on LVM.  I put / on a normal partition specifically
>> because I wanted to avoid a init thingy.  Only / and /boot are on normal
>> partitions, everything else is on LVM.  LVM takes a bit to get used to
>> but when you run out of space or have way to much space, you can move
>> things around easily.
>>
>> LVM is the best move I made in a good while.  Thanks to all the folks
>> who helped be convert too.  :-D
>>
>> Dale
>>
>> :-)  :-)
>>
>
> *me* convert.  I proofed it three times and still missed that.  I'm a
> awful typer and getting to be a bad proof reader too.  :/
>
> Dale

Lay off the eggnog, Dale. Too early yet. :P

--
:wq

Re: [gentoo-user] Re: Anyone switched to eudev yet?

[Dale]

Michael Mol wrote:
> Lay off the eggnog, Dale. Too early yet. :P -- :wq 

For me it is NyQuil.  I'm still battling the flu.  I'm kicking butt but
getting mine kicked at the same time.  Other than NyQuil, no alcohol here. 

Dale

:-)  :-) 

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

Re: [gentoo-user] Re: Anyone switched to eudev yet?

[Dale]

Nuno J. Silva wrote:
> On 2012-12-24, Dale wrote:
>
>> Nuno J. Silva wrote:
>>> On 2012-12-24, Dale wrote:
>>>
>>>> Alan McKinnon wrote:
>>>>> On Sun, 23 Dec 2012 19:03:25 +0200
>>>>> nunojsilva@ist.utl.pt (Nuno J. Silva) wrote:
>>>>>
>>>>>> On 2012-12-23, Alan McKinnon wrote:
>>>>>>
>>>>>>> On Sun, 23 Dec 2012 12:22:24 +0200
>>>>>>> nunojsilva@ist.utl.pt (Nuno J. Silva) wrote:
>>> [...]
>>>>>>>> What about just mounting /usr as soon as the system boots?
>>>>>>> Please read the thread next time. The topic under discussion is
>>>>>>> solutions to the problem of not being able to do exactly that.
>>>>>> Then I suppose you can surely explain in a nutshell why can't init
>>>>>> scripts simply do that?
>>>>>>
>>>>> It is trivially easy to create a circular loop whereby code required to
>>>>> mount /usr now resides on /usr.
>>>>>
>>>>> Which is the entire thrust of this whole thread.
>>>>>
>>>> When I reboot, I get a lot of errors about /var being empty, since it is
>>>> not mounted yet.  It appears it wants /var as well as /usr early on in
>>>> the boot process.  It boots regardless of the errors tho.
>>>>
>>>> For the record Nuno, I have / and /boot on regular partitions.  I have
>>>> everything else, /home, /usr, /var and /usr/portage on LVM partitions. 
>>>> Until recently, I NEVER needed a init thingy and had zero errors while
>>>> booting.  Once this 'needing /usr on /' started a few months ago, I was
>>>> told I would need one to boot.  The claim being it was broken all the
>>>> time but odd that it worked for the last 9 years with no problem, might
>>>> add, I only been using Linux for the last 9 years but it also would have
>>>> worked before that. 
>>>>
>>> In your case, does it actually fail without an initrd now? It's just
>>> that I see lots of people saying "it doesn't work" or "it will silently
>>> fail", that's why I asked the question, I was looking for actual
>>> examples of how can this go wrong (other than just because the init
>>> scripts don't try to mount /usr before starting udev).
>>>
>>> Also, how does an initrd help solving the chicken-and-the-egg problem
>>> for a missing /usr?
>>>
>>> I suppose the LVM drivers create additional device files that are only
>>> created once udevd is up and running in order to process these events?
>>> (With the case of a regular partition being no problem just because
>>> linux apparently offers hardcoded files for some partitions in the first
>>> ATA controllers.)
>>>
>> Well, so far I have stuck with the udev that works without a init
>> thingy.  I do have a init thingy for when the udev that requires it is
>> marked stable.  The devs are keeping the udev that requires /usr on /
>> masked and/or keyworded until everyone is ready.  That was until eudev
>> was announced.  Now they are also waiting on eudev to get stable so
>> people can switch to it.  I plan to switch too. 
>>
>> The problem is this from my understanding.  For decades, any commands or
>> config files needed to boot Linux had to be in /bin, /sbin, /etc, and/or
>> /lib.  Those directories were what was needed to boot and anything
>> needed to boot a system should be installed into one or more of those
>> directories.  Then someone came up with the idea of putting things into
>> /usr instead.  When they did that, it broke things.  To me, this change
>> makes as much sense as putting the mount command is /usr/bin but that is
>> where some want Linux to go.  I have read where some want to basically
>> move about everything to /usr but not sure how much traction that is
>> getting. 
> >From my understanding, the problem with udev was that the rules used to
> process events may require stuff from /usr. Which is OK, as I think the
> rules may even end up executing random executables. And the sole problem
> with this is that udev will not wait, it will simply fail in a silent
> way when applying rules that require stuff from /usr.
>
> Now, also, from my understanding, this was already the case for some
> time (maybe even years?). And that's why I've asked for more details.

That's the claim but LOTS of people disagree on that.  Keep in mind,
right now, as my system is, I can boot with /usr on a LVM partition and
NO init thingy.  If it is broken, why does it work now?  Why has it
worked from the last 9 years and worked years before that for literally
millions of other Linux users? 

>
> So, if the udev you use is OK with no initrd, what is in the new udev
> that actually requires the initrd?

From my understanding there are files in /usr that are needed for udev
to work while booting.  If udev doesn't have those files, it doesn't
work and the system doesn't boot as it should. 

>
> Meanwhile, I found https://bugs.gentoo.org/show_bug.cgi?id=446372, which
> would explain why, all of a sudden, there is a bigger problem. Now, I
> wonder how is this solved with an initrd, by copying udevd there? If so,
> why don't we simply install udevd under (or copy its stuff to) / instead
> of using /usr as $PREFIX?
>
>> Basically, something that has worked for decades is declared to be
>> broken all that time and if it wasn't broken, we are going to break it. 
> ... yeah... the thing here is that I'm just trying to separate the
> upstream comments on "separate /usr is broken" from the actual thing
> that breaks the boot process. So far, even the stuff from freedesktop
> I've read stating that "separate /usr is broken" do not seem to mention
> that udevd is moving to /usr.

You can't really separate the two.  Upstream is causing this.  You can't
remove upstream and then understand what is going on. 

>
>> From my understanding, if I upgrade my system to the later version of
>> udev and bypass the init system, my system will not boot.  I have not
>> tested the theory but that is what people have been saying.  Not only is
>> my /usr separate but it is on LVM partitons too. 
> Your problem would be LVM (if that's an issue at all, as I said I don't
> know LVM), you'd not need udevd to mount /usr if it were a regular
> partition.
>

The problem isn't LVM, it is files in /usr that have historically been
in / instead.  As I said above, I have been using LVM for several years
with no init thingy and it booted just fine.  Only when upstream started
moving things to /usr instead of / did this problem come along.  Keep in
mind, when booting Linux, everything should be in /bin, /sbin, /etc or
/lib which should be on the / partition.  All other partitions, /home,
/usr, /var and such can be mounted separately for either space
limitations or security reasons or even over a network. 

Dale

:-)  :-) 

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

Re: [gentoo-user] Re: Anyone switched to eudev yet?

[Bruce Hill]

On Mon, Dec 24, 2012 at 05:06:41PM +0200, Nuno J. Silva wrote:
> 
> Now, also, from my understanding, this was already the case for some
> time (maybe even years?). And that's why I've asked for more details.
> 
> So, if the udev you use is OK with no initrd, what is in the new udev
> that actually requires the initrd?

"eselect news read" is yore freeeend ;)

2012-03-16-udev-181-unmasking
  Title                     udev-181 unmasking
  Author                    William Hubbs <williamh@gentoo.org>
  Posted                    2012-03-16
  Revision                  1

udev-181 is being unmasked on 2012-03-19.

This news item is to inform you that once you upgrade to a version of
udev >=181, if you have /usr on a separate partition, you must boot your
system with an initramfs which pre-mounts /usr.

An initramfs which does this is created by
>=sys-kernel/genkernel-3.4.25.1 or
>=sys-kernel/dracut-017-r1. If you do not want to use these tools, be
sure any initramfs you create pre-mounts /usr.

Also, if you are using OpenRC, you must upgrade to >= openrc-0.9.9.

For more information on why this has been done, see the following URL:
http://freedesktop.org/wiki/Software/systemd/separate-usr-is-broken

You can read that systemd is *THE* problem, not udev, and that until the
primma donnas fubared udev by jamming systemd into it, There Was No Such
Problem (TM).

And that explains where the train jumped the track...
-- 
Happy Penguin Computers               >')
126 Fenco Drive                       ( \
Tupelo, MS 38801                       ^^
support@happypenguincomputers.com
662-269-2706 662-205-6424
http://happypenguincomputers.com/

Don't top-post: http://en.wikipedia.org/wiki/Top_post#Top-posting

Re: [gentoo-user] Re: Anyone switched to eudev yet?

[Pandu Poluan]

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

On Dec 24, 2012 11:46 PM, "Bruce Hill" <daddy@happypenguincomputers.com>
wrote:
>
> On Mon, Dec 24, 2012 at 05:06:41PM +0200, Nuno J. Silva wrote:
> >
> > Now, also, from my understanding, this was already the case for some
> > time (maybe even years?). And that's why I've asked for more details.
> >
> > So, if the udev you use is OK with no initrd, what is in the new udev
> > that actually requires the initrd?
>
> "eselect news read" is yore freeeend ;)
>
> 2012-03-16-udev-181-unmasking
>   Title                     udev-181 unmasking
>   Author                    William Hubbs <williamh@gentoo.org>
>   Posted                    2012-03-16
>   Revision                  1
>
> udev-181 is being unmasked on 2012-03-19.
>
> This news item is to inform you that once you upgrade to a version of
> udev >=181, if you have /usr on a separate partition, you must boot your
> system with an initramfs which pre-mounts /usr.
>
> An initramfs which does this is created by
> >=sys-kernel/genkernel-3.4.25.1 or
> >=sys-kernel/dracut-017-r1. If you do not want to use these tools, be
> sure any initramfs you create pre-mounts /usr.
>
> Also, if you are using OpenRC, you must upgrade to >= openrc-0.9.9.
>
> For more information on why this has been done, see the following URL:
> http://freedesktop.org/wiki/Software/systemd/separate-usr-is-broken
>
> You can read that systemd is *THE* problem, not udev, and that until the
> primma donnas fubared udev by jamming systemd into it, There Was No Such
> Problem (TM).
>
> And that explains where the train jumped the track...
>

BINGO!

I'm an Enterprise SysAdmin, and for me things that happen 'at the same
time' with 'details hidden because it clutters the screen' means lost
weekends trying to figure out what went wrong during boot.

I absolutely *love* OpenRC for it clearly, explicitly shows what steps took
place during initialization. I dislike Upstart, but I hate SystemD.

An init is exactly that : INITial system state. Not something that wants to
be-all and end-all like systemd.

That is exactly the reason when udev started to drift -- no, *veer* --
towards systemd, I embraced Walter Dnes' solution of mdev.

Sorry if slightly off-topic.

Rgds,
--

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

[gentoo-user] Re: Anyone switched to eudev yet?

[Nuno J. Silva]

On 2012-12-24, Bruce Hill wrote:

> On Mon, Dec 24, 2012 at 05:06:41PM +0200, Nuno J. Silva wrote:
>> 
>> Now, also, from my understanding, this was already the case for some
>> time (maybe even years?). And that's why I've asked for more details.
>> 
>> So, if the udev you use is OK with no initrd, what is in the new udev
>> that actually requires the initrd?
>
> "eselect news read" is yore freeeend ;)
>
> 2012-03-16-udev-181-unmasking
>   Title                     udev-181 unmasking
>   Author                    William Hubbs <williamh@gentoo.org>
>   Posted                    2012-03-16
>   Revision                  1
>
> udev-181 is being unmasked on 2012-03-19.
>
> This news item is to inform you that once you upgrade to a version of
> udev >=181, if you have /usr on a separate partition, you must boot your
> system with an initramfs which pre-mounts /usr.
>
> An initramfs which does this is created by
>>=sys-kernel/genkernel-3.4.25.1 or
>>=sys-kernel/dracut-017-r1. If you do not want to use these tools, be
> sure any initramfs you create pre-mounts /usr.
>
> Also, if you are using OpenRC, you must upgrade to >= openrc-0.9.9.
>
> For more information on why this has been done, see the following URL:
> http://freedesktop.org/wiki/Software/systemd/separate-usr-is-broken
>
> You can read that systemd is *THE* problem, not udev, and that until the
> primma donnas fubared udev by jamming systemd into it, There Was No Such
> Problem (TM).
>
> And that explains where the train jumped the track...

No, actually it doesn't. It just has the same kind of very generic claim
that has been repeated several times in this thread (which is "why?
because it won't work") and links to an article that explains why some
udev rules would silently fail for all this time (for *years* now, I'd
guess). 

The article does not describe a change introduced with 181, it describes
what already happened with previous versions. I am not using >= 181 and
I do see the issues the article mentions (it does not break here because
I do not have a separate /usr, but I can see some rules that use stuff
from /usr).

-- 
Nuno Silva (aka njsg)
http://njsg.sdf-eu.org/

Re: [gentoo-user] Re: Anyone switched to eudev yet?

[Bruce Hill]

On Tue, Dec 25, 2012 at 02:10:28PM +0200, Nuno J. Silva wrote:
> 
> No, actually it doesn't. It just has the same kind of very generic claim
> that has been repeated several times in this thread (which is "why?
> because it won't work") and links to an article that explains why some
> udev rules would silently fail for all this time (for *years* now, I'd
> guess). 
> 
> The article does not describe a change introduced with 181, it describes
> what already happened with previous versions. I am not using >= 181 and
> I do see the issues the article mentions (it does not break here because
> I do not have a separate /usr, but I can see some rules that use stuff
> from /usr).

You have such an obvious lack of understanding, and problem comprehending
English, we just don't need to post to you anymore. ;)
-- 
Happy Penguin Computers               >')
126 Fenco Drive                       ( \
Tupelo, MS 38801                       ^^
support@happypenguincomputers.com
662-269-2706 662-205-6424
http://happypenguincomputers.com/

Don't top-post: http://en.wikipedia.org/wiki/Top_post#Top-posting

[gentoo-user] Re: Anyone switched to eudev yet?

[Nuno J. Silva]

On 2012-12-25, Bruce Hill wrote:

> On Tue, Dec 25, 2012 at 02:10:28PM +0200, Nuno J. Silva wrote:
>> 
>> No, actually it doesn't. It just has the same kind of very generic claim
>> that has been repeated several times in this thread (which is "why?
>> because it won't work") and links to an article that explains why some
>> udev rules would silently fail for all this time (for *years* now, I'd
>> guess). 
>> 
>> The article does not describe a change introduced with 181, it describes
>> what already happened with previous versions. I am not using >= 181 and
>> I do see the issues the article mentions (it does not break here because
>> I do not have a separate /usr, but I can see some rules that use stuff
>> from /usr).
>
> You have such an obvious lack of understanding, and problem comprehending
> English, we just don't need to post to you anymore. ;)

Please be my guest and explain me in which part of that article is it
said that some behavior *introduced in udev-181* will break systems with
a separate /usr.


-- 
Nuno Silva (aka njsg)
http://njsg.sdf-eu.org/

Re: [gentoo-user] Re: Anyone switched to eudev yet?

[Dale]

Nuno J. Silva wrote:
> On 2012-12-25, Bruce Hill wrote:
>
>> On Tue, Dec 25, 2012 at 02:10:28PM +0200, Nuno J. Silva wrote:
>>> No, actually it doesn't. It just has the same kind of very generic claim
>>> that has been repeated several times in this thread (which is "why?
>>> because it won't work") and links to an article that explains why some
>>> udev rules would silently fail for all this time (for *years* now, I'd
>>> guess). 
>>>
>>> The article does not describe a change introduced with 181, it describes
>>> what already happened with previous versions. I am not using >= 181 and
>>> I do see the issues the article mentions (it does not break here because
>>> I do not have a separate /usr, but I can see some rules that use stuff
>>> from /usr).
>> You have such an obvious lack of understanding, and problem comprehending
>> English, we just don't need to post to you anymore. ;)
> Please be my guest and explain me in which part of that article is it
> said that some behavior *introduced in udev-181* will break systems with
> a separate /usr.
>
>

Quoting from Gentoo news item:

root@fireball / # eselect news read 2
2012-03-16-udev-181-unmasking
  Title                     udev-181 unmasking
  Author                    William Hubbs <williamh@gentoo.org>
  Posted                    2012-03-16
  Revision                  1

udev-181 is being unmasked on 2012-03-19.

This news item is to inform you that once you upgrade to a version of
udev >=181, if you have /usr on a separate partition, you must boot your
system with an initramfs which pre-mounts /usr.

An initramfs which does this is created by
>=sys-kernel/genkernel-3.4.25.1 or
>=sys-kernel/dracut-017-r1. If you do not want to use these tools, be
sure any initramfs you create pre-mounts /usr.

Also, if you are using OpenRC, you must upgrade to >= openrc-0.9.9.

For more information on why this has been done, see the following URL:
http://freedesktop.org/wiki/Software/systemd/separate-usr-is-broken

root@fireball / #

Now are you saying the Gentoo devs are lying to us?  Careful now.  Could
end up on a slippery slope and bump your head. That says anything BEFORE
181 boots fine with a separate /usr, 181 or anything after does not. 
Simple enough for you yet? 

I might add, I have ALWAYS had a separate /usr.  Darn near a decade
now.  It has never failed to boot because /usr was on a separate
partition.  NOT ONCE.  Now I am told it is going to fail.  Go figure. 
Go try to tell me that it was broken all these years.  Yea, right. 
That's like telling me the Sun comes up in the west when I can see it
doesn't with my own two eyes.  Good luck with that.  Reminds me of
that"tell it to the hand" thing.  ROFL

Dale

:-)  :-) 

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

[gentoo-user] Re: Anyone switched to eudev yet?

[Nuno J. Silva]

On 2012-12-25, Dale wrote:

> Nuno J. Silva wrote:
>> On 2012-12-25, Bruce Hill wrote:
>>
>>> On Tue, Dec 25, 2012 at 02:10:28PM +0200, Nuno J. Silva wrote:
>>>> No, actually it doesn't. It just has the same kind of very generic claim
>>>> that has been repeated several times in this thread (which is "why?
>>>> because it won't work") and links to an article that explains why some
>>>> udev rules would silently fail for all this time (for *years* now, I'd
>>>> guess). 
>>>>
>>>> The article does not describe a change introduced with 181, it describes
>>>> what already happened with previous versions. I am not using >= 181 and
>>>> I do see the issues the article mentions (it does not break here because
>>>> I do not have a separate /usr, but I can see some rules that use stuff
>>>> from /usr).
>>> You have such an obvious lack of understanding, and problem comprehending
>>> English, we just don't need to post to you anymore. ;)
>> Please be my guest and explain me in which part of that article is it
>> said that some behavior *introduced in udev-181* will break systems with
>> a separate /usr.
>>
>>
>
> Quoting from Gentoo news item:

Which was exactly the thing I was commenting on above, ok.

[...]
> Now are you saying the Gentoo devs are lying to us?  Careful now.  Could
> end up on a slippery slope and bump your head. That says anything BEFORE
> 181 boots fine with a separate /usr, 181 or anything after does not. 
> Simple enough for you yet?

It does indeed say that, but fails to provide any explanation on *why*.

And, the exact point I made above is that the URL they give points to an
explanation on something completely unrelated to the issue the news item
is about.

Further, that news item *claims* that booting with a separate /usr will
break with >=udev-181. So far, *nobody* was able to explain why that
would happen, not even that news item. The only thing people have been
able to do on this mailing list regarding this news item is "here it is,
that's why it will break".

Allow me to exemplify the exchange you and others are making here

10: A: ">=udev-181 will break boots with separate /usr"
20: B: "Why?"
30: A: "Because >=udev-181 will break boots with separate /usr"
40: B: "But why?"
50: A: "Because we say so"
60: GOTO 20

I don't have any reason to believe anyone is lying, and that's why,
instead of accusing people of lying, I decided to simply ask people here
for some explanations.

Now if the answers I've got here make me believe this whole udev mess is
more about someone saying it will break and everybody blindly believing
it does break. Regardless of whether it actually breaks or not.


>
> I might add, I have ALWAYS had a separate /usr.  Darn near a decade
> now.  It has never failed to boot because /usr was on a separate
> partition.  NOT ONCE.  Now I am told it is going to fail.  Go figure. 
> Go try to tell me that it was broken all these years.  Yea, right. 

Would it be too much trouble to ask you to share the output of

  egrep 'usb-db|pci-db|FROM_DATABASE|/usr' /*/udev/rules.d/*

and the version of udev you're running? I'm curious to see. Of course
that, if you don't have some packages installing their udev rules, you
may not have the issue at all. But maybe you have, so why don't we give
it a try?

Also, if you actually read the linked URL, it does explain it won't fail
to boot. You do realize these are two different issues here, right? One
is people saying that udev-181 will fail to boot, other is the issue
described on the URL linked on the news item, which is about stuff in
/usr breaking udev rules, which has been around for a long time and will
*silently* fail. I remind you that "silently fail" implies that your
system will still boot, even if it is affected by the issue.

> That's like telling me the Sun comes up in the west when I can see it
> doesn't with my own two eyes.  Good luck with that.  Reminds me of
> that"tell it to the hand" thing.  ROFL

-- 
Nuno Silva (aka njsg)
http://njsg.sdf-eu.org/

Re: [gentoo-user] Re: Anyone switched to eudev yet?

[Dale]

Nuno J. Silva wrote:
> On 2012-12-25, Dale wrote:
>
>>
>> Quoting from Gentoo news item:
> Which was exactly the thing I was commenting on above, ok.
>
> [...]
>> Now are you saying the Gentoo devs are lying to us?  Careful now.  Could
>> end up on a slippery slope and bump your head. That says anything BEFORE
>> 181 boots fine with a separate /usr, 181 or anything after does not. 
>> Simple enough for you yet?
> It does indeed say that, but fails to provide any explanation on *why*.
>
> And, the exact point I made above is that the URL they give points to an
> explanation on something completely unrelated to the issue the news item
> is about.
>
> Further, that news item *claims* that booting with a separate /usr will
> break with >=udev-181. So far, *nobody* was able to explain why that
> would happen, not even that news item. The only thing people have been
> able to do on this mailing list regarding this news item is "here it is,
> that's why it will break".
>
> Allow me to exemplify the exchange you and others are making here
>
> 10: A: ">=udev-181 will break boots with separate /usr"
> 20: B: "Why?"
> 30: A: "Because >=udev-181 will break boots with separate /usr"
> 40: B: "But why?"
> 50: A: "Because we say so"
> 60: GOTO 20
>
> I don't have any reason to believe anyone is lying, and that's why,
> instead of accusing people of lying, I decided to simply ask people here
> for some explanations.
>
> Now if the answers I've got here make me believe this whole udev mess is
> more about someone saying it will break and everybody blindly believing
> it does break. Regardless of whether it actually breaks or not.
>
>
>> I might add, I have ALWAYS had a separate /usr.  Darn near a decade
>> now.  It has never failed to boot because /usr was on a separate
>> partition.  NOT ONCE.  Now I am told it is going to fail.  Go figure. 
>> Go try to tell me that it was broken all these years.  Yea, right. 
> Would it be too much trouble to ask you to share the output of
>
>   egrep 'usb-db|pci-db|FROM_DATABASE|/usr' /*/udev/rules.d/*
>
> and the version of udev you're running? I'm curious to see. Of course
> that, if you don't have some packages installing their udev rules, you
> may not have the issue at all. But maybe you have, so why don't we give
> it a try?
>
> Also, if you actually read the linked URL, it does explain it won't fail
> to boot. You do realize these are two different issues here, right? One
> is people saying that udev-181 will fail to boot, other is the issue
> described on the URL linked on the news item, which is about stuff in
> /usr breaking udev rules, which has been around for a long time and will
> *silently* fail. I remind you that "silently fail" implies that your
> system will still boot, even if it is affected by the issue.

root@fireball / # egrep 'usb-db|pci-db|FROM_DATABASE|/usr' /*/udev/rules.d/*
/lib64/udev/rules.d/10-dm.rules:# Set proper sbin path, /sbin has higher
priority than /usr/sbin.
/lib64/udev/rules.d/10-dm.rules:TEST!="$env{DM_SBIN_PATH}/dmsetup",
ENV{DM_SBIN_PATH}="/usr/sbin"
/lib64/udev/rules.d/56-hpmud_add_printer.rules:SUBSYSTEM=="usb",
ENV{DEVTYPE}=="usb_device", ATTRS{idVendor}=="03f0",
ATTRS{idProduct}=="????", PROGRAM="/bin/sh -c 'logger -p user.info
loading HP Device $env{BUSNUM} $env{DEVNUM}'", RUN+="/bin/sh -c
'/usr/bin/hp-config_usb_printer $env{BUSNUM}:$env{DEVNUM} &'"
/lib64/udev/rules.d/56-hpmud_add_printer.rules:SUBSYSTEM=="usb_device",
ATTRS{idVendor}=="03f0", ATTRS{idProduct}=="????", PROGRAM="/bin/sh -c
'X=%k; X=$${X#usbdev}; B=$${X%%%%.*}; D=$${X#*.}; logger -p user.info
loading HP Device $$B $$D; printf %%03i:%%03i $$B $$D'", RUN+="/bin/sh
-c '/usr/bin/hp-config_usb_printer %c &'"
/lib64/udev/rules.d/56-hpmud_support.rules:ATTRS{idVendor}=="03f0",
ATTRS{idProduct}=="??17", RUN+="/bin/sh -c 'hp_model=%E{ID_MODEL}
/usr/bin/hp-mkuri -c &'"
/lib64/udev/rules.d/56-hpmud_support.rules:ATTRS{idVendor}=="03f0",
ATTRS{idProduct}=="??2a", RUN+="/bin/sh -c 'hp_model=%E{ID_MODEL}
/usr/bin/hp-mkuri -c &'"
/lib64/udev/rules.d/56-hpmud_support.rules:ENV{hp_test}=="yes",
RUN+="/bin/sh -c '/usr/bin/hp-mkuri -c &'"
/lib64/udev/rules.d/75-net-description.rules:SUBSYSTEMS=="usb",
ENV{ID_MODEL_FROM_DATABASE}=="", IMPORT{program}="usb-db %p"
/lib64/udev/rules.d/75-net-description.rules:SUBSYSTEMS=="pci",
ENV{ID_MODEL_FROM_DATABASE}=="", IMPORT{program}="pci-db %p"
/lib64/udev/rules.d/75-tty-description.rules:SUBSYSTEMS=="usb",
ENV{ID_MODEL_FROM_DATABASE}=="", IMPORT{program}="usb-db %p"
/lib64/udev/rules.d/75-tty-description.rules:SUBSYSTEMS=="pci",
ENV{ID_MODEL_FROM_DATABASE}=="", IMPORT{program}="pci-db %p"
/lib64/udev/rules.d/78-sound-card.rules:SUBSYSTEMS=="usb",
ENV{ID_VENDOR_FROM_DATABASE}=="", IMPORT{program}="usb-db %p"
/lib64/udev/rules.d/78-sound-card.rules:SUBSYSTEMS=="pci",
ENV{ID_VENDOR_FROM_DATABASE}=="", IMPORT{program}="pci-db %p"
/lib64/udev/rules.d/78-sound-card.rules:ENV{ID_MODEL_FROM_DATABASE}=="*[Ss]peaker*",
ENV{SOUND_FORM_FACTOR}="speaker", GOTO="sound_end"
/lib64/udev/rules.d/78-sound-card.rules:ENV{ID_MODEL_FROM_DATABASE}=="*[Hh]eadphone*",
ENV{SOUND_FORM_FACTOR}="headphone", GOTO="sound_end"
/lib64/udev/rules.d/78-sound-card.rules:ENV{ID_MODEL_FROM_DATABASE}=="*[Hh]eadset*",
ENV{SOUND_FORM_FACTOR}="headset", GOTO="sound_end"
/lib64/udev/rules.d/78-sound-card.rules:ENV{ID_MODEL_FROM_DATABASE}=="*[Hh]andset*",
ENV{SOUND_FORM_FACTOR}="handset", GOTO="sound_end"
/lib64/udev/rules.d/78-sound-card.rules:ENV{ID_MODEL_FROM_DATABASE}=="*[Mm]icrophone*",
ENV{SOUND_FORM_FACTOR}="microphone", GOTO="sound_end"
/lib64/udev/rules.d/80-udisks.rules:SUBSYSTEM=="pci",
ACTION=="add|change", ENV{ID_MODEL_FROM_DATABASE}=="",
ATTR{class}=="0x01*", IMPORT{program}="pci-db %p"
/lib64/udev/rules.d/86-hpmud_plugin.rules:SUBSYSTEM=="usb",
ENV{DEVTYPE}=="usb_device", ATTRS{idVendor}=="03f0",
ATTRS{idProduct}=="??17", PROGRAM="/bin/sh -c 'logger -p user.info
loading hp_printer_device $env{BUSNUM} $env{DEVNUM}'", RUN+="/bin/sh -c
'/usr/bin/python /usr/bin/hp-check-plugin -m $env{BUSNUM}:$env{DEVNUM} &'"
/lib64/udev/rules.d/86-hpmud_plugin.rules:SUBSYSTEM=="usb",
ENV{DEVTYPE}=="usb_device", ATTRS{idVendor}=="03f0",
ATTRS{idProduct}=="??2a", PROGRAM="/bin/sh -c 'logger -p user.info
loading hp_printer_device $env{BUSNUM} $env{DEVNUM}'", RUN+="/bin/sh -c
'/usr/bin/python /usr/bin/hp-check-plugin -m $env{BUSNUM}:$env{DEVNUM}&'"
/lib64/udev/rules.d/86-hpmud_plugin.rules:SUBSYSTEM=="usb",
ENV{DEVTYPE}=="usb_device", ATTRS{idVendor}=="03f0",
ATTRS{idProduct}=="??17", PROGRAM="/bin/sh -c 'X=%k; X=$${X#usbdev};
B=$${X%%%%.*}; D=$${X#*.}; logger -p user.info loading HP Device $$B
$$D; printf %%03i:%%03i $$B $$D'", RUN+="/bin/sh -c '/usr/bin/python
/usr/bin/hp-check-plugin -m %c &'"
/lib64/udev/rules.d/86-hpmud_plugin.rules:SUBSYSTEM=="usb",
ENV{DEVTYPE}=="usb_device", ATTRS{idVendor}=="03f0",
ATTRS{idProduct}=="??2a", PROGRAM="/bin/sh -c 'X=%k; X=$${X#usbdev};
B=$${X%%%%.*}; D=$${X#*.}; logger -p user.info loading HP Device $$B
$$D; printf %%03i:%%03i $$B $$D'", RUN+="/bin/sh -c '/usr/bin/python
/usr/bin/hp-check-plugin -m %c &'"
/lib64/udev/rules.d/90-alsa-restore.rules:       
RUN+="/usr/sbin/alsactl restore $attr{number}"
/lib/udev/rules.d/10-dm.rules:# Set proper sbin path, /sbin has higher
priority than /usr/sbin.
/lib/udev/rules.d/10-dm.rules:TEST!="$env{DM_SBIN_PATH}/dmsetup",
ENV{DM_SBIN_PATH}="/usr/sbin"
/lib/udev/rules.d/56-hpmud_add_printer.rules:SUBSYSTEM=="usb",
ENV{DEVTYPE}=="usb_device", ATTRS{idVendor}=="03f0",
ATTRS{idProduct}=="????", PROGRAM="/bin/sh -c 'logger -p user.info
loading HP Device $env{BUSNUM} $env{DEVNUM}'", RUN+="/bin/sh -c
'/usr/bin/hp-config_usb_printer $env{BUSNUM}:$env{DEVNUM} &'"
/lib/udev/rules.d/56-hpmud_add_printer.rules:SUBSYSTEM=="usb_device",
ATTRS{idVendor}=="03f0", ATTRS{idProduct}=="????", PROGRAM="/bin/sh -c
'X=%k; X=$${X#usbdev}; B=$${X%%%%.*}; D=$${X#*.}; logger -p user.info
loading HP Device $$B $$D; printf %%03i:%%03i $$B $$D'", RUN+="/bin/sh
-c '/usr/bin/hp-config_usb_printer %c &'"
/lib/udev/rules.d/56-hpmud_support.rules:ATTRS{idVendor}=="03f0",
ATTRS{idProduct}=="??17", RUN+="/bin/sh -c 'hp_model=%E{ID_MODEL}
/usr/bin/hp-mkuri -c &'"
/lib/udev/rules.d/56-hpmud_support.rules:ATTRS{idVendor}=="03f0",
ATTRS{idProduct}=="??2a", RUN+="/bin/sh -c 'hp_model=%E{ID_MODEL}
/usr/bin/hp-mkuri -c &'"
/lib/udev/rules.d/56-hpmud_support.rules:ENV{hp_test}=="yes",
RUN+="/bin/sh -c '/usr/bin/hp-mkuri -c &'"
/lib/udev/rules.d/75-net-description.rules:SUBSYSTEMS=="usb",
ENV{ID_MODEL_FROM_DATABASE}=="", IMPORT{program}="usb-db %p"
/lib/udev/rules.d/75-net-description.rules:SUBSYSTEMS=="pci",
ENV{ID_MODEL_FROM_DATABASE}=="", IMPORT{program}="pci-db %p"
/lib/udev/rules.d/75-tty-description.rules:SUBSYSTEMS=="usb",
ENV{ID_MODEL_FROM_DATABASE}=="", IMPORT{program}="usb-db %p"
/lib/udev/rules.d/75-tty-description.rules:SUBSYSTEMS=="pci",
ENV{ID_MODEL_FROM_DATABASE}=="", IMPORT{program}="pci-db %p"
/lib/udev/rules.d/78-sound-card.rules:SUBSYSTEMS=="usb",
ENV{ID_VENDOR_FROM_DATABASE}=="", IMPORT{program}="usb-db %p"
/lib/udev/rules.d/78-sound-card.rules:SUBSYSTEMS=="pci",
ENV{ID_VENDOR_FROM_DATABASE}=="", IMPORT{program}="pci-db %p"
/lib/udev/rules.d/78-sound-card.rules:ENV{ID_MODEL_FROM_DATABASE}=="*[Ss]peaker*",
ENV{SOUND_FORM_FACTOR}="speaker", GOTO="sound_end"
/lib/udev/rules.d/78-sound-card.rules:ENV{ID_MODEL_FROM_DATABASE}=="*[Hh]eadphone*",
ENV{SOUND_FORM_FACTOR}="headphone", GOTO="sound_end"
/lib/udev/rules.d/78-sound-card.rules:ENV{ID_MODEL_FROM_DATABASE}=="*[Hh]eadset*",
ENV{SOUND_FORM_FACTOR}="headset", GOTO="sound_end"
/lib/udev/rules.d/78-sound-card.rules:ENV{ID_MODEL_FROM_DATABASE}=="*[Hh]andset*",
ENV{SOUND_FORM_FACTOR}="handset", GOTO="sound_end"
/lib/udev/rules.d/78-sound-card.rules:ENV{ID_MODEL_FROM_DATABASE}=="*[Mm]icrophone*",
ENV{SOUND_FORM_FACTOR}="microphone", GOTO="sound_end"
/lib/udev/rules.d/80-udisks.rules:SUBSYSTEM=="pci",
ACTION=="add|change", ENV{ID_MODEL_FROM_DATABASE}=="",
ATTR{class}=="0x01*", IMPORT{program}="pci-db %p"
/lib/udev/rules.d/86-hpmud_plugin.rules:SUBSYSTEM=="usb",
ENV{DEVTYPE}=="usb_device", ATTRS{idVendor}=="03f0",
ATTRS{idProduct}=="??17", PROGRAM="/bin/sh -c 'logger -p user.info
loading hp_printer_device $env{BUSNUM} $env{DEVNUM}'", RUN+="/bin/sh -c
'/usr/bin/python /usr/bin/hp-check-plugin -m $env{BUSNUM}:$env{DEVNUM} &'"
/lib/udev/rules.d/86-hpmud_plugin.rules:SUBSYSTEM=="usb",
ENV{DEVTYPE}=="usb_device", ATTRS{idVendor}=="03f0",
ATTRS{idProduct}=="??2a", PROGRAM="/bin/sh -c 'logger -p user.info
loading hp_printer_device $env{BUSNUM} $env{DEVNUM}'", RUN+="/bin/sh -c
'/usr/bin/python /usr/bin/hp-check-plugin -m $env{BUSNUM}:$env{DEVNUM}&'"
/lib/udev/rules.d/86-hpmud_plugin.rules:SUBSYSTEM=="usb",
ENV{DEVTYPE}=="usb_device", ATTRS{idVendor}=="03f0",
ATTRS{idProduct}=="??17", PROGRAM="/bin/sh -c 'X=%k; X=$${X#usbdev};
B=$${X%%%%.*}; D=$${X#*.}; logger -p user.info loading HP Device $$B
$$D; printf %%03i:%%03i $$B $$D'", RUN+="/bin/sh -c '/usr/bin/python
/usr/bin/hp-check-plugin -m %c &'"
/lib/udev/rules.d/86-hpmud_plugin.rules:SUBSYSTEM=="usb",
ENV{DEVTYPE}=="usb_device", ATTRS{idVendor}=="03f0",
ATTRS{idProduct}=="??2a", PROGRAM="/bin/sh -c 'X=%k; X=$${X#usbdev};
B=$${X%%%%.*}; D=$${X#*.}; logger -p user.info loading HP Device $$B
$$D; printf %%03i:%%03i $$B $$D'", RUN+="/bin/sh -c '/usr/bin/python
/usr/bin/hp-check-plugin -m %c &'"
/lib/udev/rules.d/90-alsa-restore.rules:        RUN+="/usr/sbin/alsactl
restore $attr{number}"
root@fireball / #


Yikes, almost enough for a attachment. 

root@fireball / # equery list udev
 * Searching for udev ...
[IP-] [  ] sys-fs/udev-171-r9:0
root@fireball / #

I will not allow my system to upgrade to anything listed in the new
item.  I'm not going to chance it.

As to a silent fail.  I watch my system really close when booting.  If I
see any error message, I hit Scroll lock and make a note of it.  I have
one now about rc.conf.  I have the file in the new place but have not
rebooted yet to test.  So far, I have not seen any error except for
sound card stuff when booting.  Since a sound card is not needed when
booting, I'm not worried about it. 

Again, this comes to this that has been around for decades.  Anything
needed for booting, should be on the / file system, /bin, /sbin, /lib or
/etc.  Nothing needed for booting should be placed in /usr or /var since
a lot of people put those on separate file systems, including me.  What
I don't get is this, that has been working for decades so why change it? 

Dale

:-)  :-) 

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

[gentoo-user] Re: Anyone switched to eudev yet?

[Nuno J. Silva]

On 2012-12-25, Dale wrote:

> Nuno J. Silva wrote:
>> On 2012-12-25, Dale wrote:
[...]
>>> I might add, I have ALWAYS had a separate /usr.  Darn near a decade
>>> now.  It has never failed to boot because /usr was on a separate
>>> partition.  NOT ONCE.  Now I am told it is going to fail.  Go figure. 
>>> Go try to tell me that it was broken all these years.  Yea, right. 
>> Would it be too much trouble to ask you to share the output of
>>
>>   egrep 'usb-db|pci-db|FROM_DATABASE|/usr' /*/udev/rules.d/*
>>
>> and the version of udev you're running? I'm curious to see. Of course
>> that, if you don't have some packages installing their udev rules, you
>> may not have the issue at all. But maybe you have, so why don't we give
>> it a try?
>>
>> Also, if you actually read the linked URL, it does explain it won't fail
>> to boot. You do realize these are two different issues here, right? One
>> is people saying that udev-181 will fail to boot, other is the issue
>> described on the URL linked on the news item, which is about stuff in
>> /usr breaking udev rules, which has been around for a long time and will
>> *silently* fail. I remind you that "silently fail" implies that your
>> system will still boot, even if it is affected by the issue.
>
> root@fireball / # egrep 'usb-db|pci-db|FROM_DATABASE|/usr' /*/udev/rules.d/*
[...]
> $$D; printf %%03i:%%03i $$B $$D'", RUN+="/bin/sh -c '/usr/bin/python
> /usr/bin/hp-check-plugin -m %c &'"
> /lib/udev/rules.d/86-hpmud_plugin.rules:SUBSYSTEM=="usb",
> ENV{DEVTYPE}=="usb_device", ATTRS{idVendor}=="03f0",
> ATTRS{idProduct}=="??2a", PROGRAM="/bin/sh -c 'X=%k; X=$${X#usbdev};
> B=$${X%%%%.*}; D=$${X#*.}; logger -p user.info loading HP Device $$B
> $$D; printf %%03i:%%03i $$B $$D'", RUN+="/bin/sh -c '/usr/bin/python
> /usr/bin/hp-check-plugin -m %c &'"
> /lib/udev/rules.d/90-alsa-restore.rules:        RUN+="/usr/sbin/alsactl
> restore $attr{number}"
> root@fireball / #
>
>
> Yikes, almost enough for a attachment. 
>
> root@fireball / # equery list udev
>  * Searching for udev ...
> [IP-] [  ] sys-fs/udev-171-r9:0
> root@fireball / #

Thanks. So you don't have udev-181, but you already need stuff under
/udev for these rules to work. Which is what that URL is about.

> I will not allow my system to upgrade to anything listed in the new
> item.  I'm not going to chance it.
>
> As to a silent fail.  I watch my system really close when booting.  If I
> see any error message, I hit Scroll lock and make a note of it.  I have
> one now about rc.conf.  I have the file in the new place but have not
> rebooted yet to test.  So far, I have not seen any error except for
> sound card stuff when booting.  Since a sound card is not needed when
> booting, I'm not worried about it. 

You happen to understand that the "silent" part in "silent fail" implies
that you won't see any error message? If it wasn't silent, it would not
be called silent fail.

In fact, I'd say that the article the URL points to was written exactly
because this has been this way for some time, but as the fail is silent,
many people simply don't notice that it fails, and assume that, as far
as the system reachs the login prompt with no visible errors, then
everything is OK.

> Again, this comes to this that has been around for decades.  Anything
> needed for booting, should be on the / file system, /bin, /sbin, /lib or
> /etc.  Nothing needed for booting should be placed in /usr or /var since
> a lot of people put those on separate file systems, including me.  What
> I don't get is this, that has been working for decades so why change
> it? 

Then perhaps you should do, for example,  
   equery belongs '/usr/bin/hp-check-plugin'
   equery belongs '/usr/bin/python'
   equery belongs '/usr/bin/hp-mkuri'
   equery belongs '/usr/sbin/alsactl'

   [and so on, for executables and scripts used in the udev rules the
   command found on your system]

And file bugs on these packages (ALSA, python and perhaps some CUPS
drivers?), as these commands are needed for booting (they're called by
udev as soon as there is a device matching the rule) and, so, they
should live under /, not under /usr.

-- 
Nuno Silva (aka njsg)
http://njsg.sdf-eu.org/

Re: [gentoo-user] Re: Anyone switched to eudev yet?

[Dale]

Nuno J. Silva wrote:
> On 2012-12-25, Dale wrote:
>
>
> root@fireball / # egrep 'usb-db|pci-db|FROM_DATABASE|/usr' /*/udev/rules.d/*
> [...]
>> $$D; printf %%03i:%%03i $$B $$D'", RUN+="/bin/sh -c '/usr/bin/python
>> /usr/bin/hp-check-plugin -m %c &'"
>> /lib/udev/rules.d/86-hpmud_plugin.rules:SUBSYSTEM=="usb",
>> ENV{DEVTYPE}=="usb_device", ATTRS{idVendor}=="03f0",
>> ATTRS{idProduct}=="??2a", PROGRAM="/bin/sh -c 'X=%k; X=$${X#usbdev};
>> B=$${X%%%%.*}; D=$${X#*.}; logger -p user.info loading HP Device $$B
>> $$D; printf %%03i:%%03i $$B $$D'", RUN+="/bin/sh -c '/usr/bin/python
>> /usr/bin/hp-check-plugin -m %c &'"
>> /lib/udev/rules.d/90-alsa-restore.rules:        RUN+="/usr/sbin/alsactl
>> restore $attr{number}"
>> root@fireball / #
>>
>>
>> Yikes, almost enough for a attachment. 
>>
>> root@fireball / # equery list udev
>>  * Searching for udev ...
>> [IP-] [  ] sys-fs/udev-171-r9:0
>> root@fireball / #
> Thanks. So you don't have udev-181, but you already need stuff under
> /udev for these rules to work. Which is what that URL is about.

Actually, NO.  I only built a init thingy to GET READY for the change. 
I can still boot WITHOUT the init thingy as it is now.  I went through
this early instead of waiting for the upgrade that leaves me with a
machine that may NOT boot or me running around like a chicken with my
head cut off to figure out how to fix it.  As it was, it took me a
couple weeks at least to find a init thingy that works.  That is one
reason I hate the things.  ;-)   I suspect you were not around when hal
hit the scene.  As bad as I hate hal, I think the init thingy has it
beat.  Trust me, ask anyone on this list, I HATE hal!!  If it was
physical instead of code, I would use it for target practice.  Be nice
for my new .44 magnum rifle.  :-) 

>
>> I will not allow my system to upgrade to anything listed in the new
>> item.  I'm not going to chance it.
>>
>> As to a silent fail.  I watch my system really close when booting.  If I
>> see any error message, I hit Scroll lock and make a note of it.  I have
>> one now about rc.conf.  I have the file in the new place but have not
>> rebooted yet to test.  So far, I have not seen any error except for
>> sound card stuff when booting.  Since a sound card is not needed when
>> booting, I'm not worried about it. 
> You happen to understand that the "silent" part in "silent fail" implies
> that you won't see any error message? If it wasn't silent, it would not
> be called silent fail.
>
> In fact, I'd say that the article the URL points to was written exactly
> because this has been this way for some time, but as the fail is silent,
> many people simply don't notice that it fails, and assume that, as far
> as the system reachs the login prompt with no visible errors, then
> everything is OK.

Read above.  I can boot withOUT an init thingy still.  Also, I check for
errors after about every reboot, especially if I have not rebooted in a
while.  I go through dmesg and other logs looking for anything that is
out of place or new.  If anything has a issue, I'll find it.  That's how
I already know about the sound card issue.  It doesn't affect me booting
and never should. 

>> Again, this comes to this that has been around for decades.  Anything
>> needed for booting, should be on the / file system, /bin, /sbin, /lib or
>> /etc.  Nothing needed for booting should be placed in /usr or /var since
>> a lot of people put those on separate file systems, including me.  What
>> I don't get is this, that has been working for decades so why change
>> it? 
> Then perhaps you should do, for example,  
>    equery belongs '/usr/bin/hp-check-plugin'
>    equery belongs '/usr/bin/python'
>    equery belongs '/usr/bin/hp-mkuri'
>    equery belongs '/usr/sbin/alsactl'
>
>    [and so on, for executables and scripts used in the udev rules the
>    command found on your system]

I already know about them and they do NOT affect me booting.  The hp is
my printer.  The alsactl is my sound card.  Again, nothing that affects
me booting.  My system can boot if my printer is turned off and it also
boots without a sound card too.  I do want to get me a better card tho. 
;-) 

> And file bugs on these packages (ALSA, python and perhaps some CUPS
> drivers?), as these commands are needed for booting (they're called by
> udev as soon as there is a device matching the rule) and, so, they
> should live under /, not under /usr.
>

Thing is, upstream is not going to fix it.  Lennart, and others, has
made it clear, it is their way or go away.  This has been discussed a
lot over the past year or two.  Some have even posted links to postings
by the udev/systemd folks.  They are not interested in it. It gets
marked as 'won't fix' or whatever and that is the end of it. 

Again, the point is, what has been working for ages is being claimed
that it is broken for basically everybody because it suites the ones
that want to change it.  They use a init thingy to boot their systems,
binary based ones I might add, and they want to push the same on us. 
Gentoo should not need a init thingy unless you have some setup where /
is encrypted or something.  This is what so many disagree with.  I don't
want one because they introduce one more point of failure when booting. 

Just imagine the thread about 3.7.1 SATA errors.  If he had a init
thingy, he would have to find out what is broken first, the init thingy
or the kernel or even worse, BOTH.  I run into enough problems from time
to time.  I do NOT want to add yet one more point of failure, especially
given the history of init thingys and me when I was on Mandriva.  Been
there, done that, don't want to go back either. 

Just my $0.02 worth. 

By the way, I do NOT like init thingys.  ROFL

Dale

:-)  :-) 

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

Re: [gentoo-user] Re: Anyone switched to eudev yet?

[Paul Colquhoun]

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

On Tue, 25 Dec 2012 19:17:24 Nuno J. Silva wrote:
> 
> Also, if you actually read the linked URL, it does explain it won't fail
> to boot. You do realize these are two different issues here, right? One
> is people saying that udev-181 will fail to boot, other is the issue
> described on the URL linked on the news item, which is about stuff in
> /usr breaking udev rules, which has been around for a long time and will
> *silently* fail. I remind you that "silently fail" implies that your
> system will still boot, even if it is affected by the issue.


So, instead of fixing udev properly, by making the failures visible (as they 
probably should have been from the start) or even re-queueing the events to be 
run after the rule files are avaiable, the developers took the easy (for them) 
way out, and told the rest of the world to do things their way.


-- 
Reverend Paul Colquhoun, ULC.    http://andor.dropbear.id.au/~paulcol
     Asking for technical help in newsgroups?  Read this first:
        http://catb.org/~esr/faqs/smart-questions.html#intro

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

Re: [gentoo-user] Re: Anyone switched to eudev yet?

[Dale]

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

Paul Colquhoun wrote:
>
> On Tue, 25 Dec 2012 19:17:24 Nuno J. Silva wrote:
>
> >
>
> > Also, if you actually read the linked URL, it does explain it won't fail
>
> > to boot. You do realize these are two different issues here, right? One
>
> > is people saying that udev-181 will fail to boot, other is the issue
>
> > described on the URL linked on the news item, which is about stuff in
>
> > /usr breaking udev rules, which has been around for a long time and will
>
> > *silently* fail. I remind you that "silently fail" implies that your
>
> > system will still boot, even if it is affected by the issue.
>
>  
>
>  
>
> So, instead of fixing udev properly, by making the failures visible
> (as they probably should have been from the start) or even re-queueing
> the events to be run after the rule files are avaiable, the developers
> took the easy (for them) way out, and told the rest of the world to do
> things their way.
>
>  
>
>

Basically, yep.  If I see a error while booting, in dmesg or some other
logging tool, I can handle it and make changes so that it is fixed. 
When I mentioned on this list about using LVM, I specifically chose to
put / on a normal partition to avoid the init thingy.  If I have to use
a init thingy anyway, I may as well put everything but /boot on LVM. 
Putting / on LVM usually means you have to have a init thingy so that it
can be mounted, from what I have read anyway.  It looked like for a
while that I was going to have one whether I wanted it or not.  Now,
just waiting eudev, which is going to fix it like udev/systemd should to
begin with. 

You pretty much got the idea of it tho. 

Dale

:-)  :-) 

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


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

Re: [gentoo-user] Re: Anyone switched to eudev yet?

[Neil Bothwick]

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

On Wed, 26 Dec 2012 09:54:49 +1100, Paul Colquhoun wrote:

> > Also, if you actually read the linked URL, it does explain it won't
> > fail to boot. You do realize these are two different issues here,
> > right? One is people saying that udev-181 will fail to boot, other is
> > the issue described on the URL linked on the news item, which is
> > about stuff in /usr breaking udev rules, which has been around for a
> > long time and will *silently* fail. I remind you that "silently fail"
> > implies that your system will still boot, even if it is affected by
> > the issue.  

> So, instead of fixing udev properly, by making the failures visible (as
> they probably should have been from the start) or even re-queueing the
> events to be run after the rule files are avaiable, the developers took
> the easy (for them) way out, and told the rest of the world to do
> things their way.

That all makes sense, although it may well be harder to implement than to
suggest. To be fair to the udev developers, we owe them nothing and they
are free to take their project in whichever direction they like and spend
their time on whatever features they choose to. If we don't like it we
can fork it. If eudev works and provides a valid alternative to udev it
will simply prove that the open source ecosystem works in a way that all
those trying to avoid "upgrading" from Windows 7 to 8 can't even dream
about.

There is really no place for the insults and name calling, udev provided
us with a great tool that we were happy to use for years, now it is
moving in a direction we don't like we can either live with the change or
do something about it. Walt chose the latter route and now the eudev guys
are following suit - eudev may not be ready for use yet but the devs have
already achieved a lot more that all the list complaint and insults ever
will.


-- 
Neil Bothwick

Quantum leap: (adj.) literally, to move by the smallest amount
theoretically possible. In advertising, to move by the largest leap
imaginable (in the mind of the advertiser). There is no contradiction.

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

Re: [gentoo-user] Re: Anyone switched to eudev yet?

[pk]

On 2012-12-26 12:55, Neil Bothwick wrote:

> That all makes sense, although it may well be harder to implement
> than to suggest. To be fair to the udev developers, we owe them
> nothing and they are free to take their project in whichever
> direction they like and spend their time on whatever features they
> choose to. If we don't like it we can fork it. If eudev works and
> provides a valid alternative to udev it will simply prove that the
> open source ecosystem works in a way that all those trying to avoid
> "upgrading" from Windows 7 to 8 can't even dream about.
> 
> There is really no place for the insults and name calling, udev
> provided us with a great tool that we were happy to use for years,
> now it is moving in a direction we don't like we can either live
> with the change or do something about it. Walt chose the latter
> route and now the eudev guys are following suit - eudev may not be
> ready for use yet but the devs have already achieved a lot more
> that all the list complaint and insults ever will.

Very well said!

+1

Best regards

Peter K

Re: [gentoo-user] Re: Anyone switched to eudev yet?

[Mark David Dumlao]

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

On Dec 24, 2012 10:00 PM, "Dale" <rdalek1967@gmail.com> wrote:
> I have not
> tested the theory but that is what people have been saying.  Not only is
> my /usr separate but it is on LVM partitons too.

If I recall correctly, easy repartitioning was supposed to be one of the
main reasons wy LVM was  made in the first place. ;)

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

Re: [gentoo-user] Re: Anyone switched to eudev yet?

[Bruce Hill]

On Tue, Dec 25, 2012 at 12:25:02AM +0800, Mark David Dumlao wrote:
> On Dec 24, 2012 10:00 PM, "Dale" <rdalek1967@gmail.com> wrote:
> > I have not
> > tested the theory but that is what people have been saying.  Not only is
> > my /usr separate but it is on LVM partitons too.
> 
> If I recall correctly, easy repartitioning was supposed to be one of the
> main reasons wy LVM was  made in the first place. ;)

mingdao@server ~ $ df -hT
Filesystem                   Type      Size  Used Avail Use% Mounted on
rootfs                       rootfs    2.0G   93M  1.9G   5% /
/dev/root                    xfs       2.0G   93M  1.9G   5% /
tmpfs                        tmpfs     3.0G  284K  3.0G   1% /run
udev                         devtmpfs   10M  4.0K   10M   1% /dev
shm                          tmpfs     3.0G     0  3.0G   0% /dev/shm
cgroup_root                  tmpfs      10M     0   10M   0% /sys/fs/cgroup
/dev/mapper/system-var       xfs        10G  737M  9.3G   8% /var
/dev/mapper/system-usr       xfs        10G  4.3G  5.8G  43% /usr
/dev/mapper/system-home      xfs       6.0G  5.0G 1023M  84% /home
/dev/mapper/storage-photos   xfs       500G   19G  482G   4% /photos
/dev/mapper/storage-backups  xfs       500G  313G  188G  63% /backups
/dev/mapper/storage-offload  fuseblk   300G  262G   39G  88% /offload
/dev/mapper/storage-peter    xfs        25G  1.7G   24G   7% /peter
/dev/mapper/storage-jeremiah xfs        10G  2.5G  7.5G  25% /jeremiah

server ~ # vgdisplay
  --- Volume group ---
  VG Name               storage
  System ID             
  Format                lvm2
  Metadata Areas        1
  Metadata Sequence No  10
  VG Access             read/write
  VG Status             resizable
  MAX LV                0
  Cur LV                5
  Open LV               5
  Max PV                0
  Cur PV                1
  Act PV                1
  VG Size               1.82 TiB
  PE Size               4.00 MiB
  Total PE              476834
  Alloc PE / Size       341760 / 1.30 TiB
  Free  PE / Size       135074 / 527.63 GiB
  VG UUID               5ifFA3-FEME-tAne-s8pd-D5Zr-5MhY-GzLjGS
   
  --- Volume group ---
  VG Name               system
  System ID             
  Format                lvm2
  Metadata Areas        1
  Metadata Sequence No  7
  VG Access             read/write
  VG Status             resizable
  MAX LV                0
  Cur LV                3
  Open LV               3
  Max PV                0
  Cur PV                1
  Act PV                1
  VG Size               64.29 GiB
  PE Size               4.00 MiB
  Total PE              16459
  Alloc PE / Size       6656 / 26.00 GiB
  Free  PE / Size       9803 / 38.29 GiB
  VG UUID               vxWFrl-cfeA-YTGe-oMCF-Muei-wSbe-uLKiq9

mingdao@server ~ $ cat /proc/mdstat 
Personalities : [linear] [raid0] [raid1] [raid10] [raid6] [raid5] [raid4] [multipath] 
md3 : active raid10 sdg1[2] sde1[0] sdh1[3] sdf1[1]
      1953115136 blocks super 1.2 512K chunks 2 near-copies [4/4] [UUUU]
      
md1 : active raid6 sdc2[2] sdd2[3] sdb2[1] sda2[0]
      67418112 blocks level 6, 512k chunk, algorithm 2 [4/4] [UUUU]
      
md0 : active raid1 sdc1[2] sdd1[3] sdb1[1] sda1[0]
      2097088 blocks [4/4] [UUUU]
      
unused devices: <none>

mingdao@server ~ $ egrep -v "(^#|^ *$)" /etc/fstab 
/dev/md0		/		xfs		inode64,logbsize=262144 0 1
/var/swapfile1		swap		swap		defaults		0 0
/dev/system/var		/var		xfs		defaults		0 0
/dev/system/usr		/usr		xfs		defaults		0 0
/dev/system/home	/home		xfs		defaults		0 0
/dev/storage/photos	/photos		xfs		users,rw		0 0
/dev/storage/backups	/backups	xfs		users,rw		0 0
/dev/storage/offload	/offload	ntfs		defaults		0 0
/dev/storage/peter	/peter		xfs		defaults		0 0
/dev/storage/jeremiah	/jeremiah	xfs		defaults		0 0
/dev/cdrom		/mnt/cdrom	auto		noauto,ro		0 0

mingdao@server ~ $ egrep -v "(^#|^ *$)" /etc/lilo.conf
compact
lba32
boot = /dev/md0
raid-extra-boot = mbr-only
map = /boot/.map
install = /boot/boot-menu.b   # Note that for lilo-22.5.5 or later you
                              # do not need boot-{text,menu,bmp}.b in
                              # /boot, as they are linked into the lilo
                              # binary.
menu-scheme=Wb
prompt
timeout=50
append="panic=10 nomce dolvm domdadm rootfstype=xfs"
image = /boot/vmlinuz
        root = /dev/md0
        label = Gentoo
        read-only  # Partitions should be mounted read-only for checking
image = /boot/vmlinuz.old
        root = /dev/md0
        label = Gentoo-def
        read-only  # Partitions should be mounted read-only for checking




No initrd...
-- 
Happy Penguin Computers               >')
126 Fenco Drive                       ( \
Tupelo, MS 38801                       ^^
support@happypenguincomputers.com
662-269-2706 662-205-6424
http://happypenguincomputers.com/

Don't top-post: http://en.wikipedia.org/wiki/Top_post#Top-posting

Re: [gentoo-user] Re: Anyone switched to eudev yet?

[Dale]

Bruce Hill wrote:

<<< SNIP >>>
> No initrd... 

YET!!!  ROFL

When eudev goes stable, then we can disregard that yet.  ;-) 

Dale

:-)  :-) 

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

Re: [gentoo-user] Re: Anyone switched to eudev yet?

[Bruce Hill]

On Mon, Dec 24, 2012 at 11:05:25AM -0600, Dale wrote:
> Bruce Hill wrote:
> 
> <<< SNIP >>>
> > No initrd... 
> 
> YET!!!  ROFL
> 
> When eudev goes stable, then we can disregard that yet.  ;-) 
> 
> Dale

devfs still works wonderfully ... for principle, if no other reason, that file
server will *NEVER* have an initrd image
-- 
Happy Penguin Computers               >')
126 Fenco Drive                       ( \
Tupelo, MS 38801                       ^^
support@happypenguincomputers.com
662-269-2706 662-205-6424
http://happypenguincomputers.com/

Don't top-post: http://en.wikipedia.org/wiki/Top_post#Top-posting

Re: [gentoo-user] Re: Anyone switched to eudev yet?

[Mark David Dumlao]

On Tue, Dec 25, 2012 at 1:15 AM, Bruce Hill
<daddy@happypenguincomputers.com> wrote:
> On Mon, Dec 24, 2012 at 11:05:25AM -0600, Dale wrote:
>> Bruce Hill wrote:
>>
>> <<< SNIP >>>
>> > No initrd...
>>
>> YET!!!  ROFL
>>
>> When eudev goes stable, then we can disregard that yet.  ;-)
>>
>> Dale
>
> devfs still works wonderfully ... for principle, if no other reason, that file
> server will *NEVER* have an initrd image

You shouldn't need to wait for eudev.

Technically any early mount system configured and done _before_ udev
should do the trick. I mean, it's not like udev is even *essential*
for boot - that we happen to depend on it is just a matter of
convenience. Shouldn't be hard to write an rc script that does just
that for anyone that hates init thingies bad enough. Just hardcode an
n-second sleep and plug in the kernel detected device name. Do rc
scripts count as "init thingies"? :)
--
This email is:    [ ] actionable   [ ] fyi        [x] social
Response needed:  [ ] yes          [x] up to you  [ ] no
Time-sensitive:   [ ] immediate    [ ] soon       [x] none

Re: [gentoo-user] Re: Anyone switched to eudev yet?

[Dale]

Mark David Dumlao wrote:
> On Tue, Dec 25, 2012 at 1:15 AM, Bruce Hill
> <daddy@happypenguincomputers.com> wrote:
>> On Mon, Dec 24, 2012 at 11:05:25AM -0600, Dale wrote:
>>> Bruce Hill wrote:
>>>
>>> <<< SNIP >>>
>>>> No initrd...
>>> YET!!!  ROFL
>>>
>>> When eudev goes stable, then we can disregard that yet.  ;-)
>>>
>>> Dale
>> devfs still works wonderfully ... for principle, if no other reason, that file
>> server will *NEVER* have an initrd image
> You shouldn't need to wait for eudev.
>
> Technically any early mount system configured and done _before_ udev
> should do the trick. I mean, it's not like udev is even *essential*
> for boot - that we happen to depend on it is just a matter of
> convenience. Shouldn't be hard to write an rc script that does just
> that for anyone that hates init thingies bad enough. Just hardcode an
> n-second sleep and plug in the kernel detected device name. Do rc
> scripts count as "init thingies"? :)
> --
> This email is:    [ ] actionable   [ ] fyi        [x] social
> Response needed:  [ ] yes          [x] up to you  [ ] no
> Time-sensitive:   [ ] immediate    [ ] soon       [x] none
>
>


Is that what eudev is going to do?  I follow -dev and according to the
eudev people they are going to support a separate /usr with no init
thingy.  So, they have a plan to do this.  From what they were posting,
they seem pretty sure they can do this. 

I'm just waiting on eudev to get stable.  It was posted that the one in
the tree still needs a couple fixes and then it will be ready for some
testing.  Heck, I'll gladly test it whenever they say it boots and KDE
will work.  Heck, just booting is a good start.  lol

Dale

:-)  :-) 

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

Re: [gentoo-user] Re: Anyone switched to eudev yet?

[Mark David Dumlao]

On Tue, Dec 25, 2012 at 9:54 AM, Dale <rdalek1967@gmail.com> wrote:
> Mark David Dumlao wrote:
>> On Tue, Dec 25, 2012 at 1:15 AM, Bruce Hill
>> <daddy@happypenguincomputers.com> wrote:
>>> On Mon, Dec 24, 2012 at 11:05:25AM -0600, Dale wrote:
>>>> Bruce Hill wrote:
>>>>
>>>> <<< SNIP >>>
>>>>> No initrd...
>>>> YET!!!  ROFL
>>>>
>>>> When eudev goes stable, then we can disregard that yet.  ;-)
>>>>
>>>> Dale
>>> devfs still works wonderfully ... for principle, if no other reason, that file
>>> server will *NEVER* have an initrd image
>> You shouldn't need to wait for eudev.
>>
>> Technically any early mount system configured and done _before_ udev
>> should do the trick. I mean, it's not like udev is even *essential*
>> for boot - that we happen to depend on it is just a matter of
>> convenience. Shouldn't be hard to write an rc script that does just
>> that for anyone that hates init thingies bad enough. Just hardcode an
>> n-second sleep and plug in the kernel detected device name. Do rc
>> scripts count as "init thingies"? :)
>
> Is that what eudev is going to do?  I follow -dev and according to the
> eudev people they are going to support a separate /usr with no init
> thingy.  So, they have a plan to do this.  From what they were posting,
> they seem pretty sure they can do this.

Contrary to all the noise in this topic, udev itself works on /.

The thing is this: udev is now being _installed to_ /usr instead of /.
This is an upstream decision.

See, there's a common bug with a lot of programs using udev. They are
also installed to /usr instead of to /. And so those programs will
_silently_ fail when /usr isn't mounted. Silent failures are deemed a
bad thing by some people, worse so than noisy failures, something to
do with the Unix philosophy of failing early and loudly.

Now, you can install udev to / if you want - by writing a custom
ebuild that does just that. And it should, in theory, work. But if you
want it to run without hitches, you _must_ make sure /usr is mounted
in time for all the rules to run. That's why an early mount script
will fix any issues with udev.

One way of getting an early mount script - the most reliable and
comprehensively tested one - is to use an "init thingy". I haven't
used one in a long time, but you generally just run a script,
mkinitrd/mkinitramfs/dracut, that generates it for you. The init
thingy is a compressed filesystem that contains just enough tools and
modules you need to test and mount your filesystems. Which,
conspicuously, was supposed to be the reason for the / being separated
from the /usr filesystem.

But besides the point - it's not the only way. You could just write a
mount script yourself, and force your mount script to run before udev
does, by editing udev's dependencies in /etc/conf.d/udev. That will
also fix any issues udev has with /usr.

The eudev team did a different thing. They forked udev and changed
some bits around that they didn't like. But the one thing they didn't
fix - which by definition they cannot fix - is the fact that programs
depending on eudev - and installed to /usr - will _still_ need /usr
mounted beforehand to function properly.

A lot of us don't have those programs, or invoke those programs late
enough in the system uptime that /usr is guaranteed to be mounted. So
we just coincidentally happen to not run into any trouble.
--
This email is:    [ ] actionable   [ ] fyi        [x] social
Response needed:  [ ] yes          [x] up to you  [ ] no
Time-sensitive:   [ ] immediate    [ ] soon       [x] none

Re: [gentoo-user] Re: Anyone switched to eudev yet?

[Alan McKinnon]

On Mon, 24 Dec 2012 06:58:15 -0600
Dale <rdalek1967@gmail.com> wrote:

> So, Nuno, everything was fine until they started moving things to a
> place where it shouldn't be. 

No Dale, that is just flat out wrong.

There is no such thing as "place where stuff should be". There are only
conventions, and like all conventions, rituals, fashions and traditions
these are prone to breakage when things move on. Things move on because
they become way more complex than the designer of the convention thought
they would (or could).

The truth is simply this (derived from empirical observation):

Long ago we had established conventions about / and /usr; mostly
because the few sysadmins around agreed on some things. In those days
there was no concept of a packager or maintainer, there was only a
sysadmin. This person was a lot like me - he decided and if you didn't
like it that was tough. So things stayed as they were for a very long
time.

Thankfully, it is not like that anymore and the distinction between 
/ and /usr is now so blurry there might as well not be a distinction.
Which is good as the distinction wasn't exactly a good thing from day
1 either - it was useful for terminal servers (only by convention) and
let the sysadmin keep his treasured uptime (which only proves he isn't
doing kernel maintenance...)

I'm sorry you bought into the crap about / and /usr that people of my
ilk foisted on you, but the time for that is past, and things move on.
If there is to be a convention, there can be only one that makes any
sense:

/ and /usr are essentially the same, so put your stuff anywhere you
want it to be. ironically this no gives you the ultimate in choice, not
the false one you had for years. So if your /usr is say 8G, then
enlarge / bu that amount, move /usr over and retain all your mount
points as the were. Now for the foreseeable future anything you might
want to hotplug at launch time stands a very good chance of working as
expected.

You will only need an initrd if you have / on striped RAID or LVM or
similar, but that is a boot strap problem not a /usr problem (and you
do not have such a setup). Right now you need an initrd anyway to boot
such setups.

The design of separate / and /usr on modern machines IS broken by
design. It is fragile and causes problems in the large case. This
doesn't mean YOUR system is broken and won't boot, it means it causes
unnecessary hassle in the whole ecosystem, and the fix is to change
behaviour and layout to something more appropriate to what we have
today.

-- 
Alan McKinnon
alan.mckinnon@gmail.com

Re: [gentoo-user] Re: Anyone switched to eudev yet?

[Dale]

Alan McKinnon wrote:
> On Mon, 24 Dec 2012 06:58:15 -0600
> Dale <rdalek1967@gmail.com> wrote:
>
>> So, Nuno, everything was fine until they started moving things to a
>> place where it shouldn't be. 
> No Dale, that is just flat out wrong.
>
> There is no such thing as "place where stuff should be". There are only
> conventions, and like all conventions, rituals, fashions and traditions
> these are prone to breakage when things move on. Things move on because
> they become way more complex than the designer of the convention thought
> they would (or could).
>
> The truth is simply this (derived from empirical observation):
>
> Long ago we had established conventions about / and /usr; mostly
> because the few sysadmins around agreed on some things. In those days
> there was no concept of a packager or maintainer, there was only a
> sysadmin. This person was a lot like me - he decided and if you didn't
> like it that was tough. So things stayed as they were for a very long
> time.
>
> Thankfully, it is not like that anymore and the distinction between 
> / and /usr is now so blurry there might as well not be a distinction.
> Which is good as the distinction wasn't exactly a good thing from day
> 1 either - it was useful for terminal servers (only by convention) and
> let the sysadmin keep his treasured uptime (which only proves he isn't
> doing kernel maintenance...)
>
> I'm sorry you bought into the crap about / and /usr that people of my
> ilk foisted on you, but the time for that is past, and things move on.
> If there is to be a convention, there can be only one that makes any
> sense:
>
> / and /usr are essentially the same, so put your stuff anywhere you
> want it to be. ironically this no gives you the ultimate in choice, not
> the false one you had for years. So if your /usr is say 8G, then
> enlarge / bu that amount, move /usr over and retain all your mount
> points as the were. Now for the foreseeable future anything you might
> want to hotplug at launch time stands a very good chance of working as
> expected.
>
> You will only need an initrd if you have / on striped RAID or LVM or
> similar, but that is a boot strap problem not a /usr problem (and you
> do not have such a setup). Right now you need an initrd anyway to boot
> such setups.
>
> The design of separate / and /usr on modern machines IS broken by
> design. It is fragile and causes problems in the large case. This
> doesn't mean YOUR system is broken and won't boot, it means it causes
> unnecessary hassle in the whole ecosystem, and the fix is to change
> behaviour and layout to something more appropriate to what we have
> today.
>

The problems with that is these:  It worked ALL these years, why should
it not now?  I have / on a traditional partition which is not going to
resize easily.  If I put / on LVM, I need a init thingy.  I don't want a
init thingy or I would have put / on LVM too.  I made / large enough
that I would not fill it up in the lifetime of this system but not large
enough to absorb /usr.  If I am going to have to redo all my partitions
yet again, I will not use LVM.  I use LVM to eliminate this EXACT
problem.  I got tired of running out of space and having to move stuff
around all the time. 

So, worked for ages, then it breaks when people change where they put
things.  Answer is, don't change where you put things.  Then things
still work for most everyone, including me.  I'm not a programmer nor am
I a rocket scientist but even I can see that.  If I can see it, I have
no idea why a programmer can't other than being willingly blinded.  ;-) 

Udev/systemd seems to be the problem.  How do I come to that conclusion,
eudev people says they will support separate /usr with no init thingy. 
Either the eudev folks are rocket scientist type programmers and the
udev/systemd people are playing with fire crackers or there is a way for
this to work with udev/systemd to, IF they wanted it to work.  Thing is,
they have some grand scheme to force people to their way of doing
things, which includes a init thingy.  Since there is a way to continue
with the old way, which has worked for decades, guess what I am going to
do?  Yep, I'm going to jump off the udev ship and onto the eudev ship. 
The eudev ship may be old and traditional but it works like I expect. 
Now if others want to stay on the current ship, works for me too.  I'm
just not liking the meals served on the udev ship anymore. 

I might add, one of the reasons I left Mandriva was because of the init
thingy that kept giving me grief.  If I have to use that thing on
Gentoo, the first time it breaks, I'm going to a binary install.  If I
am going to put up with that mess, I may as well have something that
installs quickly.  That was one thing I liked about Mandriva, install
was really easy.  It still is.  Ubuntu is too.  Actually, they look a
lot alike to me. 

Everyone can have their opinion but I also have mine.  This worked fine
for ages until udev/systemd came along.  That's my opinion and I don't
think I am alone on that.

Dale

:-)  :-) 

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

Re: [gentoo-user] Re: Anyone switched to eudev yet?

[Michael Mol]

On Mon, Dec 24, 2012 at 3:00 PM, Dale <rdalek1967@gmail.com> wrote:
> Alan McKinnon wrote:

[snip]

> The problems with that is these:  It worked ALL these years, why should
> it not now?  I have / on a traditional partition which is not going to
> resize easily.  If I put / on LVM, I need a init thingy.  I don't want a
> init thingy or I would have put / on LVM too.  I made / large enough
> that I would not fill it up in the lifetime of this system but not large
> enough to absorb /usr.  If I am going to have to redo all my partitions
> yet again, I will not use LVM.  I use LVM to eliminate this EXACT
> problem.  I got tired of running out of space and having to move stuff
> around all the time.
>
> So, worked for ages, then it breaks when people change where they put
> things.  Answer is, don't change where you put things.  Then things
> still work for most everyone, including me.  I'm not a programmer nor am
> I a rocket scientist but even I can see that.  If I can see it, I have
> no idea why a programmer can't other than being willingly blinded.  ;-)
>
> Udev/systemd seems to be the problem.  How do I come to that conclusion,
> eudev people says they will support separate /usr with no init thingy.
> Either the eudev folks are rocket scientist type programmers and the
> udev/systemd people are playing with fire crackers or there is a way for
> this to work with udev/systemd to, IF they wanted it to work.  Thing is,
> they have some grand scheme to force people to their way of doing
> things, which includes a init thingy.  Since there is a way to continue
> with the old way, which has worked for decades, guess what I am going to
> do?  Yep, I'm going to jump off the udev ship and onto the eudev ship.
> The eudev ship may be old and traditional but it works like I expect.
> Now if others want to stay on the current ship, works for me too.  I'm
> just not liking the meals served on the udev ship anymore.
>
> I might add, one of the reasons I left Mandriva was because of the init
> thingy that kept giving me grief.  If I have to use that thing on
> Gentoo, the first time it breaks, I'm going to a binary install.  If I
> am going to put up with that mess, I may as well have something that
> installs quickly.  That was one thing I liked about Mandriva, install
> was really easy.  It still is.  Ubuntu is too.  Actually, they look a
> lot alike to me.
>
> Everyone can have their opinion but I also have mine.  This worked fine
> for ages until udev/systemd came along.  That's my opinion and I don't
> think I am alone on that.
>
> Dale

What's really missing on Gentoo to make this effectively painless
(even if I'd still think it hackish design) is strong automation for
updating kernels and initrd images. genkernel and dracut both try to
achieve it, but I don't think they've really hit the mark yet...and
there'd almost have to be integration with portage to make things
truly clean...but safely autobuilding kernels is a very hard problem.
And then there's building and pulling in out-of-mainline kernel
modules.

And I don't think there's enough people with the time and interest in
getting either tool updated enough that the initrd experience is as
clean as it is in, say, Debian or Ubuntu. It'd be a major undertaking.

--
:wq

Re: [gentoo-user] Re: Anyone switched to eudev yet?

[Mark Knecht]

On Mon, Dec 24, 2012 at 12:00 PM, Dale <rdalek1967@gmail.com> wrote:
<SNIP>
> The problems with that is these:  It worked ALL these years, why should
> it not now?  I have / on a traditional partition which is not going to
> resize easily.  If I put / on LVM, I need a init thingy.  I don't want a
> init thingy

Is that really true? Do you _really_ care whether an 'init thingy' exists
on your system, or is this energy about it really based in something else?

I'm just not understanding the resistance so I'm curious.

I don't like, really don't like, the work that currently goes into making
my 'init thingy' work. All the Gentoo docs about creating hierarchies by
hand and populating them with files and then compressing it. All that
drives me nuts. It should be 100% automatic, and probably is with the
right tools which I haven't found.

But I'm not understanding why you are so against it in totality. It would
be one thing to say that it's too much work. That I understand, but not
wanting one seems a bit overboard to me...

- Mark

Re: [gentoo-user] Re: Anyone switched to eudev yet?

[Dale]

Mark Knecht wrote:
> On Mon, Dec 24, 2012 at 12:00 PM, Dale <rdalek1967@gmail.com> wrote:
> <SNIP>
>> The problems with that is these:  It worked ALL these years, why should
>> it not now?  I have / on a traditional partition which is not going to
>> resize easily.  If I put / on LVM, I need a init thingy.  I don't want a
>> init thingy
> Is that really true? Do you _really_ care whether an 'init thingy' exists
> on your system, or is this energy about it really based in something else?
>
> I'm just not understanding the resistance so I'm curious.
>
> I don't like, really don't like, the work that currently goes into making
> my 'init thingy' work. All the Gentoo docs about creating hierarchies by
> hand and populating them with files and then compressing it. All that
> drives me nuts. It should be 100% automatic, and probably is with the
> right tools which I haven't found.
>
> But I'm not understanding why you are so against it in totality. It would
> be one thing to say that it's too much work. That I understand, but not
> wanting one seems a bit overboard to me...
>
> - Mark
>
>


One of the reasons I left Mandriva was because of the init thingy.  If I
wanted one and liked having one, I would have never switched to Gentoo. 
The init thingy was not the only reason but it was one of them.  The
reason I do not want one is because it adds one more point of failure. 
In my past experience, it failed me a lot on Mandriva.  I don't want to
go backwards to failure.  I want to keep moving forward, which is why I
chose Gentoo, no init thingy needed unless you put / on something like
LVM or encrypt it or something.  That is why I put everything but /boot
and / on LVM here, to avoid having to use a init thingy.  I have done a
lot to avoid that thing then it turns out, someone is trying to push it
on me anyway. 

If I am forced to use a init thingy, the first time it fails and I can't
fix it, I'm moving to something else.  If I want a broken init thingy, I
can find something else that suites my needs.  I've said it before, I
love Gentoo but I'm not going to reinstall or otherwise spend hours
trying to fix something that I shouldn't need to to begin with and never
needed before.  Just saying.  ;-)

Dale

:-)  :-) 

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

Re: [gentoo-user] Re: Anyone switched to eudev yet?

[Bruce Hill]

On Mon, Dec 24, 2012 at 04:36:06PM -0600, Dale wrote:
> 
> One of the reasons I left Mandriva was because of the init thingy.  If I
> wanted one and liked having one, I would have never switched to Gentoo. 
> The init thingy was not the only reason but it was one of them.  The
> reason I do not want one is because it adds one more point of failure. 
> In my past experience, it failed me a lot on Mandriva.  I don't want to
> go backwards to failure.  I want to keep moving forward, which is why I
> chose Gentoo, no init thingy needed unless you put / on something like
> LVM or encrypt it or something.  That is why I put everything but /boot
> and / on LVM here, to avoid having to use a init thingy.  I have done a
> lot to avoid that thing then it turns out, someone is trying to push it
> on me anyway. 
> 
> If I am forced to use a init thingy, the first time it fails and I can't
> fix it, I'm moving to something else.  If I want a broken init thingy, I
> can find something else that suites my needs.  I've said it before, I
> love Gentoo but I'm not going to reinstall or otherwise spend hours
> trying to fix something that I shouldn't need to to begin with and never
> needed before.  Just saying.  ;-)
> 
> Dale

What Dale is saying is, "I don't want anything forced on me that leaves me no
choice but to accept it." That's a fundamental way of life to us (Dale, me,
and others).

Today the idea of being an individual, and not having another man's ideas
forced on everyone, has been mostly replaced by the "sheeple" mentality. There
are so many people who just go along without even questioning. We're not two
of those sheeple, and won't become such.

So, what most of you seem to be missing is this: the thing to which Dale (and
a lot of us) object to is not so much an initrd image, but being forced to
use something that is not our choice.

And the problem with it coming from the Fedora camp, and such an arrogant,
pompous, prima donna as Lennart Poeterring, is what is most objectionable. If
there was one modicum of common sense, of humility, in his personality, then
maybe more of this "older, independent, out-of-the-sheepfold" type of man
would check out his ideas. But, alas, It Won't Happen (TM).

Nice little DuckDuckGo hit: http://pastebin.com/RzZYnZwT
-- 
Happy Penguin Computers               >')
126 Fenco Drive                       ( \
Tupelo, MS 38801                       ^^
support@happypenguincomputers.com
662-269-2706 662-205-6424
http://happypenguincomputers.com/

Don't top-post: http://en.wikipedia.org/wiki/Top_post#Top-posting

Re: [gentoo-user] Re: Anyone switched to eudev yet?

[Mark Knecht]

On Mon, Dec 24, 2012 at 2:36 PM, Dale <rdalek1967@gmail.com> wrote:
<SNIP>
> One of the reasons I left Mandriva was because of the init thingy.  If I
> wanted one and liked having one, I would have never switched to Gentoo.
> The init thingy was not the only reason but it was one of them.  The
> reason I do not want one is because it adds one more point of failure.
> In my past experience, it failed me a lot on Mandriva.  I don't want to
> go backwards to failure.  I want to keep moving forward, which is why I
> chose Gentoo, no init thingy needed unless you put / on something like
> LVM or encrypt it or something.  That is why I put everything but /boot
> and / on LVM here, to avoid having to use a init thingy.  I have done a
> lot to avoid that thing then it turns out, someone is trying to push it
> on me anyway.
>
> If I am forced to use a init thingy, the first time it fails and I can't
> fix it, I'm moving to something else.  If I want a broken init thingy, I
> can find something else that suites my needs.  I've said it before, I
> love Gentoo but I'm not going to reinstall or otherwise spend hours
> trying to fix something that I shouldn't need to to begin with and never
> needed before.  Just saying.  ;-)
>
> Dale

Fair enough. I don't agree that leaving Gentoo because you chose to
put all of /usr on LVM and then chose not to deal with the
implications of that over time, but it's your choice and I certainly
support choice.

And I appreciate you communicating your POV.

I'm also interested in Bruce's history about initrd. Sounds like if
that worked today I'd just use it to make an initrd and be done with
it. Unlike you, I guess, I don't have any political position on these
images that get used early on, any more than I do or do not like the
format of grub.conf or other things like that.

Cheers,
Mark

Re: [gentoo-user] Re: Anyone switched to eudev yet?

[Bruce Hill]

On Mon, Dec 24, 2012 at 04:34:00PM -0800, Mark Knecht wrote:
> 
> I'm also interested in Bruce's history about initrd. Sounds like if
> that worked today I'd just use it to make an initrd and be done with
> it. Unlike you, I guess, I don't have any political position on these
> images that get used early on, any more than I do or do not like the
> format of grub.conf or other things like that.
> 
> Cheers,
> Mark

Everyone I know who uses an initrd writes his own script. You might read some
of the files from Slackware:

http://slackware.oregonstate.edu/slackware-14.0/source/a/mkinitrd/

For me, personally, there just isn't a reason for having an initrd in Gentoo.
There are good and valid reasons that I use separate /var or /usr or LVM or
RAID partitions that, under systemd's udev, would require an initrd. But IMO
the OpenRC and >=sys-fs/udev-181 don't need to be rewritten, or obsoleted, by
the mess that is systemd.

As stated before ... I'm not of the mindset to have choices dictated to me.

Bruce
-- 
Happy Penguin Computers               >')
126 Fenco Drive                       ( \
Tupelo, MS 38801                       ^^
support@happypenguincomputers.com
662-269-2706 662-205-6424
http://happypenguincomputers.com/

Don't top-post: http://en.wikipedia.org/wiki/Top_post#Top-posting

Re: [gentoo-user] Re: Anyone switched to eudev yet?

[Dale]

Mark Knecht wrote:
> Fair enough. I don't agree that leaving Gentoo because you chose to
> put all of /usr on LVM and then chose not to deal with the
> implications of that over time, but it's your choice and I certainly
> support choice. And I appreciate you communicating your POV. I'm also
> interested in Bruce's history about initrd. Sounds like if that worked
> today I'd just use it to make an initrd and be done with it. Unlike
> you, I guess, I don't have any political position on these images that
> get used early on, any more than I do or do not like the format of
> grub.conf or other things like that. Cheers, Mark 

Putting /usr on LVM is not the problem.  I have had /usr on LVM for a
good long while now.  It has booted just fine.  The new udev is what is
going to break it, whether I use LVM or not from what has been said on
this list and elsewhere. 

My point is, I came here to get rid of the init nightmare.  I have my
system set up specifically to avoid the init thingy.  If I am going to
have a init thingy that I can't fix without spending hours doing it, I
may as well move to something easier.  In the past, the only way I could
get a init thingy fixed was to reinstall.  If anyone here thinks I am
going to do that with Gentoo, they are completely out of their mind and
plumb bat guano crazy.  I'll be installing Linux but it won't be a all
day event.  With all the distros out there, I bet I can find something
that installs pretty fast and maybe even not have a init thingy to
boot.  One never knows.  ;-)  When I moved to Gentoo, I felt like I
moved up.  Simple setup, works simply and works every time.  Now, I feel
like I am taking a step backwards, not forward.  I have already seen the
past, I don't want to repeat it.

That's my opinion.  I'm not saying everyone should share it or believe
it either.  I believe it tho.  I love Gentoo but not enough to have to
start over or spend hours trying to figure out something that I
shouldn't have to have to begin with.  Progress is fine but not when it
breaks what is working.  People thought hal was progress.  Look where it
ended up.  I think, and for some I hope, udev loses support by everyone
but the ones maintaining it.  Let it go its way and others progress
forward with better ideas and not by shoving it on people either. 

Just my $0.02 and considering I'm on NyQuil, it ain't much.  lol 

Dale

:-)  :-) 

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

Re: [gentoo-user] Re: Anyone switched to eudev yet?

[Neil Bothwick]

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

On Mon, 24 Dec 2012 20:33:34 -0600, Dale wrote:

> Putting /usr on LVM is not the problem.  I have had /usr on LVM for a
> good long while now.  It has booted just fine.  The new udev is what is
> going to break it, whether I use LVM or not from what has been said on
> this list and elsewhere. 

I've been running separate /usr on LVM with ~arch udev and no initramfs
on a couple of systems with no problems. The news item is taking the easy
way out by saying "it will break" rather than "it may break" - such
breakage is by no means certain - although the future holds no
guarantees.


-- 
Neil Bothwick

We never really grow up; we only learn how to act in public.

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

Re: [gentoo-user] Re: Anyone switched to eudev yet?

[Dale]

Neil Bothwick wrote:
> On Mon, 24 Dec 2012 20:33:34 -0600, Dale wrote:
>
>> Putting /usr on LVM is not the problem.  I have had /usr on LVM for a
>> good long while now.  It has booted just fine.  The new udev is what is
>> going to break it, whether I use LVM or not from what has been said on
>> this list and elsewhere. 
> I've been running separate /usr on LVM with ~arch udev and no initramfs
> on a couple of systems with no problems. The news item is taking the easy
> way out by saying "it will break" rather than "it may break" - such
> breakage is by no means certain - although the future holds no
> guarantees.
>
>

Then there is my luck.  Right?

Dale

:-)  :-) 

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

Re: [gentoo-user] Re: Anyone switched to eudev yet?

[Neil Bothwick]

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

On Tue, 25 Dec 2012 15:42:22 -0600, Dale wrote:

> > I've been running separate /usr on LVM with ~arch udev and no
> > initramfs on a couple of systems with no problems. The news item is
> > taking the easy way out by saying "it will break" rather than "it may
> > break" - such breakage is by no means certain - although the future
> > holds no guarantees.

> Then there is my luck.  Right?

Ah yes, I forgot you "Have Awful Luck" :P


-- 
Neil Bothwick

DCE seeks DTE for mutual exchange of data.

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

Re: [gentoo-user] Re: Anyone switched to eudev yet?

[Bruce Hill]

On Mon, Dec 24, 2012 at 01:23:16PM -0800, Mark Knecht wrote:
> On Mon, Dec 24, 2012 at 12:00 PM, Dale <rdalek1967@gmail.com> wrote:
> <SNIP>
> > The problems with that is these:  It worked ALL these years, why should
> > it not now?  I have / on a traditional partition which is not going to
> > resize easily.  If I put / on LVM, I need a init thingy.  I don't want a
> > init thingy
> 
> Is that really true? Do you _really_ care whether an 'init thingy' exists
> on your system, or is this energy about it really based in something else?
> 
> I'm just not understanding the resistance so I'm curious.
> 
> I don't like, really don't like, the work that currently goes into making
> my 'init thingy' work. All the Gentoo docs about creating hierarchies by
> hand and populating them with files and then compressing it. All that
> drives me nuts. It should be 100% automatic, and probably is with the
> right tools which I haven't found.
> 
> But I'm not understanding why you are so against it in totality. It would
> be one thing to say that it's too much work. That I understand, but not
> wanting one seems a bit overboard to me...

Once upon a time (for 7 years) Slackware was my distro, and not only as a
user. They still have a script (mkinitrd) which only asks a minimal amount of
information from the user to run a simple one-liner and create initrd.gz.

Gentoo had mkinitrd once upon a time, but it's now in attic. Somewhere,
sometime, for some reason, initramfs (inital ram filesystem) became vogue for
the Gentoo camp, rather than initrd (initial ram disk image), and mkinitrd got
retired.

Since there are so very many ways to boot a system, with / on RAID0, /usr on
LVM, and any other number of combinations on this LAN, I didn't bother to
investigate why the Gentoo devs retired mkinitrd.

So long as you're not going to let this thread die, I've thrown that in the
mix and maybe someone will come up with the *real* *reason* that mkinitrd,
such a simple method to create an initrd, is in attic rather than portage.
-- 
Happy Penguin Computers               >')
126 Fenco Drive                       ( \
Tupelo, MS 38801                       ^^
support@happypenguincomputers.com
662-269-2706 662-205-6424
http://happypenguincomputers.com/

Don't top-post: http://en.wikipedia.org/wiki/Top_post#Top-posting

[gentoo-user] Re: Anyone switched to eudev yet?

[»Q«]

On Mon, 24 Dec 2012 17:04:13 -0600
Bruce Hill <daddy@happypenguincomputers.com> wrote:

> Gentoo had mkinitrd once upon a time, but it's now in attic.
> Somewhere, sometime, for some reason, initramfs (inital ram
> filesystem) became vogue for the Gentoo camp, rather than initrd
> (initial ram disk image), and mkinitrd got retired.

Is there Gentoo documentation for creating initramfs without using
dracut?  I could only find documentation for doing it *with* dracut,
and that procedure required using genkernel.  Surely Gentoo must have
an initramfs guide for non-genkernel users, but I couldn't find one.

Re: [gentoo-user] Re: Anyone switched to eudev yet?

[Mark Knecht]

On Mon, Dec 24, 2012 at 4:29 PM, »Q« <boxcars@gmx.net> wrote:
> On Mon, 24 Dec 2012 17:04:13 -0600
> Bruce Hill <daddy@happypenguincomputers.com> wrote:
>
>> Gentoo had mkinitrd once upon a time, but it's now in attic.
>> Somewhere, sometime, for some reason, initramfs (inital ram
>> filesystem) became vogue for the Gentoo camp, rather than initrd
>> (initial ram disk image), and mkinitrd got retired.
>
> Is there Gentoo documentation for creating initramfs without using
> dracut?  I could only find documentation for doing it *with* dracut,
> and that procedure required using genkernel.  Surely Gentoo must have
> an initramfs guide for non-genkernel users, but I couldn't find one.
>
>

I used this one (I think!!!) 6 months or a year ago. It worked first
time but it was a bit of work getting there:

http://en.gentoo-wiki.com/wiki/Initramfs

Re: [gentoo-user] Re: Anyone switched to eudev yet?

[Dale]

Mark Knecht wrote:
> On Mon, Dec 24, 2012 at 4:29 PM, »Q« <boxcars@gmx.net> wrote:
>> On Mon, 24 Dec 2012 17:04:13 -0600
>> Bruce Hill <daddy@happypenguincomputers.com> wrote:
>>
>>> Gentoo had mkinitrd once upon a time, but it's now in attic.
>>> Somewhere, sometime, for some reason, initramfs (inital ram
>>> filesystem) became vogue for the Gentoo camp, rather than initrd
>>> (initial ram disk image), and mkinitrd got retired.
>> Is there Gentoo documentation for creating initramfs without using
>> dracut?  I could only find documentation for doing it *with* dracut,
>> and that procedure required using genkernel.  Surely Gentoo must have
>> an initramfs guide for non-genkernel users, but I couldn't find one.
>>
>>
> I used this one (I think!!!) 6 months or a year ago. It worked first
> time but it was a bit of work getting there:
>
> http://en.gentoo-wiki.com/wiki/Initramfs
>
>


I tried that a while back when this init thingy started.  I never got it
to boot once, not even a close call.  I got blinking keyboard lights and
error messages that filled the screen.  I worked with that thing for
over a week.  It is in the same pile as hal.  Oooo, let's not even go
there.  Grrrrrr!

I eventually went to dracut which *seems* to work.  My current solution,
don't reboot. 

root@fireball / # uptime
 19:28:53 up 93 days, 12:38,  9 users,  load average: 0.30, 0.31, 0.32
root@fireball / #

That has worked for the last 93 days.  If you are worried about
something, avoid it.  ;-D

Dale

:-)  :-) 

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

Re: [gentoo-user] Re: Anyone switched to eudev yet?

[Bruce Hill]

On Mon, Dec 24, 2012 at 04:54:08PM -0800, Mark Knecht wrote:
> On Mon, Dec 24, 2012 at 4:29 PM, »Q« <boxcars@gmx.net> wrote:
> > On Mon, 24 Dec 2012 17:04:13 -0600
> > Bruce Hill <daddy@happypenguincomputers.com> wrote:
> >
> >> Gentoo had mkinitrd once upon a time, but it's now in attic.
> >> Somewhere, sometime, for some reason, initramfs (inital ram
> >> filesystem) became vogue for the Gentoo camp, rather than initrd
> >> (initial ram disk image), and mkinitrd got retired.
> >
> > Is there Gentoo documentation for creating initramfs without using
> > dracut?  I could only find documentation for doing it *with* dracut,
> > and that procedure required using genkernel.  Surely Gentoo must have
> > an initramfs guide for non-genkernel users, but I couldn't find one.
> >
> >
> 
> I used this one (I think!!!) 6 months or a year ago. It worked first
> time but it was a bit of work getting there:
> 
> http://en.gentoo-wiki.com/wiki/Initramfs

Same question ... initrd.gz and initramfs are *not* the same thing; and there
was a package called mkinitrd in Gentoo that was retired to attic some time
ago, before my exodus from Slackware to Gentoo; therefore, I don't know it's
history. Most distros still have a mkinitrd script, but not Gentoo. And there
are lots of resources online which can guide you in making an initrd or
initramfs. I'm an old guy and don't care to learn too much new unless someone
very knowledgable in *nix (not just one distro) can give me a good reason for
doing so. No one has with initramfs to date.
-- 
Happy Penguin Computers               >')
126 Fenco Drive                       ( \
Tupelo, MS 38801                       ^^
support@happypenguincomputers.com
662-269-2706 662-205-6424
http://happypenguincomputers.com/

Don't top-post: http://en.wikipedia.org/wiki/Top_post#Top-posting

Re: [gentoo-user] Re: Anyone switched to eudev yet?

[Todd Goodman]

* Bruce Hill <daddy@happypenguincomputers.com> [121224 21:17]:
> On Mon, Dec 24, 2012 at 04:54:08PM -0800, Mark Knecht wrote:
> > On Mon, Dec 24, 2012 at 4:29 PM, »Q« <boxcars@gmx.net> wrote:
> > > On Mon, 24 Dec 2012 17:04:13 -0600
> > > Bruce Hill <daddy@happypenguincomputers.com> wrote:
> > >
> > >> Gentoo had mkinitrd once upon a time, but it's now in attic.
> > >> Somewhere, sometime, for some reason, initramfs (inital ram
> > >> filesystem) became vogue for the Gentoo camp, rather than initrd
> > >> (initial ram disk image), and mkinitrd got retired.
> > >
> > > Is there Gentoo documentation for creating initramfs without using
> > > dracut?  I could only find documentation for doing it *with* dracut,
> > > and that procedure required using genkernel.  Surely Gentoo must have
> > > an initramfs guide for non-genkernel users, but I couldn't find one.
> > >
> > >
> > 
> > I used this one (I think!!!) 6 months or a year ago. It worked first
> > time but it was a bit of work getting there:
> > 
> > http://en.gentoo-wiki.com/wiki/Initramfs
> 
> Same question ... initrd.gz and initramfs are *not* the same thing; and there
> was a package called mkinitrd in Gentoo that was retired to attic some time
> ago, before my exodus from Slackware to Gentoo; therefore, I don't know it's
> history. Most distros still have a mkinitrd script, but not Gentoo. And there
> are lots of resources online which can guide you in making an initrd or
> initramfs. I'm an old guy and don't care to learn too much new unless someone
> very knowledgable in *nix (not just one distro) can give me a good reason for
> doing so. No one has with initramfs to date.

Try reading the kernel Documentation.  (e.g.,
/usr/src/linux/Documentation/filesystems/ramfs-rootfs-initramfs.txt.)

initramfs is an improvement over initrd.

Todd

Re: [gentoo-user] Re: Anyone switched to eudev yet?

[Bruce Hill]

On Tue, Dec 25, 2012 at 11:51:43AM -0500, Todd Goodman wrote:
> > 
> > Same question ... initrd.gz and initramfs are *not* the same thing; and there
> > was a package called mkinitrd in Gentoo that was retired to attic some time
> > ago, before my exodus from Slackware to Gentoo; therefore, I don't know it's
> > history. Most distros still have a mkinitrd script, but not Gentoo. And there
> > are lots of resources online which can guide you in making an initrd or
> > initramfs. I'm an old guy and don't care to learn too much new unless someone
> > very knowledgable in *nix (not just one distro) can give me a good reason for
> > doing so. No one has with initramfs to date.
> 
> Try reading the kernel Documentation.  (e.g.,
> /usr/src/linux/Documentation/filesystems/ramfs-rootfs-initramfs.txt.)
> 
> initramfs is an improvement over initrd.
> 
> Todd

Having read it years ago it still fails to give me a good reason for using it.
-- 
Happy Penguin Computers               >')
126 Fenco Drive                       ( \
Tupelo, MS 38801                       ^^
support@happypenguincomputers.com
662-269-2706 662-205-6424
http://happypenguincomputers.com/

Don't top-post: http://en.wikipedia.org/wiki/Top_post#Top-posting

Re: [gentoo-user] Re: Anyone switched to eudev yet?

[Neil Bothwick]

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

On Tue, 25 Dec 2012 17:26:12 -0600, Bruce Hill wrote:

> > Try reading the kernel Documentation.  (e.g.,
> > /usr/src/linux/Documentation/filesystems/ramfs-rootfs-initramfs.txt.)
> > 
> > initramfs is an improvement over initrd.

> Having read it years ago it still fails to give me a good reason for
> using it.

That's because it's a HOWTO not a WHYTO. If you want or need to use
an initramfs that document explains how to use it and how it differs from
the old initrd. It is not trying to tell you whether you need it or not,
that is your decision. Which I guess shows a difference in attitude
between the kernel devs and udev devs.


-- 
Neil Bothwick

You are a completely unique individual, just like everybody else.

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

Re: [gentoo-user] Re: Anyone switched to eudev yet?

[Todd Goodman]

* Bruce Hill <daddy@happypenguincomputers.com> [121225 18:30]:
> On Tue, Dec 25, 2012 at 11:51:43AM -0500, Todd Goodman wrote:
> > > 
> > > Same question ... initrd.gz and initramfs are *not* the same thing; and there
> > > was a package called mkinitrd in Gentoo that was retired to attic some time
> > > ago, before my exodus from Slackware to Gentoo; therefore, I don't know it's
> > > history. Most distros still have a mkinitrd script, but not Gentoo. And there
> > > are lots of resources online which can guide you in making an initrd or
> > > initramfs. I'm an old guy and don't care to learn too much new unless someone
> > > very knowledgable in *nix (not just one distro) can give me a good reason for
> > > doing so. No one has with initramfs to date.
> > 
> > Try reading the kernel Documentation.  (e.g.,
> > /usr/src/linux/Documentation/filesystems/ramfs-rootfs-initramfs.txt.)
> > 
> > initramfs is an improvement over initrd.
> > 
> > Todd
> 
> Having read it years ago it still fails to give me a good reason for using it.

It gives plenty of good reasons.

If they aren't good for you then fine.

But if you read it you wouldn't be asking why initrd went away and was
replaced by initramfs.

Todd

Re: [gentoo-user] Re: Anyone switched to eudev yet?

[Bruce Hill]

On Wed, Dec 26, 2012 at 09:24:20AM -0500, Todd Goodman wrote:
> * Bruce Hill <daddy@happypenguincomputers.com> [121225 18:30]:
> > > 
> > > Try reading the kernel Documentation.  (e.g.,
> > > /usr/src/linux/Documentation/filesystems/ramfs-rootfs-initramfs.txt.)
> > > 
> > > initramfs is an improvement over initrd.
> > > 
> > > Todd
> > 
> > Having read it years ago it still fails to give me a good reason for using it.
> 
> It gives plenty of good reasons.
> 
> If they aren't good for you then fine.
> 
> But if you read it you wouldn't be asking why initrd went away and was
> replaced by initramfs.
> 
> Todd

Actually I had not read it in quite a number of years, did this morning, and
you are entirely correct. Perhaps all those years ago when an initrd was
required at times, I'd just held onto my mkinitrd script and didn't want to
change; and since there's no need for an initrd now, I didn't actually read
it, but clung to incorrect memories.

Thanks for the rebuke. ;)
-- 
Happy Penguin Computers               >')
126 Fenco Drive                       ( \
Tupelo, MS 38801                       ^^
support@happypenguincomputers.com
662-269-2706 662-205-6424
http://happypenguincomputers.com/

Don't top-post: http://en.wikipedia.org/wiki/Top_post#Top-posting

Re: [gentoo-user] Re: Anyone switched to eudev yet?

[Mark Knecht]

On Wed, Dec 26, 2012 at 9:03 AM, Bruce Hill
<daddy@happypenguincomputers.com> wrote:
> On Wed, Dec 26, 2012 at 09:24:20AM -0500, Todd Goodman wrote:
>> * Bruce Hill <daddy@happypenguincomputers.com> [121225 18:30]:
>> > >
>> > > Try reading the kernel Documentation.  (e.g.,
>> > > /usr/src/linux/Documentation/filesystems/ramfs-rootfs-initramfs.txt.)
>> > >
>> > > initramfs is an improvement over initrd.
>> > >
>> > > Todd
>> >
>> > Having read it years ago it still fails to give me a good reason for using it.
>>
>> It gives plenty of good reasons.
>>
>> If they aren't good for you then fine.
>>
>> But if you read it you wouldn't be asking why initrd went away and was
>> replaced by initramfs.
>>
>> Todd
>
> Actually I had not read it in quite a number of years, did this morning, and
> you are entirely correct. Perhaps all those years ago when an initrd was
> required at times, I'd just held onto my mkinitrd script and didn't want to
> change; and since there's no need for an initrd now, I didn't actually read
> it, but clung to incorrect memories.


One interesting small point I got out of the docs that Neil pointed me
toward: That since linux-2.6 we're all using an initramfs

"The 2.6 kernel build process always creates a gzipped cpio format initramfs
archive and links it into the resulting kernel binary.  By default, this
archive is empty (consuming 134 bytes on x86)."

So it's a nit but no one should be saying "I don't use an init thingy"
but rather "My init thingy is empty and has no jobs to do on my
system". (Or at least that's my understanding...)

- Mark

Re: [gentoo-user] Re: Anyone switched to eudev yet?

[Dale]

Mark Knecht wrote:
> One interesting small point I got out of the docs that Neil pointed me
> toward: That since linux-2.6 we're all using an initramfs "The 2.6
> kernel build process always creates a gzipped cpio format initramfs
> archive and links it into the resulting kernel binary. By default,
> this archive is empty (consuming 134 bytes on x86)." So it's a nit but
> no one should be saying "I don't use an init thingy" but rather "My
> init thingy is empty and has no jobs to do on my system". (Or at least
> that's my understanding...) - Mark 


Hence it will not fail, right?  Adding another point of failure is my
problem with this.  As I have said before, when I was using Mandriva,
then Mandrake, the init thingy would fail on a regular basis.  It is one
reason I left Mandriva.  I got tired of the breakage and Gentoo didn't
need one.  So, here I am, good or bad.  ;-) 

Dale

:-)  :-) 

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

Re: [gentoo-user] Re: Anyone switched to eudev yet?

[Mark Knecht]

On Wed, Dec 26, 2012 at 12:34 PM, Dale <rdalek1967@gmail.com> wrote:
> Mark Knecht wrote:
>> One interesting small point I got out of the docs that Neil pointed me
>> toward: That since linux-2.6 we're all using an initramfs "The 2.6
>> kernel build process always creates a gzipped cpio format initramfs
>> archive and links it into the resulting kernel binary. By default,
>> this archive is empty (consuming 134 bytes on x86)." So it's a nit but
>> no one should be saying "I don't use an init thingy" but rather "My
>> init thingy is empty and has no jobs to do on my system". (Or at least
>> that's my understanding...) - Mark
>
>
> Hence it will not fail, right?  Adding another point of failure is my
> problem with this.  As I have said before, when I was using Mandriva,
> then Mandrake, the init thingy would fail on a regular basis.  It is one
> reason I left Mandriva.  I got tired of the breakage and Gentoo didn't
> need one.  So, here I am, good or bad.  ;-)
>
> Dale


Dale,
   not enough info:

   If the init thingy is empty and if your kernel boots then it did not fail.

   If the init thingy is not empty and your kernel boots it did not fail.

   If the init thingy is not empty and your kernel does not boot we
don't know what failed. Might be your init thingy, might be something
else.

   I hope you understand I understand both your POV as well as your
frustration. Maybe the work I'm doing in my thread will allow both of
us to be more comfortable with init thingies. I'm going the opposite
direction as you. I don't need one (on most of my home machines) but
I'm going to add one on all my machines. It will become part of the
way I maintain them all and hopefully I'll get more comfortable with
the process.

Cheers,
Mark

Re: [gentoo-user] Re: Anyone switched to eudev yet?

[Bruce Hill]

On Mon, Dec 24, 2012 at 06:29:07PM -0600, »Q« wrote:
> On Mon, 24 Dec 2012 17:04:13 -0600
> Bruce Hill <daddy@happypenguincomputers.com> wrote:
> 
> > Gentoo had mkinitrd once upon a time, but it's now in attic.
> > Somewhere, sometime, for some reason, initramfs (inital ram
> > filesystem) became vogue for the Gentoo camp, rather than initrd
> > (initial ram disk image), and mkinitrd got retired.
> 
> Is there Gentoo documentation for creating initramfs without using
> dracut?  I could only find documentation for doing it *with* dracut,
> and that procedure required using genkernel.  Surely Gentoo must have
> an initramfs guide for non-genkernel users, but I couldn't find one.

Do you understand that initrd.gz and initramfs are *not* the same thing?
-- 
Happy Penguin Computers               >')
126 Fenco Drive                       ( \
Tupelo, MS 38801                       ^^
support@happypenguincomputers.com
662-269-2706 662-205-6424
http://happypenguincomputers.com/

Don't top-post: http://en.wikipedia.org/wiki/Top_post#Top-posting

Re: [gentoo-user] Re: Anyone switched to eudev yet?

[Dale]

Bruce Hill wrote:
> On Mon, Dec 24, 2012 at 06:29:07PM -0600, »Q« wrote:
>> On Mon, 24 Dec 2012 17:04:13 -0600
>> Bruce Hill <daddy@happypenguincomputers.com> wrote:
>>
>>> Gentoo had mkinitrd once upon a time, but it's now in attic.
>>> Somewhere, sometime, for some reason, initramfs (inital ram
>>> filesystem) became vogue for the Gentoo camp, rather than initrd
>>> (initial ram disk image), and mkinitrd got retired.
>> Is there Gentoo documentation for creating initramfs without using
>> dracut?  I could only find documentation for doing it *with* dracut,
>> and that procedure required using genkernel.  Surely Gentoo must have
>> an initramfs guide for non-genkernel users, but I couldn't find one.
> Do you understand that initrd.gz and initramfs are *not* the same thing?


Don't they sort of *do* the same thing?  Different method but still a
boot up helper thingy.  This is why I started calling them init thingy. 
There are a few init thingys and I just lump them all together since
they sort of serve the same function but in a different way. 

Feel free to set me straight tho.  As long as you don't tell me my
system is broken and has not been able to boot for the last 9 years
without one of those things.  ROFL

Dale

:-)  :-) 

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

Re: [gentoo-user] Re: Anyone switched to eudev yet?

[Bruce Hill]

On Mon, Dec 24, 2012 at 08:38:30PM -0600, Dale wrote:
> Bruce Hill wrote:
> > On Mon, Dec 24, 2012 at 06:29:07PM -0600, »Q« wrote:
> >> On Mon, 24 Dec 2012 17:04:13 -0600
> >> Bruce Hill <daddy@happypenguincomputers.com> wrote:
> >>
> >>> Gentoo had mkinitrd once upon a time, but it's now in attic.
> >>> Somewhere, sometime, for some reason, initramfs (inital ram
> >>> filesystem) became vogue for the Gentoo camp, rather than initrd
> >>> (initial ram disk image), and mkinitrd got retired.
> >> Is there Gentoo documentation for creating initramfs without using
> >> dracut?  I could only find documentation for doing it *with* dracut,
> >> and that procedure required using genkernel.  Surely Gentoo must have
> >> an initramfs guide for non-genkernel users, but I couldn't find one.
> > Do you understand that initrd.gz and initramfs are *not* the same thing?
> 
> 
> Don't they sort of *do* the same thing?  Different method but still a
> boot up helper thingy.  This is why I started calling them init thingy. 
> There are a few init thingys and I just lump them all together since
> they sort of serve the same function but in a different way. 
> 
> Feel free to set me straight tho.  As long as you don't tell me my
> system is broken and has not been able to boot for the last 9 years
> without one of those things.  ROFL
> 
> Dale

It's explained well here:

http://en.wikipedia.org/wiki/Initrd

There are many things reported by the Gentoo Community, especially by #gentoo
on FreeNode, such that you would think the entire world is governed that way;
however, most of it is Just Not True (TM).

You will read in that link that initial ramdisk images (initrd) became popular
for kitchen sink (distro) kernels, so that "make allmodconfig" kernel images,
with even more modules added on some distros (Slackware, for one example),
could boot on virtually anyone's hardware.

That's a basic kernel presupposition -- the binary distros ship a kernel that,
hopefully, will work on any and all comps. Gentoo, on the other hand, doesn't
ship a kernel at all, and expects you to build your own. I wasn't on the
Gentoo ship when genkernel came along, but would suspect it was originally
written to help those poor souls who were "trying Gentoo" and could not build
a kernel on their own (since that seems to be the audience using it now).

This thread has wandered so far off track that it isn't coming back. Wish I
could figure out how to /ignore a thread in Mutt. :(
-- 
Happy Penguin Computers               >')
126 Fenco Drive                       ( \
Tupelo, MS 38801                       ^^
support@happypenguincomputers.com
662-269-2706 662-205-6424
http://happypenguincomputers.com/

Don't top-post: http://en.wikipedia.org/wiki/Top_post#Top-posting

Re: [gentoo-user] Re: Anyone switched to eudev yet?

[Dale]

Bruce Hill wrote:
> On Mon, Dec 24, 2012 at 08:38:30PM -0600, Dale wrote:
>> Bruce Hill wrote:
>>> On Mon, Dec 24, 2012 at 06:29:07PM -0600, »Q« wrote:
>>>> On Mon, 24 Dec 2012 17:04:13 -0600
>>>> Bruce Hill <daddy@happypenguincomputers.com> wrote:
>>>>
>>>>> Gentoo had mkinitrd once upon a time, but it's now in attic.
>>>>> Somewhere, sometime, for some reason, initramfs (inital ram
>>>>> filesystem) became vogue for the Gentoo camp, rather than initrd
>>>>> (initial ram disk image), and mkinitrd got retired.
>>>> Is there Gentoo documentation for creating initramfs without using
>>>> dracut?  I could only find documentation for doing it *with* dracut,
>>>> and that procedure required using genkernel.  Surely Gentoo must have
>>>> an initramfs guide for non-genkernel users, but I couldn't find one.
>>> Do you understand that initrd.gz and initramfs are *not* the same thing?
>>
>> Don't they sort of *do* the same thing?  Different method but still a
>> boot up helper thingy.  This is why I started calling them init thingy. 
>> There are a few init thingys and I just lump them all together since
>> they sort of serve the same function but in a different way. 
>>
>> Feel free to set me straight tho.  As long as you don't tell me my
>> system is broken and has not been able to boot for the last 9 years
>> without one of those things.  ROFL
>>
>> Dale
> It's explained well here:
>
> http://en.wikipedia.org/wiki/Initrd
>
> There are many things reported by the Gentoo Community, especially by #gentoo
> on FreeNode, such that you would think the entire world is governed that way;
> however, most of it is Just Not True (TM).
>
> You will read in that link that initial ramdisk images (initrd) became popular
> for kitchen sink (distro) kernels, so that "make allmodconfig" kernel images,
> with even more modules added on some distros (Slackware, for one example),
> could boot on virtually anyone's hardware.
>
> That's a basic kernel presupposition -- the binary distros ship a kernel that,
> hopefully, will work on any and all comps. Gentoo, on the other hand, doesn't
> ship a kernel at all, and expects you to build your own. I wasn't on the
> Gentoo ship when genkernel came along, but would suspect it was originally
> written to help those poor souls who were "trying Gentoo" and could not build
> a kernel on their own (since that seems to be the audience using it now).
>
> This thread has wandered so far off track that it isn't coming back. Wish I
> could figure out how to /ignore a thread in Mutt. :(


That is what I thought.  It even says they are two different things but
give the same results.  So, me calling them init thingys works fine. 

"In computing, initrd (initial ramdisk) is a scheme for loading a
temporary root file system into memory in the boot process of the Linux
kernel. initrd and initramfs refer to two different methods of achieving
this. Both are commonly used to make preparations before the real root
file system can be mounted."

Dale

:-)  :-) 

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

Re: [gentoo-user] Re: Anyone switched to eudev yet?

[Mark David Dumlao]

On Tue, Dec 25, 2012 at 10:38 AM, Dale <rdalek1967@gmail.com> wrote:
> Feel free to set me straight tho.  As long as you don't tell me my
> system is broken and has not been able to boot for the last 9 years
> without one of those things.  ROFL

Nobody's telling you _your_ system, as in the collection of programs
you use for your productivity, is broken. What we're saying is that
_the_ system, as in the general practice as compared to the
specification, is broken. Those are two _very_ different things.
--
This email is:    [ ] actionable   [ ] fyi        [x] social
Response needed:  [ ] yes          [x] up to you  [ ] no
Time-sensitive:   [ ] immediate    [ ] soon       [x] none

Re: [gentoo-user] Re: Anyone switched to eudev yet?

[Dale]

Mark David Dumlao wrote:
> On Tue, Dec 25, 2012 at 10:38 AM, Dale <rdalek1967@gmail.com> wrote:
>> Feel free to set me straight tho.  As long as you don't tell me my
>> system is broken and has not been able to boot for the last 9 years
>> without one of those things.  ROFL
> Nobody's telling you _your_ system, as in the collection of programs
> you use for your productivity, is broken. What we're saying is that
> _the_ system, as in the general practice as compared to the
> specification, is broken. Those are two _very_ different things.
> --
> This email is:    [ ] actionable   [ ] fyi        [x] social
> Response needed:  [ ] yes          [x] up to you  [ ] no
> Time-sensitive:   [ ] immediate    [ ] soon       [x] none
>
>

From what I have read, they are saying what has worked for decades has
been broken the whole time.  Doesn't matter that it works for millions
of users, its broken.  They say it is broken so they can "fix it" with a
init thingy for EVERYONE.  Sorry, that's like telling me my car has been
broken for the last ten years when I have been driving it to town and it
runs just fine. 

The udev/systemd people sound like politicians.  We want to change
something so something must be broke, let's fix it.  They get together,
make some new rules and it actually ends up being worse then what it
originally was.  Do they back up and try to come up with something else,
no, they try to fix it some more which leads to more problems.  This
continues until it falls in on itself OR someone with some sense
realizes we need to go back to where it was and make it work like it has
for so many years.  The eudev folks are planning to continue with what
has worked, that's my reading on it anyway.

YMMV

Dale

:-)  :-) 

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

Re: [gentoo-user] Re: Anyone switched to eudev yet?

[Mark David Dumlao]

On Thu, Dec 27, 2012 at 4:42 AM, Dale <rdalek1967@gmail.com> wrote:
> Mark David Dumlao wrote:
>> On Tue, Dec 25, 2012 at 10:38 AM, Dale <rdalek1967@gmail.com> wrote:
>>> Feel free to set me straight tho.  As long as you don't tell me my
>>> system is broken and has not been able to boot for the last 9 years
>>> without one of those things.  ROFL
>> Nobody's telling you _your_ system, as in the collection of programs
>> you use for your productivity, is broken. What we're saying is that
>> _the_ system, as in the general practice as compared to the
>> specification, is broken. Those are two _very_ different things.
>
> From what I have read, they are saying what has worked for decades has
> been broken the whole time.  Doesn't matter that it works for millions
> of users, its broken.

Yes, that is exactly what they are saying. What I am pointing out,
however, is that there is, informally, a _technical meaning_ for the
word "broken", which is that "the specs don't match the
implementation". And in the case of /usr, the specs don't match the
implementation. For like, maybe all of the Linuxen.

>  They say it is broken so they can "fix it" with a
> init thingy for EVERYONE.  Sorry, that's like telling me my car has been
> broken for the last ten years when I have been driving it to town and it
> runs just fine.

NOBODY is telling you your system or that the systems of millions of
users out there aren't booting. You're assigning emotional baggage to
technical language.

To push your analogy, oh, your car is working just fine. Now anyone
with a pair of spark plugs and a few tools may be able to start it
without you, but your startup _works_. Now imagine some German
engineer caring nothing about you lowly driver, and caring more about
the car as a system, and he goes using fancy words like
"authentication systems" and declaring that "all cars have a flaw", or
more incensingly, "car security is fundamentally broken" (Cue angry
hordes of owners pitchfork and torching his house).

Thing is, he's right, and if he worked out some way for software to
verify that machine startup was done using the keys rather than spark
plugs, he'd be doing future generations a favor in a dramatic
reduction of carjackings. And if somehow it became mandated for future
cars to have this added in addition to airbags and whatnot, it'd annoy
the hell out of car makers but overall still be a good thing.

And here the analogy is holding up: NOBODY is breaking into your car
and forcefully installing some authentication system in its startup.
And NOBODY is breaking into your servers and forcing you to switch to
udev/systemd or merged /usr. You can still happily plow along with
your system as is. Heck, you can even install current udev without
changing your partition setup. Just modify the ebuild and have it
install it into / instead of /usr. Or use an early bootup script. Or
use an init thingy.

>
> The udev/systemd people sound like politicians.

If anything, Lennart is the worst possible politician on the planet.
He makes unpopular decisions, mucks around in stuff people don't want
touched, talks snide and derisively, etc etc etc, because he's a
nerd's nerd that knows nothing about PR and goodwill. The software is
good, but that's about all he knows how to write. He's like DJB on
crack.
--
This email is:    [ ] actionable   [ ] fyi        [x] social
Response needed:  [ ] yes          [x] up to you  [ ] no
Time-sensitive:   [ ] immediate    [ ] soon       [x] none

Re: [gentoo-user] Re: Anyone switched to eudev yet?

[Dale]

Mark David Dumlao wrote:
> On Thu, Dec 27, 2012 at 4:42 AM, Dale <rdalek1967@gmail.com> wrote:
>> Mark David Dumlao wrote:
>>> On Tue, Dec 25, 2012 at 10:38 AM, Dale <rdalek1967@gmail.com> wrote:
>>>> Feel free to set me straight tho.  As long as you don't tell me my
>>>> system is broken and has not been able to boot for the last 9 years
>>>> without one of those things.  ROFL
>>> Nobody's telling you _your_ system, as in the collection of programs
>>> you use for your productivity, is broken. What we're saying is that
>>> _the_ system, as in the general practice as compared to the
>>> specification, is broken. Those are two _very_ different things.
>> From what I have read, they are saying what has worked for decades has
>> been broken the whole time.  Doesn't matter that it works for millions
>> of users, its broken.
> Yes, that is exactly what they are saying. What I am pointing out,
> however, is that there is, informally, a _technical meaning_ for the
> word "broken", which is that "the specs don't match the
> implementation". And in the case of /usr, the specs don't match the
> implementation. For like, maybe all of the Linuxen.
>
>>  They say it is broken so they can "fix it" with a
>> init thingy for EVERYONE.  Sorry, that's like telling me my car has been
>> broken for the last ten years when I have been driving it to town and it
>> runs just fine.
> NOBODY is telling you your system or that the systems of millions of
> users out there aren't booting. You're assigning emotional baggage to
> technical language.
>
> To push your analogy, oh, your car is working just fine. Now anyone
> with a pair of spark plugs and a few tools may be able to start it
> without you, but your startup _works_. Now imagine some German
> engineer caring nothing about you lowly driver, and caring more about
> the car as a system, and he goes using fancy words like
> "authentication systems" and declaring that "all cars have a flaw", or
> more incensingly, "car security is fundamentally broken" (Cue angry
> hordes of owners pitchfork and torching his house).
>
> Thing is, he's right, and if he worked out some way for software to
> verify that machine startup was done using the keys rather than spark
> plugs, he'd be doing future generations a favor in a dramatic
> reduction of carjackings. And if somehow it became mandated for future
> cars to have this added in addition to airbags and whatnot, it'd annoy
> the hell out of car makers but overall still be a good thing.
>
> And here the analogy is holding up: NOBODY is breaking into your car
> and forcefully installing some authentication system in its startup.
> And NOBODY is breaking into your servers and forcing you to switch to
> udev/systemd or merged /usr. You can still happily plow along with
> your system as is. Heck, you can even install current udev without
> changing your partition setup. Just modify the ebuild and have it
> install it into / instead of /usr. Or use an early bootup script. Or
> use an init thingy.
>
>> The udev/systemd people sound like politicians.
> If anything, Lennart is the worst possible politician on the planet.
> He makes unpopular decisions, mucks around in stuff people don't want
> touched, talks snide and derisively, etc etc etc, because he's a
> nerd's nerd that knows nothing about PR and goodwill. The software is
> good, but that's about all he knows how to write. He's like DJB on
> crack.
> --
> This email is:    [ ] actionable   [ ] fyi        [x] social
> Response needed:  [ ] yes          [x] up to you  [ ] no
> Time-sensitive:   [ ] immediate    [ ] soon       [x] none
>
>

I think your analogy actually proves my point.  Instead of just getting
in the car and turning the key, they want to reinvent the engine and how
it works.  It doesn't matter that it is and has been working for decades,

Thanks for proving my point tho.  LOL

Dale

:-)  :-) 

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

Re: [gentoo-user] Re: Anyone switched to eudev yet?

[Mark Knecht]

On Thu, Dec 27, 2012 at 8:13 AM, Dale <rdalek1967@gmail.com> wrote:
>
> I think your analogy actually proves my point.  Instead of just getting
> in the car and turning the key, they want to reinvent the engine and how
> it works.  It doesn't matter that it is and has been working for decades,
>
> Thanks for proving my point tho.  LOL
>
> Dale

<hehe!!>

I guess you ain't one of those 'Global Warming' loonies that thinks
our precious gas guzzling, smog belching cars are melting the glaciers
and creatin' lots o' them hurricanes, 'eh? ;-)

Sometimes technology just needs to move forward, but that doesn't mean
you can't hold on to your musket and shoot them darn carpetbaggers if
they trespass on your lawn, right?

- Mark

Re: [gentoo-user] Re: Anyone switched to eudev yet?

[Mark David Dumlao]

On Fri, Dec 28, 2012 at 12:13 AM, Dale <rdalek1967@gmail.com> wrote:
> Mark David Dumlao wrote:
>> On Thu, Dec 27, 2012 at 4:42 AM, Dale <rdalek1967@gmail.com> wrote:
>>> Mark David Dumlao wrote:
>>>> On Tue, Dec 25, 2012 at 10:38 AM, Dale <rdalek1967@gmail.com> wrote:
>>>>> Feel free to set me straight tho.  As long as you don't tell me my
>>>>> system is broken and has not been able to boot for the last 9 years
>>>>> without one of those things.  ROFL
>>>> Nobody's telling you _your_ system, as in the collection of programs
>>>> you use for your productivity, is broken. What we're saying is that
>>>> _the_ system, as in the general practice as compared to the
>>>> specification, is broken. Those are two _very_ different things.
>>> From what I have read, they are saying what has worked for decades has
>>> been broken the whole time.  Doesn't matter that it works for millions
>>> of users, its broken.
>> Yes, that is exactly what they are saying. What I am pointing out,
>> however, is that there is, informally, a _technical meaning_ for the
>> word "broken", which is that "the specs don't match the
>> implementation". And in the case of /usr, the specs don't match the
>> implementation. For like, maybe all of the Linuxen.
>>
>>>  They say it is broken so they can "fix it" with a
>>> init thingy for EVERYONE.  Sorry, that's like telling me my car has been
>>> broken for the last ten years when I have been driving it to town and it
>>> runs just fine.
>> NOBODY is telling you your system or that the systems of millions of
>> users out there aren't booting. You're assigning emotional baggage to
>> technical language.
>>
>> To push your analogy, oh, your car is working just fine. Now anyone
>> with a pair of spark plugs and a few tools may be able to start it
>> without you, but your startup _works_. Now imagine some German
>> engineer caring nothing about you lowly driver, and caring more about
>> the car as a system, and he goes using fancy words like
>> "authentication systems" and declaring that "all cars have a flaw", or
>> more incensingly, "car security is fundamentally broken" (Cue angry
>> hordes of owners pitchfork and torching his house).
>>
>> Thing is, he's right, and if he worked out some way for software to
>> verify that machine startup was done using the keys rather than spark
>> plugs, he'd be doing future generations a favor in a dramatic
>> reduction of carjackings. And if somehow it became mandated for future
>> cars to have this added in addition to airbags and whatnot, it'd annoy
>> the hell out of car makers but overall still be a good thing.
>
> I think your analogy actually proves my point.  Instead of just getting
> in the car and turning the key, they want to reinvent the engine and how
> it works.  It doesn't matter that it is and has been working for decades,

I think your reaction proves my point about angry mobs torching his
home without understanding what's being proposed. Your fine reading
comprehension once again failed to catch the notion that in my
analogy, all he invented was a mechanism that makes sure it was a key,
not a spark plug, that did the starting. i.e., you're asking literally
for a turnkey system, and that's literally what he invented, except
that the system guarantees that it's a key that was turned.

You have not said a THING about your misunderstanding of the use of
the word _broken_ and you're continuing to peddle your hate-boner even
after it's been shown that you're confused.

--
This email is:    [ ] actionable   [ ] fyi        [x] social
Response needed:  [ ] yes          [x] up to you  [ ] no
Time-sensitive:   [ ] immediate    [ ] soon       [x] none

Re: [gentoo-user] Re: Anyone switched to eudev yet?

[Dale]

Mark David Dumlao wrote:
> I think your reaction proves my point about angry mobs torching his
> home without understanding what's being proposed. Your fine reading
> comprehension once again failed to catch the notion that in my
> analogy, all he invented was a mechanism that makes sure it was a key,
> not a spark plug, that did the starting. i.e., you're asking literally
> for a turnkey system, and that's literally what he invented, except
> that the system guarantees that it's a key that was turned. You have
> not said a THING about your misunderstanding of the use of the word
> _broken_ and you're continuing to peddle your hate-boner even after
> it's been shown that you're confused. -- This email is: [ ] actionable
> [ ] fyi [x] social Response needed: [ ] yes [x] up to you [ ] no
> Time-sensitive: [ ] immediate [ ] soon [x] none 

So I guess Linus is confused to?  You think he is just a hate-boner?  I
would think Linus if anyone knows what he is talking about.  Maybe you
need to go talk to him about his feeling on the direction of
udev/systemd.  Good luck with that. 

Name calling, lost argument.  No more facts.

Dale

:-)  :-) 

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

Re: [gentoo-user] Re: Anyone switched to eudev yet?

[Mark David Dumlao]

On Fri, Dec 28, 2012 at 2:15 AM, Dale <rdalek1967@gmail.com> wrote:
> So I guess Linus is confused to?

In your head, and only in your head, you're agreeing with Linus. Linus
was talking about a different bug entirely from the one you're talking
about.

The bug you're talking about: you go on and on about people saying
that your personal system is broken when it's been working for years.
Again, NOBODY said that. What was said, what you are not able to
refute, is that yes, the case for the / and /usr split IS broken, and
something needs to be done about that moving forward.

> Name calling, lost argument.  No more facts.
I've repeatedly proposed technical solutions to your issues with the
fact that udev is doing something about that and you continue to whine
all night about the bogey-men breaking into your boxes. In fact,
between just you and me, I believe I'm the only one who backed up
anything he said with anything even remotely approaching technical
merit.

1) initramfs. It's not that hard
2) early mount script. It's not that hard.
3) modify your udev ebuild to install to /. It's not that hard.

None of this is being prevented by the vengeful Lennart you're so afraid of.
--
This email is:    [ ] actionable   [ ] fyi        [x] social
Response needed:  [ ] yes          [x] up to you  [ ] no
Time-sensitive:   [ ] immediate    [ ] soon       [x] none

Re: [gentoo-user] Re: Anyone switched to eudev yet?

[Michael Mol]

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

On Thu, Dec 27, 2012 at 1:31 PM, Mark David Dumlao <madumlao@gmail.com>wrote:

> On Fri, Dec 28, 2012 at 2:15 AM, Dale <rdalek1967@gmail.com> wrote:
> > So I guess Linus is confused to?
>
> In your head, and only in your head, you're agreeing with Linus. Linus
> was talking about a different bug entirely from the one you're talking
> about.
>
> The bug you're talking about: you go on and on about people saying
> that your personal system is broken when it's been working for years.
> Again, NOBODY said that. What was said, what you are not able to
> refute, is that yes, the case for the / and /usr split IS broken, and
> something needs to be done about that moving forward.
>
> > Name calling, lost argument.  No more facts.
> I've repeatedly proposed technical solutions to your issues with the
> fact that udev is doing something about that and you continue to whine
> all night about the bogey-men breaking into your boxes. In fact,
> between just you and me, I believe I'm the only one who backed up
> anything he said with anything even remotely approaching technical
> merit.
>
> 1) initramfs. It's not that hard
> 2) early mount script. It's not that hard.
> 3) modify your udev ebuild to install to /. It's not that hard.
>

If you'd read the thread (and/or related ones), you'd know he tried to go
the initrd route, and spent a solid week on the project. You're not talking
to someone who hasn't tried to tread the path.


-- 
:wq

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

Re: [gentoo-user] Re: Anyone switched to eudev yet?

[Mark Knecht]

On Thu, Dec 27, 2012 at 10:41 AM, Michael Mol <mikemol@gmail.com> wrote:
<SNIP>
>>
>> 1) initramfs. It's not that hard
>> 2) early mount script. It's not that hard.
>> 3) modify your udev ebuild to install to /. It's not that hard.
>
>
> If you'd read the thread (and/or related ones), you'd know he tried to go
> the initrd route, and spent a solid week on the project. You're not talking
> to someone who hasn't tried to tread the path.
>

<hehe!>

And while I have a initramfs external to 3.2.1 a kernel working on a
RAID6 / system, my first attempt at building the initramfs into
gentoo-sources-3.6.11 as per Neil's pointers resulted in the RAID6
kicking one drive and not booting, so there is pain out there to be
had. ;-) I'll post more in my thread about how I fix it and move
forward later.

Again, I don't really care about the pain - in a sick sense I sort of
like it (more if it wore high heels...) - but I'm gonna learn this
initramfs stuff and make it work because I suspect it's at least a
good thing to know.

It ain't only you Dale. I have (!)fun(!) with this stuff too... ;-)

Cheers,
Mark

Re: [gentoo-user] Re: Anyone switched to eudev yet?

[Dale]

Mark Knecht wrote:
> On Thu, Dec 27, 2012 at 10:41 AM, Michael Mol <mikemol@gmail.com> wrote:
> <SNIP>
>>> 1) initramfs. It's not that hard
>>> 2) early mount script. It's not that hard.
>>> 3) modify your udev ebuild to install to /. It's not that hard.
>>
>> If you'd read the thread (and/or related ones), you'd know he tried to go
>> the initrd route, and spent a solid week on the project. You're not talking
>> to someone who hasn't tried to tread the path.
>>
> <hehe!>
>
> And while I have a initramfs external to 3.2.1 a kernel working on a
> RAID6 / system, my first attempt at building the initramfs into
> gentoo-sources-3.6.11 as per Neil's pointers resulted in the RAID6
> kicking one drive and not booting, so there is pain out there to be
> had. ;-) I'll post more in my thread about how I fix it and move
> forward later.
>
> Again, I don't really care about the pain - in a sick sense I sort of
> like it (more if it wore high heels...) - but I'm gonna learn this
> initramfs stuff and make it work because I suspect it's at least a
> good thing to know.
>
> It ain't only you Dale. I have (!)fun(!) with this stuff too... ;-)
>
> Cheers,
> Mark
>
>

Well, I have enough pain already.  I don't need my computer adding to
it.  Using something that I shouldn't need and certainly don't want to
use is not my first or second option. 

If I liked pain like that, I'd go break a leg or something.  :/ 

Just saying.

Dale

:-)  :-) 

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

Re: [gentoo-user] Re: Anyone switched to eudev yet?

[Neil Bothwick]

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

On Thu, 27 Dec 2012 11:02:54 -0800, Mark Knecht wrote:

> Again, I don't really care about the pain - in a sick sense I sort of
> like it (more if it wore high heels...) - but I'm gonna learn this
> initramfs stuff and make it work because I suspect it's at least a
> good thing to know.

I said the files worked for me, I never said they worked first time :)

Like you, I tried it more as a learning exercise when the whole udev/init
thingy first came up.


-- 
Neil Bothwick

WinErr 018: Unrecoverable error - System has been destroyed. Buy a new
one. Old Windows licence is not valid anymore.

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

Re: [Bulk] Re: [gentoo-user] Re: Anyone switched to eudev yet?

[Kevin Chadwick]

Again you don't break the spec unless you have to and you don't change
the spec unless it is an improvement or you have no choice. Non of
which is the case. Just like you do not mould a mail RFC to a
widely used technically inferior hotmail implementation.

> He's like DJB on crack.

Except DJB made every Linux system on this planet more reliable simple
and secure through better coding practices and pointing out how buggy
sendmail was. Lennart if anything will accomplish the exact opposite
where systemd is used.


-- 
_______________________________________________________________________

'Write programs that do one thing and do it well. Write programs to work
together. Write programs to handle text streams, because that is a
universal interface'

(Doug McIlroy)
_______________________________________________________________________

Re: [Bulk] Re: [gentoo-user] Re: Anyone switched to eudev yet?

[Mark David Dumlao]

On Fri, Dec 28, 2012 at 12:28 AM, Kevin Chadwick <ma1l1ists@yahoo.co.uk> wrote:
>
> Again you don't break the spec unless you have to and you don't change
> the spec unless it is an improvement or you have no choice. Non of
> which is the case. Just like you do not mould a mail RFC to a
> widely used technically inferior hotmail implementation.

The spec - or implementation - of / and /usr separation is broken and
has been for quite a while now. Nobody here's even bothered answering
how the modern Gentoo distro / sysad would survive /usr being out of
sync with /, for instance, or the fact that some udev programs tend to
be located in /usr, or even just a solid detailed specification on the
precise criteria for inclusion into /. Even the FHS is mum on all the
extra crap we randomly decide between / and /usr to land in. You'd
think, for instance, something as clear cut as filesystem manipulation
tools, e.g., xfs_admin, would belong in /sbin rather than /usr/sbin.
But no it's not. Or - for crying out loud, at least a text editor that
isn't ed.

Again, the broken state of the / and /usr split is a different thing
from the usefulness state of your own already installed distro.

TLDR: The spec is broken.

>
>> He's like DJB on crack.
>
> Except DJB made every Linux system on this planet more reliable simple
> and secure through better coding practices and pointing out how buggy
> sendmail was. Lennart if anything will accomplish the exact opposite
> where systemd is used.

If you have something more than FUD to back up your technical claims,
go ahead. You're directly claiming that wherever systemd is used, the
system will be less reliable and secure, and that Lennart isn't
pointing out buggy behaviors in - what's the analogue for sendmail? oh
yeah - SysVInit scripts.

To carry the analogy, DJB's main point was that the size of the code
was one of - if not the - most important factors in increasing code
quality and security, and worked to make qmail and its configuration
about as spartan as you can get. That's kind of the point of systemd
unit files, trimming the boilerplate size to reduce gotchas like init
scripts failing to detect whether a service is running or not, or if
its dependencies have been started.
--
This email is:    [ ] actionable   [ ] fyi        [x] social
Response needed:  [ ] yes          [x] up to you  [ ] no
Time-sensitive:   [ ] immediate    [ ] soon       [x] none

Re: [Bulk] Re: [gentoo-user] Re: Anyone switched to eudev yet?

[Michael Mol]

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

On Thu, Dec 27, 2012 at 1:22 PM, Mark David Dumlao <madumlao@gmail.com>wrote:

> On Fri, Dec 28, 2012 at 12:28 AM, Kevin Chadwick <ma1l1ists@yahoo.co.uk>
> wrote:
> >
> > Again you don't break the spec unless you have to and you don't change
> > the spec unless it is an improvement or you have no choice. Non of
> > which is the case. Just like you do not mould a mail RFC to a
> > widely used technically inferior hotmail implementation.
>
> The spec - or implementation - of / and /usr separation is broken and
> has been for quite a while now. Nobody here's even bothered answering
> how the modern Gentoo distro / sysad would survive /usr being out of
> sync with /, for instance,


If the basics are kept in /, with prod-additionals kept in /usr, then you
should be able to boot to "basics", and restore /usr.


> or the fact that some udev programs tend to
> be located in /usr,


That's either a bug with those programs, or a need for architectural
improvements within udev. Both plausible answers.



> or even just a solid detailed specification on the
> precise criteria for inclusion into /.


For anyone arguing that / and /usr should be separate, the answer to this
is "that ought to be common sense."

Since I'm not someone who knows all there is to know about the software and
interactions thereof, the most I can say is:

* / ought to contain all binaries, libraries and static data necessary for
booting beyond the point where / is mounted, and any machine-specific
binaries, libraries and static data.
* /usr ought to contain all binaries, libraries and static data not
necessary for its own mount.


> Even the FHS is mum on all the
> extra crap we randomly decide between / and /usr to land in.


So fix it. FHS was a document written to say "we have a standard" that
happened to map almost cleanly to all the implementations of the day. Kinda
like how SQL mapped "almost cleanly" to the existing RDBMSs that existed
when it was introduced. Such is how standards documents are born.


> You'd
> think, for instance, something as clear cut as filesystem manipulation
> tools, e.g., xfs_admin, would belong in /sbin rather than /usr/sbin.
> But no it's not. Or - for crying out loud, at least a text editor that
> isn't ed.
>

I'd say that warrants bug reports against those programs. Also, isn't
busybox under /? I think it has nano built-in.


>
> Again, the broken state of the / and /usr split is a different thing
> from the usefulness state of your own already installed distro.
>
> TLDR: The spec is broken.
>

It's not that the spec is broken. It's that the spec doesn't lay out every
single detail imaginable, and as a consequence, people assuming that the
spec should be able to do their thinking for them assume the spec is broken
when it's silent on a given query.

-- 
:wq

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

Re: [Bulk] Re: [gentoo-user] Re: Anyone switched to eudev yet?

[Mark David Dumlao]

On Fri, Dec 28, 2012 at 2:40 AM, Michael Mol <mikemol@gmail.com> wrote:
>> or the fact that some udev programs tend to
>> be located in /usr,
>
>
> That's either a bug with those programs, or a need for architectural
> improvements within udev. Both plausible answers.
>

The most obvious architectural improvement being: simply place udev
where all its dependencies are and all those bugs turn to nothing.
Which is what the udev guys did. And the part which seems to elude
everyone is: it isn't even a limitation of the program. It can still
be installed to /. Heck we could probably make a USE=root-prefix flag
for udev that installs it to / instead of /usr.

>
>>
>> or even just a solid detailed specification on the
>> precise criteria for inclusion into /.
>
>
> For anyone arguing that / and /usr should be separate, the answer to this is
> "that ought to be common sense."
>
> Since I'm not someone who knows all there is to know about the software and
> interactions thereof, the most I can say is:
>
> * / ought to contain all binaries, libraries and static data necessary for
> booting beyond the point where / is mounted, and any machine-specific
> binaries, libraries and static data.
> * /usr ought to contain all binaries, libraries and static data not
> necessary for its own mount.
>

I'm sure you mean well, as did most of the architects of the past, but
the reality is, this simplistic take on the problem misses out on some
fundamental issues. Yes, you mention later that the spec just doesn't
specify what happens in such and such case, and try to trivialize it
into saying people think that specs should "be able to do their
thinking for them". But unfortunately, specifying what happens is
exactly what specs are for!

However...

>>
>> Even the FHS is mum on all the
>> extra crap we randomly decide between / and /usr to land in.
>
>
> So fix it. FHS was a document written to say "we have a standard" that
> happened to map almost cleanly to all the implementations of the day. Kinda
> like how SQL mapped "almost cleanly" to the existing RDBMSs that existed
> when it was introduced. Such is how standards documents are born.
>

Don't forget that FHS is heavily an after-the-fact descriptive
document of what is happening in practice, with heavy "rationale"
sections describing what's going on in the wild. Before you can fix
FHS, you first have to fix the practice, then FHS can get amended to
reflect what's going on.

And the "we have a standard" part is effectively not true anymore, on
the matter of the / and /usr split. That is - what the specification
says should happen is not happening, on a massive scale, because it
turns out that it's not that trivial to determine which binaries go in
/ and which go in /usr. Now that doesn't translate to epic disasters
of biblical proportion, fire and brimstone, rivers and seas boiling,
dogs and cats living together, mass hysteria - because it's just a
collection of hard to pin down "essential" boot programs - but it does
translate to an unsustainable practice in distro development / package
management.

http://www.pathname.com/fhs/pub/fhs-2.3.html#THEROOTFILESYSTEM

"""
Purpose:
The contents of the root filesystem must be adequate to boot, restore,
recover, and/or repair the system.

To boot a system, enough must be present on the root partition to
mount other filesystems. This includes utilities, configuration, boot
loader information, and other essential start-up data. /usr, /opt, and
/var are designed such that they may be located on other partitions or
filesystems.

To enable recovery and/or repair of a system, those utilities needed
by an experienced maintainer to diagnose and reconstruct a damaged
system must be present on the root filesystem.

To restore a system, those utilities needed to restore from system
backups (on floppy, tape, etc.) must be present on the root
filesystem.
"""

* some teasers:
[1] udev rules themselves being a case in point. I mean, do the
requisite binaries belong in /? For example, there's a virtualbox udev
rule in /usr that doesn't mount other filesystems or stop udev from
starting. However, given the right race conditions, udev will fail to
start the requisite script because /usr isn't mounted.
[2] fuse-based filesystems allow an administrator the crazy
possibility of, for example, demanding that /home be an ssh
connection. Should the ssh client belong in /? ftp? substitute any
arbitrary client program.
[3] a fuse-based filesystem depends on a local network service being
started. For example, someone writes a crazy fuse mysql browser that
also is coincidentally mounted at boot time. Should the mysqld service
belong in /? ldap? substitute any arbitrary server program.
[4] /root (which is why it's separated from /home) contains docs and
custom utilities used by root user for recovery. Unfortunately,
there's a lot of perl scripts there specifically for doing filesystem
checks / reports. Should perl be in in /? substitute any scripting
language.

The point is not whether _you_ can come up with an answer for _your_
own case. A _standard_ speaks for everyone that conforms to it. If it
doesn't, or it comes up with conflicting use cases as above, the spec
is broken. The fact that edge cases are appearing (and would all
disappear if / and /usr were merged) is a hint that something funny is
going on.
--
This email is:    [ ] actionable   [ ] fyi        [x] social
Response needed:  [ ] yes          [x] up to you  [ ] no
Time-sensitive:   [ ] immediate    [ ] soon       [x] none

Re: [Bulk] Re: [gentoo-user] Re: Anyone switched to eudev yet?

[Michael Mol]

On Thu, Dec 27, 2012 at 3:16 PM, Mark David Dumlao <madumlao@gmail.com> wrote:
> On Fri, Dec 28, 2012 at 2:40 AM, Michael Mol <mikemol@gmail.com> wrote:
>>> or the fact that some udev programs tend to
>>> be located in /usr,
>>
>>
>> That's either a bug with those programs, or a need for architectural
>> improvements within udev. Both plausible answers.
>>
>
> The most obvious architectural improvement being: simply place udev
> where all its dependencies are and all those bugs turn to nothing.
> Which is what the udev guys did. And the part which seems to elude
> everyone is: it isn't even a limitation of the program. It can still
> be installed to /. Heck we could probably make a USE=root-prefix flag
> for udev that installs it to / instead of /usr.

This came up today on Reddit. I think it's _highly_ relevant.

http://www.runswift.ly/solving-bugs.html

Moving into a full dependency on initr* for separate /usr is a 'fix',
not a solution.

>
>>
>>>
>>> or even just a solid detailed specification on the
>>> precise criteria for inclusion into /.
>>
>>
>> For anyone arguing that / and /usr should be separate, the answer to this is
>> "that ought to be common sense."
>>
>> Since I'm not someone who knows all there is to know about the software and
>> interactions thereof, the most I can say is:
>>
>> * / ought to contain all binaries, libraries and static data necessary for
>> booting beyond the point where / is mounted, and any machine-specific
>> binaries, libraries and static data.
>> * /usr ought to contain all binaries, libraries and static data not
>> necessary for its own mount.
>>
>
> I'm sure you mean well, as did most of the architects of the past, but
> the reality is, this simplistic take on the problem misses out on some
> fundamental issues. Yes, you mention later that the spec just doesn't
> specify what happens in such and such case, and try to trivialize it
> into saying people think that specs should "be able to do their
> thinking for them". But unfortunately, specifying what happens is
> exactly what specs are for!

Does the term "overspecification" mean anything to you? Specs cannot
and should not specify every possible conceivable related thing.

>
> However...
>
>>>
>>> Even the FHS is mum on all the
>>> extra crap we randomly decide between / and /usr to land in.
>>
>>
>> So fix it. FHS was a document written to say "we have a standard" that
>> happened to map almost cleanly to all the implementations of the day. Kinda
>> like how SQL mapped "almost cleanly" to the existing RDBMSs that existed
>> when it was introduced. Such is how standards documents are born.
>>
>
> Don't forget that FHS is heavily an after-the-fact descriptive
> document of what is happening in practice, with heavy "rationale"
> sections describing what's going on in the wild. Before you can fix
> FHS, you first have to fix the practice, then FHS can get amended to
> reflect what's going on.
>
> And the "we have a standard" part is effectively not true anymore, on
> the matter of the / and /usr split. That is - what the specification
> says should happen is not happening, on a massive scale, because it
> turns out that it's not that trivial to determine which binaries go in
> / and which go in /usr.

Give me an example, and I'll describe a reasonably detailed solution.
It would be my pleasure.

> Now that doesn't translate to epic disasters
> of biblical proportion, fire and brimstone, rivers and seas boiling,
> dogs and cats living together, mass hysteria - because it's just a
> collection of hard to pin down "essential" boot programs - but it does
> translate to an unsustainable practice in distro development / package
> management.
>
> http://www.pathname.com/fhs/pub/fhs-2.3.html#THEROOTFILESYSTEM
>
> """
> Purpose:
> The contents of the root filesystem must be adequate to boot, restore,
> recover, and/or repair the system.
>
> To boot a system, enough must be present on the root partition to
> mount other filesystems. This includes utilities, configuration, boot
> loader information, and other essential start-up data. /usr, /opt, and
> /var are designed such that they may be located on other partitions or
> filesystems.
>
> To enable recovery and/or repair of a system, those utilities needed
> by an experienced maintainer to diagnose and reconstruct a damaged
> system must be present on the root filesystem.
>
> To restore a system, those utilities needed to restore from system
> backups (on floppy, tape, etc.) must be present on the root
> filesystem.
> """
>
> * some teasers:
> [1] udev rules themselves being a case in point. I mean, do the
> requisite binaries belong in /?

Udev is a dispatcher. Actually, in substance, it's a piece of the
kernel that resides in userland; it exists because it was decided back
around the time of devfs that what devfs was doing is something that
ought to be outside the kernel. In reality, it's effectively been a
userland kernel-support process its entire life.

What should probably happen is that udev should be fixed to defer
hotplug events until a rules file is able to sucessfully handle it.
And rules files should perform sanity checking and feedback in the
form of "WTF? No, I can't do that yet. Wake me later." systemd does
something interesting with its "After" clause; that makes perfect
sense. And that's why I asked Canek why one couldn't write a systemd
service file to treat /usr as a service, and make anything dependent
on /usr's presence depend on the /usr "service". That would actually
make _sense_. (Canek declined to opine, or even utilize his
familiarity with the system to theorize how it could be done or what
it would look like. I was disappointed; I was genuinely interested.)

> For example, there's a virtualbox udev
> rule in /usr that doesn't mount other filesystems or stop udev from
> starting. However, given the right race conditions, udev will fail to
> start the requisite script because /usr isn't mounted.

See above.

> [2] fuse-based filesystems allow an administrator the crazy
> possibility of, for example, demanding that /home be an ssh
> connection. Should the ssh client belong in /? ftp? substitute any
> arbitrary client program.

System dependent binaries and libraries aren't commonly placed in
/home. Your better argument would have been fuse-mounted /usr...in
which case it would be the administrator's responsibility to ensure
said arbitrary client program is present in /bin, and its libraries in
/lib.

> [3] a fuse-based filesystem depends on a local network service being
> started. For example, someone writes a crazy fuse mysql browser that
> also is coincidentally mounted at boot time. Should the mysqld service
> belong in /? ldap? substitute any arbitrary server program.

I seriously cannot imagine anyone doing this except as a prank. The
only similar case I can think of would have the db server on a
separate machine.

And if an administrator decides to do this, it's his responsibility to
make sure mysqld is located in /bin, its libraries are in /lib...and
he's got to find some place other than /var for his database! By this
point, you've gone so far into reducto ad absurdum I honestly can't
imagine anyone apart from someone who has absolutely _no_ idea what
they're doing landing themselves in that situation.

> [4] /root (which is why it's separated from /home) contains docs and
> custom utilities used by root user for recovery. Unfortunately,
> there's a lot of perl scripts there specifically for doing filesystem
> checks / reports. Should perl be in in /? substitute any scripting
> language.

You quoted FHS. I'll quote it back to you:

"/usr, /opt, and /var are designed such that they may be located on
other partitions or filesystems."

/root is ridiculously out of the question. /home isn't defended by the
spec, but it's commonly enough separated that it's difficult to
imagine someone making that error twice.

>
> The point is not whether _you_ can come up with an answer for _your_
> own case. A _standard_ speaks for everyone that conforms to it. If it
> doesn't, or it comes up with conflicting use cases as above, the spec
> is broken.

The use cases you described, per spec, are broken. The standard, as
described, makes my answers to your use case descriptions virtually
self-evident.

> The fact that edge cases are appearing (and would all
> disappear if / and /usr were merged) is a hint that something funny is
> going on.

What's funny is the gratuitous misreading of the spec that exists, the
anticipation that it would explicitly state more than it does, the
weak technical arguments (so far) in favor of merging / and /usr, and
the dogmatic defense of the merge.

With a system such as portage, it should be entirely possible (with
few code changes) to configure installation targets (/ vs /usr) on a
per-package basis, and have that trickle down the dependency chain.
Certainly, many packages with broken build systems won't properly
accept --prefix, but that's something that can (and should, and
really, must eventually) be fixed. There's also the matter of
stability while moving packages between /usr and /, but
@preserved-rebuild and subslots should solve that.

Now, binary distros? There are solutions to be had. They're more
difficult. But most of the binary distros don't care, since they use
initrd and update it automatically.

--
:wq

Re: [Bulk] Re: [gentoo-user] Re: Anyone switched to eudev yet?

[Mark David Dumlao]

On Fri, Dec 28, 2012 at 4:59 AM, Michael Mol <mikemol@gmail.com> wrote:
> On Thu, Dec 27, 2012 at 3:16 PM, Mark David Dumlao <madumlao@gmail.com> wrote:
>> On Fri, Dec 28, 2012 at 2:40 AM, Michael Mol <mikemol@gmail.com> wrote:
>>>> or the fact that some udev programs tend to
>>>> be located in /usr,
>>>
>>>
>>> That's either a bug with those programs, or a need for architectural
>>> improvements within udev. Both plausible answers.
>>>
>>
>> The most obvious architectural improvement being: simply place udev
>> where all its dependencies are and all those bugs turn to nothing.
>> Which is what the udev guys did. And the part which seems to elude
>> everyone is: it isn't even a limitation of the program. It can still
>> be installed to /. Heck we could probably make a USE=root-prefix flag
>> for udev that installs it to / instead of /usr.
>
> This came up today on Reddit. I think it's _highly_ relevant.
>
> http://www.runswift.ly/solving-bugs.html
>
> Moving into a full dependency on initr* for separate /usr is a 'fix',
> not a solution.
>

This is where you stumble. It's not a fix. It's a WONTFIX. It's a
"make a lot of noise so that something else gets fixed because this is
outside of our domain and we're not going to be responsible for it as
it wasnt our bug in the first place". And that something else happens
to be the / and /usr split conflicting with the user programs.

If you give the squeaky wheel the grease - as in merge / and /usr -
you apply the fix independently of udev, which was simply installed to
the /usr prefix. THAT is a solution - one independent of udev and
again, does not depend on initr*. You don't have to.

>>
>>>
>>>>
>>>> or even just a solid detailed specification on the
>>>> precise criteria for inclusion into /.
>>>
>>>
>>> For anyone arguing that / and /usr should be separate, the answer to this is
>>> "that ought to be common sense."
>>>
>>> Since I'm not someone who knows all there is to know about the software and
>>> interactions thereof, the most I can say is:
>>>
>>> * / ought to contain all binaries, libraries and static data necessary for
>>> booting beyond the point where / is mounted, and any machine-specific
>>> binaries, libraries and static data.
>>> * /usr ought to contain all binaries, libraries and static data not
>>> necessary for its own mount.
>>>
>>
>> I'm sure you mean well, as did most of the architects of the past, but
>> the reality is, this simplistic take on the problem misses out on some
>> fundamental issues. Yes, you mention later that the spec just doesn't
>> specify what happens in such and such case, and try to trivialize it
>> into saying people think that specs should "be able to do their
>> thinking for them". But unfortunately, specifying what happens is
>> exactly what specs are for!
>
> Does the term "overspecification" mean anything to you? Specs cannot
> and should not specify every possible conceivable related thing.

Two things.

First, I'm not saying that a spec should specify everything. I am
saying, however, that there are specific cases that is within its
domain to specify and that it should be specifying. And because those
cases generate conflicts, the fact that they aren't is a bug.

Second, going back to problem solving in general - just because you
can put down in words what you think the problem is, doesn't mean
you've mapped out an accurate or even consistent statement of the
problem. There really are cases where it's not enough to just give
general airy abstractions and rules of thumb to map out a problem,
where it isn't obvious that you're running into edge cases until you
really look at it deeply, and yes, the / and /usr split is one of
them.

>> And the "we have a standard" part is effectively not true anymore, on
>> the matter of the / and /usr split. That is - what the specification
>> says should happen is not happening, on a massive scale, because it
>> turns out that it's not that trivial to determine which binaries go in
>> / and which go in /usr.
>
> Give me an example, and I'll describe a reasonably detailed solution.
> It would be my pleasure.

The most fundamental and relevant one for us Gentoo users is this:
- how can /usr be sharable among different hosts if it depends on
libraries in /?

"""
http://www.pathname.com/fhs/pub/fhs-2.3.html#THEUSRHIERARCHY

Purpose

/usr is the second major section of the filesystem. /usr is shareable,
read-only data. That means that /usr should be shareable between
various FHS-compliant hosts and must not be written to. Any
information that is host-specific or varies with time is stored
elsewhere.
"""

Many distros place fundamental libraries that many programs in /usr
depend on in /lib. Especially bad for Gentoo - libraries in /lib may
be recompiled as same-version variants if you want to change the USE
flags, resulting in clients that don't synchronously recompile their
own libraries in /lib to both silently and noisily fail.

In other words, many programs in /usr in practice are functionally
inseparable from the libraries in /, conflicting with the notion that
they were properly shared in the first place.

Compare this with the alternate spec that /usr contains both the
programs and the libraries. In which case there is no possibility of
the programs being out of sync with the libraries. From a maintainance
perspective, this reduces the number of points of failure in upgrading
the central NFS share.

Please note, though, that the / vs /usr issue is a bigger thing after
all than udev, and only happens to be a udev-centric discussion
because it's one of the most obvious cases of the spec going awry.

>> * some teasers:
>> [1] udev rules themselves being a case in point. I mean, do the
>> requisite binaries belong in /?
>
> Udev is a dispatcher. Actually, in substance, it's a piece of the
> kernel that resides in userland; it exists because it was decided back
> around the time of devfs that what devfs was doing is something that
> ought to be outside the kernel. In reality, it's effectively been a
> userland kernel-support process its entire life.
>
> What should probably happen is that udev should be fixed to defer
> hotplug events until a rules file is able to sucessfully handle it.

This is an interesting idea for a fix for the udev subproblem. However
again note that the / and /usr split/merge is a bigger thing than the
issues that just happen to manifest in udev. Perhaps right now they're
giving up on it because they'd rather not waste time fixing a sub
problem when fixing the / and /usr split fixes udev with less effort.

> And rules files should perform sanity checking and feedback in the
> form of "WTF? No, I can't do that yet. Wake me later."

$ equery belongs udev/rules.d/|wc -l
36

On just my system, 36 different packages and god knows how many
different upstreams / maintainers write to udev/rules.d. And that's
Gentoo. How about Fedora. How about Red Hat. How about Debian, Ubuntu
and god knows how many packages and distros that nobody can guarantee
is going to use entirely new syntax.

Face it - the udev guys are not going to be in control of whoever
writes the rules. Yes, having wait / dependencies in udev might be a
neat feature, but there's no guarantee they'll be implemented because
they're not part of udev itself.

On the other hand you can just edit the system so that the _default
setting_ makes it unnecessary to specify dependencies for like 99.xx%
of programs out there.

>  systemd does
> something interesting with its "After" clause; that makes perfect
> sense. And that's why I asked Canek why one couldn't write a systemd
> service file to treat /usr as a service

Again, it's not enough to have just a passing understanding of the
problem and talk airy abstractions about solutions. You really have to
have an understanding of the problem space.

systemd, for similar reasons to udev, is installed to /usr by default.
This means that systemd won't even be runnable if /usr isn't
available, so it won't even be possible to treat /usr as a service. So
what you're saying makes no sense as far as typical systemd
installations are involved.

Now, if you installed systemd to / instead of to /usr, then yes you
could create a /usr service which everything else would be dependent
on. But you'd conspicuously make almost everything useful it does
dependent on /usr, challenging the assumption that it should be
separate in the first place. You would, for example, force
90-something percent of your unit files to have an extra dependency
line that smells like it came from boilerplate kitchen, one of the
things systemd was supposed to be designed to minimise.

>> [2] fuse-based filesystems allow an administrator the crazy
>> possibility of, for example, demanding that /home be an ssh
>> connection. Should the ssh client belong in /? ftp? substitute any
>> arbitrary client program.
>
> System dependent binaries and libraries aren't commonly placed in
> /home. Your better argument would have been fuse-mounted /usr...in
> which case it would be the administrator's responsibility to ensure
> said arbitrary client program is present in /bin, and its libraries in
> /lib.

It's misleading to think that /home being in ssh is an issue, because
the point is that the purpose of the root filesystem is:

"To boot a system, enough must be present on the root partition to
mount other filesystems. This includes utilities, configuration, boot
loader information, and other essential start-up data."

In other words, if /home is one of the "other filesystems" tools for
mounting it should, according to FHS, be in the root filesystem.
You're confusing that with the idea binaries are essential. And by the
way, if you had emacs-daemon as an init service, it would depend on
/home being mounted to be able to read the user's startup, or other
similar things like that, so your system would not start up completely
unless you had /home mounted.

Now you say that it's alright, in this case, the sysad makes ssh
available at /bin. But this undermines the primary FHS rationale: for
binaries to be in _predictable_ locations for both the sysad AND the
software packager.

To implement this, then, as either the user / software packager /
distro maintainer, I now have to do an intelligent check on /etc/fstab
to determine that no filesystems are mounted on fuse. This demands, of
course, a table of possible filesystem names and the corresponding
client programs (currently not codified), plus that check to
/etc/fstab. So the spec _fails to achieve its goal_ for systems where
table of client-fuse mappings is not codified: practically all of
them.

Compare: if all executables were in /usr FHS would have no problem
locating the client binaries, because they're all in the same place.

>
>> [3] a fuse-based filesystem depends on a local network service being
>> started. For example, someone writes a crazy fuse mysql browser that
>> also is coincidentally mounted at boot time. Should the mysqld service
>> belong in /? ldap? substitute any arbitrary server program.
>
> I seriously cannot imagine anyone doing this except as a prank. The
> only similar case I can think of would have the db server on a
> separate machine.

Well I did say he was crazy ;)

>
> And if an administrator decides to do this, it's his responsibility to
> make sure mysqld is located in /bin, its libraries are in /lib...and
> he's got to find some place other than /var for his database! By this
> point, you've gone so far into reducto ad absurdum I honestly can't
> imagine anyone apart from someone who has absolutely _no_ idea what
> they're doing landing themselves in that situation.
>

More or less same as above. Since the admin is now manually moving
things around, the spec _fails to achieve its goal_.

Compare: if all executables were in /usr FHS would have no problem
locating the server binaries, because they're all in the same place.

>> [4] /root (which is why it's separated from /home) contains docs and
>> custom utilities used by root user for recovery. Unfortunately,
>> there's a lot of perl scripts there specifically for doing filesystem
>> checks / reports. Should perl be in in /? substitute any scripting
>> language.
>
> You quoted FHS. I'll quote it back to you:
>
> "/usr, /opt, and /var are designed such that they may be located on
> other partitions or filesystems."
>
> /root is ridiculously out of the question. /home isn't defended by the
> spec, but it's commonly enough separated that it's difficult to
> imagine someone making that error twice.

/root is the home directory of the root user. If it's not available
there, it defaults to the root directory (/). The point being the root
user has its own storage that defaults to the root directory,
independent of /home or whatnot.

http://www.pathname.com/fhs/pub/fhs-2.3.html#FTN.AEN1037

One good reason why it's separated from /home is because the root user
may download or store his own stuff there relevant to fixing that
machine. For example, post-install notes are often placed in /root,
which detail which packages were selected upon installation. Or while
performing lengthy system maintainance, the sysad may write down their
upgrade notes, or snip relevant tcpdumps, or what-have-you and store
them in the /root directory while the /home directory is unavailable.

It is very conceivable for the /root directory to contain perl scripts
or whatever the sysad has downloaded in his adventures to grep through
his logs and find out what the heck is going on in his system and/or
repair it.

Should perl be in / or /usr?

Again compare: if all executables were in /usr FHS would have no
problem locating perl.

> What's funny is the gratuitous misreading of the spec that exists, the
> anticipation that it would explicitly state more than it does, the
> weak technical arguments (so far) in favor of merging / and /usr, and
> the dogmatic defense of the merge.

You have to think the individual cases through ;)

>
> With a system such as portage, it should be entirely possible (with
> few code changes) to configure installation targets (/ vs /usr) on a
> per-package basis, and have that trickle down the dependency chain.

Yes, that should be. In fact I think that's the cleanest way to push
through so far. Just add a USE=prefix-root to udev.
--
This email is:    [ ] actionable   [ ] fyi        [x] social
Response needed:  [ ] yes          [x] up to you  [ ] no
Time-sensitive:   [ ] immediate    [ ] soon       [x] none

Re: [Bulk] Re: [gentoo-user] Re: Anyone switched to eudev yet?

[Michael Mol]

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

On Thu, Dec 27, 2012 at 5:37 PM, Mark David Dumlao <madumlao@gmail.com>
wrote:
> On Fri, Dec 28, 2012 at 4:59 AM, Michael Mol <mikemol@gmail.com> wrote:
>> On Thu, Dec 27, 2012 at 3:16 PM, Mark David Dumlao <madumlao@gmail.com>
wrote:
>>> On Fri, Dec 28, 2012 at 2:40 AM, Michael Mol <mikemol@gmail.com> wrote:
>>>>> or the fact that some udev programs tend to
>>>>> be located in /usr,
>>>>
>>>>
>>>> That's either a bug with those programs, or a need for architectural
>>>> improvements within udev. Both plausible answers.
>>>>
>>>
>>> The most obvious architectural improvement being: simply place udev
>>> where all its dependencies are and all those bugs turn to nothing.
>>> Which is what the udev guys did. And the part which seems to elude
>>> everyone is: it isn't even a limitation of the program. It can still
>>> be installed to /. Heck we could probably make a USE=root-prefix flag
>>> for udev that installs it to / instead of /usr.
>>
>> This came up today on Reddit. I think it's _highly_ relevant.
>>
>> http://www.runswift.ly/solving-bugs.html
>>
>> Moving into a full dependency on initr* for separate /usr is a 'fix',
>> not a solution.
>>
>
> This is where you stumble. It's not a fix. It's a WONTFIX. It's a
> "make a lot of noise so that something else gets fixed because this is
> outside of our domain and we're not going to be responsible for it as
> it wasnt our bug in the first place". And that something else happens
> to be the / and /usr split conflicting with the user programs.

I understand that. I made that point myself; that the Gentoo dev moved udev
into /usr to reduce the bug passing load on himself.

>
> If you give the squeaky wheel the grease - as in merge / and /usr -
> you apply the fix independently of udev, which was simply installed to
> the /usr prefix. THAT is a solution - one independent of udev and
> again, does not depend on initr*. You don't have to.

That's one solution, but the cure is worse than the disease.

>
>>>
>>>>
>>>>>
>>>>> or even just a solid detailed specification on the
>>>>> precise criteria for inclusion into /.
>>>>
>>>>
>>>> For anyone arguing that / and /usr should be separate, the answer to
this is
>>>> "that ought to be common sense."
>>>>
>>>> Since I'm not someone who knows all there is to know about the
software and
>>>> interactions thereof, the most I can say is:
>>>>
>>>> * / ought to contain all binaries, libraries and static data necessary
for
>>>> booting beyond the point where / is mounted, and any machine-specific
>>>> binaries, libraries and static data.
>>>> * /usr ought to contain all binaries, libraries and static data not
>>>> necessary for its own mount.
>>>>
>>>
>>> I'm sure you mean well, as did most of the architects of the past, but
>>> the reality is, this simplistic take on the problem misses out on some
>>> fundamental issues. Yes, you mention later that the spec just doesn't
>>> specify what happens in such and such case, and try to trivialize it
>>> into saying people think that specs should "be able to do their
>>> thinking for them". But unfortunately, specifying what happens is
>>> exactly what specs are for!
>>
>> Does the term "overspecification" mean anything to you? Specs cannot
>> and should not specify every possible conceivable related thing.
>
> Two things.
>
> First, I'm not saying that a spec should specify everything. I am
> saying, however, that there are specific cases that is within its
> domain to specify and that it should be specifying. And because those
> cases generate conflicts, the fact that they aren't is a bug.

The spec also doesn't say anything about /usr/lib vs /usr/lib32 vs
/usr/lib64, yet decisions about those can also cause conflicts. I suppose
you'd argue that that's also a bug.

I already gave you a pretty succinct definition of what I thought the
treatment of /usr should be. And you quoted FHS on the subject, which was
eerily similar to what I described. Now, further down, you actually raise
specific issues. Let's focus on those.

>
> Second, going back to problem solving in general - just because you
> can put down in words what you think the problem is, doesn't mean
> you've mapped out an accurate or even consistent statement of the
> problem. There really are cases where it's not enough to just give
> general airy abstractions and rules of thumb to map out a problem,
> where it isn't obvious that you're running into edge cases until you
> really look at it deeply, and yes, the / and /usr split is one of
> them.

So let's look at it deeply, since nobody else will. I'm game. This is the
most detailed technical discussion of the problem anyone's cared to
actually have, as far as I've been able to observe.

>
>>> And the "we have a standard" part is effectively not true anymore, on
>>> the matter of the / and /usr split. That is - what the specification
>>> says should happen is not happening, on a massive scale, because it
>>> turns out that it's not that trivial to determine which binaries go in
>>> / and which go in /usr.
>>
>> Give me an example, and I'll describe a reasonably detailed solution.
>> It would be my pleasure.
>
> The most fundamental and relevant one for us Gentoo users is this:
> - how can /usr be sharable among different hosts if it depends on
> libraries in /?
>
> """
> http://www.pathname.com/fhs/pub/fhs-2.3.html#THEUSRHIERARCHY
>
> Purpose
>
> /usr is the second major section of the filesystem. /usr is shareable,
> read-only data. That means that /usr should be shareable between
> various FHS-compliant hosts and must not be written to. Any
> information that is host-specific or varies with time is stored
> elsewhere.
> """
>
> Many distros place fundamental libraries that many programs in /usr
> depend on in /lib. Especially bad for Gentoo - libraries in /lib may
> be recompiled as same-version variants if you want to change the USE
> flags, resulting in clients that don't synchronously recompile their
> own libraries in /lib to both silently and noisily fail.
>
> In other words, many programs in /usr in practice are functionally
> inseparable from the libraries in /, conflicting with the notion that
> they were properly shared in the first place.

There are certain implicit assumptions made in the spec that are important.

First, it's assumed the binaries are compatible with all the hosts. It's
assumed you're not sharing s360 binaries with x86 hosts, or sparc binaries
with ppc hosts.

From there, it's reasonable to assume that the authors of the spec assume
the administrator to be smart enough to not do things like:
* Mix compiler versions
* Mix program compile options
* Place a dependency on a binary that's going to be missing.

The spec is very, very much a "do what you want within these guidelines;
don't shoot yourself in the foot" thing, it's very much not a declarative
bikeshedding of everything related to it.

>
> Compare this with the alternate spec that /usr contains both the
> programs and the libraries. In which case there is no possibility of
> the programs being out of sync with the libraries. From a maintainance
> perspective, this reduces the number of points of failure in upgrading
> the central NFS share.

If I were doing a shared-/usr-over-NFS setup, here's how I'd do it:

1) Have two NFS shares for /usr, A and B.
2) Have all my clients configured to draw from A.
3) Perform my upgrade on B.
4) Prepare my upgraded client image matching the data on B. Upgraded client
image would mount B for /usr.
5) Replace my clients targeting A with clients targeting B.

And tick-tock between A and B. Or proceed A->B->C, removing old shares once
they're no longer needed.

Either that, or do the whole thing flag-day style.

And in any case, I wouldn't share /usr between images with different roles.
That way lies madness.

>
> Please note, though, that the / vs /usr issue is a bigger thing after
> all than udev, and only happens to be a udev-centric discussion
> because it's one of the most obvious cases of the spec going awry.

It's a udev-centric discussion right now because the udev+systemd group
chose to take the position that the spec was at fault. I'm arguing with you
here to show why they're wrong.

>
>>> * some teasers:
>>> [1] udev rules themselves being a case in point. I mean, do the
>>> requisite binaries belong in /?
>>
>> Udev is a dispatcher. Actually, in substance, it's a piece of the
>> kernel that resides in userland; it exists because it was decided back
>> around the time of devfs that what devfs was doing is something that
>> ought to be outside the kernel. In reality, it's effectively been a
>> userland kernel-support process its entire life.
>>
>> What should probably happen is that udev should be fixed to defer
>> hotplug events until a rules file is able to sucessfully handle it.
>
> This is an interesting idea for a fix for the udev subproblem. However
> again note that the / and /usr split/merge is a bigger thing than the
> issues that just happen to manifest in udev. Perhaps right now they're
> giving up on it because they'd rather not waste time fixing a sub
> problem when fixing the / and /usr split fixes udev with less effort.

When we went from x86 to x86_64, we didn't consider it the processor's
fault for badly-written packages misbehaving. As we went from 8-bit
codepages to UTF-8, we didn't consider it UTF-8's fault for badly-written
packages misbehaving. As we go from IPv4 to IPv6, most don't consider it
IPv6's fault when packages start misbehaving.

We say the package needs to be fixed.

So what on earth makes this different? While I understand why *systemd*
should care about badly-written packages with cross-mount-point
dependencies, I don't understand why udev should, or why udev's direction
so be so *completely* subsumed by systemd's direction.

(For the record, I believe systemd likely cares about badly-written
packages because of its already extraordinarily sophisticated complex
behavior involving extremely high levels of concurrency that *will* make
debugging far more difficult. You'll need some amazing advancements in
concurrency-bug-detecting tools to cope with the kinds of debugging issues
systemd would make the *norm* for rolling distros like Gentoo, Arch or
Debian/unstable. Imagine trying to debug concurrency issues that crop up
because program A and program B have an unanticipated influence on each
other, and a race condition exists because they're launching in parallel.
The Linux scheduler and debugging APIs will need to add some means of
halting multiple processes at the same time, just to break into the mess!)

>
>> And rules files should perform sanity checking and feedback in the
>> form of "WTF? No, I can't do that yet. Wake me later."
>
> $ equery belongs udev/rules.d/|wc -l
> 36
>
> On just my system, 36 different packages and god knows how many
> different upstreams / maintainers write to udev/rules.d. And that's
> Gentoo. How about Fedora. How about Red Hat. How about Debian, Ubuntu
> and god knows how many packages and distros that nobody can guarantee
> is going to use entirely new syntax.

So? If a package is broken, *it should be fixed*. I keep pounding that
point over and over. Shoving crap into an initramfs, or shoving everything
into /usr, or merging / and /usr, doesn't _solve_ complexity problems, it
_hides_ it. That's the kind of problem I was trying to allude to with my
link to that "fix vs solutions" blog post.

>
> Face it - the udev guys are not going to be in control of whoever
> writes the rules.

I wouldn't expect them to. And I don't care; it's not *their*
responsibility. It's the responsibility of the package maintainer.

It seems like everybody is pointing at the udev folks as the people who
should implement a solution for other people's broken packages, and this
strikes me as bass-ackward.

> Yes, having wait / dependencies in udev might be a
> neat feature, but there's no guarantee they'll be implemented because
> they're not part of udev itself.

Perhaps they'll get implemented in eudev. If I had the time, I'd write up
the patches myself. The concepts aren't that hard.

>
> On the other hand you can just edit the system so that the _default
> setting_ makes it unnecessary to specify dependencies for like 99.xx%
> of programs out there.

And why is this a thing that needs to be done except on an as-needed basis?
The only answer I can come up with is that the systemd boot process is
going to be a royal pain to debug, given its high degree of concurrency.
Quite frankly, that's like issuing body armor to everyone in a factory
because someone got hit with a piece of broken glass from a beer bottle
crushed by a heavy piece of machinery; it's an overreaction that reduces
everyone's agility in response to something whose presence was already a
violation of policy and good sense.

>
>>  systemd does
>> something interesting with its "After" clause; that makes perfect
>> sense. And that's why I asked Canek why one couldn't write a systemd
>> service file to treat /usr as a service
>
> Again, it's not enough to have just a passing understanding of the
> problem and talk airy abstractions about solutions. You really have to
> have an understanding of the problem space.
>
> systemd, for similar reasons to udev, is installed to /usr by default.

Please, explain these reasons. I've described what I believe these reasons
to be, but the only reasons given to me so far are that "it makes a bunch
of other badly-written or badly-packages programs behave better." I hold
that that's a fundamental misplacement of responsibility.

> This means that systemd won't even be runnable if /usr isn't
> available, so it won't even be possible to treat /usr as a service. So
> what you're saying makes no sense as far as typical systemd
> installations are involved.
>
> Now, if you installed systemd to / instead of to /usr, then yes you
> could create a /usr service which everything else would be dependent
> on. But you'd conspicuously make almost everything useful it does
> dependent on /usr, challenging the assumption that it should be
> separate in the first place.

Almost everything useful the kernel does depends on the presence of an
init. Does that seriously challenge the assumption that init should be
separate from the kernel?

> You would, for example, force
> 90-something percent of your unit files to have an extra dependency
> line that smells like it came from boilerplate kitchen, one of the
> things systemd was supposed to be designed to minimise.

The problem with this argument is that it really does come down to a
tradeoff largely based in philosophy. It's a question of expressiveness vs
a combination of capability-of-completeness and flexibility.

And, frankly, if it matters, there are ways to improve the language. Every
dependency-aware package manager since the concept existed has had to
grapple with all the same problems. This is not a space where new work is
needed to come up with something useful, flexible and largely complete.
And, frankly, systemd is trying to reinvent it. It's the same as the cycle
of invention in everything in software; "A is ugly and complex. Let's write
B to be lean, mean and fast." "B isn't flexible enough to handle these use
cases we didn't anticipate, but need to support." "B is ugly and complex.
Let's write C to be lean, mean and fast."

(Heck, before you know it, init system configuration files will be written
in Common Lisp. :P )

>
>>> [2] fuse-based filesystems allow an administrator the crazy
>>> possibility of, for example, demanding that /home be an ssh
>>> connection. Should the ssh client belong in /? ftp? substitute any
>>> arbitrary client program.
>>
>> System dependent binaries and libraries aren't commonly placed in
>> /home. Your better argument would have been fuse-mounted /usr...in
>> which case it would be the administrator's responsibility to ensure
>> said arbitrary client program is present in /bin, and its libraries in
>> /lib.
>
> It's misleading to think that /home being in ssh is an issue, because
> the point is that the purpose of the root filesystem is:

Wha? *You're* the one who brought up /home in the first place.

>
> "To boot a system, enough must be present on the root partition to
> mount other filesystems. This includes utilities, configuration, boot
> loader information, and other essential start-up data."
>
> In other words, if /home is one of the "other filesystems" tools for
> mounting it should, according to FHS, be in the root filesystem.

Why would /home be "one of the 'other filesystems' tools for mounting"? You
made a jump here I seriously don't follow. Are we talking credentials? That
kind of thing that's usually kept under /etc.

> You're confusing that with the idea binaries are essential. And by the
> way, if you had emacs-daemon as an init service, it would depend on
> /home being mounted to be able to read the user's startup, or other
> similar things like that, so your system would not start up completely
> unless you had /home mounted.

I'm frankly unfamiliar with emacs-daemon, but (from what you say), it's
either broken, or was never, ever intended to be run as an init service.

>
> Now you say that it's alright, in this case, the sysad makes ssh
> available at /bin. But this undermines the primary FHS rationale: for
> binaries to be in _predictable_ locations for both the sysad AND the
> software packager.

The sysad controls the package manager. Regardless of the distribution,
package placement should _always_ be done via the package manager. This is
why every package management system that exists is accompanied with a tool
for importing other package management systems' packages. Including binary
and source tarballs.

>
> To implement this, then, as either the user / software packager /> distro
maintainer, I now have to do an intelligent check on /etc/fstab
> to determine that no filesystems are mounted on fuse.

This doesn't follow, since you haven't explained what you need /home for!
Credentials are typically kept under /etc.

> This demands, of
> course, a table of possible filesystem names and the corresponding
> client programs (currently not codified), plus that check to
> /etc/fstab. So the spec _fails to achieve its goal_ for systems where
> table of client-fuse mappings is not codified: practically all of
> them.

Irrelevant, because the scenario is invalid.

>
> Compare: if all executables were in /usr FHS would have no problem
> locating the client binaries, because they're all in the same place.

And defeats existing functional systems without valid purpose. (Where I
hold that presuming responsibility of packages' dependencies is somehow
udev/systemd's responsibility, rather than that of the package authors and
maintainers, is invalid.)

>
>>
>>> [3] a fuse-based filesystem depends on a local network service being
>>> started. For example, someone writes a crazy fuse mysql browser that
>>> also is coincidentally mounted at boot time. Should the mysqld service
>>> belong in /? ldap? substitute any arbitrary server program.
>>
>> I seriously cannot imagine anyone doing this except as a prank. The
>> only similar case I can think of would have the db server on a
>> separate machine.
>
> Well I did say he was crazy ;)
>
>>
>> And if an administrator decides to do this, it's his responsibility to
>> make sure mysqld is located in /bin, its libraries are in /lib...and
>> he's got to find some place other than /var for his database! By this
>> point, you've gone so far into reducto ad absurdum I honestly can't
>> imagine anyone apart from someone who has absolutely _no_ idea what
>> they're doing landing themselves in that situation.
>>
>
> More or less same as above. Since the admin is now manually moving
> things around, the spec _fails to achieve its goal_.

The presumption is that the admin would use the tools available to him to
achieve his goals in a consistent fashion. We consider it an error for
packages to be manually installed into /usr/ as opposed to /usr/local. Why
would you think I wouldn't consider it an error for a package to be
manually installed into /?

*Anything* an admin does without the knowledge of his package manager is
his own fault if it blows up in his face. This is why he is provided with a
package manager in the first place.

>
> Compare: if all executables were in /usr FHS would have no problem
> locating the server binaries, because they're all in the same place.

Hold off on the compares until we have something useful to compare to.

>
>>> [4] /root (which is why it's separated from /home) contains docs and
>>> custom utilities used by root user for recovery. Unfortunately,
>>> there's a lot of perl scripts there specifically for doing filesystem
>>> checks / reports. Should perl be in in /? substitute any scripting
>>> language.
>>
>> You quoted FHS. I'll quote it back to you:
>>
>> "/usr, /opt, and /var are designed such that they may be located on
>> other partitions or filesystems."
>>
>> /root is ridiculously out of the question. /home isn't defended by the
>> spec, but it's commonly enough separated that it's difficult to
>> imagine someone making that error twice.
>
> /root is the home directory of the root user. If it's not available
> there, it defaults to the root directory (/). The point being the root
> user has its own storage that defaults to the root directory,
> independent of /home or whatnot.
>
> http://www.pathname.com/fhs/pub/fhs-2.3.html#FTN.AEN1037
>
> One good reason why it's separated from /home is because the root user
> may download or store his own stuff there relevant to fixing that
> machine. For example, post-install notes are often placed in /root,
> which detail which packages were selected upon installation. Or while
> performing lengthy system maintainance, the sysad may write down their
> upgrade notes, or snip relevant tcpdumps, or what-have-you and store
> them in the /root directory while the /home directory is unavailable.

Of course. This is why /root as a separate filesystem is ridiculously out
of the question.

>
> It is very conceivable for the /root directory to contain perl scripts
> or whatever the sysad has downloaded in his adventures to grep through
> his logs and find out what the heck is going on in his system and/or
> repair it.
>
> Should perl be in / or /usr?

Now that is a good question, if only because Perl traditionally _loathes_
being in /bin, for its own philosophical reasons.

Now, as a practical matter? WTF are the scripts written in Perl? Or in
anything other than sh? If they're intended for emergency use, they've got
some pretty fat dependencies, and should probably be launched from a full
rescue environment instead. Or the log files should be copied to some place
with more featureful tools available.

>
> Again compare: if all executables were in /usr FHS would have no
> problem locating perl.

If you need a Cadillac for bootstrapping and emergency maintenance, sure.
But this is one of those scenarios that experience and good sense teaches
you to avoid. Once-in-a-blue-moon scripts are useful when they're
needed--until they blow up because they were written for a version of the
language that's incompatible with what's installed. That's why sh-fu is
such a vital skill for admins. sh is everywhere. Even where bash isn't.

So, I still disagree with your example scenario.

>
>> What's funny is the gratuitous misreading of the spec that exists, the
>> anticipation that it would explicitly state more than it does, the
>> weak technical arguments (so far) in favor of merging / and /usr, and
>> the dogmatic defense of the merge.
>
> You have to think the individual cases through ;)

I've responded.

>
>>
>> With a system such as portage, it should be entirely possible (with
>> few code changes) to configure installation targets (/ vs /usr) on a
>> per-package basis, and have that trickle down the dependency chain.
>
> Yes, that should be. In fact I think that's the cleanest way to push
> through so far. Just add a USE=prefix-root to udev.

Make it default. The change of default to /usr is what's ridiculously
stupid about the current scenario.

And, frankly, if this is as much an issue as it's described to be, then
something beyond USE flags is necessary. A different per-package tunable is
needed.

-- 
:wq

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

Re: [Bulk] Re: [gentoo-user] Re: Anyone switched to eudev yet?

[Kevin Chadwick]

> > Should perl be in / or /usr?  
> 
> Now that is a good question, if only because Perl traditionally _loathes_
> being in /bin, for its own philosophical reasons.
> 


> Now, as a practical matter? WTF are the scripts written in Perl? Or in
> anything other than sh? If they're intended for emergency use, they've got
> some pretty fat dependencies, and should probably be launched from a full
> rescue environment instead. Or the log files should be copied to some place
> with more featureful tools available.


Can perl be built statically and moved to / by the admin for this
corner case?

If not you should have all the tools to fix /usr in root and then if
anything needs fixing via perl then you should be able to mount /usr or
mount -a and have a fully working single user system to run perl from.

-- 
_______________________________________________________________________

'Write programs that do one thing and do it well. Write programs to work
together. Write programs to handle text streams, because that is a
universal interface'

(Doug McIlroy)
_______________________________________________________________________

Re: [Bulk] Re: [gentoo-user] Re: Anyone switched to eudev yet?

[Michael Mol]

On Fri, Dec 28, 2012 at 9:10 AM, Kevin Chadwick <ma1l1ists@yahoo.co.uk> wrote:
>> > Should perl be in / or /usr?
>>
>> Now that is a good question, if only because Perl traditionally _loathes_
>> being in /bin, for its own philosophical reasons.
>>
>
>
>> Now, as a practical matter? WTF are the scripts written in Perl? Or in
>> anything other than sh? If they're intended for emergency use, they've got
>> some pretty fat dependencies, and should probably be launched from a full
>> rescue environment instead. Or the log files should be copied to some place
>> with more featureful tools available.
>
>
> Can perl be built statically and moved to / by the admin for this
> corner case?

Certainly, but you still have modules to consider...but those can of
course be bundled.

>
> If not you should have all the tools to fix /usr in root and then if
> anything needs fixing via perl then you should be able to mount /usr or
> mount -a and have a fully working single user system to run perl from.

Indeed. The only reason I can imagine this to not be the case is if
the mount for /usr fails. Most of the reasons imaginable also apply
equally strongly to initramfs+root-on-special-mount and
everything-in-/usr.

--
:wq

Re: [gentoo-user] Re: Anyone switched to eudev yet?

[Kevin Chadwick]

On Thu, 27 Dec 2012 00:01:58 +0800
Mark David Dumlao <madumlao@gmail.com> wrote:

> Nobody's telling you _your_ system, as in the collection of programs
> you use for your productivity, is broken. What we're saying is that
> _the_ system, as in the general practice as compared to the
> specification, is broken. Those are two _very_ different things.

If the spec and practice are out of sync then if possible as this
thread demonstrates most and is perfectly possible then you fix the
practice and do not erode the spec.

Re: [gentoo-user] Re: Anyone switched to eudev yet?

[Neil Bothwick]

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

On Mon, 24 Dec 2012 13:23:16 -0800, Mark Knecht wrote:

> I don't like, really don't like, the work that currently goes into
> making my 'init thingy' work. All the Gentoo docs about creating
> hierarchies by hand and populating them with files and then compressing
> it. All that drives me nuts. It should be 100% automatic, and probably
> is with the right tools which I haven't found.

The right tools are included, and documented, with your kernel. Create a
plain text config file detailing the contents of the initramfs and set
CONFIG_INITRAMFS_SOURCE to the path top  this file. That and an init
script are all you need to have the initramfs automatically built with
the current versions of all files when you compile your kernel.

No messing around with copying files from the main filesystem or calling
arcane incantations involving cpio, "make all" takes care of it all.

-- 
Neil Bothwick

COBOL: (n.) an old computer language, designed to be read and not
       run. Unfortunately, it is often run anyway.

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

Re: [gentoo-user] Re: Anyone switched to eudev yet?

[Mark Knecht]

On Tue, Dec 25, 2012 at 1:19 PM, Neil Bothwick <neil@digimed.co.uk> wrote:
> On Mon, 24 Dec 2012 13:23:16 -0800, Mark Knecht wrote:
>
>> I don't like, really don't like, the work that currently goes into
>> making my 'init thingy' work. All the Gentoo docs about creating
>> hierarchies by hand and populating them with files and then compressing
>> it. All that drives me nuts. It should be 100% automatic, and probably
>> is with the right tools which I haven't found.
>
> The right tools are included, and documented, with your kernel. Create a
> plain text config file detailing the contents of the initramfs and set
> CONFIG_INITRAMFS_SOURCE to the path top  this file. That and an init
> script are all you need to have the initramfs automatically built with
> the current versions of all files when you compile your kernel.
>
> No messing around with copying files from the main filesystem or calling
> arcane incantations involving cpio, "make all" takes care of it all.
>
> --
> Neil Bothwick


If you have one handy and it's not something huge (I don't think it is
but I don't really know) maybe you could post an example of what that
file looks like?

Thanks,
Mark

Re: [gentoo-user] Re: Anyone switched to eudev yet?

[Neil Bothwick]

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

On Tue, 25 Dec 2012 14:00:36 -0800, Mark Knecht wrote:

> > The right tools are included, and documented, with your kernel.
> > Create a plain text config file detailing the contents of the
> > initramfs and set CONFIG_INITRAMFS_SOURCE to the path top  this file.
> > That and an init script are all you need to have the initramfs
> > automatically built with the current versions of all files when you
> > compile your kernel.

> If you have one handy and it's not something huge (I don't think it is
> but I don't really know) maybe you could post an example of what that
> file looks like?

This is the file I use on a system that has / on a LUKS filesystem on top
of LVM. The format is documented in the kernel docs at
Documentation/filesystems/ramfs-rootfs-initramfs.txt


dir /bin 755 0 0
file /bin/busybox /bin/busybox 755 0 0
slink /bin/sh busybox 777 0 0

dir /realroot 755 0 0
dir /etc 755 0 0
dir /proc 755 0 0
dir /sys 755 0 0

dir /sbin 755 0 0
file /sbin/lvm.static /sbin/lvm.static 755 0 0
#file /sbin/mdadm /sbin/mdadm 755 0 0
file /sbin/cryptsetup /sbin/cryptsetup 755 0 0

file /sbin/e2fsck /sbin/e2fsck 755 0 0
dir /lib 755 0 0
file /lib/libext2fs.so /usr/lib64/libext2fs.so 755 0 0

dir /dev 755 0 0
nod /dev/console 600 0 0 c 5 1
nod /dev/null 666 0 0 c 1 3
nod /dev/tty 666 0 0 c 5 0
nod /dev/urandom 666 0 0 c 1 9

file /init /usr/src/init.sh 755 0 0


-- 
Neil Bothwick

Don't take life too seriously, you won't get out alive.

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

Re: [gentoo-user] Re: Anyone switched to eudev yet?

[Mark Knecht]

On Tue, Dec 25, 2012 at 2:13 PM, Neil Bothwick <neil@digimed.co.uk> wrote:
> On Tue, 25 Dec 2012 14:00:36 -0800, Mark Knecht wrote:
>
>> > The right tools are included, and documented, with your kernel.
>> > Create a plain text config file detailing the contents of the
>> > initramfs and set CONFIG_INITRAMFS_SOURCE to the path top  this file.
>> > That and an init script are all you need to have the initramfs
>> > automatically built with the current versions of all files when you
>> > compile your kernel.
>
>> If you have one handy and it's not something huge (I don't think it is
>> but I don't really know) maybe you could post an example of what that
>> file looks like?
>
> This is the file I use on a system that has / on a LUKS filesystem on top
> of LVM. The format is documented in the kernel docs at
> Documentation/filesystems/ramfs-rootfs-initramfs.txt
>

Thanks for the Xmas present! I've wanted to try it this way but never
got up the energy to go do it all from scratch on my own. This should
help me (and maybe Dale?) ;-) ;-) alot.

Cheers,
Mark

Re: [gentoo-user] Re: Anyone switched to eudev yet?

[Dale]

Mark Knecht wrote:
> On Tue, Dec 25, 2012 at 2:13 PM, Neil Bothwick <neil@digimed.co.uk> wrote:
>> On Tue, 25 Dec 2012 14:00:36 -0800, Mark Knecht wrote:
>>
>>>> The right tools are included, and documented, with your kernel.
>>>> Create a plain text config file detailing the contents of the
>>>> initramfs and set CONFIG_INITRAMFS_SOURCE to the path top  this file.
>>>> That and an init script are all you need to have the initramfs
>>>> automatically built with the current versions of all files when you
>>>> compile your kernel.
>>> If you have one handy and it's not something huge (I don't think it is
>>> but I don't really know) maybe you could post an example of what that
>>> file looks like?
>> This is the file I use on a system that has / on a LUKS filesystem on top
>> of LVM. The format is documented in the kernel docs at
>> Documentation/filesystems/ramfs-rootfs-initramfs.txt
>>
> Thanks for the Xmas present! I've wanted to try it this way but never
> got up the energy to go do it all from scratch on my own. This should
> help me (and maybe Dale?) ;-) ;-) alot.
>
> Cheers,
> Mark
>
>


I'm waiting on eudev myself.  I'm going to enjoy the heck out of typing
in "rm -rfv /boot/init*".  Then I can remove it from grub.conf and it is
history.  Hopefully for a LONG time too. 

Dale

:-)  :-) 

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

Re: [gentoo-user] Re: Anyone switched to eudev yet?

[Mark Knecht]

On Tue, Dec 25, 2012 at 3:04 PM, Dale <rdalek1967@gmail.com> wrote:
> Mark Knecht wrote:
>> On Tue, Dec 25, 2012 at 2:13 PM, Neil Bothwick <neil@digimed.co.uk> wrote:
>>> On Tue, 25 Dec 2012 14:00:36 -0800, Mark Knecht wrote:
>>>
>>>>> The right tools are included, and documented, with your kernel.
>>>>> Create a plain text config file detailing the contents of the
>>>>> initramfs and set CONFIG_INITRAMFS_SOURCE to the path top  this file.
>>>>> That and an init script are all you need to have the initramfs
>>>>> automatically built with the current versions of all files when you
>>>>> compile your kernel.
>>>> If you have one handy and it's not something huge (I don't think it is
>>>> but I don't really know) maybe you could post an example of what that
>>>> file looks like?
>>> This is the file I use on a system that has / on a LUKS filesystem on top
>>> of LVM. The format is documented in the kernel docs at
>>> Documentation/filesystems/ramfs-rootfs-initramfs.txt
>>>
>> Thanks for the Xmas present! I've wanted to try it this way but never
>> got up the energy to go do it all from scratch on my own. This should
>> help me (and maybe Dale?) ;-) ;-) alot.
>>
>> Cheers,
>> Mark
>>
>>
>
>
> I'm waiting on eudev myself.  I'm going to enjoy the heck out of typing
> in "rm -rfv /boot/init*".  Then I can remove it from grub.conf and it is
> history.  Hopefully for a LONG time too.

Sure, if eudev ever really happens.

In the meantime, if you followed Neil's example here, you'd be doing

rm -rfv init*

today.

Think about it! :-)

Cheers,
Mark

Re: [gentoo-user] Re: Anyone switched to eudev yet?

[Dale]

Mark Knecht wrote:
> On Tue, Dec 25, 2012 at 3:04 PM, Dale <rdalek1967@gmail.com> wrote:
>> Mark Knecht wrote:
>>> On Tue, Dec 25, 2012 at 2:13 PM, Neil Bothwick <neil@digimed.co.uk> wrote:
>>>> On Tue, 25 Dec 2012 14:00:36 -0800, Mark Knecht wrote:
>>>>
>>>>>> The right tools are included, and documented, with your kernel.
>>>>>> Create a plain text config file detailing the contents of the
>>>>>> initramfs and set CONFIG_INITRAMFS_SOURCE to the path top  this file.
>>>>>> That and an init script are all you need to have the initramfs
>>>>>> automatically built with the current versions of all files when you
>>>>>> compile your kernel.
>>>>> If you have one handy and it's not something huge (I don't think it is
>>>>> but I don't really know) maybe you could post an example of what that
>>>>> file looks like?
>>>> This is the file I use on a system that has / on a LUKS filesystem on top
>>>> of LVM. The format is documented in the kernel docs at
>>>> Documentation/filesystems/ramfs-rootfs-initramfs.txt
>>>>
>>> Thanks for the Xmas present! I've wanted to try it this way but never
>>> got up the energy to go do it all from scratch on my own. This should
>>> help me (and maybe Dale?) ;-) ;-) alot.
>>>
>>> Cheers,
>>> Mark
>>>
>>>
>>
>> I'm waiting on eudev myself.  I'm going to enjoy the heck out of typing
>> in "rm -rfv /boot/init*".  Then I can remove it from grub.conf and it is
>> history.  Hopefully for a LONG time too.
> Sure, if eudev ever really happens.
>
> In the meantime, if you followed Neil's example here, you'd be doing
>
> rm -rfv init*
>
> today.
>
> Think about it! :-)
>
> Cheers,
> Mark
>
>

How would using a init thingy keep me from using a init thingy anyway? 
Huh?  <scratches head>

I don't have to have a init thingy today either.  Think about it.  LOL 
If I reboot and the init thingy fails, I just edit grub and bypass the
init thingy.  Fixed that pretty quick. ^_^

By the way, eudev is already in the tree but a dev on -dev said they had
a couple up coming fixes before needing any testing.  It is REALLY
happening.  ;-) 

Dale

:-)  :-) 

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

Re: [gentoo-user] Re: Anyone switched to eudev yet?

[Mark David Dumlao]

On Tue, Dec 25, 2012 at 4:00 AM, Dale <rdalek1967@gmail.com> wrote:
> If I put / on LVM, I need a init thingy.
No you don't. You could use a boot partition. Or grub2.

> So, worked for ages, then it breaks when people change where they put
> things.  Answer is, don't change where you put things.  Then things
> still work for most everyone, including me.  I'm not a programmer nor am
> I a rocket scientist but even I can see that.  If I can see it, I have
> no idea why a programmer can't other than being willingly blinded.  ;-)

You have no idea why it's being deprecated because you STAUNCHLY
REFUSE TO READ why so, even when it's blatantly being spelled out over
and over again why it's being done that way.

recap: many packages depending on udev keep putting stuff in their
udev rules that depend on binaries in /usr. It's not udev's
responsibility to fix or maintain these packages. Does it work for
you? Ok. That doesn't mean it isn't broken. There's a couple of
documents [1] [2] that spell out what /usr is supposed to be, and for
many distros, it's _failing_ to meet those standards.

[1] http://www.tldp.org/LDP/Linux-Filesystem-Hierarchy/html/usr.html
[2] http://www.pathname.com/fhs/pub/fhs-2.3.html#THEUSRHIERARCHY

Again:
/usr, according to what it's supposed to be, is deeply broken for a
large number of distros. Even when it works - for you. / merging with
/usr (or /, wherever the rest of the programs are supposed to be)
actually fixes the breakage, because then udev or whatever programs in
/ can't be out of sync with the programs it depends on.

The analogy here is like when people complained to Ted Tso that ext4
was not as stable was ext3 (exhibiting the same corruption problems as
seen in xfs). No, that's not true. ext3 just happened to have a quirky
behavior that gave the illusion of stability (the writes still failed
to reach the disk) _for programs that were written broken_. Come ext4,
which actually behaves as the standard is supposed to, and people
complain that ext4 is the broken one. It isn't.

Hm, was that a knock from the ghost of Unix past?

> Since there is a way to continue
> with the old way, which has worked for decades,

Yes there is one. An "init thingy" is just one of them and the means
to automatically make one is already available to all distros. Another
thing you could do is run an early mount script prior to running udev.
--
This email is:    [ ] actionable   [ ] fyi        [x] social
Response needed:  [ ] yes          [x] up to you  [ ] no
Time-sensitive:   [ ] immediate    [ ] soon       [x] none

Re: [gentoo-user] Re: Anyone switched to eudev yet?

[Michael Mol]

On Mon, Dec 24, 2012 at 4:43 PM, Mark David Dumlao <madumlao@gmail.com> wrote:
> On Tue, Dec 25, 2012 at 4:00 AM, Dale <rdalek1967@gmail.com> wrote:
>> If I put / on LVM, I need a init thingy.
> No you don't. You could use a boot partition. Or grub2.

I don't remember reading /boot as a suggested solution. Frankly,
that's an interesting idea.

And I'd completely forgotten about grub2. That actually sounds promising.

>
>> So, worked for ages, then it breaks when people change where they put
>> things.  Answer is, don't change where you put things.  Then things
>> still work for most everyone, including me.  I'm not a programmer nor am
>> I a rocket scientist but even I can see that.  If I can see it, I have
>> no idea why a programmer can't other than being willingly blinded.  ;-)
>
> You have no idea why it's being deprecated because you STAUNCHLY
> REFUSE TO READ why so, even when it's blatantly being spelled out over
> and over again why it's being done that way.
>
> recap: many packages depending on udev keep putting stuff in their
> udev rules that depend on binaries in /usr. It's not udev's
> responsibility to fix or maintain these packages.

Nobody ever argued that it was.

The reason this argument is so heated on this list has its roots in an
earlier discussion, going back about a year and a half ago. It started
when systemd was brought up as a response to one problem or another a
few times, and critiques and arguments against it were often met with
what read like bad-faith arguments in dismissive tones. Elsewhere,
systemd's architect met criticisms in a similarly dismissive fashion.
This made some folks (myself included) wary of systemd and anything it
controlled, simply because it seemed useless to try to participate in
rational critique.

Then udev announced it was going to merge into systemd's source tree
for better developer interop. At that point, some of us feared
(rightly, as it turned out) that the top-down, my-way-or-the-highway
attitude from systemd would take over udev, and that the close
proximity in the source tree would make it difficult for the udev
component to exist independently and in a stable fashion. (Where 'in a
stable fashion' means "doesn't become a moving target for anyone apart
from systemd trying to interoperate with it.) I remember feeling like
I'd just seen a train derail, and was watching a large, slow moving
train wreck.

Then came the declaration of "separate /usr is broken", much to the
dismay of those of us for whom that configuration truly did work just
fine. Yes, we understand that, in an overly complex system,
dependencies can get mixed up and you need to resolve that somehow.
(Personally, I think that any binary outside /usr that depends on
binaries or data inside /usr is broken and should be fixed.)

Then came the decision to move udev inside /usr, forcing the issue.
Now, it'd been long understood that udev *itself* hadn't been broken.
The explanation given as much as a year earlier was that udev couldn't
control what *other* packages gave it for rules scripts. OK, that's
not strictly udev's fault. That's the fault of packages being depended
on at too early a stage in the boot process. And, perhaps, hotplug
events for some devices _should_ be deferred until the proper
resources for handling it are available. I can think of at least a few
ways you could do that. And, yes, this was a problem systemd was
facing, and wasn't finding a way out of. (Why? I still don't know.
Maybe they didn't want to implement dependency declarations or demand
that packages impement partial functionality to reduce initial
dependencies.)

Still, instead, the decision was made by the systemd/udev management
to give udev the same _intrinsic_ dependency faults that systemd had,
and udev, previously, hadn't. Previously, udev was a tool that you
would use, and you would be expected to be wise while using it. Now,
udev is a tool that's lost some of its power in order to force an
environment more suitable for systemd.


--
:wq

Re: [gentoo-user] Re: Anyone switched to eudev yet?

[Bruce Hill]

On Mon, Dec 24, 2012 at 05:23:13PM -0500, Michael Mol wrote:
> 
> Then came the decision to move udev inside /usr, forcing the issue.
> Now, it'd been long understood that udev *itself* hadn't been broken.
> The explanation given as much as a year earlier was that udev couldn't
> control what *other* packages gave it for rules scripts. OK, that's
> not strictly udev's fault. That's the fault of packages being depended
> on at too early a stage in the boot process. And, perhaps, hotplug
> events for some devices _should_ be deferred until the proper
> resources for handling it are available. I can think of at least a few
> ways you could do that. And, yes, this was a problem systemd was
> facing, and wasn't finding a way out of. (Why? I still don't know.
> Maybe they didn't want to implement dependency declarations or demand
> that packages impement partial functionality to reduce initial
> dependencies.)

You're stumbling upon it ... just keep hashing it out.

The decision to write a new init system (systemd) and do things altogether
differently is exactly what caused your previously referred to train wreck.
And Kay Sievers collaborating with Lennart on this corrupted udev. Take those
two prima donnas out of the udev destruction, and no such init problem exists
today ... just as it didn't exist before then, for so many years.

Linus didn't tolerate what they did to module and firmware loading:

https://lkml.org/lkml/2012/10/2/303

and he placed the blame squarely on Lennart and Kay where it belongs. To quote
Linus Torvalds:

"What kind of insane udev maintainership do we have? And can we fix it?"

Bank on it ... he *will* keep these prima donnas from destroying it. There's
quite the historical precedent for such.
-- 
Happy Penguin Computers               >')
126 Fenco Drive                       ( \
Tupelo, MS 38801                       ^^
support@happypenguincomputers.com
662-269-2706 662-205-6424
http://happypenguincomputers.com/

Don't top-post: http://en.wikipedia.org/wiki/Top_post#Top-posting

Re: [gentoo-user] Re: Anyone switched to eudev yet?

[Dale]

Bruce Hill wrote:
> On Mon, Dec 24, 2012 at 05:23:13PM -0500, Michael Mol wrote:
>> Then came the decision to move udev inside /usr, forcing the issue.
>> Now, it'd been long understood that udev *itself* hadn't been broken.
>> The explanation given as much as a year earlier was that udev couldn't
>> control what *other* packages gave it for rules scripts. OK, that's
>> not strictly udev's fault. That's the fault of packages being depended
>> on at too early a stage in the boot process. And, perhaps, hotplug
>> events for some devices _should_ be deferred until the proper
>> resources for handling it are available. I can think of at least a few
>> ways you could do that. And, yes, this was a problem systemd was
>> facing, and wasn't finding a way out of. (Why? I still don't know.
>> Maybe they didn't want to implement dependency declarations or demand
>> that packages impement partial functionality to reduce initial
>> dependencies.)
> You're stumbling upon it ... just keep hashing it out.
>
> The decision to write a new init system (systemd) and do things altogether
> differently is exactly what caused your previously referred to train wreck.
> And Kay Sievers collaborating with Lennart on this corrupted udev. Take those
> two prima donnas out of the udev destruction, and no such init problem exists
> today ... just as it didn't exist before then, for so many years.
>
> Linus didn't tolerate what they did to module and firmware loading:
>
> https://lkml.org/lkml/2012/10/2/303
>
> and he placed the blame squarely on Lennart and Kay where it belongs. To quote
> Linus Torvalds:
>
> "What kind of insane udev maintainership do we have? And can we fix it?"
>
> Bank on it ... he *will* keep these prima donnas from destroying it. There's
> quite the historical precedent for such.


I find it fitting that me and Linus agree on udev.  ROFL  I'm not alone
but still.  ;-)

Dale

:-)  :-) 

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

Re: [gentoo-user] Re: Anyone switched to eudev yet?

[Michael Mol]

On Mon, Dec 24, 2012 at 6:31 PM, Bruce Hill
<daddy@happypenguincomputers.com> wrote:
> On Mon, Dec 24, 2012 at 05:23:13PM -0500, Michael Mol wrote:
>>
>> Then came the decision to move udev inside /usr, forcing the issue.
>> Now, it'd been long understood that udev *itself* hadn't been broken.
>> The explanation given as much as a year earlier was that udev couldn't
>> control what *other* packages gave it for rules scripts. OK, that's
>> not strictly udev's fault. That's the fault of packages being depended
>> on at too early a stage in the boot process. And, perhaps, hotplug
>> events for some devices _should_ be deferred until the proper
>> resources for handling it are available. I can think of at least a few
>> ways you could do that. And, yes, this was a problem systemd was
>> facing, and wasn't finding a way out of. (Why? I still don't know.
>> Maybe they didn't want to implement dependency declarations or demand
>> that packages impement partial functionality to reduce initial
>> dependencies.)
>
> You're stumbling upon it ... just keep hashing it out.

No, I'm pretty sure I understand most of what's going on. I don't
understand why systemd and udevd couldn't settle on a standard
interface for each other (rather than tightly integrate), and I don't
understand why neither systemd nor udevd could implement a
dependency-aware system that understands problems like circular
dependencies and accounts for it; every package manager since the dawn
of the thing has had

The purpose of my email was to try to be as neutral as possible while
laying out the history of the thing over the past year and a half. I'm
stopping short of calling the lead admins lazy, because you don't get
where they are by being lazy. The most generous thing I can think of
to say is that Lennart has deadlines to meet in order to meet Red Hat
release schedules, and trying to corral a bunch of packages with
lazily-defined dependencies into would be extraordinarily difficult.

And...huh. I think I just realized why Lennart and Red Hat are pushing
systemd...it's because of Amazon's EC2. In EC2, you spin up more
copies of a system image in order to scale your site to handle
additional load. Reducing boot time for new system images means you
can scale your computational capacity that much more quickly...and Red
Hat wants in on the scalable cloud action.

>
> The decision to write a new init system (systemd) and do things altogether
> differently is exactly what caused your previously referred to train wreck.
> And Kay Sievers collaborating with Lennart on this corrupted udev. Take those
> two prima donnas out of the udev destruction, and no such init problem exists
> today ... just as it didn't exist before then, for so many years.
>
> Linus didn't tolerate what they did to module and firmware loading:
>
> https://lkml.org/lkml/2012/10/2/303
>
> and he placed the blame squarely on Lennart and Kay where it belongs. To quote
> Linus Torvalds:
>
> "What kind of insane udev maintainership do we have? And can we fix it?"
>
> Bank on it ... he *will* keep these prima donnas from destroying it. There's
> quite the historical precedent for such.

That's what forks accomplish. The original project can die, but a
useful thing can take its place. So I'd venture a guess eudev will
replace udev in Linus's eyes. And some functionality has been pulled
into the kernel to avoid depending on the rogue userland project.

--
:wq

Re: [gentoo-user] Re: Anyone switched to eudev yet?

[Dale]

Mark David Dumlao wrote:
> On Tue, Dec 25, 2012 at 4:00 AM, Dale <rdalek1967@gmail.com> wrote:
>> If I put / on LVM, I need a init thingy.
> No you don't. You could use a boot partition. Or grub2.
>
>> So, worked for ages, then it breaks when people change where they put
>> things.  Answer is, don't change where you put things.  Then things
>> still work for most everyone, including me.  I'm not a programmer nor am
>> I a rocket scientist but even I can see that.  If I can see it, I have
>> no idea why a programmer can't other than being willingly blinded.  ;-)
> You have no idea why it's being deprecated because you STAUNCHLY
> REFUSE TO READ why so, even when it's blatantly being spelled out over
> and over again why it's being done that way.
>
> recap: many packages depending on udev keep putting stuff in their
> udev rules that depend on binaries in /usr. It's not udev's
> responsibility to fix or maintain these packages. Does it work for
> you? Ok. That doesn't mean it isn't broken. There's a couple of
> documents [1] [2] that spell out what /usr is supposed to be, and for
> many distros, it's _failing_ to meet those standards.
>
> [1] http://www.tldp.org/LDP/Linux-Filesystem-Hierarchy/html/usr.html
> [2] http://www.pathname.com/fhs/pub/fhs-2.3.html#THEUSRHIERARCHY
>
> Again:
> /usr, according to what it's supposed to be, is deeply broken for a
> large number of distros. Even when it works - for you. / merging with
> /usr (or /, wherever the rest of the programs are supposed to be)
> actually fixes the breakage, because then udev or whatever programs in
> / can't be out of sync with the programs it depends on.
>
> The analogy here is like when people complained to Ted Tso that ext4
> was not as stable was ext3 (exhibiting the same corruption problems as
> seen in xfs). No, that's not true. ext3 just happened to have a quirky
> behavior that gave the illusion of stability (the writes still failed
> to reach the disk) _for programs that were written broken_. Come ext4,
> which actually behaves as the standard is supposed to, and people
> complain that ext4 is the broken one. It isn't.
>
> Hm, was that a knock from the ghost of Unix past?
>
>> Since there is a way to continue
>> with the old way, which has worked for decades,
> Yes there is one. An "init thingy" is just one of them and the means
> to automatically make one is already available to all distros. Another
> thing you could do is run an early mount script prior to running udev.
> --
> This email is:    [ ] actionable   [ ] fyi        [x] social
> Response needed:  [ ] yes          [x] up to you  [ ] no
> Time-sensitive:   [ ] immediate    [ ] soon       [x] none
>
>

I think Michael said it better but. . . I am against changing my system
from something that I KNOW FOR A FACT WORKS to adding one more point of
failure that I should NOT need.  Don't tell me my system is broken and
can't boot when I sit here and watch it boot all the way to a GUI
login.  I have watched it boot just fine for years, ever since I started
using Gentoo WITHOUT a init thingy I might add.  Other than the
occasional kernel issue, it boots just fine.  I'm not concerned about
some exotic or weird setup since I purposely AVOID that.  I use LVM but
not on anything that will affect booting up.  All that should be needed
for booting is on a regular partition. 

If udev, systemd or any other programs needs something to boot, it
should NOT be placed in /usr.  Again, I'm not a programmer but even I
know that.  If some programmer, not going to mention names, is not smart
enough to know that, then it is not my system or me that has a problem. 
Maybe that programmer has some of his brain on some partition that has
not yet been mounted.  lol  Maybe he/she should use a init thingy to fix
that.  ROFL

If this is so broken, why are the eudev people going to fix it?  They
have said on -dev that they will support booting a separate /usr without
a init thingy.  If eudev can do it, why not udev?  I think it is like
Michael said, they want everything their way and every one else can just
suck it up.  Well, I'm not planning to suck it up.  I'm just going to
use something else that apparently has some smarter programmers. 

Dale

:-)  :-) 

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

Re: [gentoo-user] Re: Anyone switched to eudev yet?

[Daniel Wagener]

On Mon, 24 Dec 2012 14:00:39 -0600
Dale <rdalek1967@gmail.com> wrote:

> Alan McKinnon wrote:
> > On Mon, 24 Dec 2012 06:58:15 -0600
> > Dale <rdalek1967@gmail.com> wrote:
> >
> >> So, Nuno, everything was fine until they started moving things to a
> >> place where it shouldn't be. 
> > No Dale, that is just flat out wrong.
> >
> > There is no such thing as "place where stuff should be". There are
> > only conventions, and like all conventions, rituals, fashions and
> > traditions these are prone to breakage when things move on. Things
> > move on because they become way more complex than the designer of
> > the convention thought they would (or could).
> >
> > The truth is simply this (derived from empirical observation):
> >
> > Long ago we had established conventions about / and /usr; mostly
> > because the few sysadmins around agreed on some things. In those
> > days there was no concept of a packager or maintainer, there was
> > only a sysadmin. This person was a lot like me - he decided and if
> > you didn't like it that was tough. So things stayed as they were
> > for a very long time.
> >
> > Thankfully, it is not like that anymore and the distinction between 
> > / and /usr is now so blurry there might as well not be a
> > distinction. Which is good as the distinction wasn't exactly a good
> > thing from day 1 either - it was useful for terminal servers (only
> > by convention) and let the sysadmin keep his treasured uptime
> > (which only proves he isn't doing kernel maintenance...)
> >
> > I'm sorry you bought into the crap about / and /usr that people of
> > my ilk foisted on you, but the time for that is past, and things
> > move on. If there is to be a convention, there can be only one that
> > makes any sense:
> >
> > / and /usr are essentially the same, so put your stuff anywhere you
> > want it to be. ironically this no gives you the ultimate in choice,
> > not the false one you had for years. So if your /usr is say 8G, then
> > enlarge / bu that amount, move /usr over and retain all your mount
> > points as the were. Now for the foreseeable future anything you
> > might want to hotplug at launch time stands a very good chance of
> > working as expected.
> >
> > You will only need an initrd if you have / on striped RAID or LVM or
> > similar, but that is a boot strap problem not a /usr problem (and
> > you do not have such a setup). Right now you need an initrd anyway
> > to boot such setups.
> >
> > The design of separate / and /usr on modern machines IS broken by
> > design. It is fragile and causes problems in the large case. This
> > doesn't mean YOUR system is broken and won't boot, it means it
> > causes unnecessary hassle in the whole ecosystem, and the fix is to
> > change behaviour and layout to something more appropriate to what
> > we have today.
> >
> 
> The problems with that is these:  It worked ALL these years, why
> should it not now?  I have / on a traditional partition which is not
> going to resize easily.  If I put / on LVM, I need a init thingy.  I
> don't want a init thingy or I would have put / on LVM too.  I made /
> large enough that I would not fill it up in the lifetime of this
> system but not large enough to absorb /usr.  If I am going to have to
> redo all my partitions yet again, I will not use LVM.  I use LVM to
> eliminate this EXACT problem.  I got tired of running out of space
> and having to move stuff around all the time. 
> 
> So, worked for ages, then it breaks when people change where they put
> things.  Answer is, don't change where you put things.  Then things
> still work for most everyone, including me.  I'm not a programmer nor
> am I a rocket scientist but even I can see that.  If I can see it, I
> have no idea why a programmer can't other than being willingly
> blinded.  ;-) 
> 
> Udev/systemd seems to be the problem.  How do I come to that
> conclusion, eudev people says they will support separate /usr with no
> init thingy. Either the eudev folks are rocket scientist type
> programmers and the udev/systemd people are playing with fire
> crackers or there is a way for this to work with udev/systemd to, IF
> they wanted it to work.  Thing is, they have some grand scheme to
> force people to their way of doing things, which includes a init
> thingy.  Since there is a way to continue with the old way, which has
> worked for decades, guess what I am going to do?  Yep, I'm going to
> jump off the udev ship and onto the eudev ship. The eudev ship may be
> old and traditional but it works like I expect. Now if others want to
> stay on the current ship, works for me too.  I'm just not liking the
> meals served on the udev ship anymore. 
> 
> I might add, one of the reasons I left Mandriva was because of the
> init thingy that kept giving me grief.  If I have to use that thing on
> Gentoo, the first time it breaks, I'm going to a binary install.  If I
> am going to put up with that mess, I may as well have something that
> installs quickly.  That was one thing I liked about Mandriva, install
> was really easy.  It still is.  Ubuntu is too.  Actually, they look a
> lot alike to me. 
> 
> Everyone can have their opinion but I also have mine.  This worked
> fine for ages until udev/systemd came along.  That's my opinion and I
> don't think I am alone on that.
> 
> Dale
> 
> :-)  :-) 
> 

Is this actually about something being broken like in "the code does
not do what it is supposed to" or about something no longer being the
tool of choice for everyone?

-- 
()  ascii ribbon campaign - against html e-mail 
/\  www.asciiribbon.org   - against proprietary attachments

Re: [gentoo-user] Re: Anyone switched to eudev yet?

[Pandu Poluan]

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

On Dec 25, 2012 1:55 AM, "Alan McKinnon" <alan.mckinnon@gmail.com> wrote:
>
> On Mon, 24 Dec 2012 06:58:15 -0600
> Dale <rdalek1967@gmail.com> wrote:
>
> The truth is simply this (derived from empirical observation):
>
> Long ago we had established conventions about / and /usr; mostly
> because the few sysadmins around agreed on some things. In those days
> there was no concept of a packager or maintainer, there was only a
> sysadmin. This person was a lot like me - he decided and if you didn't
> like it that was tough. So things stayed as they were for a very long
> time.
>

The convention stuck for a loooooong time because it works, it's
reasonable, and it does not place unduly restrictions on the SysAdmin.

Even back when hard disks are a mote in the eyes of today's mammoths, you
*can* make /usr part of /, there's no stopping you. Sure, other SysAdmins
may scoff and/or question your sanity, but the choice is yours. YOU know
what's best for your precious servers, YOU made the call.

But with the latest udev, Lennart et al saw it fit to yank that choice out
of the hands of SysAdmins, while at the same time trying to enforce a
stupidly overbloated init replacement.

> Thankfully, it is not like that anymore and the distinction between
> / and /usr is now so blurry there might as well not be a distinction.
> Which is good as the distinction wasn't exactly a good thing from day
> 1 either - it was useful for terminal servers (only by convention) and
> let the sysadmin keep his treasured uptime (which only proves he isn't
> doing kernel maintenance...)
>

When you're in charge of over 100 servers as the back-end of a
multinational company that has a revenue in excess of 10 million USD per
day, even a temporary outage means the CIO, COO, and CEO breathing down
your neck.

There's an adage: If it ain't broke, don't fix it.

> I'm sorry you bought into the crap about / and /usr that people of my
> ilk foisted on you, but the time for that is past, and things move on.
> If there is to be a convention, there can be only one that makes any
> sense:
>
> / and /usr are essentially the same, so put your stuff anywhere you
> want it to be. ironically this no gives you the ultimate in choice, not
> the false one you had for years. So if your /usr is say 8G, then
> enlarge / bu that amount, move /usr over and retain all your mount
> points as the were. Now for the foreseeable future anything you might
> want to hotplug at launch time stands a very good chance of working as
> expected.
>

No. I prefer any mucking in /usr to have as small effect as possible to /

That I what SysAdmins worth their salary do: compartment everything. Reduce
interdependencies as much as possible.

> The design of separate / and /usr on modern machines IS broken by
> design. It is fragile and causes problems in the large case. This
> doesn't mean YOUR system is broken and won't boot, it means it causes
> unnecessary hassle in the whole ecosystem, and the fix is to change
> behaviour and layout to something more appropriate to what we have
> today.
>

The way I see it, it's /usr integrated into / that introduces fragility.
Too much going on in /

In case you haven't noticed, since Windows 7 (or Vista, forget which)
Microsoft has even went the distance of splitting between C: (analogous to
/usr) and 'System Partition' (analogous to /). The boot process is actually
handled by the 100ish MB 'System Partition' before being handed to C:. This
will at least give SysAdmins a fighting chance of recovering a botched
maintenance.

(Note: Said behavior will only be visible if installing onto a clean hard
disk. If there are partitions left over from previous Windows installs,
Win7 will not create a separate 'System Partition')

So, if Microsoft saw the light, why does Red Hat sunk into darkness
instead?

> --
> Alan McKinnon
> alan.mckinnon@gmail.com
>
>

Rgds,
--

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

Re: [gentoo-user] Re: Anyone switched to eudev yet? -> what was wron with SysVInit?

[G.Wolfe Woodbury]

On 12/24/2012 10:56 PM, Pandu Poluan wrote:
> 
> Even back when hard disks are a mote in the eyes of today's mammoths,
> you *can* make /usr part of /, there's no stopping you. Sure, other
> SysAdmins may scoff and/or question your sanity, but the choice is
> yours. YOU know what's best for your precious servers, YOU made the call.
> 
> But with the latest udev, Lennart et al saw it fit to yank that choice
> out of the hands of SysAdmins, while at the same time trying to enforce
> a stupidly overbloated init replacement.

I may be really out of the loop or old-fashioned, but what went wrong
with the old SysV init scheme?

SysV inhereited the init scheme practically in toto from what was
created for the intermediate SysIV version that was intermal to Bell
Labs.  SysIV got used for a few projects, and it was a major improvement
over the SysIII scheme.  Those developing the SysIV/SysV init scheme
tried to anticipate future extensions (especially dependency problems)
even to the point of ashing Murry Hill to make chenges to the shell to
make some "magic" easier. [Specifically the use of shell exec for
input/output file descriptor changes.]

[Disclaimer: I was working a Holmdel with a SystemIV based project as a
contractor and was involved in some of this work.]

From what has been happening with the systemd stuff, I do not see what
advantages it really offers over the SysV scheme and its successors like
OpenRC.  Someone enlighten me please?

-- 
G.Wolfe Woodbury
redwolfe@gmail.com

Re: [gentoo-user] Re: Anyone switched to eudev yet? -> what was wron with SysVInit?

[Canek Peláez Valdés]

On Tue, Dec 25, 2012 at 1:38 AM, G.Wolfe Woodbury <redwolfe@gmail.com> wrote:
[ snip ]
> From what has been happening with the systemd stuff, I do not see what
> advantages it really offers over the SysV scheme and its successors like
> OpenRC.  Someone enlighten me please?

I wrote the following some months ago; I think nothing much has
changed since then (I added a couple of comments):

Take this with a grain (or a kilo) of salt, since I'm obviously
biased, but IMHO this are systemd advantages over OpenRC:

* Really fast boot. OpenRC takes at least double the time that systemd
does when booting, easily verifiable. In my laptop systemd is twice as
fast as OpenRC; in my desktop is three times faster. (With a solid
state hard drive, my laptop now boots even faster).

* Really parallel service startup: OpenRC has never been reliable on
parallel service startup; its documentation says it explicitly. Some
will tell you that for them "it works", but just like the guys who
have a separate /usr and refuse to use an initramfs, they just haven't
been bitten by the inherent problems of it (just ask kernel developer
Greg Kroah-Hartman). The Gentoo devs recognize that OpenRC is just
broken with parallel service startup.

* Really simple service unit files: The service unit files are really
small, really simple, really easy to understand/modify. Compare the 9
lines of sshd.service:

$ cat /etc/systemd/system/sshd.service
[Unit]
Description=SSH Secure Shell Service
After=syslog.target

[Service]
ExecStart=/usr/sbin/sshd -D

[Install]
WantedBy=multi-user.target

with the 84 of /etc/init.d/sshd (80 without comments).

* Really good documentation: systemd has one of the best
documentations I have ever seen in *any* project. Everything (except
really new, experimental features) is documented, with manual pages
explaining everything. And besides, there are blog posts by Lennart
explaining in a more informal way how to do neat tricks with systemd.

* Really good in-site customization: The service unit files are
trivially overrided with custom ones for specific installations,
without needing to touch the ones installed by systemd or a program.
With OpenRC, if I modify a /etc/init.d file, chances are I need to
check out my next installation so I can see how the new file differs
from the old one, and adapt the changes to my customized version.

* All the goodies from Control Groups: You can use kernel cgroups to
monitor/control several properties of your daemons, out of the box,
almost no admin effort involved.

* It tries to unify Linux behaviour among distros (some can argue that
this is a bad thing): Using systemd, the same
configurations/techniques work the same in every distribution. No more
need to learn /etc/conf.d, /etc/sysconfig, /etc/default hacks by
different distros.

* Finally, and what I think is the most fundamental difference between
systemd and almost any other init system: The service unit files in
systemd are *declarative*; you tell the daemon *what* to do, not *how*
to do it. If the service files are shell scripts (like in
OpenRC/SysV), everything can spiral out of control really easily. And
it usually does (again, look at sshd; and that one is actully nicely
written, there are all kind of monsters out there abusing the power
that shell gives you).

These are the ones off the top of my head; but what I like the most
about systemd is that it just works, and that it makes a lot of sense
(at least to me).

Most of systemd features can be implemented in OpenRC, although the
speed difference will never be eliminated if OpenRC keeps using shell
files; however, Luca Barbato said that using reentrant busybox the
speed difference is greatly reduced (I haven't confirmed this, since I
haven't even installed OpenRC in months).

Now, this set of (IMO) advantages of systemd over OpenRC pile up over
the advantages of OpenRC over SysV: the most important one (I believe)
is that OpenRC has dependencies, so a service starts only when another
has already started. AFAIK, SysV has lacked this since always.

I don't think I have ever heard anyone saying that we should keep
using SysV; like a lot of Unix legacies, it should just die. OpenRC is
much better, but it still uses a Turing-complete language (and a
really slow one) to simply tell services when to start and when to
stop, and it doesn't reliably keep track of what services are really
still running (anyone who has ever used the "zap" command in OpenRC
knows this).

systemd of course has dependencies, a reliable tracking of service
status (thanks in part to the use of cgroups), and its service files
can't enter in an infinite loop.

Hope it helps.

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] Re: Anyone switched to eudev yet? -> what was wron with SysVInit?

[G.Wolfe Woodbury]

On 12/25/2012 03:01 AM, Canek Peláez Valdés wrote:
> On Tue, Dec 25, 2012 at 1:38 AM, G.Wolfe Woodbury <redwolfe@gmail.com> wrote:
> [ snip ]
>> From what has been happening with the systemd stuff, I do not see what
>> advantages it really offers over the SysV scheme and its successors like
>> OpenRC.  Someone enlighten me please?
> 
> I wrote the following some months ago; I think nothing much has
> changed since then (I added a couple of comments):

Thanks, quite helpful.

-- 
G.Wolfe Woodbury

Re: [gentoo-user] Re: Anyone switched to eudev yet? -> what was wron with SysVInit?

[Michael Mol]

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

On Dec 25, 2012 3:04 AM, "Canek Peláez Valdés" <caneko@gmail.com> wrote:
>
> On Tue, Dec 25, 2012 at 1:38 AM, G.Wolfe Woodbury <redwolfe@gmail.com>
wrote:
> [ snip ]
> > From what has been happening with the systemd stuff, I do not see what
> > advantages it really offers over the SysV scheme and its successors like
> > OpenRC.  Someone enlighten me please?
>
> I wrote the following some months ago; I think nothing much has
> changed since then (I added a couple of comments):
>
> Take this with a grain (or a kilo) of salt, since I'm obviously
> biased, but IMHO this are systemd advantages over OpenRC:
>
> * Really fast boot. OpenRC takes at least double the time that systemd
> does when booting, easily verifiable. In my laptop systemd is twice as
> fast as OpenRC; in my desktop is three times faster. (With a solid
> state hard drive, my laptop now boots even faster).
>
> * Really parallel service startup: OpenRC has never been reliable on
> parallel service startup; its documentation says it explicitly. Some
> will tell you that for them "it works", but just like the guys who
> have a separate /usr and refuse to use an initramfs, they just haven't
> been bitten by the inherent problems of it (just ask kernel developer
> Greg Kroah-Hartman). The Gentoo devs recognize that OpenRC is just
> broken with parallel service startup.
>
> * Really simple service unit files: The service unit files are really
> small, really simple, really easy to understand/modify. Compare the 9
> lines of sshd.service:
>
> $ cat /etc/systemd/system/sshd.service
> [Unit]
> Description=SSH Secure Shell Service
> After=syslog.target
>
> [Service]
> ExecStart=/usr/sbin/sshd -D
>
> [Install]
> WantedBy=multi-user.target
>
> with the 84 of /etc/init.d/sshd (80 without comments).
>
> * Really good documentation: systemd has one of the best
> documentations I have ever seen in *any* project. Everything (except
> really new, experimental features) is documented, with manual pages
> explaining everything. And besides, there are blog posts by Lennart
> explaining in a more informal way how to do neat tricks with systemd.
>
> * Really good in-site customization: The service unit files are
> trivially overrided with custom ones for specific installations,
> without needing to touch the ones installed by systemd or a program.
> With OpenRC, if I modify a /etc/init.d file, chances are I need to
> check out my next installation so I can see how the new file differs
> from the old one, and adapt the changes to my customized version.
>
> * All the goodies from Control Groups: You can use kernel cgroups to
> monitor/control several properties of your daemons, out of the box,
> almost no admin effort involved.
>
> * It tries to unify Linux behaviour among distros (some can argue that
> this is a bad thing): Using systemd, the same
> configurations/techniques work the same in every distribution. No more
> need to learn /etc/conf.d, /etc/sysconfig, /etc/default hacks by
> different distros.
>
> * Finally, and what I think is the most fundamental difference between
> systemd and almost any other init system: The service unit files in
> systemd are *declarative*; you tell the daemon *what* to do, not *how*
> to do it. If the service files are shell scripts (like in
> OpenRC/SysV), everything can spiral out of control really easily. And
> it usually does (again, look at sshd; and that one is actully nicely
> written, there are all kind of monsters out there abusing the power
> that shell gives you).
>
> These are the ones off the top of my head; but what I like the most
> about systemd is that it just works, and that it makes a lot of sense
> (at least to me).
>
> Most of systemd features can be implemented in OpenRC, although the
> speed difference will never be eliminated if OpenRC keeps using shell
> files; however, Luca Barbato said that using reentrant busybox the
> speed difference is greatly reduced (I haven't confirmed this, since I
> haven't even installed OpenRC in months).
>
> Now, this set of (IMO) advantages of systemd over OpenRC pile up over
> the advantages of OpenRC over SysV: the most important one (I believe)
> is that OpenRC has dependencies, so a service starts only when another
> has already started. AFAIK, SysV has lacked this since always.
>
> I don't think I have ever heard anyone saying that we should keep
> using SysV; like a lot of Unix legacies, it should just die. OpenRC is
> much better, but it still uses a Turing-complete language (and a
> really slow one) to simply tell services when to start and when to
> stop, and it doesn't reliably keep track of what services are really
> still running (anyone who has ever used the "zap" command in OpenRC
> knows this).
>
> systemd of course has dependencies, a reliable tracking of service
> status (thanks in part to the use of cgroups), and its service files
> can't enter in an infinite loop.
>
> Hope it helps.
>
> Regards.
> --
> Canek Peláez Valdés
> Posgrado en Ciencia e Ingeniería de la Computación
> Universidad Nacional Autónoma de México
>

Thank you. I think that may well be the cleanest set of favorable arguments
I've seen for systemd.

Now, question: could I not create a "/usr" service and make things
dependent on /usr come after it's been mounted? That seems the single, core
missing piece.

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

[gentoo-user] Re: Anyone switched to eudev yet? -> what was wron with SysVInit?

[Nuno J. Silva]

On 2012-12-25, Michael Mol wrote:

> Now, question: could I not create a "/usr" service and make things
> dependent on /usr come after it's been mounted? That seems the single, core
> missing piece.

This suffices for /usr on regular partitions. The problem is with more
complex stuff which, I assume (assume, because nobody who actually has
that setup has actually explained what happens), requires device files
which are not present under /dev by default, and, even if /dev is
already mounted once init is started, it only has a handful of default
files.

The additional, non-default files for most of the stuff are nowadays
created through udev, and so you need to have udevd running and
processing events to populate /dev. Thus:

- The already existing "rules will silently fail" problem will not be
  solved, as some events will get processed before you have a chance to
  mount /usr 

- The "udev won't work because it is under /usr" issue, which seems to
  be the case of udev since it got merged with systemd (once again I'm
  assuming here, from a bug report)), well, this one is not easy to
  solve unless you copy the udev tools to / or to some initr*, or you
  install udev to /.


But, of course, for /usr on regular partitions, just issuing "mount
/usr" before starting udevd works.

-- 
Nuno Silva (aka njsg)
http://njsg.sdf-eu.org/

Re: [gentoo-user] Re: Anyone switched to eudev yet? -> what was wron with SysVInit?

[Canek Peláez Valdés]

On Tue, Dec 25, 2012 at 7:14 AM, Michael Mol <mikemol@gmail.com> wrote:
>
> On Dec 25, 2012 3:04 AM, "Canek Peláez Valdés" <caneko@gmail.com> wrote:
>>
>> On Tue, Dec 25, 2012 at 1:38 AM, G.Wolfe Woodbury <redwolfe@gmail.com>
>> wrote:
>> [ snip ]
>> > From what has been happening with the systemd stuff, I do not see what
>> > advantages it really offers over the SysV scheme and its successors like
>> > OpenRC.  Someone enlighten me please?
>>
>> I wrote the following some months ago; I think nothing much has
>> changed since then (I added a couple of comments):
>>
>> Take this with a grain (or a kilo) of salt, since I'm obviously
>> biased, but IMHO this are systemd advantages over OpenRC:
>>
>> * Really fast boot. OpenRC takes at least double the time that systemd
>> does when booting, easily verifiable. In my laptop systemd is twice as
>> fast as OpenRC; in my desktop is three times faster. (With a solid
>> state hard drive, my laptop now boots even faster).
>>
>> * Really parallel service startup: OpenRC has never been reliable on
>> parallel service startup; its documentation says it explicitly. Some
>> will tell you that for them "it works", but just like the guys who
>> have a separate /usr and refuse to use an initramfs, they just haven't
>> been bitten by the inherent problems of it (just ask kernel developer
>> Greg Kroah-Hartman). The Gentoo devs recognize that OpenRC is just
>> broken with parallel service startup.
>>
>> * Really simple service unit files: The service unit files are really
>> small, really simple, really easy to understand/modify. Compare the 9
>> lines of sshd.service:
>>
>> $ cat /etc/systemd/system/sshd.service
>> [Unit]
>> Description=SSH Secure Shell Service
>> After=syslog.target
>>
>> [Service]
>> ExecStart=/usr/sbin/sshd -D
>>
>> [Install]
>> WantedBy=multi-user.target
>>
>> with the 84 of /etc/init.d/sshd (80 without comments).
>>
>> * Really good documentation: systemd has one of the best
>> documentations I have ever seen in *any* project. Everything (except
>> really new, experimental features) is documented, with manual pages
>> explaining everything. And besides, there are blog posts by Lennart
>> explaining in a more informal way how to do neat tricks with systemd.
>>
>> * Really good in-site customization: The service unit files are
>> trivially overrided with custom ones for specific installations,
>> without needing to touch the ones installed by systemd or a program.
>> With OpenRC, if I modify a /etc/init.d file, chances are I need to
>> check out my next installation so I can see how the new file differs
>> from the old one, and adapt the changes to my customized version.
>>
>> * All the goodies from Control Groups: You can use kernel cgroups to
>> monitor/control several properties of your daemons, out of the box,
>> almost no admin effort involved.
>>
>> * It tries to unify Linux behaviour among distros (some can argue that
>> this is a bad thing): Using systemd, the same
>> configurations/techniques work the same in every distribution. No more
>> need to learn /etc/conf.d, /etc/sysconfig, /etc/default hacks by
>> different distros.
>>
>> * Finally, and what I think is the most fundamental difference between
>> systemd and almost any other init system: The service unit files in
>> systemd are *declarative*; you tell the daemon *what* to do, not *how*
>> to do it. If the service files are shell scripts (like in
>> OpenRC/SysV), everything can spiral out of control really easily. And
>> it usually does (again, look at sshd; and that one is actully nicely
>> written, there are all kind of monsters out there abusing the power
>> that shell gives you).
>>
>> These are the ones off the top of my head; but what I like the most
>> about systemd is that it just works, and that it makes a lot of sense
>> (at least to me).
>>
>> Most of systemd features can be implemented in OpenRC, although the
>> speed difference will never be eliminated if OpenRC keeps using shell
>> files; however, Luca Barbato said that using reentrant busybox the
>> speed difference is greatly reduced (I haven't confirmed this, since I
>> haven't even installed OpenRC in months).
>>
>> Now, this set of (IMO) advantages of systemd over OpenRC pile up over
>> the advantages of OpenRC over SysV: the most important one (I believe)
>> is that OpenRC has dependencies, so a service starts only when another
>> has already started. AFAIK, SysV has lacked this since always.
>>
>> I don't think I have ever heard anyone saying that we should keep
>> using SysV; like a lot of Unix legacies, it should just die. OpenRC is
>> much better, but it still uses a Turing-complete language (and a
>> really slow one) to simply tell services when to start and when to
>> stop, and it doesn't reliably keep track of what services are really
>> still running (anyone who has ever used the "zap" command in OpenRC
>> knows this).
>>
>> systemd of course has dependencies, a reliable tracking of service
>> status (thanks in part to the use of cgroups), and its service files
>> can't enter in an infinite loop.
>>
>> Hope it helps.
>>
>> Regards.
>> --
>> Canek Peláez Valdés
>> Posgrado en Ciencia e Ingeniería de la Computación
>> Universidad Nacional Autónoma de México
>>
>
> Thank you. I think that may well be the cleanest set of favorable arguments
> I've seen for systemd.
>
> Now, question: could I not create a "/usr" service and make things dependent
> on /usr come after it's been mounted? That seems the single, core missing
> piece.

I'm not going into that. People with far more knowledge, experience,
and communication hability than me (Greg, William, Michał, Diego,
etc.) have explained why the "separated /usr without initramfs" is
broken, and that udev/systemd actually *works* in a separated /usr
*without* an initramfs (if you use the --with-rootprefix= configure
option, which exists exactly for this), but that's not enough for a
lot of folks.

To be honest, I don't think nothing will be ever be enough, because
they are not listening to technical reasons. Which is fine, I guess;
they can now use eudev (which the only thing it does so far to is
remove features from plain udev), and with luck their systems will
"work", in the sense that the breakage doesn't show in their
particular setups, like it happened with plain udev for many. If the
breakage shows, I'm pretty sure the eudev fork will be of not help at
all, because the problem has never been in udev (nor systemd, for that
matter).

So, no, I'm not trying to answer if you could "create a "/usr" service
and make things dependent on /usr come after it's been mounted". I
passed almost this entire thread because it's mostly people still
hitting the same dead horse; really, if someone believe the eudev fork
is the answer, they should go forth and use it. If there are people
who don't want to believe developers like Greg Kroah-Hartman or Diego
Pettenò when they basically say that eudev is a joke, why they would
believe *me*? And, by the way, Diego doesn't like systemd *at all*.

I just replied to Wolfe question because it was really concrete, and I
thought I could answer it. I'm not going to hit a dead horse.

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] Re: Anyone switched to eudev yet? -> what was wron with SysVInit?

[Pandu Poluan]

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

On Dec 26, 2012 1:05 AM, "Canek Peláez Valdés" <caneko@gmail.com> wrote:

{supersnip}

>
> So, no, I'm not trying to answer if you could "create a "/usr" service
> and make things dependent on /usr come after it's been mounted". I
> passed almost this entire thread because it's mostly people still
> hitting the same dead horse; really, if someone believe the eudev fork
> is the answer, they should go forth and use it. If there are people
> who don't want to believe developers like Greg Kroah-Hartman or Diego
> Pettenò when they basically say that eudev is a joke, why they would
> believe *me*? And, by the way, Diego doesn't like systemd *at all*.
>

Canek, I distinctly remember, at the very beginning of this brouhaha over
udev requiring /usr to be mounted at boot time, you stated something along
the lines of 'show me the code, then I'll believe that replacing udev is
doable'.

First, Walter Dnes came out with an amazingly complete -- considering it
was all done by just one man -- solution using mdev. You scoffed at him,
saying that mdev solution is incomplete.

Now, some respected Gentoo devs forked udev into eudev, and produced a
working solution, yet you still scoff at them.

In your eyes, udev has become like the cosmos: everything there is, and
ever shall be.

Greg KH and Diego Petteno are similar; they ridiculed a good forking by
spreading FUD, and almost totally unwilling to listen to rational arguments
from the devs about why udev is forked. As a result, they received great
opposition, in turn. Even Linus piped up at one point, sharply reminding
Greg KH that even though udev was at one time Greg's 'baby', at this point
udev serves only the wants of the few.

I'd say that you, Greg KH, and others denigrating eudev are udev fanatics,
preferring to denigrate anything outside the 'party lines' of udev+systemd.

Rgds,
--

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

Re: [gentoo-user] Re: Anyone switched to eudev yet? -> what was wron with SysVInit?

[Canek Peláez Valdés]

On Wed, Dec 26, 2012 at 6:45 PM, Pandu Poluan <pandu@poluan.info> wrote:
>
> On Dec 26, 2012 1:05 AM, "Canek Peláez Valdés" <caneko@gmail.com> wrote:
>
> {supersnip}

> Canek, I distinctly remember, at the very beginning of this brouhaha over
> udev requiring /usr to be mounted at boot time, you stated something along
> the lines of 'show me the code, then I'll believe that replacing udev is
> doable'.

Yeah, and like I said, check the commits in eudev. They haven't done
nothing but to remove code and a very rational (IMO) dependency, kmod.

> First, Walter Dnes came out with an amazingly complete -- considering it was
> all done by just one man -- solution using mdev. You scoffed at him, saying
> that mdev solution is incomplete.

I'm sorry if sounded like scoffing (certainly I don't remember
scoffing anyone, at least consciously). I remember I praised Walt for
doing the work for mdev. Do you remember that? I can dig the archives,
but I'm pretty sure I said that I greatly admired him.

> Now, some respected Gentoo devs forked udev into eudev, and produced a
> working solution, yet you still scoff at them.

I'm not the one doing the scoffing; those where Greg and Diego. And
sorry, but I really trust those guys.

> In your eyes, udev has become like the cosmos: everything there is, and ever
> shall be.

No, of course no. Hell, I hope something even better will be developed
along the way. And I said at some point (to Greg, in the -dev list)
that *perhaps* something good will come from eudev. I hope you
remember, but (again) I can search the archives.

> Greg KH and Diego Petteno are similar; they ridiculed a good forking by
> spreading FUD, and almost totally unwilling to listen to rational arguments
> from the devs about why udev is forked. As a result, they received great
> opposition, in turn. Even Linus piped up at one point, sharply reminding
> Greg KH that even though udev was at one time Greg's 'baby', at this point
> udev serves only the wants of the few.

I really think that's the crux of the matter Pandou: udev/systemd
serves to the wants of the many. The eudev fork serves to the wants of
a very few which really don't want an initramfs, when it has a lot of
technical advantages. It has some problems, of course, but we can
solve those, and solve the problem *in the general case*. Which is the
one that it's important ant interesting.

In my humble opinion (apparently, if I don't say that, it sounds like
it's impossible for me to be wrong).

> I'd say that you, Greg KH, and others denigrating eudev are udev fanatics,
> preferring to denigrate anything outside the 'party lines' of udev+systemd.

What about Diego? He doesn't like systemd.

Pandou, the "party lines" and the "thought police" is the other way
around in this list. You don't seem to remember my praises to Walt or
my wishing luck to the eudev fork (which, BTW, Greg also did). The few
of us who *dare* to praise udev/systemd get an incredible amount of
crap for it. We are nothing but fanbois or, in your words, "udev has
become like the cosmos: everything there is, and ever shall be."
Really? I didn't knew that.

Maybe we are doing it wrong. But as far as i can see, we are only
expressing our opinion on technical grounds. We are not calling names
nor doubting their technical backgrounds, nor telling people what they
should or should not use.

It's the other way around.
-- 
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] Re: Anyone switched to eudev yet? -> what was wron with SysVInit?

[Canek Peláez Valdés]

On Wed, Dec 26, 2012 at 7:14 PM, Canek Peláez Valdés <caneko@gmail.com> wrote:
[ snip ]
> I'm sorry if sounded like scoffing (certainly I don't remember
> scoffing anyone, at least consciously). I remember I praised Walt for
> doing the work for mdev. Do you remember that? I can dig the archives,
> but I'm pretty sure I said that I greatly admired him.

Found it:

http://article.gmane.org/gmane.linux.gentoo.user/254885

"""
As I have said before, I admire a lot what Walter et al. are doing,
and as I always will say, this is how our community works: people
writing the code (as Walter is doing) are the ones that get things
done. This is the correct (and only) way to address a problem
(perceived or real) with the current status: write the code that does
the thing the way you want it. Complaining and crying that you don't
like the direction some part of the stack is taking is at best a waste
of time, and at worst idiotic. Actually doing something about it (as
Walter is doing) is the smart thing to do.
"""

[ snip ]
>> In your eyes, udev has become like the cosmos: everything there is, and ever
>> shall be.
>
> No, of course no. Hell, I hope something even better will be developed
> along the way. And I said at some point (to Greg, in the -dev list)
> that *perhaps* something good will come from eudev. I hope you
> remember, but (again) I can search the archives.

Found this one also:

http://article.gmane.org/gmane.linux.gentoo.devel/81251

"""
Seeing some people comparing udev to XFree86 is one of the more
bizarre things coming out from this fork, and that's saying. However,
I agree with Doug that anyone should code whatever they want to code.
Who knows, maybe something interesting would come off from this fork,
and it certainly doesn't affect us happy Gentoo+systemd+udev users.
"""

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] Re: Anyone switched to eudev yet? -> what was wron with SysVInit?

[pk]

On 2012-12-27 02:14, Canek Peláez Valdés wrote:

> I really think that's the crux of the matter Pandou: udev/systemd
> serves to the wants of the many. The eudev fork serves to the wants of

systemd+udev serves the "large mass" (users of mainly Fedora and other
distros using systemd) that doesn't care/know computers.

> a very few which really don't want an initramfs, when it has a lot of
> technical advantages. It has some problems, of course, but we can
> solve those, and solve the problem *in the general case*. Which is the
> one that it's important ant interesting.

It's unimportant and uninteresting on the terms that
Poettering/Sievers/Greg KH put forward, for us that wants control and
does not want an all singing and dancing system (incl. "kitchen sink").
In my opinion the init system should be completely independent of the
kernel with a well defined, generic, interface so that the user can
choose and pick whatever pieces he/she wishes to run his system. Think
"Lego" (as in small, well defined pieces that fit together in any way
the user sees fit)...

> my wishing luck to the eudev fork (which, BTW, Greg also did). The few

The way I read Greg's "good luck" was that it had quite a bit of a
sarcastic tone... Was there really any need for him to say anything at
all? I've previously had a lot of respect for Greg but this made me
think quite a lot less of him...

> of us who *dare* to praise udev/systemd get an incredible amount of
> crap for it. We are nothing but fanbois or, in your words, "udev has
> become like the cosmos: everything there is, and ever shall be."
> Really? I didn't knew that.

You really sound like a fanboy... And I don't mean that in a derogatory
way; it's just how I see your writing...

> Maybe we are doing it wrong. But as far as i can see, we are only
> expressing our opinion on technical grounds. We are not calling names

Your opinions (technical or not) doesn't matter to me since (it seems)
you have a very different goal than me with your system. I want you to
enjoy whatever system you use but you shouldn't try to force that same
system on to me. In that regard I see the eudev fork as a saviour.

These are the technical grounds that I've seen you state:

* fast boot time
Irrelevant, BIOS/UEFI/card firmware takes longer time than booting to
XDM for me. The few seconds that it takes to boot from grub to login is
of no matter (to me).

* parallel service startup
Nice to have but still irrelevant, see above. Sequential is also
preferred from a trouble shooting perspective. Furthermore I like having
the ability to stop a particular daemon if there something that needs
fixing (pushing "I" when booting).

* "simple service unit files"
Simplicity is fine but to accomplish the same in your simple "service"
file as in the example you brought forward (sshd) you need to hide a lot
of stuff elsewhere. Not for me thanks, I'm a control freak.

* good documentation
I haven't read it so I won't touch this. Not a technical point though,
more of an opinion. Although I agree that good documentation is very
nice to have.

* "Really good in-site customization"
If I choose to upgrade a daemon, I should be interested in what changes,
if any, that brings in configuration in order to not have any surprises
later. If you think that's a good thing, that really sounds like you
would be doing the OpenRC equivalent of:
'etc-update --automode -5'

* control groups
As I understand it, this depends on someone writing config files for the
individual daemons. Noone is stopping Gentoo devs or anyone else from
writing such. And I would, again, prefer to go through a good manual or
a "howto" and do it myself so that I can understand the consequences, if
I would want it.

* unification
I've tried quite a few distros over the years (starting with Redhat in
the late 90'ies) and Gentoos OpenRC is by far the most sane system I've
come across. Never going back to Redhat hell thank you! Standardizing
the interfaces is fine but it's not ok to force a whole "kitchen and
sink" solution in order to "satisfy" as many as possible. This is not
the Gentoo way, as I understand it. Gentoo is all about choice.

* "you tell the daemon *what* to do, not *how* to do it"
It's good if you don't want to learn about what things you install and
understand what the consequences are of different choices, in the config
files. I run very few daemons on my desktop machine so it's not so time
consuming to read up on/fix things etc. If I ever were to run a full
blown server (esp. connected to the "net") with lots of daemons I would
be very hesitant to use any pre-configurations, seems suicidal to me.
The only usage I see here of "declarative" scripts are when you don't
care about what the machine is doing.

Best regards

Peter K

Re: [gentoo-user] Re: Anyone switched to eudev yet? -> what was wron with SysVInit?

[Canek Peláez Valdés]

On Thu, Dec 27, 2012 at 10:00 AM, pk <peterk2@coolmail.se> wrote:
> On 2012-12-27 02:14, Canek Peláez Valdés wrote:
>
>> I really think that's the crux of the matter Pandou: udev/systemd
>> serves to the wants of the many. The eudev fork serves to the wants of
>
> systemd+udev serves the "large mass" (users of mainly Fedora and other
> distros using systemd) that doesn't care/know computers.

Well, yeah, that's the point. I want to install Gentoo in my mother's
PC, and never have to go to her house because someting broke.

>> a very few which really don't want an initramfs, when it has a lot of
>> technical advantages. It has some problems, of course, but we can
>> solve those, and solve the problem *in the general case*. Which is the
>> one that it's important ant interesting.
>
> It's unimportant and uninteresting on the terms that
> Poettering/Sievers/Greg KH put forward, for us that wants control and
> does not want an all singing and dancing system (incl. "kitchen sink").
> In my opinion the init system should be completely independent of the
> kernel with a well defined, generic, interface so that the user can
> choose and pick whatever pieces he/she wishes to run his system. Think
> "Lego" (as in small, well defined pieces that fit together in any way
> the user sees fit)...

And how's that changed? If you want control, you will *always* have
control. The source code is out there; what more control do you need?

>> my wishing luck to the eudev fork (which, BTW, Greg also did). The few
>
> The way I read Greg's "good luck" was that it had quite a bit of a
> sarcastic tone... Was there really any need for him to say anything at
> all? I've previously had a lot of respect for Greg but this made me
> think quite a lot less of him...

That's how you choose to interpret it, and I'm pretty sure it was not
the way Greg said it.

>> of us who *dare* to praise udev/systemd get an incredible amount of
>> crap for it. We are nothing but fanbois or, in your words, "udev has
>> become like the cosmos: everything there is, and ever shall be."
>> Really? I didn't knew that.
>
> You really sound like a fanboy... And I don't mean that in a derogatory
> way; it's just how I see your writing...

It does sound derogatory...

>> Maybe we are doing it wrong. But as far as i can see, we are only
>> expressing our opinion on technical grounds. We are not calling names
>
> Your opinions (technical or not) doesn't matter to me since (it seems)
> you have a very different goal than me with your system. I want you to
> enjoy whatever system you use but you shouldn't try to force that same
> system on to me. In that regard I see the eudev fork as a saviour.

What *I* am forcing on *anyone*? How could *I* force *anything* on
*anyone*? I'm just stating why I believe udev/systemd is a nice
solution to the general problem. That's all: I'm not a developer, I'm
not a distro planer; I'm not in any way capable to enforce anything on
anyone.

And I, if I'm allowed to repeat it, have never called names on anyone.
I'm just stating my opinion; how could you twist that into the idea
that I'm trying "to force that same system on to me"? Really?

> These are the technical grounds that I've seen you state:
>
> * fast boot time
> Irrelevant, BIOS/UEFI/card firmware takes longer time than booting to
> XDM for me. The few seconds that it takes to boot from grub to login is
> of no matter (to me).

It matters to me. A lot. Specially in my laptop (I follow
vanilla-sources unstable, so I reboot relatively often), in my media
center (same reasons). In my servers certainly the hardware
initialization phase is longer; but (IMO) that makes even more
important the speed gains from grub to userspace.

Please, understand that my above (↑) reasons doesn't mean I don't care
of yours, or that you are wrong. It only means that our reasons are
different, and then perhaps the proper thing to do is to agree to
disagree.

> * parallel service startup
> Nice to have but still irrelevant, see above. Sequential is also
> preferred from a trouble shooting perspective. Furthermore I like having
> the ability to stop a particular daemon if there something that needs
> fixing (pushing "I" when booting).

Relevant for me, see above. And that's another thing I hate about the
shell init scripts; problems get "workarounded" instead of properly
fixed. If there is a problem at boot time *it should be fixed where
the problem lives*, not "workarounded" with shell hackery.

Again, please understand that my above (↑) reasons doesn't mean I
don't care of yours, or that you are wrong. It only means that our
reasons are different, and then perhaps the proper thing to do is to
agree to disagree.

> * "simple service unit files"
> Simplicity is fine but to accomplish the same in your simple "service"
> file as in the example you brought forward (sshd) you need to hide a lot
> of stuff elsewhere. Not for me thanks, I'm a control freak.

I'm not; let the machines do the work. The least I have to think about
my system, the better; I care only for it to work.

Again, please understand that my above (↑) reasons doesn't mean I
don't care about yours, or that you are wrong. It only means that our
reasons are different, and then perhaps the proper thing to do is to
agree to disagree.

> * good documentation
> I haven't read it so I won't touch this. Not a technical point though,
> more of an opinion. Although I agree that good documentation is very
> nice to have.

Common ground.

> * "Really good in-site customization"
> If I choose to upgrade a daemon, I should be interested in what changes,
> if any, that brings in configuration in order to not have any surprises
> later. If you think that's a good thing, that really sounds like you
> would be doing the OpenRC equivalent of:
> 'etc-update --automode -5'

But that's the beauty of systemd; I don't have to do *anything*. If
the original unit file gets updated, my customization gets updated to.
Again, I don't need to do anything.

Again, please understand that my above (↑) reasons doesn't mean I
don't care about yours, or that you are wrong. It only means that our
reasons are different, and then perhaps the proper thing to do is to
agree to disagree.

> * control groups
> As I understand it, this depends on someone writing config files for the
> individual daemons. Noone is stopping Gentoo devs or anyone else from
> writing such. And I would, again, prefer to go through a good manual or
> a "howto" and do it myself so that I can understand the consequences, if
> I would want it.

It's a little more difficult than "writing config files", in OpenRC's
case. To begin with, you need to check if there is cgroup support.

Again, please understand that my above (↑) reasons doesn't mean I
don't care about yours, or that you are wrong. It only means that our
reasons are different, and then perhaps the proper thing to do is to
agree to disagree.

> * unification
> I've tried quite a few distros over the years (starting with Redhat in
> the late 90'ies) and Gentoos OpenRC is by far the most sane system I've
> come across. Never going back to Redhat hell thank you! Standardizing
> the interfaces is fine but it's not ok to force a whole "kitchen and
> sink" solution in order to "satisfy" as many as possible. This is not
> the Gentoo way, as I understand it. Gentoo is all about choice.

And who has taken any choice from you? Even if systemd became the
default init system in Gentoo, you will be able to install OpenRC
always. Even if there is no ebuild, you'll be *always* able to do
"./configure && make && make install". Nobody is taking choices from
anyone. I just want udev/systemd to work fine in Gentoo (which it
does)  and not having to install OpenRC if I don't need it (which I
need to use my overlay right now).

I just want *my* choice to be a 1st class citizen in Gentoo; right now
it's not. If Gentoo is (as you say) "about choice" (which, BTW,  I
don't agree 100%), then I should be able to use systemd without OpenRC
without me needing to use an overlay, shouldn't I?

Again, please understand that my above (↑) reasons doesn't mean I
don't care about yours, or that you are wrong. It only means that our
reasons are different, and then perhaps the proper thing to do is to
agree to disagree.

> * "you tell the daemon *what* to do, not *how* to do it"
> It's good if you don't want to learn about what things you install and
> understand what the consequences are of different choices, in the config
> files. I run very few daemons on my desktop machine so it's not so time
> consuming to read up on/fix things etc. If I ever were to run a full
> blown server (esp. connected to the "net") with lots of daemons I would
> be very hesitant to use any pre-configurations, seems suicidal to me.
> The only usage I see here of "declarative" scripts are when you don't
> care about what the machine is doing.

I think you are gravely mistaken in this last point: you can learn
*all* the things you can from systemd as in OpenRC. The source is out
there, nothing is "hidding".

But, one last time, probably the best thing to do is to agree to
disagree; your answers to my technical points are all basically "I
don't wanna/I don't like it/I don't care about it"... which is
perfectly fine, but I can retort each and everyone with a mirror
argument.

So, yeah, let's just agree to disagree

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] Re: Anyone switched to eudev yet? -> what was wron with SysVInit?

[pk]

On 2012-12-28 00:24, Canek Peláez Valdés wrote:

> Well, yeah, that's the point. I want to install Gentoo in my mother's
> PC, and never have to go to her house because someting broke.

I really don't have the time nor the inclination to continue this but...
Why would you in that case install Gentoo and not Fedora? They (Fedora)
do the "kitchen-and-sink-installation" with systemd, which begs the
question: Why are you using Gentoo in the first place? I'm asking
because I honestly don't see why you would want to use it if you just
don't want to care about how the system works...

Also, all your "technical" arguments are not really technical at all;
It's merely a differing (from mine) philosophical view on how you think
a operating system should work (the details on how to solve that is
technical on the other hand). Which is what I was trying to show you
with my first reply... although a bit convoluted perhaps.

And on another note:
https://en.wikipedia.org/wiki/Fanboy#Fanboy.2Ffangirl

I don't really care about what init system I use but I do know what I
don't want and that's systemd. But I am a fanboy of Unix philosophy[1]:
"keep it simple, programs do one thing and do it well, clean interfaces,
portability etc..." (see how systemd doesn't fit that?).
So you can call me a fanboy too if you like, I don't care.

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

Best regards

Peter K

Re: [gentoo-user] Re: Anyone switched to eudev yet? -> what was wron with SysVInit?

[Michael Orlitzky]

On 12/28/12 13:15, pk wrote:
> On 2012-12-28 00:24, Canek Peláez Valdés wrote:
> 
>> Well, yeah, that's the point. I want to install Gentoo in my mother's
>> PC, and never have to go to her house because someting broke.
> 
> I really don't have the time nor the inclination to continue this but...
> Why would you in that case install Gentoo and not Fedora? They (Fedora)
> do the "kitchen-and-sink-installation" with systemd, which begs the
> question: Why are you using Gentoo in the first place? I'm asking
> because I honestly don't see why you would want to use it if you just
> don't want to care about how the system works...
> 

This has nothing to do with (e)udev, but Gentoo is actually easier to
keep working than any of the distributions that change everything all at
once on a Monday morning.

Fedora et al. are only easier to maintain for friends/family if you
don't plan on having the machine (or friend) for more than a year.

Re: [gentoo-user] Re: Anyone switched to eudev yet? -> what was wron with SysVInit?

[Canek Peláez Valdés]

On Fri, Dec 28, 2012 at 12:15 PM, pk <peterk2@coolmail.se> wrote:
> On 2012-12-28 00:24, Canek Peláez Valdés wrote:
>
>> Well, yeah, that's the point. I want to install Gentoo in my mother's
>> PC, and never have to go to her house because someting broke.
>
> I really don't have the time nor the inclination to continue this but...
> Why would you in that case install Gentoo and not Fedora?

Because I prefer 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] Re: Anyone switched to eudev yet? -> what was wron with SysVInit?

[pk]

On 2012-12-28 20:01, Canek Peláez Valdés wrote:

> Because I prefer Gentoo?

That's what I really don't understand! You say you don't want to care
about the system which implies Fedora or any other install-and-forget
distro. I care about the system which is why I run Gentoo. Do you have
USE=* in make.conf too? That last part is not to be taken seriously but
that's (basically) what the "masses" are running (and from what I can
interpret your emails that's what you want).

I'm done, thanks for listening.

Best regards

Peter K

Re: [gentoo-user] Re: Anyone switched to eudev yet? -> what was wron with SysVInit?

[Canek Peláez Valdés]

On Fri, Dec 28, 2012 at 4:40 PM, pk <peterk2@coolmail.se> wrote:
> On 2012-12-28 20:01, Canek Peláez Valdés wrote:
>
>> Because I prefer Gentoo?
>
> That's what I really don't understand! You say you don't want to care
> about the system which implies Fedora or any other install-and-forget
> distro. I care about the system which is why I run Gentoo. Do you have
> USE=* in make.conf too? That last part is not to be taken seriously but
> that's (basically) what the "masses" are running (and from what I can
> interpret your emails that's what you want).

I have USE="-kde -qt4" in my desktop/laptop. Last time I tried that
with RedHat and Mandrake (many, *many* years ago), it wasn't easy, and
I'm not certain that it is possible.

Like everyone here, I use Gentoo for it's flexibility at the moment of
configuring it. That doesn't mean I want to keep track of absolutely
everything in my machines; I love to set them up. Once. Then I love to
forget about them; they should just work.

> I'm done, thanks for listening.

Thanks to 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] Re: Anyone switched to eudev yet? -> what was wron with SysVInit?

[Volker Armin Hemmann]

Am Donnerstag, 27. Dezember 2012, 07:45:24 schrieb Pandu Poluan:
> On Dec 26, 2012 1:05 AM, "Canek Peláez Valdés" <caneko@gmail.com> wrote:
> Even Linus piped up at one point, sharply reminding
> Greg KH that even though udev was at one time Greg's 'baby', at this point
> udev serves only the wants of the few.

link?

-- 
#163933

Re: [gentoo-user] Re: Anyone switched to eudev yet? -> what was wron with SysVInit?

[Bruce Hill]

On Fri, Dec 28, 2012 at 02:06:27AM +0100, Volker Armin Hemmann wrote:
> Am Donnerstag, 27. Dezember 2012, 07:45:24 schrieb Pandu Poluan:
> > On Dec 26, 2012 1:05 AM, "Canek Peláez Valdés" <caneko@gmail.com> wrote:
> > Even Linus piped up at one point, sharply reminding
> > Greg KH that even though udev was at one time Greg's 'baby', at this point
> > udev serves only the wants of the few.
> 
> link?

Surf around here
http://thread.gmane.org/gmane.linux.drivers.video-input-infrastructure/49758/focus%3D55168
-- 
Happy Penguin Computers               >')
126 Fenco Drive                       ( \
Tupelo, MS 38801                       ^^
support@happypenguincomputers.com
662-269-2706 662-205-6424
http://happypenguincomputers.com/

Don't top-post: http://en.wikipedia.org/wiki/Top_post#Top-posting

Re: [gentoo-user] Re: Anyone switched to eudev yet? -> what was wron with SysVInit?

[Joshua Murphy]

On Tue, Dec 25, 2012 at 3:01 AM, Canek Peláez Valdés <caneko@gmail.com> wrote:
> [ snip ]
> * Really simple service unit files: The service unit files are really
> small, really simple, really easy to understand/modify. Compare the 9
> lines of sshd.service:
>
> $ cat /etc/systemd/system/sshd.service
> [Unit]
> Description=SSH Secure Shell Service
> After=syslog.target
>
> [Service]
> ExecStart=/usr/sbin/sshd -D
>
> [Install]
> WantedBy=multi-user.target
>
> with the 84 of /etc/init.d/sshd (80 without comments).
>
[snip]
>
> Hope it helps.
>
> Regards.
> --
> Canek Peláez Valdés
> Posgrado en Ciencia e Ingeniería de la Computación
> Universidad Nacional Autónoma de México
>

I've not yet made the leap, as the benefit of faster boot really
doesn't affect me between systems that're always on and laptops that
typically spend 75% of their time asleep, rather than ever getting
turned off, so I'm in no position to speak for or against the whole of
systemd's changes... but one issue I've had with the claimed benefits
is the reduction in size compared to startup scripts like
/etc/init.d/sshd ... based on that service declaration above, it's a
horribly unfair comparison. /etc/init.d/sshd is doing a lot more than
simply starting/stopping the service and dropping all of that
functionality, then claiming "these few lines serve the same purpose"
isn't an equal comparison. It would still be a (notable, at that) drop
in size if the shell script was redone to provide exactly the same set
of features, then compared, but that size difference wouldn't have the
same shock value as the comparison against 80+ lines. The argument
that those functions should be handled by the service rather than the
service handler is for another day, 'course.

I'll eventually get around to switching to play with systemd, at the
very least to learn its quirks enough to work with it, and it's very
helpful to have a clearly stated set of _favorable_ comments on it
(compared to the majority of less favorable commentary) to look
forward to, so don't take my having one issue with the list as
anything against either the list as a whole or your effort in putting
all that together, as both are very much appreciated.

Happy holidays.

-- 
Poison [BLX]
Joshua M. Murphy

Re: [gentoo-user] Re: Anyone switched to eudev yet? -> what was wron with SysVInit?

[Canek Peláez Valdés]

On Tue, Dec 25, 2012 at 7:56 AM, Joshua Murphy <poisonbl@gmail.com> wrote:
> On Tue, Dec 25, 2012 at 3:01 AM, Canek Peláez Valdés <caneko@gmail.com> wrote:
>> [ snip ]
>> * Really simple service unit files: The service unit files are really
>> small, really simple, really easy to understand/modify. Compare the 9
>> lines of sshd.service:
>>
>> $ cat /etc/systemd/system/sshd.service
>> [Unit]
>> Description=SSH Secure Shell Service
>> After=syslog.target
>>
>> [Service]
>> ExecStart=/usr/sbin/sshd -D
>>
>> [Install]
>> WantedBy=multi-user.target
>>
>> with the 84 of /etc/init.d/sshd (80 without comments).
>>
> [snip]
>>
>> Hope it helps.
>>
>> Regards.
>> --
>> Canek Peláez Valdés
>> Posgrado en Ciencia e Ingeniería de la Computación
>> Universidad Nacional Autónoma de México
>>
>
> I've not yet made the leap, as the benefit of faster boot really
> doesn't affect me between systems that're always on and laptops that
> typically spend 75% of their time asleep, rather than ever getting
> turned off, so I'm in no position to speak for or against the whole of
> systemd's changes... but one issue I've had with the claimed benefits
> is the reduction in size compared to startup scripts like
> /etc/init.d/sshd ... based on that service declaration above, it's a
> horribly unfair comparison. /etc/init.d/sshd is doing a lot more than
> simply starting/stopping the service and dropping all of that
> functionality, then claiming "these few lines serve the same purpose"
> isn't an equal comparison. It would still be a (notable, at that) drop
> in size if the shell script was redone to provide exactly the same set
> of features, then compared, but that size difference wouldn't have the
> same shock value as the comparison against 80+ lines. The argument
> that those functions should be handled by the service rather than the
> service handler is for another day, 'course.

No, I think that's the interesting argument. Like you say
"/etc/init.d/sshd is doing a lot more than simply starting/stopping
the service"; why it should do that? That's the work of the package
manager and/or the administrator. An init system should only
start/stop/monitor the services; it should not be checking if the keys
are generated or not, or if the config file is there or not. That
should happen at install time, and if for some reason they got borked
between the last reboot and this one, the system is probably fucked up
anyway, and putting checks in the *init script* will not help at all.

But *even* if you really want to have those checks, you can do it in
systemd in a cleaner way: put the checks in an executable script, and
call the script with ExecStartPre:

[Unit]
Description=SSH Secure Shell Service
After=syslog.target

[Service]
ExecStartPre=/usr/local/bin/checksshd
ExecStart=/usr/sbin/sshd -D

[Install]
WantedBy=multi-user.target

There; the unit file is now 10 lines, it *still* doesn't use a
Turing-complete language, you got your checks (which I believe they
don't belong there, but whatever), and it will timeout if the
checksshd goes into an infinite loop (30 seconds is the default
timeout, I believe).

That's how yo properly do more than start/stop/monitor services; the
init system doesn't need to know about it, you clearly move the init
system responsibility (start/stop/monitor services) from the service
requirements (checking that the config files are there, or that you
need to generate keys, which I repeat, I think they belong at install
time), and it keeps the unit files nice and simple.

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] Re: Anyone switched to eudev yet? -> what was wron with SysVInit?

[Kevin Chadwick]

On Tue, 25 Dec 2012 08:56:38 -0500
Joshua Murphy <poisonbl@gmail.com> wrote:

> It would still be a (notable, at that) drop
> in size if the shell script was redone to provide exactly the same set
> of features, then compared, but that size difference wouldn't have the
> same shock value as the comparison against 80+ lines.

If you look at the ssh devs distribution OpenBSD, sshd's rc config is a
one liner basically of simply enable or provide command line arguments.
Key checking is part of the OS startup script which is beautifully easy
to read and follow through to shutdown.

The turing complete language as oppose to the increased pid1 of systemd
is a theoretical fallacy where bugs can be immediately fixed with a
text editor or swapping the constantly tested but admittedly
complex shell code. Note though that init does not require a shell or
Turing complete language at all or anything else making it appropriate
in it's various forms to all cases. Ironically this variation can be
seen as unifying unix communities. What would be good is a common
agreement on the format or sysadmins equivelent to API of controlling a
universally applicable init system.

Re: [gentoo-user] Re: Anyone switched to eudev yet? -> what was wron with SysVInit?

[Kevin Chadwick]

On Tue, 25 Dec 2012 02:01:13 -0600
Canek Peláez Valdés <caneko@gmail.com> wrote:

To the OP of this OT sub-thread. The main difference for me is OpenRC
removes some of the symlink mess and uncertainty compared to for
example debians init. I very much like OpenRC but my fav is still
OpenBSD that tries to minimise the number of files/folders to be
potentially locked down and is very transparent and quick to follow
through.

> On Tue, Dec 25, 2012 at 1:38 AM, G.Wolfe Woodbury
> <redwolfe@gmail.com> wrote: [ snip ]
> > From what has been happening with the systemd stuff, I do not see
> > what advantages it really offers over the SysV scheme and its
> > successors like OpenRC.  Someone enlighten me please?
> 
> I wrote the following some months ago; I think nothing much has
> changed since then (I added a couple of comments):
> 
> Take this with a grain (or a kilo) of salt, since I'm obviously
> biased, but IMHO this are systemd advantages over OpenRC:
> 
> * Really fast boot. OpenRC takes at least double the time that systemd
> does when booting, easily verifiable. In my laptop systemd is twice as
> fast as OpenRC; in my desktop is three times faster. (With a solid
> state hard drive, my laptop now boots even faster).
> 

The usual statistic cited is 2 seconds but systemd can increase the
time dramatically or be a complete no go on embedded systems with
limited cpu and/or ram. Percentages of a section of the bootup is just
playing games like often used by annoying marketing departments. You
will save more boot time by switching to xfce from KDE/Gnome with
stronger arguments for doing so.

> * Really parallel service startup: OpenRC has never been reliable on
> parallel service startup; its documentation says it explicitly. Some
> will tell you that for them "it works", but just like the guys who
> have a separate /usr and refuse to use an initramfs, they just haven't
> been bitten by the inherent problems of it (just ask kernel developer
> Greg Kroah-Hartman). The Gentoo devs recognize that OpenRC is just
> broken with parallel service startup.
> 

Not only that but is seen by many to be pointless except to minute
speed gains and a cause of various problems such as increased
difficulty in determining where a problem occurs.

> * Really simple service unit files: The service unit files are really
> small, really simple, really easy to understand/modify. Compare the 9
> lines of sshd.service:
> 

But require reading documentation to understand with no other external
gain, unlike shell.

> 
> * Really good documentation: systemd has one of the best
> documentations I have ever seen in *any* project. Everything (except
> really new, experimental features) is documented, with manual pages
> explaining everything. And besides, there are blog posts by Lennart
> explaining in a more informal way how to do neat tricks with systemd.
> 

That explains why I see so many asking for help. The documentation may?
be complete but is terrible. Like LVM it is spread out into many
illogical files that would require a non existent sitemap to find.
OpenBSD is renowned for it's excellent documentation and note that it's
openssl pages are consolidated.

> * Really good in-site customization: The service unit files are
> trivially overrided with custom ones for specific installations,
> without needing to touch the ones installed by systemd or a program.
> With OpenRC, if I modify a /etc/init.d file, chances are I need to
> check out my next installation so I can see how the new file differs
> from the old one, and adapt the changes to my customized version.
> 

Nothing new, OpenBSD does similar. Completely aside from this
discussion.

> * All the goodies from Control Groups: You can use kernel cgroups to
> monitor/control several properties of your daemons, out of the box,
> almost no admin effort involved.
> 

The OpenBSD list pointed out the double forking argument to be
technically pointless.

http://marc.info/?l=openbsd-misc&m=135314269712851&w=2

> * It tries to unify Linux behaviour among distros (some can argue that
> this is a bad thing): Using systemd, the same
> configurations/techniques work the same in every distribution. No more
> need to learn /etc/conf.d, /etc/sysconfig, /etc/default hacks by
> different distros.
> 

So why was /etc/inittab removed for something that takes much more
effort to configure.

> * Finally, and what I think is the most fundamental difference between
> systemd and almost any other init system: The service unit files in
> systemd are *declarative*; you tell the daemon *what* to do, not *how*
> to do it. If the service files are shell scripts (like in
> OpenRC/SysV), everything can spiral out of control really easily. And
> it usually does (again, look at sshd; and that one is actully nicely
> written, there are all kind of monsters out there abusing the power
> that shell gives you).
> 

Then you don't have a great deal of experience in init systems.

> These are the ones off the top of my head; but what I like the most
> about systemd is that it just works, and that it makes a lot of sense
> (at least to me).
> 
> Most of systemd features can be implemented in OpenRC, although the
> speed difference will never be eliminated if OpenRC keeps using shell
> files; however, Luca Barbato said that using reentrant busybox the
> speed difference is greatly reduced (I haven't confirmed this, since I
> haven't even installed OpenRC in months).
>

So basically you like systemd because it does not follow the unix
philosohy of many small independent tools to be more than the sum of
it's parts and systemd absolutely unarguably does complicate the code
**REQUIRED** to boot using many external and other questionably desired
features as justification.

> Now, this set of (IMO) advantages of systemd over OpenRC pile up over
> the advantages of OpenRC over SysV: the most important one (I believe)
> is that OpenRC has dependencies, so a service starts only when another
> has already started. AFAIK, SysV has lacked this since always.
> 
> I don't think I have ever heard anyone saying that we should keep
> using SysV; like a lot of Unix legacies, it should just die. OpenRC is
> much better, but it still uses a Turing-complete language (and a
> really slow one) to simply tell services when to start and when to
> stop, and it doesn't reliably keep track of what services are really
> still running (anyone who has ever used the "zap" command in OpenRC
> knows this).
> 
> systemd of course has dependencies, a reliable tracking of service
> status (thanks in part to the use of cgroups), and its service files
> can't enter in an infinite loop.
> 
> Hope it helps.
> 
> Regards.

Enough time has been wasted on systemd including my own so start a new
thread that I can ignore from now on please or better still accept
that systemd is dividing and not unifying the unix community. Once you
realise that re-question everything else.

Re: [gentoo-user] Re: Anyone switched to eudev yet? -> what was wron with SysVInit?

[Canek Peláez Valdés]

On Wed, Dec 26, 2012 at 4:19 PM, Kevin Chadwick <ma1l1ists@yahoo.co.uk> wrote:
> On Tue, 25 Dec 2012 02:01:13 -0600
> Canek Peláez Valdés <caneko@gmail.com> wrote:
>
> To the OP of this OT sub-thread. The main difference for me is OpenRC
> removes some of the symlink mess and uncertainty compared to for
> example debians init. I very much like OpenRC but my fav is still
> OpenBSD that tries to minimise the number of files/folders to be
> potentially locked down and is very transparent and quick to follow
> through.
>
>> On Tue, Dec 25, 2012 at 1:38 AM, G.Wolfe Woodbury
>> <redwolfe@gmail.com> wrote: [ snip ]
>> > From what has been happening with the systemd stuff, I do not see
>> > what advantages it really offers over the SysV scheme and its
>> > successors like OpenRC.  Someone enlighten me please?
>>
>> I wrote the following some months ago; I think nothing much has
>> changed since then (I added a couple of comments):
>>
>> Take this with a grain (or a kilo) of salt, since I'm obviously
>> biased, but IMHO this are systemd advantages over OpenRC:
>>
>> * Really fast boot. OpenRC takes at least double the time that systemd
>> does when booting, easily verifiable. In my laptop systemd is twice as
>> fast as OpenRC; in my desktop is three times faster. (With a solid
>> state hard drive, my laptop now boots even faster).
>>
>
> The usual statistic cited is 2 seconds but systemd can increase the
> time dramatically or be a complete no go on embedded systems with
> limited cpu and/or ram. Percentages of a section of the bootup is just
> playing games like often used by annoying marketing departments. You
> will save more boot time by switching to xfce from KDE/Gnome with
> stronger arguments for doing so.
>
>> * Really parallel service startup: OpenRC has never been reliable on
>> parallel service startup; its documentation says it explicitly. Some
>> will tell you that for them "it works", but just like the guys who
>> have a separate /usr and refuse to use an initramfs, they just haven't
>> been bitten by the inherent problems of it (just ask kernel developer
>> Greg Kroah-Hartman). The Gentoo devs recognize that OpenRC is just
>> broken with parallel service startup.
>>
>
> Not only that but is seen by many to be pointless except to minute
> speed gains and a cause of various problems such as increased
> difficulty in determining where a problem occurs.
>
>> * Really simple service unit files: The service unit files are really
>> small, really simple, really easy to understand/modify. Compare the 9
>> lines of sshd.service:
>>
>
> But require reading documentation to understand with no other external
> gain, unlike shell.
>
>>
>> * Really good documentation: systemd has one of the best
>> documentations I have ever seen in *any* project. Everything (except
>> really new, experimental features) is documented, with manual pages
>> explaining everything. And besides, there are blog posts by Lennart
>> explaining in a more informal way how to do neat tricks with systemd.
>>
>
> That explains why I see so many asking for help. The documentation may?
> be complete but is terrible. Like LVM it is spread out into many
> illogical files that would require a non existent sitemap to find.
> OpenBSD is renowned for it's excellent documentation and note that it's
> openssl pages are consolidated.
>
>> * Really good in-site customization: The service unit files are
>> trivially overrided with custom ones for specific installations,
>> without needing to touch the ones installed by systemd or a program.
>> With OpenRC, if I modify a /etc/init.d file, chances are I need to
>> check out my next installation so I can see how the new file differs
>> from the old one, and adapt the changes to my customized version.
>>
>
> Nothing new, OpenBSD does similar. Completely aside from this
> discussion.
>
>> * All the goodies from Control Groups: You can use kernel cgroups to
>> monitor/control several properties of your daemons, out of the box,
>> almost no admin effort involved.
>>
>
> The OpenBSD list pointed out the double forking argument to be
> technically pointless.
>
> http://marc.info/?l=openbsd-misc&m=135314269712851&w=2
>
>> * It tries to unify Linux behaviour among distros (some can argue that
>> this is a bad thing): Using systemd, the same
>> configurations/techniques work the same in every distribution. No more
>> need to learn /etc/conf.d, /etc/sysconfig, /etc/default hacks by
>> different distros.
>>
>
> So why was /etc/inittab removed for something that takes much more
> effort to configure.
>
>> * Finally, and what I think is the most fundamental difference between
>> systemd and almost any other init system: The service unit files in
>> systemd are *declarative*; you tell the daemon *what* to do, not *how*
>> to do it. If the service files are shell scripts (like in
>> OpenRC/SysV), everything can spiral out of control really easily. And
>> it usually does (again, look at sshd; and that one is actully nicely
>> written, there are all kind of monsters out there abusing the power
>> that shell gives you).
>>
>
> Then you don't have a great deal of experience in init systems.
>
>> These are the ones off the top of my head; but what I like the most
>> about systemd is that it just works, and that it makes a lot of sense
>> (at least to me).
>>
>> Most of systemd features can be implemented in OpenRC, although the
>> speed difference will never be eliminated if OpenRC keeps using shell
>> files; however, Luca Barbato said that using reentrant busybox the
>> speed difference is greatly reduced (I haven't confirmed this, since I
>> haven't even installed OpenRC in months).
>>
>
> So basically you like systemd because it does not follow the unix
> philosohy of many small independent tools to be more than the sum of
> it's parts and systemd absolutely unarguably does complicate the code
> **REQUIRED** to boot using many external and other questionably desired
> features as justification.
>
>> Now, this set of (IMO) advantages of systemd over OpenRC pile up over
>> the advantages of OpenRC over SysV: the most important one (I believe)
>> is that OpenRC has dependencies, so a service starts only when another
>> has already started. AFAIK, SysV has lacked this since always.
>>
>> I don't think I have ever heard anyone saying that we should keep
>> using SysV; like a lot of Unix legacies, it should just die. OpenRC is
>> much better, but it still uses a Turing-complete language (and a
>> really slow one) to simply tell services when to start and when to
>> stop, and it doesn't reliably keep track of what services are really
>> still running (anyone who has ever used the "zap" command in OpenRC
>> knows this).
>>
>> systemd of course has dependencies, a reliable tracking of service
>> status (thanks in part to the use of cgroups), and its service files
>> can't enter in an infinite loop.
>>
>> Hope it helps.
>>
>> Regards.
>
> Enough time has been wasted on systemd including my own so start a new
> thread that I can ignore from now on please or better still accept
> that systemd is dividing and not unifying the unix community. Once you
> realise that re-question everything else.

I didn't started the thread, Wolfe did. I just answered his question
from my point of view.

And, what community is being divided? Fedora,OpenSuse, and Arch use
systemd by default. Gentoo derivative Exherbo recommends it as init
system. It works great on Gentoo and Debian. I understand it even
works in Ubuntu. systemd has done more to unify the Linux ecosystem
than a lot of other projects in the last 20 years.

And, really, I don't care about OpenBSD. I worked with it for three
years; it's a nice toy Unix. But for serious work (server, desktop and
mobile) I prefer Linux, and in my case (except for my phone, that uses
Android) I run Gentoo+systemd in all my machines. You don't have to
agree with that, is my personal preference.

So it's great if you believe that the OpenBSD init system is similar
in features to systemd; but even if it's true (which I seriously
doubt), I care only about Linux, and from my point of view, systemd is
one of the best things to happen to 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] Re: Anyone switched to eudev yet? -> what was wron with SysVInit?

[Michael Mol]

On Wed, Dec 26, 2012 at 6:01 PM, Canek Peláez Valdés <caneko@gmail.com> wrote:

[snip]

> I didn't started the thread, Wolfe did. I just answered his question
> from my point of view.
>
> And, what community is being divided? Fedora,OpenSuse, and Arch use
> systemd by default. Gentoo derivative Exherbo recommends it as init
> system. It works great on Gentoo and Debian. I understand it even
> works in Ubuntu. systemd has done more to unify the Linux ecosystem
> than a lot of other projects in the last 20 years.
>
> And, really, I don't care about OpenBSD. I worked with it for three
> years; it's a nice toy Unix.

You do realize you just lost any moral high ground you might have had
over saying things that might or might not offend others? Seriously?
"toy"?

I'm not an OpenBSD user. But I do know it's one of the longest-lived,
most prominent UNIX-like systems in the ecosystem, and it's the home
for a huge amount of code that's imported by virtually every other
notable operating system.

To call it a "toy" tells me you know next to nothing about the history
(or even present) positions and involvement of the major players of
the UNIX-like ecosystem over the last twenty years.

> But for serious work (server, desktop and
> mobile) I prefer Linux, and in my case (except for my phone, that uses
> Android) I run Gentoo+systemd in all my machines. You don't have to
> agree with that, is my personal preference.

Canek, I have to ask. Have you ever done _anything_ outside of
academia? Up to Masters, academia is learning about what is.
Afterward, it's either about teaching or discovering what may be...but
a Masters only teaches you theory. A Doctorate is a discovery of a
truth under controlled conditions. The real world is nowhere near that
clean.

Quite frankly, I've found your emails to have to have a far more pomp,
ipsie dixit arguments, playbook arguments and appeals to authority
than hard, technical defense of arguments against your positions in
debate. Generally, I try to ignore you, and when I respond, it's
usually because your emails carry with them a tone of authority that
could easily mislead the uninformed into assuming he'd just read the
One True Way on some subject--something that's terrible when there are
real differences and not always clear-cut answers.

I try very, very hard to avoid both the use and appearance of use of
ad hominem arguments and reasoning. I do my damnedest to give the
benefit of the doubt. However, quite frankly, I've read almost
everything you've posted to this list over the last year and a half,
and you've never consistently exhibited an awareness of pragmatic
concerns for the subject, an understanding of the low levels issues in
theoretical concerns of the subject, or an ability to stick to
technical argument in a non-evasive fashion; that you might be wrong
on a technical point never occurs to you, and when pressed, you engage
in sophistry. Quite frankly, you act and speak more like a PR
spokesman than an engineer.

It's this behavior that probably led Bruce to make a crack about your
defense of systemd to an irrational degree. You advocate, but you
don't respond to criticisms with substance, suggesting your advocacy
isn't something based on rational motivation.

My purpose in debate isn't to win, it's to understand. I would be
positively delighted if you would approach debate the with the same
goal; we might be able to learn from each other.

--
:wq

Re: [gentoo-user] Re: Anyone switched to eudev yet? -> what was wron with SysVInit?

[Canek Peláez Valdés]

On Wed, Dec 26, 2012 at 5:51 PM, Michael Mol <mikemol@gmail.com> wrote:
> On Wed, Dec 26, 2012 at 6:01 PM, Canek Peláez Valdés <caneko@gmail.com> wrote:
>
> [snip]
>
>> I didn't started the thread, Wolfe did. I just answered his question
>> from my point of view.
>>
>> And, what community is being divided? Fedora,OpenSuse, and Arch use
>> systemd by default. Gentoo derivative Exherbo recommends it as init
>> system. It works great on Gentoo and Debian. I understand it even
>> works in Ubuntu. systemd has done more to unify the Linux ecosystem
>> than a lot of other projects in the last 20 years.
>>
>> And, really, I don't care about OpenBSD. I worked with it for three
>> years; it's a nice toy Unix.
>
> You do realize you just lost any moral high ground you might have had
> over saying things that might or might not offend others? Seriously?
> "toy"?

Hey, it's my opinion. You don't need to agree with me and, again, I
don't pretend to offend anyone. It's jsut what I think. Have you read
the name calling against GNOME and udev/systemd projects, developers
and/or users?  How come you never say anything about those?

> I'm not an OpenBSD user. But I do know it's one of the longest-lived,
> most prominent UNIX-like systems in the ecosystem, and it's the home
> for a huge amount of code that's imported by virtually every other
> notable operating system.

Longest-lived mean nothing. Literally. Minix is older than all the
modern *BSDs and Linux, and its author called it (until recently) a
toy Unix.

> To call it a "toy" tells me you know next to nothing about the history
> (or even present) positions and involvement of the major players of
> the UNIX-like ecosystem over the last twenty years.

I know my Unix history, thank you very much. Do you? You read LWN, don't you?

http://lwn.net/Articles/524606/

I call OpenBSD a toy Unix in the sense of the above article's quote:

"There will be fewer and fewer settings where BSD-based systems will
operate in the way their users want.

That, needless to say, is a recipe for irrelevance and, eventually,
disappearance."

>> But for serious work (server, desktop and
>> mobile) I prefer Linux, and in my case (except for my phone, that uses
>> Android) I run Gentoo+systemd in all my machines. You don't have to
>> agree with that, is my personal preference.
>
> Canek, I have to ask. Have you ever done _anything_ outside of
> academia? Up to Masters, academia is learning about what is.
> Afterward, it's either about teaching or discovering what may be...but
> a Masters only teaches you theory. A Doctorate is a discovery of a
> truth under controlled conditions. The real world is nowhere near that
> clean.

Again, thank you for teaching me about the real world. I worked for
various years between my Bachelor's and Master's degrees, programming
and administering Linux, SCO, BSD and Aix systems. I still administer
several machines in my university. I think I know the real world,
thanks.

> Quite frankly, I've found your emails to have to have a far more pomp,
> ipsie dixit arguments, playbook arguments and appeals to authority
> than hard, technical defense of arguments against your positions in
> debate. Generally, I try to ignore you, and when I respond, it's
> usually because your emails carry with them a tone of authority that
> could easily mislead the uninformed into assuming he'd just read the
> One True Way on some subject--something that's terrible when there are
> real differences and not always clear-cut answers.

Relax Michael; as I said in other emails: who the fuck cares what I
say or who I am? Wolfe made a question, I tried to answer it to the
best of my knowledge. That's it: nobody has to agree with me, nobody
has to do anything about what I write. Not even read it.

By the way,  did you read whay Kevin told me?

"""
> * Finally, and what I think is the most fundamental difference between
> systemd and almost any other init system: The service unit files in
> systemd are *declarative*; you tell the daemon *what* to do, not *how*
> to do it. If the service files are shell scripts (like in
> OpenRC/SysV), everything can spiral out of control really easily. And
> it usually does (again, look at sshd; and that one is actully nicely
> written, there are all kind of monsters out there abusing the power
> that shell gives you).
>

Then you don't have a great deal of experience in init systems.
"""

I understand that in the Gentoo mailing lists (which doens't
necessarily reflect the Gentoo community as a whole), us udev/systemd
users and supporters look like a (very maligned) minority. I
understand a lot of people here doesn't like the direction
udev/systemd is taking Linux. But it's really kinda funny how people
react when we calmly try to express why do we like said direction.

> I try very, very hard to avoid both the use and appearance of use of
> ad hominem arguments and reasoning. I do my damnedest to give the
> benefit of the doubt. However, quite frankly, I've read almost
> everything you've posted to this list over the last year and a half,
> and you've never consistently exhibited an awareness of pragmatic
> concerns for the subject, an understanding of the low levels issues in
> theoretical concerns of the subject, or an ability to stick to
> technical argument in a non-evasive fashion; that you might be wrong
> on a technical point never occurs to you, and when pressed, you engage
> in sophistry. Quite frankly, you act and speak more like a PR
> spokesman than an engineer.

I'm not an engineer. I'm a computer scientist for what is worth.

> It's this behavior that probably led Bruce to make a crack about your
> defense of systemd to an irrational degree. You advocate, but you
> don't respond to criticisms with substance, suggesting your advocacy
> isn't something based on rational motivation.

In yout point of view, sure.

> My purpose in debate isn't to win, it's to understand. I would be
> positively delighted if you would approach debate the with the same
> goal; we might be able to learn from each other.

I have learned from you Michael; you usually have something
intelligent to say, and you usually do with calm and an open mind. I'm
sorry if you don't think the same of me, but as I said in the other
threads, I try to stick to the technical arguments.

Of course sometimes I'm wrong. I just don't understand what it has to
do with anything in this thread in particular: Wolfe asked what
advantages had OpenRC and systemd over SysV, and I said the ones *I*
believe are the most important ones. Nothing else.

Then Kevin started to suggest that I know nothing about init systems,
and I responded in kind. Perhaps I shouldn't have, that I give you,
but if that's the tone that starts to populate the thread, I felt that
it was the right thing to do. Again, perhaps I'm wrong.

I don't pretend to "win" anything, by the way. As I have said many
times, the future of Linux is in the hands of the people writing the
code, not the people screaming at each other about what is right or
wrong. I doesn't matter the discussion here if no one involved writes
a single line of code. I just saw Wolfe's question, and I tried (I
hope I succeeded) to respond it.

Probably I should have dono like you do and ignore Kevin's response.
Perhaps I will do that next time.

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] Re: Anyone switched to eudev yet? -> what was wron with SysVInit?

[Kevin Chadwick]

> * Finally, and what I think is the most fundamental difference between
> systemd and almost any other init system: The service unit files in
> systemd are *declarative*; you tell the daemon *what* to do, not *how*
> to do it. If the service files are shell scripts (like in
> OpenRC/SysV), everything can spiral out of control really easily. And
> it usually does (again, look at sshd; and that one is actully nicely
> written, there are all kind of monsters out there abusing the power
> that shell gives you).
>  

> Then Kevin started to suggest that I know nothing about init systems,
> and I responded in kind.

I did not and apologise if you took offense. I said perhaps badly that
based on this posting, you don't have a great deal of experience in
init systems. To me, your comment demonstrated that you don't on the
vast plethora of init systems which all actually accomplish the same
thing daemon wise just with varying reliability and functionality
surrounding the process of doing so. No init system can tell a daemon
how to do anything.

So your comment.

What to do, how to do actually has nothing to do with systemd.

What does is having to learn a new more restrictive non
intuitive and non externally useful or non universal *declarative*
language. Like polkit/pkexecs javascript vs sudo. I will take sudoers
every time and for good reason.

"Shell scripts usually spiral out of control" is just utter FUD. I
do realise you didn't originate this FUD, but it shouldn't be
spread. Yes some corner case wants in init that some thought
impossible in shell can get complex by scripting them but a small c
tool following the unix philosophy simply becomes a shell command
potentially useful in even unforeseeable cases.

We are dealing with simple options meant for admins here. As I said
OpenBSDs scripts are usually rediculously simple and should often
really be called commands. As others have said the argument of function
being in the scripts rather than the daemon is an irrelevance to using
systemd. Systemd may try to become the whole OS but I'm fairly sure it
hasn't plagiarised the c code to check and deal with ssh keys yet. That
is rightly the job of the aptly named ssh-keygen and IMO some very
simple shell code.

The arch sshd script is only 44 lines and includes more than that to
make the output colourful. The gentoo sshd script is actually simple
too and doesn't do anything most of the time and is easily modifiable
in absolutely predictable ways.

-- 
_______________________________________________________________________

'Write programs that do one thing and do it well. Write programs to work
together. Write programs to handle text streams, because that is a
universal interface'

(Doug McIlroy)
_______________________________________________________________________

Re: [gentoo-user] Re: Anyone switched to eudev yet? -> what was wron with SysVInit?

[Canek Peláez Valdés]

On Thu, Dec 27, 2012 at 10:29 AM, Kevin Chadwick <ma1l1ists@yahoo.co.uk> wrote:
>> * Finally, and what I think is the most fundamental difference between
>> systemd and almost any other init system: The service unit files in
>> systemd are *declarative*; you tell the daemon *what* to do, not *how*
>> to do it. If the service files are shell scripts (like in
>> OpenRC/SysV), everything can spiral out of control really easily. And
>> it usually does (again, look at sshd; and that one is actully nicely
>> written, there are all kind of monsters out there abusing the power
>> that shell gives you).
>>
>
>> Then Kevin started to suggest that I know nothing about init systems,
>> and I responded in kind.
>
> I did not and apologise if you took offense.

Apology accepted, and I also apologise if my response was out of
line/with bad tone.

> I said perhaps badly that
> based on this posting, you don't have a great deal of experience in
> init systems.

Well, I haven't wrote any, but I used the ones in OpenBSD, Solaris,
Linux SysV, OpenRC systemd, and Windows NT. Used as in administering
several machines with them. So, I have some experience.

> To me, your comment demonstrated that you don't on the
> vast plethora of init systems which all actually accomplish the same
> thing daemon wise just with varying reliability and functionality
> surrounding the process of doing so. No init system can tell a daemon
> how to do anything.

You are wrong. In SysV, I can *write* the daemon in the init script.
In *that* sense, the init system tells the daemon how to do things,
and to a lesser degree,  it happens when you use a shell to launch
daemons.

> So your comment.
>
> What to do, how to do actually has nothing to do with systemd.
>
> What does is having to learn a new more restrictive non
> intuitive and non externally useful or non universal *declarative*
> language. Like polkit/pkexecs javascript vs sudo. I will take sudoers
> every time and for good reason.

I'm not 100% happy with Polkit use of JS, but having finally
understood how it works, I think is kind of nice. I believe role
verification and authentication is one of the tasks where a
Turing-complete language actually be justified.

> "Shell scripts usually spiral out of control" is just utter FUD. I
> do realise you didn't originate this FUD, but it shouldn't be
> spread. Yes some corner case wants in init that some thought
> impossible in shell can get complex by scripting them but a small c
> tool following the unix philosophy simply becomes a shell command
> potentially useful in even unforeseeable cases.

Funny that you said that; if you are really interested, take a look at
/usr/lib/systemd in a systemd machine. Almost all of those are really
simple C programs that do one thing, and one thing only. Most of them
don't reach the 100 lines of C code.

To me, a Turing-complete language for starting and stoping services is
overkill. And also there is the Halting Problem; you simply cannot
workaround that.

> We are dealing with simple options meant for admins here. As I said
> OpenBSDs scripts are usually rediculously simple and should often
> really be called commands. As others have said the argument of function
> being in the scripts rather than the daemon is an irrelevance to using
> systemd. Systemd may try to become the whole OS but I'm fairly sure it
> hasn't plagiarised the c code to check and deal with ssh keys yet. That
> is rightly the job of the aptly named ssh-keygen and IMO some very
> simple shell code.

Yeah, running from the install
script/Makefile/post-inst-hook/whatever. Not the init system. IMO.

> The arch sshd script is only 44 lines and includes more than that to
> make the output colourful. The gentoo sshd script is actually simple
> too and doesn't do anything most of the time and is easily modifiable
> in absolutely predictable ways.

I'm not arguing that; I'm arguing that it can be done even more
simple, and even more easily modifiable.

But like a said to Pandou; let's just agree to disagree.

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] Re: Anyone switched to eudev yet? -> what was wron with SysVInit?

[Kevin Chadwick]

On Thu, 27 Dec 2012 17:38:15 -0600
Canek Peláez Valdés <caneko@gmail.com> wrote:

> In SysV, I can *write* the daemon in the init script.
> In *that* sense, the init system tells the daemon how to do things,

Please explain, sure there is the environment that tells a daemon what
to do. No shell can tell a c daemon like sshd how to drop priviledges
or use systrace but it could do these things for it in a more fine
grained manner before it tries and fails itself or if the daemon
wishes it to like monit. It's still not telling how but duplicating or
removing the need. That's just a bonus that applies to all init
systems because shell is so powerful on unix.

Re: [gentoo-user] Re: Anyone switched to eudev yet? -> what was wron with SysVInit?

[Canek Peláez Valdés]

On Fri, Dec 28, 2012 at 12:53 PM, Kevin Chadwick <ma1l1ists@yahoo.co.uk> wrote:
> On Thu, 27 Dec 2012 17:38:15 -0600
> Canek Peláez Valdés <caneko@gmail.com> wrote:
>
>> In SysV, I can *write* the daemon in the init script.
>> In *that* sense, the init system tells the daemon how to do things,
>
> Please explain, sure there is the environment that tells a daemon what
> to do. No shell can tell a c daemon like sshd how to drop priviledges
> or use systrace but it could do these things for it in a more fine
> grained manner before it tries and fails itself or if the daemon
> wishes it to like monit. It's still not telling how but duplicating or
> removing the need. That's just a bonus that applies to all init
> systems because shell is so powerful on unix.

Stop thinking in sshd. I can write the *whole* daemon in shell, not in
another script file, but inside /etc/init.d/mystupiddaemon (or
/etc/rc.whatever); shell is Turing-complete, I can write in it
anything I can write in C (or in assembler, or machine code). In that
sense, the init system (which uses shell for launching daemons) can be
used to determine *how* the daemon behaves (because it uses shell for
launching daemons).

You can't do that with systemd; there is a clear and unavoidable
separation between the starting/stoping/monitoring of daemons, and the
daemons themselves. Such distinction doesn't really exists in SysV nor
OpenRC (since they use shell, a Turing-complete language, for
launching daemons), and therefore you can mixup everything. I agree,
it doesn't necessarily means that it *will* happen; but even the
possibility is frigthning for a system administrator in a production
server. With systemd, that possibility *doesn't exist* (because it
doesn't uses a Turing-complete language to start/stop/monitor
daemons).

Like the clear separation between content and presentation in webapps,
or between the model and the view in the MVC design patter, having a
clear separation between how you start/stop/monitor your daemon, and
what the daemon does, is a good thing. If you don't agree with that,
well, we must agree to disagree.

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] Re: Anyone switched to eudev yet? -> what was wron with SysVInit?

[Pandu Poluan]

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

On Dec 29, 2012 2:18 AM, "Canek Peláez Valdés" <caneko@gmail.com> wrote:
>
> Stop thinking in sshd. I can write the *whole* daemon in shell, not in
> another script file, but inside /etc/init.d/mystupiddaemon (or
> /etc/rc.whatever); shell is Turing-complete, I can write in it
> anything I can write in C (or in assembler, or machine code). In that
> sense, the init system (which uses shell for launching daemons) can be
> used to determine *how* the daemon behaves (because it uses shell for
> launching daemons).
>
> You can't do that with systemd; there is a clear and unavoidable
> separation between the starting/stoping/monitoring of daemons, and the
> daemons themselves. Such distinction doesn't really exists in SysV nor
> OpenRC (since they use shell, a Turing-complete language, for
> launching daemons), and therefore you can mixup everything. I agree,
> it doesn't necessarily means that it *will* happen; but even the
> possibility is frigthning for a system administrator in a production
> server.

You got it wrong.

SysAdmins, especially Enterprise SysAdmins, will prefer total control of
the startup process. If a daemon is extremely important for enterprise
operation, any SysAdmin worth his/her salary will fire up vi (or emacs) and
pepper the code with asserts and instrumentation.

Having a Turing-complete language for starting a script is one of our (=
Enterprise SysAdmins) weapon for fixing up glitches due to some changes
introduced by the package maintainer.

An example: A dev needs a newer version of a package. We upgrade it. It
refuses to startup properly, but going back is out of the question because
the dev *needs* the features only available in the new version. We check
the (extremely) detailed logs. We find out what made the package balked. We
do some changes, and all is well.

Another example: After a security audit, we are required to upgrade a
certain daemon to a new version, despite the current version running well.
As we feared, the new version can't start. We use the detailed log to find
out what happened. We made changes. It works again.

In the two examples I give, having a C program doing all the starting will
certainly mean that complex things have to be done, not to mention the
headache of compiling them -- and possibly fail.

sh scripts are much easier to modify.

> Like the clear separation between content and presentation in webapps,
> or between the model and the view in the MVC design patter, having a
> clear separation between how you start/stop/monitor your daemon, and
> what the daemon does, is a good thing.

That is the Theory. In Practice, things don't work that way. Murphy's Law
reigns supreme.

Rgds,
--

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

Re: [gentoo-user] Re: Anyone switched to eudev yet? -> what was wron with SysVInit?

[Canek Peláez Valdés]

On Fri, Dec 28, 2012 at 2:17 PM, Pandu Poluan <pandu@poluan.info> wrote:
>
> On Dec 29, 2012 2:18 AM, "Canek Peláez Valdés" <caneko@gmail.com> wrote:
>>
>> Stop thinking in sshd. I can write the *whole* daemon in shell, not in
>> another script file, but inside /etc/init.d/mystupiddaemon (or
>> /etc/rc.whatever); shell is Turing-complete, I can write in it
>> anything I can write in C (or in assembler, or machine code). In that
>> sense, the init system (which uses shell for launching daemons) can be
>> used to determine *how* the daemon behaves (because it uses shell for
>> launching daemons).
>>
>> You can't do that with systemd; there is a clear and unavoidable
>> separation between the starting/stoping/monitoring of daemons, and the
>> daemons themselves. Such distinction doesn't really exists in SysV nor
>> OpenRC (since they use shell, a Turing-complete language, for
>> launching daemons), and therefore you can mixup everything. I agree,
>> it doesn't necessarily means that it *will* happen; but even the
>> possibility is frigthning for a system administrator in a production
>> server.
>
> You got it wrong.

I don't believe so.

> SysAdmins, especially Enterprise SysAdmins, will prefer total control of the
> startup process. If a daemon is extremely important for enterprise
> operation, any SysAdmin worth his/her salary will fire up vi (or emacs) and
> pepper the code with asserts and instrumentation.

Pandou, I have worked as SysAdmin. Several years. "Total control" has
degrees; if you program in assembly language, you have even more
control. And with systemd you can still fire up vi or Emacs (or, if
you prefer "total control", ed), and fix *your* daemon. If systemd has
a bug, you can still look at the code, and fix *that* code. What you
say doesn't make any sense: "any SysAdmin worth his/her salary will
fire up vi (or emacs) and pepper the code with asserts and
instrumentation" works in SysV, OpenRC, systemd, and anything else as
long as you have the source code. The only problem resides in
proprietary code.

> Having a Turing-complete language for starting a script is one of our (=
> Enterprise SysAdmins) weapon for fixing up glitches due to some changes
> introduced by the package maintainer.

Again, you make no sense: you can fix "glitches" as long as you have
the source code. You can roll your own packages (I maintain my overlay
to get rid of OpenRC on my systems). That some SysAdmins can *only*
code properly (if at all) in shell is a problem of *those* SysAdmins.
A worthy SysAdmin, if encountering a bug with systemd, can easily
check out the C code and fix it (it's relatively simple, not
kernel-level).

And having a separation between the starting/stoping of daemons and
the daemons themselves makes it easier to check where the bug lies,
and fixing accordingly, instead of patching blindly to workaround the
real problem.

> An example: A dev needs a newer version of a package. We upgrade it. It
> refuses to startup properly, but going back is out of the question because
> the dev *needs* the features only available in the new version. We check the
> (extremely) detailed logs. We find out what made the package balked. We do
> some changes, and all is well.

How that is not possible in systemd?

> Another example: After a security audit, we are required to upgrade a
> certain daemon to a new version, despite the current version running well.
> As we feared, the new version can't start. We use the detailed log to find
> out what happened. We made changes. It works again.

How that is not possible in systemd? Have you ever used it?

> In the two examples I give, having a C program doing all the starting will
> certainly mean that complex things have to be done, not to mention the
> headache of compiling them -- and possibly fail.

You are assuming the problem is going to be in systemd's side. First
of all, that will not always be the case. Second, if it is the case,
you go and fix it. You still have the code.

SysAdmin's laziness is not an excuse to do things wrong. It's also
"more complex" to add comments to the code, it's "more complex" to
take notes of the procedures rolling servers, it's "more complex" to
keep a database of the versions running in each machine, and what
hardware has and when it was installed. It's always "more complex" to
properly do the job.

> sh scripts are much easier to modify.

Read above.

>> Like the clear separation between content and presentation in webapps,
>> or between the model and the view in the MVC design patter, having a
>> clear separation between how you start/stop/monitor your daemon, and
>> what the daemon does, is a good thing.
>
> That is the Theory. In Practice, things don't work that way. Murphy's Law
> reigns supreme.

Then we should agree to disagree in this particular issue.

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] Re: Anyone switched to eudev yet? -> what was wron with SysVInit?

[Mark David Dumlao]

On Sat, Dec 29, 2012 at 4:17 AM, Pandu Poluan <pandu@poluan.info> wrote:
> An example: A dev needs a newer version of a package. We upgrade it. It
> refuses to startup properly, but going back is out of the question because
> the dev *needs* the features only available in the new version. We check the
> (extremely) detailed logs. We find out what made the package balked. We do
> some changes, and all is well.
>
> Another example: After a security audit, we are required to upgrade a
> certain daemon to a new version, despite the current version running well.
> As we feared, the new version can't start. We use the detailed log to find
> out what happened. We made changes. It works again.
>
> In the two examples I give, having a C program doing all the starting will
> certainly mean that complex things have to be done, not to mention the
> headache of compiling them -- and possibly fail.

You obviously haven't the slightest _clue_ what the hell you're talking about.
1) systemd does not prevent you from checking logs. If anything the
systemd journal gives you more fine-grained tools for ensuring that
some logs came from some daemon, not so easy to ensure when your log
file is being peppered with auth attempts and whatnot.
2) the "make some changes" part you mentioned has little, if anything,
to do with the init script that started it. "Any Enterprise SysAdmin
worth his salt", to use your term, knows it's 99% something he
overlooked in the config settings that are independent of the startup
system.
3) "Having a C program doing all the starting" doesn't imply complex
things have to be done, because in most cases your startup script -
whatever it's written in - simply calls the program with the right
arguments. Ironically, shell scripts only appear simpler because
_someone has already done the complex things for you_.
--
This email is:    [ ] actionable   [ ] fyi        [x] social
Response needed:  [ ] yes          [x] up to you  [ ] no
Time-sensitive:   [ ] immediate    [ ] soon       [x] none

Re: [gentoo-user] Re: Anyone switched to eudev yet? -> what was wron with SysVInit?

[Kevin Chadwick]

On Fri, 28 Dec 2012 13:14:46 -0600
Canek Peláez Valdés <caneko@gmail.com> wrote:

> On Fri, Dec 28, 2012 at 12:53 PM, Kevin Chadwick
> <ma1l1ists@yahoo.co.uk> wrote:
> > On Thu, 27 Dec 2012 17:38:15 -0600
> > Canek Peláez Valdés <caneko@gmail.com> wrote:
> >
> >> In SysV, I can *write* the daemon in the init script.
> >> In *that* sense, the init system tells the daemon how to do things,
> >
> > Please explain, sure there is the environment that tells a daemon
> > what to do. No shell can tell a c daemon like sshd how to drop
> > priviledges or use systrace but it could do these things for it in
> > a more fine grained manner before it tries and fails itself or if
> > the daemon wishes it to like monit. It's still not telling how but
> > duplicating or removing the need. That's just a bonus that applies
> > to all init systems because shell is so powerful on unix.
> 
> Stop thinking in sshd. I can write the *whole* daemon in shell, not in
> another script file, but inside /etc/init.d/mystupiddaemon (or
> /etc/rc.whatever); shell is Turing-complete, I can write in it
> anything I can write in C (or in assembler, or machine code). In that
> sense, the init system (which uses shell for launching daemons) can be
> used to determine *how* the daemon behaves (because it uses shell for
> launching daemons).
> 

That's what you meant, how disappointing. Yeah I've knocked up a few
very useful ones myself but call them scripts (Such as grepping logs or
dns servers and feeding real daemons with info).

> You can't do that with systemd; there is a clear and unavoidable

You can't is better is it? Yet you can exec a daemon written in shell
with systemd.

> separation between the starting/stoping/monitoring of daemons, and the
> daemons themselves. 

> Such distinction doesn't really exists in SysV nor
> OpenRC (since they use shell, a Turing-complete language, for

With regular expressions to get the exact pid but

/usr/sbin/sshd -f /etc/ssh/sshd_config = start
/usr/bin/pkill sshd = stop or many other incantations

There are many tools that do this job just fine. If systemd just did
this and was there by default I would consider replacing monit with it.
Like a reliable root filesystem I want a reliable pid 1.

> launching daemons), and therefore you can mixup everything. I agree,
> it doesn't necessarily means that it *will* happen; but even the
> possibility is frigthning for a system administrator in a production
> server. With systemd, that possibility *doesn't exist* (because it
> doesn't uses a Turing-complete language to start/stop/monitor
> daemons).

Doesn't frighten me one bit. I know the startup almost inside out of my
servers, doesn't take long on OpenBSD. On Linux it would take longer but
nowhere near reviewing systemd and knowing C has nothing to do with the
immediate control shell can provide under any init system including
systemd but the Turing complete argument is simply propaganda as well
as all the features to distract from the fundamental flaws in the
design of systemd.

> 
> Like the clear separation between content and presentation in webapps,
> or between the model and the view in the MVC design patter, having a
> clear separation between how you start/stop/monitor your daemon, and
> what the daemon does, is a good thing. If you don't agree with that,
> well, we must agree to disagree.

There is nothing else, you exec or parse a script or daemon just as
systemd does. The only difference is systemd tracking double forked
processes with cgroups and I have already provided a link that refutes
any point to do so. There are corner cases that are easily manageable
and it certainly isn't worth the sacrifice of POSIX compatibility and
so Linux applicability. Linus has said cgroups are a horrible
but necessary evil, which in my opinion means avoid them unless you have
no choice. There is a perfectly good and in my opinion superior
choice, but I love simplicity, it has served me well.

Re: [gentoo-user] Re: Anyone switched to eudev yet? -> what was wron with SysVInit?

[Canek Peláez Valdés]

On Fri, Dec 28, 2012 at 5:23 PM, Kevin Chadwick <ma1l1ists@yahoo.co.uk> wrote:
> On Fri, 28 Dec 2012 13:14:46 -0600
> Canek Peláez Valdés <caneko@gmail.com> wrote:
>
>> On Fri, Dec 28, 2012 at 12:53 PM, Kevin Chadwick
>> <ma1l1ists@yahoo.co.uk> wrote:
>> > On Thu, 27 Dec 2012 17:38:15 -0600
>> > Canek Peláez Valdés <caneko@gmail.com> wrote:
>> >
>> >> In SysV, I can *write* the daemon in the init script.
>> >> In *that* sense, the init system tells the daemon how to do things,
>> >
>> > Please explain, sure there is the environment that tells a daemon
>> > what to do. No shell can tell a c daemon like sshd how to drop
>> > priviledges or use systrace but it could do these things for it in
>> > a more fine grained manner before it tries and fails itself or if
>> > the daemon wishes it to like monit. It's still not telling how but
>> > duplicating or removing the need. That's just a bonus that applies
>> > to all init systems because shell is so powerful on unix.
>>
>> Stop thinking in sshd. I can write the *whole* daemon in shell, not in
>> another script file, but inside /etc/init.d/mystupiddaemon (or
>> /etc/rc.whatever); shell is Turing-complete, I can write in it
>> anything I can write in C (or in assembler, or machine code). In that
>> sense, the init system (which uses shell for launching daemons) can be
>> used to determine *how* the daemon behaves (because it uses shell for
>> launching daemons).
>>
>
> That's what you meant, how disappointing. Yeah I've knocked up a few
> very useful ones myself but call them scripts (Such as grepping logs or
> dns servers and feeding real daemons with info).
>
>> You can't do that with systemd; there is a clear and unavoidable
>
> You can't is better is it? Yet you can exec a daemon written in shell
> with systemd.
>
>> separation between the starting/stoping/monitoring of daemons, and the
>> daemons themselves.
>
>> Such distinction doesn't really exists in SysV nor
>> OpenRC (since they use shell, a Turing-complete language, for
>
> With regular expressions to get the exact pid but
>
> /usr/sbin/sshd -f /etc/ssh/sshd_config = start
> /usr/bin/pkill sshd = stop or many other incantations
>
> There are many tools that do this job just fine. If systemd just did
> this and was there by default I would consider replacing monit with it.
> Like a reliable root filesystem I want a reliable pid 1.
>
>> launching daemons), and therefore you can mixup everything. I agree,
>> it doesn't necessarily means that it *will* happen; but even the
>> possibility is frigthning for a system administrator in a production
>> server. With systemd, that possibility *doesn't exist* (because it
>> doesn't uses a Turing-complete language to start/stop/monitor
>> daemons).
>
> Doesn't frighten me one bit. I know the startup almost inside out of my
> servers, doesn't take long on OpenBSD. On Linux it would take longer but
> nowhere near reviewing systemd and knowing C has nothing to do with the
> immediate control shell can provide under any init system including
> systemd but the Turing complete argument is simply propaganda as well
> as all the features to distract from the fundamental flaws in the
> design of systemd.
>
>>
>> Like the clear separation between content and presentation in webapps,
>> or between the model and the view in the MVC design patter, having a
>> clear separation between how you start/stop/monitor your daemon, and
>> what the daemon does, is a good thing. If you don't agree with that,
>> well, we must agree to disagree.
>
> There is nothing else, you exec or parse a script or daemon just as
> systemd does. The only difference is systemd tracking double forked
> processes with cgroups and I have already provided a link that refutes
> any point to do so. There are corner cases that are easily manageable
> and it certainly isn't worth the sacrifice of POSIX compatibility and
> so Linux applicability. Linus has said cgroups are a horrible
> but necessary evil, which in my opinion means avoid them unless you have
> no choice. There is a perfectly good and in my opinion superior
> choice, but I love simplicity, it has served me well.

I don't doub it. As I said, the only thing to do is to agree to disagree.

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] Re: Anyone switched to eudev yet? -> what was wron with SysVInit?

[Kevin Chadwick]

On Wed, 26 Dec 2012 17:01:17 -0600
Canek Peláez Valdés <caneko@gmail.com> wrote:

> And, what community is being divided? Fedora,OpenSuse, and Arch use
> systemd by default.

From debian and hurd to slackware which will not touch systemd ever and
ubuntu and also embedded with the kernel working on more and more
deeply embedded processors and userland working potentially on less or
more difficulties in porting if lennart's dreams ever come to pass,
which I hope many won't. So way more than half of linux will not use
systemd by default likely ever and it is rather different. Any
unification it does bring like /etc/hostname could be easily achieved
with a little organisation without systemd and would be way more
constructive if it happened because of that single purpose.

I didn't even mention POSIX compliance which is a requirement on many
projects. Fudging POSIX into Linux only would defeat the whole point of
POSIX, though apparently that is a real danger.

Re: [gentoo-user] Re: Anyone switched to eudev yet?

[Bruce Hill]

On Tue, Dec 25, 2012 at 10:56:52AM +0700, Pandu Poluan wrote:
> 
> When you're in charge of over 100 servers as the back-end of a
> multinational company that has a revenue in excess of 10 million USD per
> day, even a temporary outage means the CIO, COO, and CEO breathing down
> your neck.

Who is "in charge of over 100 servers as the back-end of a multinational
company that has a revenue in excess of 10 million USD per day"? And what is
the name of this company?
-- 
Happy Penguin Computers               >')
126 Fenco Drive                       ( \
Tupelo, MS 38801                       ^^
support@happypenguincomputers.com
662-269-2706 662-205-6424
http://happypenguincomputers.com/

Don't top-post: http://en.wikipedia.org/wiki/Top_post#Top-posting

Re: [gentoo-user] Re: Anyone switched to eudev yet?

[Michael Mol]

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

On Dec 25, 2012 8:07 AM, "Bruce Hill" <daddy@happypenguincomputers.com>
wrote:
>
> On Tue, Dec 25, 2012 at 10:56:52AM +0700, Pandu Poluan wrote:
> >
> > When you're in charge of over 100 servers as the back-end of a
> > multinational company that has a revenue in excess of 10 million USD per
> > day, even a temporary outage means the CIO, COO, and CEO breathing down
> > your neck.
>
> Who is "in charge of over 100 servers as the back-end of a multinational
> company that has a revenue in excess of 10 million USD per day"? And what
is
> the name of this company?
> --
> Happy Penguin Computers               >')
> 126 Fenco Drive                       ( \
> Tupelo, MS 38801                       ^^
> support@happypenguincomputers.com
> 662-269-2706 662-205-6424
> http://happypenguincomputers.com/
>
> Don't top-post: http://en.wikipedia.org/wiki/Top_post#Top-posting
>

Um. I work at such a company, the the number distribution is a bit
different, but Pandu's point stands.

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

Re: [gentoo-user] Re: Anyone switched to eudev yet?

[Pandu Poluan]

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

On Dec 25, 2012 8:07 PM, "Bruce Hill" <daddy@happypenguincomputers.com>
wrote:
>
> On Tue, Dec 25, 2012 at 10:56:52AM +0700, Pandu Poluan wrote:
> >
> > When you're in charge of over 100 servers as the back-end of a
> > multinational company that has a revenue in excess of 10 million USD per
> > day, even a temporary outage means the CIO, COO, and CEO breathing down
> > your neck.
>
> Who is "in charge of over 100 servers as the back-end of a multinational
> company that has a revenue in excess of 10 million USD per day"? And what
is
> the name of this company?
>

I do. It's one of the world's largest retailers.

We sold more than 10 million USD of stuff per day.

Of course, the profit margin is very slim, that's why I purposefully use
the word 'revenue' instead of 'income' ;-)

Rgds,
--

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

Re: [gentoo-user] Re: Anyone switched to eudev yet?

[Bruce Hill]

On Tue, Dec 25, 2012 at 10:01:14PM +0700, Pandu Poluan wrote:
> > >
> > > When you're in charge of over 100 servers as the back-end of a
> > > multinational company that has a revenue in excess of 10 million USD per
> > > day, even a temporary outage means the CIO, COO, and CEO breathing down
> > > your neck.
> >
> > Who is "in charge of over 100 servers as the back-end of a multinational
> > company that has a revenue in excess of 10 million USD per day"? And what
> is
> > the name of this company?
> >
> 
> I do. It's one of the world's largest retailers.
> 
> We sold more than 10 million USD of stuff per day.
> 
> Of course, the profit margin is very slim, that's why I purposefully use
> the word 'revenue' instead of 'income' ;-)

So I am to assume your are named Pandu Poluan and you work for a company named
"one of the world's largest retailers". 

Sure...
-- 
Happy Penguin Computers               >')
126 Fenco Drive                       ( \
Tupelo, MS 38801                       ^^
support@happypenguincomputers.com
662-269-2706 662-205-6424
http://happypenguincomputers.com/

Don't top-post: http://en.wikipedia.org/wiki/Top_post#Top-posting

Re: [gentoo-user] Re: Anyone switched to eudev yet?

[Pandu Poluan]

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

On Dec 26, 2012 6:35 AM, "Bruce Hill" <daddy@happypenguincomputers.com>
wrote:
>
> On Tue, Dec 25, 2012 at 10:01:14PM +0700, Pandu Poluan wrote:
> > > >
> > > > When you're in charge of over 100 servers as the back-end of a
> > > > multinational company that has a revenue in excess of 10 million
USD per
> > > > day, even a temporary outage means the CIO, COO, and CEO breathing
down
> > > > your neck.
> > >
> > > Who is "in charge of over 100 servers as the back-end of a
multinational
> > > company that has a revenue in excess of 10 million USD per day"? And
what
> > is
> > > the name of this company?
> > >
> >
> > I do. It's one of the world's largest retailers.
> >
> > We sold more than 10 million USD of stuff per day.
> >
> > Of course, the profit margin is very slim, that's why I purposefully use
> > the word 'revenue' instead of 'income' ;-)
>
> So I am to assume your are named Pandu Poluan and you work for a company
named
> "one of the world's largest retailers".
>
> Sure...
>

Ever heard of LinkedIn.com?

Rgds,
--

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

Re: [gentoo-user] Re: Anyone switched to eudev yet?

[Michael Mol]

On Tue, Dec 25, 2012 at 6:31 PM, Bruce Hill
<daddy@happypenguincomputers.com> wrote:
> On Tue, Dec 25, 2012 at 10:01:14PM +0700, Pandu Poluan wrote:
>> > >
>> > > When you're in charge of over 100 servers as the back-end of a
>> > > multinational company that has a revenue in excess of 10 million USD per
>> > > day, even a temporary outage means the CIO, COO, and CEO breathing down
>> > > your neck.
>> >
>> > Who is "in charge of over 100 servers as the back-end of a multinational
>> > company that has a revenue in excess of 10 million USD per day"? And what
>> is
>> > the name of this company?
>> >
>>
>> I do. It's one of the world's largest retailers.
>>
>> We sold more than 10 million USD of stuff per day.
>>
>> Of course, the profit margin is very slim, that's why I purposefully use
>> the word 'revenue' instead of 'income' ;-)
>
> So I am to assume your are named Pandu Poluan and you work for a company named
> "one of the world's largest retailers".
>
> Sure...

This list has the highest signal to noise ratio of any technical
mailing list I've been on. Seriously, you should take most of the
people on this list at their word.

--
:wq

Re: [gentoo-user] Re: Anyone switched to eudev yet?

[Canek Peláez Valdés]

On Tue, Dec 25, 2012 at 8:16 PM, Michael Mol <mikemol@gmail.com> wrote:
> On Tue, Dec 25, 2012 at 6:31 PM, Bruce Hill
> <daddy@happypenguincomputers.com> wrote:
>> On Tue, Dec 25, 2012 at 10:01:14PM +0700, Pandu Poluan wrote:
>>> > >
>>> > > When you're in charge of over 100 servers as the back-end of a
>>> > > multinational company that has a revenue in excess of 10 million USD per
>>> > > day, even a temporary outage means the CIO, COO, and CEO breathing down
>>> > > your neck.
>>> >
>>> > Who is "in charge of over 100 servers as the back-end of a multinational
>>> > company that has a revenue in excess of 10 million USD per day"? And what
>>> is
>>> > the name of this company?
>>> >
>>>
>>> I do. It's one of the world's largest retailers.
>>>
>>> We sold more than 10 million USD of stuff per day.
>>>
>>> Of course, the profit margin is very slim, that's why I purposefully use
>>> the word 'revenue' instead of 'income' ;-)
>>
>> So I am to assume your are named Pandu Poluan and you work for a company named
>> "one of the world's largest retailers".
>>
>> Sure...
>
> This list has the highest signal to noise ratio of any technical
> mailing list I've been on. Seriously, you should take most of the
> people on this list at their word.

Bruce is the kind of person who tries to insult someone with a
slightly homophobic comment when he rans out of technical arguments:

http://article.gmane.org/gmane.linux.gentoo.user/255258

"Seriously, mate ... are you his boyfriend, on his payroll, related, or what?"

And then months later has the nerve of calling my use of the word
"fuck" (in which I wasn't insulting anyone) as "offensive":

http://article.gmane.org/gmane.linux.gentoo.user/261318

You should just ignore him. The signal to noise ratio gets even higher.

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] Re: Anyone switched to eudev yet?

[Bruce Hill]

On Tue, Dec 25, 2012 at 09:24:55PM -0600, Canek Peláez Valdés wrote:
<snip systemd fanboi text>
> 
> And then months later has the nerve of calling my use of the word
> "fuck" (in which I wasn't insulting anyone) as "offensive":
> 
> http://article.gmane.org/gmane.linux.gentoo.user/261318
> 

http://article.gmane.org/gmane.linux.gentoo.user/261318

> I hope it doesn't offend anyone. That was not (nor is) the intention.
> 
> Regards.
> -- 
> Canek Peláez Valdés

So you weren't being honest when you wrote that in the first place.
-- 
Happy Penguin Computers               >')
126 Fenco Drive                       ( \
Tupelo, MS 38801                       ^^
support@happypenguincomputers.com
662-269-2706 662-205-6424
http://happypenguincomputers.com/

Don't top-post: http://en.wikipedia.org/wiki/Top_post#Top-posting

Re: [gentoo-user] Re: Anyone switched to eudev yet?

[Canek Peláez Valdés]

On Wed, Dec 26, 2012 at 11:13 AM, Bruce Hill
<daddy@happypenguincomputers.com> wrote:
> On Tue, Dec 25, 2012 at 09:24:55PM -0600, Canek Peláez Valdés wrote:
> <snip systemd fanboi text>
>>
>> And then months later has the nerve of calling my use of the word
>> "fuck" (in which I wasn't insulting anyone) as "offensive":
>>
>> http://article.gmane.org/gmane.linux.gentoo.user/261318
>>
>
> http://article.gmane.org/gmane.linux.gentoo.user/261318
>
>> I hope it doesn't offend anyone. That was not (nor is) the intention.
>>
>> Regards.
>> --
>> Canek Peláez Valdés
>
> So you weren't being honest when you wrote that in the first place.

I already told you that I didn't wanted to offend anyone when I said
"fuck", I used the word for emphasis. You keep failing to understand
that, or you keep saying that I was dishonest as a diversion.

And I will keep using the word that way; not to insult *personally*
anyone. My point is that I find highly hypocrite that you took offense
to a word written everyday in a lot of Linux mailing lists, when some
months ago you used an homophobic rhetorical question directed
*personally* against me, in a way that even an eight year old kid
would understand it's offensive. Actually, except for you, in recent
years I have only heard eight year old kids using the question "are
you his boyfriend?" as an attack.

In a technical mailing list, besides.

So, keep trying to hide behind the false accusation that I was
"dishonest" when I say that I didn't wanted to offend anyone; the
undeniable truth is that you actually tried to offend me *personally*,
like an eight year old, when you asked me if I was Lennart's
boyfriend.

In a technical mailing list. Recheck the March thread, if you must; or
all the mailing list archives for what is worth. I try to stick with
only technical arguments; sometimes I'm wrong, sometimes I have a
different opinion than most on the list. But I stick to the technical
arguments. And my "who the fuck cares?" mail was a call to stick to
the technical arguments, BTW, not to some silly thing like who has the
most seniority in the list.

You, on the other hand in March, when you ran out of technical
arguments (if saying "his coding is so questionable that "Lennartware"
has become derogatory slang" can be called a "technical argument"),
you resorted to ask me if I was Lennart's boyfriend.

That's *your* level of discussion. Not mine. You are the one trying to
offend. Not 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] Re: Anyone switched to eudev yet?

[Alan McKinnon]

On Tue, 25 Dec 2012 10:56:52 +0700
Pandu Poluan <pandu@poluan.info> wrote:

> In case you haven't noticed, since Windows 7 (or Vista, forget which)
> Microsoft has even went the distance of splitting between C:
> (analogous to /usr) and 'System Partition' (analogous to /). The boot
> process is actually handled by the 100ish MB 'System Partition'
> before being handed to C:. This will at least give SysAdmins a
> fighting chance of recovering a botched maintenance. (Note: Said
> behavior will only be visible if installing onto a clean hard disk.
> If there are partitions left over from previous Windows installs,
> Win7 will not create a separate 'System Partition') So, if Microsoft
> saw the light, why does Red Hat sunk into darkness instead? 


I zone out of work-related stuff for three days to enjoy presents
instead, and look what happens to the thread :-)

I think I've said all I need to say on this matter, I'm not out to
prove any point really and don't have a dog in this fight. I might not
agree with how Lennart and RH are proceeding with implementation, but I
do agree with the generally stated engineering problem at the core of
the debate.

I'm not sure about Microsoft's motivations in what you describe. My
first reaction is that the Great Circle of IT Life is turning and
MS are trying something new for them. Whether it's applicable to us
here as an illustration remains to be seen - I know very little about
Windows so can't even begin to draw sensible parallels.

 
-- 
Alan McKinnon
alan.mckinnon@gmail.com

RE: [gentoo-user] Re: Anyone switched to eudev yet?

[Mike Edenfield]

> From: Alan McKinnon [mailto:alan.mckinnon@gmail.com]
> Sent: Thursday, December 27, 2012 6:08 PM
> 
> On Tue, 25 Dec 2012 10:56:52 +0700
> Pandu Poluan <pandu@poluan.info> wrote:
> 
> > In case you haven't noticed, since Windows 7 (or Vista, forget which)
> > Microsoft has even went the distance of splitting between C:
> > (analogous to /usr) and 'System Partition' (analogous to /). The boot
> > process is actually handled by the 100ish MB 'System Partition'
> > before being handed to C:. This will at least give SysAdmins a
> > fighting chance of recovering a botched maintenance. (Note: Said
> > behavior will only be visible if installing onto a clean hard disk.
> > If there are partitions left over from previous Windows installs,
> > Win7 will not create a separate 'System Partition') So, if Microsoft
> > saw the light, why does Red Hat sunk into darkness instead?


> I'm not sure about Microsoft's motivations in what you describe. My first
> reaction is that the Great Circle of IT Life is turning and MS are trying
> something new for them. Whether it's applicable to us here as an
illustration
> remains to be seen - I know very little about Windows so can't even begin
to
> draw sensible parallels.

I know little about the history of UNIX before 1993, and the sum of my
experience with Linux is that I have never personally run into any case
where I had a single /+/usr and regretted it, but I *have* encountered
situations where I could not get /usr mounted and ended up merging it with
/. FWIW, YMMV, etc.

I can tell you that Pandu's analogy vis a vis Windows is a bit flawed. What
Windows has done recently is (by default for clean installs) to split the
boot loader and related bootstrap code into a separate partition from the
actual operating system. Claiming that this is analogous to / and /usr is
quite a stretch. It is much more accurate to make it analogous to / and
/boot. The System Partition has no "Windows" files on it, just the
equivalent to grub (and it's also used if you have BitLocker, to decrypt
your boot partition).

Which, to me, means it has absolutely nothing to do with the current
discussion one way or the other :)

--Mike

Re: [Bulk] RE: [gentoo-user] Re: Anyone switched to eudev yet?

[Kevin Chadwick]

On Fri, 4 Jan 2013 18:22:37 -0500
"Mike Edenfield" <kutulu@kutulu.org> wrote:

>  I have never personally run into any case
> where I had a single /+/usr and regretted it, but I *have* encountered
> situations where I could not get /usr mounted and ended up merging it
> with /. FWIW, YMMV, etc.

And why was that, not udev? What is your point, others have avoided
regretting it by having a seperate /usr.

> 
> I can tell you that Pandu's analogy vis a vis Windows is a bit
> flawed. What Windows has done recently is (by default for clean
> installs) to split the boot loader and related bootstrap code into a
> separate partition from the actual operating system. Claiming that
> this is analogous to / and /usr is quite a stretch. It is much more
> accurate to make it analogous to / and /boot. The System Partition
> has no "Windows" files on it, just the equivalent to grub (and it's
> also used if you have BitLocker, to decrypt your boot partition).
> 
> Which, to me, means it has absolutely nothing to do with the current
> discussion one way or the other :)

He did define the fact that he mentioned it because he claimed the
repair tools are stored in a small seperate partition like / or root is
defined in the FHS which means he brought more to the discussion than
you just have. 

In any case there are major benefits to having Windows with program
files on a seperate partition and you shouldn't be stopped from having a
seperate /usr without good reason and which there is not or if there is
good reason in a hidden agenda/future plan it has not been brought to
any discussion, note though that lies and mystery have. Broken
for years indeed, more like tiny issues that few care about and so
haven't been fixed by default.

I re-assert that eudevs mentioning of moving potentially less
stable/audited or even arbitrary code to later in the boot process is
also welcomed by me.

Re: [gentoo-user] Re: Anyone switched to eudev yet?

[Volker Armin Hemmann]

Am Sonntag, 23. Dezember 2012, 19:03:25 schrieb Nuno J. Silva:

> Then I suppose you can surely explain in a nutshell why can't init
> scripts simply do that?

because some people decided, that fsck or that dynamic /dev/ populator depends 
on stuff in /usr? which is the reason for this thread?

How do you mount a filesystem if you don't even have a dev node in the first 
place?

-- 
#163933

Re: [gentoo-user] Re: Anyone switched to eudev yet?

[Volker Armin Hemmann]

with redhat's push to move everything into /usr - why not stop right there and 
move everything back into /?

seperate /home, /var, /dev and /tmp makes sense (not counting proc, sys for 
obvious reasons). But the rest? Why /usr/lib? Just /lib  would be fine. 
Remember how once there was a whole X11 subtree in /usr? /usr/tmp - wtf? Just 
empty /usr and be happy...

I wish I could do that...

-- 
#163933

Re: [gentoo-user] Re: Anyone switched to eudev yet?

[Alan McKinnon]

On Wed, 19 Dec 2012 19:42:01 +0100
Volker Armin Hemmann <volkerarmin@googlemail.com> wrote:

> with redhat's push to move everything into /usr - why not stop right
> there and move everything back into /?
> 
> seperate /home, /var, /dev and /tmp makes sense (not counting proc,
> sys for obvious reasons). But the rest? Why /usr/lib? Just /lib
> would be fine. Remember how once there was a whole X11 subtree
> in /usr? /usr/tmp - wtf? Just empty /usr and be happy...
> 
> I wish I could do that...
> 

Well at least you don't have to put up with /usr/X11 anymore :-)

That took ripping out the entire XFree86 build system and replacing it
with something at least half-way sane that supported --prefix

I'm not too concerned with modern /usr on the whole, the layout is
something I can tolerate.

What *really* gets my goat up is /var/lib. Now what on this earth
could /var/lib/ possibly be useful for???? Surely not libs, those go
in /usr/lib or /lib. If it's variable data somehow related to libs
then someone needs to look up lib in a dictionary.

If it really is lib code, then my question is "how exactly is this
stuff variable to warrant being in /var?"

-- 
Alan McKinnon
alan.mckinnon@gmail.com

Re: [gentoo-user] Re: Anyone switched to eudev yet?

[Kevin Chadwick]

> Surely not libs, those go
> in /usr/lib or /lib. If it's variable data somehow related to libs
> then someone needs to look up lib in a dictionary.
> 

I have to say I was shocked a while back when I found /usr/bin/firefox
linking to a shell script at /usr/lib/firefox/firefox

I'd be interested if anyone can explain that oddity? I see one
other on this system. Perhaps systemd-udev copied firefox?

> If it really is lib code, then my question is "how exactly is this
> stuff variable to warrant being in /var?"

Maybe it's for JIT on steroids. JIT for pid1, what an unnerving thought.

-- 
_______________________________________________________________________

'Write programs that do one thing and do it well. Write programs to work
together. Write programs to handle text streams, because that is a
universal interface'

(Doug McIlroy)
_______________________________________________________________________

Re: [gentoo-user] Re: Anyone switched to eudev yet?

[Mark David Dumlao]

On Thu, Dec 20, 2012 at 2:42 AM, Volker Armin Hemmann
<volkerarmin@googlemail.com> wrote:
> with redhat's push to move everything into /usr - why not stop right there and
> move everything back into /?

I originally thought this way, but they actually reviewed the
technical and historical merits for all the use cases and and found
/usr to be superior. Straight out of the freedesktop wiki:
http://www.freedesktop.org/wiki/Software/systemd/TheCaseForTheUsrMerge

0) If / and /usr are kept separate, programs in /usr can't be updated
independently of programs in /, because the libraries they depend on
might break compatibility. If the binaries and libraries were *all* in
/usr, then the entire system's binaries would always be consistent
regardless of where /usr were sourced from (config files in /etc,
however, would still break).
1) There is historical precedent in Unix for /usr-centric systems,
notably Solaris.
2) If /usr were separated from /, then /usr could be mounted
read-only, with / being mounted "normally". Which makes sense, as /
does have bits that are meant to be read-write.
3) Most software packagers write their binaries to a PREFIX defaulting
to /usr/local, or /usr, as opposed to /. Determining which ones belong
in / or /usr can sometimes be dependent on the distro and/or sysad.
But since more of them default to /usr, if everything were in /usr
it'd be a saner default.

(0) basically says that keeping them separate only works as intended
if the both the sysad and the distro upstream work together for their
shared /usr mount. In many cases, however, sysads have to do a lot of
working around and careful planning to get /usr mounted remotely.
(1), (2), and (3) provide advantages to mounting the binaries and
libraries separately from the / filesystem, which mounting them as
part of / does not provide.

Re: [gentoo-user] Re: Anyone switched to eudev yet?

[Volker Armin Hemmann]

Am Donnerstag, 20. Dezember 2012, 11:45:34 schrieb Mark David Dumlao:
> On Thu, Dec 20, 2012 at 2:42 AM, Volker Armin Hemmann
> 
> <volkerarmin@googlemail.com> wrote:
> > with redhat's push to move everything into /usr - why not stop right there
> > and move everything back into /?
> 
> I originally thought this way, but they actually reviewed the
> technical and historical merits for all the use cases and and found
> /usr to be superior. Straight out of the freedesktop wiki:
> http://www.freedesktop.org/wiki/Software/systemd/TheCaseForTheUsrMerge
> 
> 0) If / and /usr are kept separate, programs in /usr can't be updated
> independently of programs in /, because the libraries they depend on
> might break compatibility. If the binaries and libraries were *all* in
> /usr, then the entire system's binaries would always be consistent
> regardless of where /usr were sourced from (config files in /etc,
> however, would still break).

not a problem at all if everything is in / and /usr doesn't even exist 
anymore.

> 1) There is historical precedent in Unix for /usr-centric systems,
> notably Solaris.

so what? historically we lived in mud huts and used flintstone knives.

> 2) If /usr were separated from /, then /usr could be mounted
> read-only, with / being mounted "normally". Which makes sense, as /
> does have bits that are meant to be read-write.
really? once upon a time I was told mounting / ro and /usr rw was a GOOD THING 
to do. I ignored that the same way I ignore it the other way round. With bind 
mounting and stuff, you can make single directories rw.. so what is the matter?

> 3) Most software packagers write their binaries to a PREFIX defaulting
> to /usr/local, or /usr, as opposed to /. Determining which ones belong
> in / or /usr can sometimes be dependent on the distro and/or sysad.
> But since more of them default to /usr, if everything were in /usr
> it'd be a saner default.

so what? PREFIX can be changed. Set it to /local if you want. Or /var/local. 
Or /my/happy/place/local. 

> 
> (0) basically says that keeping them separate only works as intended
> if the both the sysad and the distro upstream work together for their
> shared /usr mount. In many cases, however, sysads have to do a lot of
> working around and careful planning to get /usr mounted remotely.
> (1), (2), and (3) provide advantages to mounting the binaries and
> libraries separately from the / filesystem, which mounting them as
> part of / does not provide.

no, not really. No.

-- 
#163933

Re: [gentoo-user] Re: Anyone switched to eudev yet?

[Kevin Chadwick]

> really? once upon a time I was told mounting / ro and /usr rw was a GOOD THING 
> to do. I ignored that the same way I ignore it the other way round. With bind 
> mounting and stuff, you can make single directories rw.. so what is the matter?

Ignorance is bliss, so good for you.

Only as root and if RBAC/SELINUX doesn't stop you. It's an extra quite
formidable layer. It is a good thing for many reasons and even a
requirement on some embedded systems. The kernel can also inform you of
any remounts making monitoring far simpler, easier and so powerful and
more efficient.

-- 
_______________________________________________________________________

'Write programs that do one thing and do it well. Write programs to work
together. Write programs to handle text streams, because that is a
universal interface'

(Doug McIlroy)
_______________________________________________________________________

[gentoo-user] Re: Anyone switched to eudev yet?

[Nuno J. Silva]

On 2012-12-20, Volker Armin Hemmann wrote:

> Am Donnerstag, 20. Dezember 2012, 11:45:34 schrieb Mark David Dumlao:
>
>> 3) Most software packagers write their binaries to a PREFIX defaulting
>> to /usr/local, or /usr, as opposed to /. Determining which ones belong
>> in / or /usr can sometimes be dependent on the distro and/or sysad.
>> But since more of them default to /usr, if everything were in /usr
>> it'd be a saner default.
>
> so what? PREFIX can be changed. Set it to /local if you want. Or /var/local. 
> Or /my/happy/place/local. 

Ironically, I think /usr may make for a good /usr/local, as usr could
easily stand for "user-installed software". If that wasn't already the
purpose in some earlier unices...

-- 
Nuno Silva (aka njsg)
http://njsg.sdf-eu.org/

Re: [gentoo-user] Re: Anyone switched to eudev yet?

[Kevin Chadwick]

> On Thu, Dec 20, 2012 at 2:42 AM, Volker Armin Hemmann
> <volkerarmin@googlemail.com> wrote:
> > with redhat's push to move everything into /usr - why not stop right there and
> > move everything back into /?
> 
> I originally thought this way, but they actually reviewed the
> technical and historical merits for all the use cases and and found
> /usr to be superior. Straight out of the freedesktop wiki:
> http://www.freedesktop.org/wiki/Software/systemd/TheCaseForTheUsrMerge
> 
> 0) If / and /usr are kept separate, programs in /usr can't be updated
> independently of programs in /, because the libraries they depend on
> might break compatibility. If the binaries and libraries were *all* in
> /usr, then the entire system's binaries would always be consistent
> regardless of where /usr were sourced from (config files in /etc,
> however, would still break).

Complete rubbish. If something in / needs something it should be in /
if something is in / that isn't critical it shouldn't be there and
won't matter. In all other cases everything exists. If you want some
special feature that adds complexity to your early boot up stage
or single user then that should be an optional package that installs
into /. Similar to ssh enabled grub, it's optional.

> 2) If /usr were separated from /, then /usr could be mounted
> read-only, with / being mounted "normally". Which makes sense, as /
> does have bits that are meant to be read-write.

It certainly does not. There are packages that fix dhcp. I haven't ever
setup a system that needed to do that. Updates get temporary
controlled access.

> 3) Most software packagers write their binaries to a PREFIX defaulting
> to /usr/local, or /usr, as opposed to /. Determining which ones belong
> in / or /usr can sometimes be dependent on the distro and/or sysad.
> But since more of them default to /usr, if everything were in /usr
> it'd be a saner default.
> 

A concensus would be good. A right consensus is more likely to get a
consensus. This has no bearing on the matters at hand.

> (0) basically says that keeping them separate only works as intended
> if the both the sysad and the distro upstream work together for their
> shared /usr mount. In many cases, however, sysads have to do a lot of
> working around and careful planning to get /usr mounted remotely.
> (1), (2), and (3) provide advantages to mounting the binaries and
> libraries separately from the / filesystem, which mounting them as
> part of / does not provide.
> 

Rubbish you can mount the whole of / or /usr. If all you have is /usr
then if anything all you can mount is / but in fact you can mount any
folder anywhere due to unix-like systems being ace.

I wonder what percentage of Linux users believe you should have
one partition for everything due to easier installs. I know the number
will be increasing every day.

-- 
_______________________________________________________________________

'Write programs that do one thing and do it well. Write programs to work
together. Write programs to handle text streams, because that is a
universal interface'

(Doug McIlroy)
_______________________________________________________________________

Re: [gentoo-user] Re: Anyone switched to eudev yet?

[Mark David Dumlao]

On Fri, Dec 21, 2012 at 5:01 AM, Kevin Chadwick <ma1l1ists@yahoo.co.uk> wrote:
>> On Thu, Dec 20, 2012 at 2:42 AM, Volker Armin Hemmann
>> <volkerarmin@googlemail.com> wrote:
>> > with redhat's push to move everything into /usr - why not stop right there and
>> > move everything back into /?
>>
>> I originally thought this way, but they actually reviewed the
>> technical and historical merits for all the use cases and and found
>> /usr to be superior. Straight out of the freedesktop wiki:
>> http://www.freedesktop.org/wiki/Software/systemd/TheCaseForTheUsrMerge
>>
>> 0) If / and /usr are kept separate, programs in /usr can't be updated
>> independently of programs in /, because the libraries they depend on
>> might break compatibility. If the binaries and libraries were *all* in
>> /usr, then the entire system's binaries would always be consistent
>> regardless of where /usr were sourced from (config files in /etc,
>> however, would still break).
>
> Complete rubbish. If something in / needs something it should be in /
> if something is in / that isn't critical it shouldn't be there and
> won't matter. In all other cases everything exists. If you want some
> special feature that adds complexity to your early boot up stage
> or single user then that should be an optional package that installs
> into /. Similar to ssh enabled grub, it's optional.

Key here being "should" be. In theory, that's what should happen. In
practice, either the sysad or the upstream fails to keep it that way.
Here's a quick test:

$ equery belongs /lib
shows a list of packages installing to /lib. On my system, that's a
lot, including ncurses, readline, glibc, consolekit, and god knows
what other "basic" libraries a lot of programs are bound to depend on.
Wouldn't it be fun if my / filesystem got updated to a new, oh I
dunno, glibc, and my /usr filesystem didn't know all about it?

_In theory_, such programs should be independent. But to implement
this theory, either or both the sysad and the distro needs to ensure
that
(1) both / and /usr get duplicate essential libraries
(2) no programs in /usr ever depend on any libraries in /

i.e., _in practice_, the / and /usr split isn't being properly
delivered by distros anyway. And Gentoo is no exception to that. My
/usr/lib's libraries are just symlinks to the libraries in /, so I
can't trust a system where the binaries and libraries in both
filesystems aren't updated _together_.

>
>> 2) If /usr were separated from /, then /usr could be mounted
>> read-only, with / being mounted "normally". Which makes sense, as /
>> does have bits that are meant to be read-write.
>
> It certainly does not. There are packages that fix dhcp. I haven't ever
> setup a system that needed to do that. Updates get temporary
> controlled access.

You're already assuming that all the other read-write folders (/var
and /tmp) are sent off to different filesystems. That is definitely
good practice, but is not a given. And /etc is config files, which is
at least "semantically" a read-write thing - and in practice ALSO
written to by packages like *cough* *cough* networkmanager.

i.e., you're comparing
/ rw
/usr ro

to a series of bind mounts and/or extra filesystems or symlinking
magic. Well yes, those can _still_ be done if /usr contained all the
binaries, though. But combining the binaries and libs into /usr makes
the simpler setup above possible. It isn't possible right now without
some painstaking sysad work.

>
>> 3) Most software packagers write their binaries to a PREFIX defaulting
>> to /usr/local, or /usr, as opposed to /. Determining which ones belong
>> in / or /usr can sometimes be dependent on the distro and/or sysad.
>> But since more of them default to /usr, if everything were in /usr
>> it'd be a saner default.
>>
>
> A concensus would be good. A right consensus is more likely to get a
> consensus. This has no bearing on the matters at hand.

/usr as the default prefix for installed packages is the "consensus"
of the vast majority of packages out there. Why do you think this has
no bearing on their consideration?

--
This email is:    [ ] actionable   [ ] fyi        [x] social
Response needed:  [ ] yes          [x] up to you  [ ] no
Time-sensitive:   [ ] immediate    [ ] soon       [x] none

Re: [gentoo-user] Re: Anyone switched to eudev yet?

[Kevin Chadwick]

On Fri, 21 Dec 2012 05:46:33 +0800
Mark David Dumlao <madumlao@gmail.com> wrote:

> >
> > A concensus would be good. A right consensus is more likely to get a
> > consensus. This has no bearing on the matters at hand.  
> 
> /usr as the default prefix for installed packages is the "consensus"
> of the vast majority of packages out there. Why do you think this has
> no bearing on their consideration?

I'm just pointing out that despite what many seem to state there are
losses and unclear/non forth coming positive reasons or real benefits
to the current apparently to be imposed or your doomed "consensus" of
consolidating data. Once your at multi-user the whole filesystem is one
for all intensive purposes anyway and so much of what you have said is
misleading. It really shouldn't be a difficult problem to fix, it is
just data after all.

 I certainly don't expect linux to solve these management problems,
 quite the opposite in fact but I can hope. I am just glad eudev is
 removing some of the excuse to ignore and quieten complaints that may
 be the real motivation to allow changes later that don't break
 anything or cause too loud screams, being the rules of the kernel
 devs before allowing more radical changes. There are a few indicators
 that lend credence to this possibility.

What is even more encouraging is eudevs keen eye on unneccesary
complexity and increased potential for bugs and unexpected code pull
in at the very core of the early boot process.

Stability and security features or design is never missed until it's too
late and then lots is spent on ineffective band aids.

Re: [gentoo-user] Re: Anyone switched to eudev yet?

[Kevin Chadwick]

On Fri, 21 Dec 2012 00:09:50 +0000
Kevin Chadwick <ma1l1ists@yahoo.co.uk> wrote:

> I certainly don't expect linux to solve these management problems,
>  quite the opposite in fact but I can hope.

I hope mentioning OpenBSD won't put anyone off but taking a leap out of
their book I feel could really benefit linux. This could be a busybox
like project but with general usage fully functional and non space
sensitive goals that creates a core reliable single user environment
with compilation options like busybox for distros to pick and choose
from that is consistent across all distros and self managing via
packagers needing to request for immediate inclusion by default but
obviously being installable though recognising they are crossing the
line drawn in the sand.

Re: [gentoo-user] Re: Anyone switched to eudev yet?

[Mark David Dumlao]

On Fri, Dec 21, 2012 at 8:09 AM, Kevin Chadwick <ma1l1ists@yahoo.co.uk> wrote:
> On Fri, 21 Dec 2012 05:46:33 +0800
> Mark David Dumlao <madumlao@gmail.com> wrote:
>
>> >
>> > A concensus would be good. A right consensus is more likely to get a
>> > consensus. This has no bearing on the matters at hand.
>>
>> /usr as the default prefix for installed packages is the "consensus"
>> of the vast majority of packages out there. Why do you think this has
>> no bearing on their consideration?
>
> I'm just pointing out that despite what many seem to state there are
> losses and unclear/non forth coming positive reasons or real benefits
> to the current apparently to be imposed or your doomed "consensus" of
> consolidating data. Once your at multi-user the whole filesystem is one
> for all intensive purposes anyway and so much of what you have said is
> misleading. It really shouldn't be a difficult problem to fix, it is
> just data after all.

I'm having trouble understanding the whole paragraph - my English
parser must have been broken with my last emerge -uDNtav world. I'd
revdep-rebuild, but my /usr is on nfs and rebuilding the binaries
there would break them for the other shared clients. ;)

--
This email is:    [ ] actionable   [ ] fyi        [x] social
Response needed:  [ ] yes          [x] up to you  [ ] no
Time-sensitive:   [ ] immediate    [ ] soon       [x] none

Re: [gentoo-user] Anyone switched to eudev yet?

[pk]

On 2012-12-14 17:53, Mark Knecht wrote:

> I guess the other question that's lurking here for me is why do you
> have /usr on a separate partition? What's the usage model that drives
> a person to do that? The most I've ever done is move /usr/portage and
> /usr/src to other places. My /usr never has all that much in it beyond
> those two directories, along with maybe /usr/share. Would it not be
> easier for you in the long run to move /usr back to / and not have to
> deal with this question at all?

I don't want easy to supplant flexibility[1]. It really is that simple.
And this is my firm _opinion_ in the matter, I'm not interested in
another flame war, please.

[1] I'm actually planning to get rid of partitions (/, /boot, /usr,
/home, /var, /tmp) alltogether and replacing them with separate,
smaller, ssds.

Best regards

Peter K

Re: [gentoo-user] Anyone switched to eudev yet?

[Bruce Hill]

On Fri, Dec 14, 2012 at 09:48:12AM -0600, Dale wrote:
> 
> Well, it appears that one version is stable:
> 
> root@fireball / # equery list -p eudev
>  * Searching for eudev ...
> [-P-] [  ] sys-fs/eudev-0:0
> [-P-] [ ~] sys-fs/eudev-1_beta1-r1:0
> [-P-] [ -] sys-fs/eudev-9999:0
> root@fireball / #
> 
> The first one is not keyworded or masked. 
> 
> You are right, I don't like the init fix because when I used Mandrake,
> it caused me all sorts of problems.  That and the upgrade process for
> Mandrake is the reason I switched to Gentoo.  If eudev is ready, then so
> am I. 
> 
> Dale

Kindly read /usr/portage/sys-fs/eudev/eudev-0.ebuild especially:

pkg_pretend() {
        einfo "Please note that sys-fs/eudev-0 is actually a mirror of sys-fs/udev-171-r9,"
        einfo "which is necessary to handle the package name change when migrating to eudev"
        einfo "from udev < 180"
-- 
Happy Penguin Computers               >')
126 Fenco Drive                       ( \
Tupelo, MS 38801                       ^^
support@happypenguincomputers.com
662-269-2706 662-205-6424
http://happypenguincomputers.com/

Don't top-post: http://en.wikipedia.org/wiki/Top_post#Top-posting

Re: [gentoo-user] Anyone switched to eudev yet?

[Dale]

Bruce Hill wrote:
> On Fri, Dec 14, 2012 at 09:48:12AM -0600, Dale wrote:
>> Well, it appears that one version is stable:
>>
>> root@fireball / # equery list -p eudev
>>  * Searching for eudev ...
>> [-P-] [  ] sys-fs/eudev-0:0
>> [-P-] [ ~] sys-fs/eudev-1_beta1-r1:0
>> [-P-] [ -] sys-fs/eudev-9999:0
>> root@fireball / #
>>
>> The first one is not keyworded or masked. 
>>
>> You are right, I don't like the init fix because when I used Mandrake,
>> it caused me all sorts of problems.  That and the upgrade process for
>> Mandrake is the reason I switched to Gentoo.  If eudev is ready, then so
>> am I. 
>>
>> Dale
> Kindly read /usr/portage/sys-fs/eudev/eudev-0.ebuild especially:
>
> pkg_pretend() {
>         einfo "Please note that sys-fs/eudev-0 is actually a mirror of sys-fs/udev-171-r9,"
>         einfo "which is necessary to handle the package name change when migrating to eudev"
>         einfo "from udev < 180"


Ahhhh, so it needs a little more time yet then.  I can do that, for a
little while longer.

Dale

:-)  :-) 

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