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?

1 members found this post helpful.

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

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.

1 members found this post helpful.

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.

1 members found this post helpful.

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.