Systemd Dreams Up New Feature, Makes It Like Cron

[duby229]

The only subsystem they've incorporated is udev. And the udev-merger was backed by the original writer of udev, the then-current maintainer of udev, every main udev developer and all of the systemd developers. It was a good idea since systemd handles modules. You can still use udev without systemd just fun, no ones stopping that. Yes it may be a little harder since you have to pull udev out of the compiled folder but thats not your specific concern, thats the distro maintainers concern. And the only distros that have to worry about that are Ubuntu, Gentoo, Debian and Slackware. Everyone else IS on or WILL be on systemd by the next release.

I had a legthy post written but it was too inflammatory so I deleted it.

You'll see. I don't give sysd more than 4 years before it gets replaced. It won't be long lived. Once it hits the limitations imposed by the maintainer and these distro's see how futile it is they will adopt something else. And the work that is being done now to work around it will be key.

[Ericg]

I had a legthy post written but it was too inflammatory so I deleted it.

You'll see. I don't give sysd more than 4 years before it gets replaced. It won't be long lived. Once it hits the limitations imposed by the maintainer and these distro's see how futile it is they will adopt something else. And the work that is being done now to work around it will be key.

What limitations? The only pieces of 'core' systemd are udev, systemctl and journalctl. Everything else is a module. Modules can be swapped in and out at will. So unless they find a major limitation within one of those 3 core pieces, any problems will be solved by replacing said module.

The only work right now to "work around" systemd is eudev which so far only has the expressed backing of gentoo. Slackware has said systemd is "essentially evil" but they havent gone so far as to back eudev.

[duby229]

You mean to tell me that you don't remember just a few posts back where you effectively stated what the limitations were? I clarified it for you in plain english.... Do I really need to repeat it again?

[Ericg]

You mean:

Well, you just prove my point. They removed capability, compatibility, stability, and support and then said if you don't like these faults and want to do something else then oh well..... And this even though they have incorporated subsystems that are still needed outside of sysd.

Thats the problem.

Capability? You can have a .service execute a shell script if you really need it to.
Compatibility? Meh, sometimes you need to break compatibility. It happens all the time, the only piece of software NOT allowed to break compatibility is the kernel.
Stability? Honestly I had more problems with sysV than I have with systemd. Mostly related to poorly written init scripts, in comparison: its pretty hard to mess up .service scripts.
Support? Yeah, but everyone knew that going in. Non-linux kernels arent support, end of story. No other kernels have the features that systemd uses, if they did then they would be supported.

[bobwya]

