Re: MATE 1.8 has now fully arrived in Debian
Hi,
On 06/26/2014 14:33, Svante Signell wrote:
> On Thu, 2014-06-26 at 14:03 +0200, Jean-Christophe Dubacq wrote:
>> [ ⏰ 26/06/2014 12:05 ] [ ✎ Svante Signell ]
>>> On Thu, 2014-06-26 at 11:59 +0200, Ansgar Burchardt wrote:
>>>> On 06/26/2014 11:34, Thorsten Glaser wrote:
>>>>>> No, it didn't work. You had to be root for operations as simple as
>>>>>> shutting down the computer.
>>>>>
>>>>> Only on Debian. OpenBSD and MirBSD have:
>>>>>
>>>>> -r-sr-x--- 1 root operator 122716 Sep 10 2013 /sbin/shutdown*
>>>>>
>>>>> I never understood why Debian doesn't.
>>>>
>>>> Google says the operator group also has (read) access to raw disk devices.
>>>
>>> What about creating a unique group then, e.g. calling it it shutdown?
>>
>> So that students can do eg ssh mybuddymachine /sbin/shutdown ?
>
> Of course with the additional check that the students are logged in to
> that box locally, did I forget to mention that?
And for that you need to keep track of sessions via something like
systemd-logind, ConsoleKit, utmp or something else, whatever developers
decide to use. Mostly they seem to settle on systemd-logind.
So, we end with a system that works for both simple (single-user) and
more complex setups (multi-user, multi-seat).
The question then is: "I have a system that works for both simple and
complex setups. Should I implement (continue to maintain) a second
system that only works for simple setups?"
Some upstreams have decided that they have not the resources and
interest to maintain a second system; they end with a dependency on systemd.
Sometimes they keep code for the old system, but don't write code to
fallback to it at runtime. So one has to decide at build time which
system to support. Maintainers might choose to enable the system that
works both setups[1] -- again ending with a systemd dependency, but
still working on *BSD where the alternative (less capable) system in
chosen instead.
[1] It might be possible to build two alternative versions like done
with, for example, vim. But maintainers might choose not to do so
for the same reasons upstream -- not enough resources and lack of
interest of involved people.
So, if people care about support for mechanisms that don't rely on
systemd-logind and only support a subset of configurations, they need to
join upstream projects. Just stomping with your foot does not work: sign
up to maintain support for non-systemd setups and implement fallback
code from one system to another where needed instead.
> Another point is of course is that if you are locally connected to
> your/somebody else's computer nothing is hindering you from pushing the
> on/off button or pull the plug (except physically). Is shutting off a
> computer really a problem, normally multi-available ones are always on?
Shutting the system down is just one example: you can go on with access
to audio devices and USB ports (and connected media) in multi-seat
configurations and so on.
Ansgar
Reply to: