eqvinox

Who other than nixOS has this problem? Feels like a nixOS thing to me, which I'm not going to complicate my applications for. All the orchestration tools have something like a vault, don't they?

Happy to be shown wrong though.

You can put the "< <( foo )" before the "while" btw, for pipe-like ordering of things. All redirections can be anywhere on the command line.

3 reasons against that:

* in a lot of cases the performance just doesn't matter

* xargs gets you the spaces in filenames landmine

* some commands don't even support multiple target filename arguments

For scripts in long term use, yeah, sure, figure out xargs maybe. Any other situation with a "| while read" solution, especially on an interactive session, is an oddball and simplicity wins.

bash vs. POSIX sh (or some other shells)

zsh should be bash compatible on this AFAIR

Not sure I see the point of this. Remembering a bunch of options on one tool is no better than a bunch of tools/constructs? Especially if the latter are useful elsewhere. And it can't be used for scripts unless you start shipping it alongside, which… nah.

Just go with

  foo | while read X; do bar "$X"; done

The language is primarily used by Rotonda, the composable, programmable BGP routing engine.

Not odd to have those data types at all…

This seems to be largely devops stuff, not developer. (Or plain ops.)

We also received a license from Bluesky for the atproto trademark.

Is that license irrevocable/permanent from their side?

(It really needs to be, except for clauses against misconduct from your side.)

Your diagram at the top of that explainer doesn't include the various Mastodon (not sure if instance<->reader is ActivityPub) client apps, but does include ATProto/Bluesky client apps. Without that, it seems rather incomplete and I don't feel like so can take away much from it?

If it's no issue, why not put a "note: I work for bluesky" on your posts?

If that works for you, great!

Kubernetes is Too Hard. I built a system that I didn't actually know how to maintain without the time or energy necessary to dig myself out of trouble.

Couldn't agree more. Unless your homelab's point is to learn Kubernetes, just keep it simple. Proxmox sounds good, or just QEMU, libvirt, lxc, Docker, podman, whatever. Install packages, not containers where possible. Shell scripts are fine where needed. If it works for you, that's it, end of discussion, don't spend time on "pretty" if it's not the thing you want to get into / enjoy / learn.

(My "thing" is networking, I can assure you my homenet is beautiful. Couldn't give a rat's ass how & where my paperless is running tho. It runs. Done.)

Cool people use ActivityPub.

Single vendor owned & controlled standards always turn out badly, just a question when.

So, does X11 have lower latency than Wayland?

Yes, but nowhere near enough to explain why Wayland is generally perceived as much worse than X11.

Personally speaking: Wayland has massive stutters when the system is under load, most notably on the mouse pointer. X11 doesn't.

Wow. Good thing I sent back my Samsung health watch after discovering some of the fancy features were locked to having a Samsung smartphone to go with it.

Shameful business conduct.

The sad part: strtol(s, ..., 0) would've handled hex input automatically...

Leap smearing is amazing exactly until the moment you need to know whether you're leap smearing (because your seconds are 1.0000116s long, or the reverse). That instant, it turns from amazing into the worst godawful mess you can imagine.

Leap seconds can be stored and communicated, if you need it you can do the work and get it. Leap smearing, you're shit out of luck, especially if you're a developer and need to deal with systems operated by others.

If you're sure you'll never cross that moment and need to know you're in a smear, go ahead, it's great. Otherwise test yo' stuff with leap seconds and get bugs reported & fixed.

"fully ignorant" might not have been the best wording there...

- clarification: "fully ignorant" from a human perspective, using dates and times. UNIX time lines up with those.

I'd figured that UNIX time just counts actual seconds

It doesn't. UNIX time is 1:1 with what your clock reads, you can convert between 2026-07-10 00:12:25 UTC and 1783642345 by simple math (note how the last digit is the same; but the leap second offset is 37s, that wouldn't align. The TAI timestamp for the same moment in time is 1783642382.)

and that leap seconds and similar calendar shenanigans would be a problem of mapping epoch to the correct date, so that if normally epoch X maps to date D then both epoch X and X+1 map to date D.

It's the other way around, if you need to get the exact seconds between two UNIX timestamps (or calendar date/time), you need to check if there were any leap second changes between the two.

