Historically we've seen other software saturate the market, gain leverage and become a de facto standard - without necessarily being technically superior to anything else. So long as the software as a "platform" and ties itself in with other important software, then users can slowly sucked in.

So in fact the worries over the monolithic nature of systemd do have some grounding at least. But unlike certain historical examples it's far more difficult to foist systemd on users who exercise the right to choice. Users who merely complain and still stick to the same distribution actually deserve all they get. systemd is certainly inevitable for someone if they are going to just complain incessantly and then still use it...

In all honesty, when Linux went 'mainstream', this was to be expected. The majority of new users who got onboard the Linux bandwagon with distributions like Ubuntu, just wanted an alternative to a Windows desktop/server, not a free *nix.

systemd will either fade away to be replaced by something else, or slowly evolve into a Linux based OS in it's own right (something like Android but for workstations and servers and much more flexible of course).

It already is it's own OS. It's called CoreOS. Take CoreOS and add any package manager and you have Debian, Fedora, Arch, etc.

systemd is already replaced... with everything it tried to replace. The distributions still using it really haven't progressed much either, and systemd development-wise has slowed considerably. Kdbus literally ended up stalled out and left in limbo within linux-next, and when vdev is completed, neither systemd, udev, or eudev will be needed and neither will kdbus.

I never have claimed that. What I have said is that logind configuration for the normal user is largely irrelevant, you almost never have to touch it.
You make that sound that somehow it is the fault of the systemd developers that after Consolekit went unmaintained no one, despite all the complaining and whining on all the forums, took it up to themselves to go ahead and take it over. Yes, some projects indeed stopped maintaining compatibility with Consolekit (the uPower people, for example), only they did it not because systemd was there, but because Consolekit went unmaintained for years. No sane developer will maintain compatibility with unmaintained projects and they shouldn't be blamed for doing that, as systemd developers shouldn't be blamed that no one takes over maintaining of projects totally unrelated projects.
Anyways, you claimed that systemd forcibly deprecates other projects (post #26), you claimed that developers have abandoned their projects for systemd inclusion (post #35) and you claim that systemd somehow is "trying to force, coerce, and bully users, administrators, and system developers into a single locked in and locked down system they'd have little to no control over", yet you don't present a single bit of evidence for your claims and when asked for names of those allegedly abandoned projects you tell us that you don't have to tell us the names, leaving me to believe that you can't actually present any evidence for your claims.
And now you are down to name-calling. Sad, just sad. Nothing more to say to that.

Well, at least I don't try to claim to be agnostic to the argument of being for or against systemd and blatantly show publicly that I'm for it and do everything short of breaking the rules to pick a fight, belittle the opposition, and poking the stick to make myself seem that much more knowledgeable or important all why trying to deny my position. At least I'm up front and make it known where I stand, even if I am blunt and don't come with a filter.

The fact is systemd has lost all it's great momentum of steam and has little or less made any real advancement these days. A few things are done here and there, but nothing huge. Maybe we'll never know why. Could be everyone did go to Windows 10 and shut up about it, maybe even the fact kdbus didn't get added officially to the kernel let the air out of their tires, maybe things are just getting monotonous as trying to add more and more stuff proved a huge task, maybe even too huge, or maybe after that "The internet is full of assholes..." speech, someone finally got knocked down a peg or two and learned that not everyone is going to just willy nilly go along in lockstep with some delusions of grandeur no matter how much you push the issue because the GNU/Linux community pushed back, pushed back hard, will always push back, and proved that systemd wasn't all it was cracked up to be by stating that a locked model is not what is needed or wanted and choice is the best solution to any design. Who knows?

All we do know is, even after all this time, the more things tried to be changed, even by force, the more things remained the same by the return of force used. Some systems use it, some avoid it, and some offer it as optional. Your best bet, pick your poison (distribution) of choice and drink your fill. If you like it, by all means, and if not, then you have plenty of options. Some like the kool-aid, others don't.

1 members found this post helpful.

Unfortunately systemd and the kind of developer and mindset behind it are not unique.

Do you have an opinion on the gnome project? You may find gnome irrelevant, but in fact gnome is a very big part of what's dragging systemd into the mainstream.

What about Xamarin and de Icaza? http://techrights.org/2015/10/30/xam...obovm-freedom/

I mention these as you've brought up "UNIX philosophy" and "POSIX compliance" in the past - and Apple's OSX is much closer to both than any of those. I just don't get why systemd is suddenly the bogeyman of the moment when a lot of horrible shit has been present in the Linux "eco system" for a number of years...

"Write programs that do one thing, and does that one thing well."

Solaris' SMF is an init program similar to systemd, launchd, s6, runit, etc. but it is an init only, and does not serve any other function other than being the init service supervisor and system state manager. It basically does the same job sysvinit and bsdinit do, but with supervision of services. It does it's job, only it's job, and it does it well.

https://github.com/systemd/systemd/graphs/contributors
I can neither see it slowing down nor see an influence of the Windows 10 release in this actual data. Other than that, we can see what we see in any other large software project: Once the groundwork is done you won't see it on the news every day anymore, this is just how software development works.

Systemd fallacies, fallacy #6 was mentioned in this thread, too.

If systemd ever works right it might be great. But until then:

If I restart dbus. Switching users takes half a minute (it takes less time to reboot). Restarting systemd-logind after restarting dbus seems to tame this beast, sort of. No idea why systemd-logind AND logind are BOTH running, when just logind was good enough before.

If I do a chroot, like when installing linux in linux. I have to stop ALL the processes on the HOST system (including dbus and udev) to unmount the chroot after I'm done with the chroot. Or behave like a windows admin and reboot, reboot, reboot.

And probably hundreds of other this schtuff isn't ready for production issues. The service and systemctl stuff is nice-ish, except for the all processes that are not yet adapted to systemd. Like lpd, ModemManager, ... ... ... ... At times I feel like systemd will end up like Xdmx. As in reach a point of almost amazeballs, and then get left for dead with no alternatives that can do equivalent type stuff. And no one proficient enough in the lingo to ever risk changing it.

Just tested that on my Arch system, no problems at all.Then something is seriously wrong with your setup. None of my systems behave that way when using chroots (while admittedly I mostly use systemd-nspawn instead), not Arch, not Gentoo, though I would have to test it on Debian. May I ask which distro you are using?

Yes, Jude is the vdev developer and clearly knows his stuff. He is not averse to posting on forums either and he has registered and responded to me in the past at one of the Debian forums and has demonstrated a deeper understanding of this issue than most.

I agree with pretty much everything he writes there, that's within my sphere of understanding anyway. I can certainly understand and relate to the shell scripts vs compiled binary code arguments. I can also relate to the 'controversial' argument that not liking how the developers manage things is as good an excuse as any for avoiding the software. It's funny that in most Linux forums not liking and trusting MS and their business practices is a good enough reason not to use their software. Not so for systemd though it seems... You can't exactly criticise the code for MS windows because it's closed source...

My personal opinion has always been that systemd is poor quality code, developed at an alarming rate for performance and functionality's sake alone. Unfortunately it's now the standard in most Linux distros - so that's most Linux distros pretty much putting their cards on the table and saying "we don't care about quality". It's what amounts to the headless pursuit of features and performance at the cost to robustness, a proven design methodology and security.

Well Systemd IBM wanted it. Billion dollar donation to Redhat or was it linux foundation what ever they go with the money and that is cool.
But this article here is from the people that really deal systems and large server farms.
Oh well you have to trust the person building the system. That is what stability comes to. Any one can write somthing and keep tweaking it to work for them.
As long as it is stable and you trust the people behind the distribution.

1 members found this post helpful.

Isn't systemd just experimental software though?

Will I have to buy a text book to find out how to use systemd on my desktop?

No, its the default replacement of the old SysV init system on RHEL 7 (!) and derivatives.
That's as mainstream as it gets (for servers at least).

Looks like Debian is going that route too http://arstechnica.com/information-t...ge-since-1993/ .

Those are the 2 of the main base distros that others are based on ... inc desktops
http://futurist.se/gldt/wp-content/u...0/gldt1210.png

We are their lab rats, so yes it is very experimental.

I'm looking for a book on systemd myself but there are none.