UNIX, BSD, Linux og SystemD

No Comments

Dette indlæg handler om et startsystem til Linux som hedder SystemD, men inden jeg dykker ned i detaljerne omkring systemet, vil jeg gerne gennemgå lidt baggrund.

Et styresystems startsystem kaldes traditionelt for init, som er den engelske forkortelse for initializing. Løst oversat betyder det klargørelse, og det er præcis hvad init gør; klargører systemet til brug, ved at starte de programmer op, som skal bruges af styresystemet og brugeren. Det gør i sagens natur init til et vigtigt program, for går det ned eller laver fejl, så stopper computeren med at fungere. Den init jeg referer til i den her artikel er SysVinit, som bygger på software fra 1983.

Den anden del af baggrunden handler om historie. Det første egentlige styresystem der blev lavet var UNIX i '50erne. I '70erne blev *BSD-systemerne lavet med UNIX som forbillede med en fri licens, så skoler osv. også havde adgang til styresystemer, uden at skulle bryde loven, hvis de ville vise elever hvordan software virker. Desuden var UNIX meget dyr i licens. 20 år senere (igen) kom Linux så til, også inspireret af UNIX, men ikke helt så meget som *BSD. Forskellen imellem de 3 systemer er begrænset, hvor man meget groft kan sige, at UNIX er et kommercielt system sammen med Windows' og Apples, og *BSD'erne og Linux er frie systemer med åben kildekode, som kan bruges uden at de skal købes. *BSD dækker over FreeBSD, OpenBSD, NetBSD og PC-BSD, men de bygger grundlæggende set på det samme system. Linux dækker over et system som bruger Linux-kernen, og er fx distributioner som Debian (og afledte som Ubuntu og Mint), Gentoo og Fedora. Ligesom med *BSD er forskellen imellem Linux distributioner ikke ret stor.

Forskellen imellem forskellige Linux' kommer fra de programmer de bruger, og fx har Ubuntu i nogle år brugt Upstart fremfor init. Mere synlige forskelle er ofte hvilken type skrivebord en Linux bruger, og der har Debian længe brugt GNOME. Personligt stoppede jeg med at bruge GNOME da Debian 7 kom med GNOME3, men rigtig mange kan godt lide det nye GNOME3. Et skrivebord som GNOME har en login-manager, hvis opgave det er at kunne logge brugere grafisk ind på skrivebordet, og det bruger sessionshåndtering til den opgave. Tidligere brugte GNOME3 sin egen sessionshåndtering, men begyndte at bruge SystemD's for at spare på koden og dermed arbejdet.

Med andre ord, så virker GNOME3 ikke længere uden SystemD. Beslutningen er taget af den ene vedligeholder hos GNOME, som står for sessionshåndtering, og det er forståeligt at han eller hun gerne vil lette sit frivillige bidrag til GNOME. Bemærk at GNOME er et selvstændigt projekt, og er vel indenfor deres rammer til at forlange afhængigheder som SystemD. Der findes et mindre hav af forskellige skriveborde til UNIX, *BSD og Linux, så problemet er ikke større, end at man kan prøve noget nyt.

Det betyder så igen, at Debian fra version 8 ikke længere bruger den traditionelle init som startsystem (på trods af heftig modstand blandt Debians brugere), men skifter til SystemD for fortsat at kunne tilbyde GNOME3 til sine brugere. Det gjorde mig i sagens natur nysgerrig omkring SystemD, ikke mindst fordi projektet jævnligt har været i modvind. Først besøgte jeg deres hjemmeside, og måtte se mig belært allerede på deres forside:

"Yes, it is written systemd, not system D or System D, or even SystemD. And it isn't system d either. Why? Because it's a system daemon, and under Unix/Linux those are in lower case, and get suffixed with a lower case d. And since systemd manages the system, it's called systemd. It's that simple."

Så sagt på godt dansk, så skriver jeg SystemD forkert, og det skal jeg stoppe med. At der også er tradition for at referer til et projekt som SystemD sådan som jeg gør det, ser man åbenbart bort fra. Fx er init's projektnavn jo SysVinit, men når man snakker om programmet, er det bare init. På samme måde er SystemD projektet, og systemd programmet, når jeg skriver om det. Men nej, her må jeg altså se mig belært. Og hvorfor er det overhovedet så vigtigt for dem, at de skriver det på deres forside? Det virker sgu' lidt småligt, for at være ærlig.

Inden jeg fortsætter, skal jeg selvfølgelig huske at nævne, at Debian understøtter adskillige startsystemer, og at init stadig kan bruges fra version 8, ligesom at SystemD har kunne bruges i årevis. Min bekymring i den sammenhæng er dels, at kun det startsystem som er standard bliver vedligeholdt ordentligt, og dels at flere og flere programmer begynder at kræve SystemD for at fungere.

Efter en kort søgning på Google om SystemD, faldt jeg over denne fejlrapport (se fuldt transskript i bunden).

