Systemd 199 Has Its Own D-Bus Client Library

[phoronix]

Phoronix: Systemd 199 Has Its Own D-Bus Client Library

Lennart Poettering released systemd 199 on Tuesday and it brings with it a couple of new features...

http://www.phoronix.com/vr.php?view=MTMzNjg

[varikonniemi]

While many have bad things to say about Poettering, there is no denying the fact he is one of the most notable opensource developers currently. Not THE most notable, just one very prominent figure.

I think the work he does is valuable; systemd was severely needed, and he delivered very well.

[stqn]

I?m surprised by the automatic setting of sysctl variables? Is it the job of systemd to change default kernel settings? There must be a reason why the kernel devs didn?t make them default, right? (I have no idea what the concerned options do.)

[Rexilion]

I’m surprised by the automatic setting of sysctl variables… Is it the job of systemd to change default kernel settings? There must be a reason why the kernel devs didn’t make them default, right? (I have no idea what the concerned options do.)

I wondered that too and went to check (link!).
- 50-coredump.conf changes the core dump location of files that have segfaulted. You might consider this a change in a standard path. Systemd apparently likes to handle these?
- 50-default.conf contains several changes:
- - Restricting sysrq through a bitmask
- - Append pid to coredumps (I think it's related to 50-coredump.conf, but not sure why it's not in there)
- - Enabling the default disabled source route verification (this might give me trouble)
- - 'Do not accept source routing' not sure what this means
- - 'Enable hard and soft link protection' this seems somewhat unconventional (link!) -> this is actually a security fix to prevent a whole class of vulnerability's. However it seems to induce standard (i.e. POSIX) behaviour...

And it's not _bad_ to change sysctl value's from their default. Distributions have non-standard sysctl's since /etc/sysctl.conf is existing. So now systemd is doing it and the eyebrow's going up is kind of non logical.

[uid313]

systemd, D-Bus, kernel D-Bus?
It sounds like a big dependency chain where everything is depending on each other and nothing is replacable.
systemd seems very intrusive.

Will it be possible to run a system without systemd?
Will it be possible to replace systemd?
Will it be possible to remove systemd?

[Rexilion]

systemd, D-Bus, kernel D-Bus?
It sounds like a big dependency chain where everything is depending on each other and nothing is replacable.
systemd seems very intrusive.

Will it be possible to run a system without systemd?
Will it be possible to replace systemd?
Will it be possible to remove systemd?

Look here (link!) and here (link!).

Furthermore, a kdbus is said to benefit over the current userspace implementation (if it ever materializes). So that is not systemd dependant.

And what's wrong with dependencie's? If you want every program to bundle it's own stale pieces of software in the form of libraries, there is always Windows for you.



(sorry couldn't resist)

[Teho]

Will it be possible to run a system without systemd?
Will it be possible to replace systemd?
Will it be possible to remove systemd?

Yes, yes and yes. If you want to use dbus without systemd, you can. If you want to use kdbus without systemd then you have to implement a new systemd independent userspace for it (probably not that big of a feat).

[uid313]

And what's wrong with dependencie's? If you want every program to bundle it's own stale pieces of software in the form of libraries, there is always Windows for you.

I just fear that in the future it will be impossible to run a Linux distribution without udev, systemd, journald, PulseAudio, etc because they all co-dependent on each other.

A good system should be loosely coupled and tightly cohesive.

[Rexilion]

I just fear that in the future it will be impossible to run a Linux distribution without udev, systemd, journald, PulseAudio, etc because they all co-dependent on each other.

Boot your kernel with 'init=/bin/sh' you will see this requirement is doing just fine. Especially if your shell is a static library

A good system should be loosely coupled and tightly cohesive.

That would require more coding effort to support all the different structures of dependency's. The additional effort that would be put into this would be a waste of time IMHO. Just look at Gentoo. Yes, they have tinderboxes. But with the huge amount of different USE-flags and package masks the amount of different interdependant(!) combination go near infinity. It's just not doable.

Furthermore, my current Gentoo setup is outdated for two years. I just ran into a regression with the kernel and smartd v5.33. I reported the bug, but I would not expect them to fix it.

Point is, if you want every feasible combination of packages to be supported then you need a lot more manpower than what there is right now. One could argue that this is a waste of time.

[schmalzler]

But with the huge amount of different USE-flags and package masks the amount of different interdependant(!) combination go near infinity. It's just not doable.

Just use stable, that should give you workable compinations. If a package needs its dep with a certain feature enabled controlled by a USE-Flag portage will compain until you turn on the USE-Flag.
If there are limitations concerning compatible versions of the dependencies, that's handled, too.
And don't forget: there are many packages maintaining API (many even ABI) compatibility. If API/ABI breaks (poppler...) that will get known quite fast. Furthermore there is just a small number of packages that are needed by really much packages.
Of course there still is a quite large number of possible combinations, but managing that is far from impossible - don't forget: Gentoo users have to compile on their own, there are many "testers" for such breakage

Concerning your smartd problem: bug #, please!