Gentoo 'lining up behind systemd'?

Message

Fitzcarraldo · Post by **Fitzcarraldo** » Tue Sep 25, 2012 8:47 pm

http://www.itworld.com/data-centerserve ... er-booting

It looks like the crowd lining up behind systemd is growing fast. With Fedora, OpenSUSE, Mandiva, Arch, Debian, Gentoo, Frugalware -- Did I forget anyone? And RedHat will probably be joining with the release of RedHat7. Ubuntu seems to be sticking with Upstart.

Well, is Gentoo 'lining up behind systemd'? I thought the official policy in Gentoo is to stick with OpenRC?

Post by **asturm** » Tue Sep 25, 2012 8:58 pm

systemd is available in portage - that's probably enough to get into that list.

Post by **NeddySeagoon** » Tue Sep 25, 2012 9:03 pm

Fitzcarraldo,

Gentoo is about choice. If you like systemd, its in the tree, use it. If you don't like it, don't.

Scimmia22 · Post by **Scimmia22** » Tue Sep 25, 2012 9:25 pm

They're making a comparison on systemd vs upstart. In that regard, systemd is available for use in the Gentoo repositories, upstart is not.

I'm one that believes the init systems we use do need to be brought up to date eventually. The scripts systems most Linux systems used prior to round up updates the article talks about are extremely out of date, not having any substantial updates in something like 30 years. OpenRC is different, it's been updated with some important advances, especially in terms of service dependencies/start order. In many respects, it's more of a competitor to upstart and systemd than it is to the old SysVinit scripts. I'm assuming it was ignored in this article because it lacks the parallelization of service startup that this article featured.

PaulBredbury · Post by **PaulBredbury** » Tue Sep 25, 2012 9:28 pm

Probably a copy-no-thought-and-paste from wikipedia

Fitzcarraldo · Post by **Fitzcarraldo** » Tue Sep 25, 2012 10:41 pm

NeddySeagoon wrote:Fitzcarraldo,

Gentoo is about choice. If you like systemd, its in the tree, use it. If you don't like it, don't.

I would hope your three axioms are obvious to the Gentoo user (I assume you were using 'you' as an impersonal pronoun). My question related to official policy or goals by this distribution's developers (the Gentoo Council), given the statement in the article I referenced. My understanding from reading various posts in the past in these Forums is that the official init system in Gentoo is OpenRC (The Gentoo Handbook, updated September 11, 2012, for example, refers only to OpenRC and not systemd) and will stay that way. The aforementioned IT World article appears to indicate that could change in the near to midterm future. Hence my question.

ulenrich · Post by **ulenrich** » Wed Sep 26, 2012 12:32 am

Why hate the good thing?
Because the creator once offered a bad?

Ant P. · Post by **Ant P.** » Wed Sep 26, 2012 2:46 am

Yeah, we have systemd. We also have upstart (sys-apps/upstart::dev-zero in layman) and einit (sys-apps/einit::jyujin), we had initng while that was alive, and if you don't like openrc it just runs on top of the standard sysv init that Debian also uses.

Gentoo isn't getting in line for systemd, it's the other way around.

Post by **NeddySeagoon** » Wed Sep 26, 2012 9:06 pm

Fitzcarraldo,

Gentoo, as represented by the council or the Foundation (or both) does not have an policy on such things.

Is up to the individual developers what they work on, when they work on it as everyone is a volunteer.
While OpenRC works and is maintained and is compatible with everything there is no reason to change.

When there is a problem and a decision needs to be made, if the devs cannot agree, the council will make a decision.
That is how gentoo works.

OpenRC was a development from baselayout1. Once of the baselayout devs decided to rewrite a large part of baselayout in C.
As a result, baselayout2 needed OpenRC.

If systemd becomes a prerequsite for GNOME, its time to drop GNOME. The philosophy throughout all of *NIX is the programs do one thing and do it well.
It smacks of poor systems design to have your choice of GUI dictate your init manager as the two things are so far apart in the system that is GNU/Linux.