Essensen er, at SystemD reagerer på en kommando, som traditionelt tilhører Linux. Brugen af kommandoen får Linux til at skrive på skærmen hvad den gør under opstart (så (start)problemer kan findes og løses), men SystemD gør altså det samme, og skriver i bedste fald så meget til skærmen, at det bliver endog meget svært at se hvad Linux laver. I værste fald går systemet ned. Den ene af vedligeholdene på SystemD lukkede fejlrapporten næsten med det samme, og nægtede at gøre noget ved det eller kigge på det, da det ikke er deres problem. Linux må jo bare ændre adfærd.

Så gruppe A har i 20 år gjort tingende på deres måde, men når gruppe B kommer til med deres program, så må gruppe A da bare lave om på tingende, så de passer med gruppe B's. Min mening om SystemD begyndte så småt at dale, men alle har vel dårlige dage.

Lig her mærke til, at jeg stadig kun skriver SystemD; SystemD består af 50 programmer udover systemd. Deriblandt er der et nyt program til at skrive logfiler med, da SystemD bruger et ikke-standard binært format, en ny dbus (står for kommunikation imellem programmer) og andre programmer, som ikke vedrører init. Se evt. Wikipedia for detaljer.

Det er ellers en tommelfingerregel, at man designer sine programmer til kun at løse én opgave, men så også at løse den godt. Strengt taget er SystemD's programmer selvstændige, og kan bruges enkeltvis, men hvorfor SystemD overhovedet vil løse 51 opgaver, er udover min fatteevne. Jeg fortsatte søgningen på Google, og fandt en e-mail fra Linus Thorvalds, Linux' designer og chefvedligeholder. Det følgende er svar på den problemtik jeg beskrev tidligere, hvor Linux bare må ændre adfærd

"Key, I'm f*cking tired of the fact that you don't fix problems in the
code *you* write, so that the kernel then has to work around the
problems you cause.

Greg - just for your information, I will *not* be merging any code
from Kay into the kernel until this constant pattern is fixed."

Key er udvikler og vedligeholder hos SystemD, og at Linus ikke vil "be merging" mere fra ham, betyder at han ikke længere kan tilføje SystemD-relevant kode til Linux.

OK, så helt fra brugerne til bidragerne er der knas i hjulene. Med udsigten til at skulle skifte fra Debian til *BSD, fortsatte jeg min søgning på Google, i håbet om at det kunne forebygges. Desværre fandt jeg følgende blogindlæg fra en af chefudviklerne hos SystemD (fuldt transskript i bunden)

"It's a sad day for the Linux ecosystem. But it makes things a lot easier for us, since we can give up on any considerations of making it easy to them and keeping their way into the systemd world open."

Hvad han kommenterer på, er Ubuntus beslutning om at beholde Upstart. Noget Ubuntu iøvrigt gav op på, da Debian annoncerede et skift til SystemD. Faktisk ved jeg dårligt hvor jeg skal starte, for den ene sætning fra Lennart viser en foragt overfor folk, som gerne vil gøre tingende anderledes end ham. Han skriver lodret op, at hvis ikke Ubuntu kommer ind i folden nu, så straffer han dem ved at besværliggøre det senere.

Men lad mig slå én ting fast med syvtommersøm: Dødstrusler og chikane imod manden er forkert. Han er muligvis selvfed og uegnet som udvikler, men derfor kan man godt holde en civiliseret tone, også selvom han gør det svært. Flere vedligeholdere hos Debian har trådt ned fra deres stillinger, fordi de blev fanget i stormen, og det er heller ikke i orden.

Så hvad der for mig startede som en svag nysgerrighed over en ny init, er blevet til at jeg i dag skriver fra en maskine med PC-BSD installeret, for jeg vil ikke bruge SystemD. Grunden skal findes i holdningen fra SystemD, for hvilken slags kode skriver den slags folk? Desuden syntes jeg ikke at SysVinit fejler noget, og vil foretrække at holde fast i en simpel og gennemprøvet init. Ej heller vil jeg bruge Debian, når der ikke bliver lyttet til brugerne. Og tænk sig, det hele startede da én udvikler hos GNOME satte SystemD som afhængighed.

Afslutningsvis vil jeg gerne kort kommentere på ting, som jeg har hørt om SystemD, men som jeg ikke syntes giver meget mening. Bemærk at disse ting er min egen mening, og er baseret på hvordan jeg bruger en computer.

Fx hører man meget ofte, at en computer har brug for at starte hurtigt, og dermed brug for at kunne starte programmer sideløbende. Men når jeg tænder en computer, er det meget sjældent for under 12 timer, så om den er 10, 20 eller 30 sekunder om at starte er ligegyldigt. Kigger vi i stedet på servere med flere månedes oppetider, bliver argumentet direkte latterligt.

Desuden giver sideløbende opstart af programmer en øget kompleksitet i startprocessen, hvilket bør undgås næsten lige meget hvad.

