Announcement

Collapse
No announcement yet.

The Leading Linux Desktop Platform Issues Of 2018

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

  • Originally posted by finite9 View Post
    I imagine Flatpak et al is useful in certain situations, but I don't want to have to download a 50MB app at every update as opposed to delta changes, and I don't want 50 apps on my system that all packaged the same 10MB library in different versions that are all out of date because the app developer has standardised on that library that he doesn't really care about because it's not a big part of his application, when the latest library is fully patched, available and installed from the repos on my system. I suppose that security argument comes down to: do I trust that the sandboxing in Flatpak will protect me from the developers laziness of updating a 10 yr old library vs does the latest library, installed once on my system, justify the hassle for developers of having to accomodate that library version in their application.

    And as for "platforms" like Android/iOS, have you ever noticed that base platform apps, that are part of the platform, are very tiny in size when updating, because they rely on other internal components being compatible that they can use and therefore don't need to package in that app component that's about to be updated? Whereas, third-party apps, not part of the base platform, are like 50MB and upwards sometimes, and every update is the same size, so often when a new update comes out a few times in quick succession, you've got to download the _full_ app again. It's not efficient use of bandwidth or storage space.

    So, It is a problem for standardisation, but Flatpak/AppImage and the One True Solution, sucks because it accomodates bad security and laziness.
    Not wanting to waste an extra 50MB is a pretty weak argument against Flatpak and AppImage in the age of multi terabyte SSDs. It's like these people with 16-32 GB RAM who complain about Electron's memory usage.

    Comment


    • Originally posted by GI_Jack View Post
      No the point of this thread is that "GNU/Linux Desktops don't have a sizable marketshare", which is "Year of the Linux Desktop". The reason is that Linux has poor support for proprietary apps cross distro. There is no open standard for closed apps.

      As far as actually using a Linux Desktop. It works better than windows 10.
      No the thread is about desktop issues, not that it doesn't have a sizable marketshare: it explains why that is so and the factors behind it, not just that it is so, everyone is aware of that fact.

      It has nothing to do with closed apps but binary compatibility, which is what closed apps require and open apps benefit from.

      Comment


      • Originally posted by Weasel View Post

        kernel32 gets loaded by the process loader, even if your executable has literally no imports whatsoever (yes there's malware that scans the address space for imports manually, with exception handling -- you don't have to use syscalls). Obviously, when a library gets loaded it gets loaded in the same process so kernel32 is already loaded, no matter what you do.

        Same with ntdll.

        https://docs.microsoft.com/en-us/win...p/dlls/dllmain
        The system also calls the entry-point function for a DLL when it is loaded or unloaded using the LoadLibrary and FreeLibrary functions.
        You missed this line why does it clearly mention this I guess you don't know. Those are if you are using kernel32.dll. There are library load functions in ntdll.

        Originally posted by Weasel View Post
        Clearly you haven't EVEN TESTED anything so you're full of shit, considering you said it's possible to not have ntdll/kernel32 loaded in a process (without employing exploits, I mean with normal CreateProcess).
        What I am referring is normal CreateProcess. Win32 program can have the NT native flag set. Once you set this flag all the things you believe in go by by.

        kernel32.dll is no longer default loaded into your application. There was a issue in the 3.11/9x time frame where some game developers thought that nt native was a go faster flag. Not I am a debugging flag. Nt native on win32/64 is like the audit flags they are designed to create a split brain. Lets say you have a program causin fault in kernel32 causing all applications to have it loaded to crash. How are you going to debug this. Knowing about nt native is really good if this happens.

        nt native flag is a method of disabling the normal CreateProcess preloads.
        Starting in Windows 8, the AppInit\_DLLs infrastructure is disabled when secure boot is enabled.

        Microsoft after vista disable this by default. So applications before vista can have nt native flag set and CreateProcess not behave how you described.

        Originally posted by Weasel View Post
        But kernel32 is still loaded even if you don't import it, the same kernel32 in literally every process in existence. That's why HeapAlloc/HeapFree can be used as long as they refer to same heaps (use GetProcessHeap() for most situations).
        This is not true. Diagnostic processes to diagnose kernel32.dll problems without being bound to kernel32.dll. This is because you are clueless about the nt native flag.


        Originally posted by Weasel View Post
        No, what ELF performs differently is that it does not FORCEFULLY ASSOCIATE a symbol with a library/module, and that is why it is garbage.
        Except that is not what you want. Forcefully associate symbols with module/library is nt native(audit flags on posix), Forcefully associated equals no common kernel32.dll/libc.

        You want something like kernel32.dll or libcapsule. That:
        1 forcefully associates some symbol with library/module/area of program not to be seen outside
        2 sets up commonly shared parts.

        ELF format does not say it cannot forcefully associate a symbol with a library/module. Problem is when you use the audit flag with the glibc dynamic loader. Its in fact associated all functions your library has used with your library using none of the libraries loaded by the application. Why it trigger your library to have its own link map. This is the same evil that the nt native flag under windows lets lose.

        So yes ELF can forcefully associate symbol with a library/module and not seen by other parts of the program. Problem is that is a sledge hammer. libcapsule is making that sledge hammer into a more usable item.

        You have presumed since something is not default that ELF cannot do it. ELF can do it. Problem is having the framework so its sane.

        Over time libcapsule could merge into glibc and then we could possible have a loader flag added other than audit. Audit is overkill.

        Of course a question to ask do you need every library to have its own non shared parts. The answer is most likely no.

        Windows basically has two states.
        1) using kernel32.dll like libcapsule.(what most windows developers know)
        2) nt native flag that is like solaris designed audit mode.(what most windows developers don't know)

        Linux has historically had 2 mode.
        1) share everything
        2) audit mode like nt native mode.(again most Linux developers don't know this beast exists either)

        Really all 3 modes to use where they suit is ideal.
        1) share everything
        2) libcapsule hopefully integrated into glibc.
        3) Audit mode.
        The complete split of world of audit mode and nt native has very useful debug cases.

        Originally posted by Weasel View Post
        That has nothing to do with it, those are function pointers and have nothing to do with SYMBOLS. They're also NOT used to destroy the zlib object -- but internally, so it doesn't matter since they'll always match.

        I'm talking about the fact that you use functions like inflateInit and inflateEnd, because like I said, construction and destruction are usually more than just freeing something. zlib NEVER asks you to free anything to "deallocate its state", instead it gives you functions to do that (init / end) like any proper API.

        Go and read it. Notice the z_streamp imported into inflateinit and inflateend. Go back up the page you will find in that structure.
        alloc_func zalloc; /* used to allocate the internal state */
        free_func zfree; /* used to free the internal state */
        Guess what you are meant to tell those functions what allocate solution to use. This is important because depending on your free you might be able to free an entry multi times. Straight after that you can manually nuke the state.

        inflateinit and inflateEnd was added to zlib when they added zalloc and zfree.

        Old posix programs using old zlib for inflateend will do
        free(z_stream.opaque)
        free(z_stream.mesg)
        free(z_stream)
        Yes you can still use zlib safely on posix platforms doing this.

        Really point me to zlib without looking at how programs on posix platform use zlib and wake up a lot don't use inflateinit/inflateEnd. So now your memory system better behave right.

        Comment


        • Originally posted by msotirov View Post

          Not wanting to waste an extra 50MB is a pretty weak argument against Flatpak and AppImage in the age of multi terabyte SSDs. It's like these people with 16-32 GB RAM who complain about Electron's memory usage.
          I want my computer to be able to do more with the more resources it has, and not to waste more. If applications double their RAM usage while I double the available RAM, I can still not do anything more than before. So that stupid app just wasted my resources. Especially for no real gain. A game (which usually runs kinda exclusive anyway; multitasking doesn't make that much sense while gaming) puts a use to those resources if it is able to render more, better, etc. However if a simple todo list application uses 500 MB RAM simply because it is actually a browser-wrapped-JS-piece-of-sh**, then that's not a gain in any way.

          Comment


          • Originally posted by aksdb View Post

            I want my computer to be able to do more with the more resources it has, and not to waste more. If applications double their RAM usage while I double the available RAM, I can still not do anything more than before. So that stupid app just wasted my resources. Especially for no real gain. A game (which usually runs kinda exclusive anyway; multitasking doesn't make that much sense while gaming) puts a use to those resources if it is able to render more, better, etc. However if a simple todo list application uses 500 MB RAM simply because it is actually a browser-wrapped-JS-piece-of-sh**, then that's not a gain in any way.
            Even worse, it evicts other useful stuff from caches at multiple levels too.

            Comment


            • Originally posted by msotirov View Post

              Not wanting to waste an extra 50MB is a pretty weak argument against Flatpak and AppImage in the age of multi terabyte SSDs. It's like these people with 16-32 GB RAM who complain about Electron's memory usage.
              I used the 50MB as an example from mobile platforms where data charges apply and storage space is substantially smaller at only on average 64GB (-12GB for the OS), but to be honest, i've not got that terabyte SSD you mention even in my home server, and 256GB SSD's are still the most common. And to be honest that's not the point, it's the principle, and it's a scaling issue. You think only in terms of one individual, but what happens when 7 billion people on mobile platforms are downloading a 50MB app every time it needs to update instead of perhaps a 2MB delta? That is electricity (battery drains faster, so needs charging more often) and global bandwidth of 7 billion people.

              Comment


              • Originally posted by oiaohm View Post
                The system also calls the entry-point function for a DLL when it is loaded or unloaded using the LoadLibrary and FreeLibrary functions.
                You missed this line why does it clearly mention this I guess you don't know. Those are if you are using kernel32.dll. There are library load functions in ntdll.
                WTF are you even talking about? The DllMain function gets called when you call FreeLibrary or LoadLibrary on the DLL, so that it has a chance to release resources.

                IT GETS CALLED FROM KERNEL32 SO IT **MUST** BE LOADED proving it even more.

                You always link and quote stuff YOU HAVE NO FUCKING IDEA OF thinking it gives you a point when in reality it's like quoting a random wikipedia article about something unrelated and claiming it supports your point.

                Originally posted by oiaohm View Post
                What I am referring is normal CreateProcess. Win32 program can have the NT native flag set. Once you set this flag all the things you believe in go by by.

                kernel32.dll is no longer default loaded into your application. There was a issue in the 3.11/9x time frame where some game developers thought that nt native was a go faster flag. Not I am a debugging flag. Nt native on win32/64 is like the audit flags they are designed to create a split brain. Lets say you have a program causin fault in kernel32 causing all applications to have it loaded to crash. How are you going to debug this. Knowing about nt native is really good if this happens.

                nt native flag is a method of disabling the normal CreateProcess preloads.
                https://support.microsoft.com/en-au/...registry-value
                Microsoft after vista disable this by default. So applications before vista can have nt native flag set and CreateProcess not behave how you described.
                Are you fucking retarded? ON THE PAGE YOU LINKED, it says: Because of their early loading, only API functions that are exported from Kernel32.dll are safe to use in the initialization of the AppInit DLLs.

                And also this: The AppInit DLLs are loaded by using the LoadLibrary() function during the DLL_PROCESS_ATTACH process of User32.dll.

                You do realize even *assuming* kernel32 did not get forcefully loaded as YOU claim, user32 imports kernel32, right...? So since AppInit DLLs are loaded by user32 which requires kernel32 to be loaded first (it imports it), all of your babbling is impossible, logically.

                Dude, just stop grasping for straws, you are fucking wrong and no amount of walls of text is going to change that fact. Shut the fuck up and do this forum a favor.

                Originally posted by oiaohm View Post
                Except that is not what you want. Forcefully associate symbols with module/library is nt native(audit flags on posix), Forcefully associated equals no common kernel32.dll/libc.
                No you are braindead.

                Forcefully associating HeapAlloc with kernel32 simply ensures that the HeapAlloc you request is loaded from kernel32. Since any other library can also export a HeapAlloc symbol which does something completely different.

                It is only on ELF where you can override libc's symbols with something rogue, so shut up.

                Roughly speaking, in layman's terms (it's not 100% correct but for morons to understand):

                ELF is like: "here's a bunch of libraries to import, here's a bunch of symbols to import"
                DLL is like: "here's a bunch of libraries to import; then within each such library, here's what symbols to import from it"

                There's no such thing as "here's a symbol to import, idk from which library though!" in DLL. It is literally impossible to specify that. Only ELF is brain damaged.

                What the fuck is so hard to understand, are you really that retarded?

                Originally posted by oiaohm View Post
                https://www.zlib.net/manual.html
                Go and read it. Notice the z_streamp imported into inflateinit and inflateend. Go back up the page you will find in that structure.
                alloc_func zalloc; /* used to allocate the internal state */
                free_func zfree; /* used to free the internal state */
                Guess what you are meant to tell those functions what allocate solution to use. This is important because depending on your free you might be able to free an entry multi times. Straight after that you can manually nuke the state.
                Those are FUNCTION POINTERS and I already BOLDED IT before, WHAT MORE DO YOU WANT FROM ME TO STOP SPEWING GARBAGE?!?. Yet here you go again with the same bullshit. Stop wasting my time.

                Do you know what a fucking function pointer is? It's an ADDRESS, not a symbol, and has NOTHING to do with symbols, you can put any address there, EVEN INTERNAL LINKAGE FUNCTIONS YOU FUCKING TWAT which are not exported, not even in static libraries.

                That structure is what you call a "class" in C++, and of course the init/end are the functions for constructing/destructing the internal state objects.

                Nobody sane relies on YOU to "destruct" the object using free, they provide their own opaque destructor, in this case, inflateEnd. This is sane API design, it has nothing to do with Windows.

                Comment


                • Originally posted by Weasel View Post
                  No the thread is about desktop issues, not that it doesn't have a sizable marketshare: it explains why that is so and the factors behind it, not just that it is so, everyone is aware of that fact.

                  It has nothing to do with closed apps but binary compatibility, which is what closed apps require and open apps benefit from.
                  This is exactly the issue. There will never be proper ring-0,1, or 2 level DRM on Linux that game developers would want for anti-piracy and anti-cheating. They also feel that we're too entitled to getting "Free" stuff.

                  The second issue is that Linux is either an unknown, or viewed as that "OS for those weird neckbeard nerds", by most non-technical people. I don't give a fuck because these people would never file a bug report and don't add anything to the community. Windows is an OS designed for them. Its mainstream. It treats them like garbage. Its what they are told to use.

                  Then the rest are not bugs, but feature, which enable Linux to work on and tackle a wide variety of tasks and roles because of this flexibility. there are hundreds of distros, but only 2 or 3 which are serious desktops.

                  In my opinion, there are no Linux Desktops, only Linux Workstations. A Linux Workstation exists for productivity. It exists for doers and builders. For people who maintain Linux servers, Linux embedded devices, Linux Super Computers.

                  Comment


                  • Originally posted by GI_Jack View Post
                    This is exactly the issue. There will never be proper ring-0,1, or 2 level DRM on Linux that game developers would want for anti-piracy and anti-cheating. They also feel that we're too entitled to getting "Free" stuff.
                    Ah, you are most certainly right with the anti-cheating crap, but I was talking in general about desktop, not just gaming... I do agree that Linux will probably never become an attractive target to retarded gaming companies who want invasive anti-cheats, unless they get forced to by laws. That's not really Linux's fault though, but the anti-cheat rootkits.

                    Originally posted by GI_Jack View Post
                    The second issue is that Linux is either an unknown, or viewed as that "OS for those weird neckbeard nerds", by most non-technical people. I don't give a fuck because these people would never file a bug report and don't add anything to the community. Windows is an OS designed for them. Its mainstream. It treats them like garbage. Its what they are told to use.
                    Nah, I'm sure companies like Canonical would love to treat non-technical people "like garbage" too and design mainstream OS "for them".

                    I know it's hip to say stuff like "Linux is for workstations" (which might be true but this is not the thread for it), but the fact is, many tried to bring it to the desktop and failed (so far). It's not that they chose to not be a desktop OS. They just failed.

                    Of course it's easy to just say "we never even tried seriously" when failing but... yeah, right.

                    Comment


                    • Originally posted by Weasel View Post
                      WTF are you even talking about? The DllMain function gets called when you call FreeLibrary or LoadLibrary on the DLL, so that it has a chance to release resources.

                      IT GETS CALLED FROM KERNEL32 SO IT **MUST** BE LOADED proving it even more.
                      Here the fun fact you have no idea.

                      The real DLL loader in windows based off windows nt is in fact in ntdll. FreeLibrary and LoadLibrary are in fact proxies.

                      Yes if you use the real DLL loader in ntdll.dll ie ldrloaddll you don't have to run DllMain. You don't have to have kernel32 loaded.

                      Originally posted by Weasel View Post
                      You do realize even *assuming* kernel32 did not get forcefully loaded as YOU claim, user32 imports kernel32, right...? So since AppInit DLLs are loaded by user32 which requires kernel32 to be loaded first (it imports it), all of your babbling is impossible, logically.
                      You don't need to have gone though user32 to start a process. Instead you can be using NtOpenProcess yes this could be stub using NtOpenProcess.

                      Originally posted by Weasel View Post
                      Forcefully associating HeapAlloc with kernel32 simply ensures that the HeapAlloc you request is loaded from kernel32. Since any other library can also export a HeapAlloc symbol which does something completely different.

                      It is only on ELF where you can override libc's symbols with something rogue, so shut up.
                      No if you are using ntdll.dll directly to the real loader for dlls and processes you can over ride kernel32.dll with what ever you like. Malware in fact exploits this.

                      Originally posted by Weasel View Post
                      ELF is like: "here's a bunch of libraries to import, here's a bunch of symbols to import"
                      DLL is like: "here's a bunch of libraries to import; then within each such library, here's what symbols to import from it"
                      User32 and kernel32 are basically Windows NT libcapsule. Neither of them are the real dynamic loader on any os based off NT. The real dynamic loader under windows nt based OS live in ntdll.dll under 3.11 9x inKernel32.dll leading to a very mistaken belief.
                      • IMAGE_SUBSYSTEM_NATIVE (1) - No subsystem required (device drivers and native system processes).
                      • IMAGE_SUBSYSTEM_WINDOWS_GUI (2) - Windows graphical user interface (GUI) subsystem.
                      • IMAGE_SUBSYSTEM_WINDOWS_CUI (3) - Windows character-mode user interface (CUI) subsystem
                      I have mentioned the Native flag. This is part of the PE format. You set NATIVE flag on a .exe/dll kiss goodbye to preloaded kernel32.dll/user32.dll/AppInit DLL
                      Windows GUI and CUI says I want particular dlls preloaded into my link maps. Native is give me what I have asked for nothing else. So no matter method you use to start a PE tag native you are not picking up extra libraries.

                      Directly use the ntdll loader functions also kiss good by all all the nicely preloaded stuff.

                      So this is fairly much like you dlmopened everything under Linux. Loader in windows not much more friendly than the glibc default loader. Only difference is the Windows loader is hidden behind a set wrapper libraries covering up how evil it is. Once you know this you lose you problem with the libcapsule method.

                      Originally posted by Weasel View Post
                      Nobody sane relies on YOU to "destruct" the object using free, they provide their own opaque destructor, in this case, inflateEnd.
                      No it called legacy code based. Since the code in applications for zlib were done that way early on and still work no one bothers fixing them. But you cannot really go around breaking these past platform promises without people hating you.

                      Not all libraries on posix are sane. You also have the issue with some posix libraries with the create and destructor is a inline in header file. So comes part of your library/program. Even if a dynamic link library developer for posix platforms make function like inflateEnd nothing say that this will be a export from the dynamic link library it can be just a inline in the header files.

                      So posix world you malloc and free needs to be the same everywhere or your programming life can be hell. Linux world .so files are not designed like .dll since its not strange for Linux World .so files headers to contain a stack of inlines.

                      The way people code under windows and the way they code under Unix/Linux is very different.

                      Comment

                      Working...
                      X