SysVinit 3.11 Released With An "Important Feature" At Long Last

[Raka555]

or perhaps an asteroid that will wipe out all "sysv init /compile everything from source / don't use graphical tools only command line" dinosaurs?

No, the asteroid is not necessary. You will die out slowly and in the process you will make a lot of noise but still remain irrelevant.

Why don't you recompile kernel once more with few more flags, it will calm you down

I am not making noise, I am writing code... But you are probably right in that it will still be futile.

[skeevy420]

I don't think one can simplify it to that level.

While "desktop" might work as a category, the other two are too much of a spectrum themselves.

Embedded, for example, covers a really wide range of devices.

On one hand it might be unnecessary overhead for devices with restricted resource, on the other hand, once you are in the area of having GUI and user configurability, it becomes really nice to have access to the systemd ecosystem.

It makes application development much easier of you can access system features through D-Bus, e.g. talking to timedated when the user changes the device time.

Desktop is but one part of the Graphical Spectrum. There are many, many combinations of things like form factors, input methods, graphical toolkits, rendering and compositing (2D/3D/X11/Wayland), desktop environments, and more that make up the Graphical Spectrum of Linux. It's not like the spectrums are isolated, either. There are Embedded Desktops, Graphical Servers, Graphical Cluster/HPC monitoring, and all sorts of wacky combinations people use to fulfill their needs.

How does that relate to the init system? Well, the more capabilities that the graphical environment is expected to be able to do, the more features the init system has to have to be able to cover more and more potential roles the system might be used for. The more fixed of a role the hardware and software is being used for, the less features and abilities the init system actually needs. An embedded graphical with one display and the one way of doing things doesn't necessarily need the full features of systemd like a generic graphical desktop or workstation might. Even the desktops and workstations don't need the full features of systemd once configured into a fixed-function role, but if they want to get reconfigured into a new role then being able to easily "systemctl start/stop some_stuff" is damn handy. If the role will never change, does it need all of that?

IMHO, I think systemd needs to figure out how to strip itself down to what the operating environment actually needs once the system is configured into its role; graphical or not is rather irrelevant to the overall problem. Not only would that help with the system using excessive space, the system wouldn't contain unnecessary and potentially exploitable functionality should someone obtain root.

The problem with that "solution" is that it assumes we're using the minimal amount of storage which begs the question, "Does Embedded have to have the same limitations in the 2020s as it did in the 1990s or the 1960s?" This is an era where we can store TBs of storage in less space than a dime. In this day and age, at what point does using minimalist storage become a problem caused by chintzy capitalism leading to bad product designs and not updating inefficient hardware because it still works?

What's the real solution? Adapting a one-size-fits-all software solution to work in more places, software using less, or adapting hardware to better align with the one-size-fits-all software, hardware coming with more? Or is it something different like keeping on with the status quo where we use the distribution that makes the most sense for our needs even if that goes against using common standards and practices?

Does Yann Collet need to develop LZ5?

[TheMightyBuzzard]

This is pointless when the time honoured and far more sane solution has been to put the complicated logic in a script file and call the script file.

Truth. This isn't a feature, it's an anti-feature. Previous to this you could be absolutely assured that all logic rested in the init script rather than ever having to even check the inittab. Now that it's an option, idiots are going to use it and spread out the logic into multiple files instead of one.

[Weasel]

Oh, it’s already there since day 1.

With a million daemons running in the background?

systemd needs to be exorcised. Waste of CPU power and memory.

[mobadboy]

With a million daemons running in the background?

systemd needs to be exorcised. Waste of CPU power and memory.

🤡🤡🤡🤡🤡🤡

tell me more about how you are thoroughly unfit to run anything

[anda_skoa]

Desktop is but one part of the Graphical Spectrum. There are many, many combinations of things like form factors, input methods, graphical toolkits, rendering and compositing (2D/3D/X11/Wayland), desktop environments, and more that make up the Graphical Spectrum of Linux.

I do agree, just that "desktop" was the only simplification in the other user's post that could somewhat work.

The other two just cover way to many scenarios.

How does that relate to the init system?

The thing is with init systems other than systemd that they are just that and in certain use cases you then end up having lots of efforts to find solutions for things that the ecosystem around systemd brings for free.

Like, as I wrote before, D-Bus APIs for all kind of system functionality.

IMHO, I think systemd needs to figure out how to strip itself down to what the operating environment actually needs once the system is configured into its role

Isn't that already the case?

You can selectively build any daemon in the systemd repository right?
Don't need systemd-networkd then you don't build/package it.

[TheMightyBuzzard]

You can selectively build any daemon in the systemd repository right?
Don't need systemd-networkd then you don't build/package it.

In theory, yes. In practice, "lol fu".

Way too many cultist userspace programmers have made their code dependent on one specific init system when it has absolutely no reason to be. That should never have happened with anything except system utilities that deal directly with the systemd init system and no other. That's not systemd's fault but it absolutely is the fault of its cultists.

[andyprough]

he called for revolution against linux and I am a meme...sophisticles logic in action

He called for a revolution against bloatware/Linux. Don't really need a revolution though. There are already plenty of distros that strip out the offending bloated bits that he's revolting against. Just try something lik Hyperbola.

[skeevy420]

I do agree, just that "desktop" was the only simplification in the other user's post that could somewhat work.

The other two just cover way to many scenarios.

The thing is with init systems other than systemd that they are just that and in certain use cases you then end up having lots of efforts to find solutions for things that the ecosystem around systemd brings for free.

Like, as I wrote before, D-Bus APIs for all kind of system functionality.

I agree with your points and was also simplifying things.

Isn't that already the case?

You can selectively build any daemon in the systemd repository right?
Don't need systemd-networkd then you don't build/package it.

Yeah, if you're on Gentoo or LFS

To me, your comment highlights how the size and functionality issues that people seem to have are more related to differences in how distributions package and handle dependencies than they are necessarily inherent to systemd itself. Depending on your distribution you can run into dependency hell by not using systemd or by trying to replace programs it depends on with something else. Not every distribution is that flexible or even wants to be. I wonder how many people really have an issue with Ubuntu or Arch and not necessarily systemd?

Also, we all seem to be using init system to refer to how the system starts as well as complex service management. Depending on one's view, init system can also cover boot loaders. Like service management, boot loaders are also separate but related* to the system initializing. One is a part of systemd which helps blur the lines. Anyways, all that overlap and blurring seems to lead to a lot miscommunication for everyone.

*You know, I just can't find any more fucks to give about init systems so I'm gonna coin the new words "sebulate" and "sebulated" to use instead of the phrase "separate but related". Pronounced "seb-you-late". Like a toddler saying "celibate".

Examples of use could be "I enrolled in the sebulate courses of Calculus and Structural Engineering." "Donald Trump's mental capacity is sebulated with that of a toddler."

Y'all wanna start using those so we can get some new words added to the English language?

[andyprough]

All these things he mentioned as "bloat" are normal parts od desktop linux today.

They are mandatory parts of RedHat/Fedora and the RedHat/Fedora wannabe distros (mainly Debian, Ubuntu and openSUSE). But there's plenty of popular distros that strip out some or all of those parts or that make those parts optional, and there's endless uses for them.