No, the problem was the vacuum worked just fine with those IP addresses blocked. It had the maps to his house locally stored and vacuumed just fine.

Except when the company found out it wasn't getting that data from the vacuum, it sent the command to disable the vacuum.

In other words, it's a device that would work fine offline, but the manufacturer put some extra telemetry code in that uploads who knows what to their servers. And when they stopped getting that data, the manufacturer disables the device.

It's not a case where the device needs the cloud to work - it doesn't. If the manufacturer goes belly up tomorrow the vacuum would work just fine with what it has now until something that needs cloud functionality was required.

This is even worse that IoT devices - this is intentionally disabling a device that would work just fine offline simply because you didn't get the marketing data you wanted. In other words, it had a mandatory online component even when it wasn't necessary. Like video game single player modes that require you to be online to play.

Except fad languages don't usually have much community support behind it. Lots of things are being reimplemented in rust to eliminate memory safety bugs. Lots of tools are mature, but likely may have hidden bugs that might be exploited for some untowards purpose.

And it's in the kernel, where some developers have found benefits to not having to worry about tricky memory handling issues especially in complex devices like GPUs where the memory buffer can be allocated by a thread long since gone and forgotten about.

Heck, there's a CVE 7.8 in netfilter because of a use-after-free bug leading to root escalation, All you need is to do is be able to run code locally so while it's not remote exploitable, it can be part of an exploit chain where you break into a vulnerable service and then use it to elevate yourself.

I don't even blame the kernel developers for the bug - memory buffers are just a tricky thing to manage in a kernel where your execution contexts between allocation, usage and deallocation can be completely independent. And it's entirely possible that you might start to use memory before it's fully initialized. Or you're using memory when someone requests it to be deallocated, which can trivially cause a use-after-free.

Unloading kernel drives was a huge source of bugs because of it - if you didn't properly do locking, you could find the rug pulled from under yourself. It made USB fun in the early days because yanking out a USB device could crash the computer simply because the unload code ran while a CPU was still executing code from the driver.

IT's expensive, around $400 expensive.

But it's basically you hook it to everything that produces sound, and it routes audio any which way you want to things that take in sound. Your PC would connect the output and input, you'd hook your console outputs to it, and other things. Then you can have it output to your speakers, your headphones, your PC etc. Add in mic ability so you can do game chat or streaming chat.

It's basically so you don't have to plug and unplug devices to get your audio routed your way - you want to do a live stream on your PS5 and audio goes to this, and then split to your PC to do the streaming and your headphones so you can hear the game audio. What you speak into your microphone can go to your PC for your livestream chat, and switched in and out for team chat on the game. (This can be surprisingly hard if the game doesn't allow mixing your voice into the audio output)

As a bonus, the thing runs DOSbox so you can play your DOS games on it.

It's modular in that you get it the way you want - if you want more buttons you can have more buttons, if you need more level sliders, you can do that instead. Since everyone's setup is different, it can matter.

I suppose it also lets you adapt audio sources - analog in sources, digital in via normal methods or USB, ad audio outs via analog or USB. There is a surprisingly demand for people who want to connect multiple devices using USB as the audio source and mixing them, but that's always required a USB DAC. And solutions to go from analog audio to a USB headphones or speakers or other device are surprisingly lacking as well.

I would pay good money for a completely dumb TV. No google anything. No smarts. Adjust the colour, the volume, the inputs source and get out of my way.

You can easily find them as "digital signage" screens. The big manufacturers typically have them - LG, Samsung, etc all have digital signage lines.

The only downsides is they typically don't come in OLED variants as most signs display the same content continually so those would wear out really quickly and often most are left on overnight and thus don't have the ability to run compensation routines. Also, if you want HDR, they typically don't feature much beyond the basic - again, HDR is not generally something you find in signs. Though it might be changing since creative use of HDR can be use to attract the eye making it stick out beyond

But they are completely dumb devices - they typically only feature a media player because the content is usually supplied as a USB stick as either a set of movie files or photo slideshow.

We do have studies though. Indiana, Arizona and Saskatchewan all have areas that don't (or didn't) observe Daylight Saving. And haven't for over a century or more.

If there was some definite "good" in this, we should be seeing ill-effects. Instead, we get relief from having to screw with the clocks twice a year.

If daylight saving was so universal and good, why just one hour? 1 hour makes a huge difference at 3AM versus 4AM for sunrise, or 10pm vs 11PM for sunset at my locale which isn't anywhere close to the arctic circle. Heck, they get 24 hours of sun in the summer.

Meanwhile there are definite health effects from the clock change - disrupted sleep both ways, disrupted cicadian rhythm, mental health, etc.

