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.]
(Score: 1) by MrNemesis on Wednesday February 26 2014, @01:16PM
Thanks, that makes a little more sense at least. But...
Can you expand on this a little perhaps?
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?
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.
I'm guessing this is to be used for dependency-based daemon startup? I'm not really sure what it entails otherwise.
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
"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
(Score: 0) by Bill, Shooter Of Bul on Wednesday February 26 2014, @06:56PM
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.
(Score: 1) by pe1rxq on Wednesday February 26 2014, @09:28PM
So they are also reinventing inetd?
(Score: 0) by Bill, Shooter Of Bul on Friday February 28 2014, @01:39PM
http://en.wikipedia.org/wiki/Inetd#inetd_replaceme nts [wikipedia.org]
Integrated and expanded the functionality, yes.