wolrah

> 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.

> We don't care to coherently reflect the light; we just want to block it.

The energy has to go somewhere. If you're not reflecting it you're absorbing it and you eventually have to do something else with it.

> 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.

> Hyperia is a fork of Hyper Terminal.

I couldn't click fast enough, then discovered that "Hyper Terminal" has nothing to do with "HyperTerminal" and couldn't click "close tab" fast enough.

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.

The motherboard is an ASUS Prime H610M-A WiFi D4.

> 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.

Two reasons come to mind for me:

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.

You don't get kicked out of trusted roots for non-compliance, you get kicked out for continuing to knowingly issue non-compliant certs, failing to revoke non-compliant certs in a timely fashion once discovered, etc.

Pausing issuance immediately upon discovery of a compliance issue is the absolute correct response so as long as they do their followup appropriately there is absolutely zero risk of being distrusted.

If I'm understanding you correctly, you have access to the entire desktop but some of it is off-screen at any given time, with the displayed area following the mouse?

This is a feature that some graphical desktops used to have back when 640x480 and 800x600 monitors were still common, the desktop resolution could be set independently of the display resolution, so you could have a larger framebuffer that your monitor presented a view in to. I recall some graphics drivers (Matrox for sure) added this to Windows 9x and called it "virtual desktop" and I know I've seen it on a few *nix platforms too.

I'd assume if the resolution adjustments work as expected below 1024x768 that whatever graphics driver OI is using in your VM only sees the virtual display as capable of 1024x768 at max and so it does this if directed to provide a larger desktop.

edit: apparently xrandr calls this "panning"

Most developed jurisdictions require commercial kitchens (and commercial spaces in general) to have fire suppression systems, not necessarily fire sprinklers. Water sprinklers are a common choice for fire suppression in many spaces because they're relatively cheap, but they're not the only option. A kitchen fire suppression system will generally be a wet chemical system that will safely blanket a grease fire while still being easy to clean off of food prep surfaces unlike dry chemicals.

> I sometimes wonder about the people who must clean messy public restrooms. All of the gross, none of the "but it's for the sake of a cute human that I love".

I worked "maintenance" at a local outlet mall back in college so I was that guy, and after the first couple of times it was just a matter of "this needs to be done, I'm the guy who does it" turning my brain off and getting the job done. I remember basically nothing from those evenings, I would just put my headphones on and mentally be somewhere else.

It was a shit job in a lot of ways, figuratively and literally, but at the same time I had amazing work/life balance. From the moment I clocked out until the next time I clocked in what happened at the outlet mall was not my problem in any way and I didn't have to think about it at all.

> At some point you have to trust vendors. I don't know exactly how AWS guarantees eleven nines of durability on S3. But I sure hope that they do.

Trust is earned, it's built on reputations at the individual, corporate, and industry-wide levels. AWS has 20 years of reputation on which I can judge the value of their promises.

Not only has the LLM industry (it is not "AI" and never will be) absolutely not earned anything like that level of trust, the thing the technology has proven most effective at is in fact scamming. Making up something that looks/sounds convincing, especially if you aren't thinking too hard about it, is what they're best at. Combine that with a lot of money flying around and trust levels should be somewhere around "Elon Musk promises".

At this point there have been so many blatant examples of why you should never give a LLM "agent" control over production systems, but the allure of just giving some vague direction to a chatbot and telling it not to screw things up it just irresistible to some like Sideshow Bob stepping on rakes [1].

If everyone around you is whacking themselves in the face with the rake, and you know you can avoid it just by using your brain and not stepping on the rake, and avoid entirely by just keeping your rakes contained, but a rake vendor comes to you saying that instead they have built a new rake that they swear won't whack you in the face even if you leave it right in your walking path, do you trust them?

1: https://www.youtube.com/watch?v=ouau9SVVrBA

> No, IPv6 as it is supposed to be implemented gives (say) a single server a /64, which is for all intents and purposes an inexhaustible supply of IPs. You could in principle have an IP per site you visit and have plenty left to spare.

No, as it's supposed to be implemented a single internet-routable /64 is used per *network* and then most devices are expected to assign themselves a single address within that network using SLAAC.

ISPs are then expected to provide each connected *site* with at least a /56 and in some cases a /48 so the site's admins can then split that apart in to /64s for whatever networks they may have running at the site. That said, I'm on AT&T fiber and I am allocated a /60 instead, which IMO is still plenty for a home internet connection because even the most insane homelab setups are rarely going to need more than 16 subnets.

> So if I wanted to annoy GitHub, I could connect to them without ever using the same IP twice. Their response would have to be banning my /64, or possibly /56.

Well yeah, but it's not like it's exactly rocket science to implement any sorts of IP rate limiting or blocking at the subnet level instead of individual IP. For those purposes you can basically assume that a v6 /64 is equivalent to a v4 /32. A /56 is more or less comparable to /25 through /29 block assignments from a normal ISP, and a /48 is comparable to a /24 as the smallest network that can be advertised in the global routing tables.