Announcement

Collapse
No announcement yet.

Google Still Doesn't Trust Linux GPU Drivers Enough To Enable Chrome Video Acceleration

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

  • Originally posted by pal666 View Post
    amd media drivers are in mesa. some work is done by closed source firmware, but same is true for 3d drivers
    I should have been more specific. I'm thinking of Intel hardware. AMD is doing a fine job here and I wish Intel was doing the same.

    Comment


    • Originally posted by pal666 View Post
      that was third line. first line is:
      You're right, my bad, I should've included first line which says: particularly legacy 16-bit editions.

      Thanks for doing me a favor to discredit your argument more. ;-)

      Originally posted by pal666 View Post
      how windows ecosystem-specific thing can be linux, not windows? it is windows-specific and it has special term, therefore it happened on windows a lot. while my opponent tried to lie that it never happened
      I was talking about "Dependency Hell" I quoted, go look at the wikipedia article. That's what sounds like Linux and is NOT Windows specific.

      Here link in case you're too lazy: https://en.wikipedia.org/wiki/Dependency_hell

      Originally posted by pal666 View Post
      moron is someone who confuses "particularly" with "only"
      You don't get it. DLL Hell is a term used for dependency hell on Windows, but the only Windows-specific parts of it are in 16-bit Windows. Everything else is common to all OSes that use dynamic libraries.

      However, Linux userland is worse, due to ELF and crappy developer choices (breaking ABI compatibility).

      You know it's shit when the Linux kernel follows a completely different model (full ABI compatibility forever). So Linux has a "split" design and only one of them can be right. Do you think the kernel is wrong and shit? Or the userland? Pick one.

      Clearly "Linux" means just the kernel though... so... I side with Torvalds and the kernel... which makes the userland total shit ;-) (and yes he did complain about it, on several occasions, you cannot have your cake and eat it too, sorry)


      Here's Linus and his opinion on why Windows and macOS userland are better (you know, the guy who made the kernel): https://www.youtube.com/watch?v=5PmHRSeA2c8&t=357

      You can babble all you want. He has no interest to sabotage his own project. He's just stating facts.
      Last edited by Weasel; 05 October 2018, 11:46 AM.

      Comment


      • Originally posted by Weasel View Post
        Here's Linus and his opinion on why Windows and macOS userland are better (you know, the guy who made the kernel): https://www.youtube.com/watch?v=5PmHRSeA2c8&t=357
        Well, at first Linus didn't publish Linux binaries for his Subsurface app. Third-party cross-distro binary software packaging undoubtedly has been historically a mess. Since then however an AppImage binary for Subsurface has been released. Also, flatpak and Snappy have emerged.

        I am not entirely sure what are you claiming here, but there have been certain claims by Windows fanboys, like that it was supposedly somehow impossible to have different versions of shared objects to coexist on Linux. Those claims don't hold water.

        Comment


        • Originally posted by Sonadow View Post
          Linux's userland is so damn monolithic and glued together with stupid dependencies that result in the application suddenly failing to launch after an update.
          Exactly! This is *exactly* what has to be fixed in Linux userspace in order for it to become a good desktop OS.

          Here I propose a solution:

          - Separate the userland into 2 spaces: the base system one (the monolithic and glued together one), and the other "variable" one (for user applications, macOS style).

          - The base system provides an "SDK" which can be used to develop applications for the "variable" space, and it must consist solely of very stable (as in API) libraries.

          - Developers can still target the base system, but they are encouraged to use the "SDK".

          Although Flatpak and AppImage are trying to do something like this, they have problems. In Flatpak it demands sandboxing. In AppImage there is no standard "library base", resulting in developers having to pack in many libraries (which sometimes are often used like Qt), and as such AppImage versions of apps are generally bigger than their macOS/Windows counterparts. Furthermore, they don't want the developer to use newer versions of certain libraries (such as newer versions of glibc) to "achieve broad compatibility". What if he/she really needs to use the new features?

          Also, it requires the user to "make it executable", something the Windows/Mac user doesn't do when he/she downloads an application.
          Last edited by tildearrow; 06 October 2018, 02:10 PM. Reason: correction

          Comment


          • Originally posted by tildearrow View Post
            In Flatpak you can't install applications from files (the Android way)
            False.

            http://docs.flatpak.org/en/latest/si...e-bundles.html

            Comment


            • Originally posted by tildearrow View Post

              Exactly! This is *exactly* what has to be fixed in Linux userspace in order for it to become a good desktop OS.

              Here I propose a solution:

              - Separate the userland into 2 spaces: the base system one (the monolithic and glued together one), and the other "variable" one (for user applications, macOS style).

              - The base system provides an "SDK" which can be used to develop applications for the "variable" space, and it must consist solely of very stable (as in API) libraries.

              - Developers can still target the base system, but they are encouraged to use the "SDK".

              Although Flatpak and AppImage are trying to do something like this, they have problems. In Flatpak you can't install applications from files (the Android way), and it demands sandboxing. In AppImage there is no standard "library base", resulting in developers having to pack in many libraries (which sometimes are often used like Qt), and as such AppImage versions of apps are generally bigger than their macOS/Windows counterparts. Furthermore, they don't want the developer to use newer versions of certain libraries (such as newer versions of glibc) to "achieve broad compatibility". What if he/she really needs to use the new features?

              Also, it requires the user to "make it executable", something the Windows/Mac user doesn't do when he/she downloads an application.
              You do realize that what you're complaining about is the whole entire point for package management right? And the truth is as long as you actually use package management exclusively none of what you just complained about is even a problem.., It is exactly what package management solved decades ago.

              Comment


              • Originally posted by Weasel View Post
                You're right, my bad, I should've included first line which says: particularly legacy 16-bit editions.

                Thanks for doing me a favor to discredit your argument more. ;-)

                I was talking about "Dependency Hell" I quoted, go look at the wikipedia article. That's what sounds like Linux and is NOT Windows specific.

                Here link in case you're too lazy: https://en.wikipedia.org/wiki/Dependency_hell

                You don't get it. DLL Hell is a term used for dependency hell on Windows, but the only Windows-specific parts of it are in 16-bit Windows. Everything else is common to all OSes that use dynamic libraries.

                However, Linux userland is worse, due to ELF and crappy developer choices (breaking ABI compatibility).

                You know it's shit when the Linux kernel follows a completely different model (full ABI compatibility forever). So Linux has a "split" design and only one of them can be right. Do you think the kernel is wrong and shit? Or the userland? Pick one.

                Clearly "Linux" means just the kernel though... so... I side with Torvalds and the kernel... which makes the userland total shit ;-) (and yes he did complain about it, on several occasions, you cannot have your cake and eat it too, sorry)


                Here's Linus and his opinion on why Windows and macOS userland are better (you know, the guy who made the kernel): https://www.youtube.com/watch?v=5PmHRSeA2c8&t=357

                You can babble all you want. He has no interest to sabotage his own project. He's just stating facts.
                You do realize that every single thing you just complained about was solved decades ago? Right? I hope so, because the real truth is that package management has existed for a long time now and it actually works....

                Comment


                • Originally posted by duby229 View Post
                  You do realize that every single thing you just complained about was solved decades ago? Right?
                  Linus' talk was in 2014, 4 years is a decade now? And no, NOTHING changed, except for flatpak and snap being added as alternatives. The core packaging is still the same broken mess. ELF is still the same garbage format.

                  Originally posted by duby229 View Post
                  I hope so, because the real truth is that package management has existed for a long time now and it actually works....
                  Except it doesn't, and don't take my word for it, go listen to Linus. You clearly have no idea what you're talking about.

                  Just because your computer needs are trivially solved as a "mobile experience" by pushing a few buttons and automatically installing apps from some retarded centralized repository doesn't mean there are no problems. It only means your needs are too simple and out of the scope of anyone who complains. They don't give a shit about it. They complain of stuff you never use so why even talk?

                  For example, like idk, distributing your own app for Linux without a centralized repository. Alien concept to you, I bet.

                  Comment


                  • Originally posted by duby229 View Post
                    You do realize that what you're complaining about is the whole entire point for package management right?
                    You don't realize their entire complaint is about the retarded package management, right? Most devs don't want it. That's why they code for Windows only.


                    I don't even know what your point is honestly. It's like saying "Problems with Linux is that X, Y, Z" and you go and reply "you do realize entire point of Linux package management is X?"

                    Well no shit it means package management concept needs to fucking die in a fire.

                    Comment


                    • Originally posted by ilmaisin View Post
                      I am not entirely sure what are you claiming here, but there have been certain claims by Windows fanboys, like that it was supposedly somehow impossible to have different versions of shared objects to coexist on Linux. Those claims don't hold water.
                      Except it doesn't.

                      I don't know why I always have to repeat the same things. Have you guys *ever* considered that maybe you are simply *wrong*, given the fact that so many people complain about it on Linux, including Torvalds himself?

                      Ever stopped to think something like "gee, maybe I got it all wrong to think Windows is as broken with dependencies as Linux, since so many people complain about Linux. Maybe it's not *them* who are delusional, maybe *I am missing something* that I hadn't thought of yet!"

                      Please do that, anyone who reads it. It's good thing to learn in life. Valuable skill. Then proceed to read below and get enlightened.





                      Here's it for the 100th time:

                      Usually, if they use the same symbols (which is almost always the case due to laziness), you can't load two versions of the same library in the same application. You're asking, who the hell would load two versions of the same library in the same app? Nested dependencies.

                      Brief explanation with two examples:
                      • Your app depends on lib2 and hosts plugin with XYZ interface, like other such host apps. ABC plugin, though, uses lib1. What do you think happens? On Windows, it works since all modules have local symbols. In ELF, they are global, so you get a fiasco. Linux-only dependency hell.
                      • Your app depends on lib1 and libfoo. Your distro only supplies lib5 and its own updated (but STILL COMPATIBLE) libfoo. What do you do? On Windows, you simply supply lib1.dll with your app and it just works no matter what the system has (lib5).

                        On Linux, though, it's not quite so simple yet. It might work, or it might not, it depends on the nested dependencies of the other libraries on the system. Let's look at libfoo. When you compiled your app, libfoo on your machine depended on lib1. Now, however, libfoo depends on libshit, which depends on lib5. Yes you have to walk the entire dependency chain recursively to find out if an app will "just work" on Linux, whereas on Windows you only need to look at the immediate dependencies to know that.

                        So, on Linux, you have to look at all the dependencies of ALL the dependencies, recursively because it's a spaghetti mess due to ELF's global symbol retardation. On Windows all symbols are local to a module, so you can import both lib1 and lib5 without issues in the same process.

                        If libfoo loads libshit which loads lib5, your app will simply fail on Linux with a crash or worse.

                        Solution is to bundle THE ENTIRE CHAIN down to libc, which is exactly what flatpak does, and it's also why it is 500 fucking megabytes for an app, instead of like 10MB in Windows. Because Linux userland is just broken and it has a MUCH WORSE dependency hell than Windows. MUCH worse. Due to global symbols.
                      Even if the system satisfies other dependencies (such as libfoo) and is perfectly compatible in ABI/API, you still have to bundle the exact version you used when compiling your app, since it might rely on other libraries that conflict with some of yours.

                      Nested dependencies are mostly a ELF-only hell.
                      Last edited by Weasel; 06 October 2018, 10:55 AM.

                      Comment

                      Working...
                      X