Announcement

Collapse
No announcement yet.

Steam on Linux Gaming Marketshare Steady For April

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • leech
    replied
    Originally posted by Quackdoc View Post

    The difference is that 32bit will work on 64bit, arm will not, also there is a market to sell the games to, but their is not platform to sell them from, aside from itch... and there are games being made for arm that can be sold. but I already said why emulation is NOT the answer, it's a stop gap. also as I said, we have two upcoming methods for emulating 64bit through wine. it's a matter of time on that front.

    Also if you really think that about windows S, then you need to re-evaluate it, Windows S is a god send for system admins. as someone who works daily with people, Windows S has been such a time and hassle saver. I'm more worried about stupid people doing stupid things, more than bad actors in an appstore. no more GPO editing, and no more stupid people borking things in stupid ways.
    Really? That's why Microsoft sells it on cheap (I'm talking 300 dollars) laptops at Walmart and not systems they sell to Enterprises? Sure your small companies might actually really like cheap laptops with Windows S for locking down their users. I could see that. I'm betting any of the people that use the laptops where I work would be irritated if they couldn't install some tools they use for their job because they aren't in the Windows App Store... Granted, the IT department do install some software on the laptops that turn a high end laptop into something that feels like it is using spindle drives... but that's neither here nor there...

    Windows S is really an attempt at locking down what can be ran on the system. You can do that with group policies too, sure it may be more complicated... but seriously, that isn't the intent of MS...

    Leave a comment:


  • JackLilhammers
    replied
    Originally posted by birdie View Post

    I am certainly not a fan of Windows in its default state but I've found solutions to make it near 100% rock solid, for instance, I extensively use SandBoxie+ which allows to install and delete applications without a trace. I even sometimes run malware under it for fun (it's near 100% safe). Yes, Microsoft sometimes releases updates which break stuff but normally fewer than 1% of users are affected and then those users have a ton of software/drivers installed, so naturally Microsoft cannot test all the permutations of their changes in regard to what users are running. There are utilities like e.g. DriverStoreExplorer which allow to safely delete old versions of drivers.

    And Windows 10 LTSC is just a joy to use: no Microsoft store or worthless crap related to it, telemetry which you can disable pretty much completely, quite calm updates which don't break stuff unlike the standard Windows 10 which sees major updates/reinstallations each six months.

    And then there are tons of free, fast and useful utilities, like e.g. IrfanView which I even use in Linux instead of all brain-damaged half-assed Linux image viewers. Far File Manager is miles ahead (faster, a lot more features, proper code highlighting using Colorer) of Midnight Commander.
    It's fun because 1% in Windows numbers is probably still more than the double digit percentage in Linux numbers.
    However in my experience Windows 10 updates have been excellent.

    OTOH I won't use LTSC, because I think Microsoft new approach is way better for desktops than fixed releases.

    Tons of free, fast, and useful utilities are available for every OS, usually for all of them. BTW IrfanView runs perfectly on Wine. I don't like it though, I prefer Gwenview and FastStone Image Viewer, but de gustibus non est disputandum...

    As I won't discuss your choice of a file manager, because I don't have enough beard to argue about that

    Leave a comment:


  • JackLilhammers
    replied
    Originally posted by blacknova View Post

    What I'd like to see from some linux distro is - layered structure where user can interchange each layer to their own needs.
    Layers like:
    1. Kernel
    2. Drivers
    3. Base OS (including UI env)
    4. User's software

    Right now most popular distroes tied everything to distro release. And if you want something new, you need to upgrade. Flatpak introduction somethat solves layer 4. Or user can just install that they need into their home dir and be done.
    But it still leave you without ability to update your UI env, kernel and drivers separately from each other.

    Don't get me wrong Linux distroes as they are an excelent server, and very good task oriented workstation. But it is very mediocry end user desktop IMHO.
    I'd say it's quite hard to separate the first two layers, especially on Linux, 3 and 4 on the other hand should be completely replaceable.
    I agree that the classic release based approach is not the best for the desktop and there are many different takes on a less rigid upgrade path.
    While Linux as a desktop os is undeniably worse than Windows and Mac os, it's not that much worse per se. Also it's way better on many things.
    IMHO it's the lack of certain apps that cripples Linux on the desktop. Apps that there's no interest in porting, because they already have their market and a porting would cost more than it would earn.
    Of course that doesn't concern the vast majority of the Linux community either, because usually the lack of interest is reciprocated

    Leave a comment:


  • Quackdoc
    replied
    Originally posted by leech View Post
    My point is that Steam is a store. Until there is more software or some compatibility layer in place for them to be able to sell games on ARM, there won't be a need to have an ARM version of the store. And seeing as how they haven't seen the need to upgrade the client to 64bit, and still serve 64bit games through it, I highly doubt we will see a native ARM client. There is no need for one. As you say, the 32bit one runs fine through emulation.
    If native ARM games happen, I am sure they will do that.

    Windows S is a power grab, nothing more. It isn't anymkre secure than normal windows. See every example around for "we lock it down to an app store for security!" And then every app store getting garbage uploaded to it that breaks security. You knkw, like a hidden cryptominer in a 2048 game uploaded to the snap store...
    The difference is that 32bit will work on 64bit, arm will not, also there is a market to sell the games to, but their is not platform to sell them from, aside from itch... and there are games being made for arm that can be sold. but I already said why emulation is NOT the answer, it's a stop gap. also as I said, we have two upcoming methods for emulating 64bit through wine. it's a matter of time on that front.

    Also if you really think that about windows S, then you need to re-evaluate it, Windows S is a god send for system admins. as someone who works daily with people, Windows S has been such a time and hassle saver. I'm more worried about stupid people doing stupid things, more than bad actors in an appstore. no more GPO editing, and no more stupid people borking things in stupid ways.

    Leave a comment:


  • leech
    replied
    Originally posted by Quackdoc View Post

    They will bother, because it won't be just mac, and emulating can cause security issues, since it is another layer you could potentially exploit. if performance was the only factor, valve wouldn't bother porting to linux anything, and just focus on proton/wine. considering it works nearly as performant, enough to any meaningful degree in the vast majority of cases. when optimized.

    2. We are talking specifically about the steam client, NOT games.

    3.That doesn't matter, steam still exists, and is successful to a degree.

    4. WIndows S mode, is not born out of a need to lock users down, but rather a security one, and quite frankly, its really good at that. Microsoft realized the increasing security threat to window's and it's users, and this is one of the steps they took.

    5. Already covered that. but ill go in a bit more depth. Just like why valve ported to linux, The least steps a program needs to take, the better, unless there is a valid reason to do so, (IE. Sandboxng). but its the same as M1 rossetta, just because it works good enough, doesn't mean it's the best. emulation of anything modern should always be treated as a stop gap, or as a method of preservation. when a native port is possible. Security and performance aside. another good reason is reputation. You never want the reputation of being a lazy developer. Biases stick with people. and thats not something you want sticking to your name.

    Its not hard to port steam to arm, what is hard, is making the catalogue work well with the separation of it, I suspect that would be the greatest limiting issue.
    My point is that Steam is a store. Until there is more software or some compatibility layer in place for them to be able to sell games on ARM, there won't be a need to have an ARM version of the store. And seeing as how they haven't seen the need to upgrade the client to 64bit, and still serve 64bit games through it, I highly doubt we will see a native ARM client. There is no need for one. As you say, the 32bit one runs fine through emulation.
    If native ARM games happen, I am sure they will do that.

    Windows S is a power grab, nothing more. It isn't anymkre secure than normal windows. See every example around for "we lock it down to an app store for security!" And then every app store getting garbage uploaded to it that breaks security. You knkw, like a hidden cryptominer in a 2048 game uploaded to the snap store...

    Leave a comment:


  • Quackdoc
    replied
    Originally posted by leech View Post
    1. Well, Valve is a company, Steam is their product. And being that reaching the most users possible vs cost makes me think if emulation is good enough, then it isn't likely they will bother with an ARM port. As you say in your later points.

    2. It isn't the Steam client that matters, it is the games.

    3. Yes, I know Steam exists on Macs, this was back when Apple was more open and didn't try to make sure they got a cut of every bit of software sold on their platform, in a call for security! They do application verification across the board these days, even bash scripts call home...

    4. Ever hear of Windows S-mode? It literally will not let you install anything outside of the Windows App Store. You can turn it off... now anyhow, until they decide you can't.

    5. Awesome, so much like developers not releasing native Linux games, and instead support Proton, why would Valve need to port to ARM when Wine+Box86 is good enough?
    They will bother, because it won't be just mac, and emulating can cause security issues, since it is another layer you could potentially exploit. if performance was the only factor, valve wouldn't bother porting to linux anything, and just focus on proton/wine. considering it works nearly as performant, enough to any meaningful degree in the vast majority of cases. when optimized.

    2. We are talking specifically about the steam client, NOT games.

    3.That doesn't matter, steam still exists, and is successful to a degree.

    4. WIndows S mode, is not born out of a need to lock users down, but rather a security one, and quite frankly, its really good at that. Microsoft realized the increasing security threat to window's and it's users, and this is one of the steps they took.

    5. Already covered that. but ill go in a bit more depth. Just like why valve ported to linux, The least steps a program needs to take, the better, unless there is a valid reason to do so, (IE. Sandboxng). but its the same as M1 rossetta, just because it works good enough, doesn't mean it's the best. emulation of anything modern should always be treated as a stop gap, or as a method of preservation. when a native port is possible. Security and performance aside. another good reason is reputation. You never want the reputation of being a lazy developer. Biases stick with people. and thats not something you want sticking to your name.

    Its not hard to port steam to arm, what is hard, is making the catalogue work well with the separation of it, I suspect that would be the greatest limiting issue.

    Leave a comment:


  • Quackdoc
    replied
    Originally posted by birdie View Post

    Why would people install Linux in the first place when a) Windows 10 is preinstalled on > 95% of PCs and laptops, it works just fine for most use cases and has a great backwards compatibility b) Even if it's not preinstalled, an OEM licence can be bought for as low as $10 or even less c) Windows 10 now supports the entire Linux software stack at near native speeds (WSL2) with no need for "real"/full virtualization?
    Because people that hate windows are increasing. windows breaks something for a good chunk of people on a seemingly monthly basis. Shaddy telemetry practices, and who knows what other reasons, I've been requested by old customers to install operating systems other than windows, at an alarming rate, and that's just me. Many computer savvy people are only sticking with windows because their specific app, or environment needs windows. usually corporate or multiplayer games. once those are resolved, I would not be supervised to see a large immigration to linux, purely on the basis, that it's not windows.

    Leave a comment:


  • Xaero_Vincent
    replied
    Originally posted by birdie View Post

    They work only because someone actually went ahead, patched them and made them work. There are literally thousands of other packages no one interested in - what are you propositing to do for the average user? Learn C/C++/cpp/make/cmake/autotools and then learn deprecated and modern Linux APIs because you need to make both work? Are you fucking serious?

    Speaking of these KDE 1/2 "fixed" releases - how can I install them in an average distro like e.g. Fedora? Compile them from sources? Just like that? How many users do you think out there are capable of compiling, installing and setting up software. Lastly KDE 1/2 won't just magically work if you compile them from sources for fuck's sake, you'll need to add them to /usr/share/xsessions which again most users are not capable of.

    Under bloody Windows 10 I just run Windows 95 32bit applications without any mental gymnastics. Wake me up when Linux features the same level of compatibility with old software. Binary compatibility has been the cornerstone of any successful OS which respects its users. Desktop Linux is not one of them.

    And magical TDE - how many distros even include it? What about all the KDE packages not included in TDE? TDE developers, because they needed a moment of glory, rewrote Qt3 and KDE3 APIs and made all the unported KDE3 applications totally incompatible with TDE. That's why I'm not going to touch this asinine product ever. They didn't need to do that, they didn't have to do that, in fact there's been zero justification to that other than to show off.

    I don't need Asgard or any of this crap. I need near 100% perfect backwards compatibility thank you very much. Too bad, compatibility and stability are two swear words in Linux.
    Care to name a few of these "thousands of packages"? Also care to share how the user wouldn't be better served using a modern application with equivalent functionality? I'd honestly like to know about some old FOSS or proprietary Linux applications (besides games) that don't have a decent modern equivalent or fork under current Linux distros.
    Even with old games and not using something like Asgard docker images, many games have open-source engine re-implementations that can play the original games with enhanced features on modern distros without any extra hassle.

    For instance, Luxtorpeda helps with that:



    When I installed KDE 1 from AUR last night, it compiled automatically with the "yay" AUR helper and automatically put a KDE 1 entry in GDM, so I just signed out and selected KDE 1 and it started right up. I don't know how it's done on Fedora but I imagine someone could just make a 3rd party repository and host binaries packages for it.

    What KDE 3.5 applications are missing from Trinity? Standard Qt3 applications don't require the KDE 3 or Trinity desktop environment to run. I also had no problem running KDE 1 apps in Gnome Shell 40 when I tested it yesterday.

    Leave a comment:


  • birdie
    replied
    Originally posted by Xaero_Vincent View Post

    I thought your point was that KDE 1 and 2 apps won't work despite being open-source? They certainly do work and it's because they are open-source that patches have been made to support modern distros. KDE 3.5 desktop and applications live on as the Trinity desktop environment and older Qt3 apps can still work too:




    There are plenty of ancient applications that no longer work properly or at all on Windows 10, even in compatibility mode. Windows doesn't have perfect backwards compatibility and it shouldn't, as major API breaking changes are sometimes necessary to advance the operating system functionality. In some cases, people use Wine on Linux to run old Windows applications that no longer behave properly under Windows 10.

    The bigger question is why you would want to use ancient proprietary binary-only apps on Linux in the first place. Is there a specific application that comes to mind that is of value? The only type of ancient binaries that seem of any value in my mind are games.

    For running ancient games on modern Linux, you can use Asgard:

    https://github.com/lutris/asgard/
    They work only because someone actually went ahead, patched them and made them work. There are literally thousands of other packages no one interested in - what are you propositing to do for the average user? Learn C/C++/cpp/make/cmake/autotools and then learn deprecated and modern Linux APIs because you need to make both work? Are you fucking serious?

    Speaking of these KDE 1/2 "fixed" releases - how can I install them in an average distro like e.g. Fedora? Compile them from sources? Just like that? How many users do you think out there are capable of compiling, installing and setting up software. Lastly KDE 1/2 won't just magically work if you compile them from sources for fuck's sake, you'll need to add them to /usr/share/xsessions which again most users are not capable of.

    Under bloody Windows 10 I just run Windows 95 32bit applications without any mental gymnastics. Wake me up when Linux features the same level of compatibility with old software. Binary compatibility has been the cornerstone of any successful OS which respects its users. Desktop Linux is not one of them.

    And magical TDE - how many distros even include it? What about all the KDE packages not included in TDE? TDE developers, because they needed a moment of glory, rewrote Qt3 and KDE3 APIs and made all the unported KDE3 applications totally incompatible with TDE. That's why I'm not going to touch this asinine product ever. They didn't need to do that, they didn't have to do that, in fact there's been zero justification to that other than to show off.

    I don't need Asgard or any of this crap. I need near 100% perfect backwards compatibility thank you very much. Too bad, compatibility and stability are two swear words in Linux. The Linux kernel is project number one in terms of breaking compatibility (under the pretense that it makes development faster and better) and introducing mission critical bugs which sometimes even lead to ... data loss.
    Last edited by birdie; 03 May 2021, 01:39 PM.

    Leave a comment:


  • Xaero_Vincent
    replied
    Originally posted by birdie View Post

    KDE 1.1 was heavily patched to support modern Linux'es, right: https://github.com/KDE/kde1-kdebase

    "Historical copy of the base applications module of KDE 1, adapted to compile on modern systems (circa. 2016) " - your fanboyism doesn't allow you to even follow the news.

    Good luck compiling and using the original unmodified sources. Good luck compiling and using the software which no one cares fixing/porting to moder Linux'es.

    Even relatively recent KDE 3.5.10 requires a large number of patches to fix GCC compatibility and huge patches to properly support modern software stack because many features the DE relied on were completely deprecated and removed, e.g. HAL.

    And that's only for OpenSUSE where some folds keep it alive and spend their time and lives on making it work. In many other distros KDE 3.5 has been either fully or almost completely been removed.
    I thought your point was that KDE 1 and 2 apps won't work despite being open-source? They certainly do work and it's because they are open-source that patches have been made to support modern distros. KDE 3.5 desktop and applications live on as the Trinity desktop environment and older Qt3 apps can still work too:




    There are plenty of ancient applications that no longer work properly or at all on Windows 10, even in compatibility mode. Windows doesn't have perfect backwards compatibility and it shouldn't, as major API breaking changes are sometimes necessary to advance the operating system functionality. In some cases, people use Wine on Linux to run old Windows applications that no longer behave properly under Windows 10.

    The bigger question is why you would want to use ancient proprietary binary-only apps on Linux in the first place. Is there a specific application that comes to mind that is of value? The only type of ancient binaries that seem of any value in my mind are games.

    For running ancient games on modern Linux, you can use Asgard:

    Leave a comment:

Working...
X