Facebook Continues Making Extensive Use Of systemd

[cybertraveler]

Corrections of what? They are both appeals to (biased?) authority.

You said:

"But for example it didnt't really handle well the multithreaded startup thing that OpenRC and Systemd do"

I cited evidence that, that is not true.

You also said:
"[the lack of multithreaded startup] is why most distros dropped it like a hot potato when it was the time to choose between that or Systemd or OpenRC"

My above fact invalidates it and Mark's comments about systemd further support the above fact. You statement is invalid. You are wrong and you know it.

As I already said, the whole point of a complex and powerful init system is servers where you have to start up your own application chains, if you are running mostly independent applications pre-configured by distro maintainers then it will work decently even if it's garbage, as long as the maintainers are good.

One of the reasons I had issues with it (weird bugs notwithstanding) is that Upstart is event-based, i.e. it starts services depending on the system status or event, but does not check application dependencies per-se. This matters when you are writing the init scripts to start custom services in a server.

...

Your dishonesty is shining through again. Rather just accept you were wrong you're now arguing something entirely new in favour of your favourite init system.

Your new comments aren't even entirely correct. Upstart isn't a dependency based init system. That's by design. However can and does (in my system) start services based on dependencies. It just does it in a different way. There is no limitation of the design here. It just works differently; by design.

Dependency based startup with Upstart isn't just "doable"; it works perfectly. The only way services / tasks would start out of order is if the distro creator misconfigured Upstart. This is the same as with systemd.

You act like you're so objective and committed to truth yet when confronted with facts which invalidate your claims you just change the subject and start spreading more incorrect information.

I'm not defending Upstart from an anti-systemd stance. I like both Upstart and systemd. They both have pros and cons.

[oiaohm]

So, are you suggesting that if I apt purge systemd from my Kubuntu, SDDM will still work and I'll be able to log into Plasma? If not, the initial assertion is more or less correct.

This is not a valid arguement. This fails because ubuntu the source of Kubuntu does not have upto date consolekit being consolekit2. The min requirements of SDDM is either a current versions of systemd logind or consolekit2 without other bugs.

There is no much you can do when distributions are not providing current versions of key software. Not providing also reduces the testing on that software.

When SDDM was first released if you purged consolekit it would also fail.

The reason why purge systemd fails is distributions lack of providing consolekit2 and reduce testing this has caused. Like you can purge systemd from quite a few distributions and have SDDM work their is a common fact those have consolekit2 as install-able package and have locked SDDM to versions that work with consolekit2 until upstream can apply fixes. Yes SDDM and consolekit2 both apply fixes working around each other issues.

SDDM and KDE will work with the elogind package as well that is logind cut out of systemd this is more dependable than the consolekit2 option due to being more tested.

Performing an apt purge of something only shows a problem. Does not give the exact information what the problem is. Like you would not be thinking you need to be up Ubuntu ribs to update consolekit to consolekit2 right? Or for SDDM to have more automated CI work to make sure consolekit2 and SDDM are dependable options.

Its like trying to use a program that need a libc be it glibc or musl then complain that the distribution completely fails because you remove glibc. Yet a distribution based around musl the program would work find right. There is no difference with the consolekit2 vs logind problem.

[Guest]

This is not a valid arguement. This fails because ubuntu the source of Kubuntu does not have upto date consolekit being consolekit2. The min requirements of SDDM is either a current versions of systemd logind or consolekit2 without other bugs.

There is no much you can do when distributions are not providing current versions of key software. Not providing also reduces the testing on that software.

When SDDM was first released if you purged consolekit it would also fail.

The reason why purge systemd fails is distributions lack of providing consolekit2 and reduce testing this has caused. Like you can purge systemd from quite a few distributions and have SDDM work their is a common fact those have consolekit2 as install-able package and have locked SDDM to versions that work with consolekit2 until upstream can apply fixes. Yes SDDM and consolekit2 both apply fixes working around each other issues.

SDDM and KDE will work with the elogind package as well that is logind cut out of systemd this is more dependable than the consolekit2 option due to being more tested.

Performing an apt purge of something only shows a problem. Does not give the exact information what the problem is. Like you would not be thinking you need to be up Ubuntu ribs to update consolekit to consolekit2 right? Or for SDDM to have more automated CI work to make sure consolekit2 and SDDM are dependable options.

Its like trying to use a program that need a libc be it glibc or musl then complain that the distribution completely fails because you remove glibc. Yet a distribution based around musl the program would work find right. There is no difference with the consolekit2 vs logind problem.

See, that's what I'm talking about. There is always some technical explanation or excuse but at the end of the day as far as the end user is concerned, the login on most modern distros does depend on logind and thus systemd. That's the reality of it. The technical reasons for that reality don't really matter, unless your hobby is building vs using OSes.