systemd is always going to be really controversial. I've played about with it a bit (on Gentoo, ARCH, OpenSUSE, etc.) The boot and shutdown speed-up is phenominal (especially on the distros that have whole-heartedly made the switch). I do see some occasional low-level bugs being exposed (which would be hard to debug since they appear to arise from the parallelisation of the startup process) - so I still wouldn't call it "production ready" (I wouldn't want to use it on a server).

However I have yet to work out how to reach a console target with any kind of minor error in the main fstab file (I plan to experiment with systemd automount units for non-critical/non-system mounted partitions). This issue can be a real pain in the ****... The journalctl command is nice - when you can run it - but where does systemd actually log to if you can't even reach a TTY terminal console target? systemd output literally whizzes past - so you can't spot errors quickly enough (unlike the highly sedate open-rc/system-V init process). Upstart may be a train-wreck - but at least it gives me the option to skip invalid fstab mountpoints... Googling for questions like this - just doesn't get any hits yet...

Even the ancillary BASH completion script has some annoying bugs (not handling unit names containing the escape character). I can't find the (original) Upstream source for the patch I wrote for this to fix the problem...

Will systemd stay around. YES - it's here to stay on Linux-based systems - anyone saying otherwise is totally deluding themselves... Over 10 pages of comments so far says it all...

BTW "systemd" should always written lower-case (I've been told off about that )

[Ericg]

systemd is always going to be really controversial. I've played about with it a bit (on Gentoo, ARCH, OpenSUSE, etc.) The boot and shutdown speed-up is phenominal (especially on the distros that have whole-heartedly made the switch). I do see some occasional low-level bugs being exposed (which would be hard to debug since they appear to arise from the parallelisation of the startup process) - so I still wouldn't call it "production ready" (I wouldn't want to use it on a server).

Parallelization bugs should be reported. Systemd is supposed to buffer anything from any process going to any other that isn't started yet, then the moment that process HAS been started its supposed to push that buffer to the process to be handled.

However I have yet to work out how to reach a console target with any kind of minor error in the main fstab file (I plan to experiment with systemd automount units for non-critical/non-system mounted partitions). This issue can be a real pain in the ****... The journalctl command is nice - when you can run it - but where does systemd actually log to if you can't even reach a TTY terminal console target? systemd output literally whizzes past - so you can't spot errors quickly enough (unlike the highly sedate open-rc/system-V init process). Upstart may be a train-wreck - but at least it gives me the option to skip invalid fstab mountpoints... Googling for questions like this - just doesn't get any hits yet...

Can't comment on the fstab issue, but as far as boot-time messages.... on arch the default is systemd outputs to stdout (VT1) and then X is started on VT7. If want to see the messages that got printed out during boot I just have to jump to VT1 and they are right there at the top of the screen. Maybe your distro is similar or you can ask in your distros forums why its NOT doing that?

BTW "systemd" should always written lower-case (I've been told off about that )

yes it should. It is not Systemd, it is not SYSTEMD, it is not SyStEmD, it is not systemD or SystemD. It is systemd. The one and only exception is the beginning of a sentence when it may be spelled "Systemd" for the sake of proper english.

^That pulled from lennart's blog about how to spell systemd :P

[RahulSundaram]

However I have yet to work out how to reach a console target with any kind of minor error in the main fstab file (I plan to experiment with systemd automount units for non-critical/non-system mounted partitions). This issue can be a real pain in the ****

You are looking for the option "nofail" or 'noauto,x-systemd.automount' depending on your preference.

[bkor]

Sanity? Shell scripting is a very powerful tool that shouldnt be thrown out the window.. That is definitely insane to do so.
Reliability? Sure if your running a system that has all the .system files that is needed. But what happens when you install something that doesnt? It happens alot. Not to mention all of the compatibilty problems that is still has. Hell apache2 still doesnt have a reliable .system file.
Standardization? It doesnt work on every distro even still, and then it doesnt work on every hardware that older init system could,. It doesnt work on every kernel that older ones could.

You make a lot of stuff up that is addressed in the article already. Repeating things does not make it true.

E.g. it removes various shell scripts, but you can still have your shell scripting. If you install something which still has a sysvinit script, then systemd supports that just fine.

Did you actually use systemd? It comes across as making stuff up as you go along. Suggest to read the article.

Now regarding: "it doesnt work on every distro": sysvinit script do not work across distributions, various things are done differently, plus some distributions do not have /bin/sh as bash, which exposes the loads of bugs that occur in various sysvinit scripts. Systemd unit files are now part of upstream because they're just a configuration file.

I don't see systemd having that many bugs, unless you are using Fedora. Fedora always introduces features early. But that is the idea behind Fedora, so...

[GreatEmerald]

Make sure you check both the Arch Linux wiki (https://wiki.archlinux.org/index.php/Systemd/Services) and the Gentoo wiki (http://en.gentoo-wiki.com/wiki/Systemd) to see if there's an available .service file for your daemon. If they do, I would actually recommend putting those in /usr/lib/systemd/system instead of /etc/systemd/system for the sole reason: if one day the package provides its own .service file, it will automatically overwrite the non-native one you copy-pasted or wrote yourself, assuming they have the same name

Hmm, actually, the two less-usual daemons that I will need to use (distccd and hostapd) are not mentioned, but they appear to have service files on Arch, so if anything it should be possible to get them off there.

[Marc Driftmeyer]

Fsck other kernels. Systemd isnt SUPPOSED to support other kernels. It uses linux-specific features to bring up linux systems. If *BSD wants systemd then they can implement cgroups and any other feature needed by systemd.



Sanity? It tosses indecipherable shell-scripts out the window.
Reliability? Have you used it recently? Originally it had some bugs, sure, but systemd had brought systems up and down without problems since F17's release.
Standardization? It means no more pointless differences in distros configuration files.

FreeBSD has a port of Launchd which is rational seeing as FreeBSD and Darwin cross-polinate with one another.