Systemd-logind must be restarted to prevent delay

ok, dbus has this ridiculous bug, triggering crazy systemd behaviour, more proof that both of dbus and systemd are best new shiny things since sliced bread.

But systemd relies on dbus; indeed, a major reason for its existence is to dbusify every aspect of your system. And the fact that dbus, which has been around for ages, is still exhibiting strange behavior like this does not bode well for the reliability of such a system.

The whole fd.o ball of mud is well beyond the complexity threshold. It's a pain in the ass to attempt to even understand the workings of, let alone maintain. Expect to see minor to moderate shitshows like this every few months or so, and box-breaking flagdays when the maintainers decide they don't like the current interface and throw it out to write a brand new one.

It can also be because people want others to know that they're not alone when they see strange delays when logging into production systems and there's a fix for it that you probably want to know about.

both sides are really toxic here. that's a problem.

even a compile time switch was not feasible for tmux (to enable pam). while systemd still lacks a good api design that is close to daemon(). in a world with so much communication we should at least try to work together..

> Besides that it is pretty obvious that the standardization of systemd and the elimination of distribution-specific scripts and services has resulted in massive reduction of bugs and complexity in the Linux OS. Accounting for each distribution individually, counting those bugs up, adding all them into one lump sum... I am willing to bet that for every 1 bug that systemd introduces into the OS it has resolved at least a 1000

Citation needed.

I'm not a fan of the kernel-up/desktop-down dichotomy, but please remember that "1. User's needs/wants and 2. User's application" are a) not necessarily desktop applications (in fact, for 99% of the places where Linux is deployed on this planet, it's anything but desktop applications) and b) depend on systems software, which is anything but pleasant to write and integrate with community non-players like systemd.

This binary, "user needs = true, programmer needs = irrelevant" dichotomy is very toxic to an environment that still, by and large, depends on community support for its existence.

> Besides that it is pretty obvious that the standardization [..] has resulted in massive reduction of bugs and complexity.

If that were true it would be easy to see the difference in outstanding bugs between distributions that adopted SystemD and those who haven't, since their bug-numbers would be orders of magnitudes larger. To my knowledge this isn't so.

From a larger perspective you are arguing for the benefits consolidation and unification, as in 'If only we had one X (where X can be a Desktop Environment, GUI toolkit, Editor, etc), every developer could focus their effort on that, innovation would be quicker and adoption of the OS would be better (and we would finally have "the year of the desktop").

It is a pretty idea, to boost productivity through standardisation, but by now decades of free OS development (and proprietary OS development, to illustrate the value of mono-cultures and cathedral planning) have shown it does not work.

As of now, SystemD adoption hinders the development of:

-alternative cgroup managers

-non-affiliated container development

-DE development on non-linux systems

-GNU running on alternative kernels

-adoption and development of alternative init systems

Now none of these directly affect the Desktop Experience, so many will not care. But standardisation is not necessarily a direct benefit, or even a net benefit from a larger--long-term--context, especially in the Free Software world.

I think you are missing the parent's point. By "kernel up" I think they mean that the kernel can stand alone without any other software. It's not very useful, but it does work. Then you add system executables (sh, ls, etc.) and the only thing they require is the kernel (and maybe each other). You keep adding more and more layers, each depending on the previous but not the next. The top of the stack is, as you say, what the user wants/needs and it is dependent on all of the previous layers.

The current situation with systemd is that this hierarchy is no longer valid and low level components are now relying on things above them in the stack. So much so that, for example, if the web browser stops working you have to reboot the computer because it hung a kernel process somewhere. That doesn't seem like a very good system to me.

But, in contrast, you cannot shut it down just fine without being really careful.

* http://unix.stackexchange.com/a/195978/5132

* http://unix.stackexchange.com/a/197472/5132

* http://askubuntu.com/a/638165/43344

> similar principles as Microsoft espoused for many years

A little bit more recent comparison of systemd and Red Hat strategy behind it would be Google with PlayServices - proprietary ball of mud, which render AOSP effectively useless for vast majority of users, and more and more of Android is moving there.

While the people you mention did say those things, I don't see how the contradicts Lennart's assertion. It is true that historically a Unix distribution did indeed consist of the tools, C library and kernel and that they we all released together in sync and were provided in one source archive[0]. To my mind, these ideas are not necessarily in conflict, one is about what comprises the entire product and the other guides design and implementation.

In my opinion, I don't think it's fair to characterize Microsoft's OS design principles as "integrated so tightly... that it becomes difficult to tease apart or to understand." It is true that Windows (NT) is pretty tightly integrated with it's own components, I would argue this is because the majority of it was written by Microsoft. Many of the commercial Unix products were also similarly integrated for much the same reason.

I'd argue that the only reason we see the modularization in Linux is because, historically, the modules were written by entirely different groups of people. As this changes and one group begins to control more and more components, it seems both natural and reasonable that they would integrate those components more tightly. Many of the Linux distributions appear to agree that this isn't necessarily a bad thing. Indeed, most Linux distributions are like the Unix distributions of old: they include the tools, C library, kernel and now a plethora of software.

[0]: https://en.wikipedia.org/wiki/Unix#Components

That Poettering quote is a frightening example of intellectual dishonesty. It's like a politician talking nonsense to legitimize the shit sandwich he's about to stuff into your face. Either that, or he has no clue what he's talking about. Both alternatives are really bad.

PAM behind the scenes seems fine, it's the interface that's clunky and prone to error.

Imagine a world where a PAM would come with a file /etc/systemd/system/sssd.pam which specified all of its dependencies, what services it should be installed in, and uses Before= and After= to determine its position.

Enabling SSS auth would be as simple as systemctl enable sssd.pam. And since sssd.pam would depend on sssd.service if sssd.service fails for some reason the pam module could be disabled to keep the junk out of your logs.

Not to nitpick, but I'm fairly certain that when using mount units, systemd is directly calling mount(2), eschewing use of mount(8).

edit: I also want to say until somewhat recently, systemd's mount units were just a wrapper around mount(8), but could be completely mistaken.

I care about systemd.

Thus all my personal infra is using variants of BSD fit for the purpose and I'm pushing for my next game launch to be on FreeBSD where POSIX/Unix is required.

Change is slow but it will happen if people can make convincing arguments against systemd to people who just want it to work and not break with the least amount of money.

Topics like this help my cause. It's not about grovelling it's about sending a message that "if you're going to try to be the alpha and the omega then we will hold you responsible when you fail to deliver"

Nobody asked them to do this, people fought against it. But here we are and they are absolutely responsible for the bugs they inflict on the world and their hostile attitudes towards other projects.

Actually there's more distributives without systemd, Gentoo is different because it just gives a choice - with systemd, udev, dbus or almost anything else.