gerard27 · Post by **gerard27** » Thu Sep 27, 2012 12:37 pm

I'd like to know if Linus has made any comments on systemd.
He has/had ties with RH.
Gerard.

pidsley · Post by **pidsley** » Thu Sep 27, 2012 12:51 pm

gerard82 wrote:I'd like to know if Linus has made any comments on systemd.

This was all I found in a quick Ixquick search:

LinuxFR : Do you think systemd is a huge improvement in comparison to SysV init ? Is it a game changing technology ?
Linus Torvalds : I also will take a somewhat wait-and-see approach, it's not widely enough used yet. I do think bootup performance is important, and anything that helps that, and helps make it more flexible is a good thing. Would I call it "game changing"? Probably not.

http://www.preguntaslinux.org/printthread.php?tid=6512

ulenrich · Post by **ulenrich** » Thu Sep 27, 2012 1:26 pm

@pidsley, this interview is one year old. And kernel intergration (Linus work) will not be game changed, but system integration will:

- admin blaming feature (journald is highest priority for commercial vendors)
- virtualisation features
- boot process isn't any more the distribution special
- no boundaries for system services reaching out direction AI user experience

Systemd is one use flag and a kernel cmdline (grub entry) away. Try it using current~unstable!
Then look at "man systemd.exec systemd.unit systemd.service" and you'll see what is game changing anyway ...

mv · Post by mv » Thu Sep 27, 2012 2:00 pm

ulenrich wrote:Then look at "man systemd.exec systemd.unit systemd.service" and you'll see what is game changing anyway ...

...and especially look at "top" and "mem" to see what the nonsense costs you permanently on running time and memory. Not to speak about the time you will need to debug due to the undeterministic boot process and broken log concept.

pidsley · Post by **pidsley** » Thu Sep 27, 2012 2:04 pm

ulenrich wrote:@pidsley, this interview is one year old.

That's why I said "this was all I found with a quick search"

and I never said I agreed with him... I use systemd on my Arch installs and I like it very much.

ulenrich · Post by **ulenrich** » Thu Sep 27, 2012 3:12 pm

mv wrote:...and especially look at "top" and "mem" to see what the nonsense costs you permanently on running time and memory. Not to speak about the time you will need to debug due to the undeterministic boot process and broken log concept.

In contrary to
- openrc parallel boot is undeterministic and therefore unsupported
- systemd undeterministic parallelism is supported

Since systemd-189 I don't have any issues regarding performace, this systemd-192:

Code: Select all

 
etc # top -b -n 1 |grep systemd
    1 root       1   0 45416 3900 2128 S   0.0  0.1   0:00.21 systemd
   66 root       1   0 33592 2060 1204 S   0.0  0.1   0:00.07 systemd-udevd
   68 root       1   0 61532 3760 3468 S   0.0  0.1   0:00.05 systemd-journal
  408 root       1   0 30328 1696 1372 S   0.0  0.0   0:00.03 systemd-logind
  419 root       1   0  8492  684  576 S   0.0  0.0   0:00.00 systemd-tty-ask

steveL · Post by **steveL** » Thu Sep 27, 2012 3:55 pm

ulenrich wrote:Why hate the good thing?
Because the creator once offered a bad?

No, it's because everything he comes out with wants to take over our machines, with a mess of so-called "integration" requiring changes across the board. Til he finally realises what everyone was on about, and drops the project for his next shiny adventure, leaving everyone else to pick up the pieces.

Sorry, but track record is relevant, especially if you're making wholesale changes across user-space without so much as asking, rather whining at everyone about what you've given them "for free" when we never asked for it, don't like it, and don't want to adopt his corporate "vision". Why does his ego require every distro take on his work?

As ever, distrust of claims for the One True Way is appropriate.

ulenrich · Post by **ulenrich** » Thu Sep 27, 2012 4:13 pm

