Re: DE features dependent on Systemd

[Ivan Shmakov <ivan@siamics.net>]

>>>>> Vincent Bernat <bernat@debian.org> writes:
>>>>> ❦ 30 novembre 2014 10:10 GMT, Ivan Shmakov <ivan@siamics.net> :

[…]

 >> Or does the above concerns the users of “normally battery-powered”
 >> devices instead?

 > Previously, every DE would need to reimplement power management.
 > Now, this is handled by systemd (and hence not by the DE anymore).
 > Without any special configuration, closing the lid of a laptop will
 > put it to sleep except if there is still an active user on an
 > external display.

	Just to be clear: I do not use any laptops myself.  (Or anything
	else I’d need to put to sleep by closing its lid, for that
	matter.)

	I guess this means that this particular feature is of no use to
	me, right?  (And, as a consequence, that I may safely ignore it
	when deciding if I should retain my current init.)

[…]

 >>> Indirectly through PolicyKit: lots of functionality will be missing
 >>> if PolicyKit doesn’t have access to a console management interface.

 >> Specifically?

 > PolicyKit rely on logind to know if a user is locally connected.  A
 > non-local user won't be allowed things like network management, local
 > device mounting or sound card access.

	That looks like a problem to solve, not a feature.

	For home installs, I see no reason for the owner of the device
	to be /denied/ access to the sound card just because of using
	SSH.  Why, it’s exactly what I do.  (I even did things like
	$ ssh remote ogg123 /dev/stdin < local/file.ogg for various
	reasons in the past.)

	OTOH, for “workplace” installs, I see no reason for the user to
	be /granted/ access to the things like network management just
	because he or she happens to be logged in locally, – these
	privileges should rather be granted only to the person(s)
	responsible for that particular host.  (And then again, – SSH is
	a perfectly valid way to access to these facilities.)

	IIRC, D-I used to add the first non-root user it creates (which
	more or less is bound to happen to be the owner, or the person
	otherwise responsible for the host) to a number of groups (like
	audio or plugdev) to grant access to certain devices.  I know of
	no reason to abandon this practice.

	I agree that the issue gets trickier for multiuser hosts, but
	I’m pretty sure that there still will be at least one user for
	whom no such access restrictions should apply, – irrespective of
	his or her “login locality.”

-- 
FSF associate member #7257  http://boycottsystemd.org/  … 3013 B6A0 230E 334A