Overturning The Distro

The systemd folks have an agenda, changing everything. While I, like many others, resist change I want to have some idea of where we are going and how we are gong to get there.“we push quite a few problems into btrfs, that other solutions try to solve in user space. One of them is actually signing/verification of images. The btrfs maintainers are working on adding this to the code base, but currently nothing exists. This functionality is essential though to come to a fully verified system where a trust chain exists all the way from the firmware to the apps. Also, to make the home sub-volume scheme fully workable we actually need encrypted sub-volumes, so that the sub-volume’s pass-phrase can be used for authenticating users in PAM.” One idea is that they will choose a single file-system, btrfs, and use some of its features/complexity to standardize the GNU/Linux file-system, versioning of software, production, distribution and installation of software. They seem to want to turn the GNU/Linux PC into something more like Android so that developers will have a standard target and more control over the run-time environment.

Ewww! This might be fine for the developers, OEMs, and perhaps distro-makers who could share their efforts more efficiently but what of the end-user? No choice of file-system? Umpteen versions of libraries in umpteen branches of the file-system? Relying on the file-system to de-dupe stuff and secure everything?

Imagine the fluff that will replace our solid, dense, reliable distros like Debian GNU/Linux. Imagine how little control the end-user will have over anything. Imagine how complex an installation will become for ordinary folks. Imagine how much expertise will be required to fiddle anything on a GNU/Linux system. Will such systems even be GNU/Linux any longer? Not likely. It’s just not UNIXy enough.

Is this better, desirable at all or necessary? I don’t see it. Is this the evolution of what AT&T and GNU started so long ago? Nope. It looks like starting over from scratch. Is this going to delay, undermine or prevent domination of the world of IT by GNU/Linux? Almost certainly. I can see this process taking a decade or longer. Look how long it took us just to get OEMs to install GNU/Linux. How long is it going to take them to install something few if any understand? Ages. I’m too old to wait for that. I’ll stick with Debian for now. Oops. I’ve just installed systemd on all my machines…

See Revisiting How We Put Together Linux Systems.

About Robert Pogson

I am a retired teacher in Canada. I taught in the subject areas where I have worked for almost forty years: maths, physics, chemistry and computers. I love hunting, fishing, picking berries and mushrooms, too.
This entry was posted in technology and tagged , , , . Bookmark the permalink.