Bad charakter?
H.R. - reiser4 - a btrfs predecessor was geniously architectured ...

steveL · Post by **steveL** » Thu Sep 27, 2012 5:02 pm

ulenrich wrote:Bad charakter?

I wasn't saying anything about his character: just about the software he's done, and what its impacts have been.

For instance, I still don't see what benefit consolekit delivers to the standard desktop machine. Much was made of its support for multiseat, especially at the beginning, to the extent that it seemed to the main benefit it offered. How useful is that across the board though? Yet it caused an awful lot of problems for everyone, and is now deprecated. Similarly with policykit: AIUI network admins were happier with straight pam.

H.R. - reiser4 - a btrfs predecessor was geniously architectured ...

True. Unfortunately I really don't see anything Poettering has done as being in any way a work of genius. His work is derivative, and too often falls into the trap of intoxication with ideas, which is prevalent when you're coding: the work you do appears to come from nowhere, and you start to see lots of possibilities of what could be done. Hence feature-creep, and trying to do way too much, instead of understanding the "Unix" philosophy, which is simply the discipline of Software Engineering without pretension.

Leave alone the insane ideas like xml as part of the system software, binary log formats and so on. Or the constant public u-turns about just what the One True Way is this month.

ulenrich · Post by **ulenrich** » Thu Sep 27, 2012 5:20 pm

@SteveL , i am not into it. But I imagine it is just about having the same index what belong together in the logs:
You get exactly to see what you need to without fiddling around so much. All at your fingertips as an administrator. And you can convert to traditional logs using syslog-ng etc... And the dmesg is showing the traditional kernel text as ever.

Regarding consolekit: That ugly workaround is not needed any more!

mv · Post by mv » Fri Sep 28, 2012 8:13 pm

ulenrich wrote:In contrary to
- openrc parallel boot is undeterministic and therefore unsupported
- systemd undeterministic parallelism is supported

Which shows very nicely the difference between a sane developer who know what problem this is casting on users, and a developer who doesn't give a damn about his users.

Since systemd-189 I don't have any issues regarding performace, this systemd-192:

Code: Select all

 
etc # top -b -n 1 |grep systemd
    1 root       1   0 45416 3900 2128 S   0.0  0.1   0:00.21 systemd
   66 root       1   0 33592 2060 1204 S   0.0  0.1   0:00.07 systemd-udevd
   68 root       1   0 61532 3760 3468 S   0.0  0.1   0:00.05 systemd-journal
  408 root       1   0 30328 1696 1372 S   0.0  0.0   0:00.03 systemd-logind
  419 root       1   0  8492  684  576 S   0.0  0.0   0:00.00 systemd-tty-ask

You forgot to add the resources of other "useful tools" which systemd forces on you like policykit (do not forget to add its javascript interpreter - I am actually missing words about this race on who can develop the most broken concept).
And you should compare your numbers with

Code: Select all

# top -b -n 1|grep openrc
#

I see a factor about as large as the stupidity of these broken concepts.
Anyway, we had this discussion before, and I am tired to repeat all the points systemd does wrong. It is a pity if you do not understand this. You can use of course, whatever you want, especially if you do not care about resources and security of your system. But you do not a good thing to others if you recommend it without understanding the security implications.

ulenrich · Post by **ulenrich** » Fri Sep 28, 2012 11:56 pm

Code: Select all

