[gentoo-user] udev blocks systemd etc

[gentoo-user] udev blocks systemd etc

[Stefan G. Weichinger]

Just found that I have a blocking situation ... systemd and udev don't
"like each other" right now ;-)

Tried various maskings ... and found some hints in the Changelog here:

http://gentoo-portage.com/sys-fs/udev/ChangeLog#ptabs

this lead me to this bugreport:

https://bugs.gentoo.org/show_bug.cgi?id=462750

... it is flagged "RESOLVED FIXED" and I am digging for the solution ...
the latest comment (at the very moment
https://bugs.gentoo.org/show_bug.cgi?id=462750#c45) there says "Let's
not discuss blocker problems on this bug report please."

ok ...

So I just stay with sys-fs/udev-198-r5 and sys-apps/systemd-198-r2 for
now and look forward to the things coming :-)

Anyone in here already hit that? Suggestions?

Best regards, Stefan

Re: [gentoo-user] udev blocks systemd etc

[Mike Gilbert]

On Mon, Mar 25, 2013 at 4:59 PM, Stefan G. Weichinger <lists@xunil.at> wrote:
>
> Just found that I have a blocking situation ... systemd and udev don't
> "like each other" right now ;-)
>
> Tried various maskings ... and found some hints in the Changelog here:
>
> http://gentoo-portage.com/sys-fs/udev/ChangeLog#ptabs
>
> this lead me to this bugreport:
>
> https://bugs.gentoo.org/show_bug.cgi?id=462750
>
> ... it is flagged "RESOLVED FIXED" and I am digging for the solution ...
> the latest comment (at the very moment
> https://bugs.gentoo.org/show_bug.cgi?id=462750#c45) there says "Let's
> not discuss blocker problems on this bug report please."
>
> ok ...
>
> So I just stay with sys-fs/udev-198-r5 and sys-apps/systemd-198-r2 for
> now and look forward to the things coming :-)
>
> Anyone in here already hit that? Suggestions?
>
> Best regards, Stefan
>
>

I feel your pain. That bug report got out of control so I wanted to
put a stop to the comments.

I am happy to help you work out your blocker issue here, or in a new bug report.

Re: [gentoo-user] udev blocks systemd etc

[Mike Gilbert]

On Mon, Mar 25, 2013 at 5:18 PM, Mike Gilbert <floppym@gentoo.org> wrote:
> On Mon, Mar 25, 2013 at 4:59 PM, Stefan G. Weichinger <lists@xunil.at> wrote:
>>
>> Just found that I have a blocking situation ... systemd and udev don't
>> "like each other" right now ;-)
>>
>> Tried various maskings ... and found some hints in the Changelog here:
>>
>> http://gentoo-portage.com/sys-fs/udev/ChangeLog#ptabs
>>
>> this lead me to this bugreport:
>>
>> https://bugs.gentoo.org/show_bug.cgi?id=462750
>>
>> ... it is flagged "RESOLVED FIXED" and I am digging for the solution ...
>> the latest comment (at the very moment
>> https://bugs.gentoo.org/show_bug.cgi?id=462750#c45) there says "Let's
>> not discuss blocker problems on this bug report please."
>>
>> ok ...
>>
>> So I just stay with sys-fs/udev-198-r5 and sys-apps/systemd-198-r2 for
>> now and look forward to the things coming :-)
>>
>> Anyone in here already hit that? Suggestions?
>>
>> Best regards, Stefan
>>
>>
>
> I feel your pain. That bug report got out of control so I wanted to
> put a stop to the comments.
>
> I am happy to help you work out your blocker issue here, or in a new bug report.

Oh, some suggestions:

1. Make sure your portage tree is up to date.
2. Make sure your use flags for virtual/udev and sys-apps/systemd are synced up.
3. Run equery d sys-fs/udev to see if you have any packages depending
on it directly.
4. Add sys-fs/udev and sys-fs/eudev to /etc/portage/package.mask to
see if you can get portage to emit a more useful message.

Re: [gentoo-user] udev blocks systemd etc

[Stefan G. Weichinger]

Am 25.03.2013 22:18, schrieb Mike Gilbert:

> I feel your pain. That bug report got out of control so I wanted to 
> put a stop to the comments.
> 
> I am happy to help you work out your blocker issue here, or in a new
> bug report.

I am in no hurry and could simply wait for fresh ebuilds coming in via
portage if there are any changes planned or in the pipeline.

If it is possible to correct things now I'd be happy to do so while I am
online and my system is up and running ;-)

Do you prefer a bug report? For later reference?

Right now I get:

# emerge -1 systemd
Calculating dependencies... done!
[ebuild     U  ] sys-apps/systemd-198-r5 [198-r2] USE="gudev%*
introspection%* -doc%"
[blocks B      ] sys-fs/udev ("sys-fs/udev" is blocking
sys-apps/systemd-198-r5)

# emerge -1 udev
Calculating dependencies... done!
[ebuild     U  ] sys-fs/udev-198-r6 [198-r5]
[blocks B      ] sys-apps/systemd ("sys-apps/systemd" is blocking
sys-fs/udev-198-r6)

# emerge -1 udev systemd
Calculating dependencies... done!
[ebuild     U  ] sys-apps/systemd-198-r5 [198-r2] USE="gudev%*
introspection%* -doc%"
[ebuild     U  ] sys-fs/udev-198-r6 [198-r5]
[blocks B      ] sys-fs/udev ("sys-fs/udev" is blocking
sys-apps/systemd-198-r5)
[blocks B      ] sys-apps/systemd ("sys-apps/systemd" is blocking
sys-fs/udev-198-r6)

Thanks, regards, Stefan

Re: [gentoo-user] udev blocks systemd etc

[Mike Gilbert]

On Mon, Mar 25, 2013 at 5:23 PM, Stefan G. Weichinger <lists@xunil.at> wrote:
> Am 25.03.2013 22:18, schrieb Mike Gilbert:
>
>> I feel your pain. That bug report got out of control so I wanted to
>> put a stop to the comments.
>>
>> I am happy to help you work out your blocker issue here, or in a new
>> bug report.
>
> I am in no hurry and could simply wait for fresh ebuilds coming in via
> portage if there are any changes planned or in the pipeline.
>
> If it is possible to correct things now I'd be happy to do so while I am
> online and my system is up and running ;-)
>
> Do you prefer a bug report? For later reference?
>
> Right now I get:
>
> # emerge -1 systemd
> Calculating dependencies... done!
> [ebuild     U  ] sys-apps/systemd-198-r5 [198-r2] USE="gudev%*
> introspection%* -doc%"
> [blocks B      ] sys-fs/udev ("sys-fs/udev" is blocking
> sys-apps/systemd-198-r5)
>
> # emerge -1 udev
> Calculating dependencies... done!
> [ebuild     U  ] sys-fs/udev-198-r6 [198-r5]
> [blocks B      ] sys-apps/systemd ("sys-apps/systemd" is blocking
> sys-fs/udev-198-r6)
>
> # emerge -1 udev systemd
> Calculating dependencies... done!
> [ebuild     U  ] sys-apps/systemd-198-r5 [198-r2] USE="gudev%*
> introspection%* -doc%"
> [ebuild     U  ] sys-fs/udev-198-r6 [198-r5]
> [blocks B      ] sys-fs/udev ("sys-fs/udev" is blocking
> sys-apps/systemd-198-r5)
> [blocks B      ] sys-apps/systemd ("sys-apps/systemd" is blocking
> sys-fs/udev-198-r6)
>
> Thanks, regards, Stefan
>
>

Do you have sys-fs/udev in your world file by any chance? If so,
please remove it.

Re: [gentoo-user] udev blocks systemd etc

[Stefan G. Weichinger]

Am 25.03.2013 22:26, schrieb Mike Gilbert:

> Do you have sys-fs/udev in your world file by any chance? If so,
> please remove it.

Yes, I had. Removed it, same blockages.

now:

# grep udev /var/lib/portage/world
app-vim/udev-syntax
virtual/udev

...

Ad use-flags:

I have/had

=sys-fs/udev-197-r8 static-libs

