modshatereality

It's true you shouldn't tinker with many types of hardware without extensive knowledge and experience. You're going to want to staff your off-world outpost with competent engineers and scientists that can develop and test new task-specific software or patch existing software, not some random entry-level programmer or tinkerer. IMO it would be extremely arrogant for a manufacturer to claim their remote updates "must" be tested adequately in every conceivable environment, up to and past the operating requirement extremes because some imaginary regulation dictates it. From {m,b,tr}illions of miles away because AFAIK the best they can do is simulate what might happen, not actually test operation in a real environment as their life actually depends on it. If I cannot audit the encrypted bytestream it sure as hell is not going to be piped into any of my spacecraft, life support, communication systems, or anything TBH. With me, trust starts with being able to read the source code, and modify it when it needs to be fixed. Giving a specific crypto function too much trust could leave you vulnerable or even lock you out of fixing critical flaws that "the manufacturer" sees as perfectly fine and within spec.

Maybe I've just had too many horrific experiences with software updates and that is causing some bias. Or seen too many science fiction films.

Maybe not exactly futile, but too many security measures can become a serious problem in certain scenarios. Imagine you are being chased and need to get inside your front door as quickly as possible, the more locks you need to operate, the higher chances of not making it inside.

Now I'm going to propose a more likely future scenario. Imagine you are on another planet and there is a software flaw that needs to be patched. Do you want to have to beg some billionaire millions of miles away for the privilege of modifying the code, or do you want the ability to fix it as soon as possible? If its a time-sensitive issue consider the consequences of having to fumble around with deploying signed patches, or installing a new key and updating everything to work with the new key.

None of these trust devices are perfect, they might leak data that can be used to infer keys through side channel, or can be physically inspected, etc, I think we can all agree they are not perfect. So if the security model breaks down with physical access then the only adequate solution is physical security. Putting your faith into some crypto function that will be obsoleted by time is not a winning defense. It's also possible the keys may have been obtained by a malicious adversary, rendering this mathematical security layer ineffective at best. If I can install new keys, then an attacker can also install new keys. If the imperfect security measure causes more problems than it solves, then its worth rethinking.

What problem would it ACTUALLY solve in this scenario? Maybe it could be used to mitigate a breakaway civilization by only allowing patches through remote update channels, keeping new outposts fully dependent on Earth. Potentially at the cost of real lives if that update channel is broken somehow. Though someone always figures out a way to break the lock :)

Please I don't want to hear about some hypothetical dissident of a tyrannical regime, they should have destroyed the device before capture if they had any wits. The regime would probably be forcing its citizens to run fully validated stack anyway and would be all up in their business for (red flag) installing their own key instead of government approved key... Corporate security? Lol do you think your petty secrets are worth restricting humanity by normalizing imperfect security measures? Some of these corporations need to be kept in check somehow, they have too much power already.

The only future I'm on board with is one with a robust well tested software ecosystem controlled by its users/operators/owners, not a careless conglomeration that prioritizes the well being of it's shareholders, or crushing its competition.

Others claim mrustc is the second, but has anyone actually tried to use it? the readme does not inspire too much confidence, and looks to (currently) be a C transpiler:

"mrustc's primary goal is bootstrapping rustc, and as such it tends to assume that the code it's compiling is valid (and any errors in the generated code are mrustc bugs). Code generation is done by emitting a high-level assembly (currently very ugly C, but LLVM/cretone/GIMPLE/... could work) and getting an external tool (i.e. gcc) to do the heavy-lifting of optimising and machine code generation."

At least it can be used to bootstrap the actual rust compiler. It's a bit crazy to me how popular this language appears to be, but doesn't have a proper second compiler yet.

unobserved hypothetical variables used to explain a big assumption.

The admins knew this was going to happen, people need to stop spreading misinformation pretending that they were caught off guard.

The real enemy is latency. Physical switches that trigger an IRQ directly to be handled by the program within microseconds would be ideal for human gaming (edit: or directly reading hardware registers). Everything else is just another weak option, pretending to be a gaming system. Also while I'm on the topic, F microsoft for still preventing me from developing software for their system independently.

When did computers stop being deterministic? Just because your mainstream PC-OS is no longer a sane piece of engineering doesn't mean the entire field is lost.

Judging youtubes (javascript) performance trend observed in the exact same browser build on the exact same hardware over a multi-year period, time to abandon ship fellas.

FTC website falls victim to the darkest pattern of all: relying on javascript to manipulate html elements, so this is just a blank page; yet another anti-HTML site.

True, though systemd-* naming scheme provides a substantial amount of brush for mal-binaries/configs to use as persistent cover. Every system could be different, but distros are lazy it seems.