Rather one long function than does one thing well than multiple function that are strongly coupled and difficult to reason about. Programmers who apply dogmas can be harmful.
I think it is more expectation about expectation. You buy/sell based on whether you expect other people to expect earn or lose. It is self-referential, hence irrational. If a new play enters and peoples expectations shift, that affects your expectation of value even though the companies involved are not immediately or directly affects.
They are not impossible to track, but that would be relevant only if Mullvad were severely compromised — and even then, we would only be in almost impossible territory.
There are no central repositories as to the location of arbitrary banknote serial numbers.
Lets assume, for the sake of argument, that a cash-paying user were to make the mistake of paying every single time to renew the same suspicious Mullvad account using cash which was always newly withdrawn from cash machines from a banking institution which meticulously tracks them and is able to report from which location they originated (maybe even the card which withdrew them!).
In that case, if Mullvad were to be compromised (or if the targeted user was such an absolute threat to humankind that Mullvad were to agree to collaborate in his or her capture), it would only be possible if Mullvad's mail receivers were to either a) actively keep track of either banknote serial number and link it to a customer, or b) be fully aware of the requirement to make a note of it only of received to renew the target account.
Anything short of that and even the perfectly traceable banknote serial number just becomes one of hundreds? thousands? deposited by Mullvad in their bank accounts — assuming they don't even use some of them as petty cash if needed.
If a user of Mullvad were to reach that level of a threat model I would argue they would be much more likely to be caught by tracking of their sent mail, in the style of Ted Kaczyński.
> There are no central repositories as to the location of arbitrary banknote serial numbers.
Why do you say that?
All that's needed is banks tracking serial numbers and associated persons as cash leaves the bank and enters it. The serial numbers on American cash seem machine readable, and on each bill they are printed in two places near opposite corners - as if they are designed for automated reading.
It doesn't have to be perfect, logically infallible, alibi-proof evidence. You could build a pretty good graph of who is doing business with whom, especially by examining repetitions of the same edges. At worst, it seems useful for intelligence tasks and to obtain worthwhile leads to pursue.
A serial number is not a tracking device. A sufficiently determined adversary with unlimited resources and access could maybe track you via it
But practically speaking an afternoon of shopping, exchanging coins for banknotes, breaking those into coins and back again will make it as untraceable as possible.
Especially since we're talking about 60 euro per year
When C was conceived, CPU architectures and platforms were more varied than what we see today. In order to remain portable and yet performant, some details were left as either implementation defined, or completely undefined (i.e. the responsibility of the programmer). Seems archaic today, but it was necessary when C compilers had to be two-pass and run in mere kilobytes of RAM. Even warnings for risky and undefined behavior is a relatively modern concept (last 10-20 years) compared to the age of C.
When C was conceived, it was made for a specific DEC CPU, for making an operating system. The idea of a C standard was in the future.
If you wanted to know what (for instance) memcpy actually did, you looked at the source code, or even more likely, the assembler or machine code output. That was "the standard".
I think it's reasonable to assume that GP clearly meant the C standard being conceived, as, obviously, K&R's C implementation of the language was ad hoc rather than exhibiting any prescribed specification.
> Seems archaic today ... run in mere kilobytes of RAM
There is an entire industry that does pretty much that... today. They might run in flash instead of RAM, but still, a few kilobytes.
Probably there are more embedded devices out there than PCs. PIC, AVR, MSP, ARM, custom archs. There might be one of those right now under your hand, in that thing you use to move the cursor.
Each keychain item on macOS has an access control list associated with it that lists the applications that are granted access to the keychain item. If an application not on the ACL attempts to access a keychain item, macOS prompts the user for authorization. The ACL entries identify applications based on properties of their code signature and so are not spoofable.
Correct. The best part of this system (Keychain Access) is that it has been around for more than 20 years. Only this year it got a UX makeover.
One interesting thing I noticed is that Chrome and Firefox can also seamlessly see and use Passkeys I stored in Safari even if normally they don't read the passwords from there.
Using each passkey however still requires a fingerprint every time.
Sure, if that is the only program, but it is not. This kind of thinking drains batteries faster than necessary, drains the cache, and reduces CPU efficiency.
sleep() is a wasteful system call, a kludge at best, and is never the correct solution to a synchronization problem.
