Re: What is systemd
I find it very sad that the Gnome/desktop dependency on systemd is driven, ultimately, by ConsoleKit becoming "unmaintained". The correct answer to "ConsoleKit is unmaintained" was not "replace it with something else that does the same job but depends on systemd" but "remove support for it, it's not needed anyway".
ConsoleKit/logind's existence is basically motivated by the desire to support "multi-seat" systems - computers with multiple keyboard/mouse/monitor combinations connected to them used to support more than one user. That use-case is incredibly, incredibly niche. And yet it is dictating how basic components work to the detriment of simplicity in the vast, vast majority of common use cases. The same applies to its close cousin PolicyKit - it's simply not needed for the system to work properly unless you're in one of those very niche use-cases which the distros won't support out of the box anyway. The PolicyKit attitude in turn gets generalised into things like hostnamed, the very existence of which almost sounds like some kind of cosmic joke to me.
The ConsoleKit/PolicyKit mentality has been gradually infecting the (Debian packaging of) other desktop components outside of Gnome like lightdm and this is what has led to the creeping dependencies on systemd via, e.g. libpam-systemd and systemd-logind. What is badly missing is an option to simply go without ConsoleKit features and gracefully fall back to the older way of doing things (sudo and local groups giving access to hardware, with known and defined security trade-offs).
The worst part is that for all its sophistication, the *Kit software itself is very fragile and breaks in the slightest unusual configuration. For example, I recently set up a new Linux Mint install on a laptop to use my local Kerberos server for user authentication. It won't permit Kerberos-authenticated users logged in locally to suspend/resume or shutdown, despite them having logged in on the "right" terminal. Even more bizarrely, that includes suspending triggered by hardware events like a lid close on a laptop. At worst I would have expected changing the setting of what to do on lid close to be blocked by lack of permissions. But suspending itself? That is just stupid. And not even falling back to "sudo" (which it would have found those users have permission for) is also silly.