Systemd Continues Getting Bigger, Almost At 550k Lines Of Code

[Akka]

How do you count the lines?
When I use

find . -name '*.h' -o -name '*.c' | xargs wc -l

I get 251157 total

[Ericg]

How do you count the lines?
When I use

find . -name '*.h' -o -name '*.c' | xargs wc -l

I get 251157 total

Total blind guess... Systemd is known to have one of the best sets of documentation available. Is the documentation in the source tree? If so GitStats may be counting the documentation as part of the line-count, your command above would be limited to strictly header and source files.

[mike4]

Udev is buggy like hell! And I've heard of an author being blamed by kernel devs. for producing ugly/buggy code. Is that the same person? God beware.

[slojam]

Are you talking about the /usr/bin + /bin merge? Because I'm pretty sure that was a decision Fedora made completely unrelated to systemd.

Ok, I didn't know that. Suse did it also.

[gigaplex]

How do you count the lines?
When I use

find . -name '*.h' -o -name '*.c' | xargs wc -l

I get 251157 total

There is more to the source tree than just .h and .c files. I think there's some python in there as well, plus they might be including documentation, makefiles etc as well in the line count.

[Akka]

Total blind guess... Systemd is known to have one of the best sets of documentation available. Is the documentation in the source tree? If so GitStats may be counting the documentation as part of the line-count, your command above would be limited to strictly header and source files.

I don't find them at least. I think most of it is at freedesktop.org
But I also found around 1301 loc python.

Also Makefile.in adds more than 17k loc

[Adarion]

For me it isn't actually about technical issues at all if I should run systemd or not.
[...]
but in reality it is a trust issue, simple as that. I don't trust them, I don't use their software. Many of you argue the same way about Microsoft or Apple, I don't see why it shouldn't be valid here.

Full post seconded. That hits it exactly.

[tomegun]

How do you count the lines?
When I use

find . -name '*.h' -o -name '*.c' | xargs wc -l

I get 251157 total

Yeah, the count seems off. With sloccount I get:

C:          190958 (92.66%)
sh:           12586 (6.11%)
perl:          1751 (0.85%)
python:         792 (0.38%)

I don't question the general trend though.

[tomegun]

So let's see if I'm understanding this right. Which one of these statements describes the systemd architecture?

* systemd is a monolitic binary that includes inside a lot of services (like DHCP, dbus, and so on), but using #defines is possible to compile only some of them.

* systemd is growing with new services and more, but they still run like another process. The diference is that these services (like DHCP, dbus and so on) have been modified to integrate with systemd, and are now hosted inside the source tree of systemd, but can still be considered independent binaries.

Thanks.

The latter.

dbus is a bit different though, it is basically in three parts: what used to be the dbus daemon becomes the kdbus.ko kernel module; what used to be libdbus becomes the sd-bus library (there will also be other implementations of this available, possibly including libdbus itself); PID1 will set up the basic system bus (or rather ask the kernel to do so) on very early boot so it is always available.

All the other things are added as new services / libraries, most of which can be enabled/disabled at both compile and run time.

[tomegun]

Then why can't they spin it off into separate libraries so that they can be used with other programs rather than just with systemd and systemd alone, without having to be spun off by some other developer?

We expose, or plan to expose, a lot of libraries. Not all will necessarily be exposed by default anytime soon, but at least we are preparing for doing so, and it is only a matter of flipping a switch (just want to be relatively confident that the API is the one we want): http://cgit.freedesktop.org/systemd/...ee/src/systemd