usamoi

If people pay for real open-source work, for example, KDE and GNOME, rather than some dotfiles, that's better.

For reference: Arch Linux's monthly expenses are about $2,000, most of which goes toward servers. In other words, for a project of Arch's scale, $10 million would be enough to keep it running for 500 years.

This code is not equivalent to the C++ version. You can directly use `*x == [0_u32; SIZE]`. The code generated by the two is different. (But the iterator version not producing optimal code is also an issue.)

I really don't understand what's the point of such comparisons. Swift uses subtyping, while Rust uses typeclasses. Even looking only at their type systems, the two are completely different. You can't assume they are similar just because they both use the Latin alphabet.

Another chip without V extension.

But isn't RISC-V just a standard? ISO will decide what is RISC-V and what isn't. Then its complicated process will become an obstacle to innovation.

> The RISC-V ISA is already an industry standard and the next step is impartial recognition from a trusted international organization.

I'm confused. Isn't RISC-V International itself a trusted international organization? It's hard to see how an organization that standardizes screws and plugs could possibly be qualified to develop ISAs.

I've never heard of SPARK. What advantages does it have compared to Lean?

It depends on who you are.

For implementers of third-party compilers, researchers of the Rust programming language, and programmers who write unsafe code, this is indeed a problem. It's bad.

For the designers of Rust, "no formal specification" allows them to make changes as long as it is not breaking. It's good.

Not implementing the Zbb extension but implementing big-endian. That sounds like doing it the hard way.

> Our engineers are smart and hardworking but they throw their hands up at this.

Since you don't think this is a skill issue, shouldn't you support Safe C++, which eliminates unsafety rather than just turning a blind eye to it?

> Please tell me my options aren’t limited to “please be better at programming”…?

You can only use Valgrind/ASan, stress testing, and rewriting in other languages to pay off the technical debt. Even if a god points out every bug in your code, you'd still need to put in great effort to fix them. If you don't pay for it while coding, then you must pay for it after coding. There are no shortcuts.

They are not rejecting Safe C++; they are rejecting memory safety. Majority of them believes that memory safety is just hype, and minority of them knows it's a problem, but doesn't want to restrict themselves about coding. If code runs, it is fine. If it does not, coder running is fine too.

Well, it is clear that they have a new definition of a microkernel, since there are now more new technologies that achieve isolation without compromising performance. Microkernel vs monolithic kernel is more of a marketing rhetoric than technical differences.

This is actually quite easy to achieve, as long as you cannot realize your own mistakes.