It's time to move...

[edbarx]

As you can see in my simplified explanation, systemd reduces GNU/Linux's level of modularity.

Is it worth avoiding for that reason?

Avoiding systemd definitely comes with its payload of hassles. It is you who should decide whether you want to value modularity or not. Modules can be swapped at will thereby increasing flexibility.

Would you run something like Devuan?

I have been running it since August last year. I also wrote a network manager for them.

[Danielsan]

To Danielsan:
Did you install a non-systemd based OS as you said you were going to do?

Not yet for lacking of time, I have to finish some tasks before reinstalling everything again but my plans are to install TruesOS or Antix on the old laptop and installing ManjaroORC to the new one but I have to wait for the 16.09 version.

[oswaldkelso]

For background only:
sysvinit / Upstart / systemd : Why systemd ?
http://0pointer.de/blog/projects/why.html

For balance only:
http://suckless.org/sucks/systemd

[L_V]

Difficult to have an opinion without being an expert: https://muchweb.me/systemd-nsa-attempt

Systemd is dangerous. It's too big to be audited as quickly as its developed.
It's complexity adds as much attack surface to a Linux system as the kernel itself. We can't get away from these facts.
Shitfighting about init systems is a waste of our time.
Sytemd is horrible because of where it comes from and how complex it is.
Backdoors will be hidden in it.

[Danielsan]

Indisputably systemd is in someways easy to learn and to manage, is perfect if you want move win-sysadmins on working in Linux containers deployment even if they've never seen a real penguin in their life.

[tomazzi]

Indisputably systemd is in someways easy to learn and to manage, is perfect if you want move win-sysadmins on working in Linux containers deployment even if they've never seen a real penguin in their life.

There's nothing special in systemd - it's not causing faster boot or faster shutdown - the only *real*
benefit is that dumb morons, who are unable to understand sysvinit template scripts are now able to understand few simple keywords (monkeys?) - at the cost of significantly lower invulnerabilty to malicious software...

But indeed, You are right - win sys admins are experienced people, so they can be re-used...

[Chiefahol2]

Difficult to have an opinion without being an expert: https://muchweb.me/systemd-nsa-attempt

This is why i need a time machine, i could travel ~20 years into the future to a time after systemd has been widely audited and report back on whether it was a conspiracy or not.

[Danielsan]

@ tomazzi

I don't want blame Win IT technicians because some schools or universities were been impermeable to *nix for a lot of time, especially outside of the US. The point is with systemd you will never have the necessity to learn how works or worked Linux because you can handle everything through it, so in the future will exist lazy or busy people which are going to administrate Linux without even knowing it.

[golinux]

. . . so in the future will exist lazy or busy people which are going to administrate Linux without even knowing it.

Which translates to administrating poorly and insecurely. And just what will they do when point and clicky fails them! tomazzi nailed it . . . dumb moron monkeys . . .

[ruffwoof]

In short this is what GNU/Linux used to be:
a) Monolithic kernel
b) Modular OS initialiser
c) Modular libraries
d) Modular user software

With systemd:
a) Monolithic kernel
b) Monolithic init (systemd) overlapping libraries
c) Modular/Monolithic libraries
d) Modular/Monolithic user software

As you can see in my simplified explanation, systemd reduces GNU/Linux's level of modularity.

By your interpretation ... not explanation

You can still extract initrd.img using gunzip and cpio extraction as before ... all looks much the same as before as well. You can write modules (scripts) to drop in, specifying whether its dependent upon a prior module/script or not (when it should run).

I see it as just a more structured/modular approach. With greater tendency to adopt others modules rather than changing code to suit your own needs, that might have been changed by others in a similar/same manner over and over again.

[Head_on_a_Stick]

b) Monolithic init (systemd) overlapping libraries
c) Modular/Monolithic libraries
d) Modular/Monolithic user software

As you can see in my simplified explanation, systemd reduces GNU/Linux's level of modularity.

I would disagree strongly with your characterisation of systemd as non-modular.

In my Arch machine, I *choose* to employ systemd-boot & systemd-networkd but I am not *forced* to use these -- GRUB & NetworkManager (and many others) are also supported and work just fine.

The same is true for almost all of the systemd-supplied tools -- alternatives can be used, if desired.

Any forum users interested in actual arguments rather than disingenuous FUD should take a moment to read this rebuttal against the "monolithic" claims that are made by the tentacle crowd:

