is systemd really all that bad?
 

hi guys,

i know most distros are switching to systemd
and i been reading a bit about systemd

i cam across a few tutorials/explanations regarding systemd and on the
one video there was a comment.

"It looks like someone is trying to "microsoft-ize" linux !! In the future i see it as "do what we say, not as you want to " mindset. and I don't like it. I use linux for a reason, i guess it's time to switch to BSD !!!!!"

what did the poster mean by this...is systemd really that bad...?

is it a bad thing that distros are going this way?
why does the poster feel the previous init system was so much better?

i value all your opinions

init.d, although it doesn't exactly read in a clearly obvious manner is straight-forward.

systemd isn't.

Want some reading?

You might also find this useful:

https://www.linux.com/learn/tutorial...-using-systemd

I don't like the all-encompassing binary blob aspect of systemd, but it does seem to be a done deal as far as most distros are concerned.

There's a Linux sysadmin in my LUG who says, that, when systemd works, it works great; when it doesn't work, diagnosing the problem is a real pain.

There is a reason a lot of distributions are going to systemd and getting an understanding why can be a real education in how a modern OS starts up and the issues involved.

The fundamental issue is that a lot of the services that need to be going after the system starts up depend upon each other in multiple ways and trying to decide which one to start first, which one can start and be put on hold, and which can start later can get 'real interesting'

There is a long history of system startup programs and I have seen an article on that history that was amazing in that there were so many of them just for Unix style systems. I don't know if that article is in the referenced additional reading links above, though, but it does appear that those links are to some good information.

As for the complaints, gripes, and bitchin' ... well, that's the community. Everybody has their favorite and a lot of folks don't like change and sometimes they get a bit hyperbolic and exaggerated in their rants. These rants may have some interesting points but separating the wheat from the chaff can be a bit of a challenge.

The distribution people are pushing their own particular flavor of a Linux solution. You choose which to use based on what does best for you. One of the nifty things about using Linux is that you can into the choices the 'experts' make and learn a lot about the technologies you use on a daily basis. That education is a real eye opener into just how much there is that many just take for granted.

And keep in mind that many of the decisions about the system design are much more than just technical issues. There are priorities to weigh against options, social factors to consider, intended market, and other factors that can be rather subtle. A lot to learn about there, too, if you have the interest.

These systemd threads always run for a long time.
Often after many posts, people just agree to disagree.

Personally, I don't like change if it is purely for the sake of change.
If it ain't broke you don't fix it!

I like the heck out of systemd

It really is that bad.
 

Systemd is the worst thing in the universe. Dennis and Ken didn't write it in the original Unix, so it must be a Windows construct. It uses binary data which will lock away your data and throw away the key, just like the rest of the binary data on your hard drive. If systemd has any value at all it's so that Red Hat can turn it's stable distribution into a Windows Server clone but worse because stability is overrated and they're not interested in making money anymore. The unit file ini format isn't an unstructured text file so that's just dumb. Byte streams are way faster than JSON, so the journal is useless. It's also not one of {s6, openrc, sysv, upstart}, so it's just reinventing the reinvented wheel again. If everyone would just pretend that our broken programs aren't broken we can stop pretending to fix them by fixing them.

Did I miss anything?

I wish there was a book about SystemD because after using it for now several years I still don't really have a real grasp about all the whistles and bells. And they just keep adding stuff to it.

Other than that I don't really care about the future of Gnu/SystemD

Not to quibble as I quibble, it's not GNU/SystemD. It's Red Hat System D.

Here's an interesting article in defense of SystemD. http://0pointer.de/blog/projects/the-biggest-myths.html

I have been looking at SystemD in a VM of Scientific Linux. I think it's important to separate complaints about how SystemD works from resistance to having to learn a new way of doing things.

I'm not saying this to take a position on SystemD. (If the day ever comes that Slackware goes SystemD, I'll probable go BSD.)

