• Оригинал: The Biggest Myths
• Дата: 26 января 2013
• Автор: Lennart Poettering
• Переводчик: Любимов Алексей

Оглавление

С того самого момента, как systemd был предложен к включению в дистрибутивы, он стал предметом многочисленных обсуждений на форумах, конференциях и в списках рассылок. В этих дискуссиях можно часто услышать какие-то мифы о systemd, которые повторяются от раза к разу, но от этого ничуть не становятся более похожими на правду. Пришло время развенчать некоторые из этих мифов:

1. systemd монолитен

Если вы соберете систему со включением всех ключиков конфигурации, то получите 69 отдельных программ (binaries, бинарников) . Эти программы решают разные задачи и на то, чтобы их разделить, было множество причин. Например, мы думали о безопасности, когда проектировали systemd, поэтому большинство демонов выполняются с минимальными правами (в частности, посредством механизма kernel capabilities) и обеспечивают выполнение только за конкретных узких задач с тем, чтобы минимизировать необходимые права безопасности и сферу своего воздействия. а еще systemd распараллеливет процесс загрузки куда лучше, чем любое из предыдущих решений. Такое рапараллеливание достигнуто за счет того, что больше процессов запускаются параллельно. Таким образом, systemd изначально предполагает дробление на множество программ и их отдельное выполнение. Фактически, многие и этих программ так здорово были выделены, что теперь используются и за пределами systemd.

Вообще, систему, состоящую из 69 отдельных программ довольно трудно назвать монолитной. Но что на самом деле отличает ее от предыдущих решений, так это то, что теперь мы предлагаем больше компонент в одном архиве и поддерживаем все это в апстриме в одном репозитарии в рамках единого цикла разработки.

2. systemd нацелен только на повышение скорости.

Да, systemd быстр (Кто еще предложит полную загрузка юзерспейса за 900ms?), но это в основном побочный эффект от того, что все сделано правильно. На деле мы ни разу целенаправленно не садились и не выжимали последние проценты быстродействия systemd. Напротив, мы часто сознательно выбирали несколько более медленные варианты кода с тем, чтобы сохранить его в целом более понятным. Это не значит, что нам плевать на скорость, но некоторое снижение быстродействия systemd действительно небольшая потеря, поскольку скорость никогда и не была высшим приоритетом в списке наших целей.

3. Быстрая загрузка с помощью systemd не имеет значения на серверах.

Это вообще не так. Многие администраторы на самом деле ищут способы уменьшить простои при обслуживании windows. В установках высокой доступности это вообще важно, чтобы упавшая машина вернулась как можно быстрее. В облачных инсталляциях с большим количеством виртуальных машин или контейнеров цена медленной загрузки умножается на количество экземпляров. Потеря минут процеесорного времени или ввода-вывода за счет действительно медленной загрузки сотен виртуалок и контейнеров серьезно снижает отдачу вашей системы и выливается в затраты энергии. Медленная загрузка может дорого обойтись в финансовом плане. И затем, быстрая загрузка контейнеров позволяет реализовать такой механизм, как контейнеры, запускающиеся через сокет, что позволяет серьезно увеличить отдачу от облачной системы.

Естественно, на многих серверах загрузка сама по себе не является чем значимым, но systemd призван покрыть широкий спектр применений. И да, я полагаю, что зачастую прошивка сервера забирает на себя значительную долю времени загрузки, так что в любом случае операционная система грузится сравнительно быстро, но в самом деле systemd все равно покрывает широкий спектр применений(см выше...), и нет, не все содержат настолько плохую прошивку, и тем более этого не скажешь про виртуальные машины и контейнеры, а ведь это тоже один из видов серверов.

4 systemd не совместим с shell скриптами.

Это полная ерунда. Мы просто нге используем их в самом процессе загрузки, потому что считаем что, это не самое лучше средство для данной цели, но из этого никак не следует, что systemd не совместим с ними. Вы легко можете запускать shell-скрипты как сервисы systemd, да, вы можете исполнять скрипты, написанные на любом языке как сервисы systemd, а systemd в свою очередь абсолютно не волнует, что там внутри ваших исполняемых файлов. Более того, мы плотно используем shell-скрипты в своих собственных целях, для установки, сборки и тестирования systemd. И вы можете зафиксировать свои скрипты с самого начала процесса загрузки, использовать их для обычных сервисов, а еще можете запускать их в конце процедуры выключения, для этого практически нет никаких ограничений.

5 systemd сложен в понимании

Это тоже полная ерунда. Платформа systemd на самом деле куда проще, чем традиционные линуксы, потому что унифицирует объекты системы и их зависимости как юниты systemd. Язык описания конфигураций очень прост и такие упрощенные конфигурационные файлы легко понять. Мы предоставляем унифицированные инструменты для большинства конфигураций системы. В система получается значительно меньше намешано, нежели в традиционных линуксах. А еще у нас есть хорошая подробная документация(все ссылки есть на домашней страничке), которая не обходт вниманием практически все детали systemd, и покрывает не только интерфейсы администратов или пользователей, но и АПИ для разработчиков.

Естественно, systemd требует обучения. Все требуют. Тем не менее, мы верим, что для абсолютного большинства systemd куда проще в понимании, чем загрузка, основанная на шелле. Удивлены, что мы говорим такое? Ну так очевидно же, что Shell не слишком приятный язык для обучения, его синтаксис неочевидный и сложный. Напротив, юниты systemd куда проще для понимания, они не представляют язык программирования, но просты и естественно декларативны. все, что можно сказать по этому поводу, это то, что если у вас есть опыт программирования на шелле, то да, адаптация systemd потребует некоторого обучения.

Чтобы сделать обучение простым, мы постарались предоставить максимум совместимости с предыдущими решениями. Но этим дело не ограничилось. Во многих системах вы обнаружите, что некоторые традиционные инструменты теперь говорят вам, когда вы их запускаете в своих целях, как вы можете достигнуть такого же результата с новыми инструментами, вероятно, более удобным путем.

В любом случае, systemd стремится быть настолько простым, насколько это достижимо для такой системы и мы попытались сделать его простым для освоения. Но да, если вы знаете sysvinit, то для адаптации systemd потребуется обучение, но будем честны, если уж вы стали мастером sysvinit, то освоить systemd не станет для вас затруднением.

6. systemd не модульный.

Вообще неправда. Во вермя компиляции в вашем распоряжении есть набор ключей конфигурации, чтобы выбрать, чего же вы хотите включить в сборку, а что нет. И документ, который описывает, как вы можете выбрать искомое, куда более подробный, чем это требуется для этих целей.

Модульность не так уж далека от той, что в ядре, для которого вы можете во время компиляции задать свои отдельные настройки. Если модульность ядра для вас достаточна, то модульность systemd должна быть тоже достаточна.

7 systemd только для десктопов

Конечно, это не так. С помощью systemd мы попытались закрыть те же области, что и весь линукс в целом. Думая об использовании на десктопе, мы озабочены тем же самым и для серверного использования, также как и использовании во встраиваемых решениях. Вы можете ставить на то, что Red Hat не захочет сделать systemd ядром RHEL7 если эта система не будет лучшим решением для управления службами на серверах.

People from numerous companies work on systemd. Car manufactureres build it into cars, Red Hat uses it for a server operating system, and GNOME uses many of its interfaces for improving the desktop. You find it in toys, in space telescopes, and in wind turbines.

Most features I most recently worked on are probably relevant primarily on servers, such as container support, resource management or the security features. We cover desktop systems pretty well already, and there are number of companies doing systemd development for embedded, some even offer consulting services in it.

Myth: systemd was created as result of the NIH syndrome.

This is not true. Before we began working on systemd we were pushing for Canonical's Upstart to be widely adopted (and Fedora/RHEL used it too for a while). However, we eventually came to the conclusion that its design was inherently flawed at its core (at least in our eyes: most fundamentally, it leaves dependency management to the admin/developer, instead of solving this hard problem in code), and if something's wrong in the core you better replace it, rather than fix it. This was hardly the only reason though, other things that came into play, such as the licensing/contribution agreement mess around it. NIH wasn't one of the reasons, though...

Myth: systemd is a freedesktop.org project.

Well, systemd is certainly hosted at fdo, but freedesktop.org is little else but a repository for code and documentation. Pretty much any coder can request a repository there and dump his stuff there (as long as it's somewhat relevant for the infrastructure of free systems). There's no cabale involved, no "standardization" scheme, no project vetting, nothing. It's just a nice, free, reliable place to have your repository. In that regard it's a bit like SourceForge, github, kernel.org, just not commercial and without over-the-top requirements, and hence a good place to keep our stuff.

So yes, we host our stuff at fdo, but the implied assumption of this myth in that there was a group of people who meet and then agree on how the future free systems look like, is entirely bogus.

Myth: systemd is not UNIX.

There's certainly some truth in that. systemd's sources do not contain a single line of code originating from original UNIX. However, we drive inspiration from UNIX, and thus there's a ton of UNIX in systemd. For example, the UNIX idea of "everything is a file" finds reflection in that in systemd all services are exposed at runtime in a kernel file system, the cgroupfs. Then, one of the original features of UNIX was multi-seat support, based on built-in terminal support. Text terminals are hardly the state of the art how you interface with your computer these days however. With systemd we brought native multi-seat support back, but this time with full support for today's hardware, covering graphics, mice, audio, webcams and more, and all that fully automatic, hotplug-capable and without configuration. In fact the design of systemd as a suite of integrated tools that each have their individual purposes but when used together are more than just the sum of the parts, that's pretty much at the core of UNIX philosophy. Then, the way our project is handled (i.e. maintaining much of the core OS in a single git repository) is much closer to the BSD model (which is a true UNIX, unlike Linux) of doing things (where most of the core OS is kept in a single CVS/SVN repository) than things on Linux ever where.

Ultimately, UNIX is something different for everybody. For us systemd maintainers it is something we drive inspiration from. For others it is a religion, and much like the other world religions there are different readings and understandings of it. Some define UNIX based on specific pieces of code heritage, others see it just as a set of ideas, others as a set of commands or APIs, and even others as a definition of behaviours. Of course, it is impossible to ever make all these people happy.

Ultimately the question whether something is UNIX or not matters very little. Being technically excellent is hardly exclusive to UNIX. For us, UNIX is a major influence (heck, the biggest one), but we also have other influences. Hence in some areas systemd will be very UNIXy, and in others a little bit less.

Myth: systemd is complex.

There's certainly some truth in that. Modern computers are complex beasts, and the OS running on it will hence have to be complex too. However, systemd is certainly not more complex than prior implementations of the same components. Much rather, it's simpler, and has less redundancy (see above). Moreover, building a simple OS based on systemd will involve much fewer packages than a traditional Linux did. Fewer packages makes it easier to build your system, gets rid of interdependencies and of much of the different behaviour of every component involved.

Myth: systemd is bloated.

Well, bloated certainly has many different definitions. But in most definitions systemd is probably the opposite of bloat. Since systemd components share a common code base, they tend to share much more code for common code paths. Here's an example: in a traditional Linux setup, sysvinit, start-stop-daemon, inetd, cron, dbus, all implemented a scheme to execute processes with various configuration options in a certain, hopefully clean environment. On systemd the code paths for all of this, for the configuration parsing, as well as the actual execution is shared. This means less code, less place for mistakes, less memory and cache pressure, and is thus a very good thing. And as a side-effect you actually get a ton more functionality for it...

As mentioned above, systemd is also pretty modular. You can choose at build time which components you need, and which you don't need. People can hence specifically choose the level of "bloat" they want.

When you build systemd, it only requires three dependencies: glibc, libcap and dbus. That's it. It can make use of more dependencies, but these are entirely optional.

So, yeah, whichever way you look at it, it's really not bloated.

Myth: systemd being Linux-only is not nice to the BSDs.

Completely wrong. The BSD folks are pretty much uninterested in systemd. If systemd was portable, this would change nothing, they still wouldn't adopt it. And the same is true for the other Unixes in the world. Solaris has SMF, BSD has their own "rc" system, and they always maintained it separately from Linux. The init system is very close to the core of the entire OS. And these other operating systems hence define themselves among other things by their core userspace. The assumption that they'd adopt our core userspace if we just made it portable, is completely without any foundation.

Myth: systemd being Linux-only makes it impossible for Debian to adopt it as default.

Debian supports non-Linux kernels in their distribution. systemd won't run on those. Is that a problem though, and should that hinder them to adopt system as default? Not really. The folks who ported Debian to these other kernels were willing to invest time in a massive porting effort, they set up test and build system, and patched and built numerous packages for their goal. The maintainance of both a systemd unit file and a classic init script for the packaged services is a negligable amount of work compared to that, especially since those scripts tend to already exist.

Myth: systemd could be ported to other kernels if its maintainers just wanted to.

That is simply not true. Porting systemd to other kernel is not feasible. We just use too many Linux-specific interfaces. For a few one might find replacements on other kernels, some features one might want to turn off, but for most this is nor really possible. Here's a small, very incomprehensive list: cgroups, fanotify, umount2(), /proc/self/mountinfo (including notification), /dev/swaps (same), udev, netlink, the structure of /sys, /proc/$PID/comm, /proc/$PID/cmdline, /proc/$PID/loginuid, /proc/$PID/stat, /proc/$PID/session, /proc/$PID/exe, /proc/$PID/fd, tmpfs, devtmpfs, capabilities, namespaces of all kinds, various prctl()s, numerous ioctls, the mount() system call and its semantics, selinux, audit, inotify, statfs, O_DIRECTORY, O_NOATIME, /proc/$PID/root, waitid(), SCM_CREDENTIALS, SCM_RIGHTS, mkostemp(), /dev/input, ...

And no, if you look at this list and pick out the few where you can think of obvious counterparts on other kernels, then think again, and look at the others you didn't pick, and the complexity of replacing them.

Myth: systemd is not portable for no reason.

Non-sense! We use the Linux-specific functionality because we need it to implement what we want. Linux has so many features that UNIX/POSIX didn't have, and we want to empower the user with them. These features are incredibly useful, but only if they are actually exposed in a friendly way to the user, and that's what we do with systemd.

Myth: systemd uses binary configuration files.

No idea who came up with this crazy myth, but it's absolutely not true. systemd is configured pretty much exclusively via simple text files. A few settings you can also alter with the kernel command line and via environment variables. There's nothing binary in its configuration (not even XML). Just plain, simple, easy-to-read text files.

Myth: systemd is a feature creep.

Well, systemd certainly covers more ground that it used to. It's not just an init system anymore, but the basic userspace building block to build an OS from, but we carefully make sure to keep most of the features optional. You can turn a lot off at compile time, and even more at runtime. Thus you can choose freely how much feature creeping you want.

Myth: systemd forces you to do something.

systemd is not the mafia. It's Free Software, you can do with it whatever you want, and that includes not using it. That's pretty much the opposite of "forcing".

Myth: systemd makes it impossible to run syslog.

Not true, we carefully made sure when we introduced the journal that all data is also passed on to any syslog daemon running. In fact, if something changed, then only that syslog gets more complete data now than it got before, since we now cover early boot stuff as well as STDOUT/STDERR of any system service.

Myth: systemd is incompatible.

We try very hard to provide the best possible compatibility with sysvinit. In fact, the vast majority of init scripts should work just fine on systemd, unmodified. However, there actually are indeed a few incompatibilities, but we try to document these and explain what to do about them. Ultimately every system that is not actually sysvinit itself will have a certain amount of incompatibilities with it since it will not share the exect same code paths.

It is our goal to ensure that differences between the various distributions are kept at a minimum. That means unit files usually work just fine on a different distribution than you wrote it on, which is a big improvement over classic init scripts which are very hard to write in a way that they run on multiple Linux distributions, due to numerous incompatibilities between them.

Myth: systemd is not scriptable, because of its D-Bus use.

Not true. Pretty much every single D-Bus interface systemd provides is also available in a command line tool, for example in systemctl, loginctl, timedatectl, hostnamectl, localectl and suchlike. You can easily call these tools from shell scripts, they open up pretty much the entire API from the command line with easy-to-use commands.

That said, D-Bus actually has bindings for almost any scripting language this world knows. Even from the shell you can invoke arbitrary D-Bus methods with dbus-send or gdbus. If anything, this improves scriptability due to the good support of D-Bus in the various scripting languages.

Myth: systemd requires you to use some arcane configuration tools instead of allowing you to edit your configuration files directly.

Not true at all. We offer some configuration tools, and using them gets you a bit of additional functionality (for example, command line completion for all settings!), but there's no need at all to use them. You can always edit the files in question directly if you wish, and that's fully supported. Of course sometimes you need to explicitly reload configuration of some daemon after editing the configuration, but that's pretty much true for most UNIX services.

Myth: systemd is unstable and buggy.

Certainly not according to our data. We have been monitoring the Fedora bug tracker (and some others) closely for a long long time. The number of bugs is very low for such a central component of the OS, especially if you discount the numerous RFE bugs we track for the project. We are pretty good in keeping systemd out of the list of blocker bugs of the distribution. We have a relatively fast development cycle with mostly incremental changes to keep quality and stability high.

Myth: systemd is not debuggable.

False. Some people try to imply that the shell was a good debugger. Well, it isn't really. In systemd we provide you with actual debugging features instead. For example: interactive debugging, verbose tracing, the ability to mask any component during boot, and more. Also, we provide documentation for it.

It's certainly well debuggable, we needed that for our own development work, after all. But we'll grant you one thing: it uses different debugging tools, we believe more appropriate ones for the purpose, though.

Myth: systemd makes changes for the changes' sake.

Very much untrue. We pretty much exclusively have technical reasons for the changes we make, and we explain them in the various pieces of documentation, wiki pages, blog articles, mailing list announcements. We try hard to avoid making incompatible changes, and if we do we try to document the why and how in detail. And if you wonder about something, just ask us!

Myth: systemd is a Red-Hat-only project, is private property of some smart-ass developers, who use it to push their views to the world.

Not true. Currently, there are 16 hackers with commit powers to the systemd git tree. Of these 16 only six are employed by Red Hat. The 10 others are folks from ArchLinux, from Debian, from Intel, even from Canonical, Mandriva, Pantheon and a number of community folks with full commit rights. And they frequently commit big stuff, major changes. Then, there are 374 individuals with patches in our tree, and they too came from a number of different companies and backgrounds, and many of those have way more than one patch in the tree. The discussions about where we want to take systemd are done in the open, on our IRC channel (#systemd on freenode, you are always weclome), on our mailing list, and on public hackfests (such as our next one in Brno, you are invited). We regularly attend various conferences, to collect feedback, to explain what we are doing and why, like few others do. We maintain blogs, engage in social networks (we actually have some pretty interesting content on Google+, and our Google+ Community is pretty alive, too.), and try really hard to explain the why and the how how we do things, and to listen to feedback and figure out where the current issues are (for example, from that feedback we compiled this lists of often heard myths about systemd...).

What most systemd contributors probably share is a rough idea how a good OS should look like, and the desire to make it happen. However, by the very nature of the project being Open Source, and rooted in the community systemd is just what people want it to be, and if it's not what they want then they can drive the direction with patches and code, and if that's not feasible, then there are numerous other options to use, too, systemd is never exclusive.

One goal of systemd is to unify the dispersed Linux landscape a bit. We try to get rid of many of the more pointless differences of the various distributions in various areas of the core OS. As part of that we sometimes adopt schemes that were previously used by only one of the distributions and push it to a level where it's the default of systemd, trying to gently push everybody towards the same set of basic configuration. This is never exclusive though, distributions can continue to deviate from that if they wish, however, if they end-up using the well-supported default their work becomes much easier and they might gain a feature or two. Now, as it turns out, more frequently than not we actually adopted schemes that where Debianisms, rather than Fedoraisms/Redhatisms as best supported scheme by systemd. For example, systems running systemd now generally store their hostname in /etc/hostname, something that used to be specific to Debian and now is used across distributions.

One thing we'll grant you though, we sometimes can be smart-asses. We try to be prepared whenever we open our mouth, in order to be able to back-up with facts what we claim. That might make us appear as smart-asses.

But in general, yes, some of the more influental contributors of systemd work for Red Hat, but they are in the minority, and systemd is a healthy, open community with different interests, different backgrounds, just unified by a few rough ideas where the trip should go, a community where code and its design counts, and certainly not company affiliation.

Myth: systemd doesn't support /usr split from the root directory.

Non-sense. Since its beginnings systemd supports the --with-rootprefix= option to its configure script which allows you to tell systemd to neatly split up the stuff needed for early boot and the stuff needed for later on. All this logic is fully present and we keep it up-to-date right there in systemd's build system.

Of course, we still don't think that actually booting with /usr unavailable is a good idea, but we support this just fine in our build system. This won't fix the inherent problems of the scheme that you'll encounter all across the board, but you can't blame that on systemd, because in systemd we support this just fine.

Myth: systemd doesn't allow your to replace its components.

Not true, you can turn off and replace pretty much any part of systemd, with very few exceptions. And those exceptions (such as journald) generally allow you to run an alternative side by side to it, while cooperating nicely with it.

Myth: systemd's use of D-Bus instead of sockets makes it intransparent.

This claim is already contradictory in itself: D-Bus uses sockets as transport, too. Hence whenever D-Bus is used to send something around, a socket is used for that too. D-Bus is mostly a standardized serialization of messages to send over these sockets. If anything this makes it more transparent, since this serialization is well documented, understood and there are numerous tracing tools and language bindings for it. This is very much unlike the usual homegrown protocols the various classic UNIX daemons use to communicate locally.

Hmm, did I write I just wanted to debunk a "few" myths? Maybe these were more than just a few... Anyway, I hope I managed to clear up a couple of misconceptions. Thanks for your time.