Announcement

Collapse
No announcement yet.

Steam Linux Use Dips Back Below 0.5%

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

  • #61
    Originally posted by Weasel View Post
    Compiling from source? Dude, even amongst Linux users... Gentoo users are a tiny minority.

    "Vast majority" and yet the majority of Windows apps (that have APIs implemented I mean) work just fine under Wine...? Obviously apps that don't have APIs implemented are not gonna work, that has nothing to do with corner cases, just not implemented yet (e.g. D3D12).
    Like I said, I'm not new, if Gentoo is a small minority and it has millions of users, then there must be hundreds of millions of linux users total. Think about it and stop trying so hard to be contradictory. Yes I came to linux because of gentoo's use flags, and hundreds of millions more came to linux for whatever their own reasons were. The bottom line fact is for whatever reason it -already- happened. And it's a way bigger number than you're admitting to.

    No wine definitely doesn't not even run a tiny percentage of available windows apps. I think it would be phenomenal if it could be proven to run 5%. I doubt it's anywhere close to that high even.

    Comment


    • #62
      I hope their fuzzy statistics does not effect the production of Linux games. Steam is so great to have and I am very thankful it is on linux and I have the games that I have. Maybe we all need to contact Steam somehow? I don't feel their survey is even remotely accurate myself, but I have been wrong.
      Last edited by creative; 05 August 2018, 09:42 AM.

      Comment


      • #63
        Originally posted by duby229 View Post
        Like I said, I'm not new, if Gentoo is a small minority and it has millions of users, then there must be hundreds of millions of linux users total. Think about it and stop trying so hard to be contradictory. Yes I came to linux because of gentoo's use flags, and hundreds of millions more came to linux for whatever their own reasons were. The bottom line fact is for whatever reason it -already- happened. And it's a way bigger number than you're admitting to.
        There's around 3.5 billion people online these days, and with a 2% market share on the desktop that's already 70 million people using Linux online...

        Originally posted by duby229 View Post
        No wine definitely doesn't not even run a tiny percentage of available windows apps. I think it would be phenomenal if it could be proven to run 5%. I doubt it's anywhere close to that high even.
        How about you prove it runs less than 5% first before demanding proof from others that you, yourself, can't even produce.

        I talk from experience, if the app has no copy protection or anti cheat bullshit, and all its important APIs are implemented, and bonus if it's "portable" (so no installation woes), then it usually works. I'd say 75% (if not more) of such apps work. They may have a few little glitches in some parts, but usually minuscule in obscure situations when using said app.

        Comment


        • #64
          Originally posted by oiaohm View Post
          The thing is that works.
          But I asked you if it works on the new distro, not the distro from 1999. You might as well say, I used a container full of stuff from 1999 to run an app from 1999. Or a virtual machine. Seriously dude?

          Originally posted by oiaohm View Post
          TSMC CAD for silicon design is one. Yes it protection does require root access in fact in kernel module that use to decode silicon node into memory and protect it from coping unencrypted..
          Then it's a very special case because there are a very tiny amount of apps who are going to do that. That's why they'll remain "Windows only". (which I find a shame because it's usually only this bullshit that makes them not run on Linux or not get a Linux port)

          Can you give me a link to this app's system requirements? I want to confirm if I'm right that it supports a tiny minority of distro configurations or kernel versions.

          You can't expect games to do that though.

          Originally posted by oiaohm View Post
          We are lucky that most of the sane priced closed source on Linux if it has licensing control is either steam or FlexNet Publisher that are both kind of sane. As soon as the software crosses 2000 dollar a seat you start seeing root level and custom kernel driver requiring. When software crosses 10000 dollars a seat you start seeing the really nasty stuff like custom hyper visor enforced copy protection that gets worst like listing what motherboard/cpu/video card/harddrive brand.... you most have so their software works.

          I don't think anyone playing games would put up with hypervisor enforce copyright protection. Hypervisor enforced copy protection makes general gaming copy protection and anti-cheat look tame.
          There's something similarly bad on Windows: Syncrosoft or PACE iLok (hardware dongles). Those will never run on Linux, either, because they won't make them compatible with it (would require kernel modules and all that hell). It's not Linux's fault though, it's just that kind of bullshit that I hate, but people blame Wine for.
          Last edited by Weasel; 05 August 2018, 03:59 PM.

          Comment


          • #65
            Originally posted by Weasel View Post
            But I asked you if it works on the new distro, not the distro from 1999. You might as well say, I used a container full of stuff from 1999 to run an app from 1999. Or a virtual machine. Seriously dude?
            Does not have to be full container. Old programs if users wanted them could be flatpak. Loki games only require quite a small runtime. The recent work to make dlmopen work will allow mixing new libraries with these older programs. So the fact that these old programs still work under current Linux distributions with effort being a chroot/container/runtime. Valve is funding the work I pointed to showed at debian conf 2018 because they have a lot of programs requiring older versions of glibc.

            Interesting part is this https://meetings-archive.debian.net/...ing-the-p.webm work is aim to allow old with new libraries without the limitation on free and allocation. Basically make all the program use the same allocation system even if you are using multi versions of glibc. Of course there are still the other resource allocations issues to watch out for.

            Open source can take a long time to get around to-do something but when it done it normally done right.

            Originally posted by Weasel View Post
            Then it's a very special case because there are a very tiny amount of apps who are going to do that. That's why they'll remain "Windows only". (which I find a shame because it's usually only this bullshit that makes them not run on Linux or not get a Linux port)

            Can you give me a link to this app's system requirements? I want to confirm if I'm right that it supports a tiny minority of distro configurations or kernel versions.
            These silicon design programs are not on windows they use to be Unix programs but are now Linux programs because most Unix solutions cannot get graphics drivers any more. Due to areas of system they push heavy if they were on windows it would add at least 20% to the processing time. These are programs that you press process and watch your quad socket cpu(yes 4 xeon intel processor chips 16 threads each total of 64 threads) workstation Linux computer come fully not responsive at almost 100 percent cpu load for 5 to 7 days that is bad enough without having to wait 20% long than that.

            Even worse you get the system requirements after you have signed the NDA and paid a single seat license fee with no refund. You want silicon produced by them you obey their terms. This is a true case of being over a barrel. Basically gamers have no clue how bad it can get this is the worst level of copy protection they have even copy protected the system requirements behind NDA.

            Originally posted by Weasel View Post
            There's something similarly bad on Windows: Syncrosoft or PACE iLok (hardware dongles). Those will never run on Linux, either, because they won't make them compatible with it (would require kernel modules and all that hell). It's not Linux's fault though, it's just that kind of bullshit that I hate, but people blame Wine for.
            Again lack of knowledge. I can tell you that the drivers for Syncrosoft and PACE iLok don't contain anything that prevents them from running under the current wine winedevice problem is winedevice don't have the parts emulated/redirected so they can talk to the dongles so they believe their dongle is not plugged in. So someone funding a developer to work on this could make it work. This is a lack of resources problem yes people are annoyed that wine does not support these yet but they are not putting up the money to pay developer to make them work either.

            Winedevice loads windows kernel driver in ring 3 instead of ring 0 so if the driver does contain checks for ring 0 or perform an action requiring ring 0 then that will not work most windows drivers don't in fact check if they are running at ring 0 or perform action that require ring 0 directly the legacy of the micro kernel design in NT kernel. So most cases it not drivers stopping program from working but the features those drivers need not being implemented.


            Sentinel Gemalto provides Linux support for their dongles interesting point is they don't use a kernel mode driver at all. Instead you set up a udev rule to allow user access to the dongle and the program uses something embedded like libusb to talk to the dongle from userspace. Yes sentinel gemalto requires a kernel mode driver under windows. This is important fact about the Linux kernel a lot of what has to be kernel mode drivers under Windows can be done as usermode drivers under Linux so totally avoiding the linux kernel space mix of stable and unstable ABI.

            There are some drivers in Linux kernel 2.0 that will build not modified on current Linux kernel because they used sections of the kernel space ABI that has not changed in all that time. So the Linux kernel space ABI is not 100 percent unstable problem is what is stable has not been clearly tag this is where kernel namespace of symbols that is being done will be good for Linux.

            The reality lot of the barriers are disappearing and there are lot of myths like around dongle drivers that they are barriers when they are nothing more than a issue of stuff not being implemented yet so not a hard barrier at all.

            Dongle support/fake accelerator does not require kernel drivers under Linux due to the fact usb drivers can done as userspace code. Heck it possible to do PCI/PCI-e cards as userspace code under Linux. Yes I do mean fake accelerator is another thing you see some of these NDA protected programs calling their dongle and it kind of clear fake that when you use the more distribution restrictive version you don't need the pci/pci-e card and it processes faster and the card has no heat sink at all.

            Comment


            • #66
              Originally posted by oiaohm View Post
              Does not have to be full container. Old programs if users wanted them could be flatpak. Loki games only require quite a small runtime. The recent work to make dlmopen work will allow mixing new libraries with these older programs. So the fact that these old programs still work under current Linux distributions with effort being a chroot/container/runtime. Valve is funding the work I pointed to showed at debian conf 2018 because they have a lot of programs requiring older versions of glibc.
              Uhm, flatpak is kind of a full blown container in a way, being a sandbox and all... I don't know what you mean by "container". To me, a full sandbox (not a union of your original filesystem with another) is a container.

              Originally posted by oiaohm View Post
              Again lack of knowledge. I can tell you that the drivers for Syncrosoft and PACE iLok don't contain anything that prevents them from running under the current wine winedevice problem is winedevice don't have the parts emulated/redirected so they can talk to the dongles so they believe their dongle is not plugged in. So someone funding a developer to work on this could make it work. This is a lack of resources problem yes people are annoyed that wine does not support these yet but they are not putting up the money to pay developer to make them work either.

              Winedevice loads windows kernel driver in ring 3 instead of ring 0 so if the driver does contain checks for ring 0 or perform an action requiring ring 0 then that will not work most windows drivers don't in fact check if they are running at ring 0 or perform action that require ring 0 directly the legacy of the micro kernel design in NT kernel. So most cases it not drivers stopping program from working but the features those drivers need not being implemented.
              Nah, pretty sure they use privileged instructions, at least Syncrosoft probably (I don't know about iLok). There's a reason they need drivers on Windows, and aren't just installed as a userspace library.

              I heard Syncrosoft even does virtualization to hide its interaction with the dongle and obfuscate. I admit I don't know how it works, I'm not a reverse-engineer, but I know for a fact that Syncrosoft wasn't cracked for over a decade. That should tell you something.

              You always think you know how easy everything works, but no. I'm fairly certain Syncrosoft uses virtualization.



              _________________________

              BTW, I have a question about PunkBuster seeing as you really care a lot about it. How the fuck does it work on Linux, like say, Gentoo? Checksums will always fail given that you compile the code yourself.

              If you mean that it has the checksum function removed, then it should NOT be called PunkBuster anymore because it's simply not the same thing as on Windows. Ergo, the Windows implementation will never be "ported" to Linux and never work on Linux, which was the point. It's not Wine's fault.

              You can't just say "Wine sucks because it can't handle an impossible copy protection" when that copy protection can simply not exist on Linux in that state. If you remove it and port it to Linux, that doesn't prove anything. Wine would also work if it was removed from the Windows version, you know. So it's not Wine's fault (and neither Linux), but more like the copy protection's.
              Last edited by Weasel; 06 August 2018, 08:37 AM.

              Comment


              • #67
                Originally posted by Weasel View Post
                Uhm, flatpak is kind of a full blown container in a way, being a sandbox and all... I don't know what you mean by "container". To me, a full sandbox (not a union of your original filesystem with another) is a container.
                Really would users care as long as the applications they want work right?

                Originally posted by Weasel View Post
                Nah, pretty sure they use privileged instructions, at least Syncrosoft probably (I don't know about iLok). There's a reason they need drivers on Windows, and aren't just installed as a userspace library.
                A cross-platform library to access USB devices . Contribute to libusb/libusb development by creating an account on GitHub.

                First question you have to ask what is privileged to kernel module/usermode in windows vs linux. There is a differences.

                The generic windows USB access from userspace lib cannot do a stack of things generic USB access from userspace lib on Linux can do like reset the USB device what is kind of important if the device locks up for some reason. Also using using the generic under windows you cannot set up exclusive access these things are privileged under windows not so under Linux.

                So you are doing a dongle USB you must implement a driver under windows or you don't have the control over dongle when things go wrong. You can be fairly sure at some point things will go wrong like the the dongle trying to encode a new license and running out of power on the USB bus to-do that and locking up.

                Of course many parties have implemented dongle protection under windows and has not given a stuff about this problem.

                For example http://www.tdi-matrix.com/english/e_products.htm yes Linux, OS X and Windows support dongle protected programs no drivers. If you have dongle issues with matrix it will drive you nuts with OS X or Windows as neither can reset the USB key without a driver installed. Works fine under Linux. This is what happens when you have had lots of these dongle protected software some really suxs.

                Originally posted by Weasel View Post
                I heard Syncrosoft even does virtualization to hide its interaction with the dongle and obfuscate. I admit I don't know how it works, I'm not a reverse-engineer, but I know for a fact that Syncrosoft wasn't cracked for over a decade. That should tell you something.

                You always think you know how easy everything works, but no. I'm fairly certain Syncrosoft uses virtualization.
                Syncrosoft was bought out by steinberg.

                Steinberg Nuendo if you look around for cracks you will find it being cracked quite a few times this is Syncrosoft eLicenser using software. So your claim that Synrosoft was not cracked for over a decade is wrong. Syncrosoft has been cracked many times before 2008 also after steinberg it also has been cracked many times as well. Cracking syncrosoft/steinberg Elicenser its like cracking a redhat license key having the software work and no updates or online help is not much use. And worse than redhat invalid key attempt to download updates results in been sent disable code.

                Yes Syncrosoft eLicenser does have some issues but its not from drivers it from DEP because it is using its own internal JIT on a internal bytecode for anti reverse engineering in the userspace program..

                iLok has also been defeated a few times as well.

                Both iLok and Syncrosoft in there current windows kernel drivers don't polymorph or anything else stupid they do that in the userspace code. They use to be horrible but with Microsoft a few years back threatening to pull certificates and refusing to sign horrible kernel mode drivers so lots of the really horrible stuff stopped in windows drivers. The automated certification to get drivers signed for windows these days will reject submitted drivers doing horrible things like attempt to directly access user-space memory or polymorphic.

                Basically weasel it use to be a problem that these software protection dongle drivers would not work with winedevice due to doing really horrible things. Now that they will not get signed by Microsoft if they are doing stupid crap in kernel space the stupid crap is now restricted to userspace. So now a most of the software protection drivers will run winedevice perfectly but fail due to wine device not supporting all the stuff required to in fact talk to the hardware.. Now if their supporting userspace programs work in wine itself that is another problem thinking they are still full of lets over write sections of the executable code. So the arguement is now expanding winedevice implementation and making wine running userspace application being able to handle those doing really security unsafe things.

                You should have noticed that game protection has been depending less and less on kernel space drivers for the same reason Microsoft is refusing to sign if driver is too stupid and cannot be validates not to be source of stability problem.

                Originally posted by Weasel View Post
                BTW, I have a question about PunkBuster seeing as you really care a lot about it. How the fuck does it work on Linux, like say, Gentoo? Checksums will always fail given that you compile the code yourself.
                Linux Punkbuster demands you use a known runtime like the steam runtime or run in limitation validation(don't validate all the system provided libraries) choice of server program is connecting to.

                Originally posted by Weasel View Post
                If you mean that it has the checksum function removed, then it should NOT be called PunkBuster anymore because it's simply not the same thing as on Windows. Ergo, the Windows implementation will never be "ported" to Linux and never work on Linux, which was the point. It's not Wine's fault.
                So Punkbuster is the same checksuming on Linux as windows with a few more control options on what it checks. Lot of the complaints from wine users about PunkBuster is they could provide option to reduced the checking on Wine like Punkbuster do on Linux so then Wine would work for more applications. So the problem is not pure wine project any more its PunkBuster problem and the answer got from Punkbuster is they are not changing this any time soon.

                Comment


                • #68
                  Originally posted by oiaohm View Post
                  Really would users care as long as the applications they want work right?
                  In terms of placing the blame, yeah, to me it does.

                  Originally posted by oiaohm View Post
                  https://github.com/libusb/libusb/wiki/Windows
                  First question you have to ask what is privileged to kernel module/usermode in windows vs linux. There is a differences.

                  The generic windows USB access from userspace lib cannot do a stack of things generic USB access from userspace lib on Linux can do like reset the USB device what is kind of important if the device locks up for some reason. Also using using the generic under windows you cannot set up exclusive access these things are privileged under windows not so under Linux.

                  So you are doing a dongle USB you must implement a driver under windows or you don't have the control over dongle when things go wrong. You can be fairly sure at some point things will go wrong like the the dongle trying to encode a new license and running out of power on the USB bus to-do that and locking up.

                  Of course many parties have implemented dongle protection under windows and has not given a stuff about this problem.

                  For example http://www.tdi-matrix.com/english/e_products.htm yes Linux, OS X and Windows support dongle protected programs no drivers. If you have dongle issues with matrix it will drive you nuts with OS X or Windows as neither can reset the USB key without a driver installed. Works fine under Linux. This is what happens when you have had lots of these dongle protected software some really suxs.
                  The drivers aren't for talking to the dongle only, that's a small part of it. It's for encrypting and obfuscating them so that a kernel-mode debugger cannot easily trace it.

                  Originally posted by oiaohm View Post
                  Syncrosoft was bought out by steinberg.

                  Steinberg Nuendo if you look around for cracks you will find it being cracked quite a few times this is Syncrosoft eLicenser using software. So your claim that Synrosoft was not cracked for over a decade is wrong. Syncrosoft has been cracked many times before 2008 also after steinberg it also has been cracked many times as well. Cracking syncrosoft/steinberg Elicenser its like cracking a redhat license key having the software work and no updates or online help is not much use. And worse than redhat invalid key attempt to download updates results in been sent disable code.

                  Yes Syncrosoft eLicenser does have some issues but its not from drivers it from DEP because it is using its own internal JIT on a internal bytecode for anti reverse engineering in the userspace program..

                  iLok has also been defeated a few times as well.

                  Both iLok and Syncrosoft in there current windows kernel drivers don't polymorph or anything else stupid they do that in the userspace code. They use to be horrible but with Microsoft a few years back threatening to pull certificates and refusing to sign horrible kernel mode drivers so lots of the really horrible stuff stopped in windows drivers. The automated certification to get drivers signed for windows these days will reject submitted drivers doing horrible things like attempt to directly access user-space memory or polymorphic.

                  Basically weasel it use to be a problem that these software protection dongle drivers would not work with winedevice due to doing really horrible things. Now that they will not get signed by Microsoft if they are doing stupid crap in kernel space the stupid crap is now restricted to userspace. So now a most of the software protection drivers will run winedevice perfectly but fail due to wine device not supporting all the stuff required to in fact talk to the hardware.. Now if their supporting userspace programs work in wine itself that is another problem thinking they are still full of lets over write sections of the executable code. So the arguement is now expanding winedevice implementation and making wine running userspace application being able to handle those doing really security unsafe things.

                  You should have noticed that game protection has been depending less and less on kernel space drivers for the same reason Microsoft is refusing to sign if driver is too stupid and cannot be validates not to be source of stability problem.
                  Well to me it's good Microsoft stepped in, I really hate such intrusive measures, hopefully this means better support for apps in the future to run them under Wine. But it doesn't change the fact that it used to be bad in the past and a lot of people complain about Wine not running old apps with stuff like that. (also iLok was defeated due to implementation flaws, heh)

                  Originally posted by oiaohm View Post
                  Linux Punkbuster demands you use a known runtime like the steam runtime or run in limitation validation(don't validate all the system provided libraries) choice of server program is connecting to.
                  Too bad duby229 has an issue with that, since he wants open source software he compiles himself. ;-)

                  I'm saying to him, PunkBuster is not "Linux compatible" since that's what Linux means to him and a lot of others.

                  Comment


                  • #69
                    Originally posted by Weasel View Post
                    In terms of placing the blame, yeah, to me it does.

                    The drivers aren't for talking to the dongle only, that's a small part of it. It's for encrypting and obfuscating them so that a kernel-mode debugger cannot easily trace it.
                    Making kernel mode debugger unable to trace your driver cause it to fail Microsoft validation and not get signed. Part of validation is Microsoft running debugger over your driver. Obfuscating is restricted to userspace these days. Microsoft got sick of bug reports of kernel panics caused by obfuscating gone wrong so they have drawn line in sand.

                    Originally posted by Weasel View Post
                    Well to me it's good Microsoft stepped in, I really hate such intrusive measures, hopefully this means better support for apps in the future to run them under Wine. But it doesn't change the fact that it used to be bad in the past and a lot of people complain about Wine not running old apps with stuff like that. (also iLok was defeated due to implementation flaws, heh)
                    Steinberg/Syncrosoft eLicenser you install current version and it super-seeds all old versions. So all the old applications using Syncrosoft eLienser are converted to the new one even if they are not registered yet. iLok is the same. So the problem is getting the current versions of both of them to work then all the prior software will work. Of course the obfuscating in userspace is still a serous pain particular when it start depending on different areas of memory wine uses that are not application allocated and the application expects to write there.

                    Why are they done with superseeds method simple they knew issues would appear where the system would get cracked and new system would have to be deployed. When they release new version to activate software again you need to update software. This does make iLok and eLicenser hard because they are also moving target.

                    Originally posted by Weasel View Post
                    Too bad duby229 has an issue with that, since he wants open source software he compiles himself. ;-)

                    I'm saying to him, PunkBuster is not "Linux compatible" since that's what Linux means to him and a lot of others.
                    Really https://reproducible-builds.org/ just because you build something yourself does not mean the binaries have to be any different. For punkbuster to work 100 percent right the binaries have to be the same. Of course if the binaries have a reproducible build system you could have built all the game yourself and it will work with punkbuster perfectly because it will not matter if you download the binary or the source because the resulting binary would be the same.

                    Basically you should not say stuff when you are so clueless Weasel. Punkbuster puts limitations on you does not say you cannot build the game from source just limits how you can do it.

                    Please note I said known run-time. Not a run-time that has to ship as binary. Reproducible build produced run-time is still a known run-time. Yes the steam runtime you can down load and do a reproducible build on and produce exactly the same as valve ships.

                    Comment


                    • #70
                      Originally posted by Weasel View Post
                      Too bad duby229 has an issue with that, since he wants open source software he compiles himself. ;-)

                      I'm saying to him, PunkBuster is not "Linux compatible" since that's what Linux means to him and a lot of others.
                      Like I said already, I'm not new, I chose Gentoo because of use flags. But, gentoo is a minority and everybody else chose linux for their own reasons, you can bet your last dollar for most of them it wasn't so they could compile things. Whether they realize it or not the fact that they can is a good thing for them, at least they get a kernel and a userspace peer reviewed by dozens of distributions and tens of thousands of people.

                      Comment

                      Working...
                      X