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’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.
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).
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
Originally Posted by uid313
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.
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