Removing this didn't help either.

No special use-flags for systemd in package.use.

profile:

default/linux/amd64/13.0/desktop/gnome

portage tree pulled in again right now ... still:

# emerge -1 udev systemd
Calculating dependencies... done!
[ebuild     U  ] sys-apps/systemd-198-r5 [198-r2] USE="gudev%*
introspection%* -doc%"
[ebuild     U  ] sys-fs/udev-198-r6 [198-r5]
[blocks B      ] sys-fs/udev ("sys-fs/udev" is blocking
sys-apps/systemd-198-r5)
[blocks B      ] sys-apps/systemd ("sys-apps/systemd" is blocking
sys-fs/udev-198-r6)


Thanks for helping, Stefan!

Re: [gentoo-user] udev blocks systemd etc

[Mike Gilbert]

On Mon, Mar 25, 2013 at 5:38 PM, Stefan G. Weichinger <lists@xunil.at> wrote:
> Am 25.03.2013 22:26, schrieb Mike Gilbert:
>
>> Do you have sys-fs/udev in your world file by any chance? If so,
>> please remove it.
>
> Yes, I had. Removed it, same blockages.
>
> now:
>
> # grep udev /var/lib/portage/world
> app-vim/udev-syntax
> virtual/udev
>
> ...
>
> Ad use-flags:
>
> I have/had
>
> =sys-fs/udev-197-r8 static-libs
>
> Removing this didn't help either.
>
> No special use-flags for systemd in package.use.
>
> profile:
>
> default/linux/amd64/13.0/desktop/gnome
>
> portage tree pulled in again right now ... still:
>
> # emerge -1 udev systemd
> Calculating dependencies... done!
> [ebuild     U  ] sys-apps/systemd-198-r5 [198-r2] USE="gudev%*
> introspection%* -doc%"
> [ebuild     U  ] sys-fs/udev-198-r6 [198-r5]
> [blocks B      ] sys-fs/udev ("sys-fs/udev" is blocking
> sys-apps/systemd-198-r5)
> [blocks B      ] sys-apps/systemd ("sys-apps/systemd" is blocking
> sys-fs/udev-198-r6)
>
>
> Thanks for helping, Stefan!
>
>

Try just emerge -v1 systemd. You no longer need sys-fs/udev, and it
should be removed when you upgrade to sys-apps/systemd-r5.

Re: [gentoo-user] udev blocks systemd etc

[Stefan G. Weichinger]

Am 25.03.2013 22:56, schrieb Mike Gilbert:

> Try just emerge -v1 systemd. You no longer need sys-fs/udev, and it
> should be removed when you upgrade to sys-apps/systemd-r5.

Oh, interesting. I understand. Is there any information somewhere on
this (no ranting! just asking for ... as other users might hit the same
issues)?

I get:

#  emerge -v1 systemd

These are the packages that would be merged, in order:

Calculating dependencies... done!
[ebuild     U  ] sys-apps/systemd-198-r5 [198-r2] USE="acl gudev%*
introspection%* kmod pam tcpd -audit -cryptsetup -doc% -efi -gcrypt
-http -lzma -python -qrcode (-selinux) -vanilla -xattr"
PYTHON_SINGLE_TARGET="python2_7" PYTHON_TARGETS="python2_7" 0 kB
[blocks B      ] sys-fs/udev ("sys-fs/udev" is blocking
sys-apps/systemd-198-r5)

I assume I should remove sys-fs/udev now and then "emerge -v1 systemd" ?

And rely on my UPS while I do that .... ;-)

Thanks once more, Stefan

Re: [gentoo-user] udev blocks systemd etc

[Neil Bothwick]

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

On Mon, 25 Mar 2013 22:38:53 +0100, Stefan G. Weichinger wrote:

> > Do you have sys-fs/udev in your world file by any chance? If so,
> > please remove it.  
> 
> Yes, I had. Removed it, same blockages.
> 
> now:
> 
> # grep udev /var/lib/portage/world
> app-vim/udev-syntax
> virtual/udev

You still have virtual/udev in world, which pulls in sys-fs/udev.


-- 
Neil Bothwick

Top Oxymorons Number 39: Almost exactly

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

Re: [gentoo-user] udev blocks systemd etc

[Stefan G. Weichinger]

Am 25.03.2013 23:30, schrieb Neil Bothwick:
> On Mon, 25 Mar 2013 22:38:53 +0100, Stefan G. Weichinger wrote:
> 
>>> Do you have sys-fs/udev in your world file by any chance? If
>>> so, please remove it.
>> 
>> Yes, I had. Removed it, same blockages.
>> 
>> now:
>> 
>> # grep udev /var/lib/portage/world app-vim/udev-syntax 
>> virtual/udev
> 
> You still have virtual/udev in world, which pulls in sys-fs/udev.

correct. I alway feel kinda guilty ...

Didn't put it there by myself afai remember ;-)

Removed it now, thanks for the hint.

# emerge -avuDN @world

still ends with:

[blocks B      ] sys-fs/udev ("sys-fs/udev" is blocking
sys-apps/systemd-198-r5)
[blocks B      ] sys-apps/systemd ("sys-apps/systemd" is blocking
sys-fs/udev-198-r6)

---

# eix -I udev
[I] app-vim/udev-syntax
     Available versions:  20051016-r1
     Installed versions:  20051016-r1(14:17:52 14.02.2013)
     Homepage:
http://www.vim.org/scripts/script.php?script_id=1381
     Description:         vim plugin: syntax highlighting for udev
rules files

[I] sys-fs/udev-init-scripts
     Available versions:  23^t (~)24^t (~)25^t **9999^t
     Installed versions:  25^t(20:39:04 24.03.2013)
     Homepage:            http://www.gentoo.org
     Description:         udev startup scripts for openrc

[I] virtual/udev
     Available versions:  [M]171 197-r2 {gudev hwdb introspection
keymap +kmod selinux static-libs}
     Installed versions:  197-r2(21:50:13 25.03.2013)(gudev hwdb
introspection keymap kmod -selinux -static-libs)
     Description:         Virtual to select between sys-fs/udev and
sys-fs/eudev

# eix -I systemd
[I] sys-apps/systemd
     Available versions:  (~)197-r1 (~)198-r1 (~)198-r5 [M]**9999
[M]**9999[2] {acl audit cryptsetup doc efi gcrypt gudev http
introspection +kmod lzma pam python qrcode selinux tcpd vanilla xattr
PYTHON_SINGLE_TARGET="python2_7" PYTHON_TARGETS="python2_7"}
     Installed versions:  198-r5(23:27:53 25.03.2013)(acl gudev
introspection kmod pam tcpd -audit -cryptsetup -doc -efi -gcrypt -http
-lzma -python -qrcode -selinux -vanilla -xattr
PYTHON_SINGLE_TARGET="python2_7" PYTHON_TARGETS="python2_7")
     Homepage:            http://www.freedesktop.org/wiki/Software/systemd
     Description:         System and service manager for Linux

[I] sys-apps/systemd-ui
     Available versions:  (~)1 (~)2 **9999
     Installed versions:  2(21:38:11 25.03.2013)
     Homepage:            http://www.freedesktop.org/wiki/Software/systemd
     Description:         System and service manager for Linux

[I] sys-apps/baselayout-systemd [1]
     Available versions:  (~)2 {+guess}
     Installed versions:  2(13:15:29 14.02.2013)(guess)
     Homepage:
http://0pointer.de/blog/projects/the-new-configuration-files.html
     Description:         Standard system configuration files

---

Won't reboot now ;-)

S

Re: [gentoo-user] udev blocks systemd etc

[Stefan G. Weichinger]

I assume I have to remove udev-init-scripts now?

Re: [gentoo-user] udev blocks systemd etc

[Stefan G. Weichinger]

Am 25.03.2013 23:39, schrieb Stefan G. Weichinger:
> 
> I assume I have to remove udev-init-scripts now?

rebooted

..

afai see the system doesn't detect/ start up the raid-devices anymore.
This (in my case) leads to no detected PVs for the lvm2-stuff ...

Not so funny.

Re: [gentoo-user] udev blocks systemd etc

