danielheath

Radiant Star (the new Ann Leckie book, in the “Ancillary Justice” series). Not as good as her earlier books in the series, but very worthwhile if you enjoyed them.

Close enough - if they’re using Claude for anything, the DOD can’t trust that staff didn’t also use it in product development, so they’d have to keep track of everything downstream of that component to ensure it was never used for target selection.

It could also be as simple as "anything tainted by the Claude non-targeting-conditions can't be used in target selection, and we don't want to leak classified information about which components we use in target selection by requiring specific items to be developed without Claude, so we can't allow it anywhere".

Right? Imagine how badly it could go if a disease known to cause brain damage became widespread and was circulating in the population.

If you have pens in the building, and staff need a pen, they will use the pen that is available, even if there’s a sign saying “not for purpose x”. If you want to stop that happening, you need to not have limited pens available to your staff at all.

Open the effects submenu, 81% y-scale, 2% y-offset, papyrus on the left, comic sans on the right.

The two challenges there are firstly - that analog design has been a separate electrical engineering school for most of a century, so there are few who could design it - and secondly - that every single chip will have subtle variations in its computations, necessitating some sort of model finetuning per chip. Possibly the chip could be characterised at the factory, and ship with the characterisation data burned into a controller rom or something, but if that doesn’t pan out the whole thing is likely a non-starter.

If it could be made to work, you could run a fable-grade model in tens of watts.

Arguing in court over whether the details in question were functional or copyright is time-consuming (thus expensive), and risky.

Once it's established that person A has given _any_ details to person B, the upper bound on "expected cost of an effective defense" is dramatically higher.

Functional details can’t be copyrighted, but once you’ve seen a copyrighted implementation, it’s an argument in court over similarity and function.

A clean room implementation by people who haven’t seen the original work means there can be no discussion of copying, which makes it much cheaper and more reliable to fight an infringement claim.

Person A has failed to secure private material, and person B can hardly claim their implementation is “clean room” if they based it on other work.

> what if person a and person b are unrelated and person b found it on their own

That's what's referred to as a "clean room implementation" further up the thread.

However, this specific thread is about the scenario where an employee has inside knowledge and is passing that knowledge on to the implementer.

Legally speaking, a clean room implementation has much better defenses from claims of copyright violation.

> NDAs apply to all of humanity

The NDA doesn't apply to people who haven't signed it, but copyright law does. If you know the material you're receiving is under copyright (eg proprietary source code), and you publish work based on that copyright material, the fact that it's now widely available is not an effective defense against claims of copyright violation.

Person B in this scenario hasn't violated the NDA, but they could be sued for copyright infringement.

"Person A was under NDA, so we got them to pass their knowledge to person B, then had person B do the work - that's clean-room, right?"

Judges, as far as I know, do not generally take kindly to such arguments.

I'm seeing people who _used to be_ like that losing that understanding without realizing it's happening - they have a superficial idea of what the code is doing, enough to feel like they understand it, but the change is apparent when watching them handle something unexpected.

If you're going to put the graphics and NIC into separate VMs, surely the secure screen can be another of those semi-privileged VMs rather than part of dom0

Apps built with a toolkit which ships its own filepicker will immediately attempt to enumerate directories in `/`, `/home`, and probably a few other places.

Apps with a config file will often try to read `~/.config/myapp` and also `~/.myapp/config` and maybe one or two other places.

How many permission prompts will users tolerate?

I did some quick testing with `cjxl --progressive`, different quality levels, and https://google.github.io/attention-center/

A 1536w / 2048h jpg selfie: 244kb

Progressive JXL at quality=70: 151kb

Loaded 7kb of that file: looked okay up to approx 130px wide.

The first 18kb of that file was a suitable thumbnail up to approx 210px wide.

The first 50kb looked okay up to 300px wide.

The first 75kb looked okay up to 600px wide.

Maybe I need to do a lot more testing, but this seems to work alright?

Does that prove you didn't photograph a display showing the digital image?

One particularly interesting (to me, at least) approach using progressive decoding was described by Jake Archibald ( https://jakearchibald.com/2025/present-and-future-of-progres... ).

If browsers extended `srcset` with support for HTTP Range requests, we could use a progressive-encoded jpg (xl or not) file as the source for multiple detail levels.

A device with a small screen would request the first 10kb of the image, while one with a medium screen might fetch 40kb.

The big advantage of that - for sites with many images - is a much better cache hit-rate for a given CDN spend.

Additionally, if you've already fetched a small version of an image and then want to view a bigger version, you've already got partial content downloaded & can fetch only the rest of the file.

Most useful code comment I have encountered read:

“”” After you give up on trying to refactor this code, increment the following line accordingly. HOURS_WASTED_HERE=26 “””

Loneliness is hard. Maybe believing that it was real was the only thing keeping him going.

They may well have used suppressors.

Tyre pollution is significant regardless of fuel source.

Also, promotions can be a different job.

I've seen a few senior developers who weren't great programmers, but could communicate effectively, manage up and down, etc. So long as they were willing to defer to others on harder technical topics, they usually made pretty good team leads when/if promoted.

IMO it's because they don't get burnt out by a lack of results.

After 5-6 consecutive approaches fail, I need a reason to think the next one might work out to stay motivated.

Claude will keep burning credits trying new approaches until something sticks. That's a huge advantage in a field where most of the things you try don't go anywhere.

In many parts of Europe prior to 1970, it was very common for children to be given watered down wine.

Back in the day, my 200mhz Pentium remained just-barely usable while listening to WinAmp, but there was noticeable latency.

It’s bloody difficult to catch someone on one of these if they don’t want to be caught; bikes can take alleyways at some speed, etc.

Excessive xylitol consumption causes digestive problems, yes.

> Is there some limitation that WASM has that JS doesn't?

You need a JS trampoline to call your WASM and make browser primitives available to it, and IIRC calls into browser code incur some extra overhead, but those are pretty manageable.

Additionally: for high level languages, source code is _much_ smaller than compiled binaries. If your initial needs are simple, your users are likely downloading more than 10x as much code.

I suspect partitioned tables would be great for this - with a stored procedure to create partitions on-demand, you could split tasks up by date-range and type, and then drop the old tables once their time-range has passed and their jobs all processed.

Job workers could query the parent table, no need to modify them.