14 Responses to Overturning The Distro

  1. oiaohm says:

    By the way a lot of people make the same mistake with sysvinit.

    PID 1 is small true. But rc that is called if that crashes so does the complete system as well. So when you join up all the code that can make the system go splat sysvinit is quite huge and its spread across multi different files.

    By the way one of the early features of systemd that is always overlooked is the fact it does not have to run as PID1 real. Systemd supports running as PID1 inside a process namespace. You will find this also mentioned in my posts before the existence of systemd. There are no Posix or Unix based init systems before that post that are designed to function that way.

    DrLoser I am working on something else at the moment. The frameworks required now in place to implement something that was in the old emails.

  2. oiaohm says:

    DrLoser if you are looking for the source document of the design systemd is following you are in fact looking for one of my emails. Yes the proposal for the init system to heavily used cgroups for security reasons is mine.

  3. oiaohm says:

    DrLoser If you are truly do go threw everything I did suggest you will find not all my suggestions did get shot down. Lennard Pottering was in those debates.

    So go ahead. Bring it on. You will find to your nightmare that a lot of the current stuff is refinements of those ideas.

  4. DrLoser says:

    Systemd has CUI, GUI and Web DrLoser.

    Spare me the nit-picking, oiaohm. Spare all of us, please.

    I never said it didn’t, you fool. I never even intimated the possibility. You just don’t bother to attempt even a rudimentary understanding of what other people write, ever, do you?

    I have said for a very long time that at some point the Distribution fragmentation would just end. The same kind of tweak systemd is doing now I proposed in linux security mailing list over 4 years ago. The structures to do it did not exist then.

    My emphasis, oiaohm.

    Do you really want me to remind people here of your asinine suggestions back then, and the several ways in which competent Linux experts shot every last one of them down?

    It’s a matter of record, oiaohm, and I can do it if you wish.

  5. oiaohm says:

    Robert Pogson when everything functions correct sysvinit is ok. Its the cases where stuff goes wrong where sysvinit is a problem and you start wishing that Linux had better process tracking.

  6. oiaohm wrote, “Every sysvinit solution from every distribution did everything differently so being a complete pain in ass for system admins..”

    That’s the same as package-management and file-system and layout. Not a big deal. Do everything with one distro. Pick one. I like Debian GNU/Linux. There is absolutely no problem dealing with Sysvinit in Debian for me. I have bunches of PCs on the LAN. Yesterday, I discovered one was still running Squeeze. I apt-get dist-upgraded it to wheezy in a few minutes and sysvinit worked perfectly stopping and starting daemons. No problem.

  7. oiaohm says:

    Robert Pogson the Linux kernel is very powerful. As you say users don’t normally use user-permissions. Problem is not every application require access to everything.

    Issue 1 disregards how complex sysvinit was. That is a no issue as such. Every sysvinit solution from every distribution did everything differently so being a complete pain in ass for system admins..

    2 issue Potentially corruptible logs claim about journald is wrong because of the reason there are a bug open about log damage is journald detected where a syslog system would not have even detected it. Using older logging solution the bug would not have been recorded as all. The old logs systems don’t record information about the process that started it.

    3 issue solaris init system is also salaris only. No issue really.

    4 issue is about lack of IPC options in posix standard.

    5 issue is in fact to prevent stolen data issues. Core dumping to a file system has resulted in multi user case of other users accessing other users data.

    6 issue there have been a huge number CVE issues that trace sysvinit as well. systemd is being attacked by attacker because breaching a cgroup contained service limits how far attacker can get into the system.

    8 issue is wrong “systemd clusters itself into PID 1” systemd has a very small control item as PID 1. In fact systemd control program at PID1 is smaller than the old init of sysvinit binary.

    9 issue is correct design selection around glibc. But sysvinit does not work with every libc either.

    10 issue not really. sysvinit still provides all the tradition service and so on of sysvinit. Why does sysvinit place up so much containment. So you don’t have the tradition sysvinit failure. Tradition sysvinit failure. Service half crashes. service [name] restart fails why parts of the prior service still running now you got to magically find what process is the problem and kill to to allow you to restart service.

    If you choose openrc instead of systemd you find the same thing your services and user are in a box. Even solaris smf is your service wrapped in zones. Conventional sysvinit system is not predictable. Conventional init system appear predictable but failures application failures are poorly managed by it.

    11 and 12 are basically the same thing. systemd is pushing the limit to make stuff work. syslog is a good example. syslog was designed on the presume that applications would tell it the truth. Journald is designed on the presume applications will attempt to lie. From a security point of view syslog never worked.

    Lets go threw the list of alternatives provided.

    runit, s6, monit, perp, supervisord, Upstart. All these suffer from the same bug as sysvinit where if a service crashes can half crash so prevent the service from being able to re restarted.

    Upstart is officially to be exterminated.

    GNU dmd and openrc uses cgroups under Linux and can in fact handle a crashed service just as well as systemd. People have resorted to reboot to get services to restart if you are using a solution without process tracking.

    BSD kernels implement a different process tracking method. BSD init systems support this. Using a third party like sysvinit on BSD systems as in fact down grading.

    “runit, s6, monit, perp, supervisord, Upstart.” This list is also fairly much worthless on a BSD kernel if you what true 100 percent dependency that a service will be restartable after a crash.

    The prime objective of systemd is to make a system as resistant as possible.

    systemd issues are fairly much its not cross platform and its not going to be easy to be cross platform. The said reality is bsd init and smf from solaris don’t port to Linux either. A properly working init system that can cope correctly with crashing services seams to be kernel dependant. Why the posix standards don’t provide the required functions to handle this problem.

    The complaints about systemd trace to the common standard between Unix like operating systems. If you stick to Posix only functions you cannot create a init system that will handle a half crashed service on every posix kernel.

  8. There’s a good write-up of the complexity of systemd at boycottsystemd.org

    I wonder if the end-point in all this is to have systemd be the new kernel. It’s doing a Hell of a lot of kernel stuff: permissions, processes, control… When systemd was just about starting processes, I liked it a lot more…

  9. oiaohm wrote, “what systemd is upto will make a more Android like desktop Linux. With each process having a set of access permissions in the control of end user.”

    The average user can barely manage file-permissions. How are they going to deal with that kind of responsibility? I suppose reasonable defaults can be set but this whole debate shows what’s reasonable to one is unreasonable to another… I can’t see this turning out well. Perhaps I will be dead before GNU/Linux has this kind of complexity added. If this happens, GNU/Linux will be just as complex as that other OS but different, raising yet another barrier to adoption. Will it even be GNU/Linux if scripting is chucked?

  10. oiaohm says:

    Robert Pogson when selinux was first introduced it was ext file systems only. But since then other file systems have grown the required features to support it. Systemd is now increasing the feature list a file system requires. Snapshots, Compression and Encryption not in the file system level has been a major headache on Linux for a while.

    Fully verified system is coming very important in the age of the NSA. NSA has tools for even patching motherboard firmwares. The thing with a Fully verified system is who controls the verification system as long as it the end user of the machine everything is ok.

    What systemd is proposing is an option to end the Linux Distribution wars. Implement a means that a person can run every distribution. Of course this is still going to be tricking with items like closed source video card drivers.

    Systemd has CUI, GUI and Web DrLoser. Yes interface issues is one of the reasons we have to leave sysvinit.

    Agent_Smith we cannot return to sysvinit its too broken. BSD init maybe. Gentoo is going openrc. Sysvinit complete dependence on scripting running without control results in huge security risks.

    Robert Pogson is right what systemd is upto will make a more Android like desktop Linux. With each process having a set of access permissions in the control of end user. Systemd is also working on bringing android like IPC ideas to Linux. Just because Android did something does not mean it bad.

    Its the history of Linux the best features end up taken up.

    I have said for a very long time that at some point the Distribution fragmentation would just end. The same kind of tweak systemd is doing now I proposed in linux security mailing list over 4 years ago. The structures to do it did not exist then.

    Road block 1 was X11 with all its required userspace to userspace interaction to operate when running applications with opengl. Wayland cures road block 1 with its mandated requirement that each application has to stand on its own two feet.

    My prior model did not require a particular file system. It used cgroup name spaces to over map /. So /ubuntu /debian …. is where the distributions installed on a file system but to the applications those locations appeared to be /.

    Wayland removes a road block to distribution unification. This is why a Lot of Linux people are looking at Wayland so closely.

  11. DrLoser says:

    (To avoid confusion, btw: by “centrally organised,” I mean “centrally organised on a single computer, or if you prefer, on a network of your own design.

    (I do not mean “centrally organised” as in “by the fiends behind the refridgerator” or “by NSA” or any such thing.)

  12. DrLoser says:

    Imagine the fluff that will replace our solid, dense, reliable distros like Debian GNU/Linux.

    Quite easy to imagine, Robert, as it happens. I imagine something that vaguely approximates a sensible, centrally-organised system where it is no longer necessary for every single daemon to understand what every single other daemon is doing, and when they are doing it.

    I can also imagine a unified control mechanism (GUI or CLI, I don’t care) that allows the user to define these relationships.

    Not exactly a Brave New World, but certainly a less crippled one.

    Imagine how little control the end-user will have over anything.

    Don’t be silly, Robert. This is still FOSS.

    You will still have the ability to “run (for any purpose), study, redistribute, improve, and release.”

    Provided you’re up to the task, of course.

  13. DrLoser says:

    You’re missing the point, I think, Robert. (Although your other random complaints might have something to them.) Here’s the nub of that cite:

    This functionality is essential though to come to a fully verified system where a trust chain exists all the way from the firmware to the apps.

    I don’t want to force you to use these vile and unacceptable words, Robert …

    … but can you say “UEFI?”

    And Digital Rights Management? And all those unspeakable other things?

    Because, make no mistake, they are coming your way. Via the sainted and unimpeachable Linux Distro mechanism.

  14. Agent_Smith says:

    Revert to sysinit. I see that many folks have problems with it, which I agree. If you need a replacement, replace it. If you don’t, don’t do it. Simple as that. But, the totalitarian folks at dead rat want us all to change, by engulfing daemons inside systemd. That’s bad, bad dead rat…

Leave a Reply