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.

Silicon wafers are the wrong thing to compare against. The CZT semiconductors are like photodiodes (for other radiation), not what they make the logic out of. It would make more sense to compare with InGaN (for blue LEDs), which plays a similarly specific role in common devices.

These days, the market is more trusting of the statement that better tools and processes require fewer employees to serve the same customers if you call that AI. If you get more of your customers to succeed in using your website or app to do what they need without having a human do anything for them individually, you don't need as many employees doing it. But the market doesn't want to hear that you can cut jobs because your website doesn't suck as much any more, so you say AI and they think you've done something futuristic when you've actually done something practical, and you're vague enough about it that the SEC can't say that you claimed to be doing something you're not.

All of the headline changes go in during a two-week window at the start of the cycle, having been developed previously. Several people write articles during that window about what got merged, so the list is already known when the release actually comes out two months later. (That two-month period is used for testing in more unusual situations and checking for incompatibilities among the set of changes that got merged for the cycle.)

So this article is really reporting that two compact weeks of merge decisions in early October are now officially considered tested and ready, and they wrote the article and people checked it over a while ago now.

The part that's harder to track is ongoing development work, which happens continuously without a set schedule, but it happens in separate trees and only goes into the official tree when it's complete, has been reviewed, and has gone through various testing in systems managed by kernel developers. All of the work described here was done before 6.17 was released, and developed during several releases before that, but it didn't need to affect Linus's tree until he decided it would land in 6.18.

They generally use a primary and standby system, just because it's a lot harder to avoid consistency problems with multiple primaries. This means that you need to direct traffic to the current primary, and redirect it to a standby when necessary, which is fine except that the system you're switching away from and the configuration interface for your DNS provider are both in us-east-1, because everything normally is. That's why they're looking for the ability to make a different region primary specifically during in AWS outage.

There's a typo in the headline. It's supposed to read "Microsoft Forms Superintelligence Team Under AI Chef Suleyman 'To Serve Humanity'".

I use the magsafe on my laptop. I almost always use the laptop in the same place and only charge it there, so it's not getting mixed into my collection and picked back out, and the magsafe is somewhat easier to fumble into place than USB-C. If I was using it long enough somewhere different to need to charge it, I'd grab a USB-C (probably already nearby), rather than collecting the magsafe from where it's set up.

They could include things like special lines at immigration, rather than just visa requirements. Arriving in Amsterdam with an EU passport is much less of a hassle than arriving with a US passport, but they both count the same on this report. Then there's the question of whether you need a permit to stay indefinitely, or just the passport.

The person who made the report is a professional penetration tester. His usual method is to look for anything that could be wrong and then test whether it actually is. What he found is that the AI tools came up with potential issues he hadn't thought of, and they weren't all wrong, so it's a valuable tool to him because he normally runs out of ideas rather than running out of time to test them. He complained about the UI making it hard to go through large lists of reported issues exhaustively, and he only used the suggested fixes to get a better idea of what the issue was supposed to be. So it's clear that the tool's output wouldn't be directly useful to a maintainer, but it does serve a purpose.

I got a third-party cable for my phone that my phone recognizes as being able to charge it faster than the cable that came with the phone could. They should probably warn you that they don't have a cable or charger, in case you're getting a phone because you lost everything and don't have that stuff, but the first-party stuff isn't better these days.