Re: Let's have a vote!
On Sat, Sep 20, 2014 at 03:04:24PM +0200, lee wrote:
> 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.
Simpler for who, is the question you need to ask? Systemd gets rid of a
lot of boilerplate in initscripts. Instead of start(), stop(), restart()
functions which call start-stop-daemon and check for its return value
and maybe there's code in there to wait for the daemon to completely
stop before restarting and blah blah blah... In systemd, the
"initscript" is a simple declarative config file. You say "This is my
daemon process", "It needs to start once, say, all file systems are
mounted" and that's it. Systemd will take care of starting the daemon,
and of stopping it (AND any children it has spawned - think of apache's
worker processes) and of starting it at the right point in the boot
sequence (which may not be the same point every time if, for example,
the network starts a little slower today).
>
> > 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.
If you can understand start-stop-daemon, I'm sure systemd isn't much
harder.
>
> > 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.
Debian has it's own idiosyncrasies of sysvinit, so this is a point to
neither side.
>
> > 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?
You asked for advantages of systemd. The fact that you can transition to
it is an advantage. Would you prefer an init system that is technically
superior, yet entirely incompatible with sysvinit? Upstart was pipped at
the post mostly because of systemd's compatibility with sysvinit
scripts.
>
> >> 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?
Users DO get a vote. Every time you download an ISO for debian, that's a
vote. Every time you install a system as debian, that's a vote.
As has been mentioned several times on this list, the best way to get
systemd out of debian is to develop an init system that is technically
superior to systemd. Read the vote on systemd-as-default and see what
features won over the developers - keep those features in your new init.
Read the discussions here on debian-user and see what people don't like
about systemd - improve on those.
When your new init system is ready for show time, either submit it to
debian (if you'd like debian to lead the way) or create your own
distribution to showcase the init system. Let people see the ease with
which your new system tackles the problems of both sysvinit and systemd.
Let them play with it and marvel at the clean, robust code.
We look forward to the fruits of your efforts!
> >
> > 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.
>
>
> --
> To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
> Archive: [🔎] 87iokio33b.fsf@yun.yagibdah.de">https://lists.debian.org/[🔎] 87iokio33b.fsf@yun.yagibdah.de
>
Reply to: