Language Selection

English French German Italian Portuguese Spanish

The Biggest systemd Myths

Filed under
Software

Since we first proposed systemd for inclusion in the distributions it has been frequently discussed in many forums, mailing lists and conferences. In these discussions one can often hear certain myths about systemd, that are repeated over and over again, but certainly don't gain any truth by constant repetition. Let's take the time to debunk a few of them:

1. Myth: systemd is monolithic.

If you build systemd with all configuration options enabled you will build 69 individual binaries. These binaries all serve different tasks, and are neatly separated for a number of reasons. For example, we designed systemd with security in mind, hence most daemons run at minimal privileges (using kernel capabilities, for example) and are responsible for very specific tasks only, to minimize their security surface and impact. Also, systemd parallelizes the boot more than any prior solution. This parallization happens by running more processes in parallel. Thus it is essential that systemd is nicely split up into many binaries and thus processes. In fact, many of these binaries[1] are separated out so nicely, that they are very useful outside of systemd, too.

rest here




More in Tux Machines

10 tips for easier collaboration between office suites

Yes, you are likely using the Microsoft formats for your documents. However, they don't always follow OpenDocument Format (ODF) standards. Instead of opting for the proprietary Microsoft formats, switch over to one that's welcomed by nearly all office suites: ODF. You'll find a much more seamless collaboration process and fewer gotchas when moving between office suites. The only platform that can have a bit of trouble with this format is Android. The one Android office suite that works well with ODF is OfficeSuite 7 Pro. Read more

Outsourcing your webapp maintenance to Debian

It turns out that I'm not the only one who thought about this approach, which has been named "debops". The same day that my talk was announced on the DebConf website, someone emailed me saying that he had instituted the exact same rules at his company, which operates a large Django-based web application in the US and Russia. It was pretty impressive to read about a real business coming to the same conclusions and using the same approach (i.e. system libraries, deployment packages) as Libravatar. Regardless of this though, I think there is a class of applications that are particularly well-suited for the approach we've just described. If a web application is not your full-time job and you want to minimize the amount of work required to keep it running, then it's a good investment to restrict your options and leverage the work of the Debian community to simplify your maintenance burden. The second criterion I would look at is framework maturity. Given the 2-3 year release cycle of stable distributions, this approach is more likely to work with a mature framework like Django. After all, you probably wouldn't compile Apache from source, but until recently building Node.js from source was the preferred option as it was changing so quickly. While it goes against conventional wisdom, relying on system libraries is a sustainable approach you should at least consider in your next project. After all, there is a real cost in bundling and keeping up with external dependencies. Read more

How Intel HD Graphics On Linux Compare To Open-Source AMD/NVIDIA Drivers With Steam On Linux

As earlier this week I did a 20-way AMD Radeon open-source comparison, looked at the most energy efficient Radeon GPUs for Linux gaming, and then yesterday provided a look at the fastest NVIDIA GPUs for open-source gaming with Nouveau, in this article is a culmination of all the open-source graphics tests this week while seeing how Intel Haswell HD Graphics fall into the mix against the open-source Radeon R600/RadeonSI and Nouveau NV50/NVC0 graphics drivers. Read more

Leftovers: Gaming