Re: Let's have a vote!
Sven Joachim <svenjoac@gmx.de> writes:
> On 2014-09-16 02:00 +0200, lee wrote:
>
>> And I'd also like to hear what advantages systemd actually brings about
>> that would make it desirable.
>
> https://wiki.debian.org/Debate/initsystem/systemd should get you started.
I've read that page. Where are the advantages?
> Systemd makes the boot process much simpler
No, it doesn't, it makes it cryptic, and makes simple things very
difficult to do.
> Systemd can handle the boot process from head to toe, without needing
> to use any of the existing shell scripts.
That's how systemd makes the boot process cryptic and non-debuggable.
> Systemd is straightforward.
No, it's very confusing and very convoluted, and there isn't even any
decent documentation. --- Later on, the page suggest that users read the
source code of systemd because there's documentation in the source.
Seriously ...
> Systemd unit files, unlike SysV scripts, can usually be shipped by
> upstream, or at least shared with other distributions (already more
> than 1000 existing unit files in Fedora) without any changes, the
> Debian specifics being handled by systemd itself.
So Debian even has its own version of systemd to make things more
complicated.
> Systemd is incredibly fast (1 second to boot).
Who cares. When I turn on my computer, it takes about 2 minutes before
grub loads, and it's totally irrelevant if booting from there takes a
second more or less. I reboot my server only when it's required due to
software updates, and it takes quite a long time before grub loads. I
reboot my computer only because it saves electricity when I turn it off
--- yet uptime is currently 14 days because I didn't turn it off
nonetheless. And if it's turned off, I turn it on and go make a coffee.
That leaves my computer about 8 minutes to boot after grub loads.
> The transition plan is easy, since existing init scripts are treated
> as first-class services: scripts can depend (using LSB headers) on
> units, units can depend on scripts. More than 99% of init scripts can
> be used without a modification.
What's easy about this, and why use systemd when the existing init
scripts are fine?
>> If there were so many people disagreeing that forcing systemd upon the
>> users, why aren't there any of them speaking up and explaining why
>> systemd is supposed to be such a great idea?
>
> Presumably because they have other, more important things to do (see
> above).
They might soon find out that they can't do these more important things
anymore because systemd gets in the way.
> Anyway, what is "forced" upon users is not systemd as PID 1 (aka
> systemd-sysv), but rather systemd-logind, shipped in the systemd
> package and usable together with sysvinit (or upstart) and
> systemd-shim.
I don't want any part of systemd. Already you can't even install gimp
without systemd anymore :(
But run gimp remotely, and it says it cannot connect to udev. It still
runs fine. So why would it depend on systemd? That's a broken
dependency.
> Here is another pointer as to why this is done:
>
> https://lists.debian.org/debian-devel/2014/06/msg00455.html
I admit that users logged in in different ways might be supposed to have
different permissions is a problem. Systemd doesn't solve this problem.
You can see that very easily on Fedora. Create a user A and log in as
this user. Create another user B to run software which, for security,
must not be able to access all the data of user A. As B, logged in
locally (like user A running 'su B') run the software which needs to
play sounds, and you will find out what B is totally unable to play any
sounds. You have no choice but to run the software as A, with access to
all of As data.
That just sucks. How do you fix this problem?
>> Shall we have a vote? AFAIK, there's nothing that would speak against
>> having one, in this very mailing list. Why not ask the users? Why
>> should only Debian developers be allowed to vote but not the users?
>
> Because the people who do the work get to make the decisions, that's the
> way Debian works.
That would mean that the users are not a priority in Debian, which
contradicts Debians' social contract.
--
Knowledge is volatile and fluid. Software is power.
Reply to: