Yes, because it switched its focus from being an init system/service supervisor to being a system of OS building blocks in one tree.
No, it didn't. DBUS is not part of the systemd tree and it was the udev developers that decided to get their project into the systemd tree.
Not that you don't already know that.
This is plain wrong and I personally explained that many times on this forum already.
Tell me more about that. When I installed systemd on my Gentoo system it installed exactly that: systemd, no additional dependencies. Also, as you are familiar with that project, show us all the additional dependencies that are necessary to install systemd on Slackware. For those that want to know, you have to recompile shadow and DBUS to install systemd on Slackware, no additional dependencies needed.
Please show us a list of those many services, I know of exactly one: Consolekit. Would be nice if oyu can show us more.
Really? Which ones and why do you think it is up to you to decide what developers of a certain project have to support. Why is there no complaining about Gedit only supporting GTK or KDE being based on Qt?
So, using features that are only available in the Linux kernel , but not in other kernels is egoistical? Isn't it egoistical in that case also to not use one of the BSD kernels, but the Linux kernel with its advanced features and much better hardware support? Is it also egoistical that alsamixer does not work with plain BSD, just because it is aimed at ALSA, not at the BSD sound systems?
This is also plain wrong and has been explained to you so many times that I seriously have problems to understand why you still repeat this point. See here:Fair enough, if you don't want or can't support it that is your right and privilege. Just stop spreading misinformation that has been debunked over and over again.
It is as Lennart said: systemd will be extended until it can be used as a set of building blocks for a Linux OS. This includes all the necessary things for an OS to work, except the kernel: init system, service supervisor, essential daemons for setting up the system. About the price for it: That is also pretty simple, the price is that this set of building blocks is incompatible with the BSDs, because it uses advanced kernel features of Linux that are not present in those OSes.
Isn't that the real question? When all these things are present for years and are of high quality, why have so few distros switched to them long ago? What is it that causes distro developers to choose systemd instead. May it be that the cause is that systemd in fact is more than an init system, but the mentioned building blocks, where it is easy to add or remove the parts you want to have for your specific distro or system?
What? Do you really think that somehow suddenly Debian systems (where version updates never occur if not absolutely and totally necessary), Arch systems (which is always bleeding edge) and Gentoo systems (where the user decides which versions to run) run on the same versions of kernel and systemd. That somehow Debian is now lock-stepped with Arch? And you realize that this lock-step of kernel and systemd does not require a specific kernel version for a specific systemd version, but that all that is needed is a specific minimal version of the kernel (at this point you need kernel >=3.4 for the latest systemd)? So you can basically use all the kernels released in the last two years if you want?

1 members found this post helpful.

First off, let me go back and read through that messy jumbled response...

D-Bus wasn't dragged in to systemd directly, but it requires it being dragged into the mix to use systemd. Journald does require d-bus to be of usage, or a patched kernel with kdbus.

A systemd system has systemd as the main core system dependency for many packages. I think UPower now requires systemd on some level with newer releases. Older versions may still work without it. GNOME requires it also.

The please enlighten us how a corrupted binary log can actually be read other than saying I'm wrong. From documentation I've read, if the journal is corrupted, it's useless, and has to be regenerated resulting in the loss of what caused the corruption, or any system problems that could have started it.

