C# and arguably Java are among the very few platforms that make sense for bespoke line-of-business applications, which probably constitute the majority of new code being written. C# for me, because Oracle, but lots of people who are either braver, and/or more trusting than myself, choose Java instead.

It might, if much of the media throughout the rest of the country did not also lean far to the left. Unfortunately, as goes California, usually the rest of the nation soon follows.

Even leaving aside free speech rights:

We do not have bills of attainder in free societies, nor even in semi-free ones like ours (Article I, Section 9, of U.S. Constitution).

I say this even though I hate TikTok, and wish it would die horribly in a fire.

Rule of law is more important than my, or anyone else's, personal preferences.

There are many reasons why I and many others do not like, trust, nor voluntarily use systemd. These are just some.

Unfortunately, we've been mostly outvoted. All major distributions use systemd.

But the freedom of choice inherent in the Linux ecosystem means there are usually other choices. My Gentoo Linux system has bits and pieces of systemd installed, as dependencies of other projects, but does not run systemd as PID 1 (first process, responsible for managing all others). And it will stay that way for the foreseeable future.

This is an aside, but I found I could not walk into a local office supply store and buy a decent laptop bag.

Went to literally a dozen or so, only to end up with a crappy one without nearly enough pockets, compartments, etc. to truly replace the old one I had.

Brick and mortar retail is dying in large part because the online shopping experience is just better.

It's become pretty easy to build desktop PCs from parts that have been vetted in advance to verify Linux support.

The laptop story on the other hand is very much hit or miss, and you may not get the quality, features, performance, or price you'd have gotten from a vaguely comparable Windows box.

And the tablet story? Completely and totally bojanxxed. A decent GNU/Linux tablet (not Chrome, not Android) is almost impossible to find at any reasonable price.

To fully understand the problems with systemd, you need to understand some basic tenets of modern software development:

    * Single Responsibility principle: Each piece of software should do one thing well, rather than multiple things poorly.

    * Keep It Simple principle: Each piece of software should be as simple as possible, though no simpler.

    * Reuse: All functionality common to multiple pieces of software should be its own piece of software.

    * Dependency Management: All software should explicitly list the specific versions of its dependencies; all software should avoid unnecessary breakage between updates.

    * Communications: Be strict in what you send (follow agreed protocols, APIs, etc.). Be liberal in what you accept. (As long as input is unambiguous and sufficient, accept it, even if it contains information you did not expect.)

    * Use versioning, including semantic versioning where appropriate.

    * Don't gratuitously replace working and tested code without a good reason. Don't re-invent a perfect wheel to make a potentially crappy one.

    * Design and build a system in such a way that testing of each piece as well as each business requirement can be automated.

    * Security. Minimize potential attack surfaces. Use the safest languages, code, constructs, system calls, etc., possible.

OK, so these are just a few things we developers try to keep in mind at all times.

Lennart Poettering is not a dumb guy, and he has had some good ideas at times.

However, systemd disregards many of these very core principles. Often gratuitously so.

While initially sold as a replacement init system, which for sure is needed for some use cases, it has morphed to become a large and growing part of Linux user space.

The entire Internet was almost brought down a couple weeks ago because of an exploit involving, though not directly caused, by systemd.

There will be more such exploits, and systemd provides a HUGE attack surface because of its unique status as the process that starts, stops, logs, and monitors all of the others.

Nontechnical end users, and distribution maintainers, are generally OK with all of the above because of the fact that it makes many parts of their lives easier.

But software developers such as myself understand the risks, and many, including me, find them unacceptable.

I hate being pessimistic, but I'm not sure there's a fix

Probably not, in a society that values only self, and not others, and certainly not rule of natural law.

In a society in which people actually gave a shit, I'd say progress would be not only possible, but inevitable.

I believe you have confused capitalism with corporatism.

Granted, corporatism is indeed what capitalism can deform into in the absence of rule of law (which would hold decisionmakers absolutely accountable for avoidable deaths, injuries, and other losses caused by their decisions).

According to what I've read, including this, Gentoo doesn't patch its sshd to integrate with systemd, and is likely not vulnerable for multiple reasons, but to be cautious, they have masked the vulnerable versions, and recommend downgrading to 5.4.x, and I believe emerge sync + emerge -upv world will do that for you.

The CPU for most of my workloads is usually waiting for user input, network packets, or I/O. It wouldn't matter if OpenBSD were marginally slower. I'd still give it serious consideration in any sort of exposed-to-the-Intarwebs server duty.

I have great respect for Dr. Stroustrup. C++ was a really, really good thing in its time. But I think its time has come and largely gone at this point. It's simply grown too big for ordinary mortals to be able to use safely, not just for writing new code, but interacting with legacy code.

I find that a lot of Linux software is written in C or C++ for reasons I don't quite understand. Managed languages/tools seem so much more productive to me. And most toolkits such as Qt, Gtk, SDL, wxWidget, etc. have perfectly good bindings to higher-level languages. I don't really get why anyone would use a memory-unsafe and very complicated language just to be able to draw some pixels on a screen, for something like a typical LOB database front end where performance really isn't an issue.

It's possible to do the first, but only a limited number of people actually can, and, I'm not either one of them.

I'd be able to do a passable job of writing modern C++.

But working with other developers whose subset of C++ is different from mine and/or each other's? Probably not so much. Because the entire language is MUCH too bit to fit into my head.

I've inherited unsafe C#, but haven't ever needed to write any myself. I have done a very tiny bit of C, called from C#, to interface with bespoke hardware that would have been otherwise difficult to control from a non-hard-realtime OS.

Most of the rest was to wrap calls around the Win32 API, and, ironically, I found that the managed framework was quite capable of similar functionality via safe, managed code.

Also, a lot of that old code did things like using ints rather than IntPtrs, or otherwise assuming a 32 bit word size, which caused it to gradually rot over the past couple decades. So over time it's tended to be replaced anyway, and, along with it, most of the "Heisenbugs" caused by crapping all over somebody else's memory.

That is my feeling as well. C++ is useful when you need something that can be a high and a low level language at the same time. But that's pretty rare, because you can almost always use higher-level languages for the bulk of the code, and drop down to C or Rust for the spots where something close to bare-metal performance is needed (e.g., when you aren't waiting for a network packet, a piece of user input, or some spinning ferric oxide.)

I've needed to drop to C only once in my very long career, and that was because of a hardware interface that needed deterministic real-time signaling.