No one mentioned Upspin? A global file namespace (URL, but better...) and protocol to isolate public data users from private governance and storage, by gurus like Rob Pike. https://github.com/upspin/upspin
At least in Finland the jail sentences have been related to extreme widely published antisemitism. Fines have been given for other sorts of hate speech.
If the U.S. wants this to be allowed, it is your business. But it is ours to decide, if we want to allow nazis synmpathy newspapers advocating killing of the jew. Generally, the americans are lost in their arrogance here, as always.
I don't think there has been a rock album ever since, that would have been so big, popular, revolutionary and generation defining. I guess some genius must have been there.
Can you explain me, why do you need to be online to extract the private key? Can't you just steal the token, input the nonces offline, and meter timing? Then, crunch out the private key, and only then, if needed, phish the password?
Yubikeys and similar FIDO hardware authenticators roughly speaking have two modes of operation:
Resident/discoverable credentials are stored on the hardware itself. You can attack these completely offline.
Non-discoverable credentials are not stored on the hardware. To get the authenticator to perform a private key operation (which is a prerequisite for being able to exfiltrate the private key using this attack), you need to supply the credential ID to it, which contains the data required for the authenticator to re-derive the private key.
Usually (i.e. in the WebAuthN-as-a-second-factor use case), a website will only reveal candidate client IDs upon successfully entering your password.
If this is inefficient, what are you comparing to? What is the best way to purify water or produce hydrogen with solar energy? Is there a good way? Certainly producing electricity first can't be the most affordable way?
Designing better error handling in Go is an ongoing work. Proposols are being considered. Personally I don't see a big problem in real life Go code bases.
Note that there is kind of a philosophical cul-de-sac here. If you understand and expect your "errors" (= exceptional situations that prevent the program to do what we thought the user wanted) you can handle them, and they become part of your program normal logic.
If you don't understand or ainticipate your errors, or choose to neglect situations that are not really rare or are really dangerous, no amount of special language constructs will save your users.
> = exceptional situations that prevent the program to do what we thought the user wanted
Just to latch onto this remark, are they actually exceptional? Say you have a REST API, does something with a database. 1 in 1000 requests fails, so it's exceptional I suppose. But then you go web scale, and your application gets called a million times per minute. Suddenly you're dealing with 1000 errors per minute; not so exceptional anymore.
Besides, errors can also be things like 'SQL row not found', which are expected in the normal run of things.
If you browse random Go code from https://pkg.go.dev/ you will have a hard time finding that hypothetical case where most of your code is error handling chores. The problem is artificial.
Yes, I agree. If you just ignore errors, they will go away. #yolo
P.S. That said, any program written in Go is an absolute shitshow of crappy UX because of the (inevitably) inconsistent and often incorrect error handling.
Once a Go program goes off the happy path, the only way to figure out what happened is to read the source code. (No, you cannot have a stack trace. Stack traces make junior programmers feel uncomfortable, and so Google made them verboten.)
And even then, because Go uses insane and outdated OOP practices like casting all pointers to a generic base class, even reading the source code is a exercise in frustration and rage.
Stacktraces are not useful for end users of the program and should never be shown unless there is a bug in the program.
It is silly how many Java or Python programs display stacktraces on trivially preventable problems that are not bugs (e.g. file not found) instead of giving short human readable messages.
There’s error wrapping for adding context. Where one adds a human readable context to errors. Stack traces as I know them from the JVM world, with their line numbers and method names, seem a lot more coupled to the source code, so I’d say it’s the other way around really.
Library code, especially stdlib, is usually the bottom of the abstraction chain and rarely performs fallible operations like IO. It’s the one originating the errors.
The issue is that application code usually has several layers between the end-user and the fundamental operations like Read()/Write(). Bookkeeping errors through all these layers is a chore. You can skip the layers but then you get spaghetti.
They are also pretty good in teaching you human languages. There is a saying that the best way to learn a new language is to fall in love with someone who speaks it. ChatGPT speaks them all. Start with "Show me some simple phrases in Chinese and in English..."
