The future with Systemd

[edbarx]

This distrust in systemd and its 'unjustified' control over the user should be a motivator for anyone who has the ability to code to fork it. Just give it time, there will be developers who will find ways of providing an alternative if it proves to be the 'monster' many are claiming. After all, this is the spirit of having the source open and a license that permits editing and forking. The liberal license is the core of GNU/Linux, when that is changed, it will be the time when one has every reason to 'weep over the death of GNU/Linux'.

Like desktops or window managers, systemd is not straightforward to fork, that will require time, but it looks like it will occur. However, don't expect it to happen overnight.

[golinux]

Like desktops or window managers, systemd is not straightforward to fork, that will require time, but it looks like it will occur. However, don't expect it to happen overnight.

I’m still on squeeze LTS so that will be good for a while. Then I should get another year or two out of wheezy. I'm hoping that by the time wheezy goes EOL, that viable alternatives will appear and that Debian will offer them (and as a bonus reject systemd).

[edbarx]

KDE4 caused an uproar as many veteran GNU/Linux users found it unduly bloated with compulsory and useless hog-applications like nepomuk..........
GNOME also caused an uproar with its shiny new tablet-style interface. Many Gnome users abandoned it for leaner desktops or window managers...........
Now, we have systemd suffering the same fate! Again, another uproar from ripe GNU/Linux users who are afraid that the GNUdom they are accustomed to, will become Windowsdom or some other locked down proprietary OS........

However, KDE4's uproar gave birth to Trinity, Gnome bred Mate, and systemd is still pre-pubescent! But....., all signs show that systemd will develop and conceive.

That's the spirit of having a liberal license, nothing will stop forks!

[Randicus]

With KDE and Gnome there were options. They are suites of applications that run on top of the system. Systemd is a change to the heart of the system. When applications become dependent on systemd, forking the init system would be useless, unless all the applications were also forked into non-systemd-dependent versions.

[edbarx]

Randicus, do you code? I code, and from experience, I can tell you, coders can make what apparently is impossible. Think about WINE, not the drink, but the Windows Emulator. Wine provides an API under GNU/Linux for Windows programs. That means, at least tentatively, that systemd should be replaceable provided there is an interface between, say Init and the packages which require systemd. So, the upper layers would still see systemd, but the workhorse would be Init. This is also what happens in virtual machines. I have Windows 7, which doesn't like GPT on a BIOS system, installed in a virtual machine. Certainly, the minds at Microsoft did not intend to have their OS running on unsupported hardware, but yet, I can use Windows 7 installed on a GPT formatted disk not under UEFI!

Give it time, the beauty of a liberal license is that it promotes the motivation of anyone wanting to fork and to write intermediary layers to increase flexibility. The reign of GNUdom will not be annihilated as discontent urges for change, and change is possible through forks and the creation of intermediary layers.

[naednaem]

yea...something...something like a shim...yea a shim.....thats it.....we need to start work on this right away...

Do you imagine a lot of coders want to do nothing but chase a moving target, constantly trying to keep up with the additional services that systemd has started handling, becoming an expert in systemd and translating that to something another init system understands...an init system that likely isnt well maintained anymore either....really...


and uefi isn't required for GPT disks according to microsoft, so not sure what amazing feat you are accomplishing
http://msdn.microsoft.com/en-us/library ... i_required

[vbrummond]

I split posts about systemd to here, because they aren't about the EDX course.

[Randicus]

That means, at least tentatively, that systemd should be replaceable provided there is an interface between, say Init and the packages which require systemd.

Adding a layer of processes would make the system more cumbersome without providing an alternative.

[robert3242]

I do not object to or oppose systemd. I do not know enough about it to have that strong an opinion. What I've read of it leads me to believe that it likely serves its function well enough. What concerns me, regarding systemd and Debian's decision to adopt it, is that the only apparent reason for doing so is the fact that Gnome3 will no longer run on systems which do not incorporate it. After all, what does it do? It is the means by which the system boots and loads. Sysv-init does this perfectly already, and I have yet to read a single complaint about it in all the years I have run Gnu/Linux systems. Systemd does the same thing; however, it does not do so any better because it cannot since it merely does precisely the same thing in a different way.

Therefore why the change? Why would Debian or any other self-respecting distribution change something that basic, which has worked perfectly well for so long, simply because the developers of a single DE have chosen in their infinite wisdom to make its presence mandatory? To me, this seems very much a case of the tail wagging the dog, as it were. And that does concern me. If the Gnome3 developers are permitted to foist this basic a change at such a basic level on Debian and other Gnu/Linux distributions, what will they or others like them, clearly so attuned to the needs and wants of the vast majority of people who actually use Debian and other distributions, decide to foist on the community next?

[vbrummond]

I think you make good points there, robert. I know some of the goals of systemd are to work better with devices or services reacting to dynamic changes in the system. There are plenty of reasons why the new model might be better. Though in reality the change effects almost everyone and will be the cause of a lot of decisions on how to interact with systemd or to not. Also the more complicated the pid1, the better chance it might bring down a whole system with a crash.

This is probably biased but it is Lennart's write up about "why systemd". http://0pointer.de/blog/projects/why.html