Counting actual seconds is TAI [https://en.wikipedia.org/wiki/International_Atomic_Time], that one is really just "number of Caesium hyperfine transitions since X", and now the mapping to a calendar date/time for display is a bit involved.

I think for the stretch of time where a leap second is smeared, the epoch second would drift by a tiny fraction for each second or etc? So you'd have some chunk of UTC time where each second lasts something like 1.0005 epoch seconds, maybe?

Yes, 1.0000116s (or 0.9999884s), and to be clear it was never intended like that. It got started after a bunch of bugs in leap second handling caused issues & some people thought it would be better to just stretch/compress time for a period around leap seconds, for docs refer to e.g.: https://developers.google.com/time/smear

Personally speaking - it's a great way of just pushing the problem around, further complicating an already complex situation. 11.6µs is very measurable on a modern system.

This would make converting from unix time to UTC need extra arbitrary handling for display, at least.

Except you need to know that leap smearing has been applied… which of course noone records. Most systems can't even signal it, much less store. If you need that level of precision, you better make sure none of your systems uses it or you're just screwed.

The really annoying part is that "leap smearing" (where people decided to just mush the leap second across about day) has made CLOCK_MONOTONIC unclear in this regard, since some leap smearing approaches affect that as well. Which destroyed any assumption a developer could make about CLOCK_MONOTONIC, since you won't know if leap smearing is in use :(.

(And depending on the leap smearing implementation, it also smears CLOCK_TAI, jumps it to opposite polarity at the actual time of leap second, and then smears it again. The leap smearing people really made a mess of this.)

From a correctness perspective, the only good choice is to go all-in on TAI.

[Ed./P.S.:] "just ignore leap seconds" - that's going all-in on TAI. At this point it's probably easier to redefine UNIX timestamps as TAI based after 2035 ("abolishing leap seconds"), and introduce a new CLOCK_SOLAR_EARTH that accumulates leap seconds and can be used if/where necessary. The main issue is to create a proper delineation between the two clocks, which we just don't have at this point. Way too many systems where it's just not clear what they use.

And note that leap seconds are earth specific too. You'll have entirely different requirements on e.g. Mars.

UNIX timestamps are fully ignorant of leap seconds, i.e. pretends they don't exist. That means there can be physical seconds of time that cannot be referenced with a UNIX timestamp (when a leap second is inserted) as well as UNIX timestamps for seconds that don't exist (when a leap second is deleted).

Curious. Most places needing SSO also have legal retention requirements, making E2E a hard nonstarter. And most E2E users wouldn't want to rely on a SSO that could likely revoke their keys. What's your environment?

What I said was "It makes much more sense to argue there is no consensus […] can be argued even in a "60:40" situation regardless of direction".

Not "there's a 60/40 split, therefore there's no consensus".

Can be argued even in. That's a statement of allowance, not sufficiency. And I was speaking in the context of contrasting against a vote. You can't argue with a vote's tally.

Anyone know if "-cpu ${CPU},vmx=off,svm=off" in QEMU is a safe workaround for this?

(To disable nested virtualization on a per-VM basis. Only against exploitation from within that specific VM, obviously does nothing against users with access to /dev/kvm on the host.)

A single sentence of encouragement is all that is on offer from this MLKEM RFC.

The draft only specifies the MLKEM binding into TLS; it'd be out of scope for it to go into detail on implementation considerations for MLKEM. Those would belong in or adjacent to FIPS 203 (the actual MLKEM specification).

It doesn't even have the lightweight "Security Considerations" section which RFC8032 for EdDSA provided.[3]

It's actually RFC8032 that this criticism would apply to, since it is actually specifying EdDSA, not just referencing it externally.

I can't help but note two things:

* the IETF's approach predates 15 U.S.C. §4302 by more than a decade

* every single case example cited is US-American scoped¹ SDOs: American Society of Mechanical Engineers, National Fire Protection Association, American National Standards Institute²

¹ NB scope ≠ legal domicile. The IETF's legal status is… complicated… but does have US dependencies. Its scope is world-wide though. Not so for any of the mentioned entities, even if…

² …ANSI is a borderline case since it is the constituent ISO member. But still, it's the US entity.

I'm not trying to make a legal argument here, but… I'll say he shouldn't be trying to do that either. Most mathematicians and CS majors make very poor lawyers in any case, and often enough without any awareness of it.

I would maintain TLS the same way WireGuard and OpenSSH are maintained. Both have superior track records. I'm generally an opponent of all security and (especially) cryptographic standards bodies.

Hmm. This doesn't entirely connect for me… WireGuard and OpenSSH are first and foremost implementations. Are you implying people should follow a "primary" implementation? Does WireGuard even have a protocol specification? (searches - ah, yes, it does. I do know there have been a very number of "further" implementations [e.g. on FreeBSD], though I'm not sure if they're derivative or clean-room.)

But then isn't this just replacing IETF processes with whatever community or corporate processes those projects have? Wouldn't that just be "get shit into {the Linux kernel,OpenBSD}"? They've gotten better but both of those communities have their shortcomings. (For Linux, it's not the social interactions anymore, at this point it's the significant corporate interests.)

Ah I see what you were trying to say. It read to me (with "He's a cryptographer. You're describing cryptographers.") like you were dismissing that knowledge about implementing and shipping cryptographic libraries is a relevant expertise (or that every cryptographer would have that, which they absolutely don't.) But, yeah, he's one among a whole bunch of experts in some of these fields and certainly shouldn't be given special weight just due to his name recognition.

…information RFC? He can’t stop that, right?

Informational RFCs still need to pass through the IETF consensus process, changing the intended status isn't a procedural bypass. However, the authors can just publish it elsewhere, it makes no difference at all for the codepoint allocations. Only distinction is that it doesn't get the somewhat intangible (but existent) "RFC sheen".