2,647 karma · joined March 26, 2010
wzdd.hn@lardcave.net https://nfd.world
Then again, I just caught Claude writing setTransparent(!opaque == false), opaque being a bool, on a purely vibecoded project. Which was pretty impressive. ("• You're right, that's nonsense.")
I've noticed Claude is specifically fond of three-element lists consisting of (standard example of class), (standard example of class), (nonstandard example of class). It's interesting because Claude often gets the nonstandard example more or less incorrect -- in this case, because gristle isn't an example of a high-fat-content food.
This initial honeymoon phase happens whenever someone starts using a new tool, fades after weeks or months, and and is not the time to evaluate the deleterious effects of the tool.
They've taken the connectome, which is a map of how neurons in the brain are connected to each other, and then created a fly brain using artificial spiking neurons connected together using that same connectome.
So the neurons are not remotely accurate. The interesting point they're making is that even with these simplified neurons they still see plausible behaviours (i.e. simulate the presence of sugar by stimulating a gustatory neuron -> neurons associated with lowering the proboscis for feeding are triggered). So they make the case that a lot of information is encoded simply in the connectome.
The body isn't connected up to the brain in the way we'd expect. "Input" comes from a completely separate neural network which they've trained to simulate appropriate CNS neurons, and output is looking at "descending" (efferent I guess) neurons in a very basic way. It's not completely playing an animation, but the level of connectivity is very low dimensional. It's not clear how much control they have, but for example I imagine they have a spiking threshold for the proboscis below which it's lowered and above which it's raised, which is sort of like you being able to stick your tongue completely out or pull it completely in but nothing else.
So it's not especially bioplausible. The most interesting part is that leaky-integrate-and-fire connectome-based brain model which they're using, even though it is also very limited (for example, it doesn't learn).
Demo looks very cool though. Much credit for being so explicit about what's going on in it in that post. And I was immediately filled with ideas about what they could do next to improve it, which to me is a signal of good research.
Classical is a harder (or at least different) problem and it's why specialist apps like Apple Music Classical exist.
> In a simplified form, retailers are responsible for warranty claims and must replace or refund the defective item
The choice is at the retailer’s discretion and the refund is obviously of the purchase price.
This is a non story. The retailer is acting lawfully. The only curiosity is that normally it is in a retailer’s best interests to replace goods, but in these circumstances they are better off refunding them.
So the meaningful difference is that unlike a test you don't know what it's looking for and you don't know if it's ranking you objectively.
"A new lawsuit doesn’t just revisit the $40 billion Terra-Luna meltdown; it questions whether..." -- the purpose of a lawsuit is to question something (by making an allegation), you don't sue someone to "revisit".
"Ten minutes is not a coincidence. It is a trade." So is an hour, or thirty seconds, or...?
"Not just as bystanders, but as alleged participants" -- the "just" doesn't make sense; participants aren't bystanders.
Of the list, only "It reads less like a rescue offer" and "These are not isolated; they are part of Snyder’s broader efforts..." makes any sense in context.
While adding pause / resume functionality certainly solves the problem, it does seem like not the best possible solution. Firstly, it's a rather far-reaching change. Prior to this work TTY updates always succeeded, but now the kernel has to be aware that they can fail just in case userspace is talking to a DisplayLink (which the article acknowledges are increasingly rare)? We have a new type of wait queue (or wait type) for "waiting on TTY operation"?
Secondly, the parallel with serial (heh) links isn't great because with a serial link you have no idea what the other side is doing with the data, so you can't make any assumptions. But for a TTY you know its dimensions and furthermore you're the one doing the terminal emulation, so a) there's a bound (and quite a small one) on the amount of data you need to buffer and b) you know exactly how the data is going to be presented because you're the one doing the presentation. So there is an opportunity here to be more efficient than just forcing userspace to halt. A good analogy would be an X terminal emulator which faithfully draws every line of text, even if it's scrolling past hundreds of times faster than a human could read, versus one which updates its buffer as fast as possible, even if it's only redrawing at the display refresh rate -- the latter performs much better because it only shows the data that ultimately matters!
In particular, non-DisplayLink TTY drivers behave more like that performant X terminal emulator, because they're writing directly to graphics memory. Treating DisplayLink like a serial terminal makes it slower than it should be in the event of a lot of data being written; it is doing all its updates, even if they are immediately overwritten.
A more performant approach would be to store two text buffers, one for the current state (ie what DisplayLink is dipslaying) and another for the desired state. Diff the two to determine what to update when the DisplayLink is ready again.
It seems like this is basically what happens in graphics mode anyway, with dirty rects (which would just become larger dirty rects basically until the DL is ready for more commands) -- i.e. you have to buffer anyway for efficient blit / readback etc.
If diffing textmode feels too much like policy, make a user-space component. Or do what graphics mode does and use just one buffer with a bounded set of dirty rects.
In other words, it seems like a solution which came from "we are deep in the bowels of the device driver, what is simplest possible thing we can do?" and there's nothing wrong with that, but it does end up moving complexity elsewhere somewhat.
And it looks bad. The streetlamps on the right are way too close together and the building on the left looks like a prison or something out of Dickens.
Nobody actually productively commenting in the thread thinks it's a conspiracy theory and everyone acknowledges that the Apple hardware is off-spec. It would be nice to see Android add this workaround.