Hacker News Reader

That just not true. "All Linux users dual boot" where's your data to say that? "Nobody compiles for Linux" factually false, many of the most-played games on steam are Linux-native, and most others run flawlessly on Proton.

And 1.2% is slightly more than half the mac market share on steam. Should mac users also be ignored?

>"Nobody compiles for Linux" factually false, many of the most-played games on steam are Linux-native, and most others run flawlessly on Proton.

The games that run on proton have not been compiled for linux.

linux native + proton means "some compiles for Linux[1], the rest either tests on proton (steamdeck should increase that segment at least) or does not care"

[1] https://news.ycombinator.com/item?id=28978086

E.g. factorio is compiled for linux.

Yes, linux-native games exist.

But games that run on linux via proton have not been compiled for linux, so mentioning them as a counter-argument to games not being compiled for linux makes no sense.

The broader context here is TFA rejecting the "steam runtime" idea, and for proton-based games proton is that runtime! They don't need anything from the system because proton/wine provides it.

Your data is wrong. I wish it were correct. But it's not.

OSX users are 2.56% of Steam. Linux is 1.13%

https://store.steampowered.com/hwsurvey/Steam-Hardware-Softw...

> Valve only needs to maintain wine & proton for a distribution. The games themselves ? well, they are windows only. Nobody compiles for Linux. All gamers either dual boot windows...or android. Even for those who game on Linux, they do it on an abstraction layer like Wine

This isn't true at all. I'm afraid you've misunderstood the situation. Get on steam and check for yourself. There are many games compiled for Linux specifically (in addition to other platforms) that do not require proton. They use some ubuntu or debian packages for their libraries and have no linkage to anything windows.

Firefox is larger on macOS because it contains 2 archs (x86_64 and arm64), not because it bundles of full runtime -- also the compression algo of dmg files is typically quite bad (zlib or bzip2), which is not helping.

I didn’t think that binaries would take up so much space, but Firefox 83 (the last x86-only release) is 73MB vs Firefox 84 (the first universal release) which is 126MB. Wow, I guess that makes sense then.

Firefox would be a bigger codebase than the whole Linux kernel so it makes sense.

Thanks for that! I quickly poked around at my Firefox install on MacOS. Firefox.app is 353M. The largest single file in there is Firefox.app/Contents/MacOS/XUL (binary) and that's 258M. Of that, lipo says 136165680 is x86_64 and 134106096 is arm64. My Firefox folder in Windows is 208M.

That still does not change the argument that file size does not matter.

In fact, this reinforces it. OSX believes file size matters so little they’re willing to double file size simply so users don’t have to pick x64 or x86 when downloading the app (and if they’re using the App Store the App Store could do it for them, but even that Apple thinks is too much complexity).

Not sure about MacApp Store, but on iOS they do trim archs and assets as needed.

That's a surprisingly recent addition on iOS, and it appears to not have made it to macOS.

Folks who have the money for Apple stuff have money for large SSDs and fast unmetered Internet.

Aaaand folks who live in the Apple universe have been accustomed to accept that they are holding it wrong, and that there's someone whose job is to figure out what's the official best way to do things. If it involves downloading 130 megs it's 130 megs. No problem. The UX and end result is worth it for them.

I have used Monolingual[1] on past laptops to remove unnecessary architectures from installed OS X applications when disk space was running low.

Having said that, I never bothered installing it on my current laptop which sort of reinforces the point others are making about being less concerned with application size.

[1] https://ingmarstein.github.io/Monolingual/

Yeah, really. OSX DMG's contain AppBundles, a concept OSX inherited from NeXT. NeXT wasn't the first implementation of the idea either, in fact pretty much every non-unix desktop OS ever released used some variation of the concept including DOS and the original Mac.

Sadly, it seems the Linux world just can't wrap its head around the idea of managing applications with the same simple mechanisms we use to manage regular every day files. It would seem that Linux Desktop users just love having inflexible management tools do it instead. Well, there is AppImage, but unfortunately its use is not wide spread.

"Sadly, it seems the Linux world just can't wrap its head around the idea of managing applications with the same simple mechanisms we use to manage regular every day files. It would seem that Linux Desktop users just love having inflexible management tools do it instead. Well, there is AppImage, but unfortunately its use is not wide spread."

Seems to me they love treating application management like one manages dependencies in a software project. There are a lot of parallels with the paradigm. Its clear where the notion came from. And I think in the context of unix/linux history it makes sense. If I were an MIT grad student in 1978 there probably isn't much difference between a library and an application practically.

But that was over 40 years ago. There is a clear distinction now and the overwhelming majority of PC users are not MIT grad students. Applications should be easy to install. People don't care that there is more than one version of some dependency. They don't care that your repro doesn't have what they want. They have work to do.

> This OTOH does not exist. Linux gamers are 1% of either the gaming market or the desktop computing market. All gamers either dual boot windows...or android. Even for those who game on Linux, they do it on an abstraction layer like Wine. Which is what Valve maintains

First off, 1.13% of Steam users are on Linux [1], and given how many users Steam has, just 1% of that population should be able to make quite a fuss. Secondly, Valve does need those containerized runtimes even if most games run on Proton, since Proton also depends on those libraries, so not sure why you're dismissive...

[1]: https://www.phoronix.com/scan.php?page=news_item&px=Steam-Li...

I'm on your side. I'm a Linux gamer..or rather used to be.

Until I saw this - https://news.ycombinator.com/item?id=28978086

Yeah sure, Linux gamers are more engaged, etc etc. But for a indie developer making games...it's like 5% of the market. Probably does not even recoup development cost.

I realised that I am probably doing a disservice to the indie gaming developers, by insisting on a militant stance.

Wine is fine. I'll just play it on Linux. Let them make more money.

osx can do this because "osx" is about as specific as "Ubuntu 20.04 LTS", so 90% of the problems that were described in the article wouldn't happen because there aren't many osxes.

I personally don't use it, so I can't tell how good the story is with 2 different versions. I've heard lots of upgrade troubles from mac users when a new OS release comes out, but maybe the authors are usually better in keeping a version for current-1 around, or the latest version compatible with current-1? Then it's still only 2 versions and not 10 distros.