I'm sure the only reason people haven't actually done anything is tradition. We've always had to change our clocks around so we still do it even though it makes little to no sense.

Password complexity rules don't mean a single thing - because changing passwords means people come up with a system. I can give you a system with capitals, small, numbers and symbols: Month name (January, February, March, etc), the symbol above the month number (like exclamation mark for January, and underscore for November, and plus for December), and the 2-4 digit for the year.

Heck, I even knew of people who simply cycled the passwords over a week to get around the "can't use the last 5 passwords" restriction. They'd add a 1, then the next day change it to 2, and by the end of the week change their password back to the original.

It's basically a cat and mouse game, and policies that may try to enhance security can fall flat and instead decrease security because people find a template for making passwords.

Except you can install programs without admin rights - Chrome for example was one of the most well-known examples. It took a while for Chrome to have a version that could be installed system wide (with admin rights). And Microsoft does it as well - Visual Studio Code can be installed with both user and system rights.

And nevermind portable apps - programs that run from USB sticks or such which require no installation at all - run the EXE and go.

Well, it' passes 3/4 of the GNU tests. The tools aim for 100% GNU compatibility - but you don't need 100% GNU compatibility to be useful. (Think: /bin/sh vs. /bin/bash)

You need compatibility with the common options people use it for - so if it doesn't support some rare and obscure GNU extension that no one uses, it will fail the test but in practical reality, no one would notice.

Ubuntu is also using 25.10 as a beta for 26.04 LTS - so passing 75% of tests would mean most people probably wouldn't notice. And the ones that do, well, you have a bug report and development efforts can focus on those GNU extensions that people actually use. Practical GNU compatibility might only be 85% - but going from 75 to 85% is hard because you want to pick the options people actually use the most. And the best way to do it is to actually use it.

The tools are all POSIX compliant - but if you were stuck with POSIX compliance you miss out on many of the "quality of life" features that were added but non-standard. GNU added those as extensions and the new re-implementations must adopt the ones people actually use.

Whether 6 months is enough to figure this out is another matter altogether. There are also some interesting bugs, like a hang caused if you real a single line 4GiB big file through sort. A bug sure, but how likely would one encounter it? It needs fixing, but priorities will likely remain elsewhere that have bigger impact.

Price really. ADS-B transmitters are expensive. They're smaller nowadays but those still need a regular transponder (they are not UAT devices, but regular transponders in "ES" or "extended squitter" mode meaning they output regular transponder data but add extra bits to the end - Garmin has a patent where it detects a normal plane transponder responding to a query then adds the extra data to the end).

Most of the radiosondes aren't recovered - the recovery rates are up to 50% or so so they're made to be cheap and disposable. (It's understandable - the weather balloons rise up to the edge of space, pop and the the payload falls to earth at a random location carried by the winds and it's basically impossible to know where they land). You might remember the whole craze a decade ago of sending stuff "to space" where you hook a camera and stuff to the bottom of a weather balloon and have it rise up filming the trip up and down. Well, who knows how many of those actually happened - we don't know about the ones that were permanently lost because they never recovered the camera and the video. Sure they could add GPS beacons to increase recovery, but again, costs.

Most weather ballons are launched 2-4 times a day to gather atmospheric data. They need to be cheap because most are never going to be recovered. Even adding GPS is quite a bit of an expense.

It's not immature products - all are based on Chromium which is very well mature at this stage having been around nearly 20 years (as WebKit later forked to Blink).

