Head to [ Ссылка ] to save 10% off your first purchase of a website or domain using code thelinuxexperiment

Grab a brand new laptop or desktop running Linux: [ Ссылка ]#


👏 SUPPORT THE CHANNEL:
Get access to a weekly podcast, vote on the next topics I cover, and get your name in the credits:

YouTube: [ Ссылка ]
Patreon: [ Ссылка ]
Liberapay: [ Ссылка ]

Or, you can donate whatever you want: [ Ссылка ]

👕 GET TLE MERCH
Support the channel AND get cool new gear: [ Ссылка ]

🎙️ LINUX AND OPEN SOURCE NEWS PODCAST:
Listen to the latest Linux and open source news, with more in depth coverage, and ad-free! [ Ссылка ]

🏆 FOLLOW ME ELSEWHERE:
Website: [ Ссылка ]
Mastodon: [ Ссылка ]
Pixelfed: [ Ссылка ]
PeerTube: [ Ссылка ]
Discord: [ Ссылка ]

#Linux #Systemd #opensource

00:00 Intro
00:42 Sponsor: 10% off your first website
01:36 Init systems and SystemD
03:21 SystemD is bloated?
05:48 Everything depends on it now?
07:01 It's a Red Hat project?
08:44 It restricts choice and modularity?
09:51 It makes Linux less secure?
10:59 Why use systemD?
12:37 Parting thoughts
13:52 Sponsor: Get a PC made to run Linux
14:52 Support the channel

All Linux based systems use an Init system, short for initialization: it's the first process that starts after you boot your OS, and it runs in the background while you're using your computer, to manage system services, and various processes. For many, many Linux distros, SystemD is this init system.

SYstem D is a relatively recent project, at the scale of Linux anyway, it started in 2010, and was spearheaded by Red Hat. Its goal was to replace the existing solutions, like SysV or Upstart, to make things faster and more resilient.

It quickly became the default on Fedora, obviously, then on Arch Linux, Debian, Ubuntu, SUSE, and many, many others.

The famous Bloat argument is one advanced most often. System D, as time went on, encompassed more and more features that were generally handled by individual services, not the init system itself, like device management, login, or network management and creating logs.

This can be perceived as going against the Unix philosophy, where a piece of software is supposed to do just one thing, and to communicate well with other small systems.

What's certain is that most distros that implement it are general purpose distros, that need to provide as many systems as possible, and so they tend to use most of systemD's features and modules.

SystemD also "hides away" certain configurations with its own tools, like systemctl, instead of exposing everything as a config file. Whether these things are important or not, though, depend on the person.

Another criticism levelled at System D is the fact that it has become so pervasive that a lot of other components are created with a hard dependency on it: without SystemD, they can't work at all, or will have a limited featureset. This results in some extra work for distros that don't want to use systemD, as they have to use an alternative implementation of these features.

Another regular criticism of SystemD comes from the fact it's mainly a Red Hat project, or at least was started by Red Hat. The fact remains that while systemD was started at Red Hat, it IS an open source project, and it is receiving contributions from a lot of people that aren't at Red hat.

Another criticism of SystemD is that it's making Linux based systems uniform and that it restricts choice. I'd argue this isn't really true, since there ARE other alternatives, like OpenRC, Dinit, SysVInit and more.

One final problem people identify with SystemD is system security. First, there's the fact that having one single system that powers the init and service management of most distros is a security risk: an attacker can target many, many systems by targeting systemD.

Second, some people would say that since SystemD is huge and does a lot of things, it has a very large attack surface.

But why would you WANT to use it, exactly?

SystemD is a unified project, which means you don't have to learn 20 different programs if you need to interact with something: you learn how systemD works, and you can manage everything.

Compared to other init systems, it's also simpler, as it opens various sockets that services can plug into, and services can start in mostly any order. And finally, systemD is written in C, and isn't the usual compilation of bash scripts, so it tends to be faster and more efficient than many other init systems.

свернуть