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:
There are a few modern shells that do include data types and fix a number of security issues that more traditional POSIX-like shells (Bash isn't technically POSIX) suffer from.
> We do meandering sync calls[1] for 1 hour, four times a week. Plus a weekly demo call.
Whatever works for your team and company, but this sounds excruciatingly inefficient and disruptive. This means that your entire team is interrupted for at least an hour every day, to be part of a meeting that may or may not be productive.
IMO meetings should be anything but meandering. They should have a clear agenda, a strict start and end time, and everyone should be clear on what the outcome was and what was agreed.
Addressing some of the points of the article you linked:
> No one reads async stand-ups.
> If you dig into the “everything async” world you will find the teams that do it best are actually lying.
That might be your experience, but is not objectively true. In my company we use Geekbot, and while I can't speak for everyone, most people do read the async updates.
Let's keep in mind what standups are: quick meetings (15m tops; that's why they're done standing up), where the team can synchronize on work in progress, and address any blocking issues. If there are no blockers for my team members, do I really need to know what they're working on? That should be obvious from regular communication over Slack or GitHub.
So the whole concept of daily meetings, even quick ones, is not strictly necessary. Extending this to an hour daily, and repurposing it for general banter or other regular meetings, seems very unstructured and chaotic.
> Creating a daily social space for the team builds trust and compassion. We get to learn about each other’s hobbies, interests, and lives outside of work.
Ah, so you're using these meetings for social activities. Personally, I don't think knowing my coworkers on a personal level is required to have a professional and cordial relationship. Everyone is different, and I appreciate that others do need that sense of connection, but I wouldn't enjoy forced social activities. At my company we do optional one on one and group sessions specifically for banter and getting to know each other. These can be fun, but the good thing is that they're entirely optional, and are scheduled precisely for this one purpose.
In addition to this, there can be game sessions and, preferably, physical meetups that can serve to create this personal connection, but again, I don't think any of it is strictly necessary to work with someone. There are completely distributed teams that have never met in person, that have established sufficient rapport and trust between them to do great collaborative work. "Teams will always work better when they know one another" is objectively wrong.
The entire concept of forced social activities is reminiscent of large corporate environments where management thinks team building exercises are what makes teams do great work. This always felt cringy, fake and ultimately didn't result in anything. Trust is built naturally by working with someone; not by being forced to learn about their personal lives. The fact our working environments have shifted to being mostly online doesn't change that fact.
> Finally, it actually reduces meetings and interruptions for the team. When we have a team retro, we do it during the sync. Weekly, monthly, quarterly planning—it all happens during the sync.
Frankly, this sounds awful. This means that people are never sure what the purpose of the meeting is and how long it will last. Doing these daily would absolutely interrupt any activity that requires long periods of concentration, such as programming. I would much prefer to have days without any meetings at all, and have scheduled meetings for a specific purpose.
Also, you have quarterly, monthly and weekly planning meetings? That sounds overly excessive.
But again, if all this somehow works for you, then by all means, keep at it. But most of these would be deal breakers for me to work in such an environment, and you shouldn't present this advice as something that will work for all teams and companies.
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.
And if you look under the hood, you will see that it's only possible because of a bunch of ad-hoc hacks, which is exactly what my proposal was about: level the playing field and make it possible to have alternatives _without_ the ad-hoc hacks.
Not at all. I'm referring to the structure of the Alpine packaging, especially around boot scripts, that hardcodes busybox in a number of places and makes it difficult to package an alternative without workarounds - which accumulates tech debt.
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.