Personally, I prefer sysvinit or bsd init.

[personalattack]

It is the means by which the system boots and loads. Sysv-init does this perfectly already, ... Systemd does the same thing;

Wrong.

[Randicus]

After all, what does it do? It is the means by which the system boots and loads. Sysv-init does this perfectly already, and I have yet to read a single complaint about it in all the years I have run Gnu/Linux systems. Systemd does the same thing;

No it is not the same. It combines the initialisation process with other processes. It is more than an initialisation system. Hence one of the main arguments against it is that it violates the UNIX philosophy of each process/programme doing one thing and doing it well. Modular design is replaced by an integrated design.

But like you mentioned, sysVinit has worked perfectly well for thirty years, so it must be replaced with something new and shiny, because Poettering says so.

[naednaem]

It is the means by which the system boots and loads. Sysv-init does this perfectly already, ... Systemd does the same thing;

Wrong.

So far it is....
init system, journal logging, login management, device management, temporary and volatile le management, binary format registration,
backlight save/restore, rfkill save/restore, bootchart, readahead, encrypted storage setup, EFI/GPT partition discovery, virtual machine/container registration,
minimal container management, hostname management, locale management, time management, random seed management,
sysctl variable management, console managment, . .

that is taken from poettering himself - http://0pointer.de/public/gnomeasia2014.pdf slide 67

[confuseling]

Those things aren't all done in PID 1 though, they're just done through programs which are part of the same project (I'm taking no position on whether that's desirable), with an apparently somewhat tangled and unstable set of interfaces between them. Apparently you can compile out, or just not use, a large number of them.

There is a demand from other projects for many of the things systemd's external interfaces provide - mostly logind at the moment from what I've read. There are even noises in the BSD community to that effect (though I don't know if they're representative). Once systemd's internal interfaces stabilise, people will start to reimplement or fork parts or all of it. If they don't stabilise, I wouldn't be surprised if there's a hostile fork specifically to stabilise them and untangle the design into discrete parts.

I'm guessing, in the long run, it'll leave new standardised (though perhaps sometimes Linux only) interfaces in its wake, rather than swallowing Linux whole...

[newgnudude]

I wouldn't be surprised if there's a hostile fork specifically to stabilise them and untangle the design into discrete parts.

Do you see debian as having the desire, not to mention the manpower to do this or even support and maintain something from another source?

Correct me if I am wrong but debian has not even adopted a udev replacement and only recently added openrc as a newer init replacement. Not to mention, it seems that systemd is on full steam ahead mode in debian and consequences be damned.

That being said, I sure hope you are right!

[confuseling]

I didn't mean by Debian, or in the short term.

I mean let's assume for the purpose of argument that the extreme conspiracy theory of systemd is true: it's a deliberate ploy by RedHat to take over as much plumbing as possible, tie it together in a monolithic and unavoidable project, and use it to force adoption of other technologies they favour or control.

What would they do? They either stabilise their own interfaces, in which case small forks become basically inevitable. Or they maliciously keep changing them to prevent forks, in which case everyone notices, cries foul, and systemd is abandoned - or if it's any good, a big fork becomes inevitable.

Maybe I'm an optimist, but I agree with Edbarx here; the kind of shenanigans predicted by systemd's conspiratorially minded opponents are basically impossible because of the GPL.

Too many large projects and companies are invested in Linux to watch a 'coup' happen in plain sight.

[newgnudude]

It sounds sensible when you say it...


That being said, I still do not like the what systemd is or what it does. So I guess my new stance is that systemd is not for me, neither was policykit so I guess this isnt a surprise.

*takes off conspiracy cap and puts it back on the shelf

[golinux]

systemd doesn't need a fork. It needs an exorcism!

[koanhead]

I don't have a problem with systemd in itself, at least not yet. When I've used it in the past (on non-Debian servers) it has seemed to work OK. It's annoying to have to learn a new set of interfaces to system controls, but I have to do that all the time anyway. systemd provides at least one great feature: it can give a (maybe reliable) list of currently-running services, which is non-trivial to accomplish under sysvinit.

I do have a problem with systemd as default in Debian. Since Debian is supposed to be the Universal Operating System, I think it's unfortunate to choose a new PID1 that only works with Linux, or a new default DE that only works with that particular PID1. It may be a lot of work to make, for example, OpenRC "ready for primetime", but I don't see how that work is less than that of separately maintaining systemd for Linux x86 and sysvinit for all the other Debian kernels and architectures (AFAIK systemd only works on x86 Linux, but a quick search failed to corroborate or disprove this). Naively, I would prefer OpenRC as a new default if any such change really need be made- but I'm not savvy enough yet to hack on OpenRC, nor yet any init system. No more am I really qualified to second-guess the CTTE on a technical basis.

[robert3242]

I may have just answered the concern I expressed in an earlier post in this thread. I just finished installing jessie using the d1-a1 installer into virtualbox--the base system only--and when I rebooted, the speed increase I noted during the boot process (using systemd) was not only noticeable but startling. My wheezy system boots faster than any other Linux distros I've used, and flies through the boot process compared to, say, Windows 7; but jessie left it in its dust.

Just thought I'd throw in that observation.