Live data from Hacker News

Loss32: Let's Build a Win32/Linux

loss32.org

441–450 of 493 posts

Re: Loss32: Let's Build a Win32/Linux

#441

Earlier quoted context omitted.

> but Linux hardware support is still crap What are you talking about? Everything for desktops work out of the box unless you have something weird and proprietary, and even then most distros have support anyway.

By desktop I include laptops (many don't work out of the box) but larger systems can be weird too. Just the choice of CPU can decide whether hibernate or suspend works at all. There's a large ecosystem of accessories which have no Linux support. Video cards have been a nightmare on Linux for decades, famously the reason Torvalds gave Nvidia the finger. Even when something's technically supported, it may require obscu…

> Video cards have been a nightmare on Linux for decades, famously the reason Torvalds gave Nvidia the finger.

What are you talking about... The situation is the same as on Windows, an officially supported and maintained proprietary driver maintained by Nvidia. Unless you're trying to run a 12+ year old car, it'll work fine. AMD on the other hand is amazingland and works perfectly, officially supported and maintained open source driver. I LOVE it.

> bit-twiddling

Never happened.

Re: Loss32: Let's Build a Win32/Linux

#442

Crazy how, thanks to Wine/Proton, Linux is now more compatible with old Windows games than Windows itself. There are a lot of games from the 90s and even the 00s that require jumping through a lot of hoops to run on Windows, but through Steam they're click-to-play on Linux.

> There are a lot of games from the 90s and even the 00s that require jumping through a lot of hoops to run on Windows What are some examples?

I remember not getting Close Combat 2 (from 1997) running on Windows 10 some years ago but I did getting it running under Wine, albeit with some tweaks.

Whether that was a Windows compatibility issue or potentially some display driver thing, I'm not sure. (90's Windows games may have used some DirectDraw features that just don't get that much attention nowadays, which I think may have been the issue, but my memory's a bit spotty.)

Re: Loss32: Let's Build a Win32/Linux

#443

Earlier quoted context omitted.

