User: Password:
|
|
Subscribe / Log in / New account

The Debian technical committee vote concludes

From:  Bdale Garbee <bdale-AT-gag.com>
To:  Anthony Towns <aj-AT-erisian.com.au>
Subject:  Bug#727708: call for votes on default Linux init system for jessie
Date:  Tue, 11 Feb 2014 07:35:13 -0700
Message-ID:  <87vbwlvhsu.fsf__19130.313388496$1392129580$gmane$org@rover.gag.com>
Cc:  727708-AT-bugs.debian.org, secretary-AT-debian.org
Archive-link:  Article

Anthony Towns <aj@erisian.com.au> writes:

> A.6.6: Schwartz set is {D,U}
> A.6.8: There are no defeats in the Schwartz set, so the elector with
>        the casting vote chooses which of these options wins.
>
> Per 6.3.2, the casting vote is held by the Chairman, who is currently
> Bdale.

Thank you, Anthony, for your analysis of the votes.

Per 6.3.2, I use my casting vote to choose D as the winner.

Therefore, the resolution reads:

  We exercise our power to decide in cases of overlapping jurisdiction
  (6.1.2) by asserting that the default init system for Linux
  architectures in jessie should be systemd.

  Should the project pass a General Resolution before the release of
  "jessie" asserting a "position statement about issues of the day" on
  init systems, that position replaces the outcome of this vote and is
  adopted by the Technical Committee as its own decision.

Bdale


(Log in to post comments)

The Debian technical committee vote concludes

