Ah what a world we have built...

"In addition to enlisting the user’s TV box in ad fraud networks, these off-brand streaming devices almost universally come with residential proxy software pre-installed. This software rents the user’s Internet address out to anonymous paying customers, who run the gamut from aggressive content scraping firms to ticket scalpers and outright cybercriminals.

What’s more, because these generic (and generally dirt cheap) TV boxes are all horribly insecure by default and bereft of any kind of authentication, installing one on your home or office network only invites further mischief. In January, the proxy tracking service Synthient documented how multiple botnets had rapidly enslaved millions of TV boxes using a complex interplay of security vulnerabilities in both the residential proxy software and the streaming devices themselves."

https://krebsonsecurity.com/2026/07/read-this-before-you-buy-that-tv-streaming-stick/

GrapheneOS has a "duress code" feature that will wipe the device if it is used in an attempt to unlock it. A potentially useful feature, but the US is now trying to prosecute somebody for having given the duress code to an officer demanding the unlocking of his phone.

https://www.theguardian.com/us-news/2026/jul/23/cop-city-protester-phone

"The home appliance giant LG Electronics USA said this week it plans to suspend any apps built for its smart TVs that turn one’s television into an always-on residential proxy node. The move comes less than a month after researchers found that more than 42 percent of games and other apps available for download on LG’s webOS store allow unknown third-parties to route their Internet traffic through a user’s TV."

— Krebs https://krebsonsecurity.com/2026/07/lg-to-ban-residential-proxies-from-smart-tv-apps/

Better late than never, I guess.

I've been spending rather too much of my time reading the depressing threads on LLM use in the kernel. But I thought that this contribution from Lyude Paul worth the investment.

"For many people who need their jobs, guidelines around acceptable use of these tools beyond "a person needs to own the the code" may end up being the only thing allowing employees to be responsible with their contributions without repercussion from employers."

https://lwn.net/ml/all/[email protected]

The @nprofile1q... web site is currently under the most intense scraper attack I have seen yet. 1.3M unique IP addresses within the last couple of hours, and it's not done yet. The work we have done on defenses appears to be paying off, though; the server is holding up reasonably well — so far.

...just in case anybody wonders why I have a rather dim view of the whole AI industry...

So the Linux Foundation and a wide range of companies have launched "Akrites" to deal with the vulnerability deluge:

https://akrites.org/letter/

I do wonder though ... "confidentiality" is at the core of this whole thing - keeping vulnerabilities secret until fixes are deployed. When you have LLMs discovering the vulnerabilities, though, they are not secret. Trying to treat them as if they were might well just slow down the process of getting fixes out and make things worse. Embargoes and confidentiality seem like an attempt to perpetuate the last decade's approaches beyond their time.

Today I got an email from a local farm saying that they will not be doing a community supported agriculture (CSA) program this year because they don't think there will be enough water to grow food.

Need I say this is not a good sign?

As the number of LLM-generated patches in my inbox increases, I am starting to experience the sort of maintainer stress that has long been predicted. But there's another aspect of this that has recently crossed my mind.

Just over a week ago, a new personality showed up with a whole pile of machine-generated patches claiming to fill in our memory-management documentation. A few reviewers had some sharp questions, the response to which has been ... silence. This person doesn't seem to have cared enough about that work to make an effort to get past the initial resistance.

Once upon a time, somebody who had produced many pages of MM documentation would be invested enough in that work to make at least a minimal attempt to defend it.

Kernel developers often worry that a patch submitter will not stick around to maintain the code they are trying to push upstream. Part of the gauntlet of getting kernel patches accepted can be seen as a sort of "are you serious?" test.

When somebody submits a big pile of machine-generated code, though, will they be *able* to maintain it? And will they be sufficiently invested in this code, which they didn't write and probably don't understand, to stick around and fix the inevitable problems that will arise? I rather fear not, and that does not bode well for the long-term maintainability of our software.

"This winter wasn’t just a bit warm or slightly unusual. It was a complete failure of the cold‑season that the West depends on, and the consequences will extend far beyond a lack of snow along Colorado’s Continental Divide. When winter fails this profoundly, the disruption radiates outward through every system that relies on the steady rhythm of cold, snow, and gradual melt. Water managers lose the natural reservoir that mountain snowpack is supposed to provide, leaving cities, farms, and entire states in the Colorado River Basin facing increasingly uncomfortable decisions about how to stretch a shrinking supply. Reservoirs that should be quietly refilling through winter will instead stumble into this spring underfilled, offering far less protection against the triple punch of summer heat, irrigation demand, and wildfire suppression. Millions of Americans who depend on the Colorado River will feel the consequences of this winter long after our snow-starved peaks fade from the headlines."

https://bouldercast.com/a-complete-failure-of-winter-across-the-west-and-what-it-means-for-the-rest-of-2026/

*sigh*

One of those little details that, probably, only I care about ... a year ago, when dealing with AI scraper problems, I observed that almost all of the traffic came from IPv4 addresses — millions of them. Use of IPv6 was a pretty strong indication that there was a human involved.

Now, when we get a heavy attack wave, it is strongly dominated by IPv6 addresses; the bots seem to actively prefer IPv6.

I wonder if it's because IPv6 addresses are more likely to remain unique through NAT boxes, giving these sleazy people yet more IP addresses to bring down web sites with?

So let's assume, just for the sake of argument, that you were foolish enough to try to make a living by writing high-quality, well-researched, technical articles about Linux and free-software development. I know that's crazy, but bear with me. In such a scenario, how does one succeed in a world increasingly full of stuff like this?

https://www.webpronews.com/linux-7-0-looms-large-inside-the-landmark-kernel-release-that-could-reshape-open-source-computing/

(I'll post no more links to that site, I promise).

These folks appear to take the stuff we humans write, inject a bunch of errors, then slop it out to the world.

If you were to engage in the silly quest described above, you would find that what you do is increasingly buried in the flood of this kind of material. Does anybody have any bright ideas about how one might survive in such an environment?