>GCSS tells us we shouldn't simply solve the one and only problem in front of us; we should use our eyes and ears and human brains to understand the context in which that problem exists

This violates KISS and YAGNI and potentially leads to overengineering code and excessive abstraction

Everything "potentially leads" to adverse outcomes if not applied with due care and cognizance. That includes KISS and YAGNI. If you're looking for a principle you can apply in 100% of cases without consideration of context, I'm afraid you'll need to shop elsewhere.

> if not applied with due care and cognizance

That's the gotcha though. Everything applied with due care and cognizance works. This is not what is being discussed here. What the author suggests does lead to overengineering though. Think of stereotypical enterprise Java code if you need examples

The context was "business", that kind of application is developed quite differently than, say, a cool little hobby terminal emulator or whatever.

Even though the business currently doesn't have a need to e.g. support any other currency than USD and EUR, an experienced developer will clearly see that it is unlikely to stay that way for long, so doing some preliminary preparation for generalizing currencies may well worth the time.

>Even though the business currently doesn't have a need to e.g. support any other currency than USD and EUR

Your regular business requirements are way more complex than just a currency list. This is like trying to justify your point using an oversimplified example imo.

> a situation where we have two phones: one to run Big Tech's apps, and one to run indie apps.

This in combination with using webapps where possible

Have an optimised web browser for the OS and you don't really have to worry about 3rd party software performance any more or not that much

Roms face a different problem: bootloader locking. But the more Android changes drastically, the harder it is to integrate the AOSP changes into the different open projects

> Roms face a different problem: bootloader locking.

Is that a problem these days? It was over a decade ago that I last needed to jailbreak a phone, nowadays it’s just "I’d like to unlock" "Ok".

That’s possible on very few phones these days. Only a handful of OEMs still ship phones that can be bootloader unlocked at all (at least in the US), and even several of THOSE require phoning home to the OEM to get an IMEI-dependent unlock key to pass to fastboot.

Source: 7 years of running deGoogled Android phones and 11 years of running ROM’d Android phones before recently moving to iOS and giving up.

Just found this [0] in another thread. Some few allow no unlocks, most allow them under certain circumstances. Some few without a waiting period or additional sacrifices.

So not as great as I thought, but also not as bad as you made it seem ;)

[0]: https://github.com/zenfyrdev/bootloader-unlock-wall-of-shame...

Curious, have run GrapheneOS on pixels ? They don't have this issue, though it might change now.

Given that Google itself is the manufacturer of Pixel devices, I wouldn't hold my breath on them allowing you to keep this ability forever

Two of my deGoogled Android phones were Pixels (4a and 7a) and one was a Nexus (6p). I know them well, though I never ran Graphene on them.

Pretty sure I read Google was no longer going to publish device tree sources for Pixel phones, which will make ROM development for them significantly harder, whether or not the bootloader is open.

Not in the US, so might be one of those pesky regulations we have over here.

It is actually getting worse over time imo. In the days of Froyo, you could run Cyanogen easy without needing keys from anyone. Now you got to go to your manufacturer's website to get the key needed to unlock it. Even after you bought the device, you are reliant on the goodwill of the manufacturer to get the unlocking key.

Web pages have a lot of restrictions even if you consider the gradual adoption of the project Fugu APIs

The algorithm was slightly different and it was working on a different kind of data (mostly videos). Now it is working also on shorts and it has to deal with the rise of automated videos, videos with misleading titles and other hacks by malicious actors.

> Was fine when it was just Netflix, had mostly everything

This was problematic too. Centralisation is never good in the long-term. Surely, we would have learned that from traditional media, AWS outages or autocratic structures. Humanity as so much to learn still

Centralized marketplaces can work, but it’s hard to maintain those (there is one Centralized Internet, not many various internets, for example).

A subscription service that “covers all” like we usually get with music would be quite nice, even if it was only “older” shows after a year or so.

There isn't one centralised internet, its thousands of autonomous systems which connect to each other using a common language.

Now sure, some companies try hard to centralise it and own it, this leads to a more fragile ecosystem.

I mean that as a customer, you buy "one Internet" and get the "whole thing", you don't have to connect to various internets depending on what you want that day (as you did before by dialing into BBSes).

Companies and countries are doing their darnedest to break the Internet up into separate, smaller networks.

> This highlights just how much unlicensed copyrighted material is in LLM training sets (whether you consider that fair use or not).

Is there any license copyrighted material in their original training sets? AFAIK, they just scrapped it all regardless of the license

> If I code a var blah = 5*5; I know the answer is always 35. But if I ask an LLM, it seems like the answer could be anything from correct to any incorrect number one could dream up.

Is this meant to be a joke or did you not realise that your answer is incorrect?

I was on my third beer. But it also makes for a good joke.

I mean, for all you know, I asked an LLM to generate my question.

Until you lose it, break it, damage it accidentally (via high humidity, high heat, etc). Arguably, if you run twake on some VPS, you have additional layers of redundancy by default.