AI and the death of Windows (and maybe commercial software)

Operating Systems & Open Source Linux
21

Hello Fabel,

I am doing something similar,

Making my own fully parametric distro out of my usual operating system, linux & winblows, they will be “functionally airgapped” except for what I narrowly authorize, disabling all self-modifying, mothership calling functionality (goodbye windows defender & update).

And my entire desktop will run inside passthroughed, “thin ramdrive” version of proxmox, so I will have instant snapshot functionality and live OS swapping at any time.

I agree making a new kernel is still beyond the scope of the technology. Although kernel decompiling and pruning as well as motherboard firmware optimization will become the next frontier after the operating system distro has been conquered by the user.

And now that we are at the end of computers and these are the last computers we will own, it is worth consolidating our position and making the best they can be as these are the first computers that won’t get obsolete next year. (unless things suddenly stop going off the track globally, which is not likely)

Here is one thing I am currently in the middle of doing, to fully control the installer software, whether that be proxmox, debian, or windows, the installer have hooks if you go looking for them, you can inject the right files in the right place, and run scripts before and after the install proper. This will give me much greater configuration leverage than the installer’s autounattend files usually allow.

Can we post large text or files here ? I made my system into paste-to-run oneliners so I wouldn’t have to bother with the copying and creating of files, just pasting from my clipboard manager (ditto) so convenient

22

Also, create a “Filesystem Hospital” for whatever filesystem you end up using, having the ability to create, apply, verify, restore, heal filesystemes down to their very last metadata and parameters will allow you to take control of even hostile operating system.

Here is my parameters from my “NTFS Hospital” working on the classical metadata only.

image
image2017×2283 311 KB

23

…

My dude.

My. Dude.

We had this exact problem in the 80s and early 90s.

Look up the Internet protocol wars.

If we disregard the specifications now… We’ll be there in ten years.

Only, it will be 20x worse.

24

I meant someone -for example W3C- creates the set of specifications for everyone to follow, then you adhere to the spec but otherwise you execute on the software however the hell you want.

Hence my separation between specs and soft.

25

:joy:

Oh you naive S.O.B, I envy you there.

I completely get where you are coming from, but sorry… The world just doesn’t work that way.

Then again, AI has started to learn how to make agents work as a team now. So maybe there is some hope after all. :slight_smile:

1 Like
26

“One of the great things about standards is that there are so many to choose from”…

3 Likes
27

You are surrounded by specifications, you yourself implied so on your Internet protocol wars reference, which sounds more exciting than it really was. Not more relevant than the OS wars, the videotape standard wars or the high-definition optical disc wars or any other such “war” past, present or future.

I have been developing from bare metal ASM to the most bland LOB over the years and the only commonalities at every level are standards and protocols and the fuck ups of not properly following them, that IS exactly how the world works.

I never had the resources for replacing key pieces of software for myself, it was not feasible, AI simply changed that.

28

Not sure how this matters. We are already at a point where every service and application has their own proprietary api or file format.

Sure there are SOME agreed upon base protocols for networking and graphics rendering, but anything beyond that is not standardized

29

And that, friend, is the exact root cause of the current enshittification wave.

Ever wondered why you need five goddamn parking apps instead of a single one performing the same service? Or why your friends simply can’t agree on a single messaging platform, so they use all from Discord to Whatsapp to Messenger to… Which works great until you meet a new friend and they are a Discorder and you a WhatsApper. A bromance never meant to be… :slight_smile:

It is not all bad - one of the great breakthroughs today is the USB-C-charging-on-everything shift that the EU managed to drive home - But yes. Without further standardization work enshittification will only get worse.

30

Not sure it will.
Enough governments are moving to linux and open source that i think open standards will win.

1 Like
31

This is so true. In my course of work, I had experienced some IT heads whose modus operandi is blame the vendor first and those with these mindset also refuse outright to use any open source software unless there is a vendor they can sue.

1 Like
32

I can definitely see the logic behind this. Trust in software is becoming just as important as security itself, especially for governments and critical infrastructure. The move toward Linux could continue if countries want more control and transparency over their systems. It’ll be interesting to see whether this becomes a much bigger trend over the next few years.

4 Likes
33

we have talked about that very thing on links with friends, a lot :smiley:

1 Like
34

Building on what @kacyl1 and @luna780 said, there’s a critical human dynamic underneath all of this: enterprise software isn’t bought for security - it’s bought for plausible deniability.

The corporate default is wanting “a single throat to choke.” When something breaks, nobody takes ownership; they point to an SLA, pass the buck to legal, and look for a vendor to blame.

Linux flipped that model entirely:

  • The web of trust: Linus Torvalds has repeatedly emphasized that the kernel doesn’t scale on code alone—it scales on human trust. Linus trusts subsystem maintainers, who trust lieutenants, who trust individual devs based on earned credibility and track records.

  • Radical accountability: When a bug hits an open-source project, you can’t sue someone to save face. The culture demands that people stand up, take responsibility, and actually solve the problem.

Linux is arguably humanity’s largest collaborative engineering project. Its biggest breakthrough isn’t just the codebase - it’s proof that a culture built on earned human trust will always outperform a system designed around passing the buck.

4 Likes
35

No? Having different APIs is different from vendor locking.
The reason you can’t have a single parking app or a single messaging client is that the communication relies on keys or encryption or just being niche enough that nobody bothers investing the time (and often the ToS not allowing third party clients) to make sure you can’t just code a single app that has different backends.

