Stories
Slash Boxes
Comments

Dev.SN ♥ developers

posted by LaminatorX on Wednesday February 26 2014, @08:30AM   Printer-friendly
from the Boot-him?-I-just-met-him! dept.

jbernardo writes:

"Having had several issues with systemd, and really not liking the philosophy behind it, I am looking into alternatives. I really prefer something that follows the Unix philosophy of using small, focused, and independent tools, with a clear interface. Unfortunately, my favourite distro, Arch Linux, is very much pro-systemd, and a discussion of alternatives is liable to get you banned for a month from their forums. There is an effort to support openrc, but it is still in its infancy and without much support.

So, what are the alternatives, besides Gentoo? Preferably binary... I'd rather have something like arch, with quick updates, cutting edge, but I've already used a lot in the past Mandrake, RedHat, SourceMage, Debian, Kubuntu, and so on, so the package format or the package management differences don't scare me."

[ED Note: I'm imagining FreeBSD sitting in the room with the all the Linux distros he mentioned being utterly ignored like Canada in Hetalia.]

 
This discussion has been archived. No new comments can be posted.
Display Options Breakthrough Mark All as Read Mark All as Unread
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
  • (Score: 1) by MrNemesis on Wednesday February 26 2014, @01:16PM

    by MrNemesis (1582) on Wednesday February 26 2014, @01:16PM (#7409)

    Thanks, that makes a little more sense at least. But...

    Good Daemon management by default

    Can you expand on this a little perhaps?

    Binary log files ( prevents tampering with them)

    I'd have to agree with the AC above on this - I don't see what about binary log files makes them any more actively tamper-resistant than text-based ones, there doesn't seem to be any checksumming involved in the systemd implementation. In any case, if you're worried about log integrity you'd redirect to a syslog server - how is this accomplished with systemd? Is an equivalent command for `tail -f access.log|grep someuser` (or tail/ack)? Or even just plain grep?

    Aggregated logging makes event correlation easier.

    I assume you mean easier to match the timestamps from one to another? Granted this can be a pain in the arse especially when you have your system/kernel log measuring things from the time of boot whilst others base on various other formats (and a colossal case of haemorrhoids when you're correlating between two different time zones in three different formats), but for that there's tools like SEC [sourceforge.net]. Even so, what I'd love even more was if there was just a simple way for force an entire system to use the YYYY-MM-DD hh:mm:ss format globally like wot you can do in windows. Manually changing the locale (the only way I know to force it) is... ugly. Very ugly.

    Socket based activation of daemons/services

    I'm guessing this is to be used for dependency-based daemon startup? I'm not really sure what it entails otherwise.

    Nothing ground breaking that couldn't have been done before, but its all preconfigured to do it.

    I think that's probably the biggest problem people like me have with the concept - maybe it's because I don't really do anything advanced with finagling init scripts, but I've never had any problems with the ones in debian, they all seem to tie nicely together, and murmurs from a people about a lot of things changing (there was a comment here about single user mode no longer working for example) for what seems like a largely philosophical reason; I'm a pragmatist rather than idealist in that regard and I'll go with what works rather than something that might be more technically perfect but with considerable caveats.

    Guess I'll have to see how I get on with it once it's rolled into Jessie.

  • (Score: 3, Informative) by VLM on Wednesday February 26 2014, @03:35PM

    by VLM (445) on Wednesday February 26 2014, @03:35PM (#7490)

    "Guess I'll have to see how I get on with it once it's rolled into Jessie."

    Can try it today, if you're on testing or have a testing VM or a sacrificial box to test on.

    apt-get install systemd

    Maybe there was more to it, I don't remember.

    To run it, at the grub boot menu you hit e to edit your boot line (this one time) and add init=/lib/systemd/systemd to the kernel command line thingy and boot the temporarily edited config.

    Did you work, awesome, might want to think about editing /etc/default/grub and put the above into a GRUB_CMDLINE_LINUX_DEFAULT="init=/lib/systemd/syst emd" and run update-grub of course.

    Or if it blew up just reboot and avoid hitting E and changing your init, or if it blew up after changing the file "permanently" you can probably guess that on boot you edit the command line kernel params and remove that init line.

    Now forcibly removing sysvinit and keeping it out and only having systemd installed is going way beyond what I've done and I don't think its currently (easily) possible.

    I suppose a truly pathological event could happen if systemd blew up while you were hand editing binary database files or some such and screw up the whole machine or something. So the usual, "make backups" applies and so on. Although I've had no problems that doesn't prove your hardware can't etc etc etc.

  • (Score: 1) by weilawei on Wednesday February 26 2014, @04:22PM

    by weilawei (109) on Wednesday February 26 2014, @04:22PM (#7535)
    Yeah, Debian really screwed the pooch on this one. I'll be looking for a new distro as well. They can keep their Emacs-wannabe.
  • (Score: 0) by Bill, Shooter Of Bul on Wednesday February 26 2014, @06:56PM

    by Bill, Shooter Of Bul (3170) on Wednesday February 26 2014, @06:56PM (#7609)

    Socket based activation of daemons/services

    You can do crazy things like have a daemon that isn't started until it gets a request. Systemd listens on the port and then starts the daemon and hands of the port. This way the daemon doesn't have to be running all the time, and/or you can better utilize system resources depending on service demands. They're also working on integrating it into linux containers, so a service that lives inside a container gets started up upon request.

    Kind of cool.