The article does not specify what configuration changes are needed to get the flaw to appear or disappear.
It references a code patch, which is a completely different thing.

And from what I can tell, non-BSD systems are vulnerable too - as long as you don't use the default configuration. If you do, you probably should wait for vendor patches anyhow, and are safe while you wait...

Except increasing your salary to a competitive level.

You can call script snippets, but they are not allowed to do the same as init scripts did, including calling each other, detaching, or prompting. You're shoehorned into the limited context of systemd.

The answer is in your one word "basically". There is a word for "95% the same", and that's "different". There's another word for not dealing correctly with the 5%, and that's "broken".

When something needs to know the status, it calls the start/stop script with a "status" parameter. And for most jobs, you don't need to monitor anything. Some tasks are one-time jobs, and others are monitored from the outside.

And if there needs to be a watchdog, you use an actual watchdog. One that fits the task at hand, not one that can't handle special requirements. One that's capable of things like asking "is the master up?", and not just "am I up?". One that's capable of negotiating with neighbors on who should propagate to become a master. One that isn't interested in whether a process is present, but whether a service is present. One that allows for systems to have different runtime configurations. including dynamic changes, like ensuring services are not running, but present and configured to start when needed. Like adding/removing services without requiring a reboot.

The great thing about init scrpts is that they give you the freedom.

You got that too wrong. What matters the most to businesses are reliability and costs. Whether that is achieved through minions or hardware or licenses is irrelevant.

Automation is only good if it can be relied on. And when the unexpected happens, as it is wont to, that it can be troubleshot and repaired with a minimum of impact.
If it means a week of production downtime when things go wrong, because nobody can troubleshoot and fix what's wrong, it's not a benefit.

A good sysadmin plans for the unexpected. Not just for sunshine days, or things that can be anticipated. Sure, plan for that too, but don't rely on it. Things will go pear shaped, and that's when you need a human to be able to troubleshoot and fix things, with a minimum of impact to the customer. Who, quite frankly, doesn't give a damn about automation and other methods, but whether the product is available, and how long it will take to fix it when it isn't. Not how. That's the domain of the sysadmin.
And the experienced sysadmin says loud and clear that systemd is utter shite, that puts all the eggs in one basket, adds restrictions, and is too abstracted to troubleshoot in any meaningful way when things go wrong.
I see systems set up by other admins that have important jobs started through at, cron or even remote runners, to avoid systemd, and regain control. Even a /dev2 system that avoids systemd-udev trampling all over the place like an elephant in a china factory. I cannot blame them one bit.

Which is why the init process needs to be trivial.

Sure, shell scripts are slower, but you can easily fix any bugs you find in them, or modify them with very little risk. And they don't take down your hole system.

Boot time is a non-issue for sysadmins. When it takes more than five minutes pre-boot just to enumerate the RAID disks, whether you save 15 seconds at boot time is irrelevant. If anything, running things serially is a boon, as you avoid hidden race conditions and can step through the boot and shutdown, correcting things as they occur. With systemd, all your eggs truly are in one basket.

,

It already was considered that. Eris, the previous contender for largest dwarf planet, has not been considered a Kuiper Belt Object for a long time now, but a Scattered Disk Object.

Does Comcast provide 2 Gbps internet? Note the words "up to" - they are very significant, and changes the meaning from "you will get 2 Gbps" to "you may or may not get 2 Gbps, but never more".
30 Mbps satisfies "up to 2 Gbps".

Speaking of blobcentric databases, whatever happened to Informix? It was supposed to be the best thing since sliced bread for documents, and would render file systems obsolete, if I remember their marketing correctly...

Does MariaDB (MySQL forked by the author of MySQL) now support ACID, raw devices and live guaranteed viable backups?
If so, that's welcome news.

PostgreSQL (pgsql) has been the main alternative for a while, but in my experience, despite automatic vacuumdb and similar, busy / complex databases still need to be dumped and restored periodically, or else they become terribly sluggish over time.
For 24/7/365, pg is not always the best alternative. It may be for 24/7/90, but in my experience, it is one of the databases that require the most scheduled downtime.

Absolutely. Pretty much anything that uses IIS, for example. Uninstall the app, and ISS continues running.
Or you could (at least in the old versions - I don't know what it's like these days) install Outlook without the standard Office apps, and it would give you an option to install Excel/Word/Powerpoint viewers. Uninstall Outlook, and the documents will still open in the viewer.

To me, it seems rather clear that functionality only turned on with the user's consent should not be turned off again without again getting the user's consent.

But that's the thing - the photo uploader is not app specific. It performs a different service.

This is like uninstalling the music player and then complain that the DLNA server is still running.

I should, perhaps, have said "public big city airports". You don't see many prototype aircraft at JFK.

As for home built planes, they have to be approved before flying them. Not after the fact. A big difference.

Given that the most popular car in TX is the F-150, there are 85 mph speed limit zones, and that car dealers offer to throw in the (not "a") gun rack for free, what do you think?

But anyhow, this isn't testing the car in Texas, it's testing it in one fairly well-regulated city, atypically designed to have as many broad streets, identical size city blocks and 90 degree corners as possible. It didn't evolve like most other cities, and present fewer challenges except for traffic density. Now Houston would have been a better challenge.

None. Because we should no more allow prototype cars on public roads than we should allow prototype planes on public airports. They have to be tested to far beyond the prototype stage before being admitted. If a company isn't confident enough that it can be let loose in real world situations, it isn't ready yet.

Wake me up when they test winter driving in upper New Hampshire.

I presume that those on a H1B visa will be let go first, of course?