[Stefan G. Weichinger]

Am 26.03.2013 00:10, schrieb Stefan G. Weichinger:
> Am 25.03.2013 23:39, schrieb Stefan G. Weichinger:
>>
>> I assume I have to remove udev-init-scripts now?
> 
> rebooted
> 
> ..
> 
> afai see the system doesn't detect/ start up the raid-devices anymore.
> This (in my case) leads to no detected PVs for the lvm2-stuff ...
> 
> Not so funny.

did "mdadm --assemble" to start my raid-devices

even then the systemd-jobs related to the lvm-devices fail.

Right now this system is broken in my terms:

no GUI coming up ...

S

Re: [gentoo-user] udev blocks systemd etc

[Mike Gilbert]

On Mon, Mar 25, 2013 at 7:47 PM, Stefan G. Weichinger <lists@xunil.at> wrote:
> Am 26.03.2013 00:10, schrieb Stefan G. Weichinger:
>> Am 25.03.2013 23:39, schrieb Stefan G. Weichinger:
>>>
>>> I assume I have to remove udev-init-scripts now?
>>
>> rebooted
>>
>> ..
>>
>> afai see the system doesn't detect/ start up the raid-devices anymore.
>> This (in my case) leads to no detected PVs for the lvm2-stuff ...
>>
>> Not so funny.
>
> did "mdadm --assemble" to start my raid-devices
>
> even then the systemd-jobs related to the lvm-devices fail.
>
> Right now this system is broken in my terms:
>
> no GUI coming up ...
>
> S
>
>

Please run "emerge -1 /lib/udev" to reinstall any packages which have
installed udev rules in /lib/udev/rules.d.

Re: [gentoo-user] udev blocks systemd etc

[Stefan G. Weichinger]

Am 26.03.2013 01:20, schrieb Mike Gilbert:

> Please run "emerge -1 /lib/udev" to reinstall any packages which have
> installed udev rules in /lib/udev/rules.d.

29 pkgs there (virtual/udev in there again) .... late here ...

more tomorrow ...

thanks, regards, Stefan

Re: [gentoo-user] udev blocks systemd etc

[Stefan G. Weichinger]

Am 26.03.2013 01:36, schrieb Stefan G. Weichinger:
> Am 26.03.2013 01:20, schrieb Mike Gilbert:
> 
>> Please run "emerge -1 /lib/udev" to reinstall any packages which have
>> installed udev rules in /lib/udev/rules.d.
> 
> 29 pkgs there (virtual/udev in there again) .... late here ...
> 
> more tomorrow ...

Was able to rebuild virtual/udev ... but the system is rather unusable
right now ... jobs related to lvm-devices time out and emerging packages
is somehow super-slow and stalling.

I will try to temporarily remove these entries from fstab and recompile
stuff from kind of a single-user-mode.

Re: [gentoo-user] udev blocks systemd etc

[Stefan G. Weichinger]

Am 26.03.2013 10:38, schrieb Stefan G. Weichinger:
> Am 26.03.2013 01:36, schrieb Stefan G. Weichinger:
>> Am 26.03.2013 01:20, schrieb Mike Gilbert:
>>
>>> Please run "emerge -1 /lib/udev" to reinstall any packages which have
>>> installed udev rules in /lib/udev/rules.d.
>>
>> 29 pkgs there (virtual/udev in there again) .... late here ...
>>
>> more tomorrow ...
> 
> Was able to rebuild virtual/udev ... but the system is rather unusable
> right now ... jobs related to lvm-devices time out and emerging packages
> is somehow super-slow and stalling.
> 
> I will try to temporarily remove these entries from fstab and recompile
> stuff from kind of a single-user-mode.

Yep, that helped. As soon as lvm2 was rebuilt things got easier.

Rebuilt the other 27 pkgs and right now I am booted up again and it
looks ok so far.
Cleaning up now and applying the learned stuff to my thinkpad now ;-)

Thanks, Stefan

Re: [gentoo-user] udev blocks systemd etc

[Stefan G. Weichinger]

Am 26.03.2013 11:08, schrieb Stefan G. Weichinger:
> Am 26.03.2013 10:38, schrieb Stefan G. Weichinger:
>> Am 26.03.2013 01:36, schrieb Stefan G. Weichinger:
>>> Am 26.03.2013 01:20, schrieb Mike Gilbert:
>>>
>>>> Please run "emerge -1 /lib/udev" to reinstall any packages which have
>>>> installed udev rules in /lib/udev/rules.d.

apcupsd-3.14.10-r1 still installs its rules into  /lib/udev/rules.d ...
the path is hard-coded in the ebuild (line 99).

-

Doesn't that removal of udev and "systemd brings all" mean that it is
even harder to switch back to openrc now?

Stefan

Re: [gentoo-user] udev blocks systemd etc

[Mike Gilbert]

On Tue, Mar 26, 2013 at 6:30 AM, Stefan G. Weichinger <lists@xunil.at> wrote:
> Am 26.03.2013 11:08, schrieb Stefan G. Weichinger:
>> Am 26.03.2013 10:38, schrieb Stefan G. Weichinger:
>>> Am 26.03.2013 01:36, schrieb Stefan G. Weichinger:
>>>> Am 26.03.2013 01:20, schrieb Mike Gilbert:
>>>>
>>>>> Please run "emerge -1 /lib/udev" to reinstall any packages which have
>>>>> installed udev rules in /lib/udev/rules.d.
>
> apcupsd-3.14.10-r1 still installs its rules into  /lib/udev/rules.d ...
> the path is hard-coded in the ebuild (line 99).
>

Thanks, I have just committed a fix for that.

>
> Doesn't that removal of udev and "systemd brings all" mean that it is
> even harder to switch back to openrc now?
>

Yes, it does. I think we are going to let udev and systemd settle down
a bit before trying to address that issue.

Also, we have made a change that should prevent this udev breakage for
anyone else upgrading systemd. I'm sorry that you were the guinea pig
on this.

https://bugs.gentoo.org/show_bug.cgi?id=463302

Re: [gentoo-user] udev blocks systemd etc

[Stefan G. Weichinger]

Am 26.03.2013 15:57, schrieb Mike Gilbert:
>> apcupsd-3.14.10-r1 still installs its rules into  /lib/udev/rules.d
>> ... the path is hard-coded in the ebuild (line 99).
> 
> Thanks, I have just committed a fix for that.

Great, my next question would have been if I should file a bug ... not
needed anymore.

>> Doesn't that removal of udev and "systemd brings all" mean that it
>> is even harder to switch back to openrc now?
> 
> Yes, it does. I think we are going to let udev and systemd settle
> down a bit before trying to address that issue.

Good choice, yes.

> Also, we have made a change that should prevent this udev breakage
> for anyone else upgrading systemd. I'm sorry that you were the guinea
> pig on this.
> 
> https://bugs.gentoo.org/show_bug.cgi?id=463302

... and as so often I thought it might have been my mistake ;-)

Good to have it sorted out now.

Stefan

Re: [gentoo-user] udev blocks systemd etc

[fantasticfears]

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

sys-kernel/dracut
​ still requires udev, please update it.

​And what to do with udev USE flag?​
​


On Tue, Mar 26, 2013 at 11:30 PM, Stefan G. Weichinger <lists@xunil.at>wrote:

> Am 26.03.2013 15:57, schrieb Mike Gilbert:
> >> apcupsd-3.14.10-r1 still installs its rules into  /lib/udev/rules.d
> >> ... the path is hard-coded in the ebuild (line 99).
> >
> > Thanks, I have just committed a fix for that.
>
> Great, my next question would have been if I should file a bug ... not
> needed anymore.
>
> >> Doesn't that removal of udev and "systemd brings all" mean that it
> >> is even harder to switch back to openrc now?
> >
> > Yes, it does. I think we are going to let udev and systemd settle
> > down a bit before trying to address that issue.
>
> Good choice, yes.
>
> > Also, we have made a change that should prevent this udev breakage
> > for anyone else upgrading systemd. I'm sorry that you were the guinea
> > pig on this.
> >
> > https://bugs.gentoo.org/show_bug.cgi?id=463302
>
> ... and as so often I thought it might have been my mistake ;-)
>
> Good to have it sorted out now.
>
> Stefan
>
>