The problem is fundamentally, the AI works on the webpage you can see (and the bits you don't). And the bits you don't make it vulnerable to prompt injection.

Prompt injection happens because you can't separate the control information from the data - and is not new. AT&T found out in the 60s and 70s when phone phreaking was common because of in-band signalling. SQL injection is another form because arbitrary input is being confused with the actual parameters. Prompt injection is another, where AI system commands are mixed in with user data - because no clear distinction between control information and data is made.

AT&T switched to using out of band signalling with a control channel private between exchanges. SQL users use parameterized queries where the SQL and the data you look up are kept separate so you don't mix them up. AI has... ? Because the system prompt is just input into the model and as far as a model is concerned, just more generic input.

A similar thing happened to Firefox many years ago when Greasemonkey was popular. Greasemonkey allowed you to inject JavaScript code onto websites - maybe to bypass annoying timers, disable ads, etc. The problem was Greasemonkey worked at the page level - so it was possible for websites to have JavaScript that told Greasemonkey to do bad things because the JavaScript engine couldn't tell the difference between code loaded from the web versus locally injected.

Well, there are some areas of manufacturing that are somewhat unpredictable.

First, performance variation - you can have a chip design, and have a huge variation in performance across the wafer and you need to characterize this. This is often done using test wafers specifically mis-manufactured to be exceptionally slow and exceptionally fast and performing simulations and tests to verify the logic is still functioning at either extreme.

Second - yield improvement - flaws in chips still remain and is one of the fundamental limiting factors - it's why we have chip families - every chip will have 4 cores, but we have a product line where you can have 1, 2, 3 or 4 cores, so the ones with damaged cores we can disable and sell as a lower cost core. But this requires testing - if you could tell ahead of time that the core would be bad you'd save seconds to minutes of testing.

All this process variation generates a huge amount of data, to which an AI (machine learning) model can be trained with. Get enough sample points and perhaps you can run the fab in a way that process variations happen less and yields increase because you're able to do things quicker. You could figure out how many of each chip you're going to get - how many chips will be fast, how many average, and how many slow, and maybe tweak parameters so you're producing more chips in the desired frequency range

A lot of IC production is really left up to luck and averages and we've all seen the shortages of parts where some particular chip is in high demand because of a nice combination of price and performance but because the process is "too good" the higher performing parts aren't in that nice in demand bin of higher performing parts.

Actually, solar, wind and nuclear are the same but opposite. They're both non-dispatchable sources of power - that is, they cannot adapt to changes in the grid. Solar and wind is obvious - they're erratic, but if you have an excess, you can always curtail production. Nuclear is the opposite - you cannot have an excess as reactors take many hours to change output so you have to run them short of what the grid needs.

This non-dispatchability is fixed with dispatchable power - things like grid scale batteries, hydro, and natural gas, where power can be brought in milliseconds for battery, or minutes for hydro and natural gas.

The problem with nuclear is its a slow reacting and thus it always has to run short to avoid accidentally producing too much power - too much is a disaster because there won't be anything to absorb the excess. Solar and wind can handle it because they can be curtailed - if they produce too much, you can command them to produce less instantly.

Grid scale batteries with nuclear would be ideal - the battery can absorb excess electricity allowing the reactor to run closer to the demand.

Wind, solar and nuclear are just options that are basically identical in many ways, and opposite in others. They're all non-dispatchable, but nuclear cannot curtail its output rapidly and thus must always be short, while solar and wind can but are erratic and unpredictable. They need to be coupled with storage to greatly increase their usefulness, else they have to run with hydro or natural gas which can be brought up in minutes.

And with great electrification - from vehicles to home heating and cooling, the duck curve relied on by nuclear to provide just short of demand is easily going to be out of date. EV charging - which used to be the domain of the off peak evening and night, is shifting to day when solar is providing excessive energy making all those batteries store up the excess. Cooling is also greater during the day, which would also be ideal for excess energy consumption - if you have too much solar, your house is heating up so run the AC to use up all the energy (storing it in the "thermal battery" of your house).

Pacific Lock (aka PacLock) makes very good locks.

They're currently suing Proven Industries because Proven Industries has "Made in the USA" plastered all over their website, but in the court filings against McNally, they said they had imported lock cores (the part of the lock that checks the key) from Finland and China. They even admitted under deposition that they imported locks from China.

PacLock is suing because the "Made in USA" label is being improperly applied, using the testimony filed under McNally's case.

So somewhere there's a problem - it says "Made in the USA" with all the flair, but admitted it contains core imported components or was made in China.

Yeah, I never really got that. If you look closely it's like the road name is embedded in the image - so when you zoom in, it's using a more detailed image but the road name is gone because it's not there in the zoomed in version.

The reason is the spacing is often very large so you can have an unnamed road because they burned it into the image too far apart for the screen so you have to scroll.

If it was a part of the map data itself, the map could easy make sure the road name is on screen.

Maybe it's time for them to upgrade to fully vector drawn maps where everything is tagged so the road names, etc. can be overlaid because the program knows where to draw them so they're visible. And you can display all known names for a road so the ceremonial name, the practical name and even nicknames can be shown. Being told to take the "horse road" isn't terribly useful if you're not from the area, but if you can have the map show the colloquial name would help.

No, they'll just be tossed in with the rest of them.

American *citizens*, you know, full blooded Americans - are getting arrested by ICE. It was even recently decided citizens may sue ICE for illegal detainment after one kept getting arrested and held for a week at a time at a detention facility.

Even worse, ICE isn't following ID rules - the law requires all government workers have ID. Sure maybe they don't want to ID themselves, but they should be wearing ID numbers. It's why police have badge numbers they give out.

In the end, anyone can gear up like Kristi Neom and kidnap people as an ICE agent. Because who really knows? It's already happened in a few instances.