I am saying it because I realize that part of my resistance is that SystemD is a new foreign language that I really don't want to have to learn.:) I need to separate that part from the rational parts. As long as rsyslog is installed and working, maintaining the traditional /var/log structure, the greatest part of my objection to SystemD is alleviated.

I think people get emotional when talking about this and most of the times get lost in their arguments...

Systemd provides some very, very nice features... Good cgroups integration and logind is just the tip of the iceberg (and two of the best things it provides)..

The problem (and the reason why systemd is considered bad and evil) is that it provides all of this in a monolithic manner and then straight up lies about this... Systemd (as opposed to what their lead-developer say) is as monolithic as the Linux kernel and this does not affect the end-user as much as the eco-system of developers that decide to use it's features... To make matters worse, those features are usually of use to important projects (like Gnome or KDE) so if they decide to, for example, depend on logind, every system that wants to run KDE will have to boot with systemd (even if KDE wouldn't care who the init is and just care about logind and cgroups). To make matters worse, systemd has it's own dependencies (enough to basically define what the base part of an OS, the one that affects virtually every other app, should be)... This can quickly turn into a disaster... Ohh, and the best part is that if they decide to depend on some library which depends on some kernel functions which are not part of the official kernel (like, say kdbus).. Well, everyone that wants Gnome or whatever app (which just needs some functions provided by systemd, not caring about the actual login system) will have to use systemd which would want a patched kernel... Of course, for now that won't happen since kdbus will probably (eventually) be integrated in the kernel and is still not a hard-dependency, but just the sheer fact that this could happen in the future... You see the problem of creating a dependency chain?
To me, systemd is similar to sticking with "goto:"'s in the code..

In short, this is an attempt of vendor lock-in.

I personally live fine without systemd.

i wonder, have there been similar "wars" in the past?
about softwares that are now just accepted, even by those currently complaining about systemd?

Yes BSD init v SysV init

No, they wouldn't. They would be able to use any system that provides the same DBUS interfaces that systemd-logind provides, since they are not dependent on systemd-logind directly.
Now, this is basically the definition of FUD, Fear, Uncertainty and Doubt, without any actual information that this happens in the real world.

How would you achieve vendor lock-in with a software that is LGPL licensed and therefore can be forked by anyone at any time?

So is anyone going to devote a few years of their life, just to come up with SystemE?

Eventually someone will. This is how this all worked for a long time and will work in the future: Someone writes a software and it is used for some time. Then someone comes up with something that he sees as fitting the current environment better and it may or may not supersede the first software. Then another person comes up with something that he sees as fitting the current environment better and it may or may not supersede the previous software. Repeat how often you want to.

That a software is used forever is simply not what's happening in the real world. Eventually systemd will get replaced, the same way that every software at some point will be replaced. At some point, maybe due to a major breakthrough in computer architecture, even the Linux kernel will be replaced by something that fits the then current environment better. That is just how the world works.

Well, how many people in linux community can actually fork something? I doubt most people who bitch about systemD can actually write even a hello world program.

And there you have it. Act like a consumer and get what you're given - want to do something about it? Get the skills (or if you have loads of cash at your disposal pay people to work on it/donate to projects already working on it). Otherwise you're just a freeloader, along for the ride using other people's work for free.

We've had loads of threads about systemd and all the hand wringing, bawling, FUD mongering, counter FUD mongering and proselytising about it changes nothing: There are still Linux distributions which don't use it or allow you to avoid it. You can switch to those distributions.

The same could have been said prior to Systemd being implemented. The point is not whether everyone can do it but that some can and may choose to. This would be
the whole point of an open system such as linux

Is that really different? Because what will you use until the alternative will be written? And ok, logind is that important (and quite a clever solution) that alternatives will be written and they will be good.. But logind isn't the only thing that systemd does and that doesn't change the fact that systemd pushed the developers eco-system into a chain reaction... Which was the point of my post..
I have to say.. It's not.. You can check any of my previous posts and see I'm not that kind of guy.. I'm just thinking logically about their push of kdbus and you're welcome to tell me where I'm wrong.. You might disagre but vendor-locking is not that far from the truth..