-- 
Regards,

Erick Frank / 管啸
fantasticfears

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

Re: [gentoo-user] udev blocks systemd etc

[Tanstaafl]

Ok...

So, what is this all about?

Does all of this mean that udev is now going *completely* away, 
*totally* replaced by systemd?

If so, has there been any kind of formal announcement about this 
*anywhere*??


On 2013-03-27 6:32 AM, fantasticfears <fantasticfears@gmail.com> wrote:
> sys-kernel/dracut
> ​ still requires udev, please update it.
>
> ​And what to do with udev USE flag?​
> ​
>
>
> On Tue, Mar 26, 2013 at 11:30 PM, Stefan G. Weichinger <lists@xunil.at
> <mailto:lists@xunil.at>> wrote:
>
>     Am 26.03.2013 15:57, schrieb Mike Gilbert:
>      >> apcupsd-3.14.10-r1 still installs its rules into  /lib/udev/rules.d
>      >> ... the path is hard-coded in the ebuild (line 99).
>      >
>      > Thanks, I have just committed a fix for that.
>
>     Great, my next question would have been if I should file a bug ... not
>     needed anymore.
>
>      >> Doesn't that removal of udev and "systemd brings all" mean that it
>      >> is even harder to switch back to openrc now?
>      >
>      > Yes, it does. I think we are going to let udev and systemd settle
>      > down a bit before trying to address that issue.
>
>     Good choice, yes.
>
>      > Also, we have made a change that should prevent this udev breakage
>      > for anyone else upgrading systemd. I'm sorry that you were the guinea
>      > pig on this.
>      >
>      > https://bugs.gentoo.org/show_bug.cgi?id=463302
>
>     ... and as so often I thought it might have been my mistake ;-)
>
>     Good to have it sorted out now.
>
>     Stefan
>
>
>
>
> --
> Regards,
>
> Erick Frank / 管啸
> fantasticfears

Re: [gentoo-user] udev blocks systemd etc

[Michael Mol]

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

On 03/27/2013 10:25 AM, Tanstaafl wrote:
> Ok...
> 
> So, what is this all about?
> 
> Does all of this mean that udev is now going *completely* away,
> *totally* replaced by systemd?
> 
> If so, has there been any kind of formal announcement about this
> *anywhere*??

Hold your horses.

The devs will work something out; systemd is not replacing the udev
package for all users. For the moment, it's just replacing the udev
package for users using systemd.

The problem at the moment is a spat between the systemd maintainer and
the udev maintainer. They don't see eye to eye about which packages
should be providing which files (and where), and there's also a serious
miscommunication (and misinterpretation of historical communication)
issue between the two of them at the moment. They're trying to get it
worked out (via attempting cooperation or via arbitration, whatever is
necessary), and things will settle down.

In the mean time, if I read the context right, this issue should only
affect people who are using systemd. This shouldn't be affecting people
who aren't using systemd.




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

Re: [gentoo-user] udev blocks systemd etc

[Michael Mol]

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

On 03/27/2013 10:33 AM, Michael Mol wrote:
> On 03/27/2013 10:25 AM, Tanstaafl wrote:
>> Ok...
>>
>> So, what is this all about?
>>
>> Does all of this mean that udev is now going *completely* away,
>> *totally* replaced by systemd?
>>
>> If so, has there been any kind of formal announcement about this
>> *anywhere*??
> 
> Hold your horses.
> 
> The devs will work something out; systemd is not replacing the udev
> package for all users. For the moment, it's just replacing the udev
> package for users using systemd.
> 
> The problem at the moment is a spat between the systemd maintainer and
> the udev maintainer. They don't see eye to eye about which packages
> should be providing which files (and where), and there's also a serious
> miscommunication (and misinterpretation of historical communication)
> issue between the two of them at the moment. They're trying to get it
> worked out (via attempting cooperation or via arbitration, whatever is
> necessary), and things will settle down.
> 
> In the mean time, if I read the context right, this issue should only
> affect people who are using systemd. This shouldn't be affecting people
> who aren't using systemd.

(incidentally, to anyone who's following the issue, please correct me if
I'm wrong...)



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

Re: [gentoo-user] udev blocks systemd etc

[Stefan G. Weichinger]

Am 27.03.2013 15:34, schrieb Michael Mol:
> On 03/27/2013 10:33 AM, Michael Mol wrote:
>> On 03/27/2013 10:25 AM, Tanstaafl wrote:
>>> Ok...
>>> 
>>> So, what is this all about?
>>> 
>>> Does all of this mean that udev is now going *completely*
>>> away, *totally* replaced by systemd?
>>> 
>>> If so, has there been any kind of formal announcement about
>>> this *anywhere*??
>> 
>> Hold your horses.
>> 
>> The devs will work something out; systemd is not replacing the
>> udev package for all users. For the moment, it's just replacing
>> the udev package for users using systemd.
>> 
>> The problem at the moment is a spat between the systemd
>> maintainer and the udev maintainer. They don't see eye to eye
>> about which packages should be providing which files (and where),
>> and there's also a serious miscommunication (and
>> misinterpretation of historical communication) issue between the
>> two of them at the moment. They're trying to get it worked out
>> (via attempting cooperation or via arbitration, whatever is 
>> necessary), and things will settle down.
>> 
>> In the mean time, if I read the context right, this issue should
>> only affect people who are using systemd. This shouldn't be
>> affecting people who aren't using systemd.
> 
> (incidentally, to anyone who's following the issue, please correct
> me if I'm wrong...)

I understand the situation as you do ...

Re: [gentoo-user] udev blocks systemd etc

[Jake Margason]

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

I ran away from Arch last year to get away from all this systemd stuff. I
hope that you guys will continue to support openrc for as long as possible.
One question though. why does everyone seem to be migrating towards
systemd? How is it superior? is openrc just a dead project is that why?


On Wed, Mar 27, 2013 at 10:21 AM, Stefan G. Weichinger <lists@xunil.at>wrote:

> Am 27.03.2013 15:34, schrieb Michael Mol:
> > On 03/27/2013 10:33 AM, Michael Mol wrote:
> >> On 03/27/2013 10:25 AM, Tanstaafl wrote:
> >>> Ok...
> >>>
> >>> So, what is this all about?
> >>>
> >>> Does all of this mean that udev is now going *completely*
> >>> away, *totally* replaced by systemd?
> >>>
> >>> If so, has there been any kind of formal announcement about
> >>> this *anywhere*??
> >>
> >> Hold your horses.
> >>
> >> The devs will work something out; systemd is not replacing the
> >> udev package for all users. For the moment, it's just replacing
> >> the udev package for users using systemd.
> >>
> >> The problem at the moment is a spat between the systemd
> >> maintainer and the udev maintainer. They don't see eye to eye
> >> about which packages should be providing which files (and where),
> >> and there's also a serious miscommunication (and
> >> misinterpretation of historical communication) issue between the
> >> two of them at the moment. They're trying to get it worked out
> >> (via attempting cooperation or via arbitration, whatever is
> >> necessary), and things will settle down.
> >>
> >> In the mean time, if I read the context right, this issue should
> >> only affect people who are using systemd. This shouldn't be
> >> affecting people who aren't using systemd.
> >
> > (incidentally, to anyone who's following the issue, please correct
> > me if I'm wrong...)
>
> I understand the situation as you do ...
>
>


-- 
Jacob Margason
(760) 694-1093

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

Re: [gentoo-user] udev blocks systemd etc

[Canek Peláez Valdés]

On Wed, Mar 27, 2013 at 9:38 AM, Jake Margason <jmargason758@gmail.com> wrote:
> I ran away from Arch last year to get away from all this systemd stuff. I
> hope that you guys will continue to support openrc for as long as possible.

Don't do top posting, please.

> One question though. why does everyone seem to be migrating towards systemd?
> How is it superior? is openrc just a dead project is that why?

That's three questions ;)

1. "why does everyone seem to be migrating towards systemd?"

Not everyone is migrating towards systemd (yet), but the trend is
certainly that more and more distros switch to it or at least offer it
as a first class alternative to whatever other init system they use.
As for why, I think it's for two reasons: a) it works, b) upstream
udev merged with systemd, and most distros just follow upstream.

2. "How is it superior?"

Well, that's the pickle. If you are like me, then systemd it's
superior to OpenRC basically in every single way. If you are one of
the people that thinks that something called "the UNIX way" actually
exists, or that "Linux/Gentoo is about choice", or that we should care
about our *BSD cousins keeping up with us, then systemd is far
inferior.

From a technical point of view (the quality of the code and the time
it takes to fix bugs), I believe everyone (even Lennart's most fervent
detractors) will agree that systemd is a superb piece of software. The
problem is the philosophy behind it; if you agree with said
philosophy, systemd is great. Otherwise, is a new fangled beast which
goes against everything that UNIX stands for (whatever that means), "a
solution for a problem no one has", and "fixing something that wasn't
broken".

3. "is openrc just a dead project is that why?"

Is not dead; it has new releases and stuff. Just not many features are
implemented to it, and it has some pretty awkward bugs, some of them
years old, like not being able to start services in parallel.

It's obviously better that SysV. From my point of view, that's not enough.

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] udev blocks systemd etc

