Lennart Poettering Takes To Battling Systemd Myths

[nightmarex]

Was I pissed when UDEV got forced to systemd, yeah, I got over it.

Do I like systemd? I guess, I am warming up to it.. still not super fond of the daemon setup however.

edit: by not being fond of the daemons I mean this crap "systemctl enable servicename.service" <- do I really need to type .service all the time? fuck.

[Ericg]

Was I pissed when UDEV got forced to systemd, yeah, I got over it.

Do I like systemd? I guess, I am warming up to it.. still not super fond of the daemon setup however.

edit: by not being fond of the daemons I mean this crap "systemctl enable servicename.service" <- do I really need to type .service all the time? fuck.

Not on mainline systemd. A few release back the requirement to always add ".service" got removed. now you can just do "systemctl enable servicename1 servicename2 servicename3" Your distro may not have that version yet, but Arch-current does

[xeekei]

Was I pissed when UDEV got forced to systemd, yeah, I got over it.

Do I like systemd? I guess, I am warming up to it.. still not super fond of the daemon setup however.

edit: by not being fond of the daemons I mean this crap "systemctl enable servicename.service" <- do I really need to type .service all the time? fuck.

No, you don't. Try it.

[cynyr]

Systemd can also parse init.d/rc.d scripts so theres that OR you could set it up where the .service file for your app actually just calls your custom written rc.d/init.d script. Make a script for mediatomb, drop it in /etc/init.d/ then just whip up a quick mediatomb.service file, drop it in /etc/systemd/system. have:

ExecStart=/etc/init.d/mediatomb start
ExecStop=/etc/init.d/mediatomb stop

this way you dont have to really mix and match init systems. a quick "systemctl enable mediatomb" will tell it to start on boot. and a "systemctl start mediatomb" will run ExecStart. Because its in /etc/systemd/system you dont have to worry about it ever being overwritten. The only problem would be if mediatomb did ever ship a default .service file, yours would automatically override it because they have the same name. So you might want to make it be "my-mediatomb.service" or something like that.

I could use the gentoo init file, except that it's not a sysV init file. It is not standalone and depends on other bits of software to work (namely runscript) and includes dependancy info in the init file. I don't really want to write init scrips just so that I can use a different init system, when the one I have works well and is fast enough. So, until everything is shipping with .system files I think I'll stick with the distro default, and a distro that doesn't use systemd.

As for the journal thing, why would I want two logs on the same machine? Either make sure that I can recover the logs, from a mostly corrupt HDD as long as I can read at least some of the file, or let me not run journal at all, and pass everything to syslog-ng. chrooting and running the installed copy of journal is not good enough and not being able to get anything out on a partially corrupted file is also not good enough.

[Ericg]

I could use the gentoo init file, except that it's not a sysV init file. It is not standalone and depends on other bits of software to work (namely runscript) and includes dependancy info in the init file. I don't really want to write init scrips just so that I can use a different init system, when the one I have works well and is fast enough. So, until everything is shipping with .system files I think I'll stick with the distro default, and a distro that doesn't use systemd.

Gentoo's wiki (http://en.gentoo-wiki.com/wiki/Systemd#Services) has a mediatomb .service, for the record. And if mediatomb doesn't ship a .service file then thats mediatomb's fault, just as it would be if they didnt ship a sysV init or an upstart job

As for the journal thing, why would I want two logs on the same machine? Either make sure that I can recover the logs, from a mostly corrupt HDD as long as I can read at least some of the file, or let me not run journal at all, and pass everything to syslog-ng. chrooting and running the installed copy of journal is not good enough and not being able to get anything out on a partially corrupted file is also not good enough.

syslogs are only there in an emergency, same way you would use a remote syslog server in the emergency event of a break in on a production machine. So far i haven't had a situation where the journal wasn't enough. "Or let me rn the journal not at all and pass everything to syslog-ng" Thats what im doing. Journal and syslog both capture log messages. Journal doesnt block syslog in any way. In fact they made it a point to allow syslog and journal to be running simultaneously.

[danielbot]

...it cant be bloated because bloated implies that things are forced. Is the kernel bloated?

Yes, the kernel is bloated. Why do you ask?

[danielbot]

He said he'd EVENTUALLY remove support for non-systemd. People always forget the "EVENTUALLY." Once people started freaking out he clarified that it was not a short-term goal by any means and would only happen once systemd was THE standard in the linux ecosystem and there WERE no competitors TO support.

It should not be a goal at all. Having the udev maintainer and systemd maintainer be the same person is a recipe for disaster. Untenable situation in my opinion. Obviously, the temptation to leverage udev to accelerate the demise of systemd competitors must be strong, and chances are, irresistable.

[danielbot]

Major distros who are using SysV?

Gentoo, Slackware, Debian (Im leaving RHEL + its clones out of this because RHEL7 uses systemd)

Major distros using Upstart?

Ubuntu, (+derivatives, but basically Ubuntu.)

Everyone else? systemd

Sounds like the preponderance of "everyone else" is "Red Hat".

[danielbot]

...systemd's biggest dep is indeed, dbus....

dbus is, by far, the least reliable component on my workstation. Goes into 100% CPU way more times than is comfortable for me. Not the only reliability or performance issue, far from it. The fact that systemd is intimately tied to it is hardly a stellar recommendation.

[danielbot]

"My recommendation for distros who want udev without the rest of systemd
is to build systemd normally and just pick the files you are interested
in from "make install"" -- Lennart Poettering

Arrogant does not begin to describe this attitude.