Systemd 240 Released To End 2018 On A High Note

What exactly did it do to your system. Or are you just making this up.

Writing a SystemD unit, and making it work properly is so easy. The older systems were a HUGE mess, and a pain to write for. The init scripts were also constantly being patched to fix issues (whereas its less of an issue with SystemD).

Don't forget, lots of projects get forked (Xfree86 for instance), and libraries like Glide was obsoleted by OpenGL. At the time, many people saw reasons to complain, but these days, people see why it happened. You'd be insane to go back..

At the moment this is the situation. Do you like an "under heavy development" OS? Feel free to use it, I do not call you insane. I want a different solution, I am a simple "Linux user" (not a sysadmin), and I want to keep my data safe in the hard disks. That's all.

[Auzy]

I'm just switching from systemd to a different init system. I already experienced an unbootable system (doing nothing) because of it. That's all.
I remember Sysvinit, I remeber how easy it was to manage, I remeber everythin, so I'm just switching over.

What exactly did it do to your system. Or are you just making this up.

Writing a SystemD unit, and making it work properly is so easy. The older systems were a HUGE mess, and a pain to write for. The init scripts were also constantly being patched to fix issues (whereas its less of an issue with SystemD).

Don't forget, lots of projects get forked (Xfree86 for instance), and libraries like Glide was obsoleted by OpenGL. At the time, many people saw reasons to complain, but these days, people see why it happened. You'd be insane to go back..

[Michael]

Zbigniew is at Red Hat? That's surprising news, since when?

https://fedoraproject.org/wiki/User:Zbyszek

[Danny3]

I hope that in the future systemd will add a easy to use and understand firewall to their existing network code.
I remember that in one of theirs conference videos Lennart or some other developer said that they would want to add a firewall that is program based, not port based.

That would be great for someone like me who doesn't want to search online which ports a program uses and then add a rule for those.
Besides, I think the program could just dynamically use another port or change the used port after an update and then the firewall rule would have no effect and the program could still use the network as if it were no firewall.
Something like this already exists on Android if you install AFWall+

https://f-droid.org/en/packages/dev.ukanth.ufirewall/

I hope to see something smart and easy like that built-in Linux too.
Maybe then distros can add a firewall section to their respective control panels.

I agree that there is a concern about too many new features making it into actual production releases, which is what I tried to refer to in my previous posts. I suggested amending the systemd development model, not going back to sysvinint or to any of the "alternatives" like openrc, runit etc..., which in fact are not alternatives at all because they don't even attempt to solve the problems that systemd wants to address.

In my case, at the moment the only solution is to use a different solution, not using an one-old-solution.
I already said all I wanted to say.

[jacob]

Are you saying that before systemd no one was able to use Linux?
I'm not against systemd, innovations are good things, but with systemd Linux is less stable than without it. Unless you think Linux should be "under development" all time, or for sysadmin only, systemd is good for you, not for me. I used to use Linux before systemd, and I used it in the exactly same way as today.
I'd like also to say this: Linux (in the meaning of Linux world) grew up very quickly until 2005/2006 (approximately), then something begun changing. It seems to me that everyone want to get something from Linux (since then), I hope it isn't the fame or money.
(I'm not a native English speaker)

Of course you could use Linux before systemd, but you used it as an old-style Unix system. By the same token you could also use computers before graphical user interfaces, or before SMP and multicore architectures were common. That doesn't mean that there is some inherent virtue in sticking to that.

Systemd is not for sysadmins only. In fact it's the contrary: systemd is all about ensuring that Linux is NOT just for sysadmins as it used to be, but instead that it can fill the role of a genuine modern desktop OS with the same kind of applications and ease of use you get on Windows or MacOS. I don't know if you have some actual data to substantiate the claim that systemd has made Linux less stable than it was before. Systemd is in "under development" all the time but that's not a problem by itself, the Linux kernel is under development all the time too. Systemd no goal to ever be "finished", its goal is to evolve perpetually based on new requirements and systems, just like the kernel does.

I agree that there is a concern about too many new features making it into actual production releases, which is what I tried to refer to in my previous posts. I suggested amending the systemd development model, not going back to sysvinint or to any of the "alternatives" like openrc, runit etc..., which in fact are not alternatives at all because they don't even attempt to solve the problems that systemd wants to address.

A proper service manager should have a number of features:

- have an API so that services, events etc. could be managed programmatically, rather than by a sysadmin writing scripts and editing config files;
- have a real process and resource tracking capability (cgroups etc.);
- support containerisation;
- allow services to depend on time events, network events, system events, user events etc.
- allow unprivileged users to install and run their own unprivileged services
- understand the notion of a user session and associate events and services with it
- ideally remain strictly declarative and avoid shell scripting totally, for security reasons (among others)
- be predictably present on user systems so that application developers can assume it and rely on it (e.g. deliberately NO "choice"), just like they can assume the semantics of system calls.

Sysvinit and OpenRC meet none of these criteria while systemd meets them all. That's not saying that systemd is perfect or ideal or optimal or whatever, but it's really the only one.

Are you saying that before systemd no one was able to use Linux?
I'm not against systemd, innovations are good things, but with systemd Linux is less stable than without it. Unless you think Linux should be "under development" all time, or for sysadmin only, systemd is good for you, not for me. I used to use Linux before systemd, and I used it in the exactly same way as today.
I'd like also to say this: Linux (in the meaning of Linux world) grew up very quickly until 2005/2006 (approximately), then something begun changing. It seems to me that everyone want to get something from Linux (since then), I hope it isn't the fame or money.
(I'm not a native English speaker)

[zdzichu]

Zbigniew is at Red Hat? That's surprising news, since when?

[jacob]

The problem with sysvinit is that it is not a service manager, and as such it will only get everything up but not supervise it's running correctly (and restart failing services).

Of course a service manager can be built on top of sysvinit, like OpenRC.

A proper service manager should have a number of features:

- have an API so that services, events etc. could be managed programmatically, rather than by a sysadmin writing scripts and editing config files;
- have a real process and resource tracking capability (cgroups etc.);
- support containerisation;
- allow services to depend on time events, network events, system events, user events etc.
- allow unprivileged users to install and run their own unprivileged services
- understand the notion of a user session and associate events and services with it
- ideally remain strictly declarative and avoid shell scripting totally, for security reasons (among others)
- be predictably present on user systems so that application developers can assume it and rely on it (e.g. deliberately NO "choice"), just like they can assume the semantics of system calls.

Sysvinit and OpenRC meet none of these criteria while systemd meets them all. That's not saying that systemd is perfect or ideal or optimal or whatever, but it's really the only one.

[tildearrow]

I'm just switching from systemd to a different init system. I already experienced an unbootable system (doing nothing) because of it. That's all.
I remember Sysvinit, I remeber how easy it was to manage, I remeber everythin, so I'm just switching over.

The problem with sysvinit is that it is not a service manager, and as such it will only get everything up but not supervise it's running correctly (and restart failing services).

Of course a service manager can be built on top of sysvinit, like OpenRC.