← Back to context

Comment by ThrowawayR2

4 days ago

He who fights with Windows should see to it that he himself does not become Windows. And when you gaze long into ntoskrnl, ntoskrnl also gazes into you.

Seriously, is it really a victory if you have to adopt the architecture of your sworn enemy?

Microsoft and Windows were never the enemy.

To quote Linus Torvalds from 1997: "I don't try to be a threat to Microsoft, mainly because I don't really see MS as competition. Especially not Windows - the goals of Linux and Windows are simply so different."

  • He got less humble later on when momentum started building behind Linux. To quote Linus Torvalds from 2003: “Really, I'm not out to destroy Microsoft. That will just be a completely unintentional side effect.

    • I mean, this whole thread is basically suggesting that 23 years later, improvements to Linux and self-sabotage by Microsoft are going to possibly destroy (or atleast, start to cause some bleeding) to Microsoft (in the gaming-market).

      This isn't Linux looking to destroy MS, this is mostly Valve understanding the requirement for an OS that won't be able to become predatory to them and their business model in a single system update.

  • Personally I used to be a Linux zealot back in the early 2000s, then I actually learned to program C++ and dove a bit into OS architecture... I realized why Linux on the desktop always sucked.. Not because of some dastardly conspiracy by Microsoft, but because of the very basic fact that server people and vendors held the developer purse strings and they drove the engineering decisions.

    Let's take a simple example.. to send a network packet to a different machine, you just call into the Linux kernel, which dispatches your stuff directly to the network card, and you're done. Pretty simple. However if you want to send a message to your neighboring X11 window, you have to go into the kernel to do IPC, which then somehow dispatches your message to the server process, unblocks and schedules the message pump in X11, which finds your window, then once again you go back into the kernel... then your target process is scheduled, so on and so forth.

    Wildly inefficient, yet Linux never got proper good IPC merged (until binder), low latency audio sucked, and none of this coordination logic or audio processing got in the kernel.

    Why? Because servers don't need that stuff and some server engineer isn't going to know or care about your use case, you're just small fry, and none of the stuff you do is worth taking on technical risk or slowing down server workloads.

  • The goal was to be able to patch and fix the systems I was using, and swap out bits and pieces as I wanted. And that seems to be less and less possible on Linux these days, as you have these tightly vertically-integrated stacks where everything depends on the latest version of everything else.

  • We are so far removed from 1997 that this statement means nothing.

    > the goals of Linux and Windows are simply so different.

    So different that Windows muscle memory works on most main stream Linux UI's, Many (most?) Steam games run on Linux, and now we have Windows in the Linux kernel.

What is the purpose of achieving victory? Is it to produce the software that works better or is it to stick your fingers in your ears and lalala the loudest?

Windows copied futexes from Linux first, anyway.

If you are refusing to have a stable architecture, then you will maintain architecture of your enemy

I mean the NT kernel was never really the enemy, it was the company behind it.

Not really, in the drunken happiness to have games, Linux users keep forgetting those are games developed on game studios that the only place there are GNU/Linux installations running are their MMO servers.

It is no different from arguing how Linux is getting better GameCube games with Dolphin.

Also Valve is only as good as its current management is still around, eventually like any other company time will pass, and new warm bodies will take other decisions.

interface and architecture may influence each other, but interface doesn’t determine architecture