Jeg har også tit hørt, at init-baseret startsystemer er forældet, dog uden nogen tilhørende argumenter.

I det hele taget har det været en trist affære at læse op på SystemD, ikke mindst som følge af den hårde tone og mangel på saglighed. Jeg ser dog frem til at lære PC-BSD at kende, ikke mindst i kraft af deres ports collection og ZFS.

\\

Fuldt transscript af https://bugs.freedesktop.org/show_bug.cgi?id=76935

Bugzilla – Bug 76935
Do not parse "debug" command line parameter

Summary: Do not parse "debug" command line parameter
Status: RESOLVED FIXED
Product: systemd
Component: general
Version: unspecified
Hardware: Other All
Importance: medium normal
Assigned To: systemd-bugs
QA Contact: systemd-bugs
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:

Reported: 2014-04-02 08:57 UTC by Borislav Petkov
Modified: 2014-05-24 08:38 UTC (History)
CC List: 17 users

Description Borislav Petkov 2014-04-02 08:57:16 UTC

Supplying "debug" on the kernel command line gets parsed by systemd. If
a random assertion in it fires, something like this, for example:

[ 150.308000] systemd-journald[1559]: Assertion 'dual_timestamp_is_set(&e->timestamp)' failed at src/libsystemd/sd-event/sd-event.c:2191, function sd_event_get_now_monotonic(). Ignoring.
[ 150.308000] systemd-journald[1559]: Assertion 'dual_timestamp_is_set(&e->timestamp)' failed at src/libsystemd/sd-event/sd-event.c:2191, function sd_event_get_now_monotonic(). Ignoring.

it floods dmesg and I cannot log into the machine anymore. I have to
reboot and remove "debug" from the command line so that the machine can
boot. BUT(!), I want to see kernel debug messages so I have to be able
to supply "debug" *without* systemd interfering.

What it should do, instead, is *not* parse "debug" but something else
with a namespace, i.e. "systemd.debug" or whatever as "debug" is a
kernel cmdline parameter and not aimed for systemd.

And while we're at it, we'd need a configurable option to tell systemd
*not* to log to dmesg for when one wants to see only output from the
kernel in the kernel ring buffer, i.e. something like "systemd.nodmesg"
or so.

Thanks.

Comment 1 Borislav Petkov 2014-04-02 09:51:59 UTC

Ok, I'm being told "systemd.log_target=null" takes care of the second part of the issue.

Comment 2 Kay Sievers 2014-04-02 10:19:54 UTC

