I don't know if you have noticed that men and women are different. Women happen to be more suitable for taking care of babies because they can do one thing men can't: breastfeed.

At least, that is one of the reasons why my wife took 6 months maternity leave, and luckily in those 6 months our situation changed so that we could manage without her working. And we have had more children since, so she is still at home.

Of course, we do realise that she will have fewer years of work experience when/if she returns to work, and this also not earn what she would have if she had continued working. However, the investment in our kids/family life is worth it.

Isn't there a --no-remote or similar option?

Or you could install and use links.

Or you could setup apache or similar to serve the documentation.

Really? Please link to mailing list posts from Lennart pushing Debian or Ubuntu to to adopt systemd (advising on features/benefits relevant to an upcoming decison the distro already had to make does not count).

systemd can run legacy sysv init scripts just as badly (or better than) as sysv init can. No need for alarm or panic.

But, why do that when a 4-line config file can do most of what you need.

In the case of a more complex service, you can write a pre-exec script, so that may require some conversion.

Note that sysv init only does anything useful for 3 use cases:
-booting the system
-shutting down the system
-changing run levels (which both of tje above are considered to be)

On most machines these days, no one changes run levels more than once or twice a month.

Note that sysv init does absolutely nothing for stopping/starting or restarting services without changing run levels. All of this is done by scripts (that are compatible with sysv init) which are unique for every family of distros, and mainly source lots of othwr shell scrupt libraries. They also have different locations for the config files these scripts use.

Packages that are made to work on multiple distros need to ship their own tooling (which dulicates this but pften with their own bigs or misfeatures) to do what the 'init system' should provide standard interfaces for.

On a sysv init system, you can't even be sure you are starting a service the same way the previous admin did, because his environment (PATH, LD_LIBRARY_PATH etc.) might have been different. Compare the /proc/$pid/environ of a service started at boot to one that has been restarted since ...

systemd is noy perfect, but it is much better in all of these aspects.

So sysv init (or bsd init) isn't good enough for your desktop, why is it (or in actual fact, upstart in sysv compat mode) good enough for servers (where some of its features are more useful). Or do you want to duplicate configuration or functionality by running an 'init' system which basically has no useful features during the majority of time it is running and a supervising system (which doesn't integrate at all with supplied diatro packages)?

Do you really like the fact that all distros require separate scripts (e.g. some that use /etc/rc.d/functions for RH-derived distros, other scripts that work on Debian-derived distros, others for SUSE, Arch etc., because sysv init basically has no useful features and all distros implemented the missing minimumfunctionality differently?

The machines I regularly use have:
4GB
8GB
16GB

The last two need to run at least 2 and 4 VMs with 3Gb ram each respectively. Running chrome for day-to-day work would make these setups impractical, whereas firefox runs well (firefox needs to be restarted more frequently than the OSs, but not significantly).

Additionally, chrome/chromium have some display issues on one machine (linux, KDE, radeon).

No, I can't (or can't justify just for chrome when firefox is fine) adding more ram, most of the above are work machines, 1 already is fully populated with DDR2, upgrading the ram would be prohibitively expensive

Have you tried Red Hat Enterprise Virtualisation ( http://www.redhat.com/promo/rh... )? It adds the management features like vCenter Server adds the vSphere to ESXi, and costs less for a suppprted environment than the cheapest VMWare option, and has feature parity and performs better (kvm).

Citation needed. It seems to me the polarization has been created in the Debian community by the anti-systemd crowd. Instead of fixing the problems that resulted in systemd acquiring more of the Linux user-space functionality, or work actively towards supporting multiple init systems, they continually claim that there are divisions in the community created by the systemd developers.

This doesn't seem to be an issue in other distributions.

No, this example shows that in previous 'init systems', the init system was adding no value after the default runlevel was reached. You were basically just running a script, and you had the option to check its return value. It just so happens that the init system would also run this script when changing to the relevant run level (but not in exactly the same way).

In systemd, systemctl tells systemd to start the service. systemctl doesn't exec the script in question itself.

The difference is that, under e.g. sysvinit, while a server remains at a specific runlevel, init scripts are no different than any other scripts. This also means that there are potential problems, where the last person to have started the service may have had different environment variables which made the service work (PATH, LANG, LC_ALL, JAVA_HOME etc. etc.), now when it fails (or the machine is rebooted), you (or init, in the one case it actually does something) try and start it, and it doesn't behave the same way. Go compare the /proc/$pid/environ for a service on a sysvinit box that was started at boot to the environ if you restart it later. In systemd, since systemctl isn't forking the init script (or similar), a clean environment can be gauranteed.

So, since systemctl isn't exec()ing the script, systemctl doesn't have to wait for the execution to finish before it returns.

Setting Type=forking will change the behaviour to what you expect. Why? In the case of a forking daemon, the init system *should* wait for the process to fork before it returns. Maybe there should be another option for Type that doesn't require a PID file but does return the exit status.

However, instead you can always call sytemctl is-active broken_systemd after-the-fact. But, if your 'service' may take some time to get through it's initial checking, maybe you are better off using Type=forking.

Really? I find it easier to troubleshoot, as you can easily find the logs for any service (e.g. foo):
systemctl status foo

systemctl status postfix # will show the last 10 log entries for the service, along with all the other useful information
journalctl -f # tail all logs
journalctl -b /usr/lib64/postfix/pickup # show just the logs for this boot of the postfix pickup binary

These are a few examples from a different distro, so you'll have to use totally different commands and log file names ... oh wait, with systemd you don't need to do that, you can always easily find the logs unlike before where each distro configured it's chosen default logging daemon differently by default.

It looks like you haven't even bothered to read anything about systemd, and it's not like you have an excuse:
$ rpm -qd systemd|grep man|wc -l
291

A good place to start is probably 'man systemd'

If it *really* was that bad, surely you could have booted into a rescue environment?

Did you even try it?

What bugs did you encounter that were specifically due to systemd? Did you file any?

We are preparing to start rolling out RHEL7 (still have some internal packages to rebuild), and systemd didn't really feature as a problem at all.

s/Linux/Debian/

Many other distros switched to systemd with no antics, commotion, and very few problems.

Maybe the problem here is Debian, not systemd?