It’s an adaption (using the term loosely) of the appendices of the LotR, which is all they have rights to.
That seems like a non sequiteur. Did you watch the video? Did you hear what the presenter was asking for? Technical feedback on the API semantics they were describing. A heads-up if breaking changes to those APIs were about to land, so they can update bindings. They were bending over backwards to be accommodating. None of this is the entitled behaviour you describe.
It’s what C is for, too.
The point is that there may be cases already where the type system that rust provides its guarantees off the back of is insufficiently expressive. (I say “may be” because there are ingenious qays to use what it does provide, although nonobvious and not necessarily without cost.) If you’re using unsafe
then it’s just an uglier C. I don’t think anyone considers the current state of Rust’s type system to be the be-all and end-all of expressivity.
That’s an interesting notion (although it underestimates the effort, I think). Honestly, having machinery to write down contract semantics in a fashion amenable to automated proofs (meaning, does it type-check?) is massively promising; and I’m a dyed-in-the-wool C hacker. I would hope that the public exposure of this bad behaviour causes a few moments of self-reflection.
I suspect that attempting to chase a moving target of describing C apis with rust is just an avenue for burnout, unless there really is a mechanism for getting fixes back in the other direction, and professional respect flowing in both directions. That would be a massive shame, and an incredible missed opportunity.
What you describe would, indeed, be risible. Fortunately it’s merely histrionic twaddle.
There are some situations where I can see Rust’s type-ststem potentially being counterproductive. For instance, it may be valid to invert lock order in a chain of operations under some circumstances, and rust might prevent you from expressing that. I grew up with C (from the pre-ANSI days) and while lifetimes and ownership are things that good C devs care about, they are tacit - and the ability to play fast and loose when necessary is great.
The linux kernel is built on a foundation of these implicit semantics. Some of it is written down, some of it isn’t. I can see why asking “but what does this mean?” can lead to frustrating conversations and overly-qualified answers, but not everyone in that video was hostile to the prospect.
The thing here is that (even with things like the vfs interface), linux doesn’t have internal SPIs.
The friction here is that the rust devs want to write down the semantics in a formal fashion, and the C devs are used to a world where the semantics are implicit in the C code.
I thought the engagement in the video was the kind of useful feedback that was needed and asked for: “I’m not sure the semantics of this specific interface are precisely that,” which might have been out of place, but getting detail-focused feedback to an example is what you are going to have to expect from people who fit the role of VFS experts.
Ted was being an unconscionably rude fucker, but - diatribe aside - his process question is a reasonable one, although his solution “well you’re SOL” was poor, undiplomatic, and unhelpful.
No, the vast majority of linux developers are professionally employed to do it.
That’s not how legal jurisdiction works in the EU. Member states are still sovereign; if you’re liable for something in France and you get off a plane in Germany then France still needs to ask Germany nicely, and sans an extraditable conviction nothing is likely to come of it.
He’s not smart enough. More like the Grand Negus.
So you’re a practiced expert and cannot understand how those who are not practiced experts can have trouble?
Minimise your windows one at a time and check that the gnome keyring hasn’t popped up a dialog box sonewhere behind everything else that’s asking you if it’s okay to proceed.
It does rather sound like proposing an immediate 25k hike in house prices, yeah.
It’s the gnome key ring ssh agent.
It’s possible that this has popped up a window asking gor permission / a passphrase / something and you’re not seeing that.
That’s only part of the handshake. It’d require agent input around that point.
Is this problem a recurring one after a reboot?
If it is it warrants more effort.
If not and you’re happy with rhe lack of closure, you can potentially fix this: kill the old agent (watch out to see if it respawns; if it does and that works, fine). If it doesn’t, you can (a) remove the socket file (b) launch ssh-agent with the righr flag (-a $SSH_AGENT_SOCK
iirc) to listen at the same place, then future terminal sessions that inherit the env var will still look in the right place. Unsatisfactory but it’ll get you going again.
Okay, that agent process is running but it looks wedged: multiple connections to the socket seem to be opened, probably your other attempts to use ssh.
The ssh-add output looks like it’s responding a bit, however.
I’d use your package manager to work out what owns it and go looking for open bugs in the tool.
(Getting a trace of that process itself would be handy, while you’re trying again. There may be a clue in its behaviour.)
The server reaponse seems like the handshake process is close to completing. It’s not immediately clear what’s up there I’m afraid.
The way the electoral roll is managed varies from place to place.
Avoiding automatic voter registration tends to favour the more traditionally conservative demographic; it’s racist and classist, but the people who turn up to vote on local electoral issues are too, by and large. It requires engagement to change.