Live data from Hacker News

Loss32: Let's Build a Win32/Linux

loss32.org

151–160 of 493 posts

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

#151

This is a really cool idea. My only gripe is that Win32 is necessarily built on x86. AArch64/ARM is up and coming, and other architectures may arise in the future. Perhaps that could be mitigated if someone could come up with an awesome OSS machine code translation layer like Apple's Rosetta.

Not sure on Windows but with Wine you can totally use Win32 on arm.

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

#152
post #31

This is only ever relevant for proprietary software. Free software does not require a stable ABI. Great that wine exists but it should be useless. (That and Linux doesn't implement win32 and wine doesn't exclusively run on Linux.)

Stable interfaces and not being in versioning hell (cough libc) would actually be good for FOSS as well. If you make a piece of software today and want to package it for Linux its an absolute mess. I mean, look at flatpack or docker, a common solution for this is to ship your own userspace, thats just insane.

Agreed... I'm kind of a fan of AppImage/Flatpak/Snap (less Snap, but still)... even then, I don't use a lot of apps, and most of my variety is usually via Docker.

It's much more bloated than it should be, but the best way to reliably run old/new software in any given Linux.

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

#153

Earlier quoted context omitted.

Piracy. The consumer versions are filled with ads because most people don't pay for them.

Is this really the case? I feel like most windows users just bought a laptop with Windows already on it. Even if all home users were running pirated versions they would still become entrenched in the world of Windows/Office which would then lead to enterprise sales.

> Is this really the case? I feel like most windows users just bought a laptop with Windows already on it.

This is largely true in North America, UK and AUS/NZ, less true in Europe, a mixed bag in the Middle East and mostly untrue everywhere else.

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

#154
post #106
post #65

Earlier quoted context omitted.

It's really just glibc

It's really just not. GTK is on its fourth major version. Wayland broke backwards compatibility with tons of apps.

GTK update schedule is very slow, and you can run multiple major versions of GTK on the same computer, it's not the right argument. When people says GTK backwards compatibility is bad, they are referring in particular to its breaking changes between minor versions. It was common for themes and apps to break (or work differently) between minor versions of GTK+ 3, as deprecations were sometimes accompanied with the breaking of the deprecated code. (anyway, before Wayland support became important people stuck to GTK+ 2 which was simple, stable, and still supported at the time; and everyone had it installed on their computer alongside GTK+ 3).

Breaking between major versions is annoying (2 to 3, 3 to 4), but for the most part it's renaming work and some slight API modifications, reminiscent of the Python 2 to 3 switch, and it only happened twice since 2000.

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

#155

Earlier quoted context omitted.

> Alternatively, RemObjects makes Elements, also a RAD programming environment in which you can code in Oxygene (their Object Pascal), C#, Swift, Java, Go, or Mercury (VB) and target all platforms: .Net, iOS and macOS, Android, WebAssemblyl, Java, Linux, Windows. Wait you can make Android applications with Golang without too much sorcery?? I just wanted to convert some Golang CLI applications to GUI's for Android and…

> Wait you can make Android applications with Golang without too much sorcery?? Why don't you try it out: https://www.remobjects.com/elements/gold/

It's really price-y and I am not sure about if I could create applications for f-droid if they aren't open source and how it might go with something like remobjects.com/gold/

One of the key principles of f-droid is that it must be reproducible (I think) or open source with it being able to be built by f-droid servers but I suppose reproducibility must require having this software which is paid in this case.

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

#156
post #85
post #67

Earlier quoted context omitted.

I agree 100% with Linus. I can run a WinXP exe on Win10 or 11 almost every time, but on Linux I often have to chase down versions that still work with the latest Mint or Ubuntu distros. Stuff that worked before just breaks, especially if the app isn’t in the repo.

That’s actually an intentional nudge to make the software packaged by the distro, which usually implies that they are open source. Who needs ABI compatibility when your software is OSS? You only need API compatibility at that point.

Even open-source software has to deal with the moving target that is ABI and API compatibility on Linux. OpenSSL’s API versioning is a nightmare, for example, and it’s the most critical piece of software to dynamically link (and almost everything needs a crypto/SSL library).

Stable ABIs for certain critical pieces of independently-updatable software (libc, OpenSSL, etc.) is not even that big of a lift or a hard tradeoff. I’ve never run into any issues with macOS’s libc because it doesn’t version the symbol for fopen like glibc does. It just requires commitment and forethought.

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

#157
post #31

This is only ever relevant for proprietary software. Free software does not require a stable ABI. Great that wine exists but it should be useless. (That and Linux doesn't implement win32 and wine doesn't exclusively run on Linux.)

We exist in a world where proprietary software exists, and always will exist. I want to be able to run said software if it's the best tool for the job, not be hobbled by an idealistic stance of "all software should be free so we don't bother to support proprietary software".

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

#158
post #97
post #65

Earlier quoted context omitted.

It's really just glibc

Can't we just freeze glibc, at least from an API version perspective?

We definitely can, because almost every other POSIX libc doesn’t have symbol versioning (or MSVC-style multi-version support). It’s not like the behavior of “open” changes radically all the time, and you need to know exactly what source symbol it linked against. It’s really just an artifact of decisions from decades ago, and the cure is way worse than the disease.

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

#159
Someone please create a windows 7 like user interface or even XP like interface too and you got yourself a serious fan

I might seriously recommend it to newbies and like there is just this love I have for windows 7 even though I really didn't use it for much but its so much more elegant in its own way than windows 10

like it can be a really fun experiment and I would be interested to see how that would pan out.

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

#160
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

AppImage, theoretically, solves this problem (or FlatPak I guess). The issue would really be in getting people to package up dead/abandoned software.

https://zapps.app/ is another interesting thing in the space.

AppImage have some issues/restrictions like it cant run on older linux than one it was compiled on, so people compile it on the oldest pc's and a little bit of more quirks

AppImage are really good but zapps are good too, I had once tried to do something on top of zapp but shame that zapp went into the route of crypto ipfs or smth and then I don't really see any development of that now but it would be interesting if someone can add the features of zapp perhaps into appimage or pick up the project and build something similar perhaps.

Post reply on HN