OSS projects have in many cases been the first to be hurt by LLMs.
As you note, LLMs are heavily trained on OSS code. This makes them very good at "license-washing" copyleft code in to a decidedly-not-cleanroom reimplementation which is different enough at first glance that it would be hard to stop without a legal battle most OSS projects could not even dream of.
Plenty of ink has also been spilled on how LLMs have led to a significant increase in administrative workload for OSS maintainers by allowing users to produce a high volume of both bug reports and pull requests that are likely to be of varying quality or adherence to project standards but unlike a new human contributor will never develop in to a better community member. It's infinite newbies forever, a computer-generated Eternal September.
On top of all that, as noted in the Debian proposal the companies training these LLMs have proven themselves to have no shame or concern for the resources of others in the process of gathering data, inefficiently crawling every single URL they can find and nowadays even using their own models to generate new potential URLs that have never existed, in ways specifically designed to make filtering, rate limiting, or blocking the traffic altogether as hard as possible while performing what are often some of the most resource-expensive requests. These tactics have imposed substantial real costs on basically everyone who hosts their own infrastructure as well as community hosting projects, without even getting in to the hardware-related cost increases every single one of us have experienced.
LLMs have gone to a lot of OSS projects, stolen their code, beat up their maintainers, and emptied their wallets. Now the LLM people are coming by wanting big projects to work with them, "for their security" like a protection racket.
As a long-time GoPro owner who recently added an Insta360 X5 to his collection, I can't really see any meaningful difference in software horribleness. They are both really really bad, with ads everywhere constantly pushing subscriptions to their cloud services.
At least with the normal cameras the software can be entirely ignored, I can take video from my Hero5 straight in to any ordinary NLE and go from there, but the 360 camera requires their software to convert from the native format to anything usable, even if I'm keeping it as 360 footage.
The worst part IMO for both is that they prioritize mobile apps over their PC software so if you want to edit on a computer like a normal reasonable person you lose features compared to idiotically doing things on a phone.
Those power supplies often shipped with both a full cord input which was grounded but also a folding two-prong component that made it in to a wall wart and of course was not grounded.
> Hey, implementation, you're a computer! Strip them out automatically on the backend if you don't like them!
This is one of my most hated categories of pet peeves, software that does something in a way that causes a human to have to expend effort every time they use it which could easily be fixed by one-time effort on the developer's part, but the developer is either uninterested or hostile to the idea of fixing it. Computers exist to do the tedious stuff for us, if software makes us do tedious stuff for it that could be avoided with a bit more work on the software side then the software is wrong.
"Enterprise" software on Windows that "requires admin" has been a long time top subcategory here, where in literally 100% of cases I've ever dug in to in 20+ years of professional IT they could change a couple of default paths to point either within the user's private folders or a common user-accessible folder like ProgramData and solve it forever, but instead they tell people to give everyone local admin and people who don't know better actually listen to that idiocy while competent administrators are forced to fire up ProcMon and track down what it's doing so they can bodge around it by pushing out permissions changes or config changes through their management platform of choice.
> And if you're cycling them every day like this, they're not going to last more than 15~20 years.
You can't make a blanket statement like that because it depends on a lot of variables about their specific battery system and power needs. If you have just enough battery to get through a normal day so you're running them top to bottom every day then sure, those are likely to have a relatively short life. If you've set up your system with extra capacity to support extended total grid outages and/or bad weather now your normal days might only be cycling from 80% down to 60% and back. Of course battery chemistry is also relevant, and a home battery system doesn't need to care about energy density or peak charge/discharge rates in the same way an EV might.
On top of all that, now that we're over 15 years in to mass-produced EVs we've learned that our battery life expectations were generally pessimistic. As long as the batteries are kept within a reasonable temperature range and not otherwise abused they tend to be in pretty good condition even this far in to their expected service life. Home energy storage systems are a lot easier on batteries than automotive use so as a general rule they should last even longer even with similar cycle counts.
> If you believe that adding lanes doesn't reduce congestion, then you must also believe that adding transit doesn't reduce congestion.
The problem with road congestion is the number of personal vehicles inefficiently carrying 1-2 people while taking up a lot of space on the road.
In any situation where the roads would be clogged with personal vehicles an effective transit network will be carrying dozens or even hundreds of people per vehicle in vehicles that may not even be sharing the same lanes and thus can't contribute to road congestion.
> Sony actually allowed "OtherOS" until Geohot screwed it up for everybody and they locked it down.
I recall exploits allowing some level of access to the RSX and other components Sony had locked away from OtherOS as far back as 2007, and Sony had already removed OtherOS from the PS3 Slim with no warning or explanation in August of 2009.
Geohot didn't even start on the PS3 until December of 2009. At that point Sony had already made it clear that they no longer saw value in OtherOS and wanted to get rid of it. Geohot's exploit (which was janky, required external hardware, and didn't even enable homebrew much less piracy) gave them a convenient excuse but there's no reason to believe they wouldn't have jumped on any other excuse.
---
I do love how Sony immediately learned the hard way that there are a lot of very skilled people out there who are more than happy to play in a sandbox and not make a mess in the rest of the yard as long as it gives them enough room to do something interesting, but if you take the sandbox away they're going to play everywhere else.
> I'd almost rather have no AI whatsoever and have storage 1/10 the price of pre-AI times.
Almost? ALMOST!?!?!
If you handed me a button that would make it like LLMs had never existed I'd be slamming that button so hard Sam Altman's clothes would spin around.
Return memory and storage prices to normal, undo the sloppification of ~everything, remove all these annoying "features" that are so useful they have to force them upon people, and make scammers actually have to put in a slight bit of effort, all at the "cost" of real human developers, artists, writers, etc. getting paid for their work....
If this is a hard decision for you, you are the problem.
Because if I download a binary package I can then fully inspect it before installation and be sure it's actually what I intended to install. If it's actually a package for my chosen variety of package manager it's probably signed too. Even if we're talking about just a single static binary distributed by the developer where I don't have the skills to usefully analyze it, the fact that I can verify that the binary I downloaded is the same as the binary everyone else using it on my platform has been using for however long without issue that still offers some level of trust.
By comparison, a curl|bash not only skips over my ability to do any of that but it also introduces two new potential paths to exploitation if a malicious user has control over the web server. There's the classic "hidden text that doesn't appear visually but will be in the copy/paste version" and the more complicated "server detection of manual download vs. curl|bash to deliver different content".
A curl|bash saves the "friction" of a `chmod +x` command and maybe an unzip/untar in exchange for introducing multiple different ways for malicious actions to be hidden.
> But all that only makes sense if you own a domain name.
I have a hard time believing the venn diagram of "has a need for an auth provider" and "has at least one domain name" isn't just a a small circle almost entirely inside a large one, and the sliver on the outside is not for any reason other than stubborn refusal.
I'd be surprised if Cloud Key gets another revision, it's a dead product line as I see it. The main purpose was to provide an appliance alternative to running the controller on your own server, which is now unnecessary for most users because the routers and NVRs can all host their own controllers.
The remaining market for such a product is people who are running UniFi switches and/or APs but not the router and yet still want an appliance, which is not a large space. Most of that market either has a random server they can run it on or is willing to throw together a Raspberry Pi controller.
1. It's very common, especially in certain ecosystems like Python, for the system to depend on old versions of things in such a way that updating to modern versions will break your entire system, while at the same time you want to run something at the user level that depends on a newer version. The solutions to this are usually ecosystem specific and often annoying to use for someone who just wants to run a program (again a great example being Python venvs, which at this point have decades of tooling built up around trying to make it less annoying to deal with).
2. For "cattle" systems having everything installed at the system level is generally not too much of an issue, but for "pet" systems where the user might be experimenting with things it's really nice to be able to install stuff in a way that doesn't affect anything outside of your user account even if it's also available at the system level. The computers that I personally operate from on a daily basis tend to build up a lot of crap I used once over time and removing it without just backing up my stuff and nuking it all can be a major pain.
That's why the article says "verify, not validate". Send an email, have a process for them to confirm they received it.
If the user gets the email and completes the validation, the email is valid. If they fucked up, they don't get the email and the account never gets created.
No one ever gets prevented from creating an account with a legitimate email address, as opposed to "opinionated validation" where that absolutely will happen. Speaking from years of experience having a .info domain which isn't even all that odd, and at one point using gmail-style + addresses regularly. "Opinionated validation" has forced me to use my .com domain without a plus dozens of times.
I know part of this is intentional, those who know they plan to sell your email addresses don't want you to use the plus addresses, but that doesn't make the advice to not filter addresses any less correct.
> in the end the Find My beacons have to resolve down to some common identifier otherwise the "an unknown device has been following you for 2 hours" warning would not work.
Not really, this is actually pretty easy. If such a device beacons and a trusted device is within range the trusted device can respond to the beacon and let it know it's nearby, then it just counts up if not. X number of beacons with no response, set the "not near my trusted device" flag. Some other device sees X number of beacons with that flag set while moving around, send alert to the user.
> Flipper Zero (without extra hardware) doesn't do 2.4 GHz for Bluetooth or Wi-Fi (or 5GHz Wi-Fi).
Flipper Zero has Bluetooth built in, that's how the phone app works.
I don't know how much control the apps have over it, but there were definitely Flipper apps to abuse the BLE auto-pairing feature of a lot of devices and spam popups to nearby phones.
> A part of me cries a little when I see so much beautiful land and trees cut down and these lifeless panels taking up so much space.
Where are you seeing healthy forests or other "beautiful land" being destroyed for solar farms? There's plenty of low-yield farmland and other similar land that's already been denatured by industry out there, lots of which already has major transmission infrastructure nearby, beautiful land tends to be expensive, and clearing trees costs money. It just doesn't make sense to do something like that outside of isolated areas where there's no other choice.
Here in the midwestern US every single solar or wind farm I've seen has either been on active farmland, former farmland, or a corporate/university campus.
OSS projects have in many cases been the first to be hurt by LLMs.
As you note, LLMs are heavily trained on OSS code. This makes them very good at "license-washing" copyleft code in to a decidedly-not-cleanroom reimplementation which is different enough at first glance that it would be hard to stop without a legal battle most OSS projects could not even dream of.
Plenty of ink has also been spilled on how LLMs have led to a significant increase in administrative workload for OSS maintainers by allowing users to produce a high volume of both bug reports and pull requests that are likely to be of varying quality or adherence to project standards but unlike a new human contributor will never develop in to a better community member. It's infinite newbies forever, a computer-generated Eternal September.
On top of all that, as noted in the Debian proposal the companies training these LLMs have proven themselves to have no shame or concern for the resources of others in the process of gathering data, inefficiently crawling every single URL they can find and nowadays even using their own models to generate new potential URLs that have never existed, in ways specifically designed to make filtering, rate limiting, or blocking the traffic altogether as hard as possible while performing what are often some of the most resource-expensive requests. These tactics have imposed substantial real costs on basically everyone who hosts their own infrastructure as well as community hosting projects, without even getting in to the hardware-related cost increases every single one of us have experienced.
LLMs have gone to a lot of OSS projects, stolen their code, beat up their maintainers, and emptied their wallets. Now the LLM people are coming by wanting big projects to work with them, "for their security" like a protection racket.