21–30 of 459 posts
> We also already have a simple way to run Windows applications, Wine. Are you high? There is nothing simple about Wine. It's at once a kludgy mess and a technical masterpiece, what it isn't is simple.
I think this attitude to the Linux ABI is maybe out of date - with a 20 year old Linux binary, that's only 2005, so it will almost certainly be using glibc (no archaic libc5). Glibc has great backwards compatibility and the binary will work on any glibc distribution today as long as you have all the .so's, same as needing the .dll's on Windows.
There are few issues: 1. GNU libc is an exception in the world of compatibility. 2. You can't just dump a bunch of GTK libraries next to the binary and expect it to work. These libraries often expect very specific file system layouts.
> NOTE: I am not against Apple or Microsoft. They have amazing engineers! I don't think they're being malicious. Rather, I think the incentives for these companies are improperly aligned. Improperly aligned incentives? Who gets to say what that is? Is it "improper" to maximize profit per their own board's guidelines? I have a feeling OP has some predefined notion of nobility they expect people to somehow operate unde…
From the standpoint of the end user the incentives are improperly aligned. If they had made hammers they would have included licence agreements for their use with specific types of nails and actively prevented users from using competitor's nails. They also would have made sure yesterday's hammer would not be sufficient to hammer in today's nail, they would have added camera's to observe what the user was doing so as to sell 'targeted' advertising - during which the hammer would not strike any nails but would sing like the singing sword in Who Framed Roger Rabbit - and they would have made sure that no matter how agile the user was with his hammer the thing would never be 100% reliable.
Of course hammers are far less complex than computers and operating systems. Maybe this is because they're made by tool manufacturers and not by tech companies, maybe it is because they're old tech. A modern hammer is what Ford would have produced if he had listened to his customers who asked him for a faster horse so maybe there is a whole world of construction efficiency waiting for the Henry Ford of Hammersmiths. Or, maybe - probably - sometimes it is better to get that faster horse, that titanium hammer or that free software operating system which works for you and nobody else.
Earlier quoted context omitted.
> shipping all dependencies (e.g. shipping a container image) gives perfect binary compatibility on Linux That doesn’t work for GUI programs which use a hardware 3D GPU. Linux doesn’t have a universally available GPU API: some systems have GL, some have GLES, some have Vulkan, all 3 come in multiple versions of limited compatibility, and optional features many of them are vendor specific. In contrast, it’s impossible…
Note that this also underlines that the post's premise of Windows having a simple stable ABI - win32 sure is stable, but that's not what applications are coded against anymore. Sure, you can run a 20 year old app, but that is not the same as a current app still working in 20 years, or even 5.
Not sure I follow. Sure, most modern programs are not using old-school WinAPI with GDI, but the stuff they added later is also rather stable. For example, the Chromium-based browser I’m looking at uses Direct3D 11 for graphics. It implements a few abstraction layers on top (ANGLE, Skia) but these are parts of the browser not the OS.
I view all that modern stuff like Direct3D, Direct2D, DirectWrite, Media Foundation as simply newer parts of the WinAPI. Pretty sure Microsoft will continue to support them for long time. For example, they can’t even deprecate the 23 years old DirectX 9 because still widely used, e.g. current version of Microsoft’s own WPF GUI framework relies on Direct3D 9 for graphics.
> Thesis: We should create a distro of Linux that runs Windows binaries by default via Wine. "We should"? Do you mean me? I have a ton of my own projects I'm busy with. Why didn't you say "I should create..."? There's nothing stopping you implementing this if you think it's a good idea. Do the work yourself.
That makes no sense: shipping all dependencies (e.g. shipping a container image) gives perfect binary compatibility on Linux, which is what flatpak/snap/appimage do. It can also be achieved with static linking and by shipping all needed library and using a shell script loader that sets LD_LIBRARY_PATH. Also glibc (contrary to the author's false claims) and properly designed libraries are backwards compatible, so in p…
The article's main premise isn't bad, but it's full of weird technical inaccuracies. At certain points he talks about syscalls, libc (I'm assuming glibc), PE vs. ELF, and an 'ABI'. Those are all different things, and IIUC all are fairly stable on Linux, what isn't stable is userspace libraries such as GTK and QT. So, what are we talking about? There's also statements like this, which, I'm not a kernel developer but t…
> A small modification to the "exec" family of system calls to dispatch on executble type would allow any Linux application to fork an exec a Windows application with no effort.
That isn't "too good to be true", it's so good it is false – no kernel modification is required because the Linux kernel already supports this via binfmt_misc. You just need to configure it. And depending on how you installed Wine, you may find it has even already been configured for you.
Why not use ReactOS?
> Imagine we made a new Linux distro. This distro would provide a desktop environment that looks close enough to Windows that a Windows user could use it without training. You could install and run Windows applications exactly as you do on Windows; no extra work needed. Why not use ReactOS?