I recommend using the package manager than building yourself. If something needs to be modified about the source, it will first be patched in the widely used package manager. convincing upstream to take in a patch & then waiting for a new version to be released with that patch takes time.
Ridiculous claim. A few months ago Gaza militants fired 460 rockets in one day, injuring 80 people (mostly civilians) and killing one, and the IDF has barely done anything besides bomb empty buildings.
When's the last time your country restrained itself after being hit by 460 rockets in one day?
Google has 100 times as many employs as NSO group. The equivalent for a group of 100 Google employees signing a petition is one person signing it. They can just be fired & replaced.
Is it weird to support some of these today? we just dropped acorn26, although it was gone for a few years.
I think mips r3k has a better behaving add ("addu"), or is that only on some? if your compiler outputs these you don't have to worry about special behavior.
I'd say a bigger concern, for vax - the lack of IEEE754 is noticeable when people pick unsuitable float constants, or it traps by default. or the many GCC bugs now.
For mips r3k, the complete lack of atomics. And the load delays.
If you've ever been on the bad side of banks you'll dread this a lot. I merely had my credit card stolen but getting a replacement was surprisingly time-consuming and I'm glad I could still eat and travel until then.
Apple isn't the best example. They generally do publish the modified source code to FOSS projects they do, and sometimes they don't add their own license clause, so the changes can get merged back.
HP's "keylogger" doesn't belong in this discussion. It was a debug trace to a driver. I've left similar traces as part of debugging. It wasn't even their driver but belonged to Synaptics.
The way netbsd does GCC updates gives a really wide margin for figuring out compiler issues:
- Copy existing compiler into gcc.old
- Add new compiler as "gcc"
- Switch architectures one by one
If one architecture is left behind it's not a big pressing issue, you have until the next GCC update. They're done once 2-3 years hopefully so the GCC VAX issue taking 6 months to resolve wasn't close to being a problem.
As for removing architecture support, as long as it builds without extreme intervention, the non-VAX crowd is going to leave it alone. The VAX code is mostly separate in its own directory so doesn't get in the way.
The people who care about VAX within NetBSD are very knowledgeable and it would be a shame to alienate them without a good reason. They've contributed a lot of non-VAX stuff too.