> Try doing the same with a Linux binary that's just a year old.
I do it all the time. Works fine. Do you have a specific example or is this just a hastily constructed strawman?
Convert Linux to Windows
141–150 of 459 posts
Re: Convert Linux to Windows
#142The 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.
Re: Convert Linux to Windows
#143Wine/Proton is basically Linux Subsystem for Windows.
Re: Convert Linux to Windows
#144Earlier quoted context omitted.
Speak for yourself. I have been using Linux for a decade and would want nothing more if standalone application setups like those in Windows became the norm of software distribution. Centralized package management is a curse. Apps should be responsible for their own updates, not the OS.
> Apps should be responsible for their own updates, not the OS. Distros are not quite "the OS". You don't need a distro to run Linux. The role distros play as far as Linux applications are concerned is more like an app store in the Windows (or Mac) world. Of course Apple has locked down their smartphones that way basically since their inception, and their desktop OS has been becoming more and more like that. So has W…
> Of course Apple has locked down their smartphones that way... So has Windows.
Is that where we want desktop Linux to go?
Re: Convert Linux to Windows
#145> 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.
Depends. Proton and CrossOver are dead easy, especially for the supported apps.
Easy to use? Sure. Simple? No way.
Re: Convert Linux to Windows
#146Earlier quoted context omitted.
https://docs.flathub.org/docs/for-app-authors/requirements says, > Windows application submissions that are using Wine or any submissions that aren't native to Linux desktop and is using some emulation or translation layer will only be accepted if they are submitted officially by upstream with the intention of maintaining it in official capacity. Although, I am curious why; they don't seem to have a general problem w…
Probably because it's implicitly pirated. No one is sharing windows freeware this way, because there's no demand for it. It'll be MS Office, Photoshop, CAD, etc. -- stuff for which there's still no good OSS alternative, and for which the barrier to entry is high. It would take a large organization with enough connections to cut through this. You'd probably need to cut a deal so you could distribute their software, an…
I am just thinking out loud. Wouldn't it be better then to just share the reproducible recipes similar to sharing Dockerfiles? For wine, specifically, it could be similar to just using FROM wine-1.23. As long as we keep the recipes maintained and "pinned" to their old dependencies.
I think this could work as a translation layer because containers already abstract away everything on syscall level.
There must be just a GUI for that, which can create multiple sandboxes easily, per application, and remember what you configured and installed there (and add it to the Winefile).
In regards to the sharing serials problem: You can easily diff the .reg file that wine adds there and if anything pops out in \\software, you can assume this is a custom field and offer it as an environment variable for the container?
Re: Convert Linux to Windows
#147Earlier quoted context omitted.
The concept of containers for Windows applications running in WINE is called "bottles." https://support.codeweavers.com/en_US/2-getting-started/2-in... I believe it started with Cedega, but I could be wrong. That's where I first recall encountering it.
TIL. I'm gonna check this out. It's good to see that people are already working on this, because it's one of those things that, to me, just makes a lot of sense. You'd think that with the all of the layers of abstraction we have nowadays, it should be possible to run software on any underlying system in an ergonomic fashion, even if it's not necessarily efficient.
It's extremely efficient: cold starting Word from an old Office suite is much faster than starting Libreoffice. It also uses less RAM.
A few years ago I purchased a few shrink-wrapped Office on ebay for each of the versions Wine claimed to support best, tested then with wine32 and wine64, and concluded the "sweet spot" was Office 2010 in wine32 (it may have changed, as wine keep evolving)
Yes, it's 15 years old software, but it works flawlessly with Unicode xkb symbols! Since it doesn't have any network access, and each app is isolated in a different user id, I don't think it can cause any problem.
And Ii I can still use vim to do everything I need and take advantage of how it will not surprise me with any unwanted changes, I don't see why I couldn't use say an old version of Excel in the same way!
Re: Convert Linux to Windows
#148Valve's Steam OS( and inspired distros) already basically does this. It's centered around games, but everything else( if your lucky) is natively supported in Linux.
You can run non games on Proton. Most things work.
Re: Convert Linux to Windows
#149Earlier quoted context omitted.
In 2005 the hot new Windows technology was .NET Framework 1.1 or 2.0. You can't just dump Framework 1.1's libraries next to the binary and expect it to work either, it needs to be installed properly.
The most recent .NET Framework still keeps 1.1 assemblies for compatibility. And yep, .NET sucked and eventually got semi-abandoned.
This must be from an alternate timeline. There is no way to call what is currently going on with .net anything other than 0% abandoned.
Re: Convert Linux to Windows
#150Earlier quoted context omitted.
TIL. I'm gonna check this out. It's good to see that people are already working on this, because it's one of those things that, to me, just makes a lot of sense. You'd think that with the all of the layers of abstraction we have nowadays, it should be possible to run software on any underlying system in an ergonomic fashion, even if it's not necessarily efficient.
It's extremely efficient: cold starting Word from an old Office suite is much faster than starting Libreoffice. It also uses less RAM. A few years ago I purchased a few shrink-wrapped Office on ebay for each of the versions Wine claimed to support best, tested then with wine32 and wine64, and concluded the "sweet spot" was Office 2010 in wine32 (it may have changed, as wine keep evolving) Yes, it's 15 years old softw…
It is interesting seeing Office suites from the 90s and wondering what really needed improved.
Google Docs pioneering “auto saving” in the cloud is the only one I can think of.