systemd deprecated consolekit yes, but it also deprecated the functions of other projects as well like ntpd, sysklogd, syslog-ng, rsyslog, hald (though it's been deprecated by udev for some time with only minor functions still useful), udev-classic (if you want to look at it in a sick twisted sense), dhcpcd, dhclient, networkmanager (not sure if these last three are even still useful since networkd came along), pm-utils, and possibly more if I had enough time to look for them. I think it even has it's own cron daemon too. Not all of those are actually deprecated, but within systemd they're useless because systemd has it's own set of tools.

Building blocks for an OS? Are you serious, or have we all been clueless forever that something was missing? That's honestly a laugh and a half because we've had a whole bazaar of building blocks for Linux based operating systems for quite some time with some variations betwixt and between others. Why do we need yet another set? Because someone egotistically says we "need" it? Are the current tools broken? Are the current tools incapable of building a proper Linux based OS? Why do we need a monolithic cathdralistic toolkit when we have a modular bazaar of toolkits that have worked and still work? Honestly, if that's the case, then ¡Ay,_caramba! UNIX has been broken since it was created, so then what have we been using all this time? Toothpaste, bubblegum, chicken wire, and duct tape holding a kernel and GNU tools together? Wow how redneck is GNU/Linux?

Honestly, I don't know why other distributions chose what they chose, other than speculation into work ethic behind porting stuff in and developing it to work. other than that, I have no clue, but choosing systemd is their choice.

Yes, Tobi, if you even have read Lennart's blogs and mailing lists, you'll see where certain kernels are locked out from systemd requiring using of newer kernels as a minimum. As far as I know, I think you can still use the minimum of kernel 2.6.32 outside of systemd, but within systemd that may not be the case. Some talk around ArchLinux forums has it pegged at kernel 3.3.8 or later. Google it yourself.

3 members found this post helpful.

Redhat leads, the other follows,
I do not think that Pottering would be so successful without a company in the background
and the future will be this
http://0pointer.net/blog/revisiting-...x-systems.html

Please remain on topic, please remain factual and please don't let your personal irritation, or anything else that doesn't matter to the core question of this thread, influence your responses. Thanks in advance.

3 members found this post helpful.

Good point worth pondering...

Had systemd, as it exists now, originated from outside the corporate nest, such that it had to sell itself and survive entirely on its own merits... would any of us even be aware of it?

Asked another way, if the current incarnation and future roadmap of systemd were presented to the free software world by its actual author(s), but without guaranteed inclusion in multiple distros, and without the monetary and political muscle of a billion dollar corporate interest pushing it... would it have gained acceptance or survived?

That is not a positive or negative comment on corporate involvement, but it is intended to provide some balance to the merit based arguments.

If removal of the power backing it signifigantly shfts the balance of the equation, then it isn't primarily about merit, or even about merit at all!

1 members found this post helpful.

But the corporate part is generating some if not most of the resistance.

You could use the proverbial statement, "Follow the money and paper trail back to where it started" with systemd very effectively.

I doubt that if Red Hat had not sponsored it, it wouldn't have gained no greater a foothold than Runit has. The LSB still classifies sysvinit as part of the requirements for LSB standards.

A question to ponder though somewhat off topic (sorry unSpawn) but has Red Hat had any significant losses in the UNIX server OS market in the last 10 years compared to other server minded and oriented distributions like Solaris, openBSD, etc.?

From the look of their financials no.

These are honestly supposed to be analogous comparisons? Alsamixer being made to work specifically with Alsa is the same as systemd development?

There is no mis-information there. Only truth. A very frightening truth. It explains with clear details where things are going.

+1

If Red Hat hasn't had any losses then why push a new project as massive as systemd that poses to develop a "LinuxOS" to duplicate other system control services like SMF, svchost, and launchd in every aspect? That makes little or no sense... but...

One of the aspects I've noticed is with systemd is distribution maintainers like for example, Red Hat, Fedora, and the like have less to maintain on their end. By fair comparison, how well are Fedora and Red Hat's sysvinit scripts written compared to other distributions, out of curiosity? I only ask because a while back on a few Linux forums similar to LQ, someone mentioned that the scripts used by Red Hat or Fedora, I forget which of the two exactly, maybe both(?), had very poorly or sloppily written script sets.

I honestly don't get why such the aggresive push.

ArchLinux I understand as they typically use bleeding edge software without second thought, and have a track record of breaking their own distribution, but others made little sense to abandon perfectly working systems designs, unless they had shortcomings in areas internally.

As far as Canonical, Upstart is a nightmare unto itself, no question why they dumped it, other than monkey-see monkey-do with Debian.

Debian, I don't get at all. That was very strange. Debian has a record of using only the highest levels of using software that's tested, proven, and absolutely non-proprietary in any way, shape, or form.

As far as other distributions, who knows but trend following and monkey-see monkey-do. I've seen few distributions dump systemd also. Only VoidLinux has dared to pasture systemd out in favor of an alternative init and service supervisor.

With sufficient money and promotion, anything can be made popular or even a "need" for it created. McDonald's did not become so immensely popular by selling good food. They became king by throwing large amounts of money into promotion. Quality and need do not play a part. Enter Red Hat and their Poettering front man.

So... Corporate power play with intention of hostile takeover?

I don't see any push but I'm not "in" the community.

xfce4-power-manager also needs DBUS to function. Can we conclude that XFCE now has dragged in DBUS, so as you state systemd has?
These are the package on my system that require systemd:Most of these packages don't actually require systemd, but can be compiled with support for it, which I have done. Also, when we go back to bartgymnast's project (running Slackware with systemd), you can see that only shadow and DBUS had to be recompiled for use with systemd. I wouldn't exactly call this "many".
I don't know much about UPower, so I can't comment on that.
Yes, also a decision by GNOME developers, not systemd developers. If you think this is bad you have two options: Either join the Gnome team and add support for ConsoleKit again, or join the OpenBSD team that develops the systemd shim software. After all, this is still open source, if you don't like something do something about it.
The journal is encoded on a line-by-line basis (how else would you do it with a log?), which means if a corruption occurs only the corrupted lines are affected, the rest of the journal is still readable. Pretty much the same as with a text file.
systemd did not deprecate ConsoleKit, it was simply abandoned by its developer. If that bothers you feel free to take ConsoleKit over. Also, all the services you list, except the ones I will address in a minute, are still existent and can be used fine together with systemd. No one is forcing you to use the inbuilt variants in systemd (just disable them at compile time or, even simpler, just don't use them), you can install and use the daemons you listed just fine. You can use ntpd (and you actually have to, since systemd does not contain a NTP server), the syslog daemons can be used (with even extended functionality) together with journald, and so on. Pretty much the same as in, for example, Busybox, where you also have the choice to use the inbuilt functions or to replace them with whatever you want. So they are hardly useless in systemd systems. You can also still use all these components outside of systemd, so where is the deprecation. You would have made a point with pm-utils, but it was not systemd that removed ConsoleKit support in pm-utils, it was lack of maintenance of ConsoleKit that is the cause and it was a decision by pm-utils developers, not by systemd.
So you are telling me that we don't need KDE, GNOME or XFCE, since WMs and other tools existed before. That nobody should use Gedit because Vi(m) and Emacs exist? Are you serious? As I said above, they want to have the building blocks for an OS in one tree, so that you can decide at compile time which features you need with a simple switch to the configure command. Also things don't need to be broken to be replaced, it is enough that a competitor of those things is better suited for a certain job. As it seems many distribution developers do actually think that systemd is better suited, otherwise they would just use something different (which in fact at least some do, see the switch of Void Linux from systemd to runit). Fact is: systemd consolidated (or is in the process of consolidating) building blocks for a Linux OS in one tree, many distro developers appreciate that effort. So there must be an advantage for systemd here.
I don't have to Google it (I would use DuckDuckGo, anyways), I gave you the answer in my last post, LP himself said that you need at least 3.4 for the latest systemd (at that point 216). This number, by the way, was given by one of Lennart's answers on the mailing list.

Yes these are honestly supposed to be analogous comparisons. How is it not egoistical of alsamixer not to support BSD sound systems because it is written specifically for ALSA sound system and all the features it has, when it is egoistical for systemd not to support BSD kernels because it is specifically written for the Linux kernel and all the features it has?
When ReaperX7 repeats again and again that all systemd services have to run in PID 1, despite this having been debunked and explained to him over and over again, then this is spreading of misinformation, it is not telling the truth (unless you think repeating a made-up "fact" often enough makes it somehow the truth). I can't say if that is deliberately or has other reasons, but that does not change the fact that he is spreading misinformations.

1 members found this post helpful.

Developing a mixer as an additional component for a sound system is vastly different than OS-kernel compatibility.
I am not sure if the meaning of my post was clear, but I was referring to your description of systemd being extended, until it can be used as a set of building blocks for a Linux OS. You are completely correct. And I wish you were not, because the implications are frightening.