you can code-sign with open-source tools. That's not the hard part. Signing with a certificate trusted by macOS , that's where there's no avoiding having to go to Apple.
Your post could be (uncharitably) paraphrased as: "once you have written correct C++ code, the drawbacks of C++ are not relevant". That is true, and the same is true of C. But it's not really a counterargument to Rust. It doesn't much help those us who have to deliver that correct code in the first place.
Does there exist any platform which has multithreading but not atomics? Such a platform would be quite impractical as you can't really implement locks or any other threading primitive without atomics.
> Does there exist any platform which has multithreading but not atomics?
Yes. Also, almost every platform I know that supports multi threading and atomics doesn’t support atomics between /all/ possible masters. Consider a microcontroller with, say, two Arm cores (multithreaded, atomic-supporting) and a DMA engine.
Certainly such systems can pretty readily exist. You merely need atomic reads/writes in order to implement locks.
You can't create userspace locks which is a bummer, but the OS has the capability of enforcing locks. That's basically how early locking worked.
The main thing needed to make a correct lock is interrupt protection. Something every OS has.
To go fast, you need atomic operations. It especially becomes important if you are dealing with multiple cores. However, for a single core system atomics aren't needed for the OS to create locks.
> You merely need atomic reads/writes in order to implement locks.
Nit: while it's possible to implement one with just atomic reads and writes, it's generally not trivial/efficient/ergonomic to do so without an atomic composite read-write operation, like a compare-and-swap.
I wrote "multithreaded" but I really meant "multicore". If two cores are contending for a lock I don't see how irq protection help. As long as there is only one core, I agree.
The boring answer is that standard atomics didn't exist until C++11, so any compiler older than that didn't support them. I think most platforms (certainly the popular desktop/server platforms) had ways to accomplish the same thing, but that was up to the vendor, and it might not've been well documented or stable. Infamously, `volatile` used to be (ab)used for this a lot before we had proper standards. (I think it still has some atomic-ish properties in MSVC?)
> A bit disappointed that it doesn't work on Firefox.
I swear the entire ~3% marketshare of FF users (myself included) are lurking in this thread lol. You are all giving me an excuse to increase the priority of cross-browser support
Using Firefox implies, to me, a willingness to customize the browser experience, which would probably heavily overlap with your target demographic. Since the extension manifest version update disabled some essential browser extensions, Chrome has become much less useful
Relicensing isn't necessary. If you violate the GPL with respect to a work you automatically lose your license to that work.
It's enough if one or two main contributors assert their copyrights. Their contributions are so tangled with everything else after years of development that it can't meaningfully be separated away.
reply