[Michael Mol]

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

On 03/27/2013 01:08 PM, Canek Peláez Valdés wrote:
> On Wed, Mar 27, 2013 at 9:38 AM, Jake Margason <jmargason758@gmail.com> wrote:
>> I ran away from Arch last year to get away from all this systemd stuff. I
>> hope that you guys will continue to support openrc for as long as possible.
> 
> Don't do top posting, please.
> 
>> One question though. why does everyone seem to be migrating towards systemd?
>> How is it superior? is openrc just a dead project is that why?
> 
> That's three questions ;)
> 
> 1. "why does everyone seem to be migrating towards systemd?"
> 
> Not everyone is migrating towards systemd (yet), but the trend is
> certainly that more and more distros switch to it or at least offer it
> as a first class alternative to whatever other init system they use.
> As for why, I think it's for two reasons: a) it works, b) upstream
> udev merged with systemd, and most distros just follow upstream.
> 
> 2. "How is it superior?"
> 
> Well, that's the pickle. If you are like me, then systemd it's
> superior to OpenRC basically in every single way. If you are one of
> the people that thinks that something called "the UNIX way" actually
> exists, or that "Linux/Gentoo is about choice", or that we should care
> about our *BSD cousins keeping up with us, then systemd is far
> inferior.
> 
> From a technical point of view (the quality of the code and the time
> it takes to fix bugs), I believe everyone (even Lennart's most fervent
> detractors) will agree that systemd is a superb piece of software. The
> problem is the philosophy behind it; if you agree with said
> philosophy, systemd is great. Otherwise, is a new fangled beast which
> goes against everything that UNIX stands for (whatever that means), "a
> solution for a problem no one has", and "fixing something that wasn't
> broken".
> 
> 3. "is openrc just a dead project is that why?"
> 
> Is not dead; it has new releases and stuff. Just not many features are
> implemented to it, and it has some pretty awkward bugs, some of them
> years old, like not being able to start services in parallel.
> 
> It's obviously better that SysV. From my point of view, that's not enough.
> 
> Hope it helps.
> 
> Regards.
> 

A nice, reasonably even-handed writeup. :)




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

Re: [gentoo-user] udev blocks systemd etc

[Kevin Chadwick]

> From a technical point of view (the quality of the code and the time
> it takes to fix bugs), I believe everyone (even Lennart's most fervent
> detractors) will agree that systemd is a superb piece of software. The
> problem is the philosophy behind it; if you agree with said
> philosophy, systemd is great. Otherwise, is a new fangled beast which
> goes against everything that UNIX stands for (whatever that means), "a
> solution for a problem no one has", and "fixing something that wasn't
> broken".
> 

I won't start this up again, there is lots of info out there. LWN
and this lists archives maybe reasonable for some for and against
arguments. This post is as bad as Lennarts myth busting post which
avoided all the real issues and skirted around the ones he did mention.

The real drive behind systemd is enterprise cloud type computing for
Red Hat. The rest is snake oil and much of the features already exist
without systemd. With more snake oil of promises of faster boot up on a
portion of the code which is already fast and gains you maybe two
seconds.

> 3. "is openrc just a dead project is that why?"
> 

Not even close, systemd is one of the least used init systems. The
question you should ask yourself is why would anyone talk about the fact
they are using OpenRC. Having said that I do hate all the symlinking
rubbish many linux (not OpenRC) uses but would bear it over systemds
technical flaws.

So there you have it complete contradictions which mean you should make
up your own mind, even if it is easier for the more advanced arguments
against it to be overlooked.

> Is not dead; it has new releases and stuff. Just not many features are
> implemented to it, and it has some pretty awkward bugs, some of them
> years old, like not being able to start services in parallel.
> 

There is arguably more weight to the argument of an init system that
does parallel starting being a bug.

What do you gain, speed? and complexity, what do you lose reliability
and predictability.

If you cause disk churn it *may* even be slower too such as windows
tools that stage autostarts.

Do one thing and do it well and you are more likely to make it into
every Unix-like OS for good not so obvious reasons.

I hope this doesn't start into another discusssion just know that there
are many arguments badly represented by Canek to research if you want
your answer.

-- 
_______________________________________________________________________

'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: udev blocks systemd etc

[Grant Edwards]

On 2013-03-27, Kevin Chadwick <ma1l1ists@yahoo.co.uk> wrote:

> The real drive behind systemd is enterprise cloud type computing for
> Red Hat. The rest is snake oil and much of the features already exist
> without systemd. With more snake oil of promises of faster boot up on a
> portion of the code which is already fast and gains you maybe two
> seconds.

I'm not trying to fan the flames: I'm genuinely confused...

I just don't get the whole "parallel startup for faster boot thing".
Most of my machines just don't boot up often enough for a few seconds
or even tens of seconds to matter at all.

It seems to me that starting things in parallel would be inherintly
much more difficult, bug-prone, and hard to troubleshoot.

Even on my laptop, which does get booted more than once every month or
two, openrc is plenty fast enough.

Are there people who reboot their machines every few minutes and
therefore need to shave a few seconds off their boot time?

I can see how boot time matters for small embedded systems (routers,
firewalls, etc.) that need to be up and running quickly after a power
outage, but they're probably even less likely to be running systemd
than desktops or servers.

-- 
Grant Edwards               grant.b.edwards        Yow! Where's th' DAFFY
                                  at               DUCK EXHIBIT??
                              gmail.com            

Re: [gentoo-user] Re: udev blocks systemd etc

[Michael Mol]

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

On 03/27/2013 04:00 PM, Grant Edwards wrote:
> On 2013-03-27, Kevin Chadwick <ma1l1ists@yahoo.co.uk> wrote:
> 
>> The real drive behind systemd is enterprise cloud type computing for
>> Red Hat. The rest is snake oil and much of the features already exist
>> without systemd. With more snake oil of promises of faster boot up on a
>> portion of the code which is already fast and gains you maybe two
>> seconds.
> 
> I'm not trying to fan the flames: I'm genuinely confused...
> 
> I just don't get the whole "parallel startup for faster boot thing".
> Most of my machines just don't boot up often enough for a few seconds
> or even tens of seconds to matter at all.

With cloud-based computing, you don't have a bunch of servers running,
waiting to received requests.

Instead, you have is a bunch of idle hardware, waiting to have pre-built
system images spun up on them on-demand.

The faster those pre-built images can spin up, the faster they can serve
requests. The faster they can serve requests, the fewer mostly-idle
images need to be already running for immediate needs. Traffic on a web
service usually spins up gradually. In the middle of the night, it's
low, but it increases during certain hours and decreases during others.
(Even with things like social media, there's a gradual buildup of
resource demands, as it takes URLs a while to take fire and spread.)
Ultimately, if you can have just enough images running to manage
immediate demand plus a small burst margin, you can save on costs. If
demand eats into your burst, you spin up more instances until you're
below your burst margin again. If demand falls, you kill off the extra
instances.