[rtfazeberdee]

See, that's what I'm talking about. There is always some technical explanation or excuse but at the end of the day as far as the end user is concerned, the login on most modern distros does depend on logind and thus systemd. That's the reality of it. The technical reasons for that reality don't really matter, unless your hobby is building vs using OSes.

But none of that is systemd's fault - its down the developers of SDDM or KDM to make it possible to make a choice of how it manages the login.

[PluMGMK]

"pystemd"… Am I the only one who finds this name somewhat unfortunate?

[duby229]

Damn, you found out my little plan of teaching kids the wrong use of shell scripts so they can get burned by it and then hate it and then flock to systemd because it does not need scripts to work.

What you really mean is that you found a way to increase retardedness by introducing a means that prevents kids from learning functionality because it doesn't have functionality.

Just because you grew up on windows which doesn't have a proper shell and can't be fixed or scripted, doesn't mean MS was right, it just means MS is fucking stupid.

[cybertraveler]

"pystemd"… Am I the only one who finds this name somewhat unfortunate?

piss-tem-d :P

I'm sure they intended:

pie-stem-d

I'd have named it:

pysystemd or pysysd

[oiaohm]

See, that's what I'm talking about. There is always some technical explanation or excuse but at the end of the day as far as the end user is concerned, the login on most modern distros does depend on logind and thus systemd. That's the reality of it. The technical reasons for that reality don't really matter, unless your hobby is building vs using OSes.

Really there are a lot of distributions out there that support both consolekit2 and logind. The issue with only 1 pam used session manager is not new. Before systemd existed you had consolekit doing the logind role and if you removed that your graphical logins died as well.

If you do not like systemd you need to be asking distributions to provide consolekit2 support and openrc support.

The technical reasons are important to understand when choosing a OS for particular roles. Like debian cut down into a container not having systemd or logind makes sense. These could be pure text based pam logins no device access required so not even consolekit make sense.

Thing get very interesting once you start using distributions in containers.

When you have user running gnome and you designed to use consolekit2 you can have the horrible that user logs out then cannot log back in. Yes the big noise about logind cleaning up processes when users logged out was so users could log back in and not be blocked by locked files caused by old sessions keeping on running.

Also logind is not straight forwards either.

https://github.com/elogind/elogind

So there are two forms of logind that have a blood line going back to systemd.

logind that comes with systemd that places sessions around almost everything. elogind that only provided elogind that only provided heavy session protection around the graphical logins.

elogind provided the protection you need to graphical logins don't result in locking users out due to kde/gnome/xfce... session management not being dependable.

The elogind contains the only part of systemd that graphical logins in fact can have as a dependency.

elogind is less features than full blown systemd logind but enough that everything works well.

elogind that is based on systemd source code would not be need if consolekit2 was more complete with cgroup support and dbus interfaces for SDDM and the like to use.

Claiming this stuff is executes means you can maintain a anti-systemd bent without understanding how little systemd is required. Consolekit2 could render the need for elogind not required in time.

elogind + openrc is quite a common and dependable combination.

Basically the cgroup tracking being requried systemd logind and the fork elogind to make everything behave traces back purely to kde,gnome, xfce.... session management being a multi standards incompatible and broken mess at times locking users out of their own system.

There is a technical reason why systemd logind design is kind of right. There is a mess in session management that needs to be fixed.

Yes it was really easy for those to complain I have logind it will not let me leave programs running while completely missing that is what the different X11 graphic desktops session managers were doing all the time then refusing to let user log back in.

msotirov technical explain is not excuse. It leads you to what you need to push to happen if you don't like the way stuff currently is.

If you don't like systemd you need work on consolekit2 or maybe those making kde/gnome/xfce... could at long last make a unified and working session management.

[starshipeleven]

i don't know about openrc, but systemd will start all apps at the same time in parallel with socket activation

As long as the application service file does not specify dependencies, that is.

[cybertraveler]

...

Yes the big noise about logind cleaning up processes when users logged out was so users could log back in and not be blocked by locked files caused by old sessions keeping on running.

...

Your whole post was interesting thanks.

Re the bit I quoted: were people really complaining about this? It seems very sensible to me to terminate all user processes when a user logs out. That's the point of logging out: to end your session. If a user wanted their session (or parts of it) to persist, it would make sense for them to either lock screen or switch user (leaving their old session running). Or maybe if they need something running (like a bittorrent client) it should be running as a service. In the example of a Bittorrent client, there are Bittorrent clients like Deluge with a daemon backend and a number of front-ends you can connnect to it. A user could turn the daemon back-end into a service that would persist after they logout (that's an option anyway).