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 |
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
Posted Feb 11, 2014 15:20 UTC (Tue)
by tsmithe (guest, #57598)
[Link] (24 responses)
Posted Feb 11, 2014 15:27 UTC (Tue)
by algernon (guest, #11573)
[Link]
Posted Feb 11, 2014 15:32 UTC (Tue)
by juliank (guest, #45896)
[Link] (18 responses)
Posted Feb 11, 2014 16:37 UTC (Tue)
by hadrons123 (guest, #72126)
[Link] (17 responses)
Posted Feb 11, 2014 16:55 UTC (Tue)
by tsmithe (guest, #57598)
[Link] (16 responses)
It'll now be interesting to watch the implications of all this.
Posted Feb 11, 2014 16:58 UTC (Tue)
by rahvin (guest, #16953)
[Link] (15 responses)
Posted Feb 11, 2014 18:53 UTC (Tue)
by dfsmith (guest, #20302)
[Link] (14 responses)
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
Posted Feb 11, 2014 19:11 UTC (Tue)
by proski (subscriber, #104)
[Link] (5 responses)
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.
Posted Feb 11, 2014 19:20 UTC (Tue)
by bluss (guest, #47454)
[Link] (3 responses)
Posted Feb 11, 2014 22:44 UTC (Tue)
by anselm (subscriber, #2796)
[Link] (1 responses)
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.
Posted Feb 14, 2014 10:16 UTC (Fri)
by Wol (subscriber, #4433)
[Link]
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,
Posted Feb 14, 2014 8:20 UTC (Fri)
by smurf (subscriber, #17840)
[Link]
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.
Posted Feb 14, 2014 7:54 UTC (Fri)
by smurf (subscriber, #17840)
[Link]
Posted Feb 11, 2014 19:46 UTC (Tue)
by dag- (guest, #30207)
[Link] (1 responses)
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 ?
Posted Feb 11, 2014 20:18 UTC (Tue)
by jspaleta (subscriber, #50639)
[Link]
Posted Feb 11, 2014 20:01 UTC (Tue)
by vonbrand (subscriber, #4458)
[Link]
Check also the slew of programs called from the rc scripts and the "libraries" of functions they call for a balanced comparison.
Posted Feb 11, 2014 21:10 UTC (Tue)
by rodgerd (guest, #58896)
[Link] (3 responses)
1/ systemd is a blob that does everything.
Posted Feb 12, 2014 16:26 UTC (Wed)
by rgmoore (✭ supporter ✭, #75)
[Link] (2 responses)
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.
Posted Feb 12, 2014 16:49 UTC (Wed)
by HelloWorld (guest, #56129)
[Link] (1 responses)
Posted Feb 12, 2014 22:17 UTC (Wed)
by vonbrand (subscriber, #4458)
[Link]
... and those tasks are done in separate, small, simple binaries.
Posted Feb 12, 2014 11:57 UTC (Wed)
by jond (subscriber, #37669)
[Link]
Posted Feb 11, 2014 18:10 UTC (Tue)
by jspaleta (subscriber, #50639)
[Link] (1 responses)
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.
Posted Feb 12, 2014 12:00 UTC (Wed)
by jond (subscriber, #37669)
[Link]
Posted Feb 12, 2014 16:34 UTC (Wed)
by Thue (guest, #14277)
[Link] (1 responses)
Posted Feb 12, 2014 21:25 UTC (Wed)
by Cyberax (✭ supporter ✭, #52523)
[Link]
> So to recap, I come in peace, I mean you no harm, and you all will die. Gallaxhar out.
Posted Feb 11, 2014 15:29 UTC (Tue)
by pdewacht (subscriber, #47633)
[Link]
Posted Feb 11, 2014 17:42 UTC (Tue)
by marduk (subscriber, #3831)
[Link] (1 responses)
Sorry... couldn't resist.
Posted Feb 12, 2014 20:07 UTC (Wed)
by balkanboy (guest, #94926)
[Link]
Posted Feb 11, 2014 19:01 UTC (Tue)
by proski (subscriber, #104)
[Link] (61 responses)
Posted Feb 11, 2014 19:46 UTC (Tue)
by dlang (guest, #313)
[Link] (60 responses)
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.
Posted Feb 11, 2014 20:14 UTC (Tue)
by vonbrand (subscriber, #4458)
[Link] (16 responses)
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.
Posted Feb 12, 2014 0:03 UTC (Wed)
by dakas (guest, #88146)
[Link] (2 responses)
Posted Feb 12, 2014 0:21 UTC (Wed)
by vonbrand (subscriber, #4458)
[Link] (1 responses)
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?
Posted Feb 12, 2014 0:39 UTC (Wed)
by jspaleta (subscriber, #50639)
[Link]
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.
This is a fantastic read:
"
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."
Posted Feb 12, 2014 2:13 UTC (Wed)
by prometheanfire (subscriber, #65683)
[Link] (7 responses)
It's an easy decision...
Posted Feb 12, 2014 2:18 UTC (Wed)
by vonbrand (subscriber, #4458)
[Link] (1 responses)
How long will there be no systemd-capable kernels for your favorite ARM platform?
Posted Feb 12, 2014 2:41 UTC (Wed)
by prometheanfire (subscriber, #65683)
[Link]
Posted Feb 12, 2014 6:46 UTC (Wed)
by koenkooi (subscriber, #71861)
[Link] (1 responses)
Posted Feb 12, 2014 7:23 UTC (Wed)
by prometheanfire (subscriber, #65683)
[Link]
The oldest kernel I know that still ships is 2.6.31 though, but one thing at a time :P
Posted Feb 12, 2014 8:34 UTC (Wed)
by xav (guest, #18536)
[Link] (1 responses)
Posted Feb 12, 2014 8:37 UTC (Wed)
by prometheanfire (subscriber, #65683)
[Link]
Don't use systemd because it can't be used on an older (incompatible) kernel.
Posted Feb 14, 2014 11:34 UTC (Fri)
by smurf (subscriber, #17840)
[Link]
Binary blobs which do not work with newer kernels (or, most likely, the same kernel, compiled with different options) are a license violation.
Posted Feb 12, 2014 15:26 UTC (Wed)
by edeloget (subscriber, #88392)
[Link] (4 responses)
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).
Posted Feb 12, 2014 15:37 UTC (Wed)
by zdzichu (subscriber, #17118)
[Link]
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.
Posted Feb 12, 2014 16:18 UTC (Wed)
by pizza (subscriber, #46)
[Link]
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. :)
Posted Feb 12, 2014 21:21 UTC (Wed)
by Cyberax (✭ supporter ✭, #52523)
[Link]
>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.
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.
Posted Feb 13, 2014 13:45 UTC (Thu)
by cmorgan (guest, #71980)
[Link]
Posted Feb 11, 2014 20:39 UTC (Tue)
by hmvp (subscriber, #54422)
[Link]
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
Posted Feb 11, 2014 21:33 UTC (Tue)
by khim (subscriber, #9252)
[Link] (7 responses)
Posted Feb 11, 2014 21:47 UTC (Tue)
by jspaleta (subscriber, #50639)
[Link] (6 responses)
Are there any NAS solutions running systemd from their firmware yet that anyone knows of?
Posted Feb 12, 2014 1:19 UTC (Wed)
by kokada (guest, #92849)
[Link] (3 responses)
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.
Posted Feb 12, 2014 1:56 UTC (Wed)
by viro (subscriber, #7872)
[Link] (2 responses)
[1] noun. uncountable: ability to see. countable: hallucination of one sort or another.
Posted Feb 12, 2014 7:16 UTC (Wed)
by palmer_eldritch (guest, #95160)
[Link]
Posted Feb 14, 2014 11:21 UTC (Fri)
by smurf (subscriber, #17840)
[Link]
Posted Feb 13, 2014 17:44 UTC (Thu)
by janecek (subscriber, #74774)
[Link] (1 responses)
Posted Feb 14, 2014 9:56 UTC (Fri)
by tzafrir (subscriber, #11501)
[Link]
Posted Feb 11, 2014 21:51 UTC (Tue)
by tao (subscriber, #17563)
[Link] (29 responses)
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.
Posted Feb 11, 2014 22:05 UTC (Tue)
by pizza (subscriber, #46)
[Link]
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...
Posted Feb 11, 2014 22:13 UTC (Tue)
by dlang (guest, #313)
[Link] (27 responses)
Posted Feb 11, 2014 22:19 UTC (Tue)
by mebrown (subscriber, #7960)
[Link] (19 responses)
Posted Feb 11, 2014 22:26 UTC (Tue)
by mpr22 (subscriber, #60784)
[Link] (18 responses)
Posted Feb 11, 2014 22:59 UTC (Tue)
by fandingo (guest, #67019)
[Link] (17 responses)
Posted Feb 11, 2014 23:07 UTC (Tue)
by dlang (guest, #313)
[Link] (16 responses)
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)
Posted Feb 11, 2014 23:46 UTC (Tue)
by fandingo (guest, #67019)
[Link] (15 responses)
> 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.
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.
Posted Feb 12, 2014 0:42 UTC (Wed)
by dlang (guest, #313)
[Link] (14 responses)
> 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.
Posted Feb 12, 2014 0:58 UTC (Wed)
by mchapman (subscriber, #66589)
[Link] (8 responses)
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.
Posted Feb 12, 2014 1:04 UTC (Wed)
by dlang (guest, #313)
[Link] (7 responses)
Posted Feb 12, 2014 1:48 UTC (Wed)
by mchapman (subscriber, #66589)
[Link] (6 responses)
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.
Posted Feb 12, 2014 2:36 UTC (Wed)
by dlang (guest, #313)
[Link] (5 responses)
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.
Posted Feb 12, 2014 3:03 UTC (Wed)
by vonbrand (subscriber, #4458)
[Link] (1 responses)
A binary format is more amenable to having indices to speed up searches than the plain text you seem to favor.
Posted Feb 12, 2014 3:52 UTC (Wed)
by dlang (guest, #313)
[Link]
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.
Posted Feb 13, 2014 0:30 UTC (Thu)
by smoogen (subscriber, #97)
[Link] (2 responses)
Posted Feb 13, 2014 0:35 UTC (Thu)
by dlang (guest, #313)
[Link] (1 responses)
Posted Feb 14, 2014 10:29 UTC (Fri)
by smurf (subscriber, #17840)
[Link]
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.
Posted Feb 14, 2014 11:18 UTC (Fri)
by smurf (subscriber, #17840)
[Link] (4 responses)
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.
Posted Feb 16, 2014 3:59 UTC (Sun)
by dlang (guest, #313)
[Link] (3 responses)
> 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
Posted Feb 16, 2014 4:21 UTC (Sun)
by mchapman (subscriber, #66589)
[Link] (2 responses)
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.
Posted Feb 16, 2014 4:46 UTC (Sun)
by dlang (guest, #313)
[Link] (1 responses)
In any case, it sounds like what systemd does and what rsyslog does are pretty similar.
Posted Feb 16, 2014 5:16 UTC (Sun)
by mchapman (subscriber, #66589)
[Link]
Sure, in this respect, I would agree with that.
Posted Feb 11, 2014 22:21 UTC (Tue)
by jspaleta (subscriber, #50639)
[Link] (6 responses)
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
Posted Feb 11, 2014 22:52 UTC (Tue)
by dlang (guest, #313)
[Link] (1 responses)
Posted Feb 12, 2014 15:26 UTC (Wed)
by jonnor (guest, #76768)
[Link]
Posted Feb 11, 2014 23:00 UTC (Tue)
by fandingo (guest, #67019)
[Link] (3 responses)
journald -> rsyslog -> network -> remote rsyslog
Posted Feb 11, 2014 23:41 UTC (Tue)
by jspaleta (subscriber, #50639)
[Link] (2 responses)
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.
Posted Feb 14, 2014 11:06 UTC (Fri)
by smurf (subscriber, #17840)
[Link] (1 responses)
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.
Posted Feb 16, 2014 3:50 UTC (Sun)
by dlang (guest, #313)
[Link]
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.
Posted Feb 11, 2014 22:17 UTC (Tue)
by mebrown (subscriber, #7960)
[Link]
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.
Posted Feb 11, 2014 23:18 UTC (Tue)
by shmerl (guest, #65921)
[Link]
Posted Feb 12, 2014 6:11 UTC (Wed)
by suy (guest, #81959)
[Link]
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.
Posted Feb 12, 2014 12:00 UTC (Wed)
by jond (subscriber, #37669)
[Link]
Posted Feb 11, 2014 19:14 UTC (Tue)
by jmorris42 (guest, #2203)
[Link] (143 responses)
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.
Posted Feb 11, 2014 19:28 UTC (Tue)
by hkario (subscriber, #94864)
[Link] (38 responses)
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.
Posted Feb 11, 2014 19:48 UTC (Tue)
by dlang (guest, #313)
[Link] (37 responses)
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.
Posted Feb 11, 2014 20:05 UTC (Tue)
by pizza (subscriber, #46)
[Link] (28 responses)
...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?
Posted Feb 11, 2014 20:15 UTC (Tue)
by dlang (guest, #313)
[Link] (27 responses)
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.
Posted Feb 11, 2014 20:30 UTC (Tue)
by vonbrand (subscriber, #4458)
[Link] (20 responses)
Pray tell who is forcing you to use this code...
Posted Feb 11, 2014 22:08 UTC (Tue)
by dlang (guest, #313)
[Link] (19 responses)
Posted Feb 12, 2014 1:09 UTC (Wed)
by vonbrand (subscriber, #4458)
[Link] (18 responses)
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.
Posted Feb 12, 2014 1:13 UTC (Wed)
by dlang (guest, #313)
[Link] (17 responses)
Posted Feb 12, 2014 1:51 UTC (Wed)
by vonbrand (subscriber, #4458)
[Link] (11 responses)
Source, please? I've read a lot by Lennart, but I don't remember any such comment.
Posted Feb 12, 2014 2:06 UTC (Wed)
by dlang (guest, #313)
[Link] (10 responses)
Posted Feb 12, 2014 2:32 UTC (Wed)
by vonbrand (subscriber, #4458)
[Link] (4 responses)
So this is just another myth. Just as I thought.
Posted Feb 12, 2014 2:37 UTC (Wed)
by dlang (guest, #313)
[Link] (3 responses)
Posted Feb 12, 2014 2:42 UTC (Wed)
by rodgerd (guest, #58896)
[Link] (2 responses)
Posted Feb 12, 2014 2:56 UTC (Wed)
by dlang (guest, #313)
[Link] (1 responses)
Posted Feb 12, 2014 9:28 UTC (Wed)
by xav (guest, #18536)
[Link]
Posted Feb 12, 2014 3:02 UTC (Wed)
by hadrons123 (guest, #72126)
[Link] (4 responses)
Posted Feb 12, 2014 3:27 UTC (Wed)
by neilbrown (subscriber, #359)
[Link] (3 responses)
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.
Posted Feb 12, 2014 3:42 UTC (Wed)
by vonbrand (subscriber, #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.
Posted Feb 12, 2014 19:18 UTC (Wed)
by suy (guest, #81959)
[Link]
Posted Feb 14, 2014 11:32 UTC (Fri)
by smurf (subscriber, #17840)
[Link]
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.
Posted Feb 12, 2014 18:05 UTC (Wed)
by HelloWorld (guest, #56129)
[Link] (4 responses)
Posted Feb 12, 2014 22:38 UTC (Wed)
by dlang (guest, #313)
[Link] (3 responses)
Posted Feb 13, 2014 1:33 UTC (Thu)
by HelloWorld (guest, #56129)
[Link] (2 responses)
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”.
Posted Feb 13, 2014 13:01 UTC (Thu)
by Zack (guest, #37335)
[Link] (1 responses)
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.
Posted Feb 13, 2014 13:52 UTC (Thu)
by HelloWorld (guest, #56129)
[Link]
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.
Posted Feb 11, 2014 21:18 UTC (Tue)
by rodgerd (guest, #58896)
[Link] (5 responses)
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.
Posted Feb 12, 2014 17:55 UTC (Wed)
by HelloWorld (guest, #56129)
[Link] (4 responses)
Posted Feb 12, 2014 20:40 UTC (Wed)
by rodgerd (guest, #58896)
[Link] (3 responses)
"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.
Posted Feb 12, 2014 21:29 UTC (Wed)
by jspaleta (subscriber, #50639)
[Link] (2 responses)
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.
Posted Feb 12, 2014 22:26 UTC (Wed)
by rodgerd (guest, #58896)
[Link] (1 responses)
Posted Feb 12, 2014 22:30 UTC (Wed)
by jspaleta (subscriber, #50639)
[Link]
-jef
Posted Feb 11, 2014 20:19 UTC (Tue)
by johannbg (guest, #65743)
[Link] (7 responses)
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...
Posted Feb 11, 2014 20:43 UTC (Tue)
by viro (subscriber, #7872)
[Link] (6 responses)
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 ;-/
Posted Feb 11, 2014 21:43 UTC (Tue)
by johannbg (guest, #65743)
[Link]
1. Megoo
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.
Posted Feb 11, 2014 21:48 UTC (Tue)
by jmorris42 (guest, #2203)
[Link] (4 responses)
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?
Posted Feb 11, 2014 22:25 UTC (Tue)
by mebrown (subscriber, #7960)
[Link]
Posted Feb 12, 2014 2:09 UTC (Wed)
by vonbrand (subscriber, #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?
Posted Feb 12, 2014 15:40 UTC (Wed)
by jonnor (guest, #76768)
[Link] (1 responses)
Have you refrained from using the Linux kernel because RedHat is the or one of the major contributors?
Posted Feb 14, 2014 9:54 UTC (Fri)
by smurf (subscriber, #17840)
[Link]
… which incidentally is exactly what I see happening.
So let's can the conspiracy theories already.
Posted Feb 11, 2014 19:50 UTC (Tue)
by viro (subscriber, #7872)
[Link] (85 responses)
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.
Posted Feb 11, 2014 20:07 UTC (Tue)
by vonbrand (subscriber, #4458)
[Link] (2 responses)
"Those guys" just so happens to include almost everyone working on 'plumbing' for Linux...
Posted Feb 11, 2014 20:14 UTC (Tue)
by dlang (guest, #313)
[Link] (1 responses)
no, only those who take the attitude that theirs is the only valid way to do things.
Posted Feb 11, 2014 21:07 UTC (Tue)
by jspaleta (subscriber, #50639)
[Link]
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.
Posted Feb 11, 2014 20:09 UTC (Tue)
by deepfire (guest, #26138)
[Link]
Posted Feb 12, 2014 11:58 UTC (Wed)
by joyuh (guest, #95216)
[Link] (80 responses)
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.
Posted Feb 12, 2014 12:57 UTC (Wed)
by viro (subscriber, #7872)
[Link] (28 responses)
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...
Posted Feb 12, 2014 14:19 UTC (Wed)
by Trelane (subscriber, #56877)
[Link] (22 responses)
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.
Posted Feb 12, 2014 15:21 UTC (Wed)
by viro (subscriber, #7872)
[Link] (21 responses)
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.
Posted Feb 12, 2014 15:41 UTC (Wed)
by andresfreund (subscriber, #69562)
[Link]
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.
Sorry for the rant, I had to adjust that value once too often ;)
Posted Feb 12, 2014 16:57 UTC (Wed)
by joyuh (guest, #95216)
[Link] (16 responses)
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.
Posted Feb 12, 2014 17:15 UTC (Wed)
by joyuh (guest, #95216)
[Link]
Posted Feb 13, 2014 2:11 UTC (Thu)
by viro (subscriber, #7872)
[Link] (1 responses)
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.
Posted Feb 13, 2014 5:25 UTC (Thu)
by joyuh (guest, #95216)
[Link]
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)
Posted Feb 13, 2014 21:04 UTC (Thu)
by jonabbey (guest, #2736)
[Link] (12 responses)
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.
Posted Feb 13, 2014 22:47 UTC (Thu)
by viro (subscriber, #7872)
[Link]
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...
Posted Feb 14, 2014 1:44 UTC (Fri)
by joyuh (guest, #95216)
[Link] (10 responses)
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.
Posted Feb 14, 2014 2:08 UTC (Fri)
by mgb (guest, #3226)
[Link] (5 responses)
Posted Feb 14, 2014 2:50 UTC (Fri)
by joyuh (guest, #95216)
[Link] (4 responses)
Which is, you know, what happens on all OSes except on Linux distributions.
Posted Feb 14, 2014 3:23 UTC (Fri)
by vonbrand (subscriber, #4458)
[Link] (1 responses)
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...
Posted Feb 14, 2014 4:23 UTC (Fri)
by joyuh (guest, #95216)
[Link]
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.
Posted Feb 14, 2014 3:45 UTC (Fri)
by viro (subscriber, #7872)
[Link] (1 responses)
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...
Posted Feb 14, 2014 4:16 UTC (Fri)
by joyuh (guest, #95216)
[Link]
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.
Posted Feb 14, 2014 7:49 UTC (Fri)
by anselm (subscriber, #2796)
[Link] (3 responses)
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.
Posted Feb 14, 2014 10:50 UTC (Fri)
by Wol (subscriber, #4433)
[Link] (2 responses)
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,
Posted Feb 14, 2014 11:16 UTC (Fri)
by mchapman (subscriber, #66589)
[Link] (1 responses)
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.
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.)
Posted Feb 12, 2014 18:27 UTC (Wed)
by josh (subscriber, #17465)
[Link] (2 responses)
Posted Feb 12, 2014 19:13 UTC (Wed)
by HelloWorld (guest, #56129)
[Link] (1 responses)
Posted Feb 12, 2014 20:18 UTC (Wed)
by josh (subscriber, #17465)
[Link]
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.
Posted Feb 12, 2014 18:32 UTC (Wed)
by rodgerd (guest, #58896)
[Link] (3 responses)
Posted Feb 13, 2014 2:34 UTC (Thu)
by viro (subscriber, #7872)
[Link] (2 responses)
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.
Posted Feb 13, 2014 9:41 UTC (Thu)
by HelloWorld (guest, #56129)
[Link]
So please, stop trolling already.
Posted Feb 13, 2014 15:05 UTC (Thu)
by nix (subscriber, #2304)
[Link]
Posted Feb 13, 2014 5:31 UTC (Thu)
by bojan (subscriber, #14302)
[Link]
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.
Posted Feb 12, 2014 18:34 UTC (Wed)
by rodgerd (guest, #58896)
[Link]
Posted Feb 13, 2014 3:36 UTC (Thu)
by dlang (guest, #313)
[Link] (49 responses)
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
Posted Feb 13, 2014 4:06 UTC (Thu)
by rodgerd (guest, #58896)
[Link] (48 responses)
Posted Feb 13, 2014 5:10 UTC (Thu)
by dlang (guest, #313)
[Link] (47 responses)
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)
Posted Feb 13, 2014 5:51 UTC (Thu)
by Cyberax (✭ supporter ✭, #52523)
[Link] (32 responses)
The latter actually causes quite a LOT of pain for binary-only publishers.
Posted Feb 13, 2014 15:52 UTC (Thu)
by madscientist (subscriber, #16861)
[Link] (31 responses)
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".
Posted Feb 13, 2014 20:40 UTC (Thu)
by Cyberax (✭ supporter ✭, #52523)
[Link] (30 responses)
> 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).
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.
Posted Feb 13, 2014 20:55 UTC (Thu)
by dlang (guest, #313)
[Link] (3 responses)
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.
Posted Feb 13, 2014 21:26 UTC (Thu)
by Cyberax (✭ supporter ✭, #52523)
[Link] (2 responses)
But not glibc. It can't be packaged or avoided.
Posted Feb 16, 2014 2:55 UTC (Sun)
by dlang (guest, #313)
[Link] (1 responses)
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
Posted Feb 16, 2014 5:11 UTC (Sun)
by Cyberax (✭ supporter ✭, #52523)
[Link]
Posted Feb 13, 2014 22:42 UTC (Thu)
by madscientist (subscriber, #16861)
[Link] (25 responses)
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 :-/.
Posted Feb 13, 2014 22:45 UTC (Thu)
by madscientist (subscriber, #16861)
[Link]
Posted Feb 14, 2014 0:38 UTC (Fri)
by Cyberax (✭ supporter ✭, #52523)
[Link] (17 responses)
> 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).
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
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.
Posted Feb 14, 2014 8:55 UTC (Fri)
by khim (subscriber, #9252)
[Link] (10 responses)
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 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.
Posted Feb 14, 2014 10:12 UTC (Fri)
by mchapman (subscriber, #66589)
[Link] (6 responses)
Bad examples. Plenty of proprietary Linux games are packaged exactly like this.
Posted Feb 14, 2014 17:51 UTC (Fri)
by khim (subscriber, #9252)
[Link] (5 responses)
Posted Feb 14, 2014 18:32 UTC (Fri)
by mjg59 (subscriber, #23239)
[Link]
Posted Feb 14, 2014 23:52 UTC (Fri)
by Cyberax (✭ supporter ✭, #52523)
[Link] (2 responses)
Of course, packaging libGL that depends on hardware is not really a good idea. But you certainly _can_ do it.
Posted Feb 15, 2014 11:58 UTC (Sat)
by khim (subscriber, #9252)
[Link] (1 responses)
Posted Feb 15, 2014 19:01 UTC (Sat)
by nix (subscriber, #2304)
[Link]
Posted Feb 15, 2014 2:07 UTC (Sat)
by mchapman (subscriber, #66589)
[Link]
You are correct. I got mixed up between my GL libraries.
Posted Feb 14, 2014 12:18 UTC (Fri)
by Cyberax (✭ supporter ✭, #52523)
[Link] (2 responses)
>How about libasound?
>Or may be libcups? How well they work on different distributions if bundled?
>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
> In reality to support XP “under the hood” MSVC does the same thing GLibC recommends to do BTW.
And I stand by my statement - glibc is literally the worst library in Linux. Bar none.
Posted Feb 14, 2014 17:45 UTC (Fri)
by khim (subscriber, #9252)
[Link] (1 responses)
Not even close. MSVC 2012 RTM had no support for XP at all. 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. 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.
Posted Feb 14, 2014 23:48 UTC (Fri)
by Cyberax (✭ supporter ✭, #52523)
[Link]
>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.
Posted Feb 14, 2014 16:46 UTC (Fri)
by madscientist (subscriber, #16861)
[Link] (2 responses)
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.
Posted Feb 14, 2014 20:20 UTC (Fri)
by mathstuf (subscriber, #69389)
[Link] (1 responses)
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
Posted Feb 14, 2014 20:34 UTC (Fri)
by madscientist (subscriber, #16861)
[Link]
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).
Posted Feb 14, 2014 21:35 UTC (Fri)
by jimparis (guest, #38647)
[Link] (2 responses)
Joey Hess seems to claim that shipping glibc with your application is also not hard: https://joeyh.name/blog/entry/completely_linux_distributi...
Posted Feb 14, 2014 23:50 UTC (Fri)
by Cyberax (✭ supporter ✭, #52523)
[Link] (1 responses)
Posted Feb 17, 2014 21:52 UTC (Mon)
by jimparis (guest, #38647)
[Link]
Posted Feb 14, 2014 17:28 UTC (Fri)
by hummassa (subscriber, #307)
[Link] (5 responses)
would you please be so kind and teach us how you do that?
Posted Feb 14, 2014 23:00 UTC (Fri)
by madscientist (subscriber, #16861)
[Link] (4 responses)
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).
Posted Feb 15, 2014 13:22 UTC (Sat)
by hummassa (subscriber, #307)
[Link] (3 responses)
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...
Posted Feb 15, 2014 14:44 UTC (Sat)
by madscientist (subscriber, #16861)
[Link]
Posted Feb 15, 2014 19:03 UTC (Sat)
by nix (subscriber, #2304)
[Link]
Posted Feb 16, 2014 18:36 UTC (Sun)
by liw (subscriber, #6379)
[Link]
Beware: I wrote this for myself. It's not designed to be clean or
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
Posted Feb 13, 2014 8:14 UTC (Thu)
by rodgerd (guest, #58896)
[Link] (13 responses)
> 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.
Posted Feb 13, 2014 11:14 UTC (Thu)
by dlang (guest, #313)
[Link] (12 responses)
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.
Posted Feb 13, 2014 12:08 UTC (Thu)
by Cyberax (✭ supporter ✭, #52523)
[Link] (11 responses)
Posted Feb 13, 2014 12:29 UTC (Thu)
by dlang (guest, #313)
[Link] (10 responses)
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.
Posted Feb 13, 2014 14:15 UTC (Thu)
by mathstuf (subscriber, #69389)
[Link] (9 responses)
Posted Feb 13, 2014 14:58 UTC (Thu)
by dlang (guest, #313)
[Link] (8 responses)
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.
Posted Feb 13, 2014 15:51 UTC (Thu)
by mathstuf (subscriber, #69389)
[Link] (7 responses)
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.
Posted Feb 13, 2014 19:46 UTC (Thu)
by dlang (guest, #313)
[Link] (5 responses)
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.
Posted Feb 13, 2014 21:50 UTC (Thu)
by paulj (subscriber, #341)
[Link] (1 responses)
Can you expand on it not doing what was claimed? How serious is the discrepancy?
Posted Feb 16, 2014 3:20 UTC (Sun)
by dlang (guest, #313)
[Link]
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.
Posted Feb 13, 2014 21:57 UTC (Thu)
by peter-b (subscriber, #66996)
[Link]
Yeah, that'll be a [citation needed], please.
Posted Feb 14, 2014 9:25 UTC (Fri)
by smurf (subscriber, #17840)
[Link] (1 responses)
You can tell the thing to be totally transparent if you don't like it.
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.
Posted Feb 16, 2014 3:44 UTC (Sun)
by dlang (guest, #313)
[Link]
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.
Posted Feb 13, 2014 19:54 UTC (Thu)
by dlang (guest, #313)
[Link]
Posted Feb 11, 2014 21:08 UTC (Tue)
by rodgerd (guest, #58896)
[Link]
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?
Posted Feb 12, 2014 4:35 UTC (Wed)
by mbt (guest, #81044)
[Link] (16 responses)
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.
Posted Feb 12, 2014 5:36 UTC (Wed)
by jmorris42 (guest, #2203)
[Link]
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.
Posted Feb 12, 2014 6:20 UTC (Wed)
by Cyberax (✭ supporter ✭, #52523)
[Link] (11 responses)
>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.
> 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.)
>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.
>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.
Posted Feb 12, 2014 22:38 UTC (Wed)
by mathstuf (subscriber, #69389)
[Link] (1 responses)
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?
Posted Feb 13, 2014 0:57 UTC (Thu)
by ABCD (subscriber, #53650)
[Link]
Posted Feb 13, 2014 5:11 UTC (Thu)
by mbt (guest, #81044)
[Link] (8 responses)
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.
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:
> 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.
Posted Feb 13, 2014 6:05 UTC (Thu)
by Cyberax (✭ supporter ✭, #52523)
[Link]
> Consider one package that certainly has the right to say that its API is in a really stable state: TeX.
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?
> 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.
> 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.
> 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.
Posted Feb 13, 2014 7:52 UTC (Thu)
by mathstuf (subscriber, #69389)
[Link]
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.
Posted Feb 14, 2014 19:50 UTC (Fri)
by smurf (subscriber, #17840)
[Link] (5 responses)
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.
Posted Feb 18, 2014 17:23 UTC (Tue)
by HelloWorld (guest, #56129)
[Link] (4 responses)
Posted Feb 18, 2014 18:44 UTC (Tue)
by smurf (subscriber, #17840)
[Link] (3 responses)
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.
Posted Feb 19, 2014 10:15 UTC (Wed)
by HelloWorld (guest, #56129)
[Link] (2 responses)
> 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.
Posted Feb 19, 2014 11:06 UTC (Wed)
by mchapman (subscriber, #66589)
[Link]
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.
Posted Feb 19, 2014 11:34 UTC (Wed)
by smurf (subscriber, #17840)
[Link]
*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?)
Posted Feb 12, 2014 6:21 UTC (Wed)
by josh (subscriber, #17465)
[Link]
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.
Posted Feb 12, 2014 12:01 UTC (Wed)
by joyuh (guest, #95216)
[Link]
Use VMs or seccomp if you want to run code with reduced privileges.
Posted Feb 12, 2014 20:45 UTC (Wed)
by Wol (subscriber, #4433)
[Link]
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,
Posted Feb 11, 2014 20:43 UTC (Tue)
by ikm (guest, #493)
[Link] (30 responses)
Posted Feb 11, 2014 20:51 UTC (Tue)
by mpr22 (subscriber, #60784)
[Link] (26 responses)
Posted Feb 11, 2014 21:00 UTC (Tue)
by zuki (subscriber, #41808)
[Link]
Posted Feb 11, 2014 21:35 UTC (Tue)
by ikm (guest, #493)
[Link] (24 responses)
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.
Posted Feb 11, 2014 21:53 UTC (Tue)
by drago01 (subscriber, #50715)
[Link]
Posted Feb 11, 2014 23:44 UTC (Tue)
by proski (subscriber, #104)
[Link] (21 responses)
I don't think the behavior of SysRq should change just because systemd is installed, so it could be considered a bug.
Posted Feb 12, 2014 0:04 UTC (Wed)
by cortana (subscriber, #24596)
[Link]
Posted Feb 12, 2014 0:17 UTC (Wed)
by jspaleta (subscriber, #50639)
[Link] (19 responses)
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.
Posted Feb 12, 2014 7:51 UTC (Wed)
by ovitters (guest, #27950)
[Link] (1 responses)
Posted Feb 12, 2014 8:19 UTC (Wed)
by jspaleta (subscriber, #50639)
[Link]
Posted Feb 17, 2014 14:19 UTC (Mon)
by nye (subscriber, #51576)
[Link] (16 responses)
> 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.
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.
Posted Feb 17, 2014 17:44 UTC (Mon)
by jspaleta (subscriber, #50639)
[Link] (15 responses)
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.
Posted Feb 17, 2014 17:51 UTC (Mon)
by andresfreund (subscriber, #69562)
[Link] (14 responses)
Restart a crashed server?
2 - enable control of console logging level
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.
Posted Feb 17, 2014 18:02 UTC (Mon)
by mjg59 (subscriber, #23239)
[Link] (2 responses)
Posted Feb 17, 2014 18:07 UTC (Mon)
by andresfreund (subscriber, #69562)
[Link] (1 responses)
Posted Feb 17, 2014 18:12 UTC (Mon)
by jspaleta (subscriber, #50639)
[Link]
Posted Feb 17, 2014 18:09 UTC (Mon)
by jspaleta (subscriber, #50639)
[Link] (10 responses)
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.
Posted Feb 17, 2014 18:16 UTC (Mon)
by andresfreund (subscriber, #69562)
[Link] (9 responses)
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.
Posted Feb 17, 2014 18:28 UTC (Mon)
by mjg59 (subscriber, #23239)
[Link] (5 responses)
Posted Feb 17, 2014 18:30 UTC (Mon)
by andresfreund (subscriber, #69562)
[Link] (4 responses)
Posted Feb 17, 2014 18:38 UTC (Mon)
by mjg59 (subscriber, #23239)
[Link] (3 responses)
Posted Feb 18, 2014 10:21 UTC (Tue)
by nye (subscriber, #51576)
[Link] (2 responses)
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?
Posted Feb 18, 2014 15:17 UTC (Tue)
by mjg59 (subscriber, #23239)
[Link] (1 responses)
Posted Feb 20, 2014 13:05 UTC (Thu)
by nye (subscriber, #51576)
[Link]
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
>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.
Posted Feb 17, 2014 18:45 UTC (Mon)
by jspaleta (subscriber, #50639)
[Link] (2 responses)
But lets talk historic usage.
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.
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.
Posted Feb 17, 2014 18:53 UTC (Mon)
by andresfreund (subscriber, #69562)
[Link] (1 responses)
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.
Posted Feb 17, 2014 19:34 UTC (Mon)
by smurf (subscriber, #17840)
[Link]
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.
Posted Feb 14, 2014 9:50 UTC (Fri)
by smurf (subscriber, #17840)
[Link]
# 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.
Posted Feb 11, 2014 20:56 UTC (Tue)
by cuboci (subscriber, #9641)
[Link] (1 responses)
Posted Feb 11, 2014 21:05 UTC (Tue)
by rodgerd (guest, #58896)
[Link]
Posted Feb 12, 2014 12:10 UTC (Wed)
by HelloWorld (guest, #56129)
[Link]
[Service]
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
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.
Posted Feb 11, 2014 22:10 UTC (Tue)
by amacater (subscriber, #790)
[Link]
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.
Posted Feb 13, 2014 3:06 UTC (Thu)
by mgb (guest, #3226)
[Link] (14 responses)
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.
Posted Feb 13, 2014 3:39 UTC (Thu)
by mpr22 (subscriber, #60784)
[Link] (10 responses)
Posted Feb 13, 2014 6:39 UTC (Thu)
by roskegg (subscriber, #105)
[Link] (9 responses)
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?
Posted Feb 13, 2014 6:56 UTC (Thu)
by fandingo (guest, #67019)
[Link] (1 responses)
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.
Posted Feb 13, 2014 15:57 UTC (Thu)
by madscientist (subscriber, #16861)
[Link]
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).
Posted Feb 13, 2014 8:58 UTC (Thu)
by tao (subscriber, #17563)
[Link] (5 responses)
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.
Posted Feb 15, 2014 22:42 UTC (Sat)
by lsl (subscriber, #86508)
[Link] (4 responses)
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.
Posted Feb 16, 2014 1:51 UTC (Sun)
by roskegg (subscriber, #105)
[Link] (3 responses)
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.
Posted Feb 16, 2014 2:35 UTC (Sun)
by mathstuf (subscriber, #69389)
[Link]
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.
Posted Feb 18, 2014 21:30 UTC (Tue)
by Wol (subscriber, #4433)
[Link]
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,
Posted Feb 18, 2014 21:56 UTC (Tue)
by rodgerd (guest, #58896)
[Link]
Anyone who has worked as a sysadmin for anything other than their own toy boxes should understand that.
Posted Feb 13, 2014 15:15 UTC (Thu)
by mathstuf (subscriber, #69389)
[Link]
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.
Posted Feb 13, 2014 12:43 UTC (Thu)
by anselm (subscriber, #2796)
[Link] (1 responses)
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.)
Posted Feb 14, 2014 3:05 UTC (Fri)
by uobe (guest, #95541)
[Link]
Posted Feb 14, 2014 19:26 UTC (Fri)
by smurf (subscriber, #17840)
[Link]
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.
Is it really over? I feel a twist coming on..
The Debian technical committee vote concludes
The Debian technical committee vote concludes
The Debian technical committee vote concludes
The Debian technical committee vote concludes
The Debian technical committee vote concludes
The Debian technical committee vote concludes
The Debian technical committee vote concludes
systemd depends on dpkg? I think it's some Debian technicality. It's not the case on Fedora :)
The Debian technical committee vote concludes
Those were stats for wheezy (stable), stats for jessie (current testing) are:
The Debian technical committee vote concludes
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
The Debian technical committee vote concludes
Wol
The Debian technical committee vote concludes
The Debian technical committee vote concludes
The Debian technical committee vote concludes
The Debian technical committee vote concludes
The Debian technical committee vote concludes
The Debian technical committee vote concludes
2/ systemd has too many external dependencies.
The Debian technical committee vote concludes
The Debian technical committee vote concludes
The Debian technical committee vote concludes
The Debian technical committee vote concludes
The Debian technical committee vote concludes
The Debian technical committee vote concludes
The Debian technical committee vote concludes
The Debian technical committee vote concludes
The Debian technical committee vote concludes
The Debian technical committee vote concludes
The Debian technical committee vote concludes
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!
Great news!
Great news!
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!
Great news!
Great news!
Say it with me three times:
sysvinit is not portable
sysvinit is not portable
sysvinit is not portable
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.
Great news!
Great news!
Great news!
Great news!
Great news!
Great news!
Great news!
Great news!
Great news!
Great news!
Those who did evaluate selected systemd in a blink. Phones (SailfishOS on Jolla), cars (GENIVI) and so on.
Great news!
Great news!
Yes, we did.
It's hard to find devices with so small amount or flash and RAM as to be incapable of running systemd.
Great news!
Great news!!
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!
Great news!
Great news!
Great news!
Great news!
Great news!
NAS with systemd
NAS with systemd
Great news!
Great news!
Great news!
Great news!
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!
Great news!
Great news!
Great news!
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.
Great news!
Great news!
Great news!
Great news!
Great news!
Great news!
Great news!
Great news!
Great news!
Great news!
Great news!
Great news!
Great news!
Great news!
Great news!
Great news!
Great news!
Great news!
Great news!
Great news!
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.
In fact I would argue that high-volumee remote logging is not what the journal or rsyslog should be doing in the first place.
Great news!
Great news!
Great news!
Great news!
Great news!
Great news!
Of course this goes to a General Resolution
Of course this goes to a General Resolution
Of course this goes to a General Resolution
Of course this goes to a General Resolution
Of course this goes to a General Resolution
Of course this goes to a General Resolution
Of course this goes to a General Resolution
Of course this goes to a General Resolution
Of course this goes to a General Resolution
Of course this goes to a General Resolution
Of course this goes to a General Resolution
Of course this goes to a General Resolution
Of course this goes to a General Resolution
Of course this goes to a General Resolution
Of course this goes to a General Resolution
Of course this goes to a General Resolution
Of course this goes to a General Resolution
Of course this goes to a General Resolution
Of course this goes to a General Resolution
Of course this goes to a General Resolution
Of course this goes to a General Resolution
Of course this goes to a General Resolution
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
Of course this goes to a General Resolution
Of course this goes to a General Resolution
Of course this goes to a General Resolution
> 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.
Of course this goes to a General Resolution
Of course this goes to a General Resolution
Now this sounds interesting. When and where did he say that?
Of course this goes to a General Resolution
Of course this goes to a General Resolution
Of course this goes to a General Resolution
Of course this goes to a General Resolution
Of course this goes to a General Resolution
Of course this goes to a General Resolution
Of course this goes to a General Resolution
2. Fedora
3. Frugalware
Of course this goes to a General Resolution
Of course this goes to a General Resolution
Of course this goes to a General Resolution
Of course this goes to a General Resolution
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.
Of course this goes to a General Resolution
Of course this goes to a General Resolution
Of course this goes to a General Resolution
Of course this goes to a General Resolution
Of course this goes to a General Resolution
Of course this goes to a General Resolution
Of course this goes to a General Resolution
Of course this goes to a General Resolution
Of course this goes to a General Resolution
Of course this goes to a General Resolution
Of course this goes to a General Resolution
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).
Of course this goes to a General Resolution
Of course this goes to a General Resolution
Of course this goes to a General Resolution
of people out there to do the same? The same for systemd, of course...
Of course this goes to a General Resolution
Of course this goes to a General Resolution
Of course this goes to a General Resolution
Of course this goes to a General Resolution
This one and only true ultimate non-distribution that you envisage ...
Of course this goes to a General Resolution
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
Of course this goes to a General Resolution
Of course this goes to a General Resolution
Of course this goes to a General Resolution
Of course this goes to a General Resolution
Of course this goes to a General Resolution
Of course this goes to a General Resolution
Wol
Of course this goes to a General Resolution
Of course this goes to a General Resolution
Of course this goes to a General Resolution
Of course this goes to a General Resolution
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
Of course this goes to a General Resolution
Of course this goes to a General Resolution
Of course this goes to a General Resolution
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!
Of course this goes to a General Resolution
Of course this goes to a General Resolution
Of course this goes to a General Resolution
This is the heart of the problem
This is the heart of the problem
This is the heart of the problem
This is the heart of the problem
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?
This is the heart of the problem
This is the heart of the problem
Look at glibc's implementation of string functions. They are not trivial.
I have Ubuntu 14.04
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
This is the heart of the problem
This is the heart of the problem
This is the heart of the problem
This is the heart of the problem
This is the heart of the problem
This is the heart of the problem
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.
Now try to compile the recent Boost library with this. I know because I did - it's not trivial.
Wrong. glibc is THE most problematic library in the Linux stack. Bar none.
This is the heart of the problem
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).
Then there's CMake which helpfully tries to find packages from the usual include/library directories.
This is the heart of the problem
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
This is the heart of the problem
This is the heart of the problem
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
This is the heart of the problem
This is the heart of the problem
This is the heart of the problem
Works just fine.
Ditto.
Haven't tried that.
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...
Nope. Multitarteting is --sysroot analog, but it's rarely necessary.
This is the heart of the problem
AFAIR, that was a beta bug.
Ah, here's a blog post that confirms this: http://blogs.msdn.com/b/vcblog/archive/2012/06/15/1032064...
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.
This is the heart of the problem
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.
It's a matter for another thread, but I have other arguments (like schizophrenic API).
This is the heart of the problem
This is the heart of the problem
00000000000930d0 T __strcpy_small
0000000000086070 t __strcpy_sse2
0000000000098ae0 t __strcpy_sse2_unaligned
0000000000153250 t __strcpy_ssse3
This is the heart of the problem
This is the heart of the problem
>
> 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).
This is the heart of the problem
This is the heart of the problem
This is the heart of the problem
This is the heart of the problem
This is the heart of the problem
This is the heart of the problem
This is the heart of the problem
This is the heart of the problem
http://git.liw.fi/cgi-bin/cgit/cgit.cgi/jenkinstool/ if you want to
have look.
easy to setup, and I don't particularly want to support it, but you
can have a look.
that easier for others to do.
This is the heart of the problem
This is the heart of the problem
This is the heart of the problem
So the libc->glibc transition is already forgotten? How swift the time passes...
This is the heart of the problem
This is the heart of the problem
This is the heart of the problem
This is the heart of the problem
This is the heart of the problem
This is the heart of the problem
This is the heart of the problem
This is the heart of the problem
This is the heart of the problem
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.
This is the heart of the problem
This is the heart of the problem
Of course this goes to a General Resolution
Of course this goes to a General Resolution
Of course this goes to a General Resolution
Of course this goes to a General Resolution
Then you're in luck! Systemd has clearly defined external interfaces with a stability guarantee.
And again, you're in luck! Most of systemd dependencies are either trivial or can be turned off.
They affected only the build system, not the end result.
And so does the variety of tools that are used for all this stuff right now.
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
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
Of course this goes to a General Resolution
> 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.
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.
> 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.
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
Yup. And they're committed to supporting it. And we have assurances of that from RedHat.
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.
Why should they be? BTW, power manager is separate.
Perfectly fine. I'm using it with only journald (and udev, of course) on embedded devices. I even removed localed and other auxilaries.
You need only one chink in the armor to get in. Are you sure that your syslog daemon is not subverted by NSA?
Computing is not biology. And I'm a computational biologist.
Yet the process scheduler has only single implementation.
Of course this goes to a General Resolution
Of course this goes to a General Resolution
Of course this goes to a General Resolution
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
Of course this goes to a General Resolution
Why is it PID 1 who needs to do that?
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
Of course this goes to a General Resolution
Of course this goes to a General Resolution
Of course this goes to a General Resolution
Of course this goes to a General Resolution
Wol
The Debian technical committee vote concludes
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
The Debian technical committee vote concludes
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
The Debian technical committee vote concludes
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.
The Debian technical committee vote concludes
The Debian technical committee vote concludes
$ 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
The Debian technical committee vote concludes
The Debian technical committee vote concludes
The Debian technical committee vote concludes
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.
The Debian technical committee vote concludes
The Debian technical committee vote concludes
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
The Debian technical committee vote concludes
The Debian technical committee vote concludes
The Debian technical committee vote concludes
The Debian technical committee vote concludes
The Debian technical committee vote concludes
We are talking about *changing* a longstanding default value.
The Debian technical committee vote concludes
The Debian technical committee vote concludes
The Debian technical committee vote concludes
The Debian technical committee vote concludes
The Debian technical committee vote concludes
The Debian technical committee vote concludes
Somebody obviously thought this feature was a real change, for it to have been implemented in the first place
The Debian technical committee vote concludes
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
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.
The Debian technical committee vote concludes
The Debian technical committee vote concludes
The Debian technical committee vote concludes
The Debian technical committee vote concludes
The Debian technical committee vote concludes
The Debian technical committee vote concludes
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:
CPUSchedulingPolicy=idle
IOSchedulingClass=idle
[EXTENDED] /usr/lib/systemd/system/packagekit.service → /etc/systemd/system/packagekit.service.d/bla.conf
The Debian technical committee vote concludes
Thanks to all concerned for their hard work, professionalism and undoubted ability.
We need to wait for a better solution in Jessie+1
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
We need to wait for a better solution in Jessie+1
We need to wait for a better solution in Jessie+1
We need to wait for a better solution in Jessie+1
We need to wait for a better solution in Jessie+1
We need to wait for a better solution in Jessie+1
We need to wait for a better solution in Jessie+1
We need to wait for a better solution in Jessie+1
We need to wait for a better solution in Jessie+1
Wol
We need to wait for a better solution in Jessie+1
We need to wait for a better solution in Jessie+1
We don't need to wait for a better solution in Jessie+1
We don't need to wait for a better solution in Jessie+1
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