The quicker the spin-up process, the more efficient the on-demand system
becomes, and the better the resource utilization (and value to the
person paying for the cloud services).

(Though, really, I'd think that the best way to handle this kind of load
would be a hibernate system with a sparse image for RAM, and driver
tweaks to allow hardware to swap out from underneath in the event of
hardware changes while asleep. Or handle things like MAC address
rewriting in the VM hypervisor.)

> 
> It seems to me that starting things in parallel would be inherintly
> much more difficult, bug-prone, and hard to troubleshoot.

Indeed.

> 
> Even on my laptop, which does get booted more than once every month or
> two, openrc is plenty fast enough.

The case for systemd is twofold:

1) Boot-to-desktop session management by one tool. (The same thing that
launches your cron daemon is what launches your favorite apps when you
log in.)
2) Reduce the amount of CPU and RAM consumed when you're talking about
booting tens of thousands of instances simultaneously across your entire
infrastructure, or when your server instance might be spun up and down
six times over the course of a single day.

> 
> Are there people who reboot their machines every few minutes and
> therefore need to shave a few seconds off their boot time?

On-demand server contexts, yes.

> 
> I can see how boot time matters for small embedded systems (routers,
> firewalls, etc.) that need to be up and running quickly after a power
> outage, but they're probably even less likely to be running systemd
> than desktops or servers.

Servers in cloud environments have one normal state: "Off". But when
they need to be "On", they need to get there hella quickly, or the
client is going to lose out on ad revenue when he starts getting a few
tens of thousands of visits per minute.



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

Re: [gentoo-user] Re: udev blocks systemd etc

[Tanstaafl]

On 2013-03-27 4:41 PM, Michael Mol <mikemol@gmail.com> wrote:
> On 03/27/2013 04:00 PM, Grant Edwards wrote:
>> On 2013-03-27, Kevin Chadwick<ma1l1ists@yahoo.co.uk>  wrote:
>>> The real drive behind systemd is enterprise cloud type computing for
>>> Red Hat. The rest is snake oil and much of the features already exist
>>> without systemd. With more snake oil of promises of faster boot up on a
>>> portion of the code which is already fast and gains you maybe two
>>> seconds.

>> I'm not trying to fan the flames: I'm genuinely confused...
>>
>> I just don't get the whole "parallel startup for faster boot thing".
>> Most of my machines just don't boot up often enough for a few seconds
>> or even tens of seconds to matter at all.

> With cloud-based computing, you don't have a bunch of servers running,
> waiting to received requests.
>
> Instead, you have is a bunch of idle hardware, waiting to have pre-built
> system images spun up on them on-demand.
>
> The faster those pre-built images can spin up, the faster they can serve
> requests.

Ok, well, that actually makes perfect sense (and answers my question 
about why Redhat is interested in and pushing it).

Re: [gentoo-user] Re: udev blocks systemd etc

[Alan McKinnon]

On 27/03/2013 22:41, Michael Mol wrote:
> The case for systemd is twofold:

...

> 2) Reduce the amount of CPU and RAM consumed when you're talking about
> booting tens of thousands of instances simultaneously across your entire
> infrastructure, or when your server instance might be spun up and down
> six times over the course of a single day.

I seems to me that this is rather a niche quite-specialized case (albeit
a rather large instance of a niche case). In which case it would be
better implemented as Redhat MagicSauce for their cloud environment
where it would be exactly tuned to that case's need.



-- 
Alan McKinnon
alan.mckinnon@gmail.com

Re: [gentoo-user] Re: udev blocks systemd etc

[Michael Mol]

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

On 03/27/2013 05:51 PM, Alan McKinnon wrote:
> On 27/03/2013 22:41, Michael Mol wrote:
>> The case for systemd is twofold:
> 
> ...
> 
>> 2) Reduce the amount of CPU and RAM consumed when you're talking about
>> booting tens of thousands of instances simultaneously across your entire
>> infrastructure, or when your server instance might be spun up and down
>> six times over the course of a single day.
> 
> I seems to me that this is rather a niche quite-specialized case (albeit
> a rather large instance of a niche case). In which case it would be
> better implemented as Redhat MagicSauce for their cloud environment
> where it would be exactly tuned to that case's need.

But it's a great deal cheaper to convince volunteers and package
maintainers to put in the time to build the necessary service files of
their own accord. Add in the complexity of parallel boot, and you can
induce upstream to fix their own race-driven bugs rather than have to
pay for that development directly.


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

Re: [gentoo-user] Re: udev blocks systemd etc

[Alan McKinnon]

On 28/03/2013 04:56, Michael Mol wrote:
> On 03/27/2013 05:51 PM, Alan McKinnon wrote:
>> On 27/03/2013 22:41, Michael Mol wrote:
>>> The case for systemd is twofold:
>>
>> ...
>>
>>> 2) Reduce the amount of CPU and RAM consumed when you're talking about
>>> booting tens of thousands of instances simultaneously across your entire
>>> infrastructure, or when your server instance might be spun up and down
>>> six times over the course of a single day.
>>
>> I seems to me that this is rather a niche quite-specialized case (albeit
>> a rather large instance of a niche case). In which case it would be
>> better implemented as Redhat MagicSauce for their cloud environment
>> where it would be exactly tuned to that case's need.
> 
> But it's a great deal cheaper to convince volunteers and package
> maintainers to put in the time to build the necessary service files of
> their own accord. Add in the complexity of parallel boot, and you can
> induce upstream to fix their own race-driven bugs rather than have to
> pay for that development directly.
> 

I don't follow the thought stream here Michael.
It feels like there's a word or a sentence missing (it's just not
hanging together)



-- 
Alan McKinnon
alan.mckinnon@gmail.com

Re: [gentoo-user] Re: udev blocks systemd etc

[J. Roeleveld]

On Thu, March 28, 2013 07:59, Alan McKinnon wrote:
> On 28/03/2013 04:56, Michael Mol wrote:
>> On 03/27/2013 05:51 PM, Alan McKinnon wrote:
>>> On 27/03/2013 22:41, Michael Mol wrote:
>>>> The case for systemd is twofold:
>>>
>>> ...
>>>
>>>> 2) Reduce the amount of CPU and RAM consumed when you're talking about
>>>> booting tens of thousands of instances simultaneously across your
>>>> entire
>>>> infrastructure, or when your server instance might be spun up and down
>>>> six times over the course of a single day.
>>>
>>> I seems to me that this is rather a niche quite-specialized case
>>> (albeit
>>> a rather large instance of a niche case). In which case it would be
>>> better implemented as Redhat MagicSauce for their cloud environment
>>> where it would be exactly tuned to that case's need.
>>
>> But it's a great deal cheaper to convince volunteers and package
>> maintainers to put in the time to build the necessary service files of
>> their own accord. Add in the complexity of parallel boot, and you can
>> induce upstream to fix their own race-driven bugs rather than have to
>> pay for that development directly.
>>
>
> I don't follow the thought stream here Michael.
> It feels like there's a word or a sentence missing (it's just not
> hanging together)

Alan, I think what Michael is trying to say is that by getting other
distros to package systemd, other distros will help RedHat to find and fix
the problems systemd is causing.

--
Joost

Re: [gentoo-user] Re: udev blocks systemd etc

[Michael Mol]

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

