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.

5 of 522 comments (clear)

  1. Completely wrong by Anonymous Coward · · Score: 5, Informative

    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?

  2. Re:Remove It by rubycodez · · Score: 5, Informative

    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

  3. Re:Hope! by Anrego · · Score: 5, Informative

    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

  4. Re:Remove It by Anonymous Coward · · Score: 5, Informative

    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.

  5. Ian Jackson by inhuman_4 · · Score: 5, Informative

    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.