(In reply to comment #0)
> Supplying "debug" on the kernel command line gets parsed by systemd. If
> a random assertion in it fires
> it floods dmesg and I cannot log into the machine anymore.I have to
> reboot and remove "debug" from the command line so that the machine can
> boot. BUT(!)

That is the expected current behaviour, "debug" can cause "too many" messages to be useful anymore if things are broken.

> I want to see kernel debug messages so I have to be able
> to supply "debug" *without* systemd interfering.

Then use the kernels loglevel= parameter for the kernel only, not affecting Base OS tools.

> What it should do, instead, is *not* parse "debug" but something else
> with a namespace, i.e. "systemd.debug" or whatever as "debug" is a
> kernel cmdline parameter and not aimed for systemd.

The generic term "debug" is read by Base OS tools too.

> And while we're at it, we'd need a configurable option to tell systemd
> *not* to log to dmesg for when one wants to see only output from the
> kernel in the kernel ring buffer, i.e. something like "systemd.nodmesg"
> or so.

Like for the kernel, there are options to fin-grain control systemd's logging behaviour; just do not use the generic term "debug" which is a convenience shortcut for the kernel AND the Base OS.

Comment 3 Borislav Petkov 2014-04-02 10:39:29 UTC

(In reply to comment #2)
> Then use the kernels loglevel= parameter for the kernel only, not
> affecting Base OS tools.

Actually, I'd like to continue using "debug" - a workflow a lot of
kernel people have been doing for years - without anything interfering,
systemd including.

> The generic term "debug" is read by Base OS tools too.

... which was wrong to begin with, without a namespace prefix.

> Like for the kernel, there are options to fin-grain control systemd's
> logging behaviour; just do not use the generic term "debug" which is a
> convenience shortcut for the kernel AND the Base OS.

And yet, it was working exactly as expected until now.

Is there any other way to tone down systemd logging as much as possible
without having to supply "systemd.log_target=null" on the command line
of each box I'm booting? I'm guessing you're going to say to go edit
/etc/systemd/system.conf each time I'm booting the box for the first
time...

Thanks.

Comment 4 Kay Sievers 2014-04-02 12:06:39 UTC

(In reply to comment #3)
> > The generic term "debug" is read by Base OS tools too.
>
> ... which was wrong to begin with, without a namespace prefix.

Which we do not agree. Generic terms are generic, not the first user
owns them.

> Is there any other way to tone down systemd logging as much as possible
> without having to supply "systemd.log_target=null" on the command line
> of each box I'm booting? I'm guessing you're going to say to go edit
> /etc/systemd/system.conf each time I'm booting the box for the first
> time...

Systemd does not "log" to the console, or to the kernel by default.

If it is about the console status output, use "quiet", just like it disables
the kernel boot log.

Comment 5 Borislav Petkov 2014-04-02 13:18:13 UTC

(In reply to comment #4)
> Which we do not agree. Generic terms are generic, not the first user
> owns them.

Right, and breaking existing use cases by hijacking generic terms is
also ok. I was right to be very skeptical when considering opening a bug
here.

> If it is about the console status output, use "quiet", just like it
> disables the kernel boot log.

No, I want to say "debug" on the kernel command line and *not* see
systemd output at all but kernel output only. Is this possible?

Thanks.

Comment 6 Mel Gorman 2014-04-02 13:29:01 UTC

(In reply to comment #4)
> (In reply to comment #3)
> > > The generic term "debug" is read by Base OS tools too.
> >
> > ... which was wrong to begin with, without a namespace prefix.
>
> Which we do not agree. Generic terms are generic, not the first user
> owns them.
>

Come on Kai. The kernel is the primary user of its own command line and has a reasonable expectation that it's the default namespace for parameters. In cases where that is not true (such as modules), the parameter get prefixed by the name of the module affected like i915.foo. There may be base utils that parse the command line (they really shouldn't) but even if they do, their reaction should not be to scribble all over the kernel log.

systemds default debug behaviour should not be to hijack the kernel log. I can see cases where you want to do that if you need the output from a serial console but that should be explicitly stated with a systemd.log_target.

Comment 7 Kay Sievers 2014-04-02 14:08:07 UTC

Bugzilla is not a discussion forum, and repeating the same

Comment 8 Jiri Slaby 2014-04-02 14:09:17 UTC

(In reply to comment #7)
> Bugzilla is not a discussion forum, and repeating the same

So do not discuss and bring arguments.

Comment 9 Mel Gorman 2014-04-02 14:18:12 UTC

(In reply to comment #7)
> Bugzilla is not a discussion forum, and repeating the same

Ok, the bug is that a *kernel* parameter compels a *userspace* program to trash the *kernels* log with enough information to break boot due to timeouts.

Comment 10 Kay Sievers 2014-04-02 14:21:00 UTC

(In reply to comment #9)
> (In reply to comment #7)
> > Bugzilla is not a discussion forum ...

Again, move discussions to the mailing list; this is a bug tracker, but
there is no bug to track or fix here.

Comment 11 Borislav Petkov 2014-04-02 14:40:50 UTC

(In reply to comment #10)
> Again, move discussions to the mailing list; this is a bug tracker,
> but there is no bug to track or fix here.

Dude, are you for real? Are you actually actively trying to be a d*ck or
you're this way by default. We're telling you there's a serious issue
and we're even being constructive by giving suggestions and you're
deflecting.

You have got to be f*cking kidding me!

Comment 12 Steven Rostedt 2014-04-02 14:58:30 UTC

Hmm, a user adds to the *kernel* command line "debug" and systemd starts spitting out so much crap that the system doesn't boot anymore? That sounds like a major regression to me. Note this is a kernel command line, not a systemd command line. Userspace tools should not be using the same kernel parameters that are defined by the kernel. That's just broken and wrong.

This bugzilla is the poster child of why people hate systemd and do not trust the developers that work on it.

Comment 13 H. Peter Anvin 2014-04-02 15:45:35 UTC

This is utterly ridiculous, and it matches what I have observed that the system becomes undebuggable on a dracut/systemd system. There are a lot of things I genuinely like about systemd, but this aspect is a disaster.

Comment 14 Luis R. Rodriguez 2014-04-02 21:17:15 UTC

I believe this report deserves a little bit more serious architectural discussion and consideration than what it has been given.

2014-04-02 08:57 UTC - reported
2014-04-02 10:19 UTC - bug closed with a not a bug resolution

While for systemd it may make sense to parse debug the kernel has been using it for ages. Even still, for system it may make sense but interpreting it this way means we may run into other generic namespace kernel parameters and the expectations seems to be to close all of those issues as a non bug.

This seems rather unreasonable given we can't realistically expect to allow all userspace application to take on over the kernel ring buffer interpreting the generic namespace as they see fit. If anything they should honor the kernel for the generic namespace and since systemd is the new application and it is very conscientiousness about namespaces it can provide its own.

Comment 15 vajorie 2014-04-04 02:12:33 UTC

just an fyi, comment by torvalds at http://lkml.iu.edu/hypermail/linux/kernel/1404.0/01331.html

Comment 16 Anonymous Helper 2014-04-05 15:23:50 UTC

(In reply to comment #10)
> (In reply to comment #9)
> > (In reply to comment #7)
> > > Bugzilla is not a discussion forum ...
>
> Again, move discussions to the mailing list; this is a bug tracker, but
> there is no bug to track or fix here.

If the system is broken or otherwise not performing properly, then enabling debug is the way to determine the cause. If enabling debug breaks the system, then that is a bug by definition.

In this case, I'm inclined to state that the very existence of systemd is a big.

Kay, Please go die in a fire along with Lennart. Your type is the cancer that is killing any semblence of usability Linux once had.

Comment 17 Zbigniew Jedrzejewski-Szmek 2014-04-05 17:51:25 UTC

(In reply to comment #0)
> Supplying "debug" on the kernel command line gets parsed by systemd. If
> a random assertion in it fires, something like this, for example:
>
> [ 150.308000] systemd-journald[1559]: Assertion
> 'dual_timestamp_is_set(&e->timestamp)' failed at
> src/libsystemd/sd-event/sd-event.c:2191, function
> sd_event_get_now_monotonic(). Ignoring.
> [ 150.308000] systemd-journald[1559]: Assertion
> 'dual_timestamp_is_set(&e->timestamp)' failed at
> src/libsystemd/sd-event/sd-event.c:2191, function
> sd_event_get_now_monotonic(). Ignoring.
>
> it floods dmesg and I cannot log into the machine anymore. I have to
> reboot and remove "debug" from the command line so that the machine can
> boot. BUT(!), I want to see kernel debug messages so I have to be able
> to supply "debug" *without* systemd interfering.
Yep, this looks like a bug, and the assertion should be fixed. If this is still occuring, can you file a new bug specifying what systemd version you are using, or post to the mailing list?

> What it should do, instead, is *not* parse "debug" but something else
> with a namespace, i.e. "systemd.debug" or whatever as "debug" is a
> kernel cmdline parameter and not aimed for systemd.
Yes, systemd.log_level is that.

> And while we're at it, we'd need a configurable option to tell systemd
> *not* to log to dmesg for when one wants to see only output from the
> kernel in the kernel ring buffer, i.e. something like "systemd.nodmesg"
> or so.
Yes, use loglevel=, and or just systemd.log_level=.

(In reply to comment #5)
> No, I want to say "debug" on the kernel command line and *not* see
> systemd output at all but kernel output only. Is this possible?
Yes, use 'loglevel=...'. Or .debug systemd.log_target=...., or .debug systemd.log_level=...'.

As has been said, plain 'debug' turns more than just the kernel debugging, and this is extremely useful for general boot problems, where it is not clear what is a bug in the kernel, and what is a but in systemd, or plymouth, or elsewhere.
Available options are listed in http://www.freedesktop.org/software/systemd/man/systemd.html#Kernel%20Command%20Line. If a combination of options which implements the functionality you need is not available, please holler.

Comment 18 Anonymous Helper 2014-04-05 21:32:10 UTC

(In reply to comment #17)
> (In reply to comment #0)
>
> > What it should do, instead, is *not* parse "debug" but something else
> > with a namespace, i.e. "systemd.debug" or whatever as "debug" is a
> > kernel cmdline parameter and not aimed for systemd.
> Yes, systemd.log_level is that.
>
No, systemd.log_level is NOT that. If it were, then adding debug to the KERNEL's command line would not have resulting in systemd spamming the kernel to death. Systemd should be looking only at parameters that are in its namespace. If it already looks at systemd.log_level, then it should definitely NOT be looking at debug as that is redundant to the log_level parameter specifically for it, which can be used to turn up the logging to whatever level of insanity is desired.

Comment 19 Zbigniew Jedrzejewski-Szmek 2014-04-05 21:40:46 UTC

(In reply to comment #18)
Get a non-anonymous account if you want to post.

Comment 20 Jiri Slaby 2014-04-05 22:20:35 UTC

(In reply to comment #19)
> Get a non-anonymous account if you want to post.

Give technical arguments if you want to post.

Do we have a commit SHA already, so that we can actually close this?

Comment 21 Alexandre Scheifer 2014-04-06 04:02:24 UTC

I'm very disappointed with the attitude of the systemd developers.

They clearly don't care about systemd, let alone Linux.

I strongly believe systemd should be forked to avoid dealing with these bad developers, or the distributions that are adopting systemd should reconsider adopting this project.

Comment 22 David Strauss 2014-04-06 06:24:31 UTC

There seems to be quite a lot of misunderstanding here. systemd has used "debug" to set its own level to debug for quite some time, at least v208, which is from mid-2013.

The issue causing the acute pain was an broken assertion, a bug that should have been fixed before the thread on LKML even started. No one claimed that assertion failure wasn't a bug, and no one hesitated to fix it (see comment #17). So, "debug" should already be usable without also setting systemd.log_level, which should have fully worked around the issue even with the assertion bug.

In short, if everything was fine for you as of weeks or months ago, it should already be back to being fine.

The question now is the semantics of the kernel command line, specifically the scope which "debug" affects. I've personally given the +1 to Greg's patch, which would switch it to "systemd.debug", but there isn't consensus to do that.

The primary argument against the namespacing is catering to end users trying to troubleshoot who are unfamiliar with the kernel/udev/systemd split of responsibilities. Obviously, the counter-argument is to namespace in order to fully isolate systemd's debug mode from the kernel's (without requiring systemd.log_level) and avoid a similar assertion bug affecting developers the same way.

Because this is now a discussion about what *intended* functionality should be, most discussion is happening on the mailing list in the thread started by Greg's patch. I encourage you to post there if you would like to contribute. If you're merely going to flame, especially in a way showing that you don't understand the assertion fix vs. debug option distinction, then please find somewhere else to post outside of systemd Bugzilla and the mailing list.

Comment 23 Alexandre Scheifer 2014-04-06 08:09:14 UTC

Lennart Poettering and Kay Sievers: worst developers of the FOSS community.

Comment 24 Alexandre Scheifer 2014-04-06 08:58:09 UTC

Systemd needs to be forked NOW.

Linus explained it well already:

Kay and Lennart: please just go away, disappear from the FOSS community, we don't need you and your crap.

Comment 25 Alexandre Scheifer 2014-04-06 09:08:11 UTC

03:20:36 Is there any way to block/ban problem users from Bugzilla?

Douchebag.

The systemd developers are not just idiots who can't code, but also dictators who want to censor what people say about their shitty project.

systemd is the worst thing that ever have happened to Linux and FOSS.

Fork now and fix it, boycott their idiot developers.

Comment 26 Anonymous Helper 2014-04-06 13:21:26 UTC

(In reply to comment #25)
> 03:20:36 Is there any way to block/ban problem users from
> Bugzilla?
>
> Douchebag.
>
> The systemd developers are not just idiots who can't code, but also
> dictators who want to censor what people say about their shitty project.
>
> systemd is the worst thing that ever have happened to Linux and FOSS.
>
> Fork now and fix it, boycott their idiot developers.

Why fork it? There is no part of systemd that is worthwhile. It would be better to start fresh, but there is no need. There are already numerous sane alternatives. OpenRC and Upstart are two that come to mind that are ready to go, in use by major distros, and not braindamaged. They are not the only alternatives.

The real problem is systemd specific crap getting pushed into other project (e.g. Xorg). That propagation of systemd dependency is a malicious action which harms not only other distros which have chosen not to use systemd, but also completely other OSes which also use that code (*BSD, Solaris/illumOS, OS X, etc).

If it was mere bad behavior of the systemd developers, the clueful distros could avoid this mess of a project and clueful users could avoid the distros foolish enough to use this crap. It is the forced dependency that is the most malicious act of the systemd developers. Hopefully the FOSS community will wake up and eject these fucktards.

Comment 27 Anonymous Helper 2014-04-06 13:24:20 UTC

(In reply to comment #22)
> There seems to be quite a lot of misunderstanding here. systemd has used
> "debug" to set its own level to debug for quite some time, at least v208,
> which is from mid-2013.
>
> The issue causing the acute pain was an broken assertion, a bug that should
> have been fixed before the thread on LKML even started. No one claimed that
> assertion failure wasn't a bug, and no one hesitated to fix it (see comment
> #17). So, "debug" should already be usable without also setting
> systemd.log_level, which should have fully worked around the issue even with
> the assertion bug.
>
> In short, if everything was fine for you as of weeks or months ago, it
> should already be back to being fine.
>
> The question now is the semantics of the kernel command line, specifically
> the scope which "debug" affects. I've personally given the +1 to Greg's
> patch, which would switch it to "systemd.debug", but there isn't consensus
> to do that.
>
> The primary argument against the namespacing is catering to end users trying
> to troubleshoot who are unfamiliar with the kernel/udev/systemd split of
> responsibilities. Obviously, the counter-argument is to namespace in order
> to fully isolate systemd's debug mode from the kernel's (without requiring
> systemd.log_level) and avoid a similar assertion bug affecting developers
> the same way.
>
> Because this is now a discussion about what *intended* functionality should
> be, most discussion is happening on the mailing list in the thread started
> by Greg's patch. I encourage you to post there if you would like to
> contribute. If you're merely going to flame, especially in a way showing
> that you don't understand the assertion fix vs. debug option distinction,
> then please find somewhere else to post outside of systemd Bugzilla and the
> mailing list.

Thank you for being sane and stating the true situation clearly. As has been said on LKML, if Kay wasn't being a dick and had merely stated the broken assertion was a known and resolved issue, there would not have been any problem. It was the attitude in his response that has made so many in the community finally stand up and tell Kay (and Lennart) to simply fuck off for good.

Comment 28 David Strauss 2014-04-06 17:27:27 UTC

(In reply to comment #25)
> 03:20:36 Is there any way to block/ban problem users from
> Bugzilla?
>
> Douchebag.
>
> The systemd developers are not just idiots who can't code, but also
> dictators who want to censor what people say about their shitty project.
>
> systemd is the worst thing that ever have happened to Linux and FOSS.
>
> Fork now and fix it, boycott their idiot developers.

Censorship is preventing people from saying what they want to say, regardless of place or a government preventing publication of something. We haven't done that at all. Please find your own place to post what you want to say; there are plenty. Calling to shun some people entirely is also rather more hostile than trying to keep things on-topic and free of personal attacks in a bug tracker.

And that's where you are: a systemd bug tracker, in an issue discussing using the use of the "debug" option by the kernel and systemd (and implications thereof, like the assert issue spilling over). Your last few posts have been empty of anything but insults and calls to fork. It's a waste of my time as a systemd maintainer to come back to Bugzilla repeatedly and only see another flame post from you.

I don't know where you learned this behavior, but it's not productive here. It's also rather "pot calling the kettle black" to keep posting off-topic flames to a bug tracker about why you think some of our developers are bad for the FOSS community.

Seriously, find somewhere else to vent.

Comment 29 Alexandre Scheifer 2014-04-06 23:51:02 UTC

(In reply to comment #28)
> (In reply to comment #25)
> > 03:20:36 Is there any way to block/ban problem users from
> > Bugzilla?
> >
> > Douchebag.
> >
> > The systemd developers are not just idiots who can't code, but also
> > dictators who want to censor what people say about their shitty project.
> >
> > systemd is the worst thing that ever have happened to Linux and FOSS.
> >
> > Fork now and fix it, boycott their idiot developers.
>
> Censorship is preventing people from saying what they want to say,
> regardless of place or a government preventing publication of something. We
> haven't done that at all. Please find your own place to post what you want
> to say; there are plenty. Calling to shun some people entirely is also
> rather more hostile than trying to keep things on-topic and free of personal
> attacks in a bug tracker.
>
> And that's where you are: a systemd bug tracker, in an issue discussing
> using the use of the "debug" option by the kernel and systemd (and
> implications thereof, like the assert issue spilling over). Your last few
> posts have been empty of anything but insults and calls to fork. It's a
> waste of my time as a systemd maintainer to come back to Bugzilla repeatedly
> and only see another flame post from you.
>
> I don't know where you learned this behavior, but it's not productive here.
> It's also rather "pot calling the kettle black" to keep posting off-topic
> flames to a bug tracker about why you think some of our developers are bad
> for the FOSS community.
>
> Seriously, find somewhere else to vent.

OK I'm sorry about that, I actually like systemd and I shouldn't have insulted anyone, I'm very sorry about that, I deeply regret and apologize.

I'm just sad about what have happened with all this problem between systemd and the kernel and especially about Kay Sievers making problems actually harder to solve with his bad attitude.

Comment 30 David Strauss 2014-04-07 00:24:39 UTC

(In reply to comment #29)
> OK I'm sorry about that, I actually like systemd and I shouldn't have
> insulted anyone, I'm very sorry about that, I deeply regret and apologize.
>
> I'm just sad about what have happened with all this problem between systemd
> and the kernel and especially about Kay Sievers making problems actually
> harder to solve with his bad attitude.

Thank you for that. It means a lot. Seeing things progressing to civility is a step forward, even if getting consensus is still a ways off.

Comment 31 Anonymous Helper 2014-04-07 16:16:47 UTC

(In reply to comment #24)
> Systemd needs to be forked NOW.
>
> Linus explained it well already:
>
> Kay and Lennart: please just go away, disappear from the FOSS community, we
> don't need you and your crap.

Please cite that quote as I've not seen it on LKML and didn't find it with a quick search, so I'm interested in where else this topic is being discussed.

Comment 32 Patrick Goetz 2014-04-08 10:07:38 UTC

(In reply to comment #22)
>
> The primary argument against the namespacing is catering to end users trying
> to troubleshoot who are unfamiliar with the kernel/udev/systemd split of
> responsibilities. Obviously, the counter-argument is to namespace in order
> to fully isolate systemd's debug mode from the kernel's (without requiring
> systemd.log_level) and avoid a similar assertion bug affecting developers
> the same way.
>

Is this a valid argument, though? Surely any end user sophisticated enough to attempt to troubleshoot a problem at this level will also be sufficiently knowledgeable to able to type systemd.debug on the kernel command line.

Being able to sandbox debugging output with something as simple as namespacing seems like it would be great feature, not a problem; i.e.

---debug
+++systemd.debug

makes systemd better, as far as I can tell.

Comment 33 Patrick Goetz 2014-04-08 10:13:36 UTC

(In reply to comment #23)
> Lennart Poettering and Kay Sievers: worst developers of the FOSS community.

Ad hominem attacks are completely out of place on a bug report comment list. You're disrupting FOSS community in a very negative way by doing things like this. Save this kind of thing for your blog.

Thanks.

Comment 34 Alexandre Scheifer 2014-04-08 10:30:29 UTC

(In reply to comment #33)
> (In reply to comment #23)
> > Lennart Poettering and Kay Sievers: worst developers of the FOSS community.
>
> Ad hominem attacks are completely out of place on a bug report comment list.
> You're disrupting FOSS community in a very negative way by doing things like
> this. Save this kind of thing for your blog.
>
> Thanks.

Sorry about that, I don't actually believe what I said when I wrote that. I don't believe that Lennart and Kay are the "worst developers" as I quite like systemd and I enjoy using it every day.

I was angry about the whole situation with Kay not being helpful enough with others and making things harder to solve.

But that's not an excuse for my bad behavior and I don't have excuses, it won't happen again and I'm sorry.

I only hope the developers involved will put their egos aside and work together and improve things for a better future.

Again, my apologies.

Comment 35 Alexandre Scheifer 2014-04-08 10:36:21 UTC

(In reply to comment #31)
> (In reply to comment #24)
> > Systemd needs to be forked NOW.
> >
> > Linus explained it well already:
> >
> > Kay and Lennart: please just go away, disappear from the FOSS community, we
> > don't need you and your crap.
>
> Please cite that quote as I've not seen it on LKML and didn't find it with a
> quick search, so I'm interested in where else this topic is being discussed.

Linus Torvalds wrote:

+Paul Morgan I think what you (and others) seem to miss is that the systemd people made the "debug" option that we introduced not just do something - but do something useless that actively broke other peoples use of that option.

It doesn't matter who "owns" it, the fact is, they broke it.

Ok, fine. Bugs happen, and that's not what makes people upset.

What makes me (and others) upset is that when the bug is reported, with explanations and a suggestion for how to fix it, Kay just closed the bug-report, claiming it wasn't a bug.

Seriously? You want to debug kernel stuff, using the kernel command line command "debug" that makes the kernel more verbose, and now the systemd people say "sorry, we stole your thing and made it useless, and it's not a bug because you didn't call shot-gun".

Now, if this was an isolated incident, I personally would let it go. There are bad engineers out there, it's not worth worrying about. Ignore them and move on.

But this is not an isolated incident. This is how Kay has treated other bugs in the past. Literally months of stalling, closing bug-reports, and blaming other people and projects for problems that he caused, telling others how they should change their projects because he broke something, and obviously it can't be his fault.

And that is a problem.

https://plus.google.com/+TheodoreTso/posts/K7ijdmxJ8PF

Comment 36 Lennart Poettering 2014-05-24 08:38:07 UTC

systemd in git since a while will turn its debug output on if the kernel command line cotnains "debug", this will stay that way. However, it has been changed to not dump things to kmsg as soon as the journal is up. Up to that point we will still dump things to kmsg howerver, since there's no other nice place to put this.

Closing.

Afslutning på fejlrapport.

Transskript fra https://plus.google.com/+LennartPoetteringTheOneAndOnly/posts/X3fUhyJREKq

"Various people have asked me for a few words on Canonical's decision not to adopt systemd. I am not going to say much. But a few things:

From what I am hearing behind the scenes this appears to be very much about control. They control Upstart (both by being maintainer and even enforcing copyright assignment), and they think they don't control systemd. Of course, free software has never been about control, and whenever something deviates too much from where you would like it to go you have the freedom to fork. [In addition in times of git it is dead-easy to maintain your own patch set.] Similar to companies like Sun (who was too afraid to give up control about Java) it's all about control for them, and that is sad, and never good for the health of a project.

I think this decision is not good for the Linux ecosystem. Ubuntu has now become an island that is growing more or more apart from any other bigger commercial Linux. Because they have not adopted systemd they will have to continue to develop and support infrastructure (such as ConsoleKit, independent udev) that is officially orphaned by its developers and maintainers. They are stuck with a half-obsolete stack that receives no new development. Of course, Canonical could step up and invest major work in the development of their platform, but that would definitely be a first for them, and I seriously doubt they have enough knowledgeable engineers for that. Canonical contributes barely anything to the Linux plumbing layer, much the same way they stay away from the kernel. There are now two options for them: a) stay stuck forever with a half-obsolete stack or b) invest a lot of work to develop their stack entirely on their own in order to stay competitive with us.

Anyway, summary is: I wish them good luck, they are now going their own way, stuck in a legacy stack with little new engineering, becoming an island of their own. In the short time frame they might save money with this decision, in the long run this is going to be quite expensive for them, since as our stacks start to diverge more and more adopting systemd later on will get more and more expensive.

That all said: I am sure that "cloud" and "focus" (Mark's favourite buzz words) are totally going to make Upstart a piece of software of the future... ;-)

It's a sad day for the Linux ecosystem. But it makes things a lot easier for us, since we can give up on any considerations of making it easy to them and keeping their way into the systemd world open."

Afslutning på blogindlæg.

Be the first to write a comment!