Slashdot Mirror
Debian Talks About Systemd Once Again
An anonymous reader writes: A couple of months ago the technical committee for Debian decided in favor of systemd. This is now a subject for discussion once again, and Ian Jackson says he wants a general resolution, so every developer within the Debian project can decide. After a short time, the required amount of supporters was reached, and the discussion can start once again.
The summary is completely wrong. They are not discussing systemd, just whether packages can depend on a specific init system. I thought there was some kind of moderation here?
systemd using binary logging, not text. Everything is a UNIX-like system was designed to be text based. binary format makes log files corruptible. systemd is huge. It has too many hooks into too much userland stuff. This should never be. The old way, while nowhere near perfect was better. Better what you know... systemd is not really progress. It's complicated and huge. Binary for logfiles is a no-no for old-school UNIX guys like me. systemd violates the tenets of the UNIX philosophy in many ways, not the least of which is the aforementioned binary logfiles. No. Just no.
Not FUD, if something wrong you'll never get to the part where you forward to syslog. Logs should be simple text files, that can be read even without the OS. ASCII text is viewable on just about anything
I've used gentoo for a long damn time, so my ability to objectively gauge it's difficulty is probably long gone.
That said, I for one think gentoo has gotten far easier to install and especially maintain. The default profiles are no longer the joke they once were, and most packages are using more generic high-level use flags so you have one --with-feature-x instead of the old --with-compat-mode-z --with-doublefork --with-some-other-unrelated-but-required-flag type stuff you had years ago, which translates into much simpler USE flags. You can actually leave make.conf relatively untouched and still end up with a decently functional system, especially if you want a desktop and go for one of the desktop profiles.
Portage is also a lot smarter these days, being able to resolve many issues that it previously would have died on. When it does run into problems, the descriptions these days are much nicer than before!
I'm being completely honest when I say that systemd has been the first major gentoo headache I've had in a while. Everything was just dandy then suddenly I'm having to switch packages around (udev being the big one), and having to blacklist udev and systemd because so much random shit pulls them in (and a -systemd use flag isn't enough), and then uninstalling a bunch of random packages (like some power management widget that got pulled in by god knows what for some reason).
I know you've probably written off gentoo at this point, here's a completely random bit of usage advice:
- Set use flags as you need them, even if this means re-installing the same thing multiple times. This avoids big important packages being pulled in as mere dependencies (though you can add them to the world list afterwards) and more importantly lets you set up and configure everything one at a time and makes it more likely that you'll notice error messages.
- Don't be afraid of package.keywords, especially for very specific use flags.
- Avoid gnome if possible. I don't know wtf it is with gnome, but it seems to be the poster child for weird and hard to diagnose issues as well as crazy dependency trees.
- Pay attention to what virtual packages are doing. Usually they are in your best interest, but not always.
- Don't bother using ebuilds for web apps
Seriously, why not OpenRC?
It solves all the deficiencies with classic init, but at the same time it doesn't have the interoperability problems and un-Unix-like feel of systemd.
I think in your rush to tell people they've missed the point completely, you've missed it yourself.
If you're reliant on trusting the logs of a system that you think might have been compromised you're already shafted. If an intruder can edit your plain text logs then they can edit everything else on the system as well, including binary ones; hacking is generally more sophisticated than vim /var/log/daemon.log dd dd dd :wq. There's nothing inherently unhackable about binary logs and if your box is rooted your only real option is to burn the hard drives to the ground and reinstall.
"Just add some hashes! Then the hash won't match and the log will reveal itself as being tampered with" comes the chorus. Nope. If you've already got the ability to rewrite the logs then recalculating the hashes so they match the massaged data is trivial.
The only remotely secure way to record logs is to write them off to a seperate log server (firewalled off, no remote access, managed by a completely different team, barbed wire, attack dogs, Slim Whitman, yadda yadda) the second they're generated - although by all means keep a local copy if you feel like it.
Windows has the whole binary logging thing, and goes to great pains to make them as hard to access as possible (which of course makes viewing them a pain as well). But anyone with admin access can clear the logs or delete whatever entries they like with winzapper or a few lines of code. Windows in secure environments uses... wait for it... a remote log server.
Long and the short of it is binary logs don't get you any extra security and, especially in the nix world where there are many and varied tools for examining plaintext logs, constitute a colossal loss of readability.
Disclaimer: I work in computer forensics. Most hacks are done by people who haven't even thought of covering their tracks and you'll have nice local log entries that tally up with those on the remote server that scream out "Look, here's me hacking teh gibson!". Advanced hacks are almost impossible to spot without a) a good IDS b) examining the discs offline.
I don't trust Poettering & Co's track record, nor competence, nor intentions (e.g. seeing him use sleazy manipulative rhetoric in a conference video where he accused a systemd opponent of not caring about handicapped people), and I sure don't want their unnecessary huge mass of dubious code on my machine. (Though I'm sure the NSA will be happy for the increased opportunities of exploits in such a huge messy mass of code.) And even if this "init system" were somehow really necessary for Gnome, I don't use Gnome.
They have lied, e.g. claiming that systemd is just an init system, or that it is not a big monolithic chunk of code, yet it becomes more and more monolithic. E.g. I just watched a week or two ago as several libsystemd packages in debian became merged into a single package while one user was trying to create a stub for one of them to satisfy some needless systemd dependencies by some applications.
I am becoming increasingly convinced that Ignorant Guru is right, and Linux is being manipulated for corporate interests, not users' interests. http://igurublog.wordpress.com...
Oh horse shit! Binary logs are the biggest crock of shit to blow out someones ass since Windows ME. Pure text log files can be parsed with the same system tools that come with all linux distributions. I'm talking grep, awk, and sed. An you really adventurous, perl.
All the excuses that I've seen for keeping this foul system are bullshit!
Supporting World Peace Through Nuclear Pacification
And yet all the complaints ignore the fact that systemd is a diverse modular set of tools, and not a monolithic blop, that can work perfectly well with other tools (like the usual system log).
Consisting of a boatload of different programs which are all required to work with each other and may not be switched out is not modular; it is, in fact, nearly the very definition of monolithic as applied to software.
And that not much code actually runs in PID 1.
Define not that much? How much is too much if the design and implementation are deeply flawed?
And that the TC found in its favor.
Railroaded by Red Hat, as anyone who actually followed the process knows.
And that before systemd there was a default init system that everyone used as well.
Because everyone was able to agree that that one worked in the way it should.
I'm not qualified to judge the technical merits of the case...
And yet you do.
...but the people that are overwhelmingly came down in favor of systemd.
Comments attempting to support systemd always seem to trot out this little chestnut, despite the fact that there is no evidence whatsoever to support it. It's almost like there's a playbook somewhere telling you all what to say.
The criticisms on philosophical grounds were rebuted and the rebutals stand unopposed.
Rebuttal: You keep using that word. I do not think it means what you think it means.
Instead the same questionable objections are raised again and again....
Which in most sane groups would indicate that the objections are perhaps not so questionable. Nice editorializing, though.
Anyone who talked against systemd in the debian IRC channel(s) was banned.
Anyone who talked forcefully against systemd on the debian mailing list was silently banned.
Eventually Anyone who wrote out "systemd" in a mail to the mailing list had their mails silently dropped, delayed, filtered.
(People started calling it killer rabbit)
Thank Don Armstrong (mailing list president for life) and the systemd cabal within debian.
(8 men plus all of debian-women)
.
Binary logs are anti-*nix. Rebut that.
That is of course wrong. If you have a POSIX compliant system, you have binary logs in /var/log. On Linux they are usually called "utmp" and "wtmp" and they keep track of logins and logoffs. You use the "last" tool to read these binary logfiles. utmpx is actually a formal part of Unix.
For those who don't know, Ian Jackson was the most vocal anti-systemd proponent on the committee. Considering that last time systemd was up for vote he tried: strategic voting, usurping the committee chairman, and finally throwing a temper-tantrum and refusing to talk to anyone for a few days. When it was all over he promised to try and reverse the committees decision with a General Resolution.
And now having failed to win on technical merits, he is back at it again trying to kill systemd via 'loose coupling'. Something that the committee declined to rule on.
Debian (you know, the topic of this discussion) and its many derived distros like Ubuntu had for many years used dash as their /bin/sh. Init wasn't passing anything to bash. Indeed, the switch was made because dash offered faster boot times for a script-based init system than bash.
That people think GIMP and GNOME require systemd is outright absurd. They both depend on a single feature exposed by the kernel which have nothing to do with the init system.
Caveat: I'm a part-time distro constibutor, and you're incorrect here.
I can't speak to GIMP, but Gnome most *definitely does* depend upon systemd -- the Gentoo distro just went through this, and it's documented in their bug tracker that systemd was now mandated via upstream. eg, Gnome3 depends upon logind which depends upon systemd. GDM now depends upon systemd. etc. etc. etc. This all really started happening around 3.8-3.12.
This left gentoo devs in the position where they could patch Gnome3 to not require logind, but then suspend/restore doesn't work unless they revert and patch upower, and on and on on.