SubjectToChange

Somewhat unrelated, but I'm looking forward to llvm-libc becoming a practical replacement for musl. I'd love a modern, non-gnu libc implementation that isn't so dogmatic.

The reality is that systemd arrived at a time when Linux distributions were dying to move off of sysvinit. Poettering struck when the metal was hot and he delivered a comprehensive tool that greatly reduced the burden on maintainers. Sure, nothing lasts forever, but it will be many years (if not decades) before systemd is slated for replacement.

People bring it up because it's usually the first thing they notice. Of course the faster boot times are not what makes systemd great, rather it's what makes those fast boot times possible.

So it went heavily imposed almost everywhere even when a quite big chunk of the Linux community deeply disagreed about the imposition.

There is a substantial selection bias in the complaints towards systemd. At the very least it seems that Red Hat's customers didn't have a problem with it. For most Linux users, it was a minor change, but for distro maintainers it was a massive relief[1].

Again, Lennart Poettering actually took the initiative to develop systemd and get it adopted. By comparison, detractors of systemd did not develop a competitive alternative. Thus, it's hardly a surprise that systemd ended up steamrolling the competition. Ultimately systemd is what users deserve because no person or company bothered to make something better.

[1]: https://bbs.archlinux.org/viewtopic.php?pid=1149530#p1149530

Hypervisors predate Unix, in fact they practically predate general purpose operating systems as a whole. The reason hypervisors came first is because they are substantially more simple than an OS. Tens of billions of dollars has been spent on virtualization technologies because of its reliability.

Sure, a virtual machine running on a type-2 hypervisor like KVM looks like a complete mess. But the sad part is that such an architecture is easier to secure than an operating system, whether OpenBSD or otherwise. Raadt may disagree, but AWS, Azure, GCP, etc depend on hypervisors/virtualization, not OpenBSD.

You're describing the linux architecture as messy and complicated, but that describes the SELinux architecture as well...

Well, yes. SELinux has to cope with the deficiencies of Linux. I'm not pretending otherwise.

...if complexity & mess are bugs that should be squashed in pursuit of security, SELinux is ill-suited to the task.

The problem is that the market settled on Linux, despite its "complexity & mess". SELinux isn't nice but it's the most concrete solution available today. Indeed, after twenty years of criticism, no one has been able to design a competent replacement or alternative.

>> It's technically capable of any kind of restriction a bureaucrat might envision Sounds like we're on the same page there. Or at least looking at the same phenomenon.

There is a material difference between our viewpoints. The government has systems running in a dizzying amount of configurations and environments. Moreover, government agencies and government contractors operate in a far more dangerous security environment than the vast majority private companies. Perhaps your workplace doesn't need SELinux, but companies like Lockheed Martin or Aerojet Rocketdyne definitely do.

...you're just blaming the users.

Maybe it seems like splitting hairs, but I'm not blaming anyone. Rather, I was lamenting over the bad situation of things. After all, I've been there as a new sysadmin. Trying to grok SELinux for the first time is not a pleasant experience.

Don't blame the user when the tool's at fault.

Look, if security isn't important for someone and/or their organization, then fine, don't bother. However, we have seen time and time again that compromises in supposedly "unimportant" systems ends up causing quite a bit of harm.

Ultimately SELinux exists because of the shortcomings of Linux itself. Nothing has replaced SELinux because genuinely securing a Linux system is extremely difficult and it fundamentally cannot be made simple.

