moring
But that would require the OS to know what a relevant URL is, so the permission must be scoped to a prefix, or maybe a regex(1) to be applied when the clipboard contains text content.
(1) restricted to "proper" regular expressions that don't have the security issues of Perl-style REs.
... who draw their wealth and power from society, because society decides they deserve it.
> Despite this, real-world LLMs still produce varying outputs due to factors like: > - Floating-point precision limitations
This by itself is deterministic, as per IEEE 754, as long as no parameters are "left to the implementation". The Java virtual machine had this problem before, and fixed all parameters to be deterministic. Depending on the hardware, this comes at a performance cost (if some hardware cannot support the chosen parameters) which is why the JVM introduced lenient floating-point to let the code choose between determinism or performance.
> - Hardware and parallel processing variability > - Decoding tie-breakers > - Other sampling parameters like top-k or top-p that may still introduce variation
I'm assuming this refers to different HW architectures, because hardware variability at the lowest level (silicon patterning and doping) is already dealt with by circuit designers. Again determinism can be achieved by prescribing the exact procedure, which the hardware must replicate in behavior but not necessarily in implementation. And again, this may come at a performance cost when specific hardware cannot implement the prescribed procedure at all, or only by keeping actual hardware parts unused.
--
All that said, I don't think that determinism is all that useful, because it only guarantees that the output will remain constant as long as you don't touch anything. In reality, you want the output to be "similar" as long as you only change "irrelevant" things, and determinism won't help you with that.
> Just like the other stack allocators we talked about, this one can also work in a multi threaded environment. You might be tempted to make the two updates transactional – like with a compare and swap loop – but it isn’t needed.
Unfortunately they don't explain HOW this is going to work...
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?