> I can pull down a 20 year old exe and still run it today on Windows. Try doing the same with a Linux binary that's just a year old.
How this can be considered a good thing?
Convert Linux to Windows
231–240 of 459 posts
Re: Convert Linux to Windows
#232I have points to burn, so I'll post, because I know this will scratch some folks the wrong way- apologies in advance. I use Windows. In fact, I like Windows. I know lots of (ok, more than 5) greybeards who feel exactly the same way. I don't want Linux to be Windows, but I also don't want Linux on my personal desktop either. I have a Mac Mini M1 on my desk, and I use that for the things it's good for, mainly videoconf…
I have the same experience. I've tried to use Linux as a desktop since 2000. And tried and retried. Year after year and distro after distro.
Until I realized the desktop experience on Linux will never be on par with Windows, that I need things to just work instead of constantly fiddling to make them work.
I discovered that Gimp is not Photoshop and Libre Office is not MS Office. And I discovered that running things under Wine are not always great.
I discovered I need and want to run Windows software.
I discovered that I like the hardware to work out of the box.
For me, Windows is great as a desktop. And I develop microservice based apps that run under Linux containers/Kubernetes in cloud.
Docker Desktop, WSL and Hyper-V are taking care of all of my potential Linux needs.
I also have a MacBook Pro, but I don't care much about the OS, I mainly bought it for the good battery life and use it to browse the web and watch movies in bed or on the couch or while traveling.
Re: Convert Linux to Windows
#233> I can pull down a 20 year old exe and still run it today on Windows. Try doing the same with a Linux binary that's just a year old. How this can be considered a good thing?
Backwards compatibility is generally a good thing. It certainly has its downsides (like security) which can be more or less of a concern depending on backwards compatibility techniques.
Re: Convert Linux to Windows
#234The shitty thing is, this just encourages closed source software on the open platform, giving vendors another reason not to port natively. Good luck with the hellscape you're building.
I do not care about access to source code or not. I use apps, I do not want to look at their source code or compile them.
So open/close, I do not care as long as it does what I need, how I need.
And I feel I am not the only one thinking like this.
Re: Convert Linux to Windows
#235Seems like it would be easier to identify and fix cases of ABI compat breakage in the Linux userland than to convert Linux to Windows.
OpenSSL
Re: Convert Linux to Windows
#236To the extent binary distribution is "unstable" on Linux, it's because users aren't expected to just download random binaries from wherever, as is normal on Windows (and Mac, for that matter). Users are expected to either obtain binaries from their distro, or compile them from source. In either case, all of the issues about binary distribution being "unstable" are invisible to users. Which is the point. People who wa…
>People who want the broken Windows software model can just..run Windows
That's what billions of people do. :)
Re: Convert Linux to Windows
#237Earlier quoted context omitted.
In Winapi land, the equivalent of "the c library" is NTDLL,its wrappers and other supporting libs (advapi32,userenv,etc... and Win32 specific libs which I consider equivalent to X11 libs). MSVCR in my opinion is there to provide the stdlib for C/C++ programs. In Linux land, the library that provides the C stdlib also wraps syscalls, in Windows, the C stdlib is a wrapper/interface for Windows api's. My opinion is that…
Very well explained, thank you. > Let Linux be Linux and Windows be Windows. They're both great if you appreciate them for what they are and use the accordingly. What if you technically prefer the Windows way, but are worried about Microsoft's behavior related to commercial strategy, lock-down, privacy...? The author envisions a system that's technically stable as Windows, yet free as Linux.
Microsoft has always been end-user-hostile. You hack around it :)
Reverse-engineer it's undesirable behavior, mitigate it. The real stuff that scares me is hardware-based (secure enclave computing for example) and legal measures it is taking to prevent us from hacking it.
ReactOS exists, as does Wine. Linux is a purely monolithic Kernel, unlike NT which is a hybrid that has the concept of subsystems built into it. Linux would have to have the concept of subsystems and have an NT-interop layer (probably based off of Wine), the advantage over Wine I fail to see.
In the end, where is the demand coming from I ask? Not from Linux devs in my opinion. I suppose a Wine focused distro might please folks like you, but Wine itself has lots of bugs and errors even after all these years. I doubt it is keeping up with all the Windows11 changes even, what the author proposes, in my opinion is not practical, at least not if you are expecting an experience better than ReactOS or Wine. If it is just Win32/winapi interop layer, it might be possible, but devs would need to demand it, otherwise who will use it?
Linux users are the most "set in their way" from my experience, try convincing any Linux dev to stop using gtk/qt and write apps for "this new Windows like api interface to create graphical apps".
but ultimately, there is no harm in trying other than wasted time and resources. I too would like to see an ecosystem that learns and imitates windows in many ways (especially security measures).
Re: Convert Linux to Windows
#238I've read the article and the comments with interest. I just have a question: if Windows ABI is so stable that 20-year-old programs are guaranteed to run, why are there computers with Win95 or NT that nobody dares touching lest some specific software stops working? I see plenty of these in industrial environments, but also in public libraries, corporate databases, etc.
I know in my use case all these ancient machines are nessessary for interacting with some ancient hardware, not a case where wine is particularly useful.
Re: Convert Linux to Windows
#239Re: Convert Linux to Windows
#240Java already solved this problem, for the most part. This whole ABI nonsense really grinds my gears. It's essentially just a result of the silly decision to compile software into dubious blobs and ship those to users. You could get rid of an awful lot of malware and massively simplify software distribution if you were to distribute a platform agnostic intermediary representation of source code that preserves enough s…
> Shipping binary files is just plain bad in every way. Aren't .class and .jar files "binaries"? > Java already solved this problem, for the most part Maybe, just maybe, there are some drawbacks that mean that in fact it's not solved. Otherwise perhaps Java would've completely obsoleted C, C++. Some of us design applications which can't tolerate the worst case GC pauses, for example. Some of us design applications wh…
>Aren't .class and .jar files "binaries"?
Not at all. jar is just a zip with a different extension +some metadata in META-INF (including dependencies). class are compiled java files but they do contain all kinds of metadata, including variable names and debug info (if you choose to retain it). they contain all methods and fields with their original names (along with annotations), so the reflection APIs work. Decompiling a class file is trivial to a point the original line numbers can be restored.
>Otherwise perhaps Java would've completely obsoleted C
Java does require a managed runtime written mostly in C/C++.
>Some of us design applications which can't tolerate the worst case GC pauses
The current breed or low latency GCs w/o a stop-the-world phase should suffices for a large set of applications.
>we can't afford to spend extra time heap-allocating nearly everything.
That has not been an issue for quite some time, heap allocation can be elided, and under normal condition is just a pointer bump. Per thread private allocation is by far the most common case - the garbage collection of non old-gen referenced objects is totally trivial too (i.e. memset). Even shared (cross thread/area) allocation is a CAS'd bump in most cases. Note: copy/generational garbage collectors copy objects that are referenced by non-young-gen ones to another area, then zero the original area.
With that being said - Java (and managed languages) are no panacea.