For several versions of the OS, this worked quite well, but once dual-sim devices2 started coming out, this became more problematic. Furthermore, when SELinux3 became common on Android, this became more problematic since the radio SELinux context that rild started with was too restrictive for the implant to function. - RoidRage Bootstrap Methods (https://wikileaks.org/ciav7p1/cms/page_28049453.html)

SELinux is designed to fulfill to primary goals. First, to secure the messy and complicated Linux architecture. And second, to be flexible enough to accommodate (highly) complex security architectures, as well as potentially unique and/or unforeseen needs. With that in mind, it's difficult to imagine any equivalent being practically more simple and/or elegant than SELinux.

The primary problem with SELinux is the broad lack of experience amongst users and sysadmins, opaque documentation, and primitive tooling. And in many ways, it is a negative feedback loop. If SELinux was used everywhere, improvements to its documentation and tooling would naturally follow.

Simply consider the case of China. They install and export more solar PV than anyone else in the world, and they are aggressively building out wind as well. It is literally impossible to get a better price than China when it comes to renewable energy, yet for some reason the Chinese have decided to dump tens of billions of dollars into nuclear energy.

OSHA standards are quite a low bar in general. An organization that is simply "OSHA compliant" is definitely not taking safety seriously. Moreover, OSHA is often far down the list of regulatory agencies that companies are worried about. For example, killing a protected bird species is far more likely to incur 6-7 figure fines and/or land management in prison than a workplace fatality.

That said, the situation with OSHA isn't particularly concerning. Most major companies are aggressively safety oriented. Even ignoring the legal liabilities of injured workers the fact is that, in the long term, unsafe working conditions are often less productive and potentially extremely damaging to capital investments. To illustrate, an accident at an oil refinery could easily run into the hundreds of millions in damage, in addition to an equal if not greater amount in lost production. The costs of settling lawsuits and/or fines for safety violations are trivial by comparison.

Nowadays, the greatest risks to U.S. labor is not from the likes of Kiewit, Union Pacific, Rio Tinto, etc. It is the small and under capitalized businesses. So, what can be done? Such businesses are already walking on a financial tightrope. If OSHA were to properly scrutinize such businesses even their limited fines would present a significant stress. Some people might retort that if a business can't operate safely than it shouldn't be operating at all, which is a fine. The downside is that all of those services will become substantially less competitive and more expensive.

OpenGL is only deprecated on MacOS, AFAIK, it will exist for many years to come.

I'm sure Vulkan is better in some regards but is simply not feasible to expect someone to learn it quickly.

Vulkan is often said to be more of a “GPU API” than a high level graphics API. With that in mind, the complexity of Vulkan is not surprising. It’s just a difficult domain.

Like, imagine the newest Intel/ARM/AMD chips came along and instead of being able to write C or C++, you're being told "We are dropping support for higher level languages so you can only write assembly on this now and it'll be faster because you have more control!" It would be correctly labeled as ridiculous.

IMO, it’s more like single threaded C/C++ vs multithreaded C/C++ programming. There is a massive increase in complexity and if you don’t know what you are doing, it’ll blow up in your face and/or give you worse performance. However, it’s the only practical path forward.

Anyway, OpenGL can basically be implemented on top of Vulkan. Perhaps it is regrettable that the OpenGL standard is no longer being actively developed, but nothing lasts forever.

Still, any serious developer should, at the very least, have the patience to interrogate their code.

Would you prefer that only 30 people should be allowed to hold up the acceptance of half-baked proposals? How could lower participation in C++ language evolution and/or standardization possibly do anything to improve the rigor and field testing of proposals?

Compilers now are in different states of ISO C++ compliance, between ISO C++14 and ISO C++23.

And? MSVC didn’t even do two-phase name lookup correctly until 2017, a fundamental feature of C++, yet the non-conforming behavior was little more than a nuisance. It’s really no concern of mine that Clang/libc++ hasn’t completed pstl support for C++17 because I wouldn’t be using it anyway. It is concerning when implementations half-asses a feature to pencil whip their “compliance” with new C++ standards (particularly when it only takes one implementation to make a feature useless for portable code).

Several of those on paper features, deemed not quite right when implemented, and had to be redone between revisions, but naturally old ones kind of stay in, backwards compatibility.

The developers behind major C++ implementations are acutely aware of every wart and failure, more so than virtually any end user. If they could they would choose to test every proposal on multiple compilers, across thousands of projects, targeting as many platforms as possible. But the resources and expertise to do so simply aren’t there. At some point the committee must hope for the best, take a leap of faith, and commit to a decision. It’s admirable that the C++ committee chooses to prioritize the needs of end users over the interests of implementations.

All languages are hostile to cross language interop,…

Managed languages do it every day (Kotlin and Java). But yes, the situation is quite different for native languages. What’s different about C++ is that it’s a remarkably difficult language to wrangle. C bindings are almost trivial to write or generate, but C++ introduces a mountain of complexity and ambiguity.

There are dozens of projects which have incrementally rewritten C in Rust. But it’s practically impossible to do anything similar with C++.

…that is why everyone pretends to be C, or uses OS IPC.

No language wants to bear the cross of a stable ABI, much less an ossified ABI. A platform’s C implementation has already paid the price, everyone is welcome to freeload.

That said, nothing good is ever free and the poverty of C ABIs prove it. With hardly any exceptions, describing a type C ABI as “fragile” is an understatement at best.

Uh.. MSVC does not adhere to the Itanium C++ ABI. ISO C++ does not specify any name mangling scheme, in fact I doubt the standard even mentions name mangling.

I think you're conflating different terms. Carbon and other similar C++-like frontends are essentially transpilers from C++-like grammar to C++.

Carbon resembles Rust far more than C++, to say the least. In my experience C++ developers criticize its difference in syntax more than anything else.

Anyway, setting aside the differences in syntax, the point I was trying to convey is that C++ is especially difficult to call from other languages, largely due to templates and/or sheer complexity. For a language to take a C++ header and be able to understand something as basic as std::vector, it needs to have quite a sophisticated understanding of C++ and its implementation. By comparison, Java is readily available in other JVM languages like Kotlin and Clojure, albeit those are managed languages.

Being "compatible" requires no reverse engineering but as I said above it's just a matter of following the C++ ABI spec

Not at all. A C++ ABI does not make it possible to magically understand C++ code. If you disagree, then please explain how a platform’s C++ ABI is sufficient to understand a type like std::string from another language. In particular even a vocabulary type like std::string is not compatible between libc++ and libstdc++, i.e. the two most binary compatible C++ standard library implementations available today.

Maybe it is becoming less relevant, but language proposals and attendance has grown tremendously since 2010, with no signs of slowing down. The real issue is that it's functionally impossible for a single group to meet the needs of the entire community.

It's no doubt a lot of work but if any of the successors to C++ such as Carbon, Circle, or cpp2 manage to release a solid compiler that is mostly compatible with C++17, I think you'll see a large migration towards it.

Only time will tell, however I would bet against C++ successors. In particular, C++ is fundamentally hostile to cross-language interopt, to the degree that even C++ compilers struggle to maintain compatibility between themselves. For a language to work with C++, its compiler basically needs to contain a C++ compiler as well (as Carbon does). Moreover, simply being "compatible with C++17" is only the very first step to practical usage, e.g. consider how much work the Clang developers put into reverse engineering GCCisms. And that is before considering more exotic language extensions and APIs like OpenMP (and perhaps SYCL at some point as well). All the while C++ continues to change and evolve.

No you aren’t. Or rather, there’s absolutely no reason for me to believe you are.

It's an ongoing problem the project talks about that there aren't enough newcomers ready to write more SIMD code with good enough quality.

Good programmers are in short supply across the entire industry. Like anything else it’s just a matter of practice.

The top reply is "just do this other thing that the article said was unworkable", so not doing that would be a start.

A) Get a thicker skin. It’s not the end of the world when people leave comments related to the topic at hand.

