Live data from Hacker News

Loss32: Let's Build a Win32/Linux

loss32.org

241–250 of 493 posts

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

#241
post #167

Earlier quoted context omitted.

The problem is not the APIs, it's symbol versions. You will routinely get loader errors when running software compiled against a newer glibc than what a system provides, even if the caller does not use any "new" APIs. glibc-based toolchains are ultimately missing a GLIBC_MIN_DEPLOYMENT_TARGET definition that gets passed to the linker so it knows which minimum version of glibc your software supports, similar to how Ap…

Yes, so that's why freezing the glibc symbol versions would help. If everybody uses the same version, you cannot get conflicts (at least after it has rippled through and everybody is on the same version). The downside is that we can't add anything new to glibc, but I'd say given all the trouble it produces, that's worth accepting. We can still add bugfixes and security fixes to glibc, we just don't change the APIs of…

It should not be necessary to freeze it. glibc is already extremely backwards compatible. The problem is people distributing programs that request the newest version even though they do not really require it, and this then fails on systems having an older version. At least this is my understanding.

The actual practical problem is not glibc but the constant GUI / desktop API changes.

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

#242

I think this project actually has merit and highlights the core issue. We have gone through one perceived reason after the other to try and explain why the year of the Linux desktop wasn’t this one. Uncharitably, Linux is too busy breaking and deprecating itself to ever become more than a server OS, and that only works due to companies sponsoring most the testing and code that makes those parts work. Desktop in all i…

Pretty sure it's Linux not being the default option

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

#243
post #74

Earlier quoted context omitted.

Wine Is Not an Emulator (WINE). It provides win32 APIs; your CPU will handle the instructions natively. There is no “probably” about it.

Whenever people bring this up I find it somewhat silly. Wine originally stood for "Windows Emulator". See old release notes ( https://lwn.net/1998/1112/wine981108.html ) for one example: "This is release 981108 of Wine, the MS Windows emulator." The name change was made for trademark and marketing reasons. The maintainers were concerned that if the project got good enough to frighten Microsoft, they might get sued fo…

The problem is the word "emulator" itself. It's a very flexible word in English, but when applied to computing, it very often implies emulating foreign hardware in software, which is always going to be slow. Wine doesn't do that and was wise to step away from the connotations.

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

#244
post #50

This might offend some people but even Linus Torvalds thinks that the ABI compatibility is not good enough in Linux distros, and this is one of the main reasons Linux is not popular on the desktop. https://www.youtube.com/watch?v=5PmHRSeA2c8&t=283s

Android makes a sport of breaking ABI compatibly and it hasn't stopped it from being the most popular mobile OS

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

#245

Earlier quoted context omitted.

> it can be a really fun experiment and I would be interested to see how that would pan out. It would fail, and just be another corpse in the desktop OS graveyard. https://en.wikipedia.org/wiki/Hitachi_Flora_Prius https://www.osnews.com/story/136392/the-only-pc-ever-shipped... https://en.wikipedia.org/wiki/Linspire Unless you ship your own hardware or get a vendor to ship your OS (see the above), and set up so the us…

Hm I see the confusion, what I was proposed was for something like loss32 to have a window manager / desktop environmnet which looks like windows 7 Loss32 is itself a linux distro and thus there should technically be nothing stopping it from shipping everywhere I think you were assuming that I meant create a whole kernel from scratch or something but I am just merely asking a loss32 reskin which looks like windows 7…

I think fundamentally I disagree with your optimism. I've seen a number of these come and go over the decades. I do not think making something that looks like Windows would be sufficient to be successful.

> you were assuming that I meant create a whole kernel from scratch or something

No, making Linux run reliably on random laptops is already a monumental challenge.

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

#247
post #4

Unironically, yes. It's time that Microsoft taste their own medicine of embrace, extend, and extinguish.

Here me out: Microsoft switches to Linux kernel for Windows 13.

(also Microsoft has been heavily embracing Linux and open source in the last decade)

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

#248
post #174
post #79

Earlier quoted context omitted.

To quote a friend; "Glibc is a waste of a perfectly good stable kernel ABI"

Kind of funny to realize, the NT kernel ABI isn’t even all that stable itself; it is just wrapped in a set of very stable userland exposures (Win32, UWP, etc.), and it’s those exposures that Windows executables are relying on. A theoretical Windows PE binary that was 100% statically linked (and so directly contained NT syscalls) wouldn’t be at-all portable between different Windows versions. Linux with glibc is the c…

Apparently there are 3 kinds of Windows containers, one using HyperV, and the others sharing the kernel (like Linux containers)

https://thomasvanlaere.com/posts/2021/06/exploring-windows-c...

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

#249
post #48

Earlier quoted context omitted.

I don’t think Witcher 3 or Cyberpunk 2077 have Linux builds available for the common folk? Cyberpunk has a ARM64 Mac build, though.

Huh, I could have sworn Witcher 3 did, but maybe I am misremembering it merely releasing without DRM.

Witcher 2 had a Linux native build, but never Witcher 3.

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

#250

Earlier quoted context omitted.

The difference is that you can statically link GTK+, and it'll work. You can't statically link glibc, if you want to be able to resolve hostnames or users, because of NSS modules.

Static linking itself doesn't prevent modules. There's https://github.com/pikhq/musl-nscd for example

Not inherently, but static linking to glibc will not get you there without substantial additional effort, and static linking to a non-glibc C library will by default get you an absence of NSS.
Post reply on HN