Myth: systemd is monolithic.

If you build systemd with all configuration options enabled you will build 69 individual binaries. These binaries all serve different tasks, and are neatly separated for a number of reasons. For example, we designed systemd with security in mind, hence most daemons run at minimal privileges (using kernel capabilities, for example) and are responsible for very specific tasks only, to minimize their security surface and impact. Also, systemd parallelizes the boot more than any prior solution. This parallization happens by running more processes in parallel. Thus it is essential that systemd is nicely split up into many binaries and thus processes. In fact, many of these binaries are separated out so nicely, that they are very useful outside of systemd, too.

A package involving 69 individual binaries can hardly be called monolithic. What is different from prior solutions however, is that we ship more components in a single tarball, and maintain them upstream in a single repository with a unified release cycle.

And this is in answer to the claims of non-modularity:

Myth: systemd is not modular.

Not true at all. At compile time you have a number of configure switches to select what you want to build, and what not. And we document how you can select in even more detail what you need, going beyond our configure switches.

This modularity is not totally unlike the one of the Linux kernel, where you can select many features individually at compile time. If the kernel is modular enough for you then systemd should be pretty close, too.

http://0pointer.de/blog/projects/the-biggest-myths.html

[edbarx]

Shall we stop here. We agree to value diverging software development paths. I am all for modularity, others may "choose" business pressures from without.

[bdtc1]

Aside from the high-level goals, personalities, and technical decisions involved, there is also the question of whether systemd is bug-free and stable enough to be in Debian Stable. As of Jessie, there were still a large number of "Fix Me" comments in the code, some of which seemed to be quite serious.

[Lou]

To each his own, I like Devuan, and what it stands for... No problems so far with Beta Stable.

[Danielsan]

After reading again the Devuan website I eventually decided to install Devuan Stable on my old laptop, at last is Debian detoxed by systemd. I will perform a fresh install but I can leave my home unchanged.

[tomazzi]

Aside from the high-level goals, personalities, and technical decisions involved, there is also the question of whether systemd is bug-free and stable enough to be in Debian Stable. As of Jessie, there were still a large number of "Fix Me" comments in the code, some of which seemed to be quite serious.

Exactly - but this rises a question (again) what was the reason to adopt it for a stable distribution? (besides strictly political reasons - what brings another questions, like who's interests are represented by the Debian Technical Committee...)

I would disagree strongly with your characterisation of systemd as non-modular.
...
http://0pointer.de/blog/projects/the-biggest-myths.html

In that sense Linux kernel is also *not* monolithic - it's fully modular, thanks to DKMS and boot-time parametrization, but also because it can be compiled in thousands of configurations (what was used as an argument for systemd "modularity" ... )

Regards.

[Danielsan]

One computer detoxed by devuan. Everything is working fine, the computer is faster to boot than systemd.

Code: Select all

lsb_release -d
Description:	Devuan GNU/Linux 1.0 (jessie)

Cool!

[anticapitalista]

To those using Devuan.

In testing or sid equivalents, how up to date are the repos compared to those in Debian? eg cups

[bdtc1]

A general comparison between AntiX and Devuan would be interesting.

Based on what I've seen of it so far, AntiX seems to be aiming for light/middle-weight with some customizations, but still mainly connected to the Debian base.

Devuan seems to be aiming for a more complete separation from Debian in the long run.

-----

I was with Debian from the Corel Linux / Debian Slink days. Woody was the only time I did a fresh install; everything since then has been dist-upgrades in-place. This resulted in a lot of little bits and pieces left over through the years, but it mostly worked fine.

Now I have AntiX on a second drive, and it looks like it'll become the main system soon.

[robert-e]

I have been following the Devuan fork for close to a couple of years, and rather than a complete move away from debian, it only forks those components that have been subsumed into the systemd mechanism. As I understand, only about 1 % of debian's software have been forked into Devuan. I cannot see a complete move away from debian, since debian is a huge distribution, and it would take an enormous number of people to accomplish that in a reasonable amount of time. It might be worth to note, that I do not see much antithapy towards debian, but rather a lot of disgust towards the systemd developers. Also, I do believe that the devuan developers intend to contribute back into the debian pool, as much as will be allowed.

Indeed, many hope that debian will "see the light" sooner than later, and that systemd will be relegated to the bin, and that debian will become as great as it used to be.

Regards,
Bob