I think there's room for regulation and forced audits. The important part is that the compliance costs are small compared to development and production costs. That's true in the car industry unless you have really low volume, while airplanes are pushed over the threshold by much lower volume and much higher regulation.
Meanwhile, i don't think i should have to ask permission from the government to make something like, e.g. a map editing tool for a 90s fps, like i did yesterday[0] (the tool, not requesting permission) or a sprite editor[1] or a quick-and-dirty wiki server to take notes in games[2]. Or really anything that doesn't have to do with areas where lives are at stake (which AFAIK is already being done anyway with programs needing to pass conformance tests - something i'm perfectly fine with, at least in theory, as i don't know in practice if these tests really work or are designed to help existing actors stay entrenched).
[0] http://runtimeterror.com/tools/chasmfe/
And again, the original comment above is not "ask permission from the government" but instead "pass independent security audits by neutral auditors before exposing your software to the general public."
> independent security audits paid with public money
The "with public money" part means they are funded and thus controlled by the government.
Not that i think a privately owned megacorp is much better, after all i do not like the scare boxes you see on unsigned (and "lesser signed") programs in Windows and macOS unless you pay the certificate mafia protection money - but at least those do not block you completely.
Daily fines proportional to installed user base, on the basis of confirmed and not yet fixed CVEs. Amount inversely proportional to price of per-user software license (ie. the cheaper the gadget, the heavier the fines). Exception for AGPL-compatible licenses.
Incentives and credits for smaller companies' training and audits. Funded by fines above.
Incentives and credits for companies fixing CVEs on AGPL-compatible software. Funded also by fines above. Amount of incentives proportional to installed user base and severity of CVE.
Audit practices defined by group of international bodies.
What have OpenBSD developers done to you? :-P
I can literally dope silicon and make my own chips, but even I have to trust "the system" to buy food and shelter, etc.
You can draw a line from the invention of the transistor to the eventual necessity of solving the ultimate human problem: how do we get along with each other?
How so? The best usable homemade transistor project that I’m aware of, consisted of something on the order of 100 amplifiers/transistors on a chip. And even then, the author had access to professionally made silicon wafers, and likely a whole lot of expensive/dangerous chemicals and equipment. This is very far outside the realm of a casual hacker.
Making even the simplest 6502 equivalent by yourself is impossible, forget more complex projects. I feel like this should be urgently addressed, given how important computing is.
Sam Zeloof is doing great things: http://sam.zeloof.xyz/
> Making even the simplest 6502 equivalent by yourself is impossible, forget more complex projects. I feel like this should be urgently addressed, given how important computing is.
I've thought about this, more in the context of post-apocalyptic computing rather than trust, FWIW.
If I were really going to make my own computers from scratch I think clockwork (Clock of the Long Now) or fluidics would probably be the way to go. Maybe electro-mechanical (relays, etc.) or vacuum tubes? We did pretty well with the abacus and the slide rule, eh?
> I've thought about this, more in the context of post-apocalyptic computing rather than trust, FWIW.
Post-apocalyptic computing is one possible motivation to look at this, but other reduced-tech settings like a fully independent Mars colony also simply cannot function without a way to fab simple IC logic. That, or we’re happy to go back to early Apollo era tech levels.
RE: computers from scratch in the absence of IC fabrication. I think our best chance is vacuum tubes. Mechanical relay computers seem to have been phased out in favour of vacuum tube solutions pretty quickly, so I guess there must have been some compelling reasons to do so (my guess - speed and failure rate of individual switching components). Couple that with old-school electromechanical tech for IO/industrial sequencing, several K of delay line/core/Williams Tube memory, and you’re golden.
Yes, what we need is more roadblocks in there, to ensure software that has captured large segments of their respective markets remain entrenched and make it harder for new developers and projects to dethrone them while giving the government (of which country?) control over what software people can run - no way this will be abused at all X-P.