# uptime;top -b -n 1|grep -e systemd -e polkit -e consolekit -e udisk -e openrc -e kdm -e journal -e dbus -e upower
 02:11:33 up  7:23,  0 users,  load average: 1.16, 0.95, 0.97
    1 root      20   0 45404 3848 2116 S   0.0  0.1   0:00.17 systemd
   66 root      20   0 33308 1860 1204 S   0.0  0.0   0:00.08 systemd-udevd
   68 root      20   0 87980 4756 4464 S   0.0  0.1   0:00.09 systemd-journal
  342 root       0 -20     0    0    0 S   0.0  0.0   0:00.00 kdmflush
  366 root      20   0 30328 1660 1352 S   0.0  0.0   0:00.00 systemd-logind
  369 messageb  20   0 22040 2060 1380 S   0.0  0.1   0:00.81 dbus-daemon
  370 root      20   0  192m 3588 2860 S   0.0  0.1   0:00.04 upowerd
  374 root      20   0 24624 1180  976 S   0.0  0.0   0:00.00 kdm
  378 root      20   0  8492  688  576 S   0.0  0.0   0:00.00 systemd-tty-ask
  438 polkitd   20   0  362m 7532 4532 S   0.0  0.2   0:00.08 polkitd
 1192 root      20   0 73020 2388 1812 S   0.0  0.1   0:00.00 kdm
 1261 root      20   0  335m 4832 3292 S   0.0  0.1   0:08.56 udisksd

The bad thing is udisks2 with eight seconds. I hope there will be better versions coming. I don't know about javascript. And I would like what you imply with security issues?

roravun · Post by **roravun** » Sat Sep 29, 2012 3:50 pm

Code: Select all

I don't know about javascript

Have a read: http://davidz25.blogspot.com/2012/06/au ... olkit.html

ulenrich · Post by **ulenrich** » Sat Sep 29, 2012 6:06 pm

And what is this related to systemd?
Nothing found about:

Code: Select all

emerge -p --depclean spidermonkey polkit polkit-qt udisks upower gconf

Calculating dependencies  ... done!
  dev-lang/spidermonkey-1.8.5-r1 pulled in by:
    sys-auth/polkit-0.107-r1

  gnome-base/gconf-3.2.5 pulled in by:
    dev-cpp/gconfmm-2.28.3
    www-client/google-chrome-22.0.1229.79_p158531
    x11-libs/wxGTK-2.8.12.1

  sys-auth/polkit-0.107-r1 pulled in by:
    gnome-base/gconf-3.2.5
    sys-auth/polkit-qt-0.103.0
    sys-fs/udisks-1.99.0-r1
    sys-power/upower-0.9.18

  sys-auth/polkit-qt-0.103.0 pulled in by:
    kde-base/kdelibs-4.9.1
    kde-misc/polkit-kde-kcmodules-0.98_pre20120917
    sys-auth/polkit-kde-agent-0.99.0

  sys-fs/udisks-1.99.0-r1 pulled in by:
    kde-base/kdelibs-4.9.1

  sys-power/upower-0.9.18 pulled in by:
    kde-base/kdelibs-4.9.1

gerard27 · Post by **gerard27** » Sat Sep 29, 2012 7:45 pm

https://bugzilla.redhat.com/show_bug.cgi?id=709351
Look at the last 3 or 4 posts.
Gerard.

mv · Post by mv » Sun Sep 30, 2012 11:21 am

ulenrich wrote:And what is this related to systemd?

I suspected policykit is already an implicit runtime dependency, but you are right: Lennart's strategy seems to be to wait until everybody was forced to systemd before he starts to make the other *kit dependencies mandatory: I conjecture that Lennart wants to repeat his udev putsch. Only consolekit is already forced yet.

Concerning udisks2, it is worth to read this. Similarly as with *kit and systemd, the whole udisks concept was also broken from the very beginning: Again a completely superfluous daemon is used instead of the proper solution - which exists since udev is called by the kernel when a new drive is attached: no need for a daemon. A correct approach to the problem is e.g. sys-apps/uam.

Concerning security implications: Any SUID program and any daemon running with root permissions (or with the power to permit almost any permissions) is a big thread to security. The complexity of such a daemon should be extremely tiny, because you must not understimate the cleverness of attackers who invent ideas the author has never even dreamed of. systemd and *kit have long left this level of simplicity on which one could seriously overview the security implications. The concept violates from the very beginning the KISS principle which is at the heart of all security considerations (Disclaimer: I have not inspected the content of that website any closer).