On 03/28/2013 03:51 AM, J. Roeleveld wrote:
> On Thu, March 28, 2013 07:59, Alan McKinnon wrote:
>> On 28/03/2013 04:56, Michael Mol wrote:
>>> On 03/27/2013 05:51 PM, Alan McKinnon wrote:
>>>> On 27/03/2013 22:41, Michael Mol wrote:
>>>>> The case for systemd is twofold:
>>>>
>>>> ...
>>>>
>>>>> 2) Reduce the amount of CPU and RAM consumed when you're talking about
>>>>> booting tens of thousands of instances simultaneously across your
>>>>> entire
>>>>> infrastructure, or when your server instance might be spun up and down
>>>>> six times over the course of a single day.
>>>>
>>>> I seems to me that this is rather a niche quite-specialized case
>>>> (albeit
>>>> a rather large instance of a niche case). In which case it would be
>>>> better implemented as Redhat MagicSauce for their cloud environment
>>>> where it would be exactly tuned to that case's need.
>>>
>>> But it's a great deal cheaper to convince volunteers and package
>>> maintainers to put in the time to build the necessary service files of
>>> their own accord. Add in the complexity of parallel boot, and you can
>>> induce upstream to fix their own race-driven bugs rather than have to
>>> pay for that development directly.
>>>
>>
>> I don't follow the thought stream here Michael.
>> It feels like there's a word or a sentence missing (it's just not
>> hanging together)
> 
> Alan, I think what Michael is trying to say is that by getting other
> distros to package systemd, other distros will help RedHat to find and fix
> the problems systemd is causing.

Exactly this.



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

Re: [gentoo-user] Re: udev blocks systemd etc

[Alan McKinnon]

On 28/03/2013 15:16, Michael Mol wrote:
> On 03/28/2013 03:51 AM, J. Roeleveld wrote:
>> On Thu, March 28, 2013 07:59, Alan McKinnon wrote:
>>> On 28/03/2013 04:56, Michael Mol wrote:
>>>> On 03/27/2013 05:51 PM, Alan McKinnon wrote:
>>>>> On 27/03/2013 22:41, Michael Mol wrote:
>>>>>> The case for systemd is twofold:
>>>>>
>>>>> ...
>>>>>
>>>>>> 2) Reduce the amount of CPU and RAM consumed when you're talking about
>>>>>> booting tens of thousands of instances simultaneously across your
>>>>>> entire
>>>>>> infrastructure, or when your server instance might be spun up and down
>>>>>> six times over the course of a single day.
>>>>>
>>>>> I seems to me that this is rather a niche quite-specialized case
>>>>> (albeit
>>>>> a rather large instance of a niche case). In which case it would be
>>>>> better implemented as Redhat MagicSauce for their cloud environment
>>>>> where it would be exactly tuned to that case's need.
>>>>
>>>> But it's a great deal cheaper to convince volunteers and package
>>>> maintainers to put in the time to build the necessary service files of
>>>> their own accord. Add in the complexity of parallel boot, and you can
>>>> induce upstream to fix their own race-driven bugs rather than have to
>>>> pay for that development directly.
>>>>
>>>
>>> I don't follow the thought stream here Michael.
>>> It feels like there's a word or a sentence missing (it's just not
>>> hanging together)
>>
>> Alan, I think what Michael is trying to say is that by getting other
>> distros to package systemd, other distros will help RedHat to find and fix
>> the problems systemd is causing.
> 
> Exactly this.
> 
> 

Ah, a definition of "getting" that I was heretofore unfamiliar with.

Obviously "getting" doesn't mean what I think it means, it means
"forcing without giving the other party much of a choice in the matter
by ripping out essential infrastructure and replacing it with something
tuned to RedHat, and only RedHat's, needs."

Ok, I got it now. Thanks for clearing that up.

-- 
Alan McKinnon
alan.mckinnon@gmail.com

Re: [gentoo-user] Re: udev blocks systemd etc

[Michael Mol]

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

On 03/28/2013 10:35 AM, Alan McKinnon wrote:
> On 28/03/2013 15:16, Michael Mol wrote:
>> On 03/28/2013 03:51 AM, J. Roeleveld wrote:
>>> On Thu, March 28, 2013 07:59, Alan McKinnon wrote:
>>>> On 28/03/2013 04:56, Michael Mol wrote:
>>>>> On 03/27/2013 05:51 PM, Alan McKinnon wrote:
>>>>>> On 27/03/2013 22:41, Michael Mol wrote:
>>>>>>> The case for systemd is twofold:
>>>>>>
>>>>>> ...
>>>>>>
>>>>>>> 2) Reduce the amount of CPU and RAM consumed when you're talking about
>>>>>>> booting tens of thousands of instances simultaneously across your
>>>>>>> entire
>>>>>>> infrastructure, or when your server instance might be spun up and down
>>>>>>> six times over the course of a single day.
>>>>>>
>>>>>> I seems to me that this is rather a niche quite-specialized case
>>>>>> (albeit
>>>>>> a rather large instance of a niche case). In which case it would be
>>>>>> better implemented as Redhat MagicSauce for their cloud environment
>>>>>> where it would be exactly tuned to that case's need.
>>>>>
>>>>> But it's a great deal cheaper to convince volunteers and package
>>>>> maintainers to put in the time to build the necessary service files of
>>>>> their own accord. Add in the complexity of parallel boot, and you can
>>>>> induce upstream to fix their own race-driven bugs rather than have to
>>>>> pay for that development directly.
>>>>>
>>>>
>>>> I don't follow the thought stream here Michael.
>>>> It feels like there's a word or a sentence missing (it's just not
>>>> hanging together)
>>>
>>> Alan, I think what Michael is trying to say is that by getting other
>>> distros to package systemd, other distros will help RedHat to find and fix
>>> the problems systemd is causing.
>>
>> Exactly this.
>>
>>
> 
> Ah, a definition of "getting" that I was heretofore unfamiliar with.
> 
> Obviously "getting" doesn't mean what I think it means, it means
> "forcing without giving the other party much of a choice in the matter
> by ripping out essential infrastructure and replacing it with something
> tuned to RedHat, and only RedHat's, needs."
> 
> Ok, I got it now. Thanks for clearing that up.

In theory, it's supposed to be an additional option when choosing an
init system, rather than forcing a wholesale switchover across the Linux
infrastructure.

If it weren't for the upstream udev behavior, that's probably what it
would still be. (Perhaps eudev will be a resolution to this, perhaps
not. Only time will tell.)

Apart from the issues around udev, I don't expect this to get in the way
a whole lot. Converting systemd unit files to classic init scripts
shouldn't prove to be difficult to largely automate.

Getting systemic race issues fixed is probably going to be a good thing.
Getting daemon writers to architect their software in ways that survive
parallel booting will probably be a good thing. Code quality outside of
systemd *should* ultimately improve as a result of all this...but it's a
valid question whether or not the things being fixed would be worth the
effort if the new parallel boot agents hadn't begun taking hold.

On the other hand, it's equally valid to note that, with SMP
architectures becoming pervasive, it was only a matter of time before
traditionally-serial systems would be pressured into taking advantage of
them.

This too, shall pass.




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

[gentoo-user] Re: udev blocks systemd etc

[Grant Edwards]

On 2013-03-27, Michael Mol <mikemol@gmail.com> wrote:

> The case for systemd is twofold:
>
> 1) Boot-to-desktop session management by one tool.

Ah, the old "universal generic tool" approach.  I've seen a lot of
money and time poured into black-hole projects with names containing
words like universal and generic, so I don't really like the sound of
that.  [Is that the right response for somebody who started using V7
Unix on a PDP11?]

>    (The same thing that launches your cron daemon is what launches
>    your favorite apps when you log in.)

The only app that runs when I log in is bash.  Then I usually start
XFCE from the command line -- but not always.

> 2) Reduce the amount of CPU and RAM consumed when you're talking
>    about booting tens of thousands of instances simultaneously across
>    your entire infrastructure, or when your server instance might be
>    spun up and down six times over the course of a single day.

It sounds like systemd really isn't intended for the likes of me.

>> Are there people who reboot their machines every few minutes and
>> therefore need to shave a few seconds off their boot time?
>
> On-demand server contexts, yes.

Thanks for the explanation -- I never would have guessed that's how
the whole cloud thing worked.

-- 
Grant

Re: [gentoo-user] Re: udev blocks systemd etc

[Michael Mol]

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

On 03/28/2013 12:28 AM, Grant Edwards wrote:
> On 2013-03-27, Michael Mol <mikemol@gmail.com> wrote:
> 
>> The case for systemd is twofold:
>>
>> 1) Boot-to-desktop session management by one tool.
> 
> Ah, the old "universal generic tool" approach.  I've seen a lot of
> money and time poured into black-hole projects with names containing
> words like universal and generic, so I don't really like the sound of
> that.  [Is that the right response for somebody who started using V7
> Unix on a PDP11?]