Posted Feb 11, 2014 15:20 UTC (Tue) by tsmithe (subscriber, #57598) [Link]

Is it really over? I feel a twist coming on..

The Debian technical committee vote concludes

Posted Feb 11, 2014 15:27 UTC (Tue) by algernon (subscriber, #11573) [Link]

Your feeling is wrong. The poster there has not (recently) read the constitution, by the looks of it.

The Debian technical committee vote concludes

Posted Feb 11, 2014 15:32 UTC (Tue) by juliank (subscriber, #45896) [Link]

It was practically over even earlier. The outcome of the vote was no longer in doubt even before Andreas voted. And once the outcome of a vote is no longer in doubt, the voting can end. Bdale delayed the conclusion in order to give Andreas the chance to vote, but it was not strictly necessary.

The Debian technical committee vote concludes

Posted Feb 11, 2014 16:37 UTC (Tue) by hadrons123 (guest, #72126) [Link]

It kinda reached the tipping point when Colin voted thereby ended Ian's madness and saving us months of wasted FD time. I hope this sticks and systemd haters don't try to kill systemd implementation with the tight and loose coupling non-sense or GR.

The Debian technical committee vote concludes

Posted Feb 11, 2014 16:55 UTC (Tue) by tsmithe (subscriber, #57598) [Link]

I suspect systemd would win a GR, too. (Of course, I could well soon be eating my words.)

It'll now be interesting to watch the implications of all this.

The Debian technical committee vote concludes

Posted Feb 11, 2014 16:58 UTC (Tue) by rahvin (subscriber, #16953) [Link]

I'd personally wager a GR would select sysV before it picks upstart. The people that are opposed to systemD are generally opposed to any change if the comments on here are anything to go by.

The Debian technical committee vote concludes

Posted Feb 11, 2014 18:53 UTC (Tue) by dfsmith (guest, #20302) [Link]

And they'd have good cause. B-)

Look at the dependency lists (1st level):

sysvinit (132kB): libc6, libselinux1, libsepol1, debianutils, initscripts, sysv-rc, sysvinit-utils

upstart (486kB): libc6, libdbus-1-3, libjson0, libnih-dbus1, libnih1, libselinux1, libudev0, sysvinit-utils, sysv-rc, initscripts, mountall, ifupdown, udev

systemd (1445kB): libacl1, libaudit0, libc6, libcap2, libcryptsetup4, libdbus-1-3, libkmod2, liblzma5, libpam0g, libselinux1, libsystemd-daemon0, libsystemd-id128-0, libsystemd-journal0, libsystemd-login0, libudev0, libwrap0, util-linux, initscripts, udev, dpkg

The Debian technical committee vote concludes

Posted Feb 11, 2014 19:11 UTC (Tue) by proski (subscriber, #104) [Link]

systemd depends on dpkg? I think it's some Debian technicality. It's not the case on Fedora :)

util-linux, initscripts and udev belong to a minimal system, so the dependency is a non-issue.

Dependencies of some libraries can be made dynamic. Yes, systemd is still a big thing, but so is a modern OS.

The Debian technical committee vote concludes

Posted Feb 11, 2014 19:20 UTC (Tue) by engla (guest, #47454) [Link]

Those were stats for wheezy (stable), stats for jessie (current testing) are:
Version: 204-6
Installed size: 4984 KB
Depends: libacl1, libaudit1, libc6, libcap2, libcryptsetup4, libdbus-1-3,
libgcrypt11, libkmod2, liblzma5, libpam0g, libselinux1, libsystemd-daemon0,
libsystemd-journal0, libudev1, libwrap0, libsystemd-login0, util-linux,
initscripts, udev, acl, adduser
Recommends: libpam-systemd

The Debian technical committee vote concludes

Posted Feb 11, 2014 22:44 UTC (Tue) by anselm (subscriber, #2796) [Link]

The problem here is that systemd does various useful things by itself that the other inits either don't do at all or push into (optional) other packages that helpfully come with init scripts so there is no dependency on that package on the part of the init systems. If these other packages then depend on other stuff, that other stuff will not show up in the init's list of dependencies.

Chances are that if you examine the transitive closure over all dependencies rather than just the direct dependencies of the init system, the difference between a system based on systemd and one based on SysV init with the same functionality will no longer be all that great.

The Debian technical committee vote concludes

Posted Feb 14, 2014 10:16 UTC (Fri) by Wol (guest, #4433) [Link]

And are the daemon init scripts included in the source-line count etc?

I thought one of the major selling points of systemd was that a 100-line systemd init script was *huge*. For sysvinit that's miniscule, isn't it?

So while systemd itself may be pretty large for an init system, that is far more than compensated for by the reduction in size in packages that make use of it.

Cheers,
Wol

The Debian technical committee vote concludes

Posted Feb 14, 2014 8:20 UTC (Fri) by smurf (subscriber, #17840) [Link]

Note that some of these dependencies are not used by systemd itself, only by some of its helpers.

Of more interest is the main memory which systemd-as-PID-1 actually uses. That boils down to 2.8MB on my system, vs. 0.8MB for sysvinit. Compared with its long list of features, that's not bad at all.

The Debian technical committee vote concludes

Posted Feb 14, 2014 7:54 UTC (Fri) by smurf (subscriber, #17840) [Link]

It actually pre-depends on a specific minimum version of dpkg so that installation works correctly (dpkg moved a script).

The Debian technical committee vote concludes

Posted Feb 11, 2014 19:46 UTC (Tue) by dag- (subscriber, #30207) [Link]

Reading your list of dependencies, my conclusion is quite the opposite of what you are implying.

Only systemd understands ACLs (libacl), integrates with the auditing framework (libaudit), can use Linux/POSIX capabilities (libcap), integrates with crypted block devices (libcryptsetup), integrates with the recent kernel module interface (libkmod), integrates with PAM (libpam), integrates with udev (libudev), integrates with tcp_wrappers (libwrap).

This is all a good thing, since all of the above means richness and a full-featured init/xinet-system. What's worrying is that upstart doesn't seem to have the same integration. For sysvinit the above complexity (when available) is moved to the scripts on a case-by-case basis, with no consistency at all.

What I do not understand is why systemd is lacking SELinux support (libselinux/libsepol) maybe because it was disabled on build ?

The Debian technical committee vote concludes

Posted Feb 11, 2014 20:18 UTC (Tue) by jspaleta (subscriber, #50639) [Link]

My fedora 19 system has systemd depending on libselinux. The lack of dep in the packaging could be due to an implicit depchain? Maybe something else in the deplist already pulls in selinux so the debian packaging didn't make it explicit?

The Debian technical committee vote concludes

Posted Feb 11, 2014 20:01 UTC (Tue) by vonbrand (guest, #4458) [Link]

Check also the slew of programs called from the rc scripts and the "libraries" of functions they call for a balanced comparison.

The Debian technical committee vote concludes

Posted Feb 11, 2014 21:10 UTC (Tue) by rodgerd (guest, #58896) [Link]

So the argument is now that:

1/ systemd is a blob that does everything.
2/ systemd has too many external dependencies.

The Debian technical committee vote concludes

Posted Feb 12, 2014 16:26 UTC (Wed) by rgmoore (✭ supporter ✭, #75) [Link]

I think the basic idea is that systemd tries to do too many low-level things that really ought to be broken up. That results in it being large by itself and it having a large number of dependencies.

The Debian technical committee vote concludes

Posted Feb 12, 2014 16:49 UTC (Wed) by HelloWorld (guest, #56129) [Link]

Well, the thing is that many of the things that systemd does aren't really at all exciting. Take things like systemd-tmpfiles, systemd-timedated, systemd-localed and so on. They're simple and they get the job done, so why shouldn't systemd ship them? The point is that the problems caused by diversity (e. g. application authors having to support different ways of doing the same thing) are greater than the benefits that can conceivably be achieved by replacing those parts.

The Debian technical committee vote concludes

Posted Feb 12, 2014 22:17 UTC (Wed) by vonbrand (guest, #4458) [Link]

... and those tasks are done in separate, small, simple binaries.

The Debian technical committee vote concludes

Posted Feb 12, 2014 11:57 UTC (Wed) by jond (subscriber, #37669) [Link]

A mere list of package dependencies is not useful without some context. What is the point you are making? You may need to spell it out. Not all packages are equal in size-terms, if that's your point.

The Debian technical committee vote concludes

Posted Feb 11, 2014 18:10 UTC (Tue) by jspaleta (subscriber, #50639) [Link]

Unfortunately... the more problematic loose coupling ballot Ian proposed, in anger, is still live and the L option as now met quorum. The other TC members really need to vote on that ballot and ensure FD wins so that the appropriate discussion about init coupling between Russ and Steve can continue and work for a better option than the very prescriptive and restrictive policy Ian has proposed.

With this ballot live, an open-ended future where Debian maintainers are disallowed from requiring any advanced feature not provided by sysvinit is still very possible.. and that's just absurd. That's more absurd than the possibility of choosing minit as as default.

The Debian technical committee vote concludes

Posted Feb 12, 2014 12:00 UTC (Wed) by jond (subscriber, #37669) [Link]

I think you're right, but it's not the end of the world outside of the ctte. The rest of the project can begin the work to support the resolution that has closed, and can wait for the closure of this one before having to act on it.

The Debian technical committee vote concludes

Posted Feb 12, 2014 16:34 UTC (Wed) by Thue (subscriber, #14277) [Link]

Twist: Ian is back, with an ultimatum.

https://lists.debian.org/debian-ctte/2014/02/msg00441.html

The Debian technical committee vote concludes

Posted Feb 12, 2014 21:25 UTC (Wed) by Cyberax (✭ supporter ✭, #52523) [Link]

A really funny message. Somehow it reminded me of "Monsters vs Aliens":

> So to recap, I come in peace, I mean you no harm, and you all will die. Gallaxhar out.

The Debian technical committee vote concludes

Posted Feb 11, 2014 15:29 UTC (Tue) by pdewacht (subscriber, #47633) [Link]

So, we're back to moment-to-moment coverage? :)

The Debian technical committee vote concludes

Posted Feb 11, 2014 17:42 UTC (Tue) by marduk (subscriber, #3831) [Link]

Recount!

Sorry... couldn't resist.

The Debian technical committee vote concludes

Posted Feb 12, 2014 20:07 UTC (Wed) by balkanboy (guest, #94926) [Link]

yeah, but where's the dimpled chad?

Great news!

Posted Feb 11, 2014 19:01 UTC (Tue) by proski (subscriber, #104) [Link]

It's a good day for systemd, it would get more eyeballs. Ultimately, it's a good day for Linux desktop. I'm sure the outcome was affected by civility and eloquence of Russ Allbery, who is a systemd proponent.

Great news!

Posted Feb 11, 2014 19:46 UTC (Tue) by dlang (subscriber, #313) [Link]

> Ultimately, it's a good day for Linux desktop.

that's probably a valid statement. But it's also probably a valid statement that this is a bad day for Linux servers and embedded devices.

Great news!

Posted Feb 11, 2014 20:14 UTC (Tue) by vonbrand (guest, #4458) [Link]

systemd explicitly targets the whole range. It has been taken up enthusiastically by embedded people, and helps enormously to clean up the mess that managing services is traditionally.

Great news!

Posted Feb 12, 2014 0:03 UTC (Wed) by dakas (guest, #88146) [Link]

Here is what is worrying me: while I don't really have a clue about the underlying technology, it would appear to me that systemd is Linux-only. As opposed to Debian which has several distributions not running over a Linux kernel (like over BSD or the HURD).

What does it mean for them if applications are supposed to be coded only for making use of systemd?

Great news!

Posted Feb 12, 2014 0:21 UTC (Wed) by vonbrand (guest, #4458) [Link]

Latest numbers are a handful running kFreeBSD (literally), while Hurd doesn't work at all. Something like a 0.1% of Debian users. Is it really worth it?

Great news!

Posted Feb 12, 2014 0:39 UTC (Wed) by jspaleta (subscriber, #50639) [Link]

If it is.... then http://homepage.ntlworld.com/jonathan.deboynepollard/Soft... might be a way forward for them, until such time that the non-linux kernels gains a native implementation of systemd that uses native kernel mechanics that work on that kernel... or develop support for the linux-specific features that systemd-linux relies on.

There is absolutely room for BSD specific re-implementation of systemd that is BSD and HURD specific, using kernel level mechanisms that work on those kernels that provide the functionality that cgroups provides on linux. Someone just has to build those implementations. Eventually I think HURD will, given enough manhours to do it. Not sure about BSD, since BSD proper seem to be converging on supporting launchd...but time will tell.

And let's all try to remember that Debian sysvinit's ability to work with BSD or Hurd at all already depends on a linux compatibility layer existing in those alternative kernels.
Say it with me three times:
sysvinit is not portable
sysvinit is not portable
sysvinit is not portable

This is a fantastic read:
https://teythoon.cryptobitch.de/posts/on-portability-of-i...

"
This highlights that not only sysvinit depends on a Linux-specific kernel interface (/proc), but it also hard-codes assumptions about the system architecture.

Amusingly, systemd get's this right (ok, I'm not sure if it does, but it could get this right...). systemd organizes processes in cgroups, one for each service it starts and one for each login session or something like that. It can (could?) kill only those processes in it was responsible for, leaving all essential translators (system servers) alone. In fact, even my tiny cgroupfs prototype can keep track of translators that are started by the root filesystem translator."

Great news!

Posted Feb 12, 2014 2:13 UTC (Wed) by prometheanfire (subscriber, #65683) [Link]

Systemd requires new kernel interfaces. With arm at least, you are made to choose between having a older kernel (with paches from a vendor, not upstreamed) that supports stuff like opengles and accelerated video decode with vendor support or a newer one with systemd no opengles, no video acceleration and no vendor support.

It's an easy decision...

Great news!

Posted Feb 12, 2014 2:18 UTC (Wed) by vonbrand (guest, #4458) [Link]

How long will there be no systemd-capable kernels for your favorite ARM platform?

Great news!

Posted Feb 12, 2014 2:41 UTC (Wed) by prometheanfire (subscriber, #65683) [Link]

That is true, just explaining the situation as it is now :D

Great news!

Posted Feb 12, 2014 6:46 UTC (Wed) by koenkooi (subscriber, #71861) [Link]

On ARM you need to backport 5 patches to 2.6.32 to make it work there (someone did the work for an RHEL kernel), a 3.x kernel works without problems.

Great news!

Posted Feb 12, 2014 7:23 UTC (Wed) by prometheanfire (subscriber, #65683) [Link]

That's good to know, may have to go hunting for those patches :D

The oldest kernel I know that still ships is 2.6.31 though, but one thing at a time :P

Great news!

Posted Feb 12, 2014 8:34 UTC (Wed) by xav (subscriber, #18536) [Link]

Stop working on kernel enhancements because of compatibility with proprietary blobs ?

Great news!

Posted Feb 12, 2014 8:37 UTC (Wed) by prometheanfire (subscriber, #65683) [Link]

I'd consider systemd userland. A more correct statement would be.

Don't use systemd because it can't be used on an older (incompatible) kernel.

Great news!

Posted Feb 14, 2014 11:34 UTC (Fri) by smurf (subscriber, #17840) [Link]

… but hardly the fault of systemd.

Binary blobs which do not work with newer kernels (or, most likely, the same kernel, compiled with different options) are a license violation.

Great news!

Posted Feb 12, 2014 15:26 UTC (Wed) by edeloget (subscriber, #88392) [Link]

> systemd explicitly targets the whole range. It has been taken up enthusiastically by embedded people, and helps enormously to clean up the mess that managing services is traditionally.

Wait, what ? The embedded people took up systemd "enthusiastically"?

Not at all. There is a whole world of consideration that systemd simply fails to met for it to be useful in the embedded world. systemd + its dependencies take way too much place on your tiny NAND (or NOR) flash, needs a lot of not-that-cheap inodes, more-or-less forces you to rely on a non-RT communication system (dbus), makes it difficult to easily change your boot sequence (because, you know, compiled program) and so on.

Some may be happy with the idea of systemd taking a large share of the embedded world yet it's plain wrong. I have yet to see a vendor-backed BSP with systemd support. Not to mention that most embedded developpers (like me) are perfectly happy with sysV init and that's a good thing because we don't care that much about distribution compatibility - the whole thing is tied to a platform or to a short list of platforms; we need to be able to rapidly "prototype" (i.e. prototype and ship) our platform-tied init; and so on.

Remember that we are in the embedded world: nothing is standard here. I saw embedded platforms with one single init script. Being able to ship init scripts instead of a compiled binary makes our life easier both during the development and in the long term and we rarely have a need for the complexity of systemd (whatever the merits of systemd are).

Great news!

Posted Feb 12, 2014 15:37 UTC (Wed) by zdzichu (subscriber, #17118) [Link]

> makes it difficult to easily change your boot sequence (because, you know, compiled program)

This single ”reason” make it obvious that you have not seen systemd in action. So you certainly did not evaluate incorporating systemd on your platform.
Those who did evaluate selected systemd in a blink. Phones (SailfishOS on Jolla), cars (GENIVI) and so on.

Great news!

Posted Feb 12, 2014 16:18 UTC (Wed) by pizza (subscriber, #46) [Link]

I get what you're talking about with respect to flash space and system resources (for a long, long time I wrote Wireless Router BSPs that had to fit in 4MB flash and 16MB RAM), but modern "embedded systems" have more resources and oomph than a workstation from a decade ago, with an even greater increase in operational requirements and complexity.

I'd have loved to have something like systemd back then, though I accept that it would never have fit. But you know what? That was then, and Moore's law has reaped wonders -- The wireless router sitting on my desk at home has 8x the RAM and 4x the flash of what I used to target, and it's actually low-spec compared to its modern contemporaries.

(as an aside, I'm not sure a modern Linux kernel would even fit in that 4/16 target of yesteryear..)

Anyway. These days I'm targetting microcontrollers with a whopping 4K of RAM and 32K for code. And that's the high end of things. :)

Great news!

Posted Feb 12, 2014 21:21 UTC (Wed) by Cyberax (✭ supporter ✭, #52523) [Link]

> Wait, what ? The embedded people took up systemd "enthusiastically"?
Yes, we did.

>Not at all. There is a whole world of consideration that systemd simply fails to met for it to be useful in the embedded world. systemd + its dependencies take way too much place on your tiny NAND (or NOR) flash, needs a lot of not-that-cheap inodes, more-or-less forces you to rely on a non-RT communication system (dbus), makes it difficult to easily change your boot sequence (because, you know, compiled program) and so on.
It's hard to find devices with so small amount or flash and RAM as to be incapable of running systemd.

At most, systemd adds about 1Mb of additional flash drive space and actually _saves_ RAM by not starting unnecessary daemons.

Oh, and somebody said that systemd can't be compiled with uclibc - that's not true, it works fine after a light patching.

Great news!

Posted Feb 13, 2014 13:45 UTC (Thu) by cmorgan (guest, #71980) [Link]

We've been using Angstrom on the BBB with systemd. Its made it super easy to add new tasks at startup, check why they aren't starting up. systemd beats the pants off of sysvinit in terms of functionality.

Great news!!

Posted Feb 11, 2014 20:39 UTC (Tue) by hmvp (subscriber, #54422) [Link]

As someone who currently works on embedded linux platform I find systemd to be a godsend where it comes to managing services on a small (or any) platform. Together with dbus (and hopefully kdbus in the future) it allows us to make a platform where all functionality is in loosely coupled services communicating through dbus and managed by systemd during the different modes the system can be in.

And given my experiences in managing linux/unix servers I sincerely hope that I can manage all my servers the same way someday. The only service management tool so far that was somewhat "acceptable" is what Sun put in Solaris and even that is not what I would recommend

Great news!

Posted Feb 11, 2014 21:33 UTC (Tue) by khim (subscriber, #9252) [Link]

systemd works fine on both servers and embedded devices. Only tiny systems like routers are not suitable target for systemd (and these rarely use sysvinit either which means that for these there are are no change at all).

Great news!

Posted Feb 11, 2014 21:47 UTC (Tue) by jspaleta (subscriber, #50639) [Link]

hmm, I would have thought tiny systems counted in embedded and that compile time options would allow systemd to work on those as well.

Are there any NAS solutions running systemd from their firmware yet that anyone knows of?

Great news!

Posted Feb 12, 2014 1:19 UTC (Wed) by m45t3r (subscriber, #92849) [Link]

When you have routers with 4/8MB of flash like mine (or the majority of domestic routers AFAIK) it's really difficult to use anything more complex than a simple init system (and when I say simple, I am talking something like Busybox's init, not even sysvinit). You can't even use glibc there (and I think systemd only compiles under glibc), you need lower overhead C libraries like uclibc or even musl.

But yeah, for everything else systemd seems to be the thing to use. I would really like to see a working implementation of systemd driving Android, but this seems unlikely since Google doesn't like GPL.

Great news!

Posted Feb 12, 2014 1:56 UTC (Wed) by viro (subscriber, #7872) [Link]

More to the point, google has every reason for _NOT_ wanting to have anyone impose a "vision"[1] upon them...

[1] noun. uncountable: ability to see. countable: hallucination of one sort or another.

Great news!

Posted Feb 12, 2014 7:16 UTC (Wed) by palmer_eldritch (guest, #95160) [Link]

Well, google's more the type to impose their own visions upon others...

Great news!

Posted Feb 14, 2014 11:21 UTC (Fri) by smurf (subscriber, #17840) [Link]

Stop trolling, please. You know as well as we do that "vision" has other meanings than the two you listed.

NAS with systemd

Posted Feb 13, 2014 17:44 UTC (Thu) by janecek (subscriber, #74774) [Link]

Netgear readynas 100 series (other series probably as well) are running a variant of debian with some ancient version of systemd (I think 44, as in debian wheezy).

NAS with systemd

Posted Feb 14, 2014 9:56 UTC (Fri) by tzafrir (subscriber, #11501) [Link]

Version 44 is just before udev got merged into the systemd repository and bumped the version number to 192 or so. It's not that ancient.

Great news!

Posted Feb 11, 2014 21:51 UTC (Tue) by tao (subscriber, #17563) [Link]

At least from my perspective servers is where systemd totally shines. I mean, reliable service monitoring? Yes *please*! Better logging? Oh *YES*!

On my laptop I could probably survive using sysvinit (not that many critical services running and if something crashes I generally notice right away...), but on a server I want reliability and logs that describe what went wrong if something goes haywire.

Great news!

Posted Feb 11, 2014 22:05 UTC (Tue) by pizza (subscriber, #46) [Link]

> At least from my perspective servers is where systemd totally shines. I mean, reliable service monitoring? Yes *please*! Better logging? Oh *YES*!

This, a thousand times over.

Not to mention I could (and did) write native systemd units to replace init scripts for couple of exceptionally-brittle services, including one that simply wasn't possible to set up properly in shell...

Great news!

Posted Feb 11, 2014 22:13 UTC (Tue) by dlang (subscriber, #313) [Link]

better logging only if you don't care about performance but do care about stdout and stderr of your apps (but didn't bother to collect them before)

Great news!

Posted Feb 11, 2014 22:19 UTC (Tue) by mebrown (subscriber, #7960) [Link]

Tell me about this performance thing you speak of. Details? Mailing list links? Bugzilla entries? I am very much interested to hear of any performance problems associated with logging to journald.

Great news!

Posted Feb 11, 2014 22:26 UTC (Tue) by mpr22 (subscriber, #60784) [Link]

dlang recently presented in LWN comments a (somewhat redacted) scenario from their workplace; it involved a setup where a daemon was generating a (desired) high volume of logging output, which the modern syslog implementation they were using was forwarding to a logging server. The modern syslog implementation they were using was handling this admirably (saturating a GigE link), but interposition of journald caused substantial performance degradation if not placed in pure passthrough mode.

Great news!

Posted Feb 11, 2014 22:59 UTC (Tue) by fandingo (subscriber, #67019) [Link]

Dlang's argument is only true until native network send/receive is implemented in the journal.

Great news!

Posted Feb 11, 2014 23:07 UTC (Tue) by dlang (subscriber, #313) [Link]

so how many different network send/receive protocols is systemd going to support? which ones?

how fast is it going to be?

what filtering options is it going to offer?

Why is it playing NIH and ignoring all the existing logging tools (rsyslog, syslog-ng, nxlog, logstash just to name the major transports)

Great news!

Posted Feb 11, 2014 23:46 UTC (Tue) by fandingo (subscriber, #67019) [Link]

Zuki can provide more info. He wrote the original patches and says he's going to finish up the work hopefully soon. You were part of the thread last time: http://lwn.net/Articles/583766/

> so how many different network send/receive protocols is systemd going to support? which ones?

It looks like initially HTTP and SSH-based TCP with HTTPS coming eventually. And before you get terribly upset about HTTP being slow, each POST (or GET if pulling) will not correspond to individual messages.

> how fast is it going to be?

How can this possibly be answered for code that isn't finished? I suppose it will be 42.

> Why is it playing NIH and ignoring all the existing logging tools (rsyslog, syslog-ng, nxlog, logstash just to name the major transports)

1) People don't want to use multiple tools.
2) Full support of journal messages. The solutions that you mention are not as flexible, in particular they do not accept arbitrary amounts of binary data.

Your entire complaint about the journal is performance due to stacking. Then, you're upset that the full network solution doesn't involve stacking with another tool (like journal+rsyslog, which is currently recommended). Seems a little contradictory, no?

Lastly, since the author of these patches is an active commentator here, and you have specific needs or complaints, it's probably worthwhile to voice them since this work is still under development.

Great news!

Posted Feb 12, 2014 0:42 UTC (Wed) by dlang (subscriber, #313) [Link]

so systemd is going to ignore everything that's currently done with logs and roll their own new protocol, just wonderful

> 1) People don't want to use multiple tools.

This is part of the problem. People who are dealing with logs today have the tools they are using. the systemd journal is breaking this.

> 2) Full support of journal messages. The solutions that you mention are not as flexible, in particular they do not accept arbitrary amounts of binary data.

have you looked? they all have some maximum message size, but I'll bet that the journal does as well (or can an app just cat /dev/urandom to stderr and expect the journal to handle it), But except for this max message size, the log systems can handle arbitrary large messages

As for binary messages, nobody except the systemd people think that's a good idea. It's been done many times over the years by different people and it's always led to trouble. But encoding whatever binary junk that the systemd people want to pass as they pass it to any of the existing logservers should be a trivial exercise.

It's not like people read binary anyway, so at some point it will need to be extracted from the binary format so it can be used.

If you think the existing journal tools are at all suitable to handle enterprise level volumes of logs, you have no idea of the scope of the issues. The performance nightmares are just starting.

Great news!

Posted Feb 12, 2014 0:58 UTC (Wed) by mchapman (subscriber, #66589) [Link]

> have you looked? they all have some maximum message size, but I'll bet that the journal does as well (or can an app just cat /dev/urandom to stderr and expect the journal to handle it),

Well, I'm recording core dumps in my journal (systemd-coredumpctl is awesome), and they're close to random. :-)

I think the maximum message size 768 MiB.

Great news!

Posted Feb 12, 2014 1:04 UTC (Wed) by dlang (subscriber, #313) [Link]

mixing core dumps with normal logs is insane (and if the max message size is 768MB then what happens if you have a core larger than that?)

Great news!

Posted Feb 12, 2014 1:48 UTC (Wed) by mchapman (subscriber, #66589) [Link]

> mixing core dumps with normal logs is insane

Possibly, though once you get over the idea that "logs must be plain text" it makes a fair bit of sense. The coredump diversion is optional, of course, and the journal entry isn't verbose in the regular journalctl output (the MESSAGE field is just "Process PID (COMM) dumped core").

> (and if the max message size is 768MB then what happens if you have a core larger than that?)

It will ignore it.

Great news!

Posted Feb 12, 2014 2:36 UTC (Wed) by dlang (subscriber, #313) [Link]

While I also believe that binary logs are a mistake, and some of the bugs that have hit the systemd journal with corruptions that caused infinite loops are an example of why, that's not the reason I say that mixing core dumps with normal logs is insiane.

logs need to be correlated and reported on, mixing gigantic unparseable blobs like core dumps with 'normal' logs in the same stream (which with the journald format must be read from the beginning to be parseable) means that you significantly slow down access to the normal logs.

choosing to be incompatible with _all_ the tools that people use to deal with logs today is just a really bad idea. Unless you are going to replace all of these tools (including several fairly large companies who's only products are log related), you are just making life harder for people by refusing to be compatible with anything.

and systemd supporters wonder why anyone could possibly question the wisdom of going to systemd.

Great news!

Posted Feb 12, 2014 3:03 UTC (Wed) by vonbrand (guest, #4458) [Link]

A binary format is more amenable to having indices to speed up searches than the plain text you seem to favor.

Great news!

Posted Feb 12, 2014 3:52 UTC (Wed) by dlang (subscriber, #313) [Link]

> A binary format is more amenable to having indices to speed up searches than the plain text you seem to favor.

how? you can have indices that point to the beginning of a text line just as well as you can have pointing to the beginning of a binary record. being text doesn't forbid it, and being binary doesn't help it.

I've had to deal with logs that were structured very similarly to the systemd binary format (although the logs I had to deal with didn't put absolute pointers all over the file, just relative ones which is a little less evil) and so I've had to deal with the types of corruptions that happen in real life, and the problems that you end up having because you have to walk the file from the beginning instead of being able to start from an arbitrary point in the file and find the beginning of a record.

Great news!

Posted Feb 13, 2014 0:30 UTC (Thu) by smoogen (subscriber, #97) [Link]

This isn't the default. Just because someone can and likes to do it does not mean everyone else is doing it.

http://xkcd.com/386/

Great news!

Posted Feb 13, 2014 0:35 UTC (Thu) by dlang (subscriber, #313) [Link]

are you saying that journald isn't the default or that journald doesn't default to binary log files?

Great news!

Posted Feb 14, 2014 10:29 UTC (Fri) by smurf (subscriber, #17840) [Link]

He's saying that by default systemd does not add core dumps to the log.

I'm of two minds with that. On one hand, storing the core files in some binary contraption feels somewhat wrong, but on the other hand core files without the surrounding logs are of questionable use (more often than not, something actually went visibly wrong before the core dump …), and so are logs stating that something dumped core but without the actual core dump – so storing them together makes sense.

Great news!

Posted Feb 14, 2014 11:18 UTC (Fri) by smurf (subscriber, #17840) [Link]

> systemd is going to ignore everything that's currently done with logs

They have to. The thing needs to run from system start. You can't just launch /usr/sbin/syslog-in-postgress-d before even mounting the rootfs.

> and roll their own new protocol

Well, if you know something that's powerful enough to support their metadata (so that "systemctl status FOO.service" can extract the relevant logs), you're free to submit a patch. I'm sure they'll take it.

Until then, their full dump format is just a block of textual lines (if no binary data are in the way) and thus reasonably easy to feed into whatever, and the auto-log-rotating features of journald protect much better against running out of space than logging to rsyslog and starting logrotate once per hour/day.

Great news!

Posted Feb 16, 2014 3:59 UTC (Sun) by dlang (subscriber, #313) [Link]

>> systemd is going to ignore everything that's currently done with logs

> They have to. The thing needs to run from system start. You can't just launch /usr/sbin/syslog-in-postgress-d before even mounting the rootfs.

actually, you could. rsyslog will be unable to output to the destination, so it will keep the logs in it's in-memory queue. Then after you get whatever you need up to output the logs to, send rsyslog a HUP and it will 'reopen' it's outputs, and dump all the pending logs.

by the way, if you don't even have your rootfs mounted, what does the journal do with it's logs in the meantime? and how does it know when it's able to start writing them?

>> and roll their own new protocol

> Well, if you know something that's powerful enough to support their metadata (so that "systemctl status FOO.service" can extract the relevant logs), you're free to submit a patch. I'm sure they'll take it.

in terms of the formatting of the data, write the data as a JSON structure and all modern syslog daemons will be able to not only pass it along, but make intelligent use of the data.

As for extracting the relevant logs, that is a question of what output you choose to use. for stand-alone systems (like desktops), the journald approach makes a lot of sense, but in an enterprise environment, you want those logs centralized and put into one or more sets of systems to process the logs, some in real-time, others to generate reports, and yet others to make searching massive log volumes easy. The right answer varies from log to log and from organization to organization, there is no single "right" way to deal with such large log volumes

Great news!

Posted Feb 16, 2014 4:21 UTC (Sun) by mchapman (subscriber, #66589) [Link]

> by the way, if you don't even have your rootfs mounted, what does the journal do with it's logs in the meantime? and how does it know when it's able to start writing them?

As I understand it, if the journal isn't running (i.e. very early boot, or while it's being restarted), then systemd will send messages to the kernel ring buffer. journald will pick them up when it is started.

If journald is running but no permanent storage at /var/log/journal/ is available for it (e.g. later on in the initramfs, and possibly early post-initramfs boot), then it will write to /run/log/journal/ on tmpfs. After the local filesystems have been mounted, systemd-journal-flush.service instructs the journal to flush the tmpfs journal to persistent storage, if it is now available. If /var/log/journal/ is not present, then the default configuration is for journald to keep using the tmpfs.

Great news!

Posted Feb 16, 2014 4:46 UTC (Sun) by dlang (subscriber, #313) [Link]

Ok, any messages sent to the kernel ring buffer would also get picked up by rsyslog when it starts, just like the kernel boot messages, right?

In any case, it sounds like what systemd does and what rsyslog does are pretty similar.

Great news!

Posted Feb 16, 2014 5:16 UTC (Sun) by mchapman (subscriber, #66589) [Link]

> In any case, it sounds like what systemd does and what rsyslog does are pretty similar.

Sure, in this respect, I would agree with that.

Great news!

Posted Feb 11, 2014 22:21 UTC (Tue) by jspaleta (subscriber, #50639) [Link]

Is there a bug number upstream to track the journal performance issue. Or is it still under a gentlemen's/vendor agreement with regard to discussing the full details of it?

I'm not discounting it as a real issue, but I've got nothing outside of lwn thread to track right now so if there's an official bug to track I'd appreciate it.

-jef

Great news!

Posted Feb 11, 2014 22:52 UTC (Tue) by dlang (subscriber, #313) [Link]

I have heard that there are bug around this, but since I don't use Fedora or RHEL I haven't put any effort into finding and tracking them.

Great news!

Posted Feb 12, 2014 15:26 UTC (Wed) by jonnor (guest, #76768) [Link]

It is a systemd issue, just report it upstream.

Great news!

Posted Feb 11, 2014 23:00 UTC (Tue) by fandingo (subscriber, #67019) [Link]

It's only in sending logs to a remote system because you have to go through a syslog bridge like

journald -> rsyslog -> network -> remote rsyslog

Great news!

Posted Feb 11, 2014 23:41 UTC (Tue) by jspaleta (subscriber, #50639) [Link]

I'm pretty sure I know how it works...
And I'm pretty sure I know what dlang would prefer which is the option to get back to letting services talk directly to rsyslog instead of taking the performance hit of the bridging service which allows the journal to index those syslog messages.

And since dlang has brought the high log throughput performance regression up now a couple of times.. including a second hand discussion of what the potential workaround is...I'm trying to tease out an authorative bug report from him without resorting to the unfortunately worded but common bombastic demand to provide a bug ticket reference.

I'm still in the market for any archived discussion, either in systemd-devel or in any vendor bug ticketing system that I can use to corroborate the workload conditions that creates a performance penalty that dlang has mentioned repeatedly here in lwn. Anybody got a ticket handy that speaks to the performance issue... please... don't be shy.

Great news!

Posted Feb 14, 2014 11:06 UTC (Fri) by smurf (subscriber, #17840) [Link]

In fact I would argue that high-volumee remote logging is not what the journal or rsyslog should be doing in the first place.

There are more efficient protocols for sending multiple megabytes per second somewhere. Funneling them through rsyslog does not strike me as particularly sensible, regardless of whether there's also a systemd journal in between or not.

Great news!

Posted Feb 16, 2014 3:50 UTC (Sun) by dlang (subscriber, #313) [Link]

actually, rsyslog can send that sort of data volumes quite easily. As for other options to send that sort of volume, what would you suggest?

and one other major advantage of using rsyslog is the ability to interoperate with the extensive set of log processing tools that are out there.

Great news!

Posted Feb 11, 2014 22:17 UTC (Tue) by mebrown (subscriber, #7960) [Link]

I have managed development for several high-volume, important embedded devices.

I have enthusiastically and wholeheartedly moved every one of them over to systemd and have seen huge improvements in boot speed, reliability, modularity, and ease of understanding of the boot process.

Please don't shed your tears on the embedded guy's behalf. We don't need them.

Great news!

Posted Feb 11, 2014 23:18 UTC (Tue) by shmerl (guest, #65921) [Link]

systemd works nicely in Sailfish and PlasmaActive. So its mobile usage is not news.

Great news!

Posted Feb 12, 2014 6:11 UTC (Wed) by suy (guest, #81959) [Link]

Could you elaborate on that? I'm developing an application that runs a service (daemon) on an embedded project, and we chose systemd for it because many features in it are amazingly compelling for us (mainly, but not only, the journal).

I would love to run it on my server (still debian stable with sysvinit), but I would prefer to use the default there, since my sysadmin skills are moderate.

Great news!

Posted Feb 12, 2014 12:00 UTC (Wed) by jond (subscriber, #37669) [Link]

Perhaps? I'm not sure. I install systemd on my VMs r-pis as soon as I can.

Of course this goes to a General Resolution

Posted Feb 11, 2014 19:14 UTC (Tue) by jmorris42 (guest, #2203) [Link]

Lets review the Systemd opponent position:

1. Systemd is alien tech, even though it works (unlike pulseaudio), has some level of documentation, etc; thus avoiding the easy and obvious objections, it has no resemblance to Unix Tech and by 'on the record' statements of it's creators this is not an accident. The old school pretty much MUST object or turn in their Unix Guru card.

2. NIH sysdrome, but with a point. Systemd is not Debian tech, it is clearly RedHat tech and they have made it clear they are not done expanding it's mandate. It aspires to be a replacement for all OS level plumbing between the kernel and the GUI. adopting parts of it defeats the entire purpose of adopting any of it, avoiding a patch frenzy on all of the other GNOME/RH tech.

3. Despite the assurances, adoption of systemd means the deprecation of all non-Linux ports within a few years as the porting effort becomes unsustainable. Again, non-portability appears to be an explicit design decision. Note that RedHat does not sell any non-Linux products. (Note also they don't make any real effort to sell desktop products but finance the effort of the GNOMEs to blow up the desktop and keep it in a state of chaos.) Paranoia? Maybe, but it is so easy to see hidden motives.

4. Adopting systemd represents a once in a generation decision on direction. Is Debian an independent project or a downstream project implementing policy and direction made elsewhere?

None of those objections are at heart technical decisions so the odds of the fight ending in the Technical Committee are low. The fight will rage and there will be damage regardless of the winner, fault lines are being exposed and torn asunder. Attempts to quash this fight and avoid a full on civil war are going to cause a civil war. Classic no win scenario.

Of course this goes to a General Resolution

Posted Feb 11, 2014 19:28 UTC (Tue) by hkario (subscriber, #94864) [Link]

> 3. Despite the assurances, adoption of systemd means the deprecation of all non-Linux ports within a few years as the porting effort becomes unsustainable. Again, non-portability appears to be an explicit design decision. Note that RedHat does not sell any non-Linux products. (Note also they don't make any real effort to sell desktop products but finance the effort of the GNOMEs to blow up the desktop and keep it in a state of chaos.) Paranoia? Maybe, but it is so easy to see hidden motives.

Systemd is very useful on the server, that's why RH develops it, it's just that GNOME people decided they want to make it a "soft" dependency.

Also, just because RH doesn't push its Linux desktop doesn't mean that it doesn't benefit from more usable Linux desktop in general. After all, Linux desktops are most compatible clients for Linux servers.

Of course this goes to a General Resolution

Posted Feb 11, 2014 19:48 UTC (Tue) by dlang (subscriber, #313) [Link]

sure, because everything that RH has developed is the right way to do things.

in case you missed it, there is heavy sarcasm intended there.

RH is sometimes right and sometimes wrong in what they do, just because they do it doesn't mean it's right.

Of course this goes to a General Resolution

Posted Feb 11, 2014 20:05 UTC (Tue) by pizza (subscriber, #46) [Link]

> RH is sometimes right and sometimes wrong in what they do, just because they do it doesn't mean it's right.

...Doesn't that depend on what you mean by "right"?

I might add that many of these "mistakes" are only obvious in hindsight.

On the other hand, the fact that they are the ones doing the um, doing means that they get a far greater say in the direction of things than the ones that aren't doing the doing.

Code talks, eh?

Of course this goes to a General Resolution

Posted Feb 11, 2014 20:15 UTC (Tue) by dlang (subscriber, #313) [Link]

perfectly find for their own distro.

But when their people start browbeating others for not agreeing with them, there is a problem.

code talks, but people should be free to not use the code as well.

Of course this goes to a General Resolution

Posted Feb 11, 2014 20:30 UTC (Tue) by vonbrand (guest, #4458) [Link]

Pray tell who is forcing you to use this code...

Of course this goes to a General Resolution

Posted Feb 11, 2014 22:08 UTC (Tue) by dlang (subscriber, #313) [Link]

just look at all the people in these threads who are insulting anyone who doesn't want to use systemd for examples. And they are just the easy examples.

Of course this goes to a General Resolution

Posted Feb 12, 2014 1:09 UTC (Wed) by vonbrand (guest, #4458) [Link]

True, there are some systemd champions here that are somewhat too shrill. But please look also at the anti-systemd people around here, with their accusations of all sort of world-wide conspiracies, forcing people to destroy the distributions they have worked hard to build, and so on. Please don't just look at one side of the flame war.

Of course this goes to a General Resolution

Posted Feb 12, 2014 1:13 UTC (Wed) by dlang (subscriber, #313) [Link]

it's more than just the shrill extremests. the statements from LP accusing people who don't move to systemd of causing fragmentation of linux are an example of the problem.

Of course this goes to a General Resolution

Posted Feb 12, 2014 1:51 UTC (Wed) by vonbrand (guest, #4458) [Link]

Source, please? I've read a lot by Lennart, but I don't remember any such comment.

Of course this goes to a General Resolution

Posted Feb 12, 2014 2:06 UTC (Wed) by dlang (subscriber, #313) [Link]

I'm pretty sure that I say this in his G+ posts, but I don't bookmark such things just in case someone asks for a reference sometime in the future.

Of course this goes to a General Resolution

Posted Feb 12, 2014 2:32 UTC (Wed) by vonbrand (guest, #4458) [Link]

So this is just another myth. Just as I thought.

Of course this goes to a General Resolution

Posted Feb 12, 2014 2:37 UTC (Wed) by dlang (subscriber, #313) [Link]

more insults, why am I not surprised.

Of course this goes to a General Resolution

Posted Feb 12, 2014 2:42 UTC (Wed) by rodgerd (guest, #58896) [Link]

You have a very broad definition of insults when pointing out that you've failed to substantiate a personal attack with evidence counts as an insult.

Of course this goes to a General Resolution

Posted Feb 12, 2014 2:56 UTC (Wed) by dlang (subscriber, #313) [Link]

Where did I make a personal attack? saying that LP has called distros that won't switch to systemd responsible for fragmenting linux could be mistaken, but it's hardly a personal attack.

Of course this goes to a General Resolution

Posted Feb 12, 2014 9:28 UTC (Wed) by xav (subscriber, #18536) [Link]

The lack of "-1 Troll, -1 Flamebait" in the LWN 'forum' starts to be painful.

Of course this goes to a General Resolution

Posted Feb 12, 2014 3:02 UTC (Wed) by hadrons123 (guest, #72126) [Link]

If you want to accuse someone you better have some evidence. Since its G+, I guess it would not be hard to search either.

Of course this goes to a General Resolution

Posted Feb 12, 2014 3:27 UTC (Wed) by neilbrown (subscriber, #359) [Link]

Not hard, but not trivial.

I found

https://lwn.net/Articles/534443/

Which is dlang making a similar statement about a year ago but with specific reference to Ubuntu, and

https://archive.fosdem.org/2013/interviews/2013-lennart-p...

which contains

> However, one of our other goals was to unify the fragmented Linux landscape, reducing the various lower-level differences between the distributions, and I guess we only partially succeeded with that. We did not convince the Ubuntu folks that systemd and unification was a worthy goal, and we certainly have to take (at least partial) blame for that.

which relates fairly well to the earlier statement by dlang (less well to the recent one).

So it seems that Lennart certainly did connect the ideas of not using systemd with fragmenting the Linux landscape (or at least: not unifying it). This example isn't exactly an accusation though. Maybe my google-fu isn't up to finding the actual accusation.

Of course this goes to a General Resolution

Posted Feb 12, 2014 3:42 UTC (Wed) by vonbrand (guest, #4458) [Link]

I'm sorry, but "we hope to reduce fragmentation" sounds far from accusing others of actively fragmenting Linux. Lennart might be quite abrasive at times, highly convinced that he is right (and for the fury of his opponents, he has the nerve to be right most of the time), absolutely opposed to compromising what he works on, but not trying to force anybody. Besides, it is free software. Don't like it? Fork it, write your own, or use something else.

Of course this goes to a General Resolution

Posted Feb 12, 2014 19:18 UTC (Wed) by suy (guest, #81959) [Link]

The quote says "WE certainly have to take (at least partial) blame". How that is an accusation?

Of course this goes to a General Resolution

Posted Feb 14, 2014 11:32 UTC (Fri) by smurf (subscriber, #17840) [Link]

> So it seems that Lennart certainly did connect the ideas of not using systemd with fragmenting the Linux landscape (or at least: not unifying it)

Precisely -- "not unifying" is the keyword here. Who the hell needs three different locations for startup scripts, with different boilerplate function libraries, support like start-stop-daemon present or not; multiple possible locations for /etc/hostname, let alone how to set it without rebooting …

… I'd have to agree with Lennart that there are better (and more productive) ways for Linux distributions to be distinctive than how to do things like that.

Of course this goes to a General Resolution

Posted Feb 12, 2014 18:05 UTC (Wed) by HelloWorld (guest, #56129) [Link]

> the statements from LP accusing people who don't move to systemd of causing fragmentation of linux are an example of the problem.
Given the current state of affairs where pretty much every major distro has switched or will switch to systemd, it is a *fact* that distros who don't adopt systemd are causing fragmentation. This is not a matter of opinion any longer. What is a matter of opinion is whether this fragmentation is good or bad. I think it's bad, and so does Lennart Poettering, and that's his prerogative and you shouldn't flame him for doing that.

Of course this goes to a General Resolution

Posted Feb 12, 2014 22:38 UTC (Wed) by dlang (subscriber, #313) [Link]

He has the right to his opinion, but him pushing for all distros to use systemd means that the mantra "just change what distro you use if you don't like systemd" is a false one. The systemd proponents are going to keep applying whatever pressure they can to get all distros to switch (in part by pretending that everyone else already has, see the embedded discussion for examples)

Of course this goes to a General Resolution

Posted Feb 13, 2014 1:33 UTC (Thu) by HelloWorld (guest, #56129) [Link]

> He has the right to his opinion, but him pushing for all distros to use systemd means that the mantra "just change what distro you use if you don't like systemd" is a false one.

Just what are you talking about? How is he pushing anybody? How are those systemd proponents you're talking about applying any pressure? What means do they even have? The only thing that Poettering does to make people use systemd rather than the alternatives is to make sure it works better than they do. This isn't called “pressure” or “pushing”, it's called “doing a great job”.

Of course this goes to a General Resolution

Posted Feb 13, 2014 13:01 UTC (Thu) by Zack (guest, #37335) [Link]

> How are those systemd proponents you're talking about applying any pressure?

Hounding everyone who doesn't agree a 100% with them whenever the subject comes up ?

> What means do they even have?

Apparently an infinite amount of time and a frightening amount of zeal.

> The only thing that Poettering does to make people use systemd rather than the alternatives is to make sure it works better than they do.

Alternatively, maybe systemd just convinced some that it works better by specifically catering to their needs. Then these "some"--comfortable in their majority--are so convinced they're on the side of righteousness and that they're part of the "one true way" forward that they will gladly and incessantly confront any undesirables with their erroneous ways and deviant thinking.

In short: systemd does nothing for me technically, and socially its track record is a trainwreck. I don't want to go near systemd for the same reason I don't want to go near OpenBSD; the development culture is just so different from what I'm used to that I want to stay as far away from it as possible. Now if only systemd would extend the same courtesy towards me, but apparently that's not a possibility; optional compliance doesn't seem to be on the roadmap forward.

Of course this goes to a General Resolution

Posted Feb 13, 2014 13:52 UTC (Thu) by HelloWorld (guest, #56129) [Link]

Sorry, you anti-systemd trolls just keep repeating the same lies over and over and over again. Systemd isn't being forced on anybody, because the systemd supporters don't have any means to do that. And these...
> Apparently an infinite amount of time and a frightening amount of zeal.
...aren't means to force anybody to do anything. Maybe to annoy them on the internet, but then it's really simple to avoid that: just stay out of the discussion entirely. I certainly wouldn't be writing this if you hadn't spread false accusations and lies about systemd and its developers and supporters.

In fact, it's the other way around: it's people like *you* who would like to force people like the gnome and Debian developers to continue to maintain and support software stacks that they themselves consider obsolete. Luckily, just like the systemd developers, you don't have any means to do that.

Of course this goes to a General Resolution

Posted Feb 11, 2014 21:18 UTC (Tue) by rodgerd (guest, #58896) [Link]

No-one is forcing you to to systemd. You can run Slackware (although Patrick is talking about possibly moving). You can use LFS. You can eschew DEs that decide running on unmaintained code like ConsoleKit is a bad choice in favour of ones which don't, or you can use DEs that don't provide that functionality.

What you can't do ise demand that the Magic Code Fairies and Rainbow Distribution Ponies work on a bunch of code they've given up on because you want them to.

Of course this goes to a General Resolution

Posted Feb 12, 2014 17:55 UTC (Wed) by HelloWorld (guest, #56129) [Link]

> although Patrick is talking about possibly moving
Now this sounds interesting. When and where did he say that?

Of course this goes to a General Resolution

Posted Feb 12, 2014 20:40 UTC (Wed) by rodgerd (guest, #58896) [Link]

Let me see if I can dig it out...

"It's hard to say whether moving to these technologies would be a good thing for Slackware overall. Concerning systemd, I do like the idea of a faster boot time (obviously), but I also like controlling the startup of the system with shell scripts that are readable ... With udev being phased out in favor of systemd performing those tasks we'll have to make the decision at some point between whether we want to try to maintain udev ourselves, have systemd replace just udev's functions, or if we want the whole kit and caboodle."

http://www.linuxquestions.org/questions/interviews-28/int...

It's not something he's particularly enthusiastic about, but may do anyway.

Of course this goes to a General Resolution

Posted Feb 12, 2014 21:29 UTC (Wed) by jspaleta (subscriber, #50639) [Link]

He seems to be laboring under some misinformation.

The snippet concerning "replacing udev functions" is a red flag concerning the amount of misinformation he's already digested from somewhere. It's going to be extremely hard for him to make a good informed decision if he's relying on factually incorrect information.

Of course this goes to a General Resolution

Posted Feb 12, 2014 22:26 UTC (Wed) by rodgerd (guest, #58896) [Link]

Bear in mind that's an interview from 2012, when the udev discussion was still fresh and emotive.

Of course this goes to a General Resolution

Posted Feb 12, 2014 22:30 UTC (Wed) by jspaleta (subscriber, #50639) [Link]

noted.

-jef

Of course this goes to a General Resolution

Posted Feb 11, 2014 20:19 UTC (Tue) by johannbg (subscriber, #65743) [Link]

Why do people claim that systemd is a Red Hat technology?

Just a bit curios since at the time it came to be Lennart was the only Red Hat employee and he was not acting alone...

Of course this goes to a General Resolution

Posted Feb 11, 2014 20:43 UTC (Tue) by viro (subscriber, #7872) [Link]

At a guess, because Fedora had been the first distro to jump that shark...

Said that, could we _please_ stop all the bullshit along the lines of "clearly so and so are just pushing the interests of their employer and/or have their position forced down their throat by said employer"? Either is a fucking serious accusation to throw around and ought to come with hard proof. And no, "it stands for reason..." doesn't constitute such. Sheesh... Folks, this is really obscene ;-/

Of course this goes to a General Resolution

Posted Feb 11, 2014 21:43 UTC (Tue) by johannbg (subscriber, #65743) [Link]

Hmm I see well if I can recall correctly the order of "jumping the shark" in 2011 was

1. Megoo
2. Fedora
3. Frugalware

So calling Fedora "first" is not entirely accurate nor fair so to speak since Opensuse was already shipping systemd as a tech preview at that time and a lot of other distribution had package it and were thinking about switchin so it really just boiled down to release cycle race who shipped it first that year followed by those who did not switch in 2011 but had it packaged did switch in 2012 with the exception of Gentoo I think.

Anyway if FESCo had not closed the door on us in F14 and told us to come back later we would have without a shadow of an doubt be the first distribution to ship systemd.

And as much as I was in disagreement with that FESCo decision at that time one should give credit where credit is due so everyone can thank them for how well systemd is documented today which was the reason they slammed the door on us in the first place ( lack of proper documentation ) in F14 and I think it's safe to say today systemd is the best documented init system out there.

Of course this goes to a General Resolution

Posted Feb 11, 2014 21:48 UTC (Tue) by jmorris42 (guest, #2203) [Link]

Doesn't really matter which way the decision flows does it?

Option one. Dark cabal at RedHat dictates fundamental changes for their own dark purposes and order their minions to agree or else.

Option two. Decisions are flowing up from the developers at RedHat. Based upon the very different needs of RH vs most other Linux distributions these solutions are very different, intended to solve a different set of problems, and even targeted to a different set of stakeholders.

Doesn't have to be a conspiracy theory. Probably isn't. But either way gets the same result and the same community response except the second would let everyone stop the ad hominum attacks. So lets just assume option two, K?

Of course this goes to a General Resolution

Posted Feb 11, 2014 22:25 UTC (Tue) by mebrown (subscriber, #7960) [Link]

Systemd development is an open process where anybody can submit code, and in fact, many people outside of Red Hat *have*. I don't see the point of saying this is driven by Red Hat, when it's clear from the development logs and mailing lists that it is not.

Of course this goes to a General Resolution

Posted Feb 12, 2014 2:09 UTC (Wed) by vonbrand (guest, #4458) [Link]

Your option one is nonsense. In option two, as other distributions have different needs, they won't adopt systemd at all. What do you worry about?

Of course this goes to a General Resolution

Posted Feb 12, 2014 15:40 UTC (Wed) by jonnor (guest, #76768) [Link]

False dilemma.
The Linux kernel project has proved that despite many stakeholders using it for many different things with different concerns, one can work together to create a solution that not only works for everyone, but works pretty darn good for almost everyone. I see abolutely no reason why the same cannot be done with low-level userland in the systemd project.
And considering the breadth of contributions to it and the usecases it solves, looks like it is off to a good start.

Have you refrained from using the Linux kernel because RedHat is the or one of the major contributors?

Of course this goes to a General Resolution

Posted Feb 14, 2014 9:54 UTC (Fri) by smurf (subscriber, #17840) [Link]

Option three: The systemd people don't just sit in their ivory tower, but actually are present at conferences and hackfests. Everybody is invited to contribute code and ideas to systemd. Problems are actually adressed, even if they happen not to be relevant for RedHat.

… which incidentally is exactly what I see happening.

So let's can the conspiracy theories already.

Of course this goes to a General Resolution

Posted Feb 11, 2014 19:50 UTC (Tue) by viro (subscriber, #7872) [Link]

How about "it would greatly increase the leverage available to a group of people who'd already demonstrated that they are not shy to use whatever leverage they have"? Existence of android will, to an extent, act as a limiting factor for pressure towards the kernel, but debian bending over will very much reduce such limiting factors towards more or less traditional userland.

Personally, I don't like the idea of that bunch in position of power. And no, it's not ad hominem. _Everyone_ makes lousy decisions once in a while; that's not the issue. What worries the hell out of me is the combination of leverage they have and utter lack of restraint regarding the use of that leverage. E.g. Linus is in position to inflict a *lot* of harm on userland projects doing something he considers wrong and stupid. The difference is, he's been very clear about not forcing any kind of, pardon the obscenity, "grand unified vision" on the rest of the world. These guys, OTOH, seem to consider doing just that as a part of their mission, which makes their mistakes extremely dangerous.

Of course this goes to a General Resolution

Posted Feb 11, 2014 20:07 UTC (Tue) by vonbrand (guest, #4458) [Link]

"Those guys" just so happens to include almost everyone working on 'plumbing' for Linux...

Of course this goes to a General Resolution

Posted Feb 11, 2014 20:14 UTC (Tue) by dlang (subscriber, #313) [Link]

> "Those guys" just so happens to include almost everyone working on 'plumbing' for Linux...

no, only those who take the attitude that theirs is the only valid way to do things.

Of course this goes to a General Resolution

Posted Feb 11, 2014 21:07 UTC (Tue) by jspaleta (subscriber, #50639) [Link]

im really not sure that's true.

I believe its more accurate to say that after reviewing existing implementations in the space, they tend to build new implementations which address specific technical short comings of existing implementations, with input of aligned stakeholders in mind.

And I think they bend over backwards with the interface stability promise they make to make a space for competing implementations to do things differently while still conforming to a common interface for applications up the stack to rely on.

I think the systemd devs generally put a lot of thought into what they build and incorporate ideas from elsewhere quite liberally. They've added debianisms into systemd that were not strictly required for fedora/rhel for example even before debian decided to climb on-board the bus.

And I've seen absolutely no indication at all that logind api is being forced on any upstream. upstreams are going to prefer to make use of logind because it better meets their needs than existing solutions. Anyone who needs to continue to rely on consolekit needs to pick it up and carry that ball forward as its been unmaintained now for a while. Anyone who would like to re-implement the logind API with a second implementation that works outside of linux and cgroups, can do so, using whatever technical choices they need, so long as they conform to that stable api that applications expect to see a service provide.

If systemd devs really want to make life difficult for alternative implementations, they could forego the stable interface promise concept entirely and make alternative implementations reverse engineer a constant moving target like we see happen in the web services API space all the time to hamper alternative implementations. But they aren't doing that.

Of course this goes to a General Resolution

Posted Feb 11, 2014 20:09 UTC (Tue) by deepfire (guest, #26138) [Link]

This is, to date, the most clear description of the worries I have over systemd.

Of course this goes to a General Resolution

Posted Feb 12, 2014 11:58 UTC (Wed) by joyuh (guest, #95216) [Link]

Well, the *whole* point of systemd is to have a way to have leverage over the policy of ALL distributions and ALL userland, to allow to implement innovations that are instantly adopted on all Linux systems (being an "init system" is merely incidental).

This improves the current situation, where the only way to change all Linux systems is to change the Linux kernel, which has the issue that kernels cannot contain policy or userspace code, which means that lots of improvements remain half-done, because the "default policy" and userspace code part is missing.

Being able to centrally change policy for all Linux systems is essential for rapid innovation of the platform, and to unify all distributions so that they behave as a single unified platform for developers.

If the people are wrong, anyone can fork systemd and convince people and distributions that their systemd is better than Lennart's.

Of course this goes to a General Resolution

Posted Feb 12, 2014 12:57 UTC (Wed) by viro (subscriber, #7872) [Link]

... which makes a lot of people very nervous about the position of power it puts Lennart et.al. Sure, I could fork systemd. Along with everything that had been, er, integrated into it. Which would leave how much time for e.g. kernel development?

What you consider as weakness (the kernel not forcing "rapid innovation" on everybody) is actually a strength. Do you really _want_ Linus (or me, or Dave Miller, or...) to start imposing our opinions on userland folks? Telling them "if you don't like that, fork the kernel" (... and the normal in-kernel interface churn will make maintaining shared code very painful very soon, so you'd better be ready to do a lot of fun work porting fixes, new drivers, etc.) A major distribution would find it hard to pull that off. Ask anybody involved in maintaining old branches of e.g. RHEL, and that - just with the normal rate of upstream changes. And I can guarantee that I could come up with a bunch of innocent-looking interface changes that would make life hell for folks dealing with filesystems in such forks. Easily. With valid excuses for every change ("it improves X, Y and Z; sure, we could do it another way and it would hurt the other side of fork less - but why should we care either way about them?") Making mournful comments about the evils of fragmentation all the time.

I see three possibilities - a troll, a systemd fanboi or a systemd developer. I wonder which one you are...

Of course this goes to a General Resolution

Posted Feb 12, 2014 14:19 UTC (Wed) by Trelane (subscriber, #56877) [Link]

Do you really _want_ Linus (or me, or Dave Miller, or...) to start imposing our opinions on userland folks?

You do. Pretty regularly. Like systemd, you define the interfaces and capabilities of the kernel and therefor jow userland may interact with it. See for example the discussion on the right way to replace a file on ext.

Perhaps the difference is that they define and change a larger inerface surface.

Of course this goes to a General Resolution

Posted Feb 12, 2014 15:21 UTC (Wed) by viro (subscriber, #7872) [Link]

Sigh... Adding syscalls is one thing; once it's in, we get to maintain it. Equivalents from my "wish I could've done that" list would be something like, say it, "ioctls for control of net devices should be on per-device files somewhere (and read/write instead of ioctl), not on any socket". And there goes the need for net namespace - the real one serves just fine after that. With all access control done by normal mechanisms, instead of ad-hackery. Oh, and no more sysv shmem - just use mmap from tmpfs instance. Userland breaks? Let 'em rewrite it, we have the ultimate upper ground. If they don't like it, they can fork the kernel. And while we are at it, the entire sysv ipc is ucking fugly and could be replaced with saner APIs. And no more /sys/class/net - it's a headache from hell for containers anyway; let them mount per-interface pseudo-filesystem explicitly. Whaddya mean, existing setups will break? We Have Leverage; See Figure One(tm). Oh, and fuck that silliness with creat(2) on a dangling symlink creating the target. It's the last bit of 4.2BSD misdesign remaining since early 80s. What, xemacs and unknown amount of other stuff breaks? Tough, let them fix their fucking code.

Do you want _that_? And yes, all of the above (and many, many other things) would make a lot of things much cleaner. "Rapid improvements", my arse... Try "second-system effect writ real large". With everyone forced to follow (OK, leveraged into following), so that every design mistake we make would spread into a lot of userland code and hit all the systems. Wonderful, innit? If it turns out we'd been wrong, we'll just change it again. Or, if we are cynical enough, suddenly recall the needs of stability and refuse to fix the problem - them's the breaks, we have leverage, you don't like it - you fork it and all such.

Look, there's a place for such strategies. On a research system. If somebody doesn't understand why it's completely wrong attitude for anything approaching "stable application platform", they have no fucking business being anywhere around critical parts of any system until they grow out of their wet dreams period and get a clue.

Of course this goes to a General Resolution

Posted Feb 12, 2014 15:41 UTC (Wed) by andresfreund (subscriber, #69562) [Link]

> Oh, and no more sysv shmem - just use mmap from tmpfs instance.

Gah. You shouldn't have used that example. The kernel's stance WRT sysv ipc comes pretty close to that by refusing to increase the default limits to realistic values (32MB SHMALL!) with the argument that people should just move of it. Despite the fact that there are features in sysv that aren't really easy to replace like querying whether other processes are currently attached to shared memory.
Postgres ended up using both sysv shmem (for the test about other attached processes) and anonymous mmap() (for large amounts of memory, without having to reconfigure the OS).

Sorry for the rant, I had to adjust that value once too often ;)

Of course this goes to a General Resolution

Posted Feb 12, 2014 16:57 UTC (Wed) by joyuh (guest, #95216) [Link]

What does intentionally breaking compatibility have to do with systemd?

Systemd promises to not break its own interfaces, just like the kernel, and they already even have a version number baked in, so that any breaking change is easily doable by adding Interface2 in addition to Interface1.

It also keeps compatibility as much as possible with sysvinit by supporting sysvinit initscripts (including LSB dependencies), the initctl command, etc.

The "rapid improvements" are about adding NEW functionality in a way that is full-featured out of the box without having to wait for each distribution to specifically integrate it, not about breaking compatibility.

For example, let's say SSD were invented today, and you add SSD TRIM functionality to the kernel, and decide that most systems will use it with a "cron job" running fstrim (because it's still too slow to be used on each delete, etc.)

At the moment, you can provide the kernel part to all users by adding it to Linus' kernel, but then you have to wait for Debian, Fedora, SuSE etc. to each individually add the fstrim job, with the risk that they fuck it up somehow.

With systemd, you just add the fstrim unit in the systemd repository, along with an announcement that systemd now requires fstrim, and all distributions will automatically acquire that behavior.

So, by just sending patches to Linux and systemd, you are now sure that all users have your feature working by default, without any need to involve the distributions.

Of course this goes to a General Resolution

Posted Feb 12, 2014 17:15 UTC (Wed) by joyuh (guest, #95216) [Link]

Of course this goes to a General Resolution

Posted Feb 13, 2014 2:11 UTC (Thu) by viro (subscriber, #7872) [Link]

Are you for real? I'm sorry, but do you really mean that you are running the latest-from-git kernel on production boxen? Or expect the majority
of people out there to do the same? The same for systemd, of course...

Stop trolling, really. No, Linus pulling into his tree does *NOT* deliver the modifications to all systems out there. And no, LP pulling into systemd tree will *NOT* do the same thing for systemd changes. Not on Fedora, not on SuSE, not on anything else. The things would be incredibly brittle if they worked that way; they do not.

Of course this goes to a General Resolution

Posted Feb 13, 2014 5:25 UTC (Thu) by joyuh (guest, #95216) [Link]

It does not do so immediately, but it will do so by default in the form you wrote in a bounded amount of time (usually in the next release or the release after that, which means 6-12 months for Fedora and Ubuntu, 2-5 years for RHEL).

On the other hand, if distributions are left to integrate something manually, then by default nothing will happen, and they may or may not do integrate it, possibly after years, and may do so in a way that differst from each other, requiring users to learn all the different dialects.

Also, most distributions have testing, unstable and/or experimental branches where there it might indeed show up very fast (perhaps even immediately if they have buildbots packaging git HEAD continuously)

Of course this goes to a General Resolution

Posted Feb 13, 2014 21:04 UTC (Thu) by jonabbey (guest, #2736) [Link]

> With systemd, you just add the fstrim unit in the systemd repository, along with an announcement that systemd now requires fstrim, and all distributions will automatically acquire that behavior.

You're arguing in favor of systemd here? I'm a big fan of systemd myself, I like the design and all, but making systemd a meta-distribution to rule them all is not going to win it that many friends.

Of course this goes to a General Resolution

Posted Feb 13, 2014 22:47 UTC (Thu) by viro (subscriber, #7872) [Link]

Give man a cigar... That's exactly why I mentioned "a troll" as a possibility.

I don't know who she/he/it is and quick search hasn't turned up anything other than recent lwn posts, so I've no way to tell which variant is more likely. But yes, "the *whole* point of $X is $SOMETHING_INFLAMMATORY and I'm an $X supporter [so surely I can't be just trying to cause a dislike of $X developers]" from anonymous poster certainly can be a troll.

BTW, "pro-$X troll" (or "anti-$X troll") doesn't imply anything about sympathies of the poster - the goal of a troll is amusement from provoked flamefest and assumed position is a matter of tactics...

Of course this goes to a General Resolution

Posted Feb 14, 2014 1:44 UTC (Fri) by joyuh (guest, #95216) [Link]

Well, making distributions more uniform is an explicit current goal of systemd and I think the ultimate goal will indeed be to get rid of distributions altogether and that's why some people are resisting it.

But it is good, because distributions are horrible, and are what is holding the Linux desktop back.

Due to distributions, we have the absurd situation where it is impossible to release software for Linux, since we have two package formats, each distribution calls dependencies what it wants, etc., and you have to go through an ill-defined manual procedure to get your package included in all distributions.

Once distributions are finally eliminated, then developers will be able to release their own packages without going through the distribution maintainers, and decide themselves how they should work and integrate into the system, and deliver them immediately to users upon release.

The question is of course whether systemd will achieve this in time before Ubuntu makes all distributions irrelevant and adds an app store, or Android somehow takes over desktops too, which are the other paths to having a single relevant distribution.

Of course this goes to a General Resolution

Posted Feb 14, 2014 2:08 UTC (Fri) by mgb (guest, #3226) [Link]

This one and only true ultimate non-distribution that you envisage ...
  • Will it be stable like Debian or bleeding edge like Fedora?
  • Will it be a rolling release like Gentoo or a versioned release like Slackware?
  • Will it be free like Ubuntu or $$$ like RHEL?
Is it possible, do you think, that different Linux users have different preferences, and that different distributions cater to those distinct preferences?

Of course this goes to a General Resolution

Posted Feb 14, 2014 2:50 UTC (Fri) by joyuh (guest, #95216) [Link]

In that model, upstreams would necessarily release directly to users, so it would probably work like Firefox on where you choose whether you want releases, betas, alphas or nightlies and automatically get the latest one of what you choose (unless you disable updates).

Which is, you know, what happens on all OSes except on Linux distributions.

Of course this goes to a General Resolution

Posted Feb 14, 2014 3:23 UTC (Fri) by vonbrand (guest, #4458) [Link]

Great idea! That way nobody will be able to try to reproduce your particular problem unless you give the exhaustive list of what exact branches of each piece of relevant software is on your system. That will certainly boost QA productivity sky-high...

Of course this goes to a General Resolution

Posted Feb 14, 2014 4:23 UTC (Fri) by joyuh (guest, #95216) [Link]

That's correct.

But you can trivially automate both the process of giving a list of the exact versions of each piece of software, and the process of building a filesystem that precisely corresponds to such a list.

Currently it's even worse because most distributions, due to their ancient packages and not including all software, force users to install some software on their own, sometimes in a way that isn't tracked by the package manager, which means you can't even produce the list at all.

Of course this goes to a General Resolution

Posted Feb 14, 2014 3:45 UTC (Fri) by viro (subscriber, #7872) [Link]

And there, gentlemen, we have a revelation of the decade. *BSD are Linux distributions. Thus the horrible secrets are coming out - *BSD folks had managed to hide this one for a long time, but joyuh has finally exposed it.

Well, either that, or s/h/it is a bold-faced liar. Or has no idea what it's blathering about. But that wouldn't be anywhere near as interesting, would it? After all, one doesn't need to look further than splashsnot to find thousands of lying and clueless wankers, whereas such discoveries are much more rare. Inexistent, even...

Of course this goes to a General Resolution

Posted Feb 14, 2014 4:16 UTC (Fri) by joyuh (guest, #95216) [Link]

BSDs are mostly irrelevant as full OSes, their only relevant parts are the FreeBSD kernel (since it unfortunately empowers several wannabe-monopolists due to their incorrect license choice) and to some extent OpenSSH and perhaps some other offshoot projects.

They can indeed be considered Linux distributions for the purposes of this discussion, though.

But they are even worse than them, since they even cause fragmentation at the kernel level, making people a bit more reluctant to rely on advances in Linux.

And in fact, accelerating the death of the BSDs will likely be one of the (intentional) effects of systemd.

Of course this goes to a General Resolution

Posted Feb 14, 2014 7:49 UTC (Fri) by anselm (subscriber, #2796) [Link]

I think it is highly unlikely that systemd will get rid of the RPM/dpkg divide anytime soon, let alone Linux distributions.

On the other hand, there is no conceivable benefit in distribution X storing the system's host name in »/etc/HOSTNAME« while distribution Y is using »/etc/sysconfig/hostname«. If systemd's unified early-boot toolkit helps us achieve more cross-distribution consistency in those areas that can only be a good thing.

Of course this goes to a General Resolution

Posted Feb 14, 2014 10:50 UTC (Fri) by Wol (guest, #4433) [Link]

And doesn't systemd make that a configurable option :-)

So you can leave the distro default untouched for old packages that look for it directly, but new packages can query systemd and know that they'll get the answer, without having to worry about where it came from.

Certainly I've wasted enough time on various nixen (RiscOS, SCO, SuSE, Slack, gentoo) trying to hunt it down :-)

Cheers,
Wol

Of course this goes to a General Resolution

Posted Feb 14, 2014 11:16 UTC (Fri) by mchapman (subscriber, #66589) [Link]

> And doesn't systemd make that a configurable option :-)

No, it's hard-coded.

You could leave the old distro-specific file around, but it'd get out-of-sync with the file managed by hostnamed.

Of course this goes to a General Resolution

Posted Feb 14, 2014 12:42 UTC (Fri) by anselm (subscriber, #2796) [Link]

A distribution would be perfectly free to change hostnamed such that it writes the (static) hostname to the old distribution-specific file whenever the hostname is changed through its D-Bus interface.

(Of course that should be considered a temporary measure until the distribution is fixed.)

Of course this goes to a General Resolution

Posted Feb 12, 2014 18:27 UTC (Wed) by josh (subscriber, #17465) [Link]

I'd actually love to see a kernel infrastructure that could enable those kinds of compatibility layers. Imagine a general infrastructure for redirecting a class of syscalls to a userspace helper, that could then implement shm and similar on top of more sensible APIs.

Of course this goes to a General Resolution

Posted Feb 12, 2014 19:13 UTC (Wed) by HelloWorld (guest, #56129) [Link]

> Imagine a general infrastructure for redirecting a class of syscalls to a userspace helper,
Congratulations, you just invented microkernels. Unfortunately, memory management and IPC are among the three things that really have to be in the kernel (the third one being scheduling), so I don't think what you proposed will ever happen.

Of course this goes to a General Resolution

Posted Feb 12, 2014 20:18 UTC (Wed) by josh (subscriber, #17465) [Link]

> Congratulations, you just invented microkernels.

Not at all. This is more along the lines of the compatibility layers glibc has to implement old functionality on top of newer and better kernel bits, except compatible with arbitrary userspace code not using glibc.

> Unfortunately, memory management and IPC are among the three things that really have to be in the kernel (the third one being scheduling), so I don't think what you proposed will ever happen.

Yes, they have to be in the kernel; that doesn't make it impossible to deprecate one family of system calls, ioctls, or similar mechanisms and redirect them to a compatibility layer that calls the new kernel mechanisms.

Of course this goes to a General Resolution

Posted Feb 12, 2014 18:32 UTC (Wed) by rodgerd (guest, #58896) [Link]

Kernel folks already do. The reason there's no equivalent of dtrace shipping as standard in Linux is because the efforts to get one mainlined keep getting nacked by kernel maintainers who don't care how useful it is to end users, it isn't interesting to them.

Of course this goes to a General Resolution

Posted Feb 13, 2014 2:34 UTC (Thu) by viro (subscriber, #7872) [Link]

No, we do not. Kernel *is* loosely coupled with the rest of the system. And that's a deliberate choice. "Integration" is often a weasel-word for being unable to keep interfaces sane and stable. DTrace, OTOH, would have to be very tightly coupled with the kernel. Along with users' dtrace scripts.

We can't maintain stability of that. And if we offered it, we would have to. It's not something that had been there and taken away or broken; it's something we can't give.

Frankly, I consider the common attitude of userland libraries authors simply atrocious. If you can't come up with a clean and stable API, somebody will end up paying the price. And shrugging and dumping that price on users of that library is unacceptable. Exposing DTrace would do exactly that kind of thing.

Of course this goes to a General Resolution

Posted Feb 13, 2014 9:41 UTC (Thu) by HelloWorld (guest, #56129) [Link]

> No, we do not. Kernel *is* loosely coupled with the rest of the system. And that's a deliberate choice. "Integration" is often a weasel-word for being unable to keep interfaces sane and stable.
And loose coupling is often a weasel-word for doing some kind of half-assed job that nobody actually uses because stuff isn't integrated properly. And by the way, systemd hasn't broken its interface stability promise yet. Though it will eventually because of the cgroup changes in the kernel!

So please, stop trolling already.

Of course this goes to a General Resolution

Posted Feb 13, 2014 15:05 UTC (Thu) by nix (subscriber, #2304) [Link]

There's a reason DTrace has stability attributes. Anything you don't want to guarantee will still be present can just be declared unstable: then it won't be visible by default and can go away at any time. (Absolutely everything fbt provides would be an example of such, while the syscall provider's probes would be declared stable, by definition.)

Of course this goes to a General Resolution

Posted Feb 13, 2014 5:31 UTC (Thu) by bojan (subscriber, #14302) [Link]

> Making mournful comments about the evils of fragmentation all the time.

The real argument here being that too much fragmentation is bad (just look at the desktop - a user (and to some degree a developer) of one Linux desktop variant may be utterly confused on another), but so is the existence grand visions (again, just look at the desktop and all the "philosophy" that one needs to swallow, instead of getting a practical tool that most understand). What is really required is middle ground of common sense, reasonableness and flexibility.

The kernel folks seem to have kept cool heads, allowed reasonable and technically valuable things in, making the system versatile, flexible and more or less one thing. Sure, there are always offshoots, but they tend to grow back in from time to time.

Attitude appears to be as important as good code.

Of course this goes to a General Resolution

Posted Feb 12, 2014 18:34 UTC (Wed) by rodgerd (guest, #58896) [Link]

Rapid? Try, say, "widespread use of cgroups in practical contexts". The facility has been in the kernal for a third of the kernal's life. General use arrived with systemd.

This is the heart of the problem

Posted Feb 13, 2014 3:36 UTC (Thu) by dlang (subscriber, #313) [Link]

This isn't just a technical debate. I think that this exchange really hits the core of the systemd divide.

from Joyuh

>> Well, the *whole* point of systemd is to have a way to have leverage over the policy of ALL distributions and ALL userland, to allow to implement innovations that are instantly adopted on all Linux systems (being an "init system" is merely incidental).

from viro

> ... which makes a lot of people very nervous about the position of power it puts Lennart et.al.

with more details at https://lwn.net/Articles/585428/

I'm with viro on this, NOBODY should have that sort of power over ALL Linux distributions.

David Lang

This is the heart of the problem

Posted Feb 13, 2014 4:06 UTC (Thu) by rodgerd (guest, #58896) [Link]

Do you spend a similar amount of time and energy inveighing against glibc?

This is the heart of the problem

Posted Feb 13, 2014 5:10 UTC (Thu) by dlang (subscriber, #313) [Link]

the glibc developer was hard to get along with, but I don't remember any cases of him talking about or using his leverage over the policy of ALL distributions and ALL userland,

I also don't see any of the existing glibc maintainers doing anything similar.

In the kernel discussion there is frequently the statement "provide the mechanism, don't force a policy". Glibc development seems to follow this as well.

This statement isn't just that policy belongs in userspace, it means that policy belongs under the control of the distro and/or admin of a system and that there are multiple policies that make sense under different conditions, no one Grand Plan will fit every condition.

I avoid Gnome because they have a similar attitude to systemd, and I'm concerned about Wayland because I'm afraid that they are slipping into that mode (X11 arguably went overboard in the mechanism not policy direction but I'm concerned that they may be overcorrecting with Wayland)

This is the heart of the problem

Posted Feb 13, 2014 5:51 UTC (Thu) by Cyberax (✭ supporter ✭, #52523) [Link]

> the glibc developer was hard to get along with, but I don't remember any cases of him talking about or using his leverage over the policy of ALL distributions and ALL userland,
Really? Do you remember the strlcpy() debacle? Or maybe refusal to add versioning mechanisms that could allow newer glibc to be used to compile binaries for earlier glibc versions?

The latter actually causes quite a LOT of pain for binary-only publishers.

This is the heart of the problem

Posted Feb 13, 2014 15:52 UTC (Thu) by madscientist (subscriber, #16861) [Link]

You can have your own strlcpy() in a trivial number of lines of code. Personally I'm in the camp that says these functions are no better than what we have, and are in some ways worse (at least with a buffer overflow you can detect it using lots of tools available for this, including things that could be LD_PRELOAD'd at runtime; incorrectly truncated buffers is in many ways a much more insidious security problem, and it cannot be detected as easily).

And I see absolutely no point in having glibc support compiling for older versions (and I've done embedded and cross development work for most of my career). It would add a lot of maintenance headache, AND it's completely trivial to get the same results without all that complexity and _much_ more reliably: you simply have to provide the --sysroot flag to your builds and point it to an older set of libraries and headers. Done.

Heck, I was implementing this years ago before GCC had decent support for it and it required an obscure set of flags, but it still worked then. Now it's a no-brainer.

I don't think we can call recommending that people use entirely more suitable, reliable, and maintenance-free methods to achieve the same goals "leveraging policy".

This is the heart of the problem

Posted Feb 13, 2014 20:40 UTC (Thu) by Cyberax (✭ supporter ✭, #52523) [Link]

> You can have your own strlcpy() in a trivial number of lines of code.
Look at glibc's implementation of string functions. They are not trivial.

> And I see absolutely no point in having glibc support compiling for older versions (and I've done embedded and cross development work for most of my career).
I have Ubuntu 14.04

How do I compile a binary for RHEL5?

> It would add a lot of maintenance headache, AND it's completely trivial to get the same results without all that complexity and _much_ more reliably: you simply have to provide the --sysroot flag to your builds and point it to an older set of libraries and headers. Done.
No, not done. It requires to create a completely separate build environment with all the required libraries. It's easier to install a complete OS in a chroot at that point.

This is the heart of the problem

Posted Feb 13, 2014 20:55 UTC (Thu) by dlang (subscriber, #313) [Link]

> It's easier to install a complete OS in a chroot at that point.

This is your answer to the RHEL 5 question above. glibc is the least of your worries, every other library you use is a problem as well.

the thing is that you don't have to do this for every distro you want to use, you just do it for the oldest one and newer ones almost always work.

this is backwards compatibility of the systems, things build for older systems keep working on newer systems.

I know that you praise the ability of the windows monoculture to set a flag and have the resulting binary work for that old version, but with multiple competing vendors it's not that easy to point at an arbitrary 'old' version of some other companies work.

This is the heart of the problem

Posted Feb 13, 2014 21:26 UTC (Thu) by Cyberax (✭ supporter ✭, #52523) [Link]

I can realistically avoid using every other library or in a pinch simply package them along with my application.

But not glibc. It can't be packaged or avoided.

This is the heart of the problem

Posted Feb 16, 2014 2:55 UTC (Sun) by dlang (subscriber, #313) [Link]

sure you can. It may not be trivial, but there are several other libc implementations, and some people do use them instead of glibc

but even if you use glibc, the glibc developers can't implement policy in your apps by implementing some new function, they can only do it if they change an existing function.

so while they can break or change something they currently do, they can't take over other functions at a whim

This is the heart of the problem

Posted Feb 16, 2014 5:11 UTC (Sun) by Cyberax (✭ supporter ✭, #52523) [Link]

Nope. It sounds easy but when you try to mix uclibc and glibc things go downhill. Fast. And it's extremely easy to pull in glibc accidentally. By depending on libgl, for example.

This is the heart of the problem

Posted Feb 13, 2014 22:42 UTC (Thu) by madscientist (subscriber, #16861) [Link]

> Look at glibc's implementation of string functions. They are not trivial.

Nevertheless, writing a strlcpy() is trivial. There are even lots of free implementations available for you. If you want versions that take advantage of all the performance tweaks for your particular hardware platform, that is much more work, sure.

> I have Ubuntu 14.04. How do I compile a binary for RHEL5?

Very simple. I've done it many times. You go get copies the RPMs or an installation ISO (if you don't want to pay for RHEL licensing you can get CentOS instead: it's binary compatible). You extract the RPMs into some directory on your system (this is simple because rpm is packaged for Debian and Ubuntu). Then you add "--sysroot=<extractdir>" to your compile and link lines.

Done and done.

> No, not done. It requires to create a completely separate build environment with all the required libraries. It's easier to install a complete OS in a chroot at that point.

That's just not true. In fact, I think chroots are a pain the ass because they require root privileges etc. I never use them. Even for creating RPMs (which ostensibly do require root access) I use fakeroot which is just the bees knees.

I have a complete build environment with my own GCC/binutils/make/flex/bison/m4/gdb, all the latest versions, and various different sysroots, and I can build my code soup to nuts including generating .deb and .rpm files with no special privileges (sudo etc.) and zero reliance on the underlying distribution: I may use Mint 14, someone else uses CentOS 6.4, someone else uses Ubuntu 13.10, and they all generate the same code and it works on any distribution RHEL 5.5 or up (or earlier, if I wanted it to). The entire thing can be tarred up and sent around and requires NO special packages installed on or configuration added to the build systems. And a further advantage is that I always know exactly what my system dependencies are (because I have to put them into the sysroot, which, since it's just for compiling/linking, doesn't need any other libraries to run a real system): no opportunities for accidentally pulling other libraries.

Now. My code is more system-level and so doesn't rely on GNOME libraries, etc. However, glibc is actually the LEAST problematic library, because while the glibc folks don't add the ability to generate code that runs on older releases, they DO very carefully and strictly maintain the ability to run code that was compiled for older releases on newer ones. This is a lot of effort on their part but it's hugely important. I can build a single binary that runs on versions of glibc that shipped with distributions 8 years old, or more, and all the ones in between.

If only the OpenSSL people cared so much :-/.

This is the heart of the problem

Posted Feb 13, 2014 22:45 UTC (Thu) by madscientist (subscriber, #16861) [Link]

(when I say "extract the RPMs", above, I only mean the lib and devel RPMs for the libraries you need to link with, of course, not all the RPMs in the distro!! So, for example, glibc, glibc-common, glibc-devel, glibc-headers, zlib, zlib-devel, libtermcap, libtermcap-devel, etc.)

This is the heart of the problem

Posted Feb 14, 2014 0:38 UTC (Fri) by Cyberax (✭ supporter ✭, #52523) [Link]

> Nevertheless, writing a strlcpy() is trivial. There are even lots of free implementations available for you. If you want versions that take advantage of all the performance tweaks for your particular hardware platform, that is much more work, sure.
We are not talking about 2-line version of strlcpy(), we're talking about optimized SSE-using version with automatic CPU detection. Like the other stuff in glibc.

> Very simple. I've done it many times. You go get copies the RPMs or an installation ISO (if you don't want to pay for RHEL licensing you can get CentOS instead: it's binary compatible).
Now try to compile the recent Boost library with this. I know because I did - it's not trivial.

Then there's CMake which helpfully tries to find packages from the usual include/library directories. At least, the recent versions of pkg-config got better than they used to be.

It's easier to simply do a complete chroot installation (perhaps with fakeroot).

> Now. My code is more system-level and so doesn't rely on GNOME libraries, etc. However, glibc is actually the LEAST problematic library
Wrong. glibc is THE most problematic library in the Linux stack. Bar none.

I can trivially package all other libraries along with my application. ALL of them (well, except maybe some libcrazy that does something perverted with ld).

Let me tell you how I'm developing applications for Windows XP on Win 8.1 (that's 12 years distance in time). I take MSVS 2012, setup a project, set the compatibility level to WinXP and that's it. All the unavailable system functions are automatically masked by WINVER guards and I can trivially bundle the new MSVCRT libraries along with my application.

This is the heart of the problem

Posted Feb 14, 2014 8:55 UTC (Fri) by khim (subscriber, #9252) [Link]

I can trivially package all other libraries along with my application. ALL of them (well, except maybe some libcrazy that does something perverted with ld).

Really? How well libGL packaged with your application works? How about libasound? Or may be libcups? How well they work on different distributions if bundled?

GLibC is one of the least problematic libraries: if you exclude purely-computatiuonal libraries which you can bundle with your app then you'll find out that GLibC is in fact one of the most stable and most well-supported libraries.

Then there's CMake which helpfully tries to find packages from the usual include/library directories.

Then it must be fixed, right? It's hard to blame GLibC for bugs in some separate, totally unrelated package.

I admit that Microsoft does better job, but then again: it, too, recommented to use old version of it's product to target old versions of Windows not too long ago, right? In reality to support XP “under the hood” MSVC does the same thing GLibC recommends to do BTW. It's called multitargeting there. The only advantage is that in Windows world these things are well-integrated and rarely bite while in Linux world everyone does this in their own separate fashion and there are rough edges everywhere. But this is problem if Linux fragmentation, not GlibC design.

This is the heart of the problem

Posted Feb 14, 2014 10:12 UTC (Fri) by mchapman (subscriber, #66589) [Link]

> Really? How well libGL packaged with your application works? How about libasound?

Bad examples. Plenty of proprietary Linux games are packaged exactly like this.

This is the heart of the problem

Posted Feb 14, 2014 17:51 UTC (Fri) by khim (subscriber, #9252) [Link]

Really? I've seen quite a few of them and they never include libGL. libGLU? Sure. libGLEW? Yes, sometimes. libGL? Never.

This is the heart of the problem

Posted Feb 14, 2014 18:32 UTC (Fri) by mjg59 (subscriber, #23239) [Link]

…and which libGL would you ship? Mesa? Nvidia's? fglrx's?

This is the heart of the problem

Posted Feb 14, 2014 23:52 UTC (Fri) by Cyberax (✭ supporter ✭, #52523) [Link]

Yes, really. I wrote an application (about 10 years ago) that used Mesa's libGL for high-quality (like 4096x4096 printer-quality images) software rendering.

Of course, packaging libGL that depends on hardware is not really a good idea. But you certainly _can_ do it.

This is the heart of the problem

Posted Feb 15, 2014 11:58 UTC (Sat) by khim (subscriber, #9252) [Link]

If you want to play such a crazy tricks then yoy can distribute GLibC, too. We don't distribute GLibC with our programs here, but we do have a GLibC packages here which are distributed independently from distributions we are using them on and which are used by most of the software developed in house thus I know it's quite possible to do.

This is the heart of the problem

Posted Feb 15, 2014 19:01 UTC (Sat) by nix (subscriber, #2304) [Link]

btw, it's called 'glibc' or 'the GNU C Library". It isn't called 'GLibC'.

This is the heart of the problem

Posted Feb 15, 2014 2:07 UTC (Sat) by mchapman (subscriber, #66589) [Link]

> Really? I've seen quite a few of them and they never include libGL. libGLU? Sure. libGLEW? Yes, sometimes. libGL? Never.

You are correct. I got mixed up between my GL libraries.

This is the heart of the problem

Posted Feb 14, 2014 12:18 UTC (Fri) by Cyberax (✭ supporter ✭, #52523) [Link]

>Really? How well libGL packaged with your application works?
Works just fine.

>How about libasound?
Ditto.

>Or may be libcups? How well they work on different distributions if bundled?
Haven't tried that.

>I admit that Microsoft does better job, but then again: it, too, recommented to use old version of it's product to target old versions of Windows not too long ago
AFAIR, that was a beta bug. I distinctly remember using the newest MSVS to compile binaries for WinXP SP2. Ah, here's a blog post that confirms this: http://blogs.msdn.com/b/vcblog/archive/2012/06/15/1032064...

> In reality to support XP “under the hood” MSVC does the same thing GLibC recommends to do BTW.
Nope. Multitarteting is --sysroot analog, but it's rarely necessary.

And I stand by my statement - glibc is literally the worst library in Linux. Bar none.

This is the heart of the problem

Posted Feb 14, 2014 17:45 UTC (Fri) by khim (subscriber, #9252) [Link]

AFAIR, that was a beta bug.

Not even close. MSVC 2012 RTM had no support for XP at all.

Ah, here's a blog post that confirms this: http://blogs.msdn.com/b/vcblog/archive/2012/06/15/1032064...

Have you actually tried to read said blog post? Later this fall, Microsoft will provide an update to Visual Studio 2012 that will enable C++ applications to target Windows XP means “you can target Windows XP just yet”, you know.

Nope. Multitarteting is --sysroot analog, but it's rarely necessary.
Well, Microsoft claims that it is necessary if you want to target WIndows XP. You can use some clever tricks to target Windows XP without doing that but they are even more fragile than multitargeting.

And I stand by my statement - glibc is literally the worst library in Linux. Bar none.

Well, Ok. Since by now we know that you are all too ready call black white and even ready to “stand by your statements” by adding links which state that black is indeed black and white is indeed white further discussion is completely useless. Because it's quite hard to discuss anything with someone who blatantly ignores logic.

This is the heart of the problem

Posted Feb 14, 2014 23:48 UTC (Fri) by Cyberax (✭ supporter ✭, #52523) [Link]

>Have you actually tried to read said blog post? Later this fall, Microsoft will provide an update to Visual Studio 2012 that will enable C++ applications to target Windows XP means “you can target Windows XP just yet”, you know.
Look at the date. It was in 2012 and the update with XP support was issued in 2013. It was true that initially MSVC12 did not support XP.

>Well, Ok. Since by now we know that you are all too ready call black white and even ready to “stand by your statements” by adding links which state that black is indeed black and white is indeed white further discussion is completely useless. Because it's quite hard to discuss anything with someone who blatantly ignores logic.
It's a matter for another thread, but I have other arguments (like schizophrenic API).

This is the heart of the problem

Posted Feb 14, 2014 16:46 UTC (Fri) by madscientist (subscriber, #16861) [Link]

> We are not talking about 2-line version of strlcpy(), we're talking about optimized SSE-using version with automatic CPU detection. Like the other stuff in glibc.

I don't understand. Why do you think that the glibc implementation of strlcpy() would have all that stuff in it? Did someone write that implementation and contribute it and it was rejected? If so then you can just use that yourself. If not, then most likely if strlcpy() _was_ added to glibc it would just be the simple, unoptimized version you would write yourself. The _fact_ is that there's absolutely nothing preventing anyone from using strlcpy() in their program, any time they want. There's no need for glibc to include it. And even if some newer version of glibc DID include it, how many years would it be before you could rely on it being present on your target systems and remove your own implementation?

> Now try to compile the recent Boost library with this. I know because I did - it's not trivial.

We use Boost 1.53. I don't know if you consider that "recent" or what might have broken in Boost since then, but I don't remember having any particular problem when I built it (for third party stuff like this we build it once then use the results). We also use ICU, MPIR, google coredumper, unixODBC, etc.: we also compile all our build tools like this so we don't have to worry about the version of Linux on our build systems, so GCC, gdb, binutils, bison, flex, make, m4, cmake, git, python, etc.

> I can trivially package all other libraries along with my application. ALL of them (well, except maybe some libcrazy that does something perverted with ld).

I never pack system libraries with my software. If I did, then I'd be on the hook for tracking and providing security updates any time _any_ of those libraries has a flaw. That's too much work, and no matter how good we are at it, it's still not as good as using the upstream distro's security updates.

I admit, as I said before, I rely on a relatively modest set of low-level system libraries that are fairly stable: no Qt, GTK, etc. But we're talking about glibc here anyway. Glibc uses weak binding, versioned symbols, etc. to avoid having to change the major soversion which makes it completely painless to support. Libraries like libcrypto, libssl, libcurl, etc. just bump the major soversion and so are a SERIOUS pain in the rear end.

> Let me tell you how I'm developing applications for Windows XP on Win 8.1 (that's 12 years distance in time).

Lord. Windows is by FAR our most difficult port. For a DLL we build that we need to work with older versions of PHP we have to actually install MSVC 2008 and perform a completely different build with that. Not to mention all the effort needed to install software onto every Windows build machine by hand, set obscure system configuration options to deal with crashes on the headless/unattended build systems, etc. etc. And of course there's all the frustration, expense, and annoyance with getting licensing for all of it.

> Wrong. glibc is THE most problematic library in the Linux stack. Bar none.

You're wrong. Simple as that.

This will be my last post on the matter since we obviously cannot make progress here. I'm going back to using my straightforward environment that requires no chroot, su, or sudo, is 100% relocatable wherever you want to install it, can be bundled into a tarball and copied to a different system without extra packages or configuration, and generates the same result, where that result runs on every Linux system from Red Hat EL 5 or newer and does not require any statically-linked libraries and does not ship any system libraries and still works fine, and which I've been using to ship enterprise products to real customers for years.

This is the heart of the problem

Posted Feb 14, 2014 20:20 UTC (Fri) by mathstuf (subscriber, #69389) [Link]

> I don't understand. Why do you think that the glibc implementation of strlcpy() would have all that stuff in it?

glibc does load-time resolution of symbols based on CPU capabilities. I call memcmp in my code, but it is resolved to __memcmp_sse4_1 at runtime. Sure, a compat/strlcpy.h works, but it wouldn't be as fast as __strlcpy_ssse3. Looking at my glibc, it seems that there would be optimized versions of strlcpy:

0000000000103cf0 T __strcpy_chk
00000000000930d0 T __strcpy_small
0000000000086070 t __strcpy_sse2
0000000000098ae0 t __strcpy_sse2_unaligned
0000000000153250 t __strcpy_ssse3

This is the heart of the problem

Posted Feb 14, 2014 20:34 UTC (Fri) by madscientist (subscriber, #16861) [Link]

> glibc does load-time resolution of symbols based on CPU capabilities.

Yes, I definitely know that. But my point is that the existence of these highly optimized versions of strcpy() doesn't magically get you a highly optimized version of strlcpy(). There are plenty of functions in glibc which have not been optimized in this way, and there is no particular reason to believe that strlcpy() would magically get this support just by being included.

Someone needs to do that work, and even if the glibc developers could be convinced to add strlcpy() etc. to the library that's no guarantee they'd be motivated to generate highly-optimized versions.

And if someone WAS motivated to generate highly-optimized versions, then those could be used external to glibc just as easily (in fact, possibly more easily since you wouldn't have to worry about which glibc version you were using).

This is the heart of the problem

Posted Feb 14, 2014 21:35 UTC (Fri) by jimparis (subscriber, #38647) [Link]

> Wrong. glibc is THE most problematic library in the Linux stack. Bar none.
>
> I can trivially package all other libraries along with my application. ALL of them (well, except maybe some libcrazy that does something perverted with ld).

Joey Hess seems to claim that shipping glibc with your application is also not hard: https://joeyh.name/blog/entry/completely_linux_distributi...

This is the heart of the problem

Posted Feb 14, 2014 23:50 UTC (Fri) by Cyberax (✭ supporter ✭, #52523) [Link]

You can realistically do it only by using Docker-like containers or some deep linker magic.

This is the heart of the problem

Posted Feb 17, 2014 21:52 UTC (Mon) by jimparis (subscriber, #38647) [Link]

Does that mean that you didn't read the link, that his approach doesn't work, or that you just don't consider it realistic? It seems pretty straightfoward to me: ship glibc and ensure that you execute your binaries through the shipped dynamic linker. I'm curious to know why you don't consider that acceptable?

This is the heart of the problem

Posted Feb 14, 2014 17:28 UTC (Fri) by hummassa (subscriber, #307) [Link]

> I have a complete build environment with my own GCC/binutils/make/flex/bison/m4/gdb, all the latest versions, and various different sysroots, and I can build my code soup to nuts including generating .deb and .rpm files with no special privileges (sudo etc.) and zero reliance on the underlying distribution

would you please be so kind and teach us how you do that?

This is the heart of the problem

Posted Feb 14, 2014 23:00 UTC (Fri) by madscientist (subscriber, #16861) [Link]

I'm not sure what "that" you are referring to?

I build GCC et.al. by running configure and make, as per the README. I have a fancy makefile I wrote that does this. I create the sysroots as described in my previous posts: I get the RPMs and use rpm2cpio to unpack them into a directory, then when I compile and link my code I add the --sysroot=<dir> flag pointing to that directory. You might have to go through the sysroot and replace absolute symlinks with relative symlinks; I have a little Perl script that does this but it's easy enough to do by hand. You only need to do it once (or anyway, once every time you change your base operating system).

This is the heart of the problem

Posted Feb 15, 2014 13:22 UTC (Sat) by hummassa (subscriber, #307) [Link]

I think the "that" I referred to was "a complete build environment with my own GCC/binutils/make/flex/bison/m4/gdb, all the latest versions, and various different sysroots" etc.

IOW, do you already, and if not, would you/ could you PLEASE (pretty please with chantilly and a cherry on top) publish your specialized makefile and perl script that enables you to do all those things authomagically? :D

I can throw in the promise of a beer (or other appeasing beverage/ edible with one hour of my arguably agreeable companionship and conversation) whether and whenever we are geographically close...

This is the heart of the problem

Posted Feb 15, 2014 14:44 UTC (Sat) by madscientist (subscriber, #16861) [Link]

Since I did this as part of my work I'm not free to just publish it all without asking. But I'll check and see what can be done.

This is the heart of the problem

Posted Feb 15, 2014 19:03 UTC (Sat) by nix (subscriber, #2304) [Link]

You might want to look at the buildroot project.

This is the heart of the problem

Posted Feb 16, 2014 18:36 UTC (Sun) by liw (subscriber, #6379) [Link]

I have something vaguely similar as my personal CI system.
http://git.liw.fi/cgi-bin/cgit/cgit.cgi/jenkinstool/ if you want to
have look.

Beware: I wrote this for myself. It's not designed to be clean or
easy to setup, and I don't particularly want to support it, but you
can have a look.

Basically: a) a VM that runs Jenkins b) a VM for each environment (stable vs unstable, i386 vs amd64) where builds happen c) an apt repository (using reprepro) to hold packages built by CI d) successfully built packages get uploaded to the repo automatically e) builds use the repo in addition the Debian once and so groups of dependent packages can be built within the CI system.

Some day I may have time (or someone to pay me to hvae time) to make
that easier for others to do.

This is the heart of the problem

Posted Feb 13, 2014 8:14 UTC (Thu) by rodgerd (guest, #58896) [Link]

> the glibc developer was hard to get along with, but I don't remember any cases of him talking about or using his leverage over the policy of ALL distributions and ALL userland,

> I also don't see any of the existing glibc maintainers doing anything similar.

Guess that incident refusing to add BCD types to the standard libraries as part of a huge dummy spit about a C standards update never happened then.

Not that that's the point, anyway. If you have a principle, it ought to apply everywhere. When you only invoke it as you find convenient, and ignore it otherwise, it's not really a principle any more, is it?

If you have a principled objection to systemd on the grounds it may wield unreasonable power in the userland, then your principle applies equally to any key plumbing, and you should be championing parallel implementations of other key infrastructure.

This is the heart of the problem

Posted Feb 13, 2014 11:14 UTC (Thu) by dlang (subscriber, #313) [Link]

it's not just "may wield unreasonable power", it's "have shown a track record of doing so and see nothing wrong with using any leverage they have to force changes"

refusal to add something is part of the 'hard to get along with' issue, but that's very different from using their position to force changes in policy across all distros.

Especially since for glibc, if you want to create patches that add those functions, you can do so and maintain such patches with very little impact on the rest of the glibc codebase, nothing else needs to change,

while glibc is on every system, unless the glibc maintainers start changing how existing library calls work, they aren't going to be exercising the type of control that the systemd maintainers have already demonstrated that they consider routine and a good thing.

where the glibc maintainers have refused to implement the strlcpy function, what we are talking about here would be more like them deciding to redefine strcpy to be strlcpy and eliminating the old capability entirely (after all, you can always make your own library, fork it, or LD_PRELOAD something to override it...)

What we are talking about here is the package mantainers mandating that ALL distros change how they act in some farily fundamental ways, due to the release of a new version of the package. And don't forget the stated plan of taking over more things in the system going forward.

This is the heart of the problem

Posted Feb 13, 2014 12:08 UTC (Thu) by Cyberax (✭ supporter ✭, #52523) [Link]

>What we are talking about here is the package mantainers mandating that ALL distros change how they act in some farily fundamental ways, due to the release of a new version of the package.
So the libc->glibc transition is already forgotten? How swift the time passes...

This is the heart of the problem

Posted Feb 13, 2014 12:29 UTC (Thu) by dlang (subscriber, #313) [Link]

how was the libc -> glibc forced by the glibc folks? I remember that the distros made the change indpendently and over several years.

but again, you are (possibly deliberately??) missing the point. the problem isn't a single library or tool be used across multiple systems, the problem is the abuse of power that results if the authors of said tool choose to use it.

again, look at the quote I'm replying to:

> Well, the *whole* point of systemd is to have a way to have leverage over the policy of ALL distributions and ALL userland, to allow to implement innovations that are instantly adopted on all Linux systems (being an "init system" is merely incidental).

the glibc transition was not 'instantly adapted' and the glibc developers have not been pushing disruptive changes. the worst they can be accused of is reluctance to implement changes that some other people want.

glibc also has trouble forcing policy, it can provide new capabilities, but it can't force them to be used. Unless it breaks existing functionality, it isn't forcing anything.

This is the heart of the problem

Posted Feb 13, 2014 14:15 UTC (Thu) by mathstuf (subscriber, #69389) [Link]

Can you point to any major functionality changes in systemd which were implemented after systemd was widely (say, three or five major distros) adopted where there was zero to minimal discussion or feedback integrated without a competent rationale? If not, then it doesn't seem to me that Lennart, Kay, or any other developer is forcing behavior changes down the distro's throats. I'd say things that happened *before* adoption don't count because they were known during the transition process.

This is the heart of the problem

Posted Feb 13, 2014 14:58 UTC (Thu) by dlang (subscriber, #313) [Link]

well, there's the journal, unless you want to claim that it happened before systemd was "widely adopted"

There was no discussion or feedback on it before it was announced, and a huge amount of FUD and misinformation spewed about the 'horrors' of syslog that it was replacing (as well as a lot of misleading at best claims about it's capabilities)

or, what about udev? that wasn't part of systemd, and as others have noted, they have made it hard for people to continue to use udev without sucking in the rest of systemd. this happened long after udev was standard on many distros.

This is the heart of the problem

Posted Feb 13, 2014 15:51 UTC (Thu) by mathstuf (subscriber, #69389) [Link]

I figured journalctl would be the first example :) . It did come out after I started using systemd, so it is after Fedora at least. So for this, we'd need to look upstream, IRC logs (which is where much of the discussion took place, I suspect), and any hackfests. Systemd devs could also help inform here ;) . The distros which were using it at that point would be Fedora, Arch, and maybe Mageia (I may be missing some though), so I'd buy that it was after some adoption. I don't remember 'horrors' being mentioned, but I do remember some misunderstanding of rsyslog's feature set at least.

It does do things that syslog does not do (such as querying for related info from the kernel, early boot logging, fast filtering, color, FSS, etc.). I think rsyslog has picked up some of these things, but still not all. I also think that even if the journal were just a shim between systemd and syslog, it'd still be wanted to ensure capture of bits from the kernel before shuttling off to syslog (which is a supported mode). Also, if rsyslog implements the journal API to systemd, you probably could use it instead (though journalctl might be high-and-dry then).

For udev, the udev developers were amenable to it. The systemd developers didn't just clone and merge the repo and tell them "we own it now" (it was an upstream decision to make anyways). IIRC, it was that the two were too interdependent (hardware triggered startup, .mount targets, etc.) and it was making collaboration harder.

This is the heart of the problem

Posted Feb 13, 2014 19:46 UTC (Thu) by dlang (subscriber, #313) [Link]

rsyslog can capture the same things from the kernel that systemd does (it may not capture everything today, but there's no reason it couldn't capture anything that is desired)

rsyslog gathers the early boot logs from the kernel after it starts. the journal would need to do the same thing if it starts at the same time as rsyslog (and if it starts earler to gather more, why don't you start rsyslog earlier as well)

I don't think you have any idea of the amount of filtering that rsyslog can do. I know that LP didn't when the journal was added. color is a display thing, not part of the log. FSS didn't do what it claimed, and rsyslog now has the equivalent that actually works.

there is no need to have journal as a shim between the app and rsyslog other than the fact that the systemd developers mandate it.

rsyslog does implement the published API to the journal. however this does not allow rsyslog to replace the journal, because the internal API to the journal is not stable, running without the journal is 'unsupported'

as far as udev goes, the fact that distros are still using udev without using systemd indicates that your claim that they have to be used together is false. The problem is that the developers have repeatedly opposed the idea of making it possible to build udev without building all of systemd. I don't think people have submitted patches to do so (but I wouldn't be surprised if they had) because they have been so vocal in saying that they would reject any such patches.

This is the heart of the problem

Posted Feb 13, 2014 21:50 UTC (Thu) by paulj (subscriber, #341) [Link]

FSS? That's the new cryptographic protocol to try secure the logs which journald implemented even before it had even been published, never mind peer-reviewed? I note there is at last a paper available for it: http://eprint.iacr.org/2013/397.pdf .

Can you expand on it not doing what was claimed? How serious is the discrepancy?

This is the heart of the problem

Posted Feb 16, 2014 3:20 UTC (Sun) by dlang (subscriber, #313) [Link]

as many people noted when it was announced, if the logs are stored locally they can be tampered with. you may not be able to modify the file in place, but you can create a complete replacement, with all the signing in place.

It requires interaction with an outside system to make a tamper-proof log, either to send signatures elsewhere or to get a token that cannot be recreated with only data on the local system.

This is the heart of the problem

Posted Feb 13, 2014 21:57 UTC (Thu) by peter-b (subscriber, #66996) [Link]

> FSS didn't do what it claimed, and rsyslog now has the equivalent that actually works.

Yeah, that'll be a [citation needed], please.

This is the heart of the problem

Posted Feb 14, 2014 9:25 UTC (Fri) by smurf (subscriber, #17840) [Link]

rsyslog starts up much later and is prone to miss some things. All the userspace output from jobs started before rsyslog used to be lost before the journal came along, and some systems spew more kernel logs up to that time than the kernel has buffer space for.

You can tell the thing to be totally transparent if you don't like it.
Though I wonder why you'd want to – "systemctl status FOO" prints the last couple of a job's journal entries. Which is something I never expected I'd *not* want to do without.

Also, I don't want rsyslog to filter output for the simple reason that I won't know whether I'll need it before the fecal matter has actually encountered the rotating air circulation facilitator.

Also², rsyslog is just text, so there's exactly one sort criterion when all is said and done (the file name). The journal has so many ways to filter for the output you're actually interested in it's not funny, shows you possible values for fields …

I do wonder what's going on here. I mean, "the output from daemons gets lost when you use sysv-rc, so that's The Unix Way. systemd captures that stuff and doesn't even use an externel helper for that, so it's not Unix, so it's Monolithic Evil" is not a technical argument, it's religious.

This is the heart of the problem

Posted Feb 16, 2014 3:44 UTC (Sun) by dlang (subscriber, #313) [Link]

> rsyslog starts up much later and is prone to miss some things.

so start it earlier

>You can tell the thing to be totally transparent if you don't like it.

well, I haven't messed with the journal personally, but the people who have that I trust tell me that it doesn't actually work, and it's still a performance problem.

to be fully transparent, the journal would need to lookup all the trusted properties from SCP_CREDENTIALS, then forge them for the message to rsyslog that's a pretty significant amount of work to do for high log rates.

> Also, I don't want rsyslog to filter output for the simple reason that I won't know whether I'll need it before the fecal matter has actually encountered the rotating air circulation facilitator.

well, that's up to you. you were talking about filtering capabilities, rsyslog can send everything as-is, split it to different destinations, normalize the messages, reformat them, etc.

If you want everything in one place you can do that, if you want things splitup or put into any of a bunch of different types of datastores, you can do that as well.

> Also², rsyslog is just text, so there's exactly one sort criterion when all is said and done (the file name). The journal has so many ways to filter for the output you're actually interested in it's not funny, shows you possible values for fields …

You keep saying that "syslog is text only", what data is it that actually needs to be binary?

rsyslog will deliver the messages to many different things, including the systemd journal if that's where you want it, but it can do that in addition to everything else.

> I do wonder what's going on here. I mean, "the output from daemons gets lost when you use sysv-rc, so that's The Unix Way. systemd captures that stuff and doesn't even use an externel helper for that, so it's not Unix, so it's Monolithic Evil" is not a technical argument, it's religious.

the output from daemons gets lost if you want it to get lost.

random garbage from stderr is not log data, and mostly it's absolutely useless (look at the apache error log for example), having an option to feed it into a logging system is great, pretending that it is all good log data is showing inexperience.

systemd has a lot of things that would be great if they were options to be used when they make sense. But they cause problems when they are made mandatory under all conditions.

There are companies out there that take the attitude that they know better than their customers what the customers want, and they can be very successful if pushing customers to buy what they offer, but that is not what Open Source or Free Software is supposed to be about.

Free and Open Software is supposed to be about empowering the users, and that includes making it possible for the users to do things differently from what the developers imagined. Unless there is a lot of configurablity (like the Linux Kernel has), "Monolithic Evil" is less a religion than it is an observation.

This is the heart of the problem

Posted Feb 13, 2014 19:54 UTC (Thu) by dlang (subscriber, #313) [Link]

by the way, I think the journal is what got a lot of people's attention to the systemd "absorb everything, even if we don't understand it" attitude. everything prior to that was really much easier to swallow. but the actions and attitudes since that point concern a lot of people.

Of course this goes to a General Resolution

Posted Feb 11, 2014 21:08 UTC (Tue) by rodgerd (guest, #58896) [Link]

> 1. Systemd is alien tech

sysvinit was "alien tech" compared to the historic BSD init.

And don't quote "do one thing...". What one thing does sysvinit do, and how does it do it well?

Of course this goes to a General Resolution

Posted Feb 12, 2014 4:35 UTC (Wed) by mbt (guest, #81044) [Link]

Rather than present a bunch of strawman arguments as the position of the systemd objectors, it would be nice to see technical objections listed. Here are some.

1. Good software engineering puts a premium on clearly delineated modules having well documented interfaces. Modules should avoid having too close of an idea of the internals of other modules. This kind of clear separation serves both to make the whole more maintainable and also to facilitate testing. This is not a Unix-only characteristic! I have found this out in many years of being a programmer.

It would be a wonderful thing to be able to build a system with some of the modular components enabled and some disabled and, better still, be able to make some of the components stand alone where that is reasonable and possible. Yes, that would mean the possibility to package some of the components separately. That's part of the benefit of modularity.

The systemd approach, by contrast, is to put everything together into one whole. If you don't need all the things in it, too bad. One case in point: multiseat. This seems to have been one of the biggest drivers behind systemd and also Gnome's dependence on systemd, yet it is hard for me to imagine why such an esoteric usage case is even desirable, let alone have its complicated code and configuration being imposed on *every* system that uses systemd.

The Gentoo developers asked really nicely for a build option in systemd to allow building udev only; they even submitted patches. No. The package was not to be modularized that way. (If you want an in-the-flesh example of embracing and extending, you need look no further than udev.)

To the objection that the kernel, like systemd, is monolithic, let me observe that the kernel has *thousands* of configuration options. You can tune it to quite a degree; it can be really big or really small. There's a little bit of choice available in systemd, like whether to include an HTTP server (??!!!??), but for the most part, you get the whole thing.

2. How do you get to systemd? This process which is supposed to run at PID 1 has open sockets, sits on top of an IPC system, has logging and configuration files all over the place, handles device events, makes hooks for a GUI tool, and deals with a stream of login credentials (which come from outside the system, remember). This presents a *HUGE* attack surface. It's almost an engraved invitation to mischief. There is, unfortunately, a continual pattern of exploits being discovered in software packages. Nearly all of these packages are much more modest than systemd, and many are much older. How much will you like systemd when zero-day exploits start showing up?

3. One other word about modularity. Lots of big packages--Apache, MySQL, Postgres, KDE, Python, and PHP come right to mind--are cross-platform and have quite a number of build options. Many of these options are for the purpose of fitting into one environment or the other. Now there will have to be configurable adaptations in some of these packages to accomodate systemd. Why can't systemd have the same kind of configurability?

4. The third argument leads into the fourth. One reason to design a package with rather few build options is because there has not been enough developer time and user experience with it to make the options. Systemd development has gone at a frenetic pace, and even now it seems poised to continue to add to its feature set. To wit: it is growing; it is still not mature. I don't consider it stable enough to use.

Of course this goes to a General Resolution

Posted Feb 12, 2014 5:36 UTC (Wed) by jmorris42 (guest, #2203) [Link]

Those are also great objections. However those are technical ones which the Technical Committee has in theory addressed. The point of my post was in pointing out that the objections to systemd also go beyond the technical and cross into the philosophical and political realms so I concentrated on objections which supported that assertion.

If mine are all invalid or easily addressed this issue is probably closed and thee and me[1] lost a fair fight. If I'm right the fun ain't even started in earnest yet. Debian has great processes to answer technical questions but questions without such an answer can get messy.

[1] More like thee lost since I'm only a fairly recent convert to Debian and not a developer.

Of course this goes to a General Resolution

Posted Feb 12, 2014 6:20 UTC (Wed) by Cyberax (✭ supporter ✭, #52523) [Link]

> 1. Good software engineering puts a premium on clearly delineated modules having well documented interfaces.
Then you're in luck! Systemd has clearly defined external interfaces with a stability guarantee.

>It would be a wonderful thing to be able to build a system with some of the modular components enabled and some disabled and, better still, be able to make some of the components stand alone where that is reasonable and possible.
And again, you're in luck! Most of systemd dependencies are either trivial or can be turned off.

> The Gentoo developers asked really nicely for a build option in systemd to allow building udev only; they even submitted patches. No. The package was not to be modularized that way. (If you want an in-the-flesh example of embracing and extending, you need look no further than udev.)
They affected only the build system, not the end result.

>2. How do you get to systemd? This process which is supposed to run at PID 1 has open sockets, sits on top of an IPC system, has logging and configuration files all over the place, handles device events, makes hooks for a GUI tool, and deals with a stream of login credentials (which come from outside the system, remember). This presents a *HUGE* attack surface.
And so does the variety of tools that are used for all this stuff right now.

>4. The third argument leads into the fourth. One reason to design a package with rather few build options is because there has not been enough developer time and user experience with it to make the options.
Nope. Keeping the set of variants to the barest possible minimum is good. For example, Linus had resisted forking Linux into a 'server' and 'desktop' variants - with great results.

Of course this goes to a General Resolution

Posted Feb 12, 2014 22:38 UTC (Wed) by mathstuf (subscriber, #69389) [Link]

> They affected only the build system, not the end result.

Seeing as it is Gentoo and users tend to build from source, avoiding that cost if the end result wasn't wanted might be a goal. Maybe a "./configure; make udev; make udev-install" would work instead in the ebuild?

Of course this goes to a General Resolution

Posted Feb 13, 2014 0:57 UTC (Thu) by ABCD (subscriber, #53650) [Link]

That is effectively what the ebuild does, but there are a lot more targets required for both the make udev and make udev-install type targets, as well as needing to pass the proper arguments to ./configure, some of which are to try to disable dependencies that upstream considers mandatory (because they are needed for systemd itself, but not for systemd-udevd).

Of course this goes to a General Resolution

Posted Feb 13, 2014 5:11 UTC (Thu) by mbt (guest, #81044) [Link]

Sigh. Let's look at some of the issues.
> Then you're in luck! Systemd has clearly defined external interfaces with a stability guarantee.
Stability is a good thing. What is not so fun is the great deal of disruption required to get to stability. Besides that, I'm really surprised that the systemd maintainers can be so sure that they've reached that point. It is certainly not to say that they've put in a huge amount of effort. I'm just saying that's a *lot* of public interface to be sure that you've got it set in stone.

Consider one package that certainly has the right to say that its API is in a really stable state: TeX. It's at version 3.14159265, a position to which it has taken more than 30 years to converge. TeX does just one thing--very, very well. It took more than 10 years to get into a reasonably fixed state. And that's from a guy who has a legendary concern with program correctness. Call me somewhat less impressed by systemd's stability guarantees.

Actually, the point I was raising was not about the external API, important as that is. I was looking at the major components (core process-starter/stopper, device-event handler, CGroups manager, logger, cron manager, login/session manager, power management, and others I have likely missed). Why are they not separable? I notice a FD.O has a page on minimal builds for systemd, but I have not found documentation on what you get by enabling or disabling some of the components and how well supported the resulting system would be.

> And again, you're in luck! Most of systemd dependencies are either trivial or can be turned off.
I notice the Gentoo ebuilds for systemd don't have USE flags to control whether to build components like logind. That is very telling since Gentoo loves configurability. How well does systemd work with some of its "optional" components missing? It would be nice to have some clarity.

The build process to get a standalone udev is painful. It is meant to be an indivisible part of systemd, yet it is (still) separable. To build just udev you have to build all of the core systemd, and then separate out just the udev parts. This also means hoping that sometime in the future they don't make a hard dependency between the actual systemd daemon and the udev component. This kind of hard dependency has already befallen logind: since systemd-205 the Gentoo developers have been unable to make a standalone logind because logind is now inextricably bound with the cgroups controller. Did there really *have* to be such a tight binding? I absolutely do not think so. All the same, if you want logind, you must allow systemd to assimilate you.

Re. the attack surface that systemd's many interfaces present:
> And so does the variety of tools that are used for all this stuff right now.
In current systems, an attacker might never be sure of the mix of components. Given the variety of init systems, loggers, cron daemons, power-control systems, and such in current Linux installations, a one-size-fits-all attack is harder to mount. Systemd, by contrast, stands for a monoculture of system components. Biology tells us a lot about the dangers of monocultures.

> Nope. Keeping the set of variants to the barest possible minimum is good. For example, Linus had resisted forking Linux into a 'server' and 'desktop' variants - with great results.
Linux manages a truly impressive thing. A single codebase works for generating kernels from the whole gamut from watches to supercomputers. There are no forks, but there are more than 3000 configuration options. The range of things you can get out of the kernel sources are well supported. I stand in awe of those developers.

Of course this goes to a General Resolution

Posted Feb 13, 2014 6:05 UTC (Thu) by Cyberax (✭ supporter ✭, #52523) [Link]

> I'm just saying that's a *lot* of public interface to be sure that you've got it set in stone.
Yup. And they're committed to supporting it. And we have assurances of that from RedHat.

> Consider one package that certainly has the right to say that its API is in a really stable state: TeX.
Funny you mentioned it. It's a great example. The core is indeed very simple and robust, but modules that are required to do anything real are most certainly not.

I wanted recently to render my thesis written in 2000 in TeX. Turned out that the recent MikTex no longer can compile it. And I had to go and fix some of the modules used.

Oh, and all of the text is written in KOI-8R encoding and it's not that trivial to make some of the new editors to switch text encodings.

> Actually, the point I was raising was not about the external API, important as that is. I was looking at the major components (core process-starter/stopper, device-event handler, CGroups manager, logger, cron manager, login/session manager, power management, and others I have likely missed). Why are they not separable?
Why should they be? BTW, power manager is separate.

> I notice the Gentoo ebuilds for systemd don't have USE flags to control whether to build components like logind. That is very telling since Gentoo loves configurability. How well does systemd work with some of its "optional" components missing? It would be nice to have some clarity.
Perfectly fine. I'm using it with only journald (and udev, of course) on embedded devices. I even removed localed and other auxilaries.

> In current systems, an attacker might never be sure of the mix of components. Given the variety of init systems, loggers, cron daemons, power-control systems, and such in current Linux installations, a one-size-fits-all attack is harder to mount.
You need only one chink in the armor to get in. Are you sure that your syslog daemon is not subverted by NSA?

>Systemd, by contrast, stands for a monoculture of system components. Biology tells us a lot about the dangers of monocultures.
Computing is not biology. And I'm a computational biologist.

> Linux manages a truly impressive thing. A single codebase works for generating kernels from the whole gamut from watches to supercomputers. There are no forks, but there are more than 3000 configuration options.
Yet the process scheduler has only single implementation.

Of course this goes to a General Resolution

Posted Feb 13, 2014 7:52 UTC (Thu) by mathstuf (subscriber, #69389) [Link]

> In current systems, an attacker might never be sure of the mix of components. Given the variety of init systems, loggers, cron daemons, power-control systems, and such in current Linux installations, a one-size-fits-all attack is harder to mount.

We all run a single kernel codebase and I'm sure spender or PaXTeam could tell you all about the problems you have running it before you stack stuff on top of it.

And besides, are you really arguing that having a pile of stuff that attackers can't deal with it anyways? Have you seen the stuff that gets worked around by people? Do you really expect every sysadmin to require such a diverse skillset just to deal with whatever heterogeneity in their system set may be?

For logind and cgroups, logind uses a DBus API to talk to the single cgroup manager. What else can it do in the New World Order of cgroups? If you implement that API (like, say, systemd-shim), you can get away with not using systemd as PID 1.

Of course this goes to a General Resolution

Posted Feb 14, 2014 19:50 UTC (Fri) by smurf (subscriber, #17840) [Link]

> core process-starter/stopper

If you want to stop processes you need to be PID 1, otherwise you get a race condition.

> device-event handler,

Starting processes depends on events.

> CGroups manager,

When you start a server you need to put it in a CGroup.

> logger,

On-disk logging is separate. In-memory logging cannot be, since you want to start logging before root is even mounted.

> cron manager,

Because cron jobs don't just depend on the time of day, these days. They depend on being on AC power, or on the database running, or whatever. So best handled within the

> login/session manager,

separate.

> power management

For instance, shutting down? init needs to cleanly stop all its children and then exec something that's in RAM, otherwise the root file system cannot be unmounted cleanly.

You seem to forget that all these jobs need to closely communicate with each other, need to run all the time, need to serialize their internal state if they're to be updated without rebooting (i.e. you cannot just kill and restart your event handler and expect that everything is magically still hunky-dory.

So you either deal with five processes and their communication overhead and the subtle race conditions which are *certain* to crop in … or you put all of this into one single-threaded program which always has consistent local state which you can serialize safely if you want to re-exec yourself after an upgrade … and which you call "pid 1", necessarily.

In summary, can we please stop pretending that Lennart & Co. (a) put all of this into one huge binary that/s /sbin/systemd, (b) cobbled the part that _is_ PID 1 together out of spite, or because they didn't know better? 'Cause, you know, it's quite obvious that they actually thought about this and had/have sound technical reasons.

Of course this goes to a General Resolution

Posted Feb 18, 2014 17:23 UTC (Tue) by HelloWorld (guest, #56129) [Link]

> If you want to stop processes you need to be PID 1, otherwise you get a race condition.
You mean because orphans are reparented to init? That can be avoided with prctl(PR_SET_CHILD_SUBREAPER). So I don't really see why systemd needs to run as PID 1 instead of, say, 2 nowadays.

Of course this goes to a General Resolution

Posted Feb 18, 2014 18:44 UTC (Tue) by smurf (subscriber, #17840) [Link]

Thanks, I wasn't aware of the SUBREAPER call.

Anyway, the point isn't whether it's possible to run systemd as PID-2. You'd still need a way to signal PID-1 that it should please pivot its root file system to the RAM disk and exec /shutdown, so that your root file system can be unmounted cleanly. And probably some other minor quibbles that seem perfectly solvable, but also completely unnecessary when you can just have the features in PID-1.

Which begs the question: why bother? I still haven't seen any reason what the advantage of running systemd as pid-2 (or pid-2+pid-3+pid-4) would be. "Clean separation of responsibilities into separate processes" is not an argument I can accept, because they all need to run continuously and they all need to talk to each other, so you get increased complexity for no net gain.

Of course this goes to a General Resolution

Posted Feb 19, 2014 10:15 UTC (Wed) by HelloWorld (guest, #56129) [Link]

> You'd still need a way to signal PID-1 that it should please pivot its root file system to the RAM disk and exec /shutdown, so that your root file system can be unmounted cleanly.
Why is it PID 1 who needs to do that?

> Which begs the question: why bother? I still haven't seen any reason what the advantage of running systemd as pid-2 (or pid-2+pid-3+pid-4) would be.
The kernel will panic if PID 1 crashes, so it should be as simple as possible. Now, systemd never actually crashed on any of my systems, but why take the risk if you don't have to?

Of course this goes to a General Resolution

Posted Feb 19, 2014 11:06 UTC (Wed) by mchapman (subscriber, #66589) [Link]

> The kernel will panic if PID 1 crashes, so it should be as simple as possible. Now, systemd never actually crashed on any of my systems, but why take the risk if you don't have to?

I think the alternative complicates things.

If systemd running as PID 2 and marked as a child subreaper were to crash, then its children would be inherited by PID 1. Even if PID 1 were to restart systemd, the new systemd wouldn't be able wait on those reparented processes any more. PID 1 would be responsible for reaping them when they exit, and PID 1 would need to pass on notifications to that effect to the systemd process (so that it could re-exec them or whatever).

In short, I think using a separate child subreaper brings as many problems as it solves.

Of course this goes to a General Resolution

Posted Feb 19, 2014 11:34 UTC (Wed) by smurf (subscriber, #17840) [Link]

> Why is it PID 1 who needs to do that?

*Every* program which holds a file open on the root file system (or any file system, for that matter) needs to either exit, or exec() a program within the new (RAM disk) root. Otherwise you cannot unmount the root FS.

PID-1 may not exit. Therefore it's its job to exec the last step. PID-2 cannot do that. (OK, it could call the unmount-and-reboot program on the RAM disk after triggering PID-1 to exec a new init there, but again: what would be the point of that additional complexity?)

Of course this goes to a General Resolution

Posted Feb 12, 2014 6:21 UTC (Wed) by josh (subscriber, #17465) [Link]

> This process which is supposed to run at PID 1 has open sockets, sits on top of an IPC system, has logging and configuration files all over the place, handles device events, makes hooks for a GUI tool, and deals with a stream of login credentials

Almost none of the things you described live in PID 1. udev, logind, and journald all live in separate processes. And as for "login credentials", systemd actually goes to great pains to never invoke NSS from PID 1.

Of course this goes to a General Resolution

Posted Feb 12, 2014 12:01 UTC (Wed) by joyuh (guest, #95216) [Link]

The Linux kernel has a far larger attack surface and is full of local exploits anyway, so you should generally assume that all users have root privileges.

Use VMs or seccomp if you want to run code with reduced privileges.

Of course this goes to a General Resolution

Posted Feb 12, 2014 20:45 UTC (Wed) by Wol (guest, #4433) [Link]

> If you don't need all the things in it, too bad. One case in point: multiseat. This seems to have been one of the biggest drivers behind systemd and also Gnome's dependence on systemd, yet it is hard for me to imagine why such an esoteric usage case is even desirable,

Let me explain why it is desirable. You have a powerful computer at home (mine is 16Gb ram, X3 processor, 1Tb disk).

My wife objects to computers everywhere (and we don't have much space for them, anyway).

At which point I start cursing because she's hogging the computer!

With multiseat I can just use the same computer (and I've tried connecting over X - it is *appallingly* laggy :-(

For those people who grew up with multiseat (ie started on minis or mainframes), it just seems the natural way to do things - and with modern powerful PCs, it seems even more natural!

Fortunately I've got a spare computer I can switch over to systemd to test out multiseat before I send it live on our main system.

Cheers,
Wol

The Debian technical committee vote concludes

Posted Feb 11, 2014 20:43 UTC (Tue) by ikm (subscriber, #493) [Link]

Reading all that systemd talk, I wonder what would happen if I apt-get installed it on sid right now. Would it work or break my system? Would it replace sysvinit? Would I be able to easily and properly roll back if I didn't like the result? And above all, would I really gain anything practically useful by doing this?

The Debian technical committee vote concludes

Posted Feb 11, 2014 20:51 UTC (Tue) by mpr22 (subscriber, #60784) [Link]

If you just apt-get install systemd, you get some more files on your system but nothing else happens. You have to either install systemd-sysv, or configure your bootloader to pass init=/bin/systemd on the kernel command line, to make systemd be your init system. You might or might not have issues depending on what else you have installed. Whether you would gain anything of direct practical use to you depends on whether your system has any issues that systemd's enhancements would make less problematic. I don't know how easily you can roll back.

The Debian technical committee vote concludes

Posted Feb 11, 2014 21:00 UTC (Tue) by zuki (subscriber, #41808) [Link]

> I don't know how easily you can roll back.
If you used "init=/bin/systemd", then just remove this line. If you used systemd-sysv, uninstall this package and install a replacement. Not hard at all. :)

The Debian technical committee vote concludes

Posted Feb 11, 2014 21:35 UTC (Tue) by ikm (subscriber, #493) [Link]

Just tried it. Time from kernel boot to Firefox was around 1:07 with sysvinit, became 1:03 or so with systemd - due to high error margin, I'd say it didn't change. I did get the console login prompt faster, though I see no practical use for this given that I use X11. Speaking of services, mysql and apache worked, nginx didn't - had to start it manually.

Tried to reboot twice - the first time it worked like a charm and was really fast, but the other time it got stuck. Much to my amusement and resentment, sysrq-u and sysrq-b did not work - said on the console that it was disabled. What is that supposed to be, really? The whole point of magic sysrq is that it's always there for me. At least sysrq-s did work. Had to press reset manually then.

I'll wait till Jessie releases and switch to whatever gets to be default there. Before that I felt like I was in favor of systemd - now I'm not so sure. I did not like the attitude which was shown to me by disabling my precious magic sysrq. And now I feel relieved it's not my call to decide this.

The Debian technical committee vote concludes

Posted Feb 11, 2014 21:53 UTC (Tue) by drago01 (subscriber, #50715) [Link]

That's because you mostly have sysvinit services and not native systemd units.

The Debian technical committee vote concludes

Posted Feb 11, 2014 23:44 UTC (Tue) by proski (subscriber, #104) [Link]

Your kernel.sysrq setting in sysctl must have changed from 1 to some other value. See Documentation/sysrq.txt in Linux sources for the bitmap. Check /etc/sysctl.d and /etc/sysctl.conf for a line that sets kernel.sysrq.

I don't think the behavior of SysRq should change just because systemd is installed, so it could be considered a bug.

The Debian technical committee vote concludes

Posted Feb 12, 2014 0:04 UTC (Wed) by cortana (subscriber, #24596) [Link]

$ grep sysrq /usr/lib/sysctl.d/50-default.conf
kernel.sysrq = 16

$ dpkg -S /usr/lib/sysctl.d/50-default.conf
systemd: /usr/lib/sysctl.d/50-default.conf

The Debian technical committee vote concludes

Posted Feb 12, 2014 0:17 UTC (Wed) by jspaleta (subscriber, #50639) [Link]

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=725422

Let me sum up for you...

systemd upstream ships what they consider as safe default for the general case. It is possible for local admins and distribution vendors to override this default with an additional config file on the system.

Debian systemd maintainers so far don't see a reason to diverge from the default value as local admins who are choosing to switch over the systemd as an alternative init can drop in local systemd config to get whatever mask is appropriate for local policy. There is an expectation that when flipping over to an alternative init, you are going to need to reconfig to some extent.

Now that systemd is going to be the new default, this is one of the integration issues that is going to end up being a Debian policy discussion as to what is the best default mask to use for new installs and the debian systemd maintainers may need to diverge from upstream to accommodate Debian policy on that.

And the harder problem is how to adequately deal with upgrades for systems that have a different mask value set locally via legacy mechanisms. Answering this question may require developing a technical solution to migrate local configs as part of that upgrade. This is exactly the sort of work that was blocking on systemd being chosen as a default. Now the systemd is a default choice, the upgrade case becomes much more important.

The Debian technical committee vote concludes

Posted Feb 12, 2014 7:51 UTC (Wed) by ovitters (subscriber, #27950) [Link]

Within Mageia they just override that default to what it originally did.

The Debian technical committee vote concludes

Posted Feb 12, 2014 8:19 UTC (Wed) by jspaleta (subscriber, #50639) [Link]

right... its going to come down to distro policy with regard to what the config their users get as defaults. Debian policy could easily result the same override that Mageia chose, now that systemd will be the default init, without the discussion over the default override being a big deal. Clearly vendors and local admins have the freedom of movement to reconfigure.. its a config... not a hardcoded build time setting.

The Debian technical committee vote concludes

Posted Feb 17, 2014 14:19 UTC (Mon) by nye (guest, #51576) [Link]

>https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=725422

> Let me sum up for you...

> systemd upstream ships what they consider as safe default for the general case.

Woah, that's pretty eye-opening. Suddenly I'm finding myself less pro-systemd, and far more sympathetic to those complaining about overreach.

First, that's a setting that systemd has no business touching; it's entirely outside its remit.
Second, assuming I've understood the meaning of the mask correctly, that default is mad; it's clearly not in any way sane for the general case. An argument could be made for setting it to 48 or 80 (I'd disagree vehemently, but I can see that the argument could be made), but just 16 is almost completely useless because there's no point in being able to sync buffers if you can't also stop them being dirtied.

This is the sort of policy change that you'd never notice until it bit you, and it makes me wonder how many other unrelated policy changes systemd might be making behind my back when I start using it, and how I would know about them before it's too late. I'm especially worried about this because that particular choice is a strong signal that the people in question have dangerously poor judgement when it comes to picking defaults.

The Debian technical committee vote concludes

Posted Feb 17, 2014 17:44 UTC (Mon) by jspaleta (subscriber, #50639) [Link]

I have no sympathy for this issue. The distibution maintainers have authority over what the configuration is they ship.

What in particular am I unable to do on my Fedora workstation right now with the mask set to 16 that I have so far not noticed?

The default is arguable. Fine. Most defaults are. Your distribution vendor can ship the config that makes sense to meet their distribution policy.


The Debian technical committee vote concludes

Posted Feb 17, 2014 17:51 UTC (Mon) by andresfreund (subscriber, #69562) [Link]

> What in particular am I unable to do on my Fedora workstation right now with the mask set to 16 that I have so far not noticed?

Restart a crashed server?

2 - enable control of console logging level
4 - enable control of keyboard (SAK, unraw)
8 - enable debugging dumps of processes etc.
16 - enable sync command
32 - enable remount read-only
64 - enable signaling of processes (term, kill, oom-kill)
128 - allow reboot/poweroff
256 - allow nicing of all real-time tasks

I see pretty little reason to not allow 16, 32, 128 for local keyboards. And it's not like you easily hit those by accident like it was the case with the X key combo.

The Debian technical committee vote concludes

Posted Feb 17, 2014 18:02 UTC (Mon) by mjg59 (subscriber, #23239) [Link]

Local access to the keyboard isn't the same thing as physical access to the machine. The argument that the default should be "Permit no harm" isn't unreasonable.

The Debian technical committee vote concludes

Posted Feb 17, 2014 18:07 UTC (Mon) by andresfreund (subscriber, #69562) [Link]

In the vast majority it's the same. I am not aruing there isn't a usecase of changing the default, but that it's annoying to just change longstanding defaults. Especially if it's likely to only be noticed exactly when the shit has hit the fan.

The Debian technical committee vote concludes

Posted Feb 17, 2014 18:12 UTC (Mon) by jspaleta (subscriber, #50639) [Link]

It's been noticed.... both in Debian and in Megeia as provided a distro config to override the upstream setting. Debian will need to decide what to do to best meet Debian policy as part of transitioning to systemd as default.

The Debian technical committee vote concludes

Posted Feb 17, 2014 18:09 UTC (Mon) by jspaleta (subscriber, #50639) [Link]

Restart a crashed server? Again I asked specifically about my workstation workload. What's a sane default for my workstation workload?

The best value for a particular workload is arguable. I'm not arguing it isn't. All I'm saying is that 16 appears to be sufficient for my workloadand my usage pattern.

And I am saying is that whatever the _default_ is upstream, distribution vendors are going to have to evaluate that and then provide an override configuration and provide the _default_ that makes sense for their distro policy. And then individual admins will then override that distro default with a value that best meets their own local policy or need.

We are talking about a default config value. It needs to be something, and arguing over a reconfigurable default can quickly become bikeshedding.

The Debian technical committee vote concludes

Posted Feb 17, 2014 18:16 UTC (Mon) by andresfreund (subscriber, #69562) [Link]

> Restart a crashed server? Again I asked specifically about my workstation workload. What's a sane default for my workstation workload?

Well, then make it "restart a crashed workstation". Trying to loose as little data as possible. In which case you want to do a sync, remount readonly, sync, boot. Which isn't possible anymore.

I think the cases where you do want it disabled primarily is internet cafes and such, but you need to change so much for that that one more sysctl to change isn't a problem.

> We are talking about a default config value. It needs to be something, and arguing over a reconfigurable default can quickly become bikeshedding.
We are talking about *changing* a longstanding default value.

The Debian technical committee vote concludes

Posted Feb 17, 2014 18:28 UTC (Mon) by mjg59 (subscriber, #23239) [Link]

If it's crashed enough that I need to use sysrq then sysrq+s is going to be good enough to leave a journalled filesystem in a consistent state. I've got a power button that'll do the rest.

The Debian technical committee vote concludes

Posted Feb 17, 2014 18:30 UTC (Mon) by andresfreund (subscriber, #69562) [Link]

If X crashed that's not necessarily sufficient. Often enough you can't switch to a VT without SAK/unraw but stuff in the background is still writing.

The Debian technical committee vote concludes

Posted Feb 17, 2014 18:38 UTC (Mon) by mjg59 (subscriber, #23239) [Link]

In which case you've still got network access and can do a clean shutdown instead.

The Debian technical committee vote concludes

Posted Feb 18, 2014 10:21 UTC (Tue) by nye (guest, #51576) [Link]

>In which case you've still got network access and can do a clean shutdown instead.

Matthew, I know you're a smart guy: can you hear yourself right now? Do you realise how absurdly unreasonable your position has become in just a couple of posts?

Imagine you're trying to talk to somebody being as willfully obstructive as you currently are; would you feel that they are having a discussion in good faith, or just taking a position out of contrariness because they like to argue?

The Debian technical committee vote concludes

Posted Feb 18, 2014 15:17 UTC (Tue) by mjg59 (subscriber, #23239) [Link]

The claim is that this change makes it impossible to reboot a crashed server without losing data. That's really just not true. If a system is wedged enough that userspace isn't running then all you need is the ability to sync, and if userspace *is* running then you're almost certainly able to reboot the system cleanly (which is a preferable situation to be in - just because the filesystem is consistent doesn't mean that your data is). For no real change in your ability to recover servers you gain physical access to the keyboard no longer providing the ability to trivially DoS the running system.

The Debian technical committee vote concludes

Posted Feb 20, 2014 13:05 UTC (Thu) by nye (guest, #51576) [Link]

>The claim is that this change makes it impossible to reboot a crashed server without losing data

No, the post you were responding to was not about servers; the topic was about workstations by that point. This is a crucial difference, because workstations often don't even have any kind of remote network access configured at all, and even when it is, it isn't the normal way to access them.

As it happens, I was actually bitten very mildly[0] by this problem last weekend while trying out OpenSUSE, though at the time I just assumed it was the distro that had made the weird choice of default. The situation there is that shutdown had apparently hung, and I wanted to reboot the machine without just hitting the reset button.

Doing that remotely would have required that I'd enabled the ssh server (not sure if I'd got that far), go downstairs, turn on my partner's computer, see if I could guess her password, download an SSH client, get my SSH key from a backup, and finally log in to the machine in question and start the laborious process of sending signal 15 to every process (I'm sure there's an easy way to do that, but I don't know it because the magic sysrq key has always been the easiest way to do it). Except that I'm pretty sure this happened after the network had been brought down, so all that would have been for naught.

Contrived? Maybe, but certainly less uncommon than somebody trying some kind of shared kiosk system using only out of the box default configurations.

>For no real change in your ability to recover servers
Somebody obviously thought this feature was a real change, for it to have been implemented in the first place

>you gain physical access to the keyboard no longer providing the ability to trivially DoS the running system.

One: You don't actually gain that, because that requires so many other changes that setting this one option is trivial in comparison. It is obviously the case that the default set up for any system requires that a person with access to the keyboard be able to reboot the machine, and changing that for some specific use case is going to mean massive changes to the running environment. So why bother setting just this one option, probably the easiest part of the job, when the actual task you appear to be doing it *for* is so much larger?

Two: You are giving some highly contrived example of an extremely specific, wildly unusual custom requirement, and using it as an explanation for changing the default for everyone. This is exactly the kind of thing people are talking about when they complain about insane defaults; defaults should be selected for the common case, not the most weird case you can think of, *especially* when that case will require enormous additional work anyway.

Both of these two points apply to servers just as well as workstations BTW, however for servers the effect is mitigated somewhat because remote login is a more realistic scenario.

[0] I say 'very mildly' because in this case it was a test system where I didn't care much about the outcome, and waiting a few minutes for some timeout to happen allowed it to continue anyway. The problem is correlated with having cifs shares in fstab, and I think the issue is that systemd doesn't know that bringing down the network needs to be done *after* unmounting those shares, but I've not yet investigated what the recommended modern way is of configuring network mount. Probably not 'just stick it in fstab like it's 1999', anyway.

The Debian technical committee vote concludes

Posted Feb 17, 2014 18:45 UTC (Mon) by jspaleta (subscriber, #50639) [Link]

yawn.. take it up with your distro vendor and make sure they override it as part of the transition to using systemd as default... as part of the init system changeover from the.. longstanding... default init...sysvinit.

But lets talk historic usage.
On my centos 5 server, using sysvinit for init
the value for the defaults to a value of 0 and is configured in /etc/sysctl.conf

Now what is really interesting is that sysctl.conf file is owned by the initscripts package on centos 5. The initscripts package on centos requires sysvinit.

Now in fedora using systemd, this configuration has been expanded and abstracted so that you can use multiple files in sysctl.d directory similar to how udev rules layer.

So the idea that this is outside of systemd's remit is arguable false in the context of Fedora and Red Hat. systemd as part of replacing sysvinit on these systems needs to also provide the equivalent of sysrq.conf for boot time configuration. systemd goes further and makes this configuration more flexible than what was previously provided.

Now if debian never had a configuration file similar to sysctl.conf for sysvinit scripts to use, then this configuration would be a new feature. Debian could choose to nuke all the sysctl.d files entirely, or replace the values in upstream shipped files, or drop in a vendor specific file to override the upstream supplied defaults. It's completely understandable if systemd provides new, configurable, functionality that Debian policy isn't ready to integrate yet. But again this is a debian policy issue on how to configure this. I'm not going to make any suggestions as to what default setting Debian should use.. its one of the integration issues Debian is going to have to figure out as part of the transition.

The Debian technical committee vote concludes

Posted Feb 17, 2014 18:53 UTC (Mon) by andresfreund (subscriber, #69562) [Link]

> yawn.. take it up with your distro vendor and make sure they override it as part of the transition to using systemd as default... as part of the init system changeover from the.. longstanding... default init...sysvinit.

Well, there are goddamn good reasons to switch away from sysvinit. And I am happy debian does so. But I don't see good reasons for this particular change. And I have yet to see somebody argue why the new value is better.

This doesn't make systemd bad overall. There's no single nontrivial piece of software where I agree with everything. Not even if it's solely written by myself.

The Debian technical committee vote concludes

Posted Feb 17, 2014 19:34 UTC (Mon) by smurf (subscriber, #17840) [Link]

Well, it seems that this simply got carried over from redhat, which has a different default than debian. I wonder whether the systemd porters even noticed.

Actually, being more restrictive makes sense in RH's context. If you have physical access to a locked-down server, all you can do to wreak havoc is to pull the plug or press the power button, which is (a) immediately obvious to monitoring and (b) shouldn't hurt too badly.

On the other hand, if you plug in a keyboard (trivial) and press SysRq+Readonly, the machine will still respond positively to most attempts at monitoring … so that your tampering may not be discovered for hours.

Anyway, something minor like that won't affect my (positive) opinion about the switch.

The Debian technical committee vote concludes

Posted Feb 14, 2014 9:50 UTC (Fri) by smurf (subscriber, #17840) [Link]

Debugging systemd startup is really easy.

# systemctl enable debug-shell.service

After the next reboot, you now have a root shell on TTY9 pretty much immediately after switching out of initrd, which you can use to figure out what the problem is – while normal boot continues. This is IMHO much nicer than sysv-rc and its "boot into single-user and then step through rc3.d to see what breaks and why" method of debugging.

Alternately, if you don't get to a shell prompt, you can boot into an emergency root shell (boot with systemd.unit=emergency.target) which you can use to start the debug shell, and then tell systemd to (try to) continue normally.

This is all documented rather well.

The Debian technical committee vote concludes

Posted Feb 11, 2014 20:56 UTC (Tue) by cuboci (subscriber, #9641) [Link]

If you just installed systemd nothing would change. You'd either have to pass init=/lib/systemd/systemd to the kernel or install systemd-sysv, which would remove sysvinit (but leave sysvinit-core in place). I've tried both ways an nothing broke, on the contrary, it works like a charm.

The Debian technical committee vote concludes

Posted Feb 11, 2014 21:05 UTC (Tue) by rodgerd (guest, #58896) [Link]

There's certainly a bunch of value I've been able to get out of it on some Wheezy boxes, even though it's a very old and not terribly featureful version os systemd: ripping out start-stop-daemon wrappers for sysvinit-not-supplied services and putting them into unit files, adding *.mount dependencies for services I want to stay down if the system isn't in the right state at boot time and so forth.

The Debian technical committee vote concludes

Posted Feb 12, 2014 12:10 UTC (Wed) by HelloWorld (guest, #56129) [Link]

> And above all, would I really gain anything practically useful by doing this?
Well, you'd get the journal, which IMO works much better than classic plain text log files.
Check this out: http://0pointer.de/blog/projects/journalctl.html
I also love the way it's configured. For example, packagekitd used to hog my CPU and IO bandwidth at the most inappropriate times. So I dumped the following lines into /etc/systemd/system/packagekit.service.d/bla.conf:

[Service]
CPUSchedulingPolicy=idle
IOSchedulingClass=idle

Voila, problem solved.And even if a package upgrade modifies the configuration file (/usr/lib/systemd/system/packagekit.service), it won't affect my changes at all. This is only possible because systemd's configuration files are entirely declarative and don't contain any executable code. systemd-delta can show you how the configuration in /etc affects the default configuration shipped in /usr/lib/systemd. For the above example, it prints the line
[EXTENDED] /usr/lib/systemd/system/packagekit.service → /etc/systemd/system/packagekit.service.d/bla.conf

My personal experience is that pretty much regardless of what you want to do, systemd usually offers a much cleaner, terser, more comprehensive and easier solution than what you have to do with sysvinit.

The Debian technical committee vote concludes

Posted Feb 11, 2014 22:10 UTC (Tue) by amacater (subscriber, #790) [Link]

Heat, light, technical (and other) arguments and kvetching: it will, eventually, blow over, with luck.

Thanks to my fellow DDs who make up the Technical Committee who have put in long hours and significant considered thought under pressure from all sides and behaved with as much integrity as could be mustered to the benefit of the Debian Project as a whole.

The Tech. Committee rarely gets called on to resolve matters in this manner and, almost never in such a glare of publicity, both positive and negative.
Thanks to all concerned for their hard work, professionalism and undoubted ability.

We need to wait for a better solution in Jessie+1

Posted Feb 13, 2014 3:06 UTC (Thu) by mgb (guest, #3226) [Link]

Systemd proponents have made it very clear that they wish to standardize and replace the "plumbing" layer across most or all Linux distros.

The problems for Debian are two-fold:

(1) Debian plumbing is in general more capable, more smoothly upgradable, and more stable than Redhat plumbing. Systemd brings with it Redhat plumbing and a long series of unnecessary changes and regressions.

(2) Despite contributions from many authors, Systemd is indubitably under Redhat control. Debian would be the tail on the Redhat dog. Debian would forever be wasting resources trying to keep up and could no longer excel.

Some reject such notions as "toxic conspiracy theories". They are mistaken. No conspiracy is needed. These are the logical and readily foreseeable consequences of good business practice by Redhat, now that the TC has put Debian's neck in the noose.

Systemd has some good (but non-portable) technology. Upstart technology is almost as good and there are no strings attached. However neither is ready for Debian.

For both Debian and Ubuntu, and for F/LOSS ecosystem health and diversity, the best solution would be for Ubuntu to learn from both Systemd and Upstart, immediately drop the Upstart CLA, and start *now* on building a world class Init for Jessie+1.

We need to wait for a better solution in Jessie+1

Posted Feb 13, 2014 3:39 UTC (Thu) by mpr22 (subscriber, #60784) [Link]

Your proposed best solution would be wonderful. It seems remarkably improbable to me, though; I'm not aware of any other example of Canonical discarding the CLA requirement of a piece of software they created and were still using.

We need to wait for a better solution in Jessie+1

Posted Feb 13, 2014 6:39 UTC (Thu) by roskegg (subscriber, #105) [Link]

All GNU software requires a CLA to the Free Software Foundation; why quibble when Canonical asks for it? It gives them the guaranteed legal standing they need to defend the software from legal attacks.

Issues of "standing" are very real in court rooms. If you don't have "standing", a judge will throw your case out without hearing it.

Since the software is released under GPL, how does the license assignment hurt anything?

I am viewing this move toward systemd with alarm.

First, some schmuck made it so I can't tar/backup/archive my own home directory, because of a stupid little non-readable directory that makes tar barf. Not sure if it was Poettering responsible, but it was definitely endorsed by the Gnome/Pulseaudio crowd. Pulseaudio, what a fiasco. First, they make files that break automated backup tools. Then they make binary formats.

There is a time or place from binary formats, but the ESSENCE of Unix is that everything is a stream of text.

I came to Unix to get AWAY from the bloat and binary obfuscation of Windows, COM/CORBA.

Especially when it comes to the base system. I need to be able to view my systems configuration and logs in vi.

Poettering and the Gnome cabal are trying to imitate M$ Windows. They are spitting on "The Unix Philosophy" outlined so well by Goncarz, and explained in such beautiful clarity by Eric Raymond in "The Art of Unix Programming".

What the hell, Red Hat? You've been subverted by the NSA? Why are you hiring all these Microsoft weenies to spoil our POSIX operating system?

We need to wait for a better solution in Jessie+1

Posted Feb 13, 2014 6:56 UTC (Thu) by fandingo (subscriber, #67019) [Link]

There are significant differences between the FSF CLA and the Canonical CLA.

1) The FSF is an American 501(c)(3) charitable organization. If the FSF were to go bankrupt, and the assets liquidated by a court, they cannot be liquidated in a manner inconsistent with the charity's principles. This doctrine is known as cy pres. That means that FSF copyrights could never be sold to an organization that would license them under nonfree terms. Canonical is a commercial company, and those assets could be sold to a company that could relicense the code under proprietary terms, although the current versions would also still exist under the present license.

2) The FSF makes explicit, legally binding promises that they will never relicense (or dual license) the code in a proprietary manner. Canonical does not do so.

3) The Canonical CLA requires that you attest to owning *any* patents that may exist on a work. If a contributor does not know that a contribution infringes a patent, and the holder of that patent sues Canonical, Canonical could seek legal recourse from the contributor. The FSF has no patent attestation clause.

The most that could possibly go wrong with a work handed over to the FSF would be a future license version is at odds with what the contributor intended. Again, the code will always remain free because they promise to do so. It would be more like you contributed when GPLv2 was the newest version and were unhappy that the work is now GPLv3.

The Canonical and FSF CLAs couldn't be more different, and it's not fair to compare them.

We need to wait for a better solution in Jessie+1

Posted Feb 13, 2014 15:57 UTC (Thu) by madscientist (subscriber, #16861) [Link]

Additionally, the FSF licenses back to you the code you contributed (but only your code!) so that you can reuse it for any purpose (not just under the GPL). The only right you give up is the actual copyright: the license you have gives you back every other right, including to relicense in a different way.

So if you develop some stand-alone code and then assign copyright to the FSF, you can still take that code and use it in your proprietary program if you want (as long as it doesn't derive from any other GPL'd code, that you didn't write, of course).

We need to wait for a better solution in Jessie+1

Posted Feb 13, 2014 8:58 UTC (Thu) by tao (subscriber, #17563) [Link]

What's the non-readable Pulseaudio-related directory you're talking about? I'm curious; I haven't seen anything like that (I'm using Pulseaudio), but obviously that's no guarantee. Also, there's no GNOME/Pulseaudio crowd. They are two different groups of developers.

Again, as others already explained, if you don't like binary formats, just set journald to pass-through mode and use rsyslogd, or keep the journald settings as they are but run rsyslogd on the side (that way you get your beloved text-logs, which still having the extended logs that journald provides available side by side).

The system configuration for systemd is done using text files and are much easier to overview and understand than initscripts.

TINC.

Also, towards the end of your message you really sound like a troll. Next time try to plead your case with rational arguments instead of troll-like behaviour.

We need to wait for a better solution in Jessie+1

Posted Feb 15, 2014 22:42 UTC (Sat) by lsl (subscriber, #86508) [Link]

> What's the non-readable Pulseaudio-related directory you're talking about?

It's probably just a mounted FUSE filesystem. Per default those can't be accessed by root to prevent random users from DOSing or at least annoying root's processes.

There's no connection to Pulseaudio.

We need to wait for a better solution in Jessie+1

Posted Feb 16, 2014 1:51 UTC (Sun) by roskegg (subscriber, #105) [Link]

Yes, that one. That is a crime that was committed at the Linux kernel developer level.

NOTHING should be withheld from root. When I am root, I want to be able to access my directories! Also, since all the permissions were turned off, even running tar with the correct user permissions didn't work. It is frickin UGLY.

We need to wait for a better solution in Jessie+1

Posted Feb 16, 2014 2:35 UTC (Sun) by mathstuf (subscriber, #69389) [Link]

Personally, I'd much prefer root getting -EPERM than infinite looping in "ls". I suppose you could ask for a FUSE sysctl knob like fuse.footgun, but that's your fight ;) .

On the root-is-omnipotent front, have you heard of Secure Boot? I think it has benefits for groups like schools and companies who want to ensure that *their* hardware is used as intended, not by the student or employee. If I have root, it is not necessarily true that I own the hardware too (e.g., installing packages might be relevant for teachers). The fear with SB is that manufactures will start "owning" hardware they sell indefinitely. *That* is valid, but it is not a reason to not do it.

We need to wait for a better solution in Jessie+1

Posted Feb 18, 2014 21:30 UTC (Tue) by Wol (guest, #4433) [Link]

Actually, that's one of the biggest Unix MISfeatures, imho, the ability for root to do anything.

From Rev19 onwards, Primos had ACLs. The one thing you couldn't take away from the superuser was the ability to override them (actually, it was implemented as a "priority acl").

So if I was testing stuff that required to run as super-user, I could just do a "set-priority-acl live-data superuser:no-rights", and then be CERTAIN that however badly I screwed up, I couldn't damage the live system. Once I was happy it was all working, I would delete the priority acl and could run the script for live.

After all, if the super-user always has the ability to edit access rights, then any (by default) lack of access rights merely makes things that little bit harder. Which is what you want - the last thing you want is the system making it easy for finger-trouble et al to cause a disaster. It's a safety-catch, not a barrier.

Cheers,
Wol

We need to wait for a better solution in Jessie+1

Posted Feb 18, 2014 21:56 UTC (Tue) by rodgerd (guest, #58896) [Link]

Just because you're root doesn't mean they're your directories.

Anyone who has worked as a sysadmin for anything other than their own toy boxes should understand that.

We need to wait for a better solution in Jessie+1

Posted Feb 13, 2014 15:15 UTC (Thu) by mathstuf (subscriber, #69389) [Link]

> There is a time or place from binary formats, but the ESSENCE of Unix is that everything is a stream of text.

So why the exception for things like compiled code? That's a stream of binary. The reason is that the tradeoffs are worth it and you have tools like nm, ldd, and readelf to coax text streams from them, so why would journalctl be much different? Just because something has historically been text doesn't mean it's the best solution forever (git tools slowly migrate from shell/perl to C which has caused me to go track the source down on multiple occasions).

> I need to be able to view my systems configuration and logs in vi.

Configurations are going to be text for a long time (though you have hashmap for postfix, so there are exceptions already) and ISTR journalctl being able to work even on Windows, so log viewers should be possible nearly everywhere.

> Poettering and the Gnome cabal are trying to imitate M$ Windows.

If you mean the fact that Windows has stable APIs which work across all instances, sure, I could see that. Other than that, systemd has *many* more features than Windows' init. Also, just because Windows does something doesn't mean it's bad and we shouldn't do it on principle. I agree that there is a lot of crap I'd never want, but I don't see those things happening in systemd (here's the binary logs, but journalctl is nice enough to forgive that).

> Why are you hiring all these Microsoft weenies to spoil our POSIX operating system?

Where are the new hires popping up from nowhere to work on it? If you're referring to Lennart himself, that's a *long* play by Microsoft.

You're also aware that Linux was never POSIX certified, right? RHEL is and Windows was, but the kernel+coreutils never was.

We don't need to wait for a better solution in Jessie+1

Posted Feb 13, 2014 12:43 UTC (Thu) by anselm (subscriber, #2796) [Link]

The obvious way forward here is for the Debian project to work with the systemd developers to support something that is functionally equivalent to the »Debian plumbing« in systemd. This lets all Linux users (and not just those on Debian) avail themselves of the superior approach. (Systemd has already adopted »Debian plumbing« in various places. The systemd developers are actively interested in technical excellence, so if Debian has something useful to offer that systemd doesn't yet do, and someone comes up with the code to do it in systemd in a reasonable way, I don't think such enhancements will be rejected.)

In addition, if Debian developers become more involved in systemd development, then as a result the ideas and requirements of Debian will gain greater weight in systemd. With more Debian packages being adapted for systemd, we will also gain more experience getting services ready for systemd, and more bugs and shortcomings in systemd will be noticed and fixed. This is a win-win situation both for Debian and the systemd community.

This course of events is vastly more likely than Canonical dropping the CLA for Upstart and coming up with something better than systemd – which would in any event be just the sort of one-company approach that various people claim is underlying systemd, and dislike so much. How is an init system entirely controlled by Canonical better than an init system entirely controlled by Red Hat? (And of course systemd is not entirely controlled by Red Hat, anyway.)

We don't need to wait for a better solution in Jessie+1

Posted Feb 14, 2014 3:05 UTC (Fri) by uobe (guest, #95541) [Link]

We are the Borg.
Lower your shields and surrender your ships.
We will add your biological and technological distinctiveness to our own.
Your culture will adapt to service us.
Resistance is futile.

We need to wait for a better solution in Jessie+1

Posted Feb 14, 2014 19:26 UTC (Fri) by smurf (subscriber, #17840) [Link]

> Systemd is indubitably under Redhat control

On what evidence do you base this? I don't see any. Poettering being employed by RedHat isn't,

> Systemd brings with it Redhat plumbing

What exactly are you talking about? I don't see any evidence of "Redhat plumbing" in Debian's systemd packages.

>> For both Debian and Ubuntu, and for F/LOSS ecosystem health and diversity, the best solution would be for Ubuntu to learn from both Systemd and Upstart, immediately drop the Upstart CLA, and start *now* on building a world class Init for Jessie+1.

Canonical is going to drop even more than the Upstart CLA. They're going to drop Upstart.


Copyright © 2014, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds