filleokus

> Will all these GPUs be used for inference once a SOTA model's training checkpoint/batch is done?

I have no real data to back this up, but that has always been my assumption.

Claude says that K3 can be assumed to have required 10-100M GPU hours. If you have 100k GPUs that would mean like 6 weeks of training. 100k GPU's can serve 3-30 trillion tokens of K3 per day. Google apparently serves ≈100 trillion per day [0].

The big labs probably want to have capacity to fairly quickly train / post train different SOTA models continuously + being able to serve peak inference demand in valuable markets (US daytime?).

[0]: https://blog.google/innovation-and-ai/sundar-pichai-io-2026

This must at least partly be region-dependent right?

In the darker northern parts of Europe, the German transition to renewable haven't really been a cost-saving success story (right?).

From my (very) casual Swedish vantage point, the wind build out here was a very government subsided race to zero marginal prices that barely helped anything?

One trivial reason might be the size of the artefacts / hardware requirements? Kimi K3 is ≈ 1.5 TB and requires multi million dollar hardware to run. Compared to e.g game development, I'm guessing that it's not like a bunch of people at Anthropic/OpenAI have the models running "locally".

It's easier to protect a power substation from being stolen then a Rolex watch

I understand "ricing" to mean customising the appearance of a Linux machine, see e.g https://old.reddit.com/r/unixporn/top/?sort=top&t=month (SFW). So in this case I assume the UI has a cat theme or cat icons.

I think the etymology is from "rice burner" cars [0]:

> Riced out is an adjective denigrating a badly customized sports car, "usually with oversized or ill-matched exterior appointments".

[0]: https://en.wikipedia.org/wiki/Rice_burner

If you want to actually enforce age restrictions that can be checked via some kind of digital identity I don't see how we can avoid the "trusted" hardware requirement.

The key material must be DRM'ed, especially if some ZKP solution is used.

Otherwise all underage kids would download the cool older brothers private key and load it into their GNU Taler client, buy wine and be gateway'ed into heavier Stallmanisms. Before soon EMacs would be all the rage in highschool.

(Of course we can argue the bigger points, if X should require age checks, or if this even should be done digitally etc. But there's a reason why we don't allow the physical equivalent of self-signed keys for physical ID's, they're not trustworthy)

Either me or you are misunderstanding the situation. A comment from the GP link: https://news.ycombinator.com/item?id=47633867

> This is slightly different from what OpenCode was banned from doing; they were a separate harness grabbing a user’s Claude Code session and pretending to be Claude Code.

> OpenClaw was still using Claude Code as the harness (via claude -p)[0]. I understand why Anthropic is doing this (and they’ve made it clear that building products around claude -p is disallowed) but I fear Conductor will be next.

But... Even when running it in mode 2 ("claude -p") they at certain points tried to detect OpenClaw-usage based prompts made, and blocked them [0]. Now OpenClaw says that Antrophic sanctions this as allowable again.

I agree with GP that this is hard to take seriously.

[0]: https://x.com/steipete/status/2040811558427648357

Neat! Pricing wise it might not always make sense though to use the commercial blob storages, especially for solo usage.

1 TB is roughly 20-30 USD per month at AWS/GCP only in storage, plus traffic and operations. R2 is slightly cheaper and includes traffic.

Compared to e.g a Google AI plan where you get 5 TB storage for the same price (25 USD/month) + Gemini Pro thrown in.

Totally agree.

Also, considering how prevalent TPM/Secure Enclaves are on modern devices, I would guess most package maintainers already have hardware capable of generating/using signing keys that never leave hardware.

I think it is mostly a devex/workflow question.

Considering the recent ci/cd-pipeline compromises, I think it would make sense to make a two phase commit process required for popular packages. Build and upload to the registry from a pipeline, but require a signature from a hardware resident key before making the package available.

I suspect nradov argues that this type of geofencing + allow-listing is not typically what people mean when they talk about "export control", which I agree with.

And while geofencing + allow-listing for sure provide value in e.g the Ukrainian conflict, it's a weak protection compared to goods that are actually under strict export control (e.g ITAR), and will always have to be done after the fact. Russia could for example put Starlink on drones launched from the Baltic Ocean targeting Poland or whatever.

Someone was using Xray, proxying to my employer, and it was detected in our attack surface management tool (Censys). I had some quite stressful few minutes before I realised what was going on, "how the hell have our TLS cert leaked to some random VPS hoster in Vietnam!?".

Thankfully for my blood pressure, whoever had set it up had left some kind of management portal accessible on a random high port number and it contained some strings which led me back to the Xray project.

Yes!

Any many CRDT implantations have already solved this for the styled text domain (e.g bold and cursive can be additive but color not etc).

But something user definable would be really useful

I agree, this seems like straight up bad design from a security perspective.

But at the same time, me as a customer of Github, would prefer if Github made it harder for vendors like CodeRabbit to make misstakes like this.

If you have an app with access to more than 1M repos, it would make sense for Github to require a short lived token to access a given repository and only allow the "master" private key to update the app info or whatever.

And/or maybe design mechanisms that only allow minting of these tokens for the repo whenever a certain action is run (i.e not arbitrarily).

But at the end of the day, yes, it's impossible for Github to both allow users to grant full access to whatever app and at the same time ensure stuff like this doesn't happen.

Spivak is saying that the DNS method is superior (i.e you are agreeing - and I do too).

One reason I can think of for HTTP-01 / TLS-ALPN-01 is on-demand issuance, issuing the certificate when you get the request. Which might seem insane (and kinda is), but can be useful for e.g crazy web-migration projects. If you have an enormous, deeply levelled, domain sprawl that are almost never used but you need it up for some reason it can be quite handy.

(Another reason, soon, is that HTTP-01 will be able to issue certs for IP addresses: https://letsencrypt.org/2025/07/01/issuing-our-first-ip-addr...)

I ride rental scooters almost 10k minutes per year and would really like to get my hands on my own ride data to plug it into something like this (or simpler) to find the optimal routes for my regular trips.

Google Maps (or others) works good to find a resonable route, but I can do better on my own. One-way streets where bikes are allowed to go do opposite way is sometimes missing, short desire paths connecting bike ways, crossings where it's safe to do an (illegal) right-on-red etc.

Tried a GDPR data claim from Voi but got nothing back :( But I hope the data is somehow available for urban planners, think it would be a great source of truth to use in tools like this.

I guess it depends a lot on your situation, but for OP's method to be effective you need to out-compete other breeding grounds in not only your backyard but also X feet/meters away (whatever distance mosquitoes typically fly to "hunt").

If there's a nice shallow pond on the property line 100 feet from your porch (or water filled tires at the sloppy neighbour or whatever it might be), I seriously doubt the efficacy of the method in the article.

This thing would lure in any mosquitoes (and unfortunately other things, as per sibling comment) that fly in your backyard, wherever they come from.

For electricity: That also of course depends, but around here it's not uncommon to have an outlet on the outside of some garage or outbuilding or something. The product I linked have a 50 feet cord as well. The fan noise has not been noticeable at all when I've seen it.

Many people with mosquito issues around here (Sweden) uses something like https://www.clasohlson.com/se/Mosquito-Magnet/p/31-7190 which burns propane to produce Co2 to lure in mosquitoes and then sucks them in with a fan towards a metal grid to zap them with electricity.

Non-poisonous and from what I've heard fairly effective. Not sure if these exists in the US?

I've been occasionally using Microsoft's RDP Client [0] on my iPhone with external keyboard + mouse with a usb-c cable into my external monitor (with a Logitech RF dongle connected to the back of it).

It worked okay, the mouse support is somewhat of a hack, but keyboard works awesome.

The biggest annoyance was actually getting RDP to work satisfactory on a linux box with no external monitor plugged in to it (hetzner box).

I thought someone would have created an app to run browser on the external screen in full resolution, so I could skip RDP and use vscode server via the browser. But the only option seems to be infinitex2p which is not available in the EU :(.

[0]: Which in typical Microsoft idiotic fashion semi recently got renamed to "Windows app"... [1]: https://x.com/infinitex2p

Allianz have more than 150k employees with offices in 50+ countries. Not all of them need access to the CRM of course, but I think going back to on-prem is just asking for different kind of trouble.

We don't have any details now, but I wouldn't be surprised if the cloud-based CRM provider didn't have a very technical interesting weakness, but rather that some kind of social engineeringy method was used.

If global companies like this instead had stuff running on-prem all around the world the likelihood of more technical vulnerabilities seems MORE likely to me.

(Air gapping is of course possible, but in my experience, outside of the most security sensitive areas the downsides are simply not acceptable. Or the "air gapping" is just the old "hard shell" / permitter based access-model...)

> It’s pretty clear if you check github that Azure’s services and documentation are written by distributed teams with little coordination.

I've come to the same conclusion after dealing (and reporting) jankyness in both the Azure (ARM) API and especially the CLI. [0] is a nice issue I look at every once in a while. I think an installed az cli is now 700 MB+ of Python code and different bundled python versions...

[0]: https://github.com/Azure/azure-cli/issues/7387

As mentioned in the thread and expanded on the blog [0] moxie is also against the whole idea of federation and multiple clients.

I think my perception has changed in the last ≈ 10 years, to be more leaning in moxie's direction. It's hard enough to design something secure and usable, having to try and support all different implementations under the sun makes most federated approaches never reach any mass adoption.

Even though it's not a one-to-one analog I also think e.g the lack of crypto agility in Wireshark was a very good decision, the same with QUIC having explicit anti-ossification (e.g encrypted headers). Giving enterprise middle boxes the chance to meddle in things is just setting things to hurt for everyone else.

https://signal.org/blog/the-ecosystem-is-moving/

Something similar again is my little tool hemlis [0]

It uses Shamir's secret sharing algorithm to generate shares where the private key is split in n shares with k needed to reconstruct it. The bytes are encoded as word on a PDF (either 'burnt in' or written manually with pen to minimise the risk of storing them on printers etc).

That way you can spread the risk of loosing the physical key, while still maintaining some assurance that e.g your friends can run away with the key (or be compelled to hand it over to some threat actor).

[0]: https://github.com/filleokus/hemlis

Looks cool! In the short demo [0] they mention "within a few hundred milliseconds" as VM boot time (I assume?). I wonder how much tweaking they had to do, because this is using the Virtualization.framework, which has been around a while and used by Docker dekstop / Colima / UTM (as an option).

I wonder what the memory overhead is, especially if running multiple containers - as that would spin up multiple VM's.

[0]: https://developer.apple.com/videos/play/wwdc2025/346 10:10 and forwards

> Surprised to see no discussion of other data structures like dicts/maps, or arrays of arbitrary type. Hopefully they'd be a straightforward extension. IME, apps need collaborative data structures more often than they need pure collaborative text editing.

Totally agree. I guess an array of "atomic" objects, where the properties of the objects can't be changed can be done just by replacing the string with your own type. Changes inside of the object is probably trickier, but maybe it's just about efficiently storing/traversing the tree?

I've also always thoguth it should be possible to create something where the consumer of the helper library (per OP terminology) can hook in their own lightweight "semantic model" logic, to prevent/manage invalid states. A todo item can't both have isDone: true and state: inProgress at the same time. Similar to rich text formatting semantics mentioned in the linked article.

Every year or so I've been toying with the idea of a thin client dev environment. Smallest possible device that can run Linux (or a RDP client) and support being plugged in to a single USB-C dock cable (display, usb for keyboard/mouse and power).

Maybe this is the answer? Even though I don't need the screen, the footprint of a smartphone is smaller than almost all SBC supporting the above requirements.

I haven't seen any hint that the Critical Alerts entitlement would use any special infra compared to regular push notifications.

It's just metadata in the notification body indicating to the device to ignore silent mode etc.

It's e.g used by Pagerduty [0]. It's just a way to override notification settings.

The software for the systems you mention have this entitlement (or some equivalent), but are otherwise completely unrelated to this.

[0]: https://support.pagerduty.com/main/docs/mobile-app-settings#...

Agreed, and I would argue that it's even worse on the browser side. We have Chrome and Safari on iOS, the rest is essentially irrelevant. With regards to web standards, Edge is just another Chrome-reskin. When Apple sooner or later looses the WebKit monopoly on iOS, it will all be Chrome...

My "fear" has always been that Meta/Alphabet would slowly but surely migrate their apps over to their own third-party App Store to get past the pesky IDFA limitations[0] and other tracking hurdles.

So far nothing seems to indicate that it's happening. The question is if it's due to Apple's "measures" or just because it is not worthwhile for Meta/Alphabet. I think it's a combination of. But if it was as easy to "side-load" an app on iOS as on macOS - per your suggestion, I'm confident Meta would have done the switch in a heartbeat.

Just imagine if Apple provided nice API's for auto-updating, essentially no limitations on what binaries can be attested, API's/mechanisms for easy migration between AppStore apps and side loaded ones, no scary screens etc. Essentially implementing the DMA to the fullest extent, really honouring the intent of the law. Why wouldn't all the mega apps just move over? And what consequences would it have?

I think it would be awesome to e.g lift the JIT blocking and allow more strange niche things in alternative app stores. But getting all regular people on a wild-west third party app stores for the (ad financed) apps the use every day is just begging for a huge _actual_ loss in privacy.

[0]: https://en.wikipedia.org/wiki/Identifier_for_Advertisers#App...

Hmm. I'm not a WebRTC pro but looked into it recently for a hobby project and felt that the typical WebRTC TURN implementation still leaves the TURN server in a quite trusted position. My rough understanding:

- (1) Each client generates a key pair

- (2) The fingerprint of the public key is part of the SDP message each client generates

- (3) The SDP message is somehow exchanged between the clients, out of band, and the session is started. The client's verify the remote peer using the public key from the SDP message.

The problem is that it's not really feasible in most circumstances to exchange the full SDP message out of band, so instead the service provide some mechanism to map a shorter ID (typically in a URL) to a centrally stored copy of the SDP. I think this might be where it happens for filepizza [0].

This means that a malicious file sharing operator, being in control of both the TURN service and the out-of-band signalling mechanism, could just MITM the DTLS connection and snoop on all the data going by. The peer's think they have each others public keys but they just have two keys owned by the server.

[0]: https://github.com/kern/filepizza/blob/main/src/channel.ts

Yeah sorry, I'm too focused on backend services.