11 ms·

Agree. Had a few games on Steam crap out with the native version, forced it to use proton with the Windows version, everything worked flawlessly. Developers na

Agree. Had a few games on Steam crap out with the native version, forced it to use proton with the Windows version, everything worked flawlessly. Developers natively porting to linux seem to be wasting their time. Funnily enough with wine we kinda recreated the model of modern windows, where Win32 is a personality on top of the NTAPI which then interfaces with the kernel. Wine sits between the application and the zoo of libraries including libc that change all the time.

dleslie 4y ago
FWIW, targeting proton is likely the best platform target for future Windows compatibility too.
Aachen 4y ago
> Developers natively porting to linux seem to be wasting their time. Factorio runs so much better than any of this emulationware, it's one of the reasons I love the game so much and gifted licenses for friends using Windows. Some software claims to support Linux but uses some tricks to avoid recompiling and it's always noticeable, either as lag, as UI quirks, or some features plainly don't work because all the testers were windows users. Emulating as a quick workaround is all fair game but don't ship that as a Linux release. I appreciate native software (so long as it's not java), and I'm also interested in buying your game if you advertise it as compatible with WINE (then I'm confident that it'll work okay and you're interested in fixing bugs under emulation), just don't mislead and pretend and then use a compatibility layer.
- jbverschoor 4y ago
  Wine Is Not an Emulator
  - bombcar 4y ago
    I believe it now actually is again, or was, or something. It's a question when dealing with Win16 and now Win32 (Windows-on-Windows).
  - caffed 4y ago
    Ha Perfect! Yes, wine is an Windows binary executor with library translation. https://wiki.winehq.org/FAQ#Is_Wine_an_emulator.3F_There_seems_to_be_disagreement https://wiki.winehq.org/FAQ#Is_Wine_an_emulator.3F_There_see...
  - delusional 4y ago
    Sure, but it's also WINdows Emulator
    - ink_13 4y ago
      No, it's not, because it's not a emulator
      - hot_gril 4y ago
        "In computing, an emulator is hardware or software that enables one computer system (called the host) to behave like another computer system (called the guest)." Sounds like Wine.
        wvenable 4y ago
        Wine isn't emulating a computer. It's another implementation of the Win32 API. Just like Linux isn't a Unix emulator.
        hot_gril 4y ago
        There is a Linux emulator for Unix (namely FreeBSD), and it's one of the first examples in the Wikipedia article on emulation. https://www.openbsd.org/60.html https://www.openbsd.org/60.html shows OpenBSD removing "Linux emulation." Linux was never designed to be the same as Unix, just similar. But it's more popular now, so Unix users found utility in pretending to run Linux.
    - jbverschoor 4y ago
      Well you know.. I guess I'm OG when it comes to naming.
  - gorkish 4y ago
    Except sometimes on aarch64
- WarChortle 4y ago
  In case you weren't aware Wine is not an emulator, it is a compatibility layer. The whole point of wine is to take a native Windows app, only compiled for Windows and translate its Windows calls to Linux calls.
  - Wowfunhappy 4y ago
    > In case you weren't aware Wine is not an emulator, it is a compatibility layer. Ehhh. I know it’s in the name, but I feel like the significance is debatable. It’s not a CPU emulator, true. It is emulating calls, which is emulation of a sort.
    - udp 4y ago
      It’s a reimplementation of the APIs rather than an emulation. Same as how Linux reimplemented UNIX APIs, but it’s not a UNIX emulator.
      - messe 4y ago
        That's still emulating the underlying API, and accepted usage of the word. Much like the FreeBSD linux emulator translates linux syscalls into FreeBSD ones.
        Spivak 4y ago
        Is any compatibility shim an emulator?
        entropicdrifter 4y ago
        This is all really just a philosophical question as to how you choose to use the word. It's the same as people who get in a twist over every game with procedural generation and permadeath being called a "Roguelike" even though that particular subgenre used to be more specific to turn-based RPGs with procedural generation, permadeath and total loss of all progress between runs. People who came into using the term earlier tend to think of it more narrowly, but colloquial use of the term has drifted to mean something more generic, e.g. "emulation" used to mean "making one piece of hardware pretend to be another", but now can sometimes just mean, "when one thing acts like another at all".
- mort96 4y ago
  Have you actually tried to run the Windows version of Factorio through Proton and experienced slowdowns? In my experience, WINE doesn't result in a noticeable slowdown compared to running on Windows natively (without "emulationware" as you call it), unless there are issues related to graphics API translation which is a separate topic.
  - Kaze404 4y ago
    I’m a huge fan of Wine, but there’s no reason to run Factorio under it. The native Linux version works flawlessly from my experience, and I’m even using a distro where problems with native binaries are common.
    - deleted 4y ago
      [deleted]
  - sirn 4y ago
    I believe OP is referring to the fact Factorio has some optimization on Linux such as using fork() to autosave (which is copy-on-write unlike its Windows counterpart), which result in zero-stuttering during auto-save for large-SPM bases.
  - hot_gril 4y ago
    > unless there are issues related to graphics API translation But there almost always are problems in that area. I've never had a game run with the same FPS and stability in Wine vs natively in Windows.
    - mort96 4y ago
      My point was it's not inherent to WINE. There's a lot of Windows games which support Vulkan or OpenGL, those work excellently.
      - hot_gril 4y ago
        Csgo is OpenGL and doesn't work excellently in my experience, but yeah, in theory they should.
LtWorf 4y ago
I've been using wine and glibc for almost 20 years now and wine is waaaay more unstable than glibc. Wine is nice until you try to play with sims3 after updating wine. Every new release of wine breaks it. Please use wine for more than a few months before commenting on how good it is. It's normal that every new release some game stops working. Which is why steam offers the option to choose which proton version to use. If they all worked great one could just stick to the last.
- noirbot 4y ago
  As someone who's been gaming on Proton or Lutris + Raw Wine, I'm not sure I agree. I regularly update Proton or Wine without seeing major issues or regressions. It certainly happens sometimes, but I'm not sure it's any worse of a "version binding" problem than a lot of stuff in Linux is. Sure, sometimes you have to specifically use an older version, but getting "native" linux games to work on different GPU architectures or distros is a mess as well, and often involves pinning drivers or dependencies. I've had games not run on my Fedora laptop that run fine on my Ubuntu desktop, but for the most part, Wine or Proton installed things work the same across Linux installs, and often with better performance somehow.
  - LtWorf 4y ago
    I specifically mentioned the sims3. That one is constantly broken by updates. Also age of empires2 hd, after working fine with wine/proton for a decade, doesn't work with the latest proton for me.
    - noirbot 4y ago
      Sure, I'm not contesting that Wine breaks things with updates. So does a lot of stuff on Linux. The amount of times I run an apt update and some config file is now obsolete or just gone is a lot more often than I'd like. The advantage is that the Wine Ecosystem seems to realize this more than the Linux ecosystem at large, and specifically makes it easy to pin versions and never update. If it worked, why update? Or why not roll back? I'm already used to having to do that with every other part of linux gaming including my graphics drivers...
bayindirh 4y ago
> Developers natively porting to linux seem to be wasting their time. Initial port of Valve's source engine ran 20% faster without any special optimizations back in the day. So I don't see why the effort is wasted.
- DiggyJohnson 4y ago
  Isn’t part of the original point not just that Wine is a perfect (dubious, imo) compatibility layer, but that distributing a native port is cumbersome on the Linux ecosystem?
  - bayindirh 4y ago
    I don't buy the cumbersomeness argument for Linux games. A lot of games in the past and today has been distributed as Linux binaries. Most famously Quake and Unreal Tournament series had native Linux binaries on disks and they worked well until I migrated to 64 bit distributions. I'm sure they'll work equally fine if I multi-arch my installations. Many of the games bundled by HumbleBundle as downloadable setups have Linux binaries. Some are re-built as 64 bit binaries and updated long after the bundle has closed. I still play Darwinia on my 64 bit Linux system occasionally. Most of these games are distributed as .tar.gz archives, too. I can accept and respect not creating Linux builds as engineering (using Windows only APIs, libraries, etc.) and business (not enough market) decisions, but cumbersomeness is not an excuse, it's a result of the other related choices. In my book, if a company doesn't want to support Linux, they can tell it bluntly, but telling "we want to, but it's hard, and this is Linux's problem" doesn't sound sincere even remotely.
    - LtWorf 4y ago
      Basically game developers never once booted linux. They'd need to do some learning and don't want to. They might have superficially read something about distributions and think that a software cannot run on two different distributions. I've read this excuse time and time again. And saying it tells me that the person never actually tried to compile anything on linux.
deleted 4y ago
[deleted]
yellowapple 4y ago
There are plenty of examples of things being the other way around. For example, heavily modding Kerbal Space Program basically necessitated running Linux because that's the only platform that had a native 64-bit build that was even remotely stable (this has since been fixed, but for the longest time the 64-bit Windows version was horrendously broken) and therefore the only platform wherein a long mod list wouldn't rapidly blow through the 32-bit application RAM ceiling.
matheusmoreira 4y ago
This wasn't a problem with the game itself. It's their anti-cheat malware that stopped working. On Windows these things are implemented as kernel modules designed to own our computers and take away our control so we can't cheat at video games. It's always great when stuff like that breaks on Linux. I'm of the opinion it should be impossible for them to even implement this stuff on Linux but broken and ineffective is good too.

dleslie 4y ago

FWIW, targeting proton is likely the best platform target for future Windows compatibility too.

Aachen 4y ago

> Developers natively porting to linux seem to be wasting their time. Factorio runs so much better than any of this emulationware, it's one of the reasons I love the game so much and gifted licenses for friends using Windows. Some software claims to support Linux but uses some tricks to avoid recompiling and it's always noticeable, either as lag, as UI quirks, or some features plainly don't work because all the testers were windows users. Emulating as a quick workaround is all fair game but don't ship that as a Linux release. I appreciate native software (so long as it's not java), and I'm also interested in buying your game if you advertise it as compatible with WINE (then I'm confident that it'll work okay and you're interested in fixing bugs under emulation), just don't mislead and pretend and then use a compatibility layer.

jbverschoor 4y ago
Wine Is Not an Emulator
- bombcar 4y ago
  I believe it now actually is again, or was, or something. It's a question when dealing with Win16 and now Win32 (Windows-on-Windows).
- caffed 4y ago
  Ha Perfect! Yes, wine is an Windows binary executor with library translation. https://wiki.winehq.org/FAQ#Is_Wine_an_emulator.3F_There_seems_to_be_disagreement https://wiki.winehq.org/FAQ#Is_Wine_an_emulator.3F_There_see...
- delusional 4y ago
  Sure, but it's also WINdows Emulator
  - ink_13 4y ago
    No, it's not, because it's not a emulator
    - hot_gril 4y ago
      "In computing, an emulator is hardware or software that enables one computer system (called the host) to behave like another computer system (called the guest)." Sounds like Wine.
      - wvenable 4y ago
        Wine isn't emulating a computer. It's another implementation of the Win32 API. Just like Linux isn't a Unix emulator.
        hot_gril 4y ago
        There is a Linux emulator for Unix (namely FreeBSD), and it's one of the first examples in the Wikipedia article on emulation. https://www.openbsd.org/60.html https://www.openbsd.org/60.html shows OpenBSD removing "Linux emulation." Linux was never designed to be the same as Unix, just similar. But it's more popular now, so Unix users found utility in pretending to run Linux.
  - jbverschoor 4y ago
    Well you know.. I guess I'm OG when it comes to naming.
- gorkish 4y ago
  Except sometimes on aarch64
WarChortle 4y ago
In case you weren't aware Wine is not an emulator, it is a compatibility layer. The whole point of wine is to take a native Windows app, only compiled for Windows and translate its Windows calls to Linux calls.
- Wowfunhappy 4y ago
  > In case you weren't aware Wine is not an emulator, it is a compatibility layer. Ehhh. I know it’s in the name, but I feel like the significance is debatable. It’s not a CPU emulator, true. It is emulating calls, which is emulation of a sort.
  - udp 4y ago
    It’s a reimplementation of the APIs rather than an emulation. Same as how Linux reimplemented UNIX APIs, but it’s not a UNIX emulator.
    - messe 4y ago
      That's still emulating the underlying API, and accepted usage of the word. Much like the FreeBSD linux emulator translates linux syscalls into FreeBSD ones.
      - Spivak 4y ago
        Is any compatibility shim an emulator?
        entropicdrifter 4y ago
        This is all really just a philosophical question as to how you choose to use the word. It's the same as people who get in a twist over every game with procedural generation and permadeath being called a "Roguelike" even though that particular subgenre used to be more specific to turn-based RPGs with procedural generation, permadeath and total loss of all progress between runs. People who came into using the term earlier tend to think of it more narrowly, but colloquial use of the term has drifted to mean something more generic, e.g. "emulation" used to mean "making one piece of hardware pretend to be another", but now can sometimes just mean, "when one thing acts like another at all".
mort96 4y ago
Have you actually tried to run the Windows version of Factorio through Proton and experienced slowdowns? In my experience, WINE doesn't result in a noticeable slowdown compared to running on Windows natively (without "emulationware" as you call it), unless there are issues related to graphics API translation which is a separate topic.
- Kaze404 4y ago
  I’m a huge fan of Wine, but there’s no reason to run Factorio under it. The native Linux version works flawlessly from my experience, and I’m even using a distro where problems with native binaries are common.
  - deleted 4y ago
    [deleted]
- sirn 4y ago
  I believe OP is referring to the fact Factorio has some optimization on Linux such as using fork() to autosave (which is copy-on-write unlike its Windows counterpart), which result in zero-stuttering during auto-save for large-SPM bases.
- hot_gril 4y ago
  > unless there are issues related to graphics API translation But there almost always are problems in that area. I've never had a game run with the same FPS and stability in Wine vs natively in Windows.
  - mort96 4y ago
    My point was it's not inherent to WINE. There's a lot of Windows games which support Vulkan or OpenGL, those work excellently.
    - hot_gril 4y ago
      Csgo is OpenGL and doesn't work excellently in my experience, but yeah, in theory they should.

LtWorf 4y ago

I've been using wine and glibc for almost 20 years now and wine is waaaay more unstable than glibc. Wine is nice until you try to play with sims3 after updating wine. Every new release of wine breaks it. Please use wine for more than a few months before commenting on how good it is. It's normal that every new release some game stops working. Which is why steam offers the option to choose which proton version to use. If they all worked great one could just stick to the last.

noirbot 4y ago
As someone who's been gaming on Proton or Lutris + Raw Wine, I'm not sure I agree. I regularly update Proton or Wine without seeing major issues or regressions. It certainly happens sometimes, but I'm not sure it's any worse of a "version binding" problem than a lot of stuff in Linux is. Sure, sometimes you have to specifically use an older version, but getting "native" linux games to work on different GPU architectures or distros is a mess as well, and often involves pinning drivers or dependencies. I've had games not run on my Fedora laptop that run fine on my Ubuntu desktop, but for the most part, Wine or Proton installed things work the same across Linux installs, and often with better performance somehow.
- LtWorf 4y ago
  I specifically mentioned the sims3. That one is constantly broken by updates. Also age of empires2 hd, after working fine with wine/proton for a decade, doesn't work with the latest proton for me.
  - noirbot 4y ago
    Sure, I'm not contesting that Wine breaks things with updates. So does a lot of stuff on Linux. The amount of times I run an apt update and some config file is now obsolete or just gone is a lot more often than I'd like. The advantage is that the Wine Ecosystem seems to realize this more than the Linux ecosystem at large, and specifically makes it easy to pin versions and never update. If it worked, why update? Or why not roll back? I'm already used to having to do that with every other part of linux gaming including my graphics drivers...

bayindirh 4y ago

> Developers natively porting to linux seem to be wasting their time. Initial port of Valve's source engine ran 20% faster without any special optimizations back in the day. So I don't see why the effort is wasted.

DiggyJohnson 4y ago
Isn’t part of the original point not just that Wine is a perfect (dubious, imo) compatibility layer, but that distributing a native port is cumbersome on the Linux ecosystem?
- bayindirh 4y ago
  I don't buy the cumbersomeness argument for Linux games. A lot of games in the past and today has been distributed as Linux binaries. Most famously Quake and Unreal Tournament series had native Linux binaries on disks and they worked well until I migrated to 64 bit distributions. I'm sure they'll work equally fine if I multi-arch my installations. Many of the games bundled by HumbleBundle as downloadable setups have Linux binaries. Some are re-built as 64 bit binaries and updated long after the bundle has closed. I still play Darwinia on my 64 bit Linux system occasionally. Most of these games are distributed as .tar.gz archives, too. I can accept and respect not creating Linux builds as engineering (using Windows only APIs, libraries, etc.) and business (not enough market) decisions, but cumbersomeness is not an excuse, it's a result of the other related choices. In my book, if a company doesn't want to support Linux, they can tell it bluntly, but telling "we want to, but it's hard, and this is Linux's problem" doesn't sound sincere even remotely.
  - LtWorf 4y ago
    Basically game developers never once booted linux. They'd need to do some learning and don't want to. They might have superficially read something about distributions and think that a software cannot run on two different distributions. I've read this excuse time and time again. And saying it tells me that the person never actually tried to compile anything on linux.

deleted 4y ago

[deleted]

yellowapple 4y ago

There are plenty of examples of things being the other way around. For example, heavily modding Kerbal Space Program basically necessitated running Linux because that's the only platform that had a native 64-bit build that was even remotely stable (this has since been fixed, but for the longest time the 64-bit Windows version was horrendously broken) and therefore the only platform wherein a long mod list wouldn't rapidly blow through the 32-bit application RAM ceiling.

matheusmoreira 4y ago

This wasn't a problem with the game itself. It's their anti-cheat malware that stopped working. On Windows these things are implemented as kernel modules designed to own our computers and take away our control so we can't cheat at video games. It's always great when stuff like that breaks on Linux. I'm of the opinion it should be impossible for them to even implement this stuff on Linux but broken and ineffective is good too.