if linux people focused on offering compelling ecosystem for app/game distribution, they wouldn't need to bloat their os with slow and bloated emulators like wine
the reason why linux isn't gaining shares on steam anymore is because valve openly said linux has no ecosystem and is forced to emulate windows -- proton
The alternative is expecting companies to make native ports for what would be less than 1% of their userbase - and the handful that have done so haven't done it well, and even if they did it well it wouldn't change any outcomes for them.
Before Wine actually got good, the few "native" ports we had of major games on Linux were poorly optimised and often worse than just running the Windows versions in Wine.
Sometimes you gotta take what you can get. Valve's approach to invest in Wine means I don't need to dual boot any more. Native games are the cherry on top.
>the reason why linux isn't gaining shares on steam anymore
Did anyone ever think Linux had any kind of comparable gaming ecosystem? lol
Valve invests in Linux as a safety net in case Microsoft ever flicks a switch and forces all game distribution through the Windows Store or similar.
> The alternative is expecting companies to make native ports for what would be less than 1% of their userbase - and the handful that have done so haven't done it well, and even if they did it well it wouldn't change any outcomes for them.
Valve decided to seek short term gains instead of thinking of a long term strategy by working with linux people to develop a nice ecosystem with libraries / drivers / app distribution
They could collaborate with Epic/Unity to facilitate linux builds
Valve went selfish and the result is here, linux share isn't growing, despite massive efforts from microsoft to kill themselves with vista, windows 8, and window 10 massive spyware drama and now the updates that break gaming
What if windows 11 is again a free upgrade and completely breaks wine? by introducing massive architecture changes
That'll be the death of wine and linux gaming, because no thought went into securing a nice and flourish ecosystem
> Valve decided to seek short term gains instead of thinking of a long term strategy by working with linux people to develop a nice ecosystem with libraries / drivers / app distribution.
The part that you suggest they should do "instead" is exactly what they have been doing. As far as I know, every game by Valve is native on Linux, along with their source engine.
> They could collaborate with Epic/Unity to facilitate linux builds
Both Unreal Engine and Unity can export games for Linux. Both seem to be able to be run on Linux for development as well. What more is needed?
> What if windows 11 is again a free upgrade and completely breaks wine?
There is literally nothing Microsoft could do to break wine; it isn't their software. If Microsoft breaks backwards compatibility, no existing software for Windows would run on the new version. Linux + WINE would be the best option for running the majority of Windows software with the most recent updates (one could of course still use older versions of Windows instead, but that's a bad idea long term).
You seems to have better ideas how to grow linux ecosystem
By looking at steam stats it doesn't seems to work, but i'll trust your judgement since it seems to.. not work at all.. but that might be the goal, to waste time, effort, money, and they gotta justify the 30% tax somehow, hey we are working on things nobody care about!
Wine is not an emulator, it is a compatibility layer for Windows system calls on a Unix-like platform. If something runs on wine, the performance overhead should be unnoticeable/very small for the typical user.
A compatibility layer wouldn't require that you essentially emulate the same file system layout, registry and functionality. It is basically emulating a Windows environment.
* Most nontrivial Windows program would get very confused if exposed to a trivially mapped Unix filesystem. It's not so bad if every program would use environment variables to locate stuff, but you can't discount the possibility that some of them hardcode paths. Also, application data in Windows is usually kept in a common folder, while in Unix filesystems it is usually split across `/usr/bin`, `/usr/share`, `/usr/lib` and so on.
* Many Windows applications store their configuration in the registry. That part is not too bad though; it should be completely doable in userspace.
* The application might issue system calls that have different semantics, or that don't even exist on Linux. TA is significant because it paves the way to an efficient implementation of one of these system calls.
> Most nontrivial Windows program would get very confused if exposed to a trivially mapped Unix filesystem. It's not so bad if every program would use environment variables to locate stuff, but you can't discount the possibility that some of them hardcode paths. Also, application data in Windows is usually kept in a common folder, while in Unix filesystems it is usually split across `/usr/bin`, `/usr/share`, `/usr/lib` and so on.
The application data in windows would not be the same as `/usr/` paths. It would be the equivalent of `~/.config` and `~/.local`. The last thing anyone in Linux would want is for Windows to start populating their system folders, let alone probably creating hundreds of top-level folders in their `~/.config` or `~/.local` directory.
> Many Windows applications store their configuration in the registry. That part is not too bad though; it should be completely doable in userspace.
The Windows registry is an atrocious monster that should have died already. You can rarely ever truly delete an app in Windows, as there will be sometimes hundreds of registry keys leftover.
> TA is significant because it paves the way to an efficient implementation of one of these system calls.
If there is mutual benefit outside of Windows, then sure why not. If it is built just for better Wine compatibility with Windows then I hope to see a rant by Linus telling them how ridiculous they are.
Sorry, my bad here. Of course, only the binaries and static assets are stored in C:\Program Files. Your point is the perfect argument though for why Wine emulates a Windows file system hierarchy.
I don't like the registry either. My `not too bad` refers to the effort required to support it. Wine should make it possible though give each application its own copy of the registry. This copy could be nuked along with the application when it is uninstalled.
Linus doesn't like a lot of things. ZFS for example. It certainly sucks to maintain out-of-kernel patches, but if there is enough benefit, someone will do it. And it would be actually pretty sweet and ironic if Windows applications run faster on the Linux desktop than on Windows. Also, I am optimistic that futex2 will find many applications outside of Wine.
That has nothing in common with emulating though. Running ARM code in x64 is emulating. If adding code were emulating than Linux is emulating Linux v0.1. Wine isn't an emulator. PCSX2 is an emulator.
The word "emulate" is overloaded, but because there's often an assumption of ISA emulation, Wine for a time called itself "WINE Is Not an Emulator" to prevent said assumption.
Taking "emulate" at its dictionary-definition, which is to imitate or copy, it's easy to argue that Wine is an emulator, because it copies and imitates the Windows ABI and API (the earliest versions of Wine even called itself a "WINdows Emulator"). They just happen to draw a hard line against emulating x86.
the reason why linux isn't gaining shares on steam anymore is because valve openly said linux has no ecosystem and is forced to emulate windows -- proton