4 ms·

I have to disagree on the topic of systemd. A lot of what it does definitely needed changing — although systemd implements that change suboptimally. Take the

I have to disagree on the topic of systemd. A lot of what it does definitely needed changing — although systemd implements that change suboptimally. Take the logind concept: In the past, Linux screensavers were simply a fullscreen window in front of everything else. They crashed? Your system unlocked. With logind, you have one tiny separate daemon that spawns your original X session, and the screensaver. As long as the screensaver is active, that screensaver replaces the X sessions's display. If the screensaver crashes, it gets restarted, or, if that fails, you get in a lovely TTY font "open a tty, login as your user, and type loginctl session-unlock". And this is secure. If something fails, your session won't accidentally unlock. Other features include an IPC protocol that allows per-message security — user A can send messsage type 1, but user B can only send message type 2 (although, did that verification language have to be JS? T_T)

ComputerGuru 9y ago
That’s just bad design to begin with, replaced by a ln inefficient kitchen sink of a solution. Why should the screensaver be part of this megalith? Edit: to be clear, it’s not about the binary used to run the screensaver, it’s about the fact that it does not need to be a question of “all or nothing” and that a solution for this particular problem could have been adopted without replacing virtually every other component of the system services simultaneously.
- kuschku 9y ago
  As I wrote in the comment you replied to, the screensaver is NOT part of the init system, nor is logind part of the init system. logind is developed by systemd, but a separate binary. In fact, every systemd project is a separate binary, just developed by the same project. Systemd is as much a monolith as KDE is. Second, this tiny little logind binary is separate from the screensaver. It does not contain the screensaver, nor the lock screen, nor does it link to them. This tiny process spawns the session and screensaver, and simply switches between them based on a signal. It's the tiniest possible concept for handling this task. In general, I'd prefer if you could be more specific about your criticism, e.g. how this separate tiny binary is a "kitchen sink" and the screensaver, which is entirely separate from logind and systemd, is "part of a megalith".
  - hedora 9y ago
    Presumably, it is part of a “megalith” because now my screensaver depends on some crazy login manager, which depends on a crazy authenticated ipc scheme that loginctl uses, and probably none of this works if I replace systemd with something else, so it all depends on running some busted dns client with a recent history of remote exploits. So, instead of wrapping my screensaver in a small program that manages respawns on crash, you’ve arranged to force me to either have the screensaver unlock itself (since you ripped out the old simple wrapper), or have remotely exploitable network holes. [edit: source: https://www.jwz.org/xscreensaver/versus-xlock.html https://www.jwz.org/xscreensaver/versus-xlock.html ] Also, due to systemd, the some of the ioctls you need for rootless X are needlessly declared “root only”, so to call them, you have to launder the call through some authentication daemon that has its own (not Unix) security model, and runs as root. Finnally, I run this mess on a machine that is also an NFS client, and it frequently times out mid login / resume session, so you need to login like three times on a bad day because nfs takes a few seconds to stat something. It was even worse with systemd aware desktop environments. There, instead of timing out quickly, it would sometimes hang for minutes, with per-user copies of what appeared to he the whole systemd stack running, and no logs anywhere.
erikb 9y ago
This thread here is obviously the wrong place to roll out the systemd discussion again.
- kuschku 9y ago
  That's a good point, it's just sad to see people directly dismiss it. Systemd is a lot of good intentions and ideas, turned into bad code. AMP is one good idea (faster loading speeds) turned into not just bad code, but also lock-in and proprietary anticompetitive services. There's no black, or white, only Greys on Greys.
- tripzilch 9y ago
  Real happy with the "fold subthread" buttons on HN :) (if only they would auto-fold after a fixed number of children, like Reddit, I might script that for myself one day)
alkjhadgukdsg 9y ago
> If the screensaver crashes, it gets restarted, or, if that fails, you get in a lovely TTY font "open a tty, login as your user, and type loginctl session-unlock". This is really offtopic, but you seem to confuse KDE with systemd. There is a bit of KDE that tells you to use loginctl to tell KDE's display manager to unlock the session if KDE's screensaver doesn't work properly.
- kuschku 9y ago
  Sure, KDE implements that bit, but the important part is that logind makes it possible to implement that bit in the first place. Before logind, the alternative was custom handling and detection of screensavers in your session, or simply it crashing back to the session.
  - slgeorge 9y ago
    I find both your comments confusing. In your first comment you said that screensavers were just normal windows and would crash back to an unlocked screen - that never happened. Here you're conflating KDE (started ~1997) needing logind (started in what 2010?) which it didn't. Even your comment about a 'session' makes no sense since at the X runlevel X itself is the 'session'. In my opinion a lot of the problem has been a lack of clarity of what the actual user benefit will be, and the crazy borg-like scope expanion. I'm going to avoid commenting on the implementation of logind and brethren.
    - kuschku 9y ago
      I'm not conflating anything — lockscreens on X11 were always just normal windows. If they crash, they unlock. I suggest you read JWZ's On Toolkits page: (archive link due to referer shenanigans): http://archive.is/BjMfp http://archive.is/BjMfp
      - makomk 9y ago
        Yes you are. The trick that KDE uses is that the screen locking is done by the KDE session manager, and because that is the main process in the X session if it crashes the session terminates so it's not possible to bypass the screen locker that way. None of that requires systemd; it makes use of something that's been true under X11 pretty much forever. The only thing that changed with logind is that instead of trying to restart the password prompt if it crashes, KDE now pops up a message asking you to drop to a console and use logind to disable the screen locker. (Annoyingly, it does this even on systems that don't use logind, in which case the instructions don't actually work.)