By desktop I include laptops (many don't work out of the box) but larger systems can be weird too. Just the choice of CPU can decide whether hibernate or suspend works at all. There's a large ecosystem of accessories which have no Linux support. Video cards have been a nightmare on Linux for decades, famously the reason Torvalds gave Nvidia the finger. Even when something's technically supported, it may require obscu…

> Video cards have been a nightmare on Linux for decades, famously the reason Torvalds gave Nvidia the finger. What are you talking about... The situation is the same as on Windows, an officially supported and maintained proprietary driver maintained by Nvidia. Unless you're trying to run a 12+ year old car, it'll work fine. AMD on the other hand is amazingland and works perfectly, officially supported and maintained…

https://en.wikipedia.org/wiki/Dunning%E2%80%93Kruger_effect

Re: Loss32: Let's Build a Win32/Linux

#444

Earlier quoted context omitted.

By desktop I include laptops (many don't work out of the box) but larger systems can be weird too. Just the choice of CPU can decide whether hibernate or suspend works at all. There's a large ecosystem of accessories which have no Linux support. Video cards have been a nightmare on Linux for decades, famously the reason Torvalds gave Nvidia the finger. Even when something's technically supported, it may require obscu…

> Video cards have been a nightmare on Linux for decades, Again, I question your experience in this regard. Do you actually use dGPUs on Linux, or are you repeating a 14-year-old meme? GPU support on Linux is more comprehensive than macOS, and if you don't need DirectX it's arguably better than Windows too. Mesa drivers are unparalleled by Apple or Microsoft, in a myriad of ways.

My experience is using Linux as my primary desktop OS for 25 years, for gaming, 3D rendering, and web browsing. I'm also a programmer and systems engineer, and I've created Linux distributions, as well as contributed over a thousand packages and ports to other distros, and patched/backported drivers in the kernel. I'm not going to detail every single video driver issue I've run into, as I don't want to write a book just to prove to a random person on the internet that Linux does, in fact, have a history of issues with graphics cards and video subsystems. A simple Google search can provide more than enough examples.

But more than that, it's simple logic: hardware manufacturers often don't often release specs or proprietary firmware blobs, forcing kernel hackers to reverse engineer in order to support a device, which often is too difficult, not to mention there's only so many kernel hackers and a lot of devices and hw revisions. There's a famous YouTube video of the most famous kernel hacker telling Nvidia to go fuck itself for this very reason.

Re: Loss32: Let's Build a Win32/Linux

#445
post #303

Earlier quoted context omitted.

When WSL first came out, I realized that Windows might be Linux + Wine in 20 or 30 years. Nowadays, with the Windows team barely able to produce a functional UI, what's happening with the NT kernel? Is it all graybeards back there? When they retire, the stability of Windows going to be in trouble, which is important for the things that really pull in the money. It'll get real bad, then they'll give up and move to an…

The NT kernel continues to evolve. The recent examples I can think of are VBS, HCVI, and Kernel DMA Protection. No reason to dump a very good kernel.

Idle curiosity, but: does Linux have similar offerings to HVCI?

Re: Loss32: Let's Build a Win32/Linux

#446

Thing is, I want the opposite. I want the NT/2k/w7 kernel and XFCE on top. NT kernel is infinitely better designed and has much better support on latest intel/amd hardware than Linux. And XFCE is much better than modern windows ui.

> has much better support on latest intel/amd hardware In what way?

Close Linux laptop. Wait 1 week. Open it. 100% Dead. Do same to windows laptop. 60% chance it is alive — better. MacBook? 100%

Re: Loss32: Let's Build a Win32/Linux

#447

Earlier quoted context omitted.

> has much better support on latest intel/amd hardware In what way?

Close Linux laptop. Wait 1 week. Open it. 100% Dead. Do same to windows laptop. 60% chance it is alive — better. MacBook? 100%

That's really not the case overall. My experience: Linux - sure, the battery won't last a week in sleep, but it will revert to hibernation and start anyway. Windows - got 2 laptops which just won't go to sleep automatically since w11 - either force hibernation, or it will overheat in a bag and drain in hours. Mac - constant wakeups to connect to the internet (that I can't disable even though I tried many times) drain the battery in days.

Re: Loss32: Let's Build a Win32/Linux

#448
post #298

Earlier quoted context omitted.

Exactly, Gnome/Linux or KDE/Linux would make a lot more sense.

Both are being baked https://distrowatch.com/table.php?distribution=gnomeos https://distrowatch.com/table.php?distribution=kdelinux The question is if either will catch any interest and if so, what will happen to regular distributions.

[deleted]

Re: Loss32: Let's Build a Win32/Linux

#449

Earlier quoted context omitted.

Ok, so you agree with him except where he says “in a VM” because you say you can also do it “in a container”. Of course, you both leave out that you could do it “on real hardware”. But none of this matters. The real point is that you have to compile on an old distro. If he left out “in a VM”, you would have had nothing to correct.

I'm not disagreeing that glibc symbol versioning could be better. I raised it because this is probably one of the few valid use cases for containers where they would have a large advantage over a heavyweight VM. But it's like complaining that you might need a VM or container to compile your software for Win16 or Win32s. Nobody is using those anymore. Nor really old Linux distributions. And if they do, they're not rea…

>As C/C++ programmer, the thing I notice is ... the people who complain about this most loudly are the web dev crowd who don't speak C/C++, when some ancient game doesn't work on their obscure Arch/Gentoo/Ubuntu distribution and they don't know how to fix it. Boo hoo.

You must really be behind the times. Arch and Gentoo users wouldn't complain because an old game doesn't run. In fact the exact opposite would happen. It's not implausible for an Arch or Gentoo user to end up compiling their code on a five hour old release of glibc and thereby maximize glibc incompatibility with every other distribution.

Re: Loss32: Let's Build a Win32/Linux

#450

Earlier quoted context omitted.

I'm not disagreeing that glibc symbol versioning could be better. I raised it because this is probably one of the few valid use cases for containers where they would have a large advantage over a heavyweight VM. But it's like complaining that you might need a VM or container to compile your software for Win16 or Win32s. Nobody is using those anymore. Nor really old Linux distributions. And if they do, they're not rea…

> But they'll happily take a paycheck for writing a bunch of shit Go/Ruby/PHP code that runs on Linux 24/7 without downtime - not because of the quality of their code, but due to the reliability of the platform at _that_ particular task. But does the lack of a stable ABI have any (negative) effect on the reliability of the platform?

Only for people who want to use it as a desktop replacement for Windows or MacOS I guess? There are no end of people complaining they can't get their wifi or sound card or trackpad working on (insert-obscure-Linux-distribution-here).

Like many others, I have Linux servers running over 2000-3000 days uptime. So I'm going to say no, it doesn't, not really.

Post reply on HN