The abysmal state of GNU/Linux is exactly why I moved to OpenBSD many years back. It's small, simple and very stable.
The BSDs are definitely not for everyone, and they come with their own set of tradeoffs. However, it is safe to say that all BSDs are better today than 10 years ago. Small and steady improvements over time.
POSIX shells does indeed have many problems, including lack of data types and various security limitations. I like the point OP is making that shells should focus on being interactive, but not so scriptable.
For scripting, it's better to resort to a simpler solution that doesn't even need complexities like parsing or data types. In a Unix environment all you need is the ability to compose commands together. This is what execline is for:
As far as I understand, this initiative is primarily about reducing hardcoded dependencies on Busybox. As such, this is indeed what would enable alternative implementations to exist cleanly alongside whatever is the default.
Because yeah, trying to change Alpine's init system, mdev, or other coreutils is indeed not easy/feasible at the moment.
Looks like a very interesting piece of software. The declarative service file interface of systemd is a distinguishing feature no other supervisor supports (to my knowledge).
On a side note, I know that skarnet is working towards declarative service files as a possible interface in the next major versions of s6 and s6-rc:
>> Declarative service files. The model of unit files, where users can just write key=value lines instead of scripts, has been a resounding success for systemd — and it is also good end-user design (provided the parser correctly validates the files). And it can be done as a separate user interface layer, running on top of the more minimalistic engine.
>> As one example, we could be installing the Linux distribution of our choice on the Pinebook Pro using a standard aarch64 UEFI ISO installer, just like we do for any other laptop, if someone spent a couple of weeks upstreaming the last 6 patches to mainline Linux and put together a suitable u-Boot payload to flash on the SPI flash chip. But, instead of one working solution for everyone, we have 20+ Linux distros publishing Pine64-specific images to flash to microSD cards.
I think this is a key part of the problem and is not unique to Pine64 devices, but the ARM ecosystem as a whole.
There needs to be more funding and focus drawn towards standards compliant firmware. U-Boot is great, but it tends to lead to lots of unique distribution-specific problems as Drew points out here.
We have the SBBR and UEFI standards for ARM, but it needs to be more widely built out for consumer devices and not just servers.
Choosing fo rewrite software because of a license does not have to be "religious". There are very real reasons why license matters. Especially when it comes to GPLv3 and companies who hold patents.
This is one of the reasons why Google Android, and probably many others, are using Toybox for their userland. Because it's distributed under a BSD license.
The BSDs are definitely not for everyone, and they come with their own set of tradeoffs. However, it is safe to say that all BSDs are better today than 10 years ago. Small and steady improvements over time.