ComputerGuru 9y ago

That’s just bad design to begin with, replaced by a ln inefficient kitchen sink of a solution. Why should the screensaver be part of this megalith? Edit: to be clear, it’s not about the binary used to run the screensaver, it’s about the fact that it does not need to be a question of “all or nothing” and that a solution for this particular problem could have been adopted without replacing virtually every other component of the system services simultaneously.

kuschku 9y ago
As I wrote in the comment you replied to, the screensaver is NOT part of the init system, nor is logind part of the init system. logind is developed by systemd, but a separate binary. In fact, every systemd project is a separate binary, just developed by the same project. Systemd is as much a monolith as KDE is. Second, this tiny little logind binary is separate from the screensaver. It does not contain the screensaver, nor the lock screen, nor does it link to them. This tiny process spawns the session and screensaver, and simply switches between them based on a signal. It's the tiniest possible concept for handling this task. In general, I'd prefer if you could be more specific about your criticism, e.g. how this separate tiny binary is a "kitchen sink" and the screensaver, which is entirely separate from logind and systemd, is "part of a megalith".
- hedora 9y ago
  Presumably, it is part of a “megalith” because now my screensaver depends on some crazy login manager, which depends on a crazy authenticated ipc scheme that loginctl uses, and probably none of this works if I replace systemd with something else, so it all depends on running some busted dns client with a recent history of remote exploits. So, instead of wrapping my screensaver in a small program that manages respawns on crash, you’ve arranged to force me to either have the screensaver unlock itself (since you ripped out the old simple wrapper), or have remotely exploitable network holes. [edit: source: https://www.jwz.org/xscreensaver/versus-xlock.html https://www.jwz.org/xscreensaver/versus-xlock.html ] Also, due to systemd, the some of the ioctls you need for rootless X are needlessly declared “root only”, so to call them, you have to launder the call through some authentication daemon that has its own (not Unix) security model, and runs as root. Finnally, I run this mess on a machine that is also an NFS client, and it frequently times out mid login / resume session, so you need to login like three times on a bad day because nfs takes a few seconds to stat something. It was even worse with systemd aware desktop environments. There, instead of timing out quickly, it would sometimes hang for minutes, with per-user copies of what appeared to he the whole systemd stack running, and no logs anywhere.

erikb 9y ago

This thread here is obviously the wrong place to roll out the systemd discussion again.

kuschku 9y ago
That's a good point, it's just sad to see people directly dismiss it. Systemd is a lot of good intentions and ideas, turned into bad code. AMP is one good idea (faster loading speeds) turned into not just bad code, but also lock-in and proprietary anticompetitive services. There's no black, or white, only Greys on Greys.
tripzilch 9y ago
Real happy with the "fold subthread" buttons on HN :) (if only they would auto-fold after a fixed number of children, like Reddit, I might script that for myself one day)

alkjhadgukdsg 9y ago

> If the screensaver crashes, it gets restarted, or, if that fails, you get in a lovely TTY font "open a tty, login as your user, and type loginctl session-unlock". This is really offtopic, but you seem to confuse KDE with systemd. There is a bit of KDE that tells you to use loginctl to tell KDE's display manager to unlock the session if KDE's screensaver doesn't work properly.

kuschku 9y ago
Sure, KDE implements that bit, but the important part is that logind makes it possible to implement that bit in the first place. Before logind, the alternative was custom handling and detection of screensavers in your session, or simply it crashing back to the session.
- slgeorge 9y ago
  I find both your comments confusing. In your first comment you said that screensavers were just normal windows and would crash back to an unlocked screen - that never happened. Here you're conflating KDE (started ~1997) needing logind (started in what 2010?) which it didn't. Even your comment about a 'session' makes no sense since at the X runlevel X itself is the 'session'. In my opinion a lot of the problem has been a lack of clarity of what the actual user benefit will be, and the crazy borg-like scope expanion. I'm going to avoid commenting on the implementation of logind and brethren.
  - kuschku 9y ago
    I'm not conflating anything — lockscreens on X11 were always just normal windows. If they crash, they unlock. I suggest you read JWZ's On Toolkits page: (archive link due to referer shenanigans): http://archive.is/BjMfp http://archive.is/BjMfp
    - makomk 9y ago
      Yes you are. The trick that KDE uses is that the screen locking is done by the KDE session manager, and because that is the main process in the X session if it crashes the session terminates so it's not possible to bypass the screen locker that way. None of that requires systemd; it makes use of something that's been true under X11 pretty much forever. The only thing that changed with logind is that instead of trying to restart the password prompt if it crashes, KDE now pops up a message asking you to drop to a console and use logind to disable the screen locker. (Annoyingly, it does this even on systems that don't use logind, in which case the instructions don't actually work.)