As others have already noted here, in theory, this shouldn't affect the non-technical end user - and in theory there is no difference between theory and practice but in practice there is.
I think few things posted here need some clarification:
It's an init system, not something users traditionally interact with.
It was the case with SysV init and with Upstart but it's not the case with systemd any more. It does a lot of things that users traditionally interact with:
It should completely replace the functionality provided by Upstart
—and do a few extra things
Two things to clarify - first about completely replacing Upstart:
No SysV init scripts
One of the issues that people have with systemd is that it doesn't run SysV init scripts. So there's one example that it doesn't completely replace the functionality provided by Upstart.
This is something that we could rely on for over 30 years and traditionally you wrote SysV init scripts for maximum portability without repeating yourself (by writing multiple versions of the same scripts), which is not the case any more.
This shouldn't be a problem when using only packages from official repositories because presumably all the packages that used to have either SysV init or Upstart scripts would need to have their scripts rewritten before they get packaged.
It will be only a problem for people who happen to use any third-party or custom software that have their init scripts written for either SysV init or for Upstart and those will need the init scripts rewritten before upgrading to a system with systemd (or get the upstart installed, which is also an option, or migrate to a system that doesn't use systemd).
There is systemd-sysv-generator that is supposed to automatically translate SysV init scripts to systemd scripts but there are some bugs and a long list of explicit incompatibilities.
Now, the second clarification - about those few extra things:
Few extra things
Those "few extra things" that systemd is going to cover - according to A Perspective for systemd - What Has Been Achieved, and What Lies Ahead presentation
by Lennart Poettering in 2014 at GNOME.asia - are the following:
- init system
- journal logging
- login management
- device management
- temporary and volatile file management
- binary format registration
- backlight save/restore
- rfkill save/restore
- encrypted storage setup
- EFI/GPT partition discovery
- virtual machine/container registration
- container management
- hostname management
- locale management
- time management
- random seed management
- sysctl variable management
- console managment
- auto discovery
- plug and play
- network management
- DNS cache
- mDNS responder
- LLMNR responder
- DNSSEC verification
- IPC in the kernel
- time synchronisation with NTP
- integration with containers
- sandboxing of services
- sandboxing of apps
- OS image format
- Container image format
- App image format
- GPT with auto-discovery
- Stateless systems
- instantiatable systems
- factory reset
- node initialisation and updates
- integration with the cloud
- service management across nodes
- verifiable OS images all the way to the firmware
- Boot Loading
- Building the Internet’s Next Generation OS Unifying pointless differences between distributions
So going back to: "It's an init system, not something users traditionally interact with." - it has to be pointed out that the init system is just one item on that list.
And finally, the last thing I'd like to comment:
[T]he only time a non-technical user will see this is when it goes wrong.
Oh, what a relief. :)
Most notable changes for end users (other than the scripts themselves) is starting and stopping services and using commands like:
which no longer work as expected. For example,
nohup is a POSIX command to make sure that the process keeps running after you log out from your session. It no longer works on systemd. Also programs like
tmux need to be invoked in a special way or otherwise the processes that you run with them will get killed (while not getting those processes killed is usually the main reason of running screen or tmux in the first place).
This is not a bug, it is a design choice, so it is not likely to get fixed in the future. This is what Lennart Poettering has said about this issue:
In my view it was actually quite strange of UNIX that it by default let arbitrary user code stay around unrestricted after logout. It has been discussed for ages now among many OS people, that this should possible but certainly not be the default, but nobody dared so far to flip the switch to turn it from a default to an option. Not cleaning up user sessions after logout is not only ugly and somewhat hackish but also a security problem. systemd 230 now finally flipped the switch and finally by default cleans everything up correctly when the user logs out.
For more info see:
systemd-run --user --scope screen
(Note: the behavior of "upstart" above is really anything except systemd, this is not upstart specific)
Starting job foo:
systemctl start foo
Stopping job foo:
systemctl stop foo
Restarting job foo:
systemctl restart foo
Listing jobs with their status:
(See my answer to What are the pros/cons of Upstart and systemd? for more details that are out of the scope for this question.)
There is also a big difference in handling the logs because contrary to the Unix tradition the logs of systemd are stored in binary files in a custom format, so instead of:
tail -f /var/log/upstart/foo.log
you need to use special commands to access your logs:
sudo journalctl -u foo
sudo journalctl -u foo -f
The introduction of systemd first to Debian and later to Ubuntu was not without controversies and vast opposition as is known to anyone who wrote one of the following articles:
The official Debian position on systemd and the resulting controversy has led to the Exodus declaration in 2014 and ended with Ian Jackson's resignation.
The Init Freedom, Without-Systemd.org and Systemd-Free.org initiatives were born, with a lot of discussion on Hacker News.