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 Weasel View Post
    Lol, what a clown. Don't shit yourself with embarrassment: https://flatpak.org/

    Look at the features:


    Stable platform = your "walled garden" hysteria.
    Consistent environments = see above.
    Full control over dependencies = sounds like Windows already.

    Future-proof builds = ABI stability you fucking retard.



    So moron, how about you prove your bullshit?
    Idiot, upgrade glibc alone and watch your abi stability disappear. The -ONLY- way to get abi stability on linux is to -NEVER- upgrade anything. Very, very few projects maintain abi stability. Moron.

    EDIT: Almost no projects available for a linux userspace were made to be abi stable, basically all of them were made to be version controlled.
    Last edited by duby229; 08 October 2018, 01:02 PM.

    Comment


    • Originally posted by duby229 View Post
      Idiot, upgrade glibc alone and watch your abi stability disappear. The -ONLY- way to get abi stability on linux is to -NEVER- upgrade anything. Very, very few projects maintain abi stability. Moron.

      EDIT: Almost no projects available for a linux userspace were made to be abi stable, basically all of them were made to be version controlled.
      Too bad flatpak runtime provides its own libc for exactly this reason, due to the pathetic mess native Linux userland is in, eh?

      Keep digging that hole. Like oiaohm, you make bold claims without knowing how shit works. Such a clown.

      Imagine if you had to provide your own kernel32 in Windows. Thankfully, it's not designed as shit as Linux userland, so it's a better platform than even flatpak runtimes are. Too bad the OS is shit, but hey, we have Wine to provide us that platform on Linux, so it's all good.

      Comment


      • Originally posted by Weasel View Post
        Too bad flatpak runtime provides its own libc for exactly this reason, due to the pathetic mess native Linux userland is in, eh?

        Keep digging that hole. Like oiaohm, you make bold claims without knowing how shit works. Such a clown.

        Imagine if you had to provide your own kernel32 in Windows. Thankfully, it's not designed as shit as Linux userland, so it's a better platform than even flatpak runtimes are. Too bad the OS is shit, but hey, we have Wine to provide us that platform on Linux, so it's all good.
        Which is exactly is exactly why you are guaranteed to get undefined symbols and I never ever will.

        Comment


        • Originally posted by duby229 View Post
          Which is exactly is exactly why you are guaranteed to get undefined symbols and I never ever will.
          No idea what you refer to. Neither flatpak nor Windows will ever give you "undefined symbols" unless you try to load a symbol that doesn't exist on an older version of Windows, which is reasonable. It's like calling a kernel function that isn't implemented cause the kernel is too old. (and yes kernel is also stable)

          So no, I don't have this problem, not on Wine, not on flatpak. It's a Linux "native" only problem due to its "wonderful" volatile design.

          Comment


          • Originally posted by Weasel View Post
            Oh, but it is going to work, as evidenced by virtually every other desktop OS in existence, including Linux but only with some environments. One out of:

            1) Wine
            2) Flatpak
            3) Snap
            4) AppImage

            works, excluding:

            5) "Native"

            which doesn't, guess why?
            Try again on 5. http://www.xonotic.org/
            Download xonotic zip unpack it. Its native and it works with as much compatibility as Appimage. If you don't like the size of that you could download the firefox zip instead.

            Originally posted by Weasel View Post
            So no, I don't have this problem, not on Wine, not on flatpak. It's a Linux "native" only problem due to its "wonderful" volatile design.
            Linux native and Appimage are exactly the same. The same issues that break Appimage break native binaries packaged to be portable.

            Please note with appimage you can choose to bundling nothing and if you bundling nothing is exactly the failures as just a native binary with nothing bundled.

            Wine, Flatpak, Snap have that you will have stuff bundled by someone.

            Also weasel did you ever look inside wine. I guess not.



            Interesting right. Wine need to use a library it dlopen it.

            Wine is a cross platform native Linux binary. So you can built it on one system copy it different system of a different distribution install it and it works.

            The one thing wine tells you is that you need a shim system. Shim like wine does use the libraries like wine does and stick to C and you can build quite a cross platform native binary. So native does in fact work if you go about it the right ways.

            Of course to use C++ you will be needing dlmopen instead of dlopen basically libcapsule.

            Reality with wine project 1 package maintainer builds for 5 major distributions this is a total of 15 different packages. The reality is he has only built wine once then packaged it 15 times. Then those packages turn out to be install-able on may of the relations. Yes that form of packaging has been done by the wine project for over 10 years now.

            The linux native is a lot more stable than most think.

            There are reasons why you dlopen like if a so has version symbols as long as the symbol name exists using dlopen path will get you a symbol. You straight link you application to library newest version of symbol and avoid symbol versioning.

            Basically what wine does for windows .exe files libcapsule can do to native binaries. Wine is just one huge shim system redirecting what windows binaries and dlls want. Wine is a cross distribution shim system. So your option 1 nukes your point about option 5.

            Comment


            • Originally posted by oiaohm View Post
              Try again on 5. http://www.xonotic.org/
              Download xonotic zip unpack it. Its native and it works with as much compatibility as Appimage. If you don't like the size of that you could download the firefox zip instead.
              Translation:

              I'm a retard called oiaohm, so to prove that ELF is not garbage, I will give you an example of an application that is statically linked and completely bypasses all of ELF's idiocy!

              Bypassing idiocy does not mean that the idiocy is sane, son. It only reinforces the opposite. So the fact it had to resort to it pretty much confirms my point even more, thanks.

              Originally posted by oiaohm View Post
              Also weasel did you ever look inside wine. I guess not.

              https://github.com/wine-mirror/wine/...coped_q=dlopen

              Interesting right. Wine need to use a library it dlopen it.
              LOL what? dlopen/dlsym is sane because it forces you to specify the module before the symbol. It is exactly like Windows DLLs.

              What's insane is about ELF's normal imports, not those done by dynamic code at runtime (those aren't even ELF itself, those are just APIs).

              So... I guess thanks for reinforcing the idea how pathetic ELF is, that even dlopen/dlsym is different (so it's assymetric)...?

              Originally posted by oiaohm View Post
              Wine is a cross platform native Linux binary. So you can built it on one system copy it different system of a different distribution install it and it works.
              I don't care about Wine itself. I'm talking about the platform that Wine gives you: Win32.

              That's what matters.

              I don't mind compiling and installing ONE thing to support all apps, it's like considering Wine part of the system, not a problem to me. Problem is when you consider each fucking app as "part of the system". That's the retardation in Linux userland.

              Same reason flatpak's installation itself is not an issue. Since it provides the platform itself and can just be considered part of the system.


              Nobody who considers flatpak as "stable" cares about flatpak, the application, itself. They care about the platform/environment that it gives to apps.

              Comment


              • Originally posted by Weasel View Post
                Translation:

                I'm a retard called oiaohm, so to prove that ELF is not garbage, I will give you an example of an application that is statically linked and completely bypasses all of ELF's idiocy!

                Bypassing idiocy does not mean that the idiocy is sane, son. It only reinforces the opposite. So the fact it had to resort to it pretty much confirms my point even more, thanks.

                LOL what? dlopen/dlsym is sane because it forces you to specify the module before the symbol. It is exactly like Windows DLLs.

                What's insane is about ELF's normal imports, not those done by dynamic code at runtime (those aren't even ELF itself, those are just APIs).

                So... I guess thanks for reinforcing the idea how pathetic ELF is, that even dlopen/dlsym is different (so it's assymetric)...?

                I don't care about Wine itself. I'm talking about the platform that Wine gives you: Win32.

                That's what matters.

                I don't mind compiling and installing ONE thing to support all apps, it's like considering Wine part of the system, not a problem to me. Problem is when you consider each fucking app as "part of the system". That's the retardation in Linux userland.

                Same reason flatpak's installation itself is not an issue. Since it provides the platform itself and can just be considered part of the system.


                Nobody who considers flatpak as "stable" cares about flatpak, the application, itself. They care about the platform/environment that it gives to apps.
                Like I already said, that's exactly why you are absolutely guaranteed to get undefined symbols and I never will. If you package an old glibc or any old library it definitely will happen to you. And -YOU- are guaranteeing that you are going to do it to yourself.

                Comment


                • Originally posted by duby229 View Post
                  Like I already said, that's exactly why you are absolutely guaranteed to get undefined symbols and I never will. If you package an old glibc or any old library it definitely will happen to you. And -YOU- are guaranteeing that you are going to do it to yourself.
                  I really have no idea what you're talking about and how that has anything to do with what you quoted.

                  If you are referring to flatpak, then all flatpak apps are aware of the runtime environment, so they know the version of libc they are up against. Otherwise they're compiled wrong and broken.

                  Nobody forces you to use one libc for every single app, duh. You do realize that, right? flatpak does not use the system libc and provides its own libc for EACH runtime it uses (depends on app), and ONLY APPS targeted for flatpak will use that libc from flatpak. Whole point is to provide a stable environment.

                  I'm guaranteeing that I will never have a symbol issue myself, thanks for the worry though. As I don't use any native apps unless they are statically linked and rely only on libc (which is supposed to be "stable"), which basically means just command line apps or bloated apps (games...). Of course, talking about non-system-specific apps, I don't care about those in the slightest.

                  For anything else, it's a stable platform for me. Win32 (Wine) or flatpak. I don't use "native" Linux apps (again, excluding system-specific apps).

                  Zero headaches.
                  Last edited by Weasel; 10 October 2018, 03:12 PM.

                  Comment


                  • Originally posted by Weasel View Post
                    I'm a retard called oiaohm, so to prove that ELF is not garbage, I will give you an example of an application that is statically linked and completely bypasses all of ELF's idiocy!
                    Weasel you are the Retard the xonotic. binary is not statically linked its a dynamic binary. The developers has built it a particular way.


                    Originally posted by Weasel View Post
                    LOL what? dlopen/dlsym is sane because it forces you to specify the module before the symbol. It is exactly like Windows DLLs.

                    What's insane is about ELF's normal imports, not those done by dynamic code at runtime (those aren't even ELF itself, those are just APIs).

                    So... I guess thanks for reinforcing the idea how pathetic ELF is, that even dlopen/dlsym is different (so it's assymetric)...?
                    No xonotic cross platform application build pulls off the same stunt wine does without using dlopen/dlsym. Its funny how far you can get when you build shims to link against(shims that are only used when you build program) that don't have version information.

                    In fact in your import process you do have the option of declaring specify module in elf with the version information. Lots of your failure to be cross distribution is you have specified exact module version if that version is not their the dynamic linker refused to link the symbol. gcc serous-ally does not make it easy to avoid this. to avoid having versions set you need to make a stub out .so file without versions or use dlopen/dlsym.

                    Default gcc/llvm on elf platforms is forcing you to define module, symbol and version of that symbol even that dynamic linker will be quite happy with just module and symbol.

                    dlopen/dlsym is just direct driving the dynamic linker. You can generate the same failures as a normal elf build on a Linux distribution on a PE binary by going stupid with you manifest file like having a windows 2000 binary and putting a manifest on it that demands windows 10 parts then only runs on Windows 10.

                    Also once you have build without version information what is lot harder than what it should you can preload any library that soname/file name has changed yet contain the same functions. This is due to having 1 link map.


                    Originally posted by Weasel View Post
                    I don't care about Wine itself. I'm talking about the platform that Wine gives you: Win32..
                    This means you never looked. Wine tells a interest story.

                    Please note dlopen/dlsym is just a method without having to build shims to build against not to have version information on the symbols you are linked against.

                    Using dlopen does not prevent conflict between two libraries using different versions of C++. To avoid symbol conflit you need to use dlmopen wine does not because that thing has been nastily buggy. Please note you can have dlmopen used on your library at load by specifying when you are build that its a audit library under Linux or Solaris. Please note historic glibc has had stupid issues like a max of 16 link maps per program and no shared libraries added to the new link map no matter what function you use. This is the same as what you get when you build a win32 nt native binary that purely depends on ntdll or uses direct kernel syscalls(under windows that is insane).

                    nt native exists for debug subsystem parts like kernel32.dll while not depend on them. So if kernel32.dll happened to have a bug that caused everything running kernel32 to crash you would not want your debugger depending on kernel32.dll right. Of course you still want means to load libraries.

                    When you use loadlibrary in kernel32 under windows you get a common library. libcapsule basically gives you kernel32 loadlibrary. dlmopen historically when it works gives you like loading libraries using ntdll functions good for debugging/auditing so not much to application developer as they automatically create split brain and are designed to do exactly that and is a useful debugging feature.



                    Comment


                    • Originally posted by oiaohm View Post
                      Weasel you are the Retard the xonotic. binary is not statically linked its a dynamic binary. The developers has built it a particular way.
                      Lol there's no difference.

                      If you use dlopen/dlsym you are using the exact same behavior as DLLs and bypassing ELF's retarded global symbols.

                      Thanks for, yet again, proving my point even more. Idiot.

                      Originally posted by oiaohm View Post
                      No xonotic cross platform application build pulls off the same stunt wine does without using dlopen/dlsym.
                      Which demand you to specify a library to import a symbol from. Sounds like DLLs.

                      xonotic sounds like it does "manually" what DLLs do "automatically".

                      Yes this definitely proves ELF is so well designed for idiots like you that you have to painstakingly do it manually and avoid its normal bullshit loader.

                      Originally posted by oiaohm View Post
                      This means you never looked. Wine tells a interest story.

                      Please note dlopen/dlsym is just a method without having to build shims to build against not to have version information on the symbols you are linked against.

                      Using dlopen does not prevent conflict between two libraries using different versions of C++. To avoid symbol conflit you need to use dlmopen wine does not because that thing has been nastily buggy. Please note you can have dlmopen used on your library at load by specifying when you are build that its a audit library under Linux or Solaris. Please note historic glibc has had stupid issues like a max of 16 link maps per program and no shared libraries added to the new link map no matter what function you use. This is the same as what you get when you build a win32 nt native binary that purely depends on ntdll or uses direct kernel syscalls(under windows that is insane).

                      nt native exists for debug subsystem parts like kernel32.dll while not depend on them. So if kernel32.dll happened to have a bug that caused everything running kernel32 to crash you would not want your debugger depending on kernel32.dll right. Of course you still want means to load libraries.

                      When you use loadlibrary in kernel32 under windows you get a common library. libcapsule basically gives you kernel32 loadlibrary. dlmopen historically when it works gives you like loading libraries using ntdll functions good for debugging/auditing so not much to application developer as they automatically create split brain and are designed to do exactly that and is a useful debugging feature.
                      Can you just shut up about dlopen/dlsym?

                      I never complained about those. Those work *exactly* like DLLs and LoadLibrary/GetProcAddress. Why would I complain about them?

                      Stop changing the subject and being so desperate.

                      To me the fact that they are literally your only argument just proves you already lost any argument you had about ELF not being retarded with global symbol namespace.

                      Now you say "see ELF is not so bad it can be like DLLs if you load symbols manually" when the point was the loader not using dynamic lookup in code.

                      And the best part? Nothing of what you said makes DLLs any worse. It's just you trying to desperately hack your way through with shitty ELF just to end up with the functionality of a DLL. dlopen/dlsym are testament to that.
                      Last edited by Weasel; 11 October 2018, 08:09 AM.

                      Comment

                      Working...
                      X