Honestly, Microsoft should just take the L, develop Windows 12 based on a Linux kernel, and re-write most of their stuff from scratch.
After focusing on backwards-compatibility for 40 years, they’re allowed a new start, to fix all the rotten code they inherited from the 1980’s.
I’m skeptical they could do it in a way that meaningfully inherits stability from Linux. Imagine bolting on their service control on top of systemd or map their registry system to /etc. They either bring all the bad over to Linux or write something that doesn’t support the windows ecosystem.
They could do what Apple did when they replaced the old MacOS with UNIX, which is they shipped an emulator for a while that was integrated really well. They also had a sort of backwards compatible API that made porting apps a bit easier (now removed, it died with 32 bit support).
But in the Windows world, third party drivers are much more important. So in that regard it would be more difficult. Especially if they’re not fully behind it. As soon as they waver and there is some way to keep using traditional Windows, the result will be the same as when they tried to slim down the Windows API on ARM, and then nobody moved away from the APIs that were removed because they still worked on x86, which significantly slowed adoption for Windows on ARM.
Shit, with the way computer horsepower has improved over the years, how hard can it be to add a legacy Windows emulator or whatever WINE is, especially when you have the original source code available?
WINE is basically an adapter. It exposes a Windows API and calls the equivalent Linux APIs when invoked. That’s less overhead than an emulator which models an entire virtual piece of hardware. When you run a Windows program through WINE your computer is actually executing the code of the program just like any Linux one it’s just calling WINE libraries instead of the Windows ones it normally would.
They would only be obliged to open source any extra code they added to the kernel. If whatever they add lives in user space then it can be closed source (that’s one of the key differences between GPL 2 and 3 and why Linus refuses to use GPL 3). That said the problem with Windows at this point isn’t really the kernel, it’s all the user space crap they built on top of it.
Er, no. A Linux program from five years ago probably won’t run on a current distro if it hasn’t been maintained in four years. A Windows program released twenty years ago and never patched has pretty good odds of running on Win10 without even needing to touch the compatibility tab.
Honestly, Microsoft should just take the L, develop Windows 12 based on a Linux kernel, and re-write most of their stuff from scratch.
After focusing on backwards-compatibility for 40 years, they’re allowed a new start, to fix all the rotten code they inherited from the 1980’s.
Oh, God I would hate that.
I don’t want microshit software to become a standard in Linux.
What Microsoft needs to do is keep pushing AI as much as possible until it burns itself to the ground.
That would make a lot of sense, which is why they are going to do something else.
It seems like the actual windows kernel isn’t that bad, it’s mainly all the stuff on top of it at this point that is killing the OS
Which they could clean up, but it would mean killing backwards compatibility, which is arguably the only selling point of Windows.
and they have decades of closed drivers written for it.
I remember that rumor for windows 11, I was really hopeful.
I don’t think they really make money in windows itself.
Why don’t they just come to linux and sell their server stuff there to keep people in that ecosystem?
I’m skeptical they could do it in a way that meaningfully inherits stability from Linux. Imagine bolting on their service control on top of systemd or map their registry system to /etc. They either bring all the bad over to Linux or write something that doesn’t support the windows ecosystem.
They could do what Apple did when they replaced the old MacOS with UNIX, which is they shipped an emulator for a while that was integrated really well. They also had a sort of backwards compatible API that made porting apps a bit easier (now removed, it died with 32 bit support).
But in the Windows world, third party drivers are much more important. So in that regard it would be more difficult. Especially if they’re not fully behind it. As soon as they waver and there is some way to keep using traditional Windows, the result will be the same as when they tried to slim down the Windows API on ARM, and then nobody moved away from the APIs that were removed because they still worked on x86, which significantly slowed adoption for Windows on ARM.
Shit, with the way computer horsepower has improved over the years, how hard can it be to add a legacy Windows emulator or whatever WINE is, especially when you have the original source code available?
WINE is basically an adapter. It exposes a Windows API and calls the equivalent Linux APIs when invoked. That’s less overhead than an emulator which models an entire virtual piece of hardware. When you run a Windows program through WINE your computer is actually executing the code of the program just like any Linux one it’s just calling WINE libraries instead of the Windows ones it normally would.
A man can wish but they would never do that because of GPL and thus having to also open source anything built-in/in-top by them (afaik?)
Not really. Android and the google layer on top is a pretty good example of what you can do.
They would only be obliged to open source any extra code they added to the kernel. If whatever they add lives in user space then it can be closed source (that’s one of the key differences between GPL 2 and 3 and why Linus refuses to use GPL 3). That said the problem with Windows at this point isn’t really the kernel, it’s all the user space crap they built on top of it.
Even then, they can just have an open source shim and a binary blob for the driver, a la Nvidia.
Lack of, you mean.
Er, no. A Linux program from five years ago probably won’t run on a current distro if it hasn’t been maintained in four years. A Windows program released twenty years ago and never patched has pretty good odds of running on Win10 without even needing to touch the compatibility tab.