> 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.
I am currently at a customer site installing a brand new mainstream budget computer purchased off the shelf from a brick and mortar retailer (Microcenter PowerSpec B687) which has PS/2 ports and a VGA output right next to the USB/HDMI/DP paired up with a 14th gen i5.
> 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.
This is Mac OS 9, which is pre-hackintosh. The term "hackintosh" refers to running x86 versions of Mac OS X on non-Mac x86 systems, where OS 9 was exclusive to PowerPC.
I agree, but it's also a rather distinct device so if it were being intentionally confiscated by TSA as some of the upstream posters claim it'd be really easy for them to identify. If it were policy in any way, even the most basic object recognition systems attached to even a simple x-ray scanner could identify one with ease.
That's of course not to say some rogue agents haven't confiscated a few Flippers, especially after seeing hyperbolic media reports about them being magical evil hacker devices, but I have high confidence that there's no official policy to do so.
Likewise, I've flown more in the last year than in the decade prior and every single leg my Flipper has been in the side pocket of my backpack. Never once has it received even a second look from the TSA, including also DEF CON.
> You end up with an Assembly program that doesn't have any UB, because Assembly doesn't have UB.
I guess that's true if you think of assembly as a more readable form of machine code, but from a practical sense I'd argue that assembly inherits the undefined behaviors of the architecture it represents and the implementations of that architecture it actually builds for.
IIRC the OG Xbox security was broken partially as a result of undefined behaviors in x86 where the AMD CPUs that were used in early development would crash or throw an error or something when execution reached the end of the memory space but the Intel CPU they switched to instead just rolled over and kept executing from 0.
Exactly my thought. APRS is nice but I'm just not interested in buying another otherwise analog-only radio. I know a lot of the popular digital modes are hard due to proprietary components but I'd be a lot more interested in something that supported digital voice and higher rate data modes even if it were just M17.
> The real question is did the operator arbitrarily and knowingly increase the level of complexity or is it appropriate for the task.
There's one major reason to have higher expectations for autonomous systems (of all kinds, not just LLM-powered) than for humans, at least those intended to be deployed at scale, and that's the scale. If a human makes a mistake, has biases, or even intentionally breaks the rules the impact of their actions is limited by the nature of them being a human, where something like an autonomous driving system, a coding agent, etc. is intended to be deployed by the thousands, millions, or more and any problematic behaviors happen at that scale.
There are obviously millions of bad drivers out there, but every one of the human ones is bad in different ways. If Waymo pushes a bad update there could be tens of thousands of "drivers" that suddenly become bad in identical ways.
Humans also have the ability to learn from our mistakes. The ones you'd want to have working for you usually don't make the same one twice. LLMs are pretty good at making the same mistake repeatedly, even the simplest things like basic math or counting letters.
This exploit is delivered through the charging cable to the wall box. These wall boxes are sometimes intentionally located in public spaces with the intent of allowing public charging, and Tesla has features specifically for that use case, so that cable is absolutely expected to be plugged in to untrusted vehicles.
Can't speak for the project members or main users, but as an alternative OS nerd who actually used BeOS R5 on a 300 MHz Pentium II in-period I see Haiku as having two different "purposes" depending on version.
The x86-32 version (and hypothetically the never-complete PowerPC version), as I see it, exists (or would exist) for binary compatibility with legacy BeOS systems. The AMD64 version on the other hand is a hobby OS demonstrating a path not taken where personal computer operating systems remained separate from server operating systems.
Also, like others, these days I can do basically everything I need to do on a computer other than gaming as long as I have a browser that supports the modern web and a SSH client so Haiku is absolutely fully usable on the right hardware.
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.