From a quick look at the Wiki page

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.

Source?

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.

I can confirm that all the flights I have been on this year we were told not to use power banks. You can have one with you (well you have to since you're not allowed to check large lithium ion batteries) but you aren't allowed to actively use it.

I've flown on half a dozen different airlines this year and all have had exactly the same stance: no power banks in checked luggage, and if they're in hand luggage you must be able to see them at all times (not in overhead storage).

You're also not allowed to use them even if you do have them with you. This is all very strictly enforced with reminders at the check-in desk and several announcements before take-off.

100 W sockets? All the flights I've been on that provided power have had a really low current USB A port that can barely keep my phone from discharging when the screen is on.

I tried to find something definitive, but it would take more time than I have right now. So to some degree this is assumptions, though generalized.

* 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.

Gotta admit, I was expecting some hiring/Social biases topic.

This was quite interesting though. Surprised to see it work so well on a real example.

I have the Framework 12".

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.

In my university times I wrote a library (to help with some homework we gave students) that calculated the CRC32 for ethernet.

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...

> Which worked well unless compiled with `strict-aliasing` gcc optimizations enabled

I can't imagine enabling this by default instead of opting in with __restrict or equivalent. Just so many things that could go wrong if every little piece of code was not written with aliasing in mind.

The GCC flag is `-fno-strict-aliasing`, unless there is one I'm unaware of, which tells the compiler to essentially assume code might make aliasing mistakes.

> Just so many things that could go wrong if every little piece of code was not written with aliasing in mind.

You should always be writing "with aliasing in mind". It is a rule of the language, which specifies the "strict aliasing" that flag refers to, and it's UB to alias in ways which are not allowed. (Some aliasing is permitted by C. It's mostly type-punning that isn't.)

For computing the packet checksum, I'm not sure how you'd manage to run afoul of the strict-aliasing rule (you're just iterating over an array of octets … right?), but C is one of those "assume nothing" languages…

I think you are talking about colocation, which is slightly different than the `jj git push` `jj git fetch` type commands.

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).

It's the third attempt of building the mono repo.

But not the 3rd mono repo on the same technology to avoid some scaling limit.

Crypto wise, fips is outdated but not horrible.

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.

FIPS-140 allowed encryption using 3DES up until Jan 1 2024, and allowed certification of modules containing SHA-1 through the end of 2025. There is some transition-timeline nuance involved, but those examples are in general pretty horrible from a security perspective.

I love fastmail, but I really wish they had servers close to me.

The high ping kills the throughput on davfs and makes their website hosting a pain to update :(

Where abouts are you located?

Smack center of Europe (southern Germany) Got >100ms pings.

Heh I’m sorry to hear that. The whole internet is that slow for us here in Australia.

I'm aware. I'm worried we'll get an Aussie customer at work and I have to fix their access to our systems...

Granted, we already have US/EU/Asia as distinct regions. AUS would just make fail over even worse.