B) x86inc.asm isn’t a particularly interesting approach to programming assembly.

Other people mostly only target one CPU architecture as they're less important,…

If hardware portability is a goal then handwritten assembly is even more wasteful.

It's similar to how x264 was better than every commercial competitor while working for free, simply because they took more time to think about what they were doing.

A lot of it simply comes down to sheer man hours and the quantity/quality of bug reports. No 4d chess, no great geniuses, just “good enough” persistence.

Anyway, the problem with handwriting assembly is that such programs are trivial in their complexity and/or given unusually strong guarantees.

The project has 2000+ direct contributors and even more indirect contributors on its mailing lists.

...because so much other incorrect advice thinks it's fine to use autovectorization that doesn't work.

There are few high performance programmers who genuinely believe that autovectorization can compete with hand written assembly.

The recent article here about ffmpeg's use of assembly exclusively these comments, or people thinking it was a joke, even though everyone replying who'd actually used it explained why it was good.

I don't see anyone thinking it was a "joke". Comments range from std::simd to SIMD support in Java/C#. A few others quibble over the problems of hand written assembly, but only one or two users genuinely push back against the assembly. This is hardly persecution.

That said, I don't exactly understand your gripe with those people. Should they be showering ffmpeg et al. with praise or something? Like, it's great that the ffmpeg developers can afford to duplicate the same routines across different architectures and SIMD instruction sets, but hardly anyone else can justify doing that. For everyone else the best they can hope for are custom languages and/or better optimizing compilers.

...people constantly replying "um actually you never need to write anything in assembly" to them.

Honestly, who is saying that?

Oh come on now, about 7.5k of those lines are comments and/or blank lines. Furthermore, a good chunk of the code is devoted to type checking, thorough error handling, compiler compatibility and/or workarounds, etc, all within the restrictions of C++11.

… bundled in a single header as the one true distribution format.

Yes, build systems are a significant pain point for C++ and C. Many users prefer to largely avoid the issue and use header-only libraries. That said, Conan and vcpkg are making genuine strides at improving the issue.

I note the CI cmake script at a thousand lines of cmake.

This is ridiculous. It’s a CI script running multiple test suites over dozens of compiler versions, of course it’s going to be a lot. Would it make you feel better if that CI script didn’t exist? If not, then what’s the “correct” size for CI script?

That's a very idiomatic representation of a C++ library, thank you for the example.

The library is genuinely good. It’s portable, well tested, user friendly, and widely supported. Your snark is unwarranted.

I'm aware. What I was saying is that the US Government doesn't care about whether or not you're using USD for your transactions, so long as you pay the appropriate taxes in USD.

This intentionally kills the use of anything other than the dollar for transactions.

So what other policy would you prefer the federal government to have? It's pretty much the only good solution.

The record keeping for this sort of nonsense presents a massive and impractical to fight burden.

It's honestly hilarious that a few IRS regulations are all it took to fundamentally break cryptocurrency. Yeah sure, if you jump through dozens of loops and practice air-tight opsec, you can get away from paying taxes. But at that point it's basically a small group of people exchanging digital beanie babies and pretending they're valuable.

In such an environment, businesses undergo brutal competition for a shrinking pool of money. Simply servicing current debts and operating expenses becomes difficult. Taking out new loans and/or investing capital into such businesses is nothing short of insanity. Even if a business could raise prices the inability of consumers to pay could easily result in a net loss.

The economy is built on the velocity of money. There's a reason why Bush called on Americans to spend money in the aftermath of 9/11, the system really can't cope with a significant slowdown in spending, even if only for a few days.

...inflation is a way to raise revenue without calling it a tax.

Wow, European governments must've made a killing off of energy inflation over the last few years. Hopefully OPEC decides on another embargo, it'd pair perfectly with a Panamanian banana virus. The resulting inflation would certainly fill EU coffers to the brink. Still, nothing will compare to the impending wave of mass retirement in the developed world, government revenues will greatly benefit from the resulting wage inflation.