Not a "bloated, monolithic system"?

Posted Jan 29, 2019 15:52 UTC (Tue) by drag (guest, #31333)
In reply to: Not a "bloated, monolithic system"? by tchernobog
Parent article: Systemd as tragedy

> Why should anyone?

At the level of the OS stack that systemd sits at the primary concern should probably be "correctness of code". Following closely with that is probably "usable system administrators" and then following a more distant third: "scalability". By "correctness of code" I mean that it behaves in the most predictable and bug free manner as possible. "System administrators" include the owner of a single user desktop as well as people who must manage systems at scale. "Scalability" means to work well on both at the smallest scale and a very large scale which covers more issues then just resource utilization (although that is certainly part of it).

Code bloat is diametrically opposed to "correctness of code". The more code you have the more bugs you have. The more bugs you have the more likely are you to run into the subset of bugs that cause security concerns or other highly disruptive problems.

So whether or not the systemd daemon's 'binary bloat' is actually a problem is highly dependent on whether or not that code is actually really necessary. It could be that a binary that large is simply required to get done what systemd sets out to do and in that case it's not really a problem at all. It could also be that they have gotten sloppy in a effort to add features. One can only know 'the level of correctness', unfortunately, by being very familiar with the code itself.

Not a "bloated, monolithic system"?

Posted Jan 29, 2019 19:18 UTC (Tue) by zdzichu (subscriber, #17118) [Link] (2 responses)

Systemd binary size is not directly related to code bloat. Big chunk of systemd binary size is made of strings – messages, textual representation of enums and more good stuff making debugging and daily operation easier.

Anyone for sure prefers “Failed to set up unit's logging directory.” instead of errno=240 ?

Not a "bloated, monolithic system"?

Posted Jan 29, 2019 20:20 UTC (Tue) by zblaxell (subscriber, #26385) [Link] (1 responses)

> Systemd binary size is not directly related to code bloat.

Indeed, a size comparison that doesn't use the output of 'size' or 'objdump' is mostly meaningless. Buried in megabytes of executable are kilobytes of code.

Not a "bloated, monolithic system"?

Posted Jan 29, 2019 21:42 UTC (Tue) by mathstuf (subscriber, #69389) [Link]

Here's the output from bloaty:

% ./bloaty -d segments =init
     VM SIZE                     FILE SIZE
 --------------               --------------
  48.9%   724Ki LOAD [RX]       724Ki  45.2%
  33.9%   502Ki LOAD [R]        502Ki  31.4%
  17.1%   253Ki LOAD [RW]       253Ki  15.8%
   0.0%       0 [Unmapped]      119Ki   7.5%
   0.0%       0 [ELF Headers]  1.94Ki   0.1%
 100.0%  1.45Mi TOTAL          1.56Mi 100.0%

So we have half of it is code, a third is static data, and another fifth for globals(?). For per-section:

     VM SIZE                             FILE SIZE
 --------------                       --------------
  46.7%   691Ki .text                   691Ki  43.2%
  16.5%   243Ki .data.rel.ro            243Ki  15.2%
  14.0%   206Ki .rodata                 206Ki  12.9%
   0.0%       0 .gnu.build.attributes   110Ki   6.9%
   6.9%   102Ki .rela.dyn               102Ki   6.4%
   5.9%  87.9Ki .eh_frame              87.9Ki   5.5%
   1.8%  26.1Ki .dynsym                26.1Ki   1.6%
   1.6%  24.3Ki .rela.plt              24.3Ki   1.5%
   1.3%  19.6Ki .dynstr                19.6Ki   1.2%
   1.2%  17.6Ki .gcc_except_table      17.6Ki   1.1%
   1.1%  16.2Ki .plt                   16.2Ki   1.0%
   1.1%  16.2Ki .plt.sec               16.2Ki   1.0%
   0.9%  13.7Ki .eh_frame_hdr          13.7Ki   0.9%
   0.0%       0 [Unmapped]             8.57Ki   0.5%
   0.6%  8.50Ki .got                   8.50Ki   0.5%
   0.0%     736 [ELF Headers]          2.66Ki   0.2%
   0.1%  2.17Ki .gnu.version           2.17Ki   0.1%
   0.0%     727 [15 Others]            1.05Ki   0.1%
   0.0%     672 .dynamic                  672   0.0%
   0.0%     496 .gnu.version_r            496   0.0%
   0.0%     416 .bss                        0   0.0%
 100.0%  1.45Mi TOTAL                  1.56Mi 100.0%

Not a "bloated, monolithic system"?

Posted Jan 29, 2019 22:13 UTC (Tue) by HenrikH (subscriber, #31152) [Link]

I would say that correctness of code should be 100% much more emphasized on the software that listens to and connects to external network traffic like http-, ftp-, dns-, smtp- servers/clients and so on.

Not a "bloated, monolithic system"?

Posted Jan 30, 2019 15:27 UTC (Wed) by MarcB (guest, #101804) [Link] (1 responses)

> Code bloat is diametrically opposed to "correctness of code". The more code you have the more bugs you have. The more bugs you have the more likely are you to run > into the subset of bugs that cause security concerns or other highly disruptive problems.

But so does faulty layering and a lack of code reuse.

SysV init does not cover functionality that is essential for every init system, so there are countless reimplementations of this functionality; usually in shell script. Most of them with severe bugs.

The prime example is process management. There is at least one implementation per distribution - usually that one is mostly OK, since it had a decade or more to mature. But then there are countless implementations by upstream developers and those often are a nightmare (they were usually written as an afterthought by developers who had no experience whatsoever in that area).
It gets even worse once you look at typical "inhouse" development. I have seen things called "init scripts", written by - otherwise capable - Java developers, that I wish I could unsee. Those creations have caused real damage.
Also, those scripts are rarely portable to other shells or non-GNU userspaces. Worst case, they won't even fail noisily but simply no longer work correctly in specific circumstances.

Systemd's larger core functionality and declarative syntax are a huge improvement. Things that should have been easy from the very beginning finally are.

Not a "bloated, monolithic system"?

Posted Jan 31, 2019 19:04 UTC (Thu) by drag (guest, #31333) [Link]

Sure. You can't correctly judge a single component without first examining the whole.

Not a "bloated, monolithic system"?

Posted Feb 1, 2019 19:12 UTC (Fri) by mebrown (subscriber, #7960) [Link]

Embedded guy checking in: systemd works great for us. You can compile out most of the stuff that you dont need, and the other stuff is binaries you can just avoid installing. It's resolved a lot of issues for us and enabled new functionality that we never could do before.