There is a menace which is spreading like a disease throughout the Linux world, it is called systemd
systemd is my life source. I will use it for eternity.
I have been saying it is a virus for 6 years.
Welcome to 2011, bruv.
I will switch to an alternative when the alternatives are as good as systemd
Right now there are none
The #1 argument people have against systemd seems to be based on a fundamental misunderstanding: That systemd is a gigantic binary which runs as pid1. Evidently these people do not even make the least amount of effort into figuring out how systemd works. They just see “poettering!” and “omg started shipping it by default!” and immediately start throwing a tantrum..
I think of it mostly as childish “must resist authority!” symptom. One of these days they'll end up using systemd and realize how wrong all of their misconceptions about its design were.
I know because I was in the same boat.
t. Gentoo+systemd user
Systemd is becoming the de facto standard init system for Linux. It replaces the venerable SysV init with a clean and efficient design, and brings a stream of new functionality that makes the life of users, administrators and packagers easier. It is better than existing alternatives for all of these current use cases:
Application and infrastructure servers benefit from reliable and easy service management, cleaner dependencies, service monitoring, security features and global system integration.
Desktops, laptops and session servers benefit from session management, multi-seat, unified system interfaces, as well as integration with udev, D-Bus and other system services.
Embedded systems benefit from speed improvements, shell-less design, ability to remove optional components, and lower memory footprint.
Systemd is well designed. It was conceived from the top, not just to fix bugs, but to be a correct implementation for the base system services.
Systemd makes the boot process much simpler, entirely removing the need to specify dependencies in many cases thanks to D-Bus activation, socket activation, file/inotify activation and udev integration.
Systemd can handle the boot process from head to toe, without needing to use any of the existing shell scripts.
Systemd is straightforward. The command-line interface is probably the best existing for service management. The unit file format (like .desktop or “ini” files) is completely declarative, can be parsed using standard tools, and is a breeze to maintain.
Systemd unit files, unlike SysV scripts, can usually be shipped by upstream, or at least shared with other distributions (already more than 1000 existing unit files in Fedora) without any changes, the Debian specifics being handled by systemd itself.
Systemd is incredibly fast (1 second to boot). It was not designed with speed in mind, but doing things correctly avoids all the delays currently incurred by the boot process.
The transition plan is easy, since existing init scripts are treated as first-class services: scripts can depend (using LSB headers) on units, units can depend on scripts. More than 99% of init scripts can be used without a modification.
are people still actually pushing sysv init?
Systemd is not just init. It unifies, in fewer lines of code, everything that is related to starting services and managing session groups: user login, cron jobs, network services (inetd), virtual TTY management… Having a single system to handle all of that allows us to remove a lot of cruft, and to use less memory on the system.
Systemd uses control groups to ensure that any service, regardless of its state, can be shut down properly.
Systemd extends the logging features of the system in many ways with journald, and can remain integrated with the existing rsyslog daemon. Logs are in a structured format, attributed to filename, line of code, PID and service. They include the early boot (starting from initramfs). They can be quickly filtered and programatically accessed through an efficient interface.
Systemd’s virtual TTY management allows real multi-seat support, and revoking access to input devices on session switch.
Systemd can trivially add security settings to a service without any need to patch it: user/group change, chroot, private network, private /tmp, read-only access to parts of the tree, tcp wrappers, filtering system calls, ?NoNewPrivileges (kernel feature to avoid privilege changes), limiting effective capabilities, limiting whatever the kernel provides in an integrated manner (device bandwidth, CPU usage, memory usage, OOM settings, nice levels, timer slack, ulimits…)
Systemd’s centralized service startup and monitoring makes it much easier to setup high-availability using software like heartbeat or pacemaker.
Systemd ships a growing number of useful, unified command-line interfaces for system settings and control (timedatectl, bootctl, hostnamectl, loginctl, machinectl, kernel-install, localectl).
Open source shilling
In addition to command-line interfaces, Systemd provides a D-Bus API to control service management and access system settings, as well as bindings to do that from Python, node.js, php, lua, Qt… GNOME is relying on these services, and it is likely for KDE and Xfce to use pieces of it in the near future. They are not specific to systemd per se, but so far it is the only implementation.
Systemd can run without any configuration change in a virtual machine or a container. It will automatically skip unwanted services.
Systemd provides full watchdog support. If configured to do so, PID 1 will enable the watchdog and will perform the watchdog notifications itself. Suitably configured services use systemd as the watchdog, and notify it regularly to be considered alive. In this way, the whole system is supervised, with the hardware supervising systemd, and systemd supervising the rest.
Systemd can be used used inside the initramfs (see dracut on Fedora), which means the same code serves an additional purpose, and there's less stuff to maintain. It can also hand control back to the initramfs at shutdown, making it possible to cleanly unmount the root filesystem even in very complicated, stacked setups.
Systemd is introspectable and easy to debug: in addition to the ability to provide debugging output and a debugging shell much earlier in the boot process than other boot systems can, systemd features command-line and GUI tools to debug the state of individual services and understand precisely why they fail to work correctly.
Systemd is moving strongly in the direction of configuration-less system (i.e. “empty /etc/”). So /etc/fstab might be empty on a system with a GPT partition table, with partitions mounted in appropriate places based on their type id. This means that the configuration of the common one-machine-one-disk setup becomes even simpler.
My main complaint with systemd is the goddamn mission creep and bloat.
thats some elaborate bait
but your first sentence jumped the shark already sorry
>its well designed
Works on my machine.
Yeah well Poettering for systemd to be usable it would have to run few more machines than just yours.
It's Debian's official stance on Systemd.
Allow me to point you at a specific example:
For many decades, we've used the time-honored crond and related services to take care of all sorts of scheduled tasks.
And for many decades, this system has been stupidly limited and rudimentary:
- The syntax is a mess
- No support for random offsets (at best you could do some sort of hacky sleep $RAND solution but that won't survive reboots for example)
- No distinction between wall clock and system clock: can't have a monotonic timers (e.g. relative to boot time or last run time), you need more hacky scripts to detect downtime periods (e.g. to have a script on next boot if it triggered during downtime), and so on
- There's no real interface for it. There's no way to ask your crond implementation when scripts are due to run next, when they last ran, etc.
- Getting and storing output of these scripts is basically impossible, most cron scripts solve this by having their own hacky mail-on-error built into the script itself. No log output in the journal, etc.
Now systemd comes along and replaces this archaic, bloated and limited system by something that plugs neatly into the existing systemd architecture while re-using existing tools (that are part of systemd for the purposes of daemon monitoring anyway).
Why should we stick to the bloated crond solutions of the past if there's a modern replacement that's not only more feature complete but also easier to work with (e.g. using systemctl list-timers)?
isn't systemd-mount a thing now
It generates mount units (which will eventually replace fstab) it doesn't replace mount.
Timers will also eventually replace cron because they are superior in every single way.
Wall of text sperglords gtfo
Or you could fix crond.
systemd is pretty much to the system what KDE is to the desktop environment
By unifying everything on top of a common interface and reusing common components aggressively, you achieve consistency, performance and the ability to bring forth change
Biggest downside is that by installing e.g.
kmail you now have to pull in all of the common KDE/Qt library components that it reuses. (Although systemd is not quite as bad - there are still some dependencies you can't quite get rid of, like the dependency on dbus)
In the end it's a tradeoff. Do you want a modern system with a rapid improvement cycle and low footprint which reuses code and provides a nice user interface? Use systemd
Do you want a system where you can easily rip out any single component and hack the rest together with enough shell scripts to make a perl programmer cry? Use sysvinit
systemdaemon has no effects for users. Users will see no difference between it and openrc / sysvinit. systemctl is also the most handy thing ever.
Prove me wrong bitch.
systemd AKA SINGLE POINT OF FAILURE
Can confirm, have been using openrc for 2 years and no difference to systemd in terms on usability.
So just switch to openrc already
Just in time for people to look into abandoning Windows... Hmmmm......
In case of fuckup it recovers cleanly. Problem?
>Users will see no difference between it and openrc / sysvinit.
Users will, because the interface is nicer and the system is more reliable
(OpenRC can't even detect a crashed service and restart it)
Single point of failure that just so happens to be split up into 10 binaries running as different processes, all of which are opt-in?
systemd is fine.
If you don't like it for whatever reason, just use something else, dumb dumbs.
Good. Fstab is a fucking mess that needs to die badly.
There is zero overlap between Windows users looking to switch and Linux users interested in the details of their init system.
And that is the true Linux philosophy.
People are looking to switch from svchost to a stable and modular system and all we have now is systemd which is basically a halfassed svchost...
[quote] * When the user presses Ctrl-Alt-Del more than 7x within 2s an
immediate reboot is triggered. This useful if shutdown is
hung and is unable to complete, to expedite the
operation. Note that this kind of reboot will still unmount
all file systems, and hence should not result in fsck being
run on next reboot.[/quote]
That didn't work, I'm disappointed.
>It unifies, in fewer lines of code, everything that is related to starting services and managing session groups: user login, cron jobs, network services (inetd), virtual TTY management…
Does this mean skynet is a possibility?
>suckless.org
Can we tie them and systemd together and blow them up both? Those sprerglords are about as bad as pöttering.
Oh for fucks sake get over yourself.
Systemd doesn't turn Linux into Windows, and if you call SysV Init "stable" compared to Systemd, you simply have no clue what you're talking about.
>bruv
faggot yuropoor
this
>Hey we made a WM
>Every program we couldn't get to work with it sucks.
>And every program that's designed differently than ours sucks too.
>Hey, and you suck. And you. And you all.
Why would I want all the trouble of Windows with none of the compatibility?
Sometimes I honestly wonder how much you have to smoke to start thinking like this
1. Nobody on windows gives a solitary rat's arse about the details of svchost
2. What the hell does svchost have to do with systemd?
lol suckless
>use slock
>it literally crashes if you type in the wrong password and press enter
>completely useless as a screen lock
>report bug in their IRC channel
>they tell me to fix it or shut up
>use i3lock instead
>works fine
suckless, never again
Just let it go and enjoy riding the wave.
> Get over systemd already. It's never going away. Join us.
I had to use sysvinit for a while (server required CentOS 6) and it was fucking trash. And this is coming from a guy who had used Slackware for years before. After having gotten used to system I literally dreaded every time I had to make a change to sysvinit because it would involve wading through unreadable scripts written by some guy 10 years ago. Want a process to run as a specific user? Ho boy, enjoy your new coding project while also trying not to break the fragile scripts and cause your system to hang next reboot. And don't even get my started on how slow reboots were with it, systemd would boot faster than the POST.
Super glad I got to move it to Debian with systemd.
Your post would suggest the majority of the problems you faced with ``sysvinit'' were caused by your incredibly poor typing. Perhaps you are just stupid but type well; I don't really care either way.
>the obvious weakness of GNU/Linux has always been the fragmented, relatively non-standardized set of packages that somehow need to work together to get a working operating system up and running
>systemd fixes this entirely by being a single replacement for many packages, applications and daemons
>it's somehow the boogeyman of the Linux world
It's better this way.
>obvious weakness
Cool opinion, pal.
Linux being fragmented in every conceivable way is fact, not opinion.
That picture is a perfect representation of the site author.
I haven't seen so much crying in a long time.
>le skynet joke i am so nerdy XDDD
FUCK YOU AND FUCK YOU SKYNET JOKES.
I'm so fucking tired of the skynet joke.