ongy
They mostly start the software because they themselves want to have it.
When they start working mostly for other people's needs, I think it's a mix of altruism, pride and probably enjoying the work.
I prefer Sydney Opera's outside shape.
The wiki pictures of the inside of the Heydar Aliyev Center also look odd to horrible to me.
Last I checked I'm allowed 100Wh of power bank on a flight. And for flights where that's not enough I'm used to having a (~100W) socket.
* Does the site know who the user is: No. That's the entire purpose here.
* Does the site know who the attestor is: Yes, they need to validate asymmetric crypto on the proof, so they need a list of public keys (which they can attach attestor identity to).
* Does the attestor know what kind of content I want to visit: They should not. With the JWT you can validate without telling the attestor which user's proof you validate. OTOH, if there's some "is this one revoked" type of API one could easily re-introduce such an information channel on accident.
* does the attestor know who the user is: Yes (or at least have some bits of information about you they are willing to attest to others. In practice assume it's Google/Apple/MS with information associated with your account, or your bank or ...)
* Does the user always know site/attestor: From a technical perspective yes. From a practical human one... doubtful.
--Googler, though far removed from this project, so no internal knowledge.
This was quite interesting though. Surprised to see it work so well on a real example.
It's hard to justify the price unless you put value to Framework's gimmicks and mission.
There's no illusion that I'm not paying extra to vote with my wallet for sustainability. And I'm on with that.
Which worked well unless compiled with `strict-aliasing` gcc optimizations enabled...
Just writing UDP RFC compliant code doesn't protect you from running into annoying behavior with your programming language of choice...
Colocation has its uses bit is a bit finicky. The push/pull compatibility works perfectly fine (with some caveats of github being broken that can be worked around).
But not the 3rd mono repo on the same technology to avoid some scaling limit.
Actual fips compliant (certified) gives you confidence in some basic competence of the solution.
Just fips compatible (i.e. picking algos that could be fips compliant) is generally neutral to negative.
I'm not 100% up to date, so that might have changed, but AEAD used to be easier if you don't follow fips than fips compatible. Still possible, but more foot guns due to regulatory lag in techniques.
Overall, IMO the other top-level comment of "only fips if you have pencil pusher benefit" applies.
Granted, we already have US/EU/Asia as distinct regions. AUS would just make fail over even worse.
The high ping kills the throughput on davfs and makes their website hosting a pain to update :(
But the git directory entry contains: * a type (this one is quite limited, so I'm not sure how well that could be (ab)used * a name * a pointer to the content
Which is exaclty what an AST entry has.
The cli really isn't the greatest either way. But there's lots of infrastructure to make the sharing work reasonably well.
It shouldn't be hard to build a bijective mapping between a file system and AST.
I don't think there's a limit in git. The structure might be a bit deep for git and thus some things might be unoptimized, but the shape is the same.
Tree.
Not a result of git.
Business continuity (no uncontrolled external dependencies) and corporate security teams wanting to be able to scan everything. Also wanting to update everyone's dependencies when they backport something.
Once you got those requirements, most of the benefits of multi-repo / roundtripping over releases just don't hold anymore.
The entanglement can be stronger, but if teams build clean APIs it's no harder than removing it from a cluster of individual repositories. That might be a pretty load bearing if though.
Or would open the system up to the originally posted attack of providing ~an open relay.
If that ever repeats, the same I'd was used twice. At the same time, the site ID would act as salt to prevent simple matching between services.
And when then, only when I'm in foreign countries.
In real world scenarios, I can observe them while they handle my ID. And systematic abuse(e.g. some video that gets stored and shows it clearly) would be a violation taken serious
With online providers it's barely news worthy if they abuse the data they get.
I'm not against age verification (at least not strongly), but I'd want it in a 2 party 0 trust way. I.e. one party signs a jwt like thing only containing one bit, the other validates it without ever contacting the issuer about the specific token.
So one knows the identity, one knows the usage But they are never related
Also, about github: Had a chat with the Gitlab chap doing the Git talk in the main track. Apparently they dialed back their involvement with upstream git quite a bit. Github is currently providing a lot of infra gratis (thanks!) but is at best neutral to code and community.
OTOH, 80% of the reason I go to talks is to see if the person has interesting things to say and grab them after the talk for a chat. I.e. it sucks for the remote experience, but I think for on-site it's fine to just talk more.
Gets harder if you consider the talks the main attraction, but I really see them more as hooks to talk to people about interesting topics.
It's a very "I've made a cool thing. This is what I think is cool about it" type of talk. Which I don't think is uncommon for FOSDEM. Maybe a bit uncommon for a higher profile figure like Lennart.