A cartridge that is just a bottle of ink has no (legitimate) reason to include a circuit board.

Guess what? The manufacturers agree with you, they have introduced "tank"-style printers that you pour ink into them from a bottle. The bottles have no electronics at all on them. But guess what? Average Joe will keep buying printers using expensive cartridges with a tiny amount of ink in them and DRM circuitry on them because Average Joe doesn't think when buying stuff and doesn't plan ahead.

Because the markets for inkjets and lasers are different. The kind of crowd that buys inkjets usually wants the cheapest possible printer and doesn't bother to look at how much the ink cartridges cost or how much they can print before they go empty. Instead, if you buy a laser, you are probably not the average clueless Joe and have probably done a minimum amount of research in your purchase. That said, "tank"-style printers do exist for people who want an inkjet (for example, if you don't want conductive toner dust in your house that houses your retro computer collection) but you aren't a clueless Average Joe.

But yeah, nothing about lasers specifically that could prevent toner cartridges from being infested with DRM if it made business sense to do so. However, taking out the drum is very complicated and would be difficult to make simple, so that ain't happening.

Not so much as you think, they will do something similar to what Apple did to work around "right-to-repair" laws: They will provide an "official" unlocking service to unlock the DRM in their ink cartridges, but charge so much for the unlocking service that remanufactured inks made with the manufacturer-blessed process won't be significantly cheaper than first-party HP ink cartridges.

To any people who think this will force printer manufacturers like HP to open the DRM in their cartridges: No, it won't, they'll simply create an "approved" unlocking system where they'll charge so much for the unlocking service that the remanufactured cartridges made with the official unlocking process won't be any cheaper, kind of like what Apple does with the iPhone replacement parts that they have to make available to third parties as part of various "right to repair" legislations.

I see it slightly different:

- When CRTs were the hot thing, Sony's Trinitron TVs ruled the market

- When LCDs were the hot thing, Samsung's "premium VA" LCD TVs ruled the market

- Now that OLEDs are the hot thing, LG's OLED TVs rule the market

It's not easy for a manufacturer to abandon a profitable product line they have poured tons of R&D into it, especially when the new technology is unproven. Let's not forget that early LCD TVs had issues with low contrast and luminance, and OLEDs had (and still have) issues with burn-in. Then the technology becomes popular regardless of the issues, and the manufacturer that stuck to the previous technology has to play catch-up. Ideally, the manufacturer would invest heavily both in proven and unproven technologies, but that's not what the board wants to hear because won't anybody think of the shareholder dividends?

Still, at least those people understand what they have built. Even if you get AI to spit out a codebase that covers your needs, it can't make changes to it (to cover a new need, for example), you can only tell it to spit out an entirely new codebase (that may or may not still cover your other needs the previous codebase did). The example that you mentioned (of developers failing to make a change) is an outlier, most software undergoes a lot of changes and additions over its lifetime.

Also, let's not forget that most of the bad designs you see are always the result of MBAs mismanaging people: They don't hire an experienced lead architect to come up with a good design but hire only kids fresh out of college (or even coding bootcamps), the impose too short timelines (they basically mistake agile to mean "we can do this with half the people in half the time"), and don't give developers time to write documentation (or they don't have a management structure to enforce documentation-writing, or they don't test applicants for proficiency in writing English before they hire them as employees).

Basically, MBAs look forward to AI as a way to get out of the mistakes they love to make when managing people. Forgetting that the codebase AI will give them is far less maintainable (and more often than not far less secure) than even a mismanaged team of "coders" gives them. But anyway, I am always looking to be proven wrong, so let's see if AI will actually deliver software that is at minimum as useful, maintainable, and secure than the average mismanaged team of humans.

MBAs don't understand that "coding" is a term we software developers invented to make the job look less scary (and risky) to MBAs. In reality, coding is by far the easiest part of software development. Software development isn't "coding", software development is the design of systems to automate complex tasks (as much as possible), it involves a thorough understanding of the problem at hand (aka domain knowledge), complex organizing of components, and managing trade-offs.

Unless it's some crappy website, software developers don't "code", they design.

What most people here forget is that, unlike countries like Greece or France, the US owns the central bank that defines the interest rate for the US dollar. So, all the government has to do is appoint someone who wants low interest rates to the chair of the Federal Reserve, and the interest rates will go down. So, the US government doesn't care about the interest rate because it knows it can always print more money (which also increases the GDP).

tl;dr: The US governments are treating money as fun coupons and will keep printing more of it, prepare for the dollar to keep sliding against any scarce asset (housing, farmland, gold, etc) beyond what official inflation figures say.

Because Japan's citizens buy all that government debt, something the average American will never do. And even then, the Japanese government is slowly running out of ideas.

Correction: the OS running on the N900 is called Maemo (it was renamed to MeeGo afterwards), my bad, but the gist is the same

The problem with the Nokia N9 was that by the time it launched (September 2011), the market had already consolidated into Android and iOS, and several "essential" smartphone apps had already become established by then. There was no market for a third OS in 2011, be it MeeGo or Windows Phone. If Nokia hadn't lost time in the Symbian vs MeeGo internal bloodbath, they'd probably have been able to ship the MeeGo running on the N9 by the time Android 2.0 (Eclair) shipped and see it become the second major OS instead of Android. But unfortunately, the company was pitching Symbian as their mainstream OS well into 2010 (Nokia N8), with MeeGo considered an OS for experimental phones like the Nokia N900. It was a major internal bloodbath between an OS that was generally outdated (only 640x360 maximum resolution and outdated UI) but which they owned 100% vs an OS that was modern but had to share with others. This is also the reason Nokia never jumped to Android: They didn't want to share an OS with other OEMs, while Windows Phone was basically theirs (with other OEMs producing only token devices).

There was a internal feud between Symbian and MeeGo that, combined with the fact software was never Nokia's strong suit, ended up on neither OS having a UX as good as iOS or Android. But even after abandoning their own OS efforts, Nokia's fatal mistake was going all-in on Windows Phone, the app-less mobile OS, in an era when smartphones were all about apps (and still are)

And what you don't understand is that cloud services come with a large amount of lock-in. If you are, for example, using AWS, you are locked into that (since your Terraform files or your deployment bash scripts are specific to EC2 or EKS). European governments were indifferent to that lock-in for years, since they considered the US a friendly country. Instead, China's governmental IT infrastructure was designed to avoid lock-in to US cloud services since day 1.

tl;dr: it's not the lack of EU cloud services, it's existing lock-in to US cloud services

*that is open-source and has reliable clean builds (sorry)

Interesting... what Gnutella P2P client do you recommend that are open-source and have reliable clean builds? Wireshare (formerly "Limewire Pirate Edition") or Frostwire?