Systemd 240 Released To End 2018 On A High Note

[phoronix]

Phoronix: Systemd 240 Released To End 2018 On A High Note

Zbigniew Jędrzejewski-Szmek, part of the systemd team at Red Hat, has taken the reins from Lennart Poettering to release systemd 240 ahead of Christmas...

http://www.phoronix.com/scan.php?page=news_item&px=Systemd-240-Released

[jacob]

I wonder if systemd development should try to synchronise with the distros' release cycles, maybe Ubuntu's since it's the major distro that releases the most often?

[nanonyme]

I wonder if systemd development should try to synchronise with the distros' release cycles, maybe Ubuntu's since it's the major distro that releases the most often?

Does it release more than two times a year these days or what?

[boxie]

I wonder if systemd development should try to synchronise with the distros' release cycles, maybe Ubuntu's since it's the major distro that releases the most often?

nah, releasing often enables finding bugs faster. release often is better imho

[jacob]

nah, releasing often enables finding bugs faster. release often is better imho

I think releasing often is better in the early stages of a project. Now that systemd is mature and a core component of all the main distros, the problem with releasing often is that distro releases get versions of systemd that have many new and comparatively untested features. Targetting six monthly cycles would allow them to deliver a more polished code base for the main distro releases and still keep a relatively rapid development pace.

[Guest]

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.

[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.

[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.

[zdzichu]

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

[Guest]

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)