Should we plan on systemd ?

[Artim]

"One Ring to Rule them All" is what systemd looks like from us non-technical ordinary users, and "standardization" is probably seen as a good thing by uninformed non-techy types as well, confused by the sheer number of Linux distributions, desktops, package managers, and other options.

I think the choices are wonderful, and that full "standardization" would be a great loss to Linuxland. That's why I resist systemd and why I hope that if Linux does become "standardized" to that degree, that BSD will be more desktop-ready by then.

[kc1di]

I too resist systemd , though the original Idea to Update boot software was a good one It's became an invasive program that wants to control every part of the system. I too believe one of the great benefits of linux is choice. So There are other boot systems that could be adopted when system V is no longer viable. Not to mention systemd will become a security risk at some point. Jesse Smith of Distrowatch wrote a good article a few weeks back comparing the different init options.
found here https://distrowatch.com/weekly.php?issue=20240527#qa

[thomasl]

"One Ring to Rule them All" is what systemd looks like from us non-technical ordinary users, and "standardization" is probably seen as a good thing by uninformed non-techy types as well, confused by the sheer number of Linux distributions, desktops, package managers, and other options.

I think the choices are wonderful, and that full "standardization" would be a great loss to Linuxland. That's why I resist systemd and why I hope that if Linux does become "standardized" to that degree, that BSD will be more desktop-ready by then.

Well, I've always thought of myself as an informed techy guy and I think standardisation is (mostly) a good thing. No standards, no TCP/IP. No USB. No WiFi. No Linux kernel. Heck, no APIs at all: every API, whether a small web API or a huge OS API, like Win32 or indeed the Linux kernel , is an attempt at standardising access.

The problem is not standardisation. The problem is simply bad/sloppy engineering, both in the design and the implementation phases.

[oops]

...
Well, I've always thought of myself as an informed techy guy and I think standardisation is (mostly) a good thing. No standards, no TCP/IP. No USB. No WiFi. No Linux kernel. Heck, no APIs at all: every API, whether a small web API or a huge OS API, like Win32 or indeed the Linux kernel , is an attempt at standardising access.

The problem is not standardisation. The problem is simply bad/sloppy engineering, both in the design and the implementation phases.

We should not confuse protocol standardization with application standardization ... for protocols it is relevant (speaking the same language, TCP, etc...), for low-level applications it is a monopoly in the long term leading to a lack of diversity (a lack of resilience and/or simplicity). So it is also a problem of standardisation (even for the kernel).

[thomasl]

... for low-level applications it is a monopoly in the long term leading to a lack of diversity (a lack of resilience and/or simplicity)...

Eh? The Linux kernel is the best example that this is not necessarily the case. The kernel (or rather Linus) has put standardisation on a pedestal when he said "We do not break user-space". The API is fixed and any not backward-compatible change in user space is an automatic bug. And yet... I can't see any evidence of this "leading to a lack of diversity"... actually quite the opposite. Not least because IMO the more stable an API behaves the more people will be tempted to use it.

In fact, an API in itself is not much more than an (often very complex) protocol specification. One could easily (big understatement here) re-implement the kernel in 100% Rust or 100% <insert favourite language> without any user space apps seeing a change.

[DukeComposed]

We should not confuse protocol standardization with application standardization ... for protocols it is relevant (speaking the same language, TCP, etc...), for low-level applications it is a monopoly

It's not unheard of for someone to claim the tool is the standard. ISC BIND touted itself for the longest time as the de facto "reference implementation" for the DNS specification and effectively tried to steamroll people online by telling folks that whatever BIND did to implement a feature was how that feature was meant to be interpreted universally. The innumerable bugs in the designs of BIND 4 and BIND 8 that required yet another rewrite later on as BIND 9 didn't seem to change their argument.

[oops]

...
It's not unheard of for someone to claim the tool is the standard. ISC BIND touted itself for the longest time as the de facto "reference implementation" for the DNS specification and effectively tried to steamroll people online by telling folks that whatever BIND did to implement a feature was how that feature was meant to be interpreted universally. The innumerable bugs in the designs of BIND 4 and BIND 8 that required yet another rewrite later on as BIND 9 didn't seem to change their argument.

Yes, it is bluff and the Coué method... an attempt at tactical self-fulfilling phophesis. ;-)

[oops]

Eh? The Linux kernel is the best example that this is not necessarily the case. The kernel (or rather Linus) has put standardisation on a pedestal when he said "We do not break user-space"....

In this case it is not the same thing, it is its own standardization (for its own project) ... but like a kernel it is very very complicated and big in lines of code, there is no competition or diversity, it has a quasi monopoly that many want to get into to act from the inside and change or influence the course of its governance.

[MXRobo]

Yes, it is bluff and the Coué method... an attempt at tactical self-fulfilling phophesis. ;-)
[/quote]
Theological discussions are frowned upon in the forum.

[oops]

@MXRobo ... Not here theological but tactical.