1,256 karma · joined January 19, 2018
Party A makes statement A,
Party B makes statement B,
Statements A and B are in contradition,
Party A claims that both parties agree that statement A is true,
Party B claims that both parties agree that statement B is true.
If you seek truth about reality, you better take humans out of the loop...
That statement itself is partisan. So is the meta-statement about who agrees with that first statement.
Really, any messy argument is about the claim who made which claims.
This is a very software-engineery point of view and totally false for the ordinary user. Heck, it is even false for me as a software engineer.
> since you know people like moving a mouse and clicking on buttons
No, they like well-designed user interfaces, and the UI design of a typical CLI is abysmal.
It's yet another xkcd-level apocalypse.
Not trying to downplay the time wasted to reject the PR, though.
Specifically, humans are known to decide subconsciously, then invent some "reasoning" out of thin air to justify it.
This matches my experience with decision-making in software projects.
I'm thinking of something like: Explain, in at most 300 characters, why we should merge your change, or at least why we should invest the time to read a longer explanation (somethings things ARE complex). If you don't do that, or those 300 characters aren't convincing, or have nothing to do with your change or the longer explanation, then you get a canned response so the maintainers waste minimal time.
At least verifying a signature is something that does not need complex hardware, so chances are that your trusted hardware can do that.
> Your own trusted hardware AND software, because you're not going to be verifying that signature by hand, and you're not going to load the binary file in memory by hand, so either a kernel or system software (like UEFI) will be handling your trusted binary first. > > But then you're back to needing a clean bootstrap again. (...)
But having solved that bootstrapping problem, you are likewise back to square one with trusting "the payload", only this time the payload isn't the actual payload but the OS kernel, UEFI or whatever that obtains and verifies the actual payload.
You have that OS kernel or UEFI as source code, but you don't know if the source code contains a backdoor unless you either verify it manually, or have it verified and signed in some way by a third party you trust, and there the whole signature thing comes back.
(BTW thanks for the discussion. I'm really enjoying this!)
In contrast, how can you make sure that the actual payload code hasn't been tampered with? It is written in a high-level language, but it gets stored and viewed on devices that have backdoors in their CPU microcode and huge OSes that can hide god knows what. The author can sign the code, but that doesn't tell anything other than it was really the author who signed it and the code hasn't been modified afterwards -- if the author's system was compromised, the code can contain backdoors before being signed. So you need to validate the (signed or not) code to be correct, but you're doing so on an untrusted system. It goes on and on.
You'd probably need the code to be verified, then signed, by a trusted party on a trusted system. THAT signature then means the payload hasn't been tampered with, and can be trusted after it gets built on your trusted system (and this is where the bootstrap problem happens, and gets solved).
All this is obviously still glossing over the problem how to obtain hardware you can trust.
...edit: But if you have all that, then you don't need a complex bootstrapping anymore. A trusted actor can verify, or even build, a trusted system by hand on trusted hardware, sign it, and then you can use that (binary!) as long as you run it on your own trusted hardware and verify the signature first.
The bootstrapping then becomes a tool to ensure reproducibility, but is no longer needed for trust.
The GCC example is valid, but can also be explained by its size.
I like the idea of bootstrapping in a Lisp-like language since it is extremely expressive for its simplicity. But then you need an interpreter for that, which must be trusted. I've been nerd-sniped by the whole thing and I'm thinking about an extremely simple virtual machine for the seed, with the actual seed code being a binary for that VM that implements a Lisp. Then an audit of the seed becomes disassembling the VM code for the Lisp interpreter, which is only moderately complex because the VM is as simple as possible.
I'll use this to ask for an explanation about the fundamental idea: How is hex text better than a binary blob? Both need detailed knowledge to understand; both need a tool to display (reading ASCII or binary), either of which could be compromised in a "trusting trust" sense.
It seems to me that the actually important aspects of the initial "seed" are its size (larger is harder to verify) and that the language used (whether it is Lisp, binary machine code or whatever) has rigorously defined semantics.
(Orthogonal to that, you'd want to store everything, seed and the rest, on a medium that cannot hide anything from you, and use that as the source. But that applies to all approaches.)
What is the "n that goes to infinity" for Sudoku? I thought that you could iterate through all possible 9x9 grids and find the ones that satisfy the rules AND are consistent with the "known" numbers. That would make it O(1), not NP-hard.
Your logic is self-defeating. How are distro volunteers going to know that you are interested in this topic if, by your logic, you don't have the privilege to ask them in the first place?
But I don't think that asking needs any privilege. I'm going to ask again: Why not? Or worded differently: What is stopping language package managers that is not at the same time stopping distro package managers?
Why not? Seems like exactly what is being asked for.
I'm not so surprised, given that you cannot write support tickets if the bug prevents you from registering...
Also, I don't think people have high hopes that a broken government website will ever get fixed.
In other words, physics can explain Shakespeare's plays when you hand-wave away the biggest reason it cannot.
> theoretically
... meaning not in reality, but in an abstraction of reality that conveniently leaves out the hard part.
> This is just a data problem though.
The word "just" makes it sound like that data problem is a minor inconvenience, and not a fundamental obstacle.
Becoming a billionaire is simple, after all it's just a money problem.
I mean, you're right in that (leaving out quantum randomness), you could predict macroscopic outcomes based on a physics simulation that includes all elementary particles explicitly, if you assume that such a simulation can be scaled from <10 particles to macroscopic numbers. But there is no evidence that this assumption is true, so it remains an interesting thought experiment that gets confused with reality because people like to slap the "in theory" label on it.
This is false. It is meant to protect users from a confused-deputy attack made by malicious websites, where that website makes a request to a "serious" API but the user has never asked for, or approved, that request.
Blaming the user for everything that happens serves nobody.
You have to already know from experience that these strange devoid-of-information requests have been blocked by CORS, then find the preflight request, and there you will find a bit more information, but still much less than would be possible to show.
Showing more information would, AFAIK, not circumvent the layer of security that CORS (or actually origin isolation, which CORS makes an exemption from) adds. My best guess is that this just had very low priority when building the dev tools.
> How much of an impact can this have? > Reading is:alive (1 byte) Across 1M Monsters
You aren't reading one byte here, you are reading 1M bytes! Of course, optimizing the access to 1M bytes is something to consider. Optimizing the access to one byte isn't.
The article is definitely worth reading IMHO, but it really needs a better headline!