But you couldnt apply security updates because Ubuntu was doen

Mini PCs (NUC-ish form factor) are selling a lot now too, small, quiet, most people don't need expansion over what you can get from eg USB4.

Yeah, the DGX Spark could qualify as a mini PC too. The AMD chip is sold as a laptop chip I believe, but I've mostly seen it in mini PCs. And the Framework Desktop. A brand that probably carries a lot of trust among the kind of tinkerers who would consider buying a barebone motherboard in the first place.

5G barely exists and mostly is the same price as 10Gb. 2.6Gb is taking off and mostly replacing 1Gb, but try to find a 5Gb switch, there really arent any, and most appear to be 10Gb switches with 5Gb PHY in them.

Yes thats one thing Musl libc removes.

If the attacker can control newroot/etc/passwd they _still_ get getpwnam to return whatever userid they want. The solution is to not lookup --userspec=username:group inside the chrooted-space, but from outside.

Also, hi how's things? :)

hi! good, how are you doing?

great. still enjoying the algarve working on my secret projects in the sun.

you able to find a reason to come visit? or am i going to have to come to blighty so we can hang out?

Some S3 APIs have 2FA options for drastic operations (delete for versioned buckets where you probably don't want deletes much) https://docs.aws.amazon.com/AmazonS3/latest/userguide/MultiF...

Codex is pretty good at Rust with x86 and arm intrinsics too, it replaced a bunch of hand written C/assembly code I was using. I will try Qwen and Kimi on this kind of task too.

These are tools for thinking with, so not obsolete.

GP is just trying to convince you that thinking is "rapidly redundant in the LLM age".

(GP here) Its true that we need to be cautious about continuing to exercise our thinking muscles, undoubtedly. Ofc you can do that without using legacy techniques, but each to their own.

Agree (redundant, not obsolete), but there are better tools for the job in terms of the production value gained in terms time and mental energy spent in mastering them. You can certainly think less as tech becomes more powerful in a domain; I wouldn't advise that either.

Yubikey can require touch, and Secretive for Apple Secure enclave can require touch with fingerprint id. Some people disable these, it depends exactly on your use case.

You don’t need Secretive, there is actually Apple native way

I put my ssh keys into the Mac’s TPM and now it asks for a password/touch ID when I use it.

Unfortunately I forget what commands I used

yes, but what's to stop a malicious actor from intercepting a signature request and replacing its own contents in place of the legitimate one. yes you would find out when your push was rejected, but that would be a bit late.

I am writing an s3 server, just checked, have detailed tests for content-length-range. I found that Ceph was the only open source implementation with decent tests, and I ported these as my first stages of implementation, although I have since added a lot more. Notionally rustfs say they use the ceph test suite, but not sure how often and completely, they certainly had big conformance gaps.

Its VC funded https://www.sec.gov/Archives/edgar/data/2076429/000207642925...

Jujutsu is not "VC funded". But some of the developers, including me, work at East River Source Control (I worked on Jujutsu before that, too). The majority of the code in the project doesn't come from us -- or Google, for that matter. We don't allow people to approve patches when the author is from the same company, anyway.

(also at ERSC here, hi Austin!) Heck, I have not had enough bandwidth to do as much upstream work as I initially thought I would when I started there!

that's a company built on top of Jujutsu, not jj itself

If I remember correctly, jj is one guy who works at Google. Which presents a separate worry, which is that one day, when jj gets popular enough, Google will consume it, make it shit, change the name of it every six months and then shut it down.

That hasn't really been the case for a while imo: Martin works at Google and is paid to work on jj (there are also other Google employees who contribute, not sure whether they're paid to). jj is in use (wide use? No idea) alongside Google's internal tool (piper) with which it can interact (and with which it has some features in common) because jj has a pluggable backend architecture.

While I hate to engage in speculation, tell spooky stories, or screech at people about the evil CLA you have to sign in order to contribute, my personal opinion is that if Google were ever to start throwing their weight around, the project would be forked in short order and development would continue as normal – it has momentum, plenty of non-Google contributors, and a community. It's also not a product per se, though as we're about to find out, you can certainly build products on top of it – that probably makes it less likely for its current home to suddenly become proprietorial about it.

(hi Andy!)

Good points. I had a horrible vision of a git -> GitHub -> Microsoft -> GitHub-on-Azure style pipeline but yeah, I think there's enough good people involved around jj that your vision is probably more likely. Also, hi Steph!

jj is not "one guy who works at Google" and the vast majority of submitted code comes from non-Google developers. Even if Google were to stop developing jj (they won't) the project would be healthy and strong.

There's some legal annoyances around e.g. CLA which was a result of being a side project of Google originally. Hopefully we'll move through that in due time. But realistically it's a much larger project at this point and has grown up a lot, it's not Martin's side project anymore.