An example of application with different backends (where the API is different but available to third party clients) is rclone. It supports a bunch of storage backends. While a good 50% of those are just a form of S3 (which is de-facto standardized to use AWS API), the others are various different things.

Or a lot of games and 3D applications on Windows. You can often choose to use DirectX or Vulkan. And the software will often have different code paths for different GPU vendors if they gaf about performance optimization.

36

You just claimed this isn’t vendor lock-in, and then immediately gave the textbook definition of it: using closed encryption and hostile Terms of Service to deliberately block third-party interoperability and trap users on a specific platform.

To top it off, you cited rclone, a tool that only succeeds across multiple providers because AWS S3 became an open, de-facto standard to argue against the need for open standards.

You proved Wertigon’s point while trying to “well, actually” it. Bravo.

37

I said that just having different APIs is not the issue, the issue is vendor lock-in.

I then explained that vendor lock-in is actually having limits in place that prevent the use of said API from a third party client.

I literally stated that rclone supports a bunch of non-S3 backends because those service’s API is available to third party clients, so I’m not sure how you managed to misread it this bad.

rclone is a lot more than just S3. Google Drive for example is VERY common and has no S3-like interface, rclone can use it because Google didn’t care enough to lock it down to only their own clients.

38

Let’s break this down so you can keep scrambling for holes to boost that forum clout meter of yours:

  • First, permission is not an open standard. Google Drive exposing a proprietary API isn’t an open system, it’s revocable corporate courtesy. The second an executive decides to pull a Reddit or Twitter, that third-party access vanishes behind a paywall or a ToS revision overnight. A platform holding the kill switch is the very definition of vendor lock-in and the exact engine of enshittification.

  • Second, rclone proves the tax, not your point. Developers having to write, test, and maintain dozens of bespoke API wrappers just to perform basic file transfers between services isn’t proof of healthy interoperability. It is the literal friction tax created when platforms build walled gardens instead of adopting open, interoperable standards.

You keep describing the textbook mechanics of API fragmentation and platform dependence while pretending they disprove the need for standardization. You aren’t refuting the argument, it’s like you’re just writing the case study for it.

3 Likes
39

Correct, but it’s tangential.

My point was not “proving we have healthy interoperability”. We don’t (see below).

My point was “We are already at a point where every service and application has their own proprietary api or file format.” AI and the death of Windows - #28 by starshipeleven

So I don’t see how it can get much worse (the fragmentation that is), nor why you need more standardization to use AI to create custom software for your needs. As claimed by Wendigoon AI and the death of Windows - #19 by wertigon

AI is already managing to massively lower the API fragmentation tax you point out in this part I quoted. Because it excels at relatively simple time wasting tasks like making a wrapper and the unit tests for it. It fails at doing big brain stuff, wrappers are leg work.
If anything, AI makes it easier, not harder, to work with the hilarious fragmentation we have today.

From what I understand Wendigoon (as shown in his examples) seems to conflate API fragmentation (that only has friction tax, which is not good but also not horrible) with entirely vendor-locked APIs and file formats (where you simply cannot use the API or file format from another client, period, which is horrible). And that would be a barrier also for AI-developed software because now you need to hack whatever mechanism they use to lock you out of API or file access.

40

First off, what’s with the childish “Wendigoon” crap? The handle is Wertigon. Resorting to grade-school name-calling is pathetic - it’s what people do when their argument is completely dead in the water and all they have left is cheap playground deflection.

Second, the shameless hypocrisy here is staggering. Four days ago on the BTRFS thread, you were lording over everyone with sanctimonious purity tests about how AI is garbage:

“Just letting the tool run loose by vibecodemaxxing is still the best way to generate absolute slop.”

“using it as a crutch, which is the wrong way to use the tool. Any tool.”

Now, the second your argument gets backed into a corner, suddenly you’re praying to the machine:

“AI is already managing to massively lower the API fragmentation tax… It fails at doing big brain stuff, wrappers are leg work.”

So which is it? Is an LLM “absolute slop” and a “crutch” when someone else uses it to test and fix a broken system, or is it your personal savior to spit out wrappers and unit tests so you don’t have to admit vendor lock-in exists? The ideological 180 just to avoid taking the L is embarrassing bud.

And I love how casually you throw around “it fails at doing big brain stuff.” As if you have the faintest clue what the “big brain stuff” actually looks like. It reeks of stolen nerd valor - posing behind the work of actual engineers who grind in the trenches, design platforms, and build low-level systems, while you sit on a forum playing the contrarian.

You talk about “friction tax” versus “vendor lock-in” like it’s some harmless academic nuance. It isn’t. I lived this. I worked for a startup that was acquired by West, and before the ink was even dry, Apollo swooped in, bought the whole thing, gutted the operation, and turned the tech we poured our lives into into patent-troll fodder just to feed the private equity “line must go up” machine for suits who don’t know code from a hole in the ground. That is how vendor lock-in actually happens in the real world. It is deliberate, predatory corporate capture designed to kill interoperability and trap users.

Back to the point: having an LLM spit out 50 brittle API wrappers doesn’t solve fragmentation. The second an upstream endpoint changes, auth shifts, or an executive decides to pull the plug to protect their moat, your entire house of cards collapses. Where’s your Ai glue-code savior now?

Open standards fix the architecture. Frantically generating disposable glue-code just makes you an unpaid janitor for the companies locking you in. But you wouldn’t know that, for many reasons I’m sure only you and your non existent therapist would know. I would sit down if I were you.

1 Like