But you are doing the work the computer should do by scripting your own startup process. Also, it will process your rc.local sequentially whereas systemd does things in parallel. If you have 5 different custom services that need network, your approach would have them started one after another. Systemd would wait for network access and then start them all in parallel. If one of those hangs, the others will still start in a few seconds (unless they depend on the hanging service) and the boot process will still continue.

Also, what about if some service fails? systemd can restart them automatically, you have commands to see at a glance whether your desired services are all running (i.e. the system is in your desired state), it manages the log outputs for each service, etc. etc. … it’s a huge comfort win and once you’ve written a few units, you won’t have to look everything up all the time.

[Unit]
Description=My service
After=network-online.target

[Service]
ExecStart=/usr/local/bin/myservice -d

[Install]
WantedBy=multi-user.target

Put this in /etc/systemd/system/myservice.service, run systemctl daemon-reload followed by systemctl enable myservice and Bob’s your mother’s brother. Optionally, start it directly using systemctl start myservice. (On most systems, service myservice start will work, too.) It doesn’t get any easier than that.

And, if you start to automate your system’s configuration(s) using e.g. Ansible, it’s far easier to just place a few files in the filesystem and run a few commands than to modify the rc.local in an automated fashion without breaking something.

While I don’t really like the one-tool-for-everything approach with systemd and its various additional features (timedated, resolvd, etc.), I do like the main feature.

Thing is, even when Ubuntu’s software has been packaged outside Ubuntu, it’s so far failed to gain traction. Upstart and Unity were available from a Gentoo overlay at one point, but never achieved enough popularity for anyone to try to move them to the main tree. I seem to recall that Unity required a cartload of core system patches that were never upstreamed by Ubuntu to be able to work, which may have been a contributing factor. It’s possible that Ubuntu doesn’t want its homegrown software ported, which would make its contribution to diversity less than useful.

I’d add irrational hate against Canonical to the list of possible causes.

Canonical’s done a few things that make it quite rational to hate them, though. I seem to remember an attempt to shoehorn advertising into Ubuntu, à la Microsoft—it was a while ago and they walked it back quickly, but it didn’t make them popular.

(Also, I’m aware of the history of systemd, and Poettering is partly responsible for the hatred still focused on the software in some quarters. I won’t speak to his ability as a programmer or the quality of the resulting software, but he is terrible at communication.)

And you have fixed versions every half a year with a set of packages that is guaranteed to work together. On top of that, there’s an upgrade path to the next version - no reinstall needed.

I’ve been upgrading one of my Gentoo systems continuously since 2008 with no reinstalls required—that’s the beauty of a rolling-release distro. And I’ve never had problems with packages not working together when installing normally from the main repository (shooting myself in the foot in creative ways while rolling my own packages or upgrades doesn’t count). Basic consistency of installed software should be a minimum requirement for any distro. I’m always amazed when some mainstream distro seems unable to handle dependencies in a sensible manner.

I have nothing against Ubuntu—just not my cup of tea for my own use—and I don’t think it’s a bad distro to recommend to newcomers (I certainly wouldn’t recommend Gentoo!) Doesn’t mean that it’s the best, or problem-free, or that its homegrown software is necessarily useful.