Yeah, and the person who released the information first was operating in an "if I noticed this, doing only as much as I'm doing, surely attackers would also notice" mode. Possibly some patches these days are sufficiently obvious as to their correctness and also effect that they should first become public as a set of stable releases. This was a kind of special case, as CopyFail was the combination of some code doing something strange with one user not being prepared for it, and fixed the user. If there are other users that also aren't prepared, fixing them isn't going to be subtle.

How shadows and reflections move when you're 10 milies from a mostly flat surface a thousand miles across is legitimately hard to analyze for a visual system that evolved on the ground, especially if you throw in small periodic surface orientation variations. Given how complicated it is to explain rare rainbow-related phenomena like sun dogs, it would be surprising if we'd identified and explained everything that can appear when flying above the ocean.

While you're at it, you also need to block installing esp4, esp6, and rxrpc, for, y'know, reasons.

According to the article, they (by way of their cloud provider) had DR backups, which they were able to get restored. But getting offline backups restored takes longer than the SLAs they give their customers and loses some data that hasn't been copied offline yet, which is why they also have backups that are complete and immediately available, using the API key that the attacker -- sorry, AI -- found in a file it wasn't supposed to have access to.

Verizon's 2 Gbps Fios home service doesn't support IPv6, due apparently to them picking hardware for this particular service that doesn't handle it. Their other service does handle it, including slower home Fios, but not that in particular.

It uses VRTX, reportedly. Linux wasn't suitable as a real-time OS when the Hubble was designed, or really even when the Hubble got the 486 installed in 2009.

The LitleLLM packages were comprimosed on Tuesday. The packages compromised today were telnyx 4.87.1 and 4.87.2. It's the same root cause: credentials exposed to a compromised version of Trivy earlier were used to make an unauthorized release of a compromised version of a different package.

Until recently, you could get the text of national weather service guidance by telnet. It was about the right level of protocol to provide plain text to a terminal with enough information to paginate it and enough input to pick an airport code.

That works at some intersections. At others, buildings and echoes make it pretty much impossible to tell if the siren you hear is an emergency vehicle about to cross the intersection in front of you where you have a green light, or there's some emergency somewhere else, which is often true. They could still go through red lights, but not at full speed. With the new system, they find that the light is green for them at every intersection, and they don't have to slow down.

I think what you think of as recipients resenting handouts is commonly misunderstood. People have a basic need to feel like they are doing something worthwhile, which is traditionally fulfilled by them having jobs that pay them an amount that indicates how much other people value the work. Telling people they need handouts, then, indicates that they aren't capable of doing meaningful work. On the other hand, if people see that their work is valuable to people who can't afford to pay them a living wage (for example, daycare providers for retail workers who are parents), they're much more willing for somebody else to provide the money. UBI also helps the perception, in that there's no implication that recipients aren't also capable of getting paid for their work, since it's universal, and that frees people to look for things to do that they personally value but may not have built-in funding.

Of course, none of this helps if no occupations people can do are worthwhile any more because AI just does it better. You still have to worry about a high rate of idleness, even if the people aren't broke, but that's a somewhat different problem.

My favorite bug was when they started using message-signaled interrupts. When enabling MSI, they didn't disable the traditional IRQ, and my machine would keep delivering it. In particular, the network card would do something to toggle the IRQ line whenever a packet came in, but would leave the line triggered when idle. If this persisted for five minutes, the kernel would decide that line was stuck and mask it, but it was shared with my hard drive, whose driver would then never find out that operations had completed. Very odd to debug a computer that would fail if you left it alone too long, and nothing suggested that the network card was using that IRQ once it was configured to use MSI instead.

The fun part was that other people had machines where disabling the IRQ would also disable the MSI, so my fix broke other motherboards, and the PCI standard said something that could be interpreted as requiring either behavior. Fortunately, there was something you could check about the manufacturer to decide what to expect.

Applications which required getting mRNA into particular cells had problems with delivery, unless those cells were in the liver where everything tends to end up eventually. But getting cells in muscles in one arm to present antigens of a respiratory disease turns out to be fine for producing an immune response to the disease when it shows up in the lungs, so delivery isn't an issue for vaccines. This was known at the time of the article, but all the diseases with known proteins that would make good antigens already had approved vaccines, and nobody really wanted to develop a flu vaccine technology that wasn't more effective and just didn't take all summer to grow after settling on a strain. Then COVID showed up, and the ability to produce a vaccine knowing just the antigen and do it fast was suddenly important.

For that matter, this year it would be useful to be able to change the flu vaccine between Thanksgiving and New Years, because they picked the wrong H3N2 in the spring, but we don't have a suitable regulatory framework for approving that change, even though it's easy to make with mRNA.

The decision to do it was made in 2011, and they've been building the parts that will go into it, and they'd already committed to doing the installation at the end of the current operating period, but the schedule for ending that period is "mid-2026", so he gets to be the one who makes that date exact, with people hoping to get one last experiment that doesn't need the upgrade in before they have to wait a long time.

That's what a kernel developer told me when I reported this problem. In particular, they said I had a machine with an nVidia device that was different from all the similar devices they'd seen in not having the second copy engine actually function. They gave me one line of config for my PCI ID, and then it worked perfectly.

They found and fixed the issue immediately upon seeing logs from my machine, but they'd never seen exactly that issue before to know in advance that it was a possibility.

It seems to me that, if you were developing something like this, you'd want to write the encryption and decryption code separately from the non-trivial key management code, so that you can unlock it easily if someone accidentally locks the wrong system. You only make the build that doesn't have an obvious key when you're really going to use it. For that matter, it's probably wise to do your demos with the version with the master key, so that potential affiliates can't attack a real target for the demo. Then you give the version that doesn't make it easy to unlock to paying affiliates who aren't SentinelOne. It's not like they'd need to redesign the whole system to generate a random key and not write it in plaintext anywhere.