That's like saying we should not say mean things about Justin Bieber because we can't sing like him..
Btw, the answer is: a lot, a lot of people can actually write complex programs.. But not that many care to do it or can devote the same amount of time into writing a fork or have the resources to do it.

And the current dbus requires systemd - or at least did the last time I looked.

Not here it does not - Gentoo.

You can say it's not vendor lock in, but when you forcibly deprecate software to push agendas and leave only one chunk of software left viable, then yes it is vendor lock in, LGPL, BSD, ISC, etc license be damned. Lock in is lock in. It takes time to redevelop stalled projects and bring them up to speed, and by then things have moved on. It takes time to bring in fresh ideas from talented programmers and put them to paper, then to code, and then to application, and by then things have moved on. Only certain things have ever stalled long enough to see new and improved.

It took time to get ConsoleKit2 brought up to be on par with logind and to a stable release. It's taking time to get vdev to a stable condition to replace udev, and it's still not finished. Time is anything but in the software world, and by then, things will have moved on.

You can replicate, revive, and replace software, but only with time, talent, effort, and willingness. License be damned. Roll the license dice and take your pick, but licenses won't prove, prevent, or promote anything.

We've been fortunate enough to not have lock in thanks to the willingness of developers though. Let's hope it stays that way.

Yes, except that everything prior SystemD was actually exactly as God intended everything to be.

http://www.freedesktop.org/wiki/Software/dbus/

//edit: Also: http://www.linuxfromscratch.org/blfs...eral/dbus.html

No, it wasn't. If it would be we would still use sysvinit without sysvrc, as was the case in the early times. Then it wasn't good enough anymore and people went to use it in conjunction with scripts (sysvrc). Then that wasn't good enough anymore and people invented stuff like daemontools, runit, S6, OpenRC, Upstart and so on. It isn't that systemd was the first and it won't be the last.

I am not quite getting your point here. Are you saying that systemd developers should be blamed for trying to achieve a vendor lock-in because other projects are not up to par with systemd?

I think we should have another argument over systemd we haven't had one in a while.

I can't speak in his name but I'm pretty sure he's saying systemd developers should be blamed for (trying to achive??) achiving a vendor lock-in from the way they designed and implemented systemd as a core, monolithic system and not a separated init-system, a separated login system, etc.. By your own words, a logind-like can be rewritten to provide the same dbus interface.. So if that's all it would have taken, why would they mangle the code so bad that they made sure systemd can't be used without logind and logind can't be used without systemd forcing everyone to wait until and alternative is written or write their own alternative? Why does ConsoleKit2 need to exist and why does logind need to depend on systemd?

Replying to the original post - as the OP has not responded since:

When you said "video" and "comment" the alarm bells rang...

The comment is just opinion from someone who is most likely not in full possession of the facts.

That's a loaded question and you will get hundreds of different answers. You will really need to research this for yourself.

Did he say it was? I doubt he even knew there was an init system until reading all of the hype about systemd. systemd has been controversial and there are diverse opinions written on mailing lists by actual developers which you can read if you like. Random blogs, opinion pieces in forum posts, videos and watered down technology press articles are not a good source of information.

At first, systemd can very well be used without logind, the only components of systemd that can not be disabled easily are udevd and journald. Logind can be used without systemd, see for example systemd-shim in Debian. Why they have all their components in one repository is well known: the components can share code that is used by them, and it is much easier to test the system for problems between different components.

There was no getting up to par with systemd until developers started abandoning projects for systemd inclusions.

Before this fiasco, projects were going along at a steady pace and developing things without any standard par to aim for. Things were ready and done, when they were ready and done. Since systemd came along, everything that was abandoned for systemd was either forked out, redeveloped, or fresh starts were made, some which made it, some which are ongoing, and some that faltered, but development had to be ramped up to get on par with systemd or be left behind, but there was no excuse that all of this could have been avoided in the first place by not trying to drag anything and everything into systemd 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.