It has theoretical advantages. Avoiding an impedance mismatch makes
turn-key systems that much easier. (I expect that to apply to embedded
systems like phones and consumer network gear, but we'll see how it
plays out. RAM is cheap, and getting cheaper...I just configured a
Netgear router with 128MB of RAM...)


> 
>>    (The same thing that launches your cron daemon is what launches
>>    your favorite apps when you log in.)
> 
> The only app that runs when I log in is bash.  Then I usually start
> XFCE from the command line -- but not always.
> 
>> 2) Reduce the amount of CPU and RAM consumed when you're talking
>>    about booting tens of thousands of instances simultaneously across
>>    your entire infrastructure, or when your server instance might be
>>    spun up and down six times over the course of a single day.
> 
> It sounds like systemd really isn't intended for the likes of me.

Indeed.

> 
>>> Are there people who reboot their machines every few minutes and
>>> therefore need to shave a few seconds off their boot time?
>>
>> On-demand server contexts, yes.
> 
> Thanks for the explanation -- I never would have guessed that's how
> the whole cloud thing worked.

"Private clouds" work the same way. As business penetration of cloud
services grow, I expect we'll see backlash as major outages occur.
Imagine if cyberbunker had attacked Google rather than Spamhaus earlier
this week. The scale of that attack reached the upper limit of what the
Internet's infrastructure is capable of carrying...nobody, not even
companies with dozens of data centers in a distributed architecture, can
ultimately bear that. Organizations which have grown comfortable in an
age of reliable Internet access and cheap cloud services are going to
discover they still have operational needs that must go on even without
network access.




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

Re: [gentoo-user] udev blocks systemd etc

[Tanstaafl]

On 2013-03-27 3:43 PM, Kevin Chadwick <ma1l1ists@yahoo.co.uk> wrote:
> The real drive behind systemd is enterprise cloud type computing for
> Red Hat.

I'd be interested in hearing more on this...

Link(s) to online articles is fine...

Re: [gentoo-user] udev blocks systemd etc

[Tanstaafl]

On 2013-03-27 10:33 AM, Michael Mol <mikemol@gmail.com> wrote:
> On 03/27/2013 10:25 AM, Tanstaafl wrote:
>> Ok...
>>
>> So, what is this all about?
>>
>> Does all of this mean that udev is now going*completely*  away,
>> *totally*  replaced by systemd?
>>
>> If so, has there been any kind of formal announcement about this
>> *anywhere*??

> Hold your horses.
>
> The devs will work something out; systemd is not replacing the udev
> package for all users. For the moment, it's just replacing the udev
> package for users using systemd.

Thanks Michael, but that didn't *exactly* answer my question.

I thought that newer versions of udev are now *dependent* on systemd? 
Doesn't that mean that anyone who is using udev is also 'using' systemd?

So, again, my question is, is udev going to be going *completely* away 
in the future, being *totally replaced* by systemd? Or maybe better said 
asked as, will udev soon just be subsumed by systemd?

Even if this is a year or more away, I'd like to know...

[gentoo-user] Re: udev blocks systemd etc

[»Q«]

On Wed, 27 Mar 2013 11:46:01 -0400
Tanstaafl <tanstaafl@libertytrek.org> wrote:

> On 2013-03-27 10:33 AM, Michael Mol <mikemol@gmail.com> wrote:
> > On 03/27/2013 10:25 AM, Tanstaafl wrote:
> >> Ok...
> >>
> >> So, what is this all about?
> >>
> >> Does all of this mean that udev is now going*completely*  away,
> >> *totally*  replaced by systemd?
> >>
> >> If so, has there been any kind of formal announcement about this
> >> *anywhere*??
> 
> > Hold your horses.
> >
> > The devs will work something out; systemd is not replacing the udev
> > package for all users. For the moment, it's just replacing the udev
> > package for users using systemd.
> 
> Thanks Michael, but that didn't *exactly* answer my question.
> 
> I thought that newer versions of udev are now *dependent* on systemd? 
> Doesn't that mean that anyone who is using udev is also 'using'
> systemd?

udev is distributed as part of systemd, but it does not depend on
systemd.  It's possible to extract the udev part of the systemd tarball
and build only udev, which is how people are using udev with openrc
instead of systemd.

> So, again, my question is, is udev going to be going *completely*
> away in the future, being *totally replaced* by systemd? Or maybe
> better said asked as, will udev soon just be subsumed by systemd?

I don't think that's clear to anyone yet.  It's only guaranteed that
udev will serve the needs of systemd users, and opinions and hopes vary
about whether it will serve the needs of non-systemd users in the
future.

Eventually, as I understand it, GNOME and KDE will require systemd
because they want full control of they system.  For people not using
GNOME or KDE, other init systems will still be possible, with either
udev or a udev alternative.  I have no idea how far away "eventually"
will be.

> Even if this is a year or more away, I'd like to know...

Me too.

# emerge crystal-ball
Calculating dependencies... done!

emerge: there are no ebuilds to satisfy "crystal-ball".

Re: [gentoo-user] Re: udev blocks systemd etc

[Yohan Pereira]

On 27/03/13 at 11:27am, »Q« wrote:
> Eventually, as I understand it, GNOME and KDE will require systemd
> because they want full control of they system.  For people not using
> GNOME or KDE, other init systems will still be possible, with either
> udev or a udev alternative.  I have no idea how far away "eventually"
> will be.

GNOME maybe/probably, but regarding KDE what makes you say this ? 
I don't recall reading anything about this (this one comes to mind but
its got nothing to do with systemd [1]. The author explains in the
comments why he chose not to use systemd). KDE always prides itself in 
being cross platform forcing systemd would be terribly detrimental. 

[1] http://dantti.wordpress.com/2013/02/27/1-2-3-plasma/

-- 

- Yohan Pereira

The difference between a Miracle and a Fact is exactly the difference
between a mermaid and a seal.
                -- Mark Twain

[gentoo-user] Re: udev blocks systemd etc

[»Q«]

On Wed, 27 Mar 2013 22:33:05 +0530
Yohan Pereira <yohan.pereira@gmail.com> wrote:

> On 27/03/13 at 11:27am, »Q« wrote:
> > Eventually, as I understand it, GNOME and KDE will require systemd
> > because they want full control of they system.  For people not using
> > GNOME or KDE, other init systems will still be possible, with either
> > udev or a udev alternative.  I have no idea how far away
> > "eventually" will be.
> 
> GNOME maybe/probably, but regarding KDE what makes you say this ? 
> I don't recall reading anything about this (this one comes to mind but
> its got nothing to do with systemd [1]. The author explains in the
> comments why he chose not to use systemd). KDE always prides itself
> in being cross platform forcing systemd would be terribly
> detrimental. 

I don't know where I read that both were headed that way, but I'm glad
to see indications that I'm wrong about KDE.

I'm sorry if I posted FUD.
 
> [1] http://dantti.wordpress.com/2013/02/27/1-2-3-plasma/
> 

Re: [Bulk] Re: [gentoo-user] Re: udev blocks systemd etc

[Kevin Chadwick]

> On 27/03/13 at 11:27am, »Q« wrote:
> > Eventually, as I understand it, GNOME and KDE will require systemd
> > because they want full control of they system.  For people not using
> > GNOME or KDE, other init systems will still be possible, with either
> > udev or a udev alternative.  I have no idea how far away "eventually"
> > will be.  
> 
> GNOME maybe/probably, but regarding KDE what makes you say this ? 
> I don't recall reading anything about this (this one comes to mind but
> its got nothing to do with systemd [1]. The author explains in the
> comments why he chose not to use systemd). KDE always prides itself in 
> being cross platform forcing systemd would be terribly detrimental. 
> 
> [1] http://dantti.wordpress.com/2013/02/27/1-2-3-plasma/

Actually it came up not too long ago that a commit was making Gnome
Linux only and I believe it was decided not to be the way to Go.

-- 
_______________________________________________________________________

'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)
_______________________________________________________________________