But how is this implemented? It's a few lines of code to implement a basic "identify and strip/replace any non printable ascii, unicode ..." or whatever. A screenshot/OCR will also do this.

SO at the end of the day you're left with some dumb rules like "you used `load-bearing` more than once per 500 words, that's AI!"

Just to +1 on this; my second folding phone was the pixel 9 fold. That phone was released several _years_ after android OS added support for multiple screens, in preperation for samsung shipping the first ever folding phone before covid!

Despite LITERAL YEARS ELAPSING, a decent number of popular apps _still_ - in aug of 2026 - do not handle the aspect ratio changing well let alone transform to actually take advantage of the additional real estate.

It remains to be seen if apple's rumored folding iPhone will be the catalyst that gets most devs to actually care about this.

The main reason that I do put up with the fragility is because I can do side-by-side multi-tasking and give my aging eyes a break when I need to read something.

I had a slim XPS13 and IIRC the headphone jack was on it's own little board. That makes it quick/easy/cheap to repair if you know what you're doing / have the service manual / are comfortable taking it apart.

Not all things are designed that way; sometimes the jack is right on the main board and most people that buy dell laptops are not going to DIY through ali express; they're going to use up phone support time, require a shipping label, technician time ... etc.

This is already happening with gpus, no? Tsmc and McDaniel capacity are sold out into the future. Data center that might not be needed in 1 to 3 years is where they’re headed.

That's the thing; they can't, really.

Best we can do is compromise; allow bots and rate limit them. Maybe someday there will be a relatively universal standard for fetching pages akin to the `index.html/index.md` pattern that is emerging now. Put the bot filters on the .html path and some sort of micro transactions system on the .md endpoint.

In basically every cat/mouse game defense is forever one step behind...

I've been curious about the north korean mobile OS...

I can pretty easily burn through my weekly quota over several agent coding hours with minimal supervision when tasked with some pretty large but well-planned refactors.

So ... most people.

> That's basically all self-generated stuff by you about you, you don't really need any outside data sources.

Other than the ones you just enumerated that most people are likely to use, I need to know - using external sources:

- When to expect the garbage truck (do I put the recycle out tonight, too?)

- Is it a school holiday?

- When it's cheapest for me to charge the car up; if there are any "grid stress, please turn non-essentials off or we're getting rolling blackouts" alerts.

- Same goes for nearby fires or other issues that are going to change the "when do you open/close the windows and switch to AC" math.

- If it's likely to rain in the next few days so I change what plants get watered / when

- Packages that I am likely to get in the post today

- Weather (for display, not just for use in the automations mentioned above)

- Where my power provider is currently getting its power from (so I can calculate estimated CO2 emissions, if any)

And that's about 1/2, probably. Can't be bothered to go spend 20 min pouring through my HA config to build the full list.

I also stream the npr newscast as an MP3 as part of the "good morning, while you wait for coffee..." automations, if that counts for anything.

That's because zwave requires everything go through certification process. You pay more for this, but things generally just work.

It's an entirely different situation in zigbee land though.

I stick with ESPHome and MQTT because I can inspect and modify the behaviors of everything with free and open tools.

Almost certainly! No eComm site wants the cautious shopper that's done their comparisons and knows price trends; they want the impulsive people with a line of credit. I doubt that my local grocery store is happy that I index all of my receipts so I know what I buy, how often and when the prices change so I know when a discount on something I buy every once in a while is actually a discount.

When I built this a few years ago, I had to write a lot of code to make all this work.

Now that's a simple "hey $agent, check the price of https://some-site.com/appliances/that-new-fridge.html and https://other-site.com/shop/appliances/that-new-fridge.aspx daily and notify me when it's on sale or has a promotion"

I would expect that more and more people will discover that their LLM of choice can do this, that their LLM of choice can help them comparison shop and do analysis of when - historically - is the best time to buy that new TV or whatever (yes, pricing on this stuff is seasonal!).

Maybe _most_ people will never do this, maybe I'm wrong. But if i'm not, blocking all bots "because bots are bad, mmmkay" is how you loose a sale.

Ignoring the specific price data example, more and more and more people _are_ browsing the web through an LLM. Assuming that continues, blocking bots is going to have the same effect on your traffic as doing everything in the "what not to do" section of the google SEO guide book.

There's a "look what I built!" thread every few days on the /r/homeassistant sub and the home assistant forums, too.

The data sources vary but it's usually a mix of devices that the user has locally and some remote data sources like weather/public transit schedules APIs or RSS and in some cases also utility rate info all integrated into a SPOG that is then displayed on some ambient screen (usually a hacked tablet or other cheap ARM device)

The point is that not all bots are bad. Assuming as much / implementing policies to that effect won't block all bots but it _will_ block the portion of bots that represent users considering giving you money.

I have a series of bots that monitor various eCom sites to monitor prices over time for big-ticket items I am considering as well as staples/groceries and everything in between. I have this little scrape/ingest pipeline because there's no other way to obtain this data... not even an API that I can pay for access to.

One of the large appliance sellers that I have in the scrape queue has gotten _hyper_ aggressive with bot detection to the point where even my personal head-full chrome instance doesn't always get to load the page. Guess who I will never buy that ~$2000 appliance from.

If you're fortunate enough to not be battery constrained at most endpoints and can put a high quality Wi-Fi access point in an optimal location than Wi-Fi is incredibly reliable.

The tooling for inspecting all layers of a Wi-Fi network is infinitely more accessible and mature and that certainly helps; I can't go to My local big box store and get a USB thread dongle for 20 bucks that will just work on a Lennox computer and integrate nicely with Wireshark out of the box...

But, won't somebody think of the children!

_sigh_.

See, that's why this can't be solved technically.

Pornhub has a decent amount of sexual health material on it so there's an argument to be made for allowing teens access to at least parts of it.

> privacy being the bit which has to be done perfectly.

> It cannot work perfectly

So we agree that this is going to end poorly?