If the shoe fits, then yes, they are completely responsible for creating this mess. If they didn't want to be held responsible for their actions, they shouldn't have attempted this crap in the first place, but no, they have too many people trying to make up excuses for them to put the blame on everyone but them.

'K, thanks!

wow, this thread has grown so fast - once again :rolleyes:

i havent really commented on anything...as i know very little...just reading comments here. i am a total newb who completed linux+ earlier thus year and have moved onto Red Hat certification...

i guess we/i will be stuck with systemd for some time...and its in the course

the next question is how much should you know?

can anybody give me some key points on things i should be learning to do with systemd...i know its to stop and start services etc...but i know it can do a heck of a lot more...from what i read its moved from being an init system to handle more management roles...correct?

and from what i read systemctl is a very popular command with systemd...some exercises would be great...

i dont even know what logind is...will do some reading

thanks

What is vdev?
Don't tell me its a "son of udev"!

If udev ever fails me I wouldn't have a hope of fixing it - its monolithic, but not as monolithic as systemd.:rolleyes:

Thanks. It does on some systems (mine for instance). It must be a compile time option, thus making the binary non-portable, but understandable.

There is no systemd in my boxes.

So your point is that somehow systemd developers are to blame for having a faster development speed (which comes naturally when you have contributors from all major distributions, I would think) then the rest of the ecosystem. I don't quite know if that is something they can be blamed for. Just out of interest, besides Consolekit, would you mind to tell me which other projects were abandoned in favor of systemd?

Vdev is the work of Jude C. Nelson who is working with the Devuan project to create a truly non-locked into systemd Debian. It uses fuse and some extra libraries to implement a kdbus-like virtual device file system that operates similar to udev, and attempts to maintain a backwards compatibility layer for udev using drivers, libraries, and utilities like gudev, evdev, etc. It's aim isn't just for GNU/Linux but *BSD as well at the current future which could import udev-like functionality to *BSD and allow portwork of utilities in *BSD that lack these functions.

systemctl is meant for controlling the system's state, read: starting/stopping services, enabling/disabling/masking them for certain targets (which are basically named runlevels), rebooting/powering off the system, ...
Then you have specialized stuff like timedatectl for setting the clock/date and timezones or machinectl for handling virtual machines, containers and sessions.
What you learn is up to you, if you don't have a need for virtual machines or containers than their is not much sense in learning how to use machinectl, for example.
In the end, if you really need something that you don't know about yet, all the info is only one manpage away.

Regarding logind, you shouldn't need to care a lot about that, have a look at the configuration in /etc/systemd/logind.conf if you want (you can for example set up the number of TTYs you want to get on boot or set actions that should be run when pressing the power management keys on your keyboard), but mostly it is just used by display managers and you don't have to care.

To add to what ReaperX7 already posted: https://github.com/jcnelson/vdev

Actually Tobi it's not just power management, it's login and session management as well as systems rights management to core resources. That means simply, I login, not as root, but attain enough rights to root level permissions to have access to sleep, hibernate, shutdown, and reboot the system. The logind.conf file isn't going to just magically say what all logind does or is doing.

I don't need to. You take out ConsoleKit and pretty much anyone wanting a nice desktop environment such as KDE, Plasma, Xfce, MATE, Gnome, LXDE, LXQT, and any other session management using desktop environment with adequate control of system and resources from a user account, and pretty much anyone would be forced to eventually bring in systemd as developers stop coding for ConsoleKit. Then what? People abandon dhcpcd, dhcp, networkmanager, etc.? If that's you're reasoning developers should just abandon the Linux kernel itself as well as the GNU project and use Windows or OSX.

Better question, where did all the loudmouth hipsters go recently who were spouting systemd this and systemd that? Answer, they'll all using Windows 10 trying to make it a trendy thing, saying it's cool, and trash talking anything but Windows 10 is the best OS ever.

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.

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