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?_________________Fitzcarraldo's blog

systemd is available in portage - that's probably enough to get into that list._________________backend.cpp:92:2: warning: #warning TODO - this error message is about as useful as a cooling unit in the arctic

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.

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._________________Fitzcarraldo's blog

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, 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._________________Regards,

NeddySeagoon

Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail.

I'd like to know if Linus has made any comments on systemd.
He has/had ties with RH.
Gerard._________________To install Gentoo I use sysrescuecd.Based on Gentoo,has firefox to browse Gentoo docs and mc to browse (and edit) files.
The same disk can be used for 32 and 64 bit installs.
You can follow the Handbook verbatim.
http://www.sysresccd.org/Download

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.

@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 ..._________________fun2gen2

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.

...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.

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?

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.

Quote:

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.

@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!_________________fun2gen2

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:

# 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.

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).