The Leading Linux Desktop Platform Issues Of 2018

[oiaohm]

When you write an application, free() does not exist. When you write a library, free() does not exist. You have to import it. Same with malloc.

You don't write the library, and you don't have its source code, so you can't control what the library links against in this example. It links against "libc-foobar-version" with its own malloc/free implementation and data structures.

But you, on the other hand, link to normal libc. So you get totally different malloc and free. The point is that THERE IS NO GLOBAL FREE BECAUSE IT DEPENDS ON WHAT YOU IMPORT. Now shut the fuck up. You don't mandate what everyone should link against.

What you described ignores posix standard.

https://en.wikipedia.org/wiki/C_POSIX_library
libc is define as part of Posix standard. It is allowed to under POSIX that is no other way to allocate memory other than free/malloc/calloc in libc. So implementing your own malloc/free will be sitting on top of the C one.

This part of standard means when you have a 2 link map inside an application or more the libc memory allocations have to be kept the same. This make libcapsule design mandatory or you will break legacy Linux applications. Windows platform rules don't define 1 single malloc/free for applications to use instead define multi-able.

Free exists on posix because it was defined and you are meant to link against the platform libc. Most Linux distributions platform libc is glibc.

When writing application yes you have to import malloc and free. If you application is valid POSIX you have imported malloc and free not written your own and with that imported malloc and free you have a expected set of behaviours include the ability to allocate in 1 library and free in a different one.

Sorry the windows one of you must free inside the dll that allocated does not fly on POSIX. A common runtime is requirement of Posix this has made doing libcapsule a little tricker than what windows did with each dll having it own link-map.

I have no idea what kind of technobabble crap I just read. You have 10 dlls as opposed to 10 ELF .so or what? I don't understand your point at all. And you only have to relocate 10 times in this case, not 20 times, what the FUCK are you talking about. On x86-64 the amount of relocation is insignificant due to RIP-relative addressing enabling efficient position-independent code.

This is what you call being termless idiot.

Relocation Record is term for the entry in the dynamic link map of entry going between two different files be this the executable to a dynamic link libary or dynamic link libary to dynamic link library. RIP/PIE has absolutely nothing to-do with this. The values for the pointers contained in dynamic link maps has to be resolved this comes with overhead RIP/PIE in fact increase this overhead.

10 so files with individual link-map per file run into the same overhead problem as 10 dlls with individual link-map.

So basically you whine that DLL gives you flexibility in having 10 different runtimes than being FORCED to use ONE libc only. Splendid point!

The posix standard says you will have 1 libc. Posix does not define dlmopen. Posix gives you a list of requirements and zero flexibility.

Yes 10 dll gives you the flexibility of 10 different runtimes but what about the case where you only have 1 runtime. You are paying the overhead as if you are using 10.

Also Weasel the rule about always free in the dll that allocated it happens be based around the presume that every dll has it own runtime. Of course this does cause a overhead problem. So X is allocated in A dll/so using C runtime. B dll/so using C runtime is the point where it worked X should be freed obeying your logic you will have to call exported function on A that then calls the C runtime to free X now posix logic B calls the C runtime directly.

dlmopen allows multi link-maps. Multi link-maps means you can have multi runtimes. Rules about cross link-maps containing different libc parts is the same dll that you must free in the right link map. Is there any requirement for malloc/free defines by posix standard to come from libc to be different.


On posix platforms you have to think of libc like the ntdll.dll on windows you don't get a different function no matter the dll that calls ntdll.dll inside your application right. So libc free/malloc under posix is expected to be the same by default.

Most platforms have not been designed like windows where windows expected that each dll will have it own unique runtime.

SUN with AT&T in 1988 designed dlmopen to allow applications to have more than 1 libc version loaded at time this was used in audit tools.

Weasel there is more than 1 way to skin a cat. There is more than 1 way to solve the multi runtime problem. The windows option is blindly create multi link-maps and take the overhead. The SUN/AT&T design is when you need more than 1 runtime you will declare multi link-maps in your code. libcapsule follows the SUN/AT&T design those shims declare create new link map.

By the way Weasel;l the 1 link-map per dll is in fact limiting.

So 10 dlls 10 runtime right is this true for platforms with dlmopen the answer is no it not.

dlmopen support a horrible hair ball.

You have A.so with X, Y, Z runtime options that alter the function of A.so. Using dlmopen to create link-maps it possible for my application to have A.so with all 3 run-times inside my application just with different link maps. Now try doing the same thing under windows without using new WSL at this point you should wake up that the link-map per dll under windows has in fact tied your hands. Why should Linux world be interested in a less flexible solution.

dlmopen allows if you wish a link-map per .so file it allows for a link-map shared between a group of .so files it also allows for a link-map to contain the same .so multi times linking to different dependencies.

Limitation has been lack of software/library to effectively use dlmopen and dlmopen being broken. libcapsule addresses the software problem and has also addressed the broken problem.

[oiaohm]

By the way libcapsule shims allow many things. So lets say you have new GTK and have an application that requires older version. Using libcapsule shim you can safely map the functions from the newer GTK into the shim matching older GTK then only maintained the code for the removed functions.

If you look at wine with the multi direct x helper libraries and multi versions of msvc libc and the like multi libraries shims in fact direct to a single dll.so file.

Lack of a functional shim system has caused enterprise distributions to be designed particular ways. It going to be interesting to what how much changes as different groups work out what shim can do.

Due to limited development people there is a need to reduce the workload to maintain backwards compatibility.

[horizonbrave]

This is a Linux ecosystem feature.
If this "problem" is to be solved, I hope the "winning" desktop is not GNOME... Otherwise that would only pave the way to the "Year of the Possibly Horrible Linux Desktop"...
Here is my proposed solution to the problem (split userspace in 2 parts: a system one and a user one).

I don't see any alternative desktop, Gnome seem the only good looking one out there, polished, minimal, out of the way without 90's style "start menus"

[horizonbrave]

I disagree with him and actually view the "problems" he sees as strengths.

Strengths but at the same time also a BIG waste of resources. Without those the desktop experience still sucks

[oiaohm]

Strengths but at the same time also a BIG waste of resources. Without those the desktop experience still sucks

Its the wrong way to look at the problem.

Trying to get all Linux Distributions to-do exactly the same things is like trying to herd cats its not going to happen. Open source software development by its nature is wasteful. Every person being able to scratch their own itches(issues) means there is always going to be waste.

Now if you cannot herd cats are other other things you can do them? Yes you can collar them. Flatpak and snap are both attempting to using sandboxing to collar the distributions. Libcapsule provides other options of a collar. I could see in time old LTS distributions with their opengl and vulkan parts being from the latest development version hidden behind libcapsule shim.

The userspace syscalls provided by the Linux kernel is very much a shim. So the question should be where is the next level where we should deploy a shim.

Remember the advantage of the shim path is it possible to ship the shims that cover up the differences with your application.

[Yndoendo]

There is a problem with the current state of software deployment pertaining to desktop applications. Why should linux users only be power users? Just because you can does not mean others are able to or have the time to take the extra steps.

I was a Gentoo user for years and jumped to Arch; got tired of continually having to compile applications and maintaining a customized kernel. Arch often has the newest release and a good distro maintined kernel. AUR allows for 3^rd party application installation but I’m starting to get sick of having to compile or repackage software just to have access to non-distro mainlined applications.

Installed Gnu Radio Companion to start learning about wireless processing. Built the functional flow of logic out but could not run the created python application. Turns out wxWidgets installed is 3.0.4 but wxPython for python2 is only built and maintained up to 3.0.2. So my options are: wait for Gnu Radio to use python3, install wxWidgets 3.0.2 and effect all current software that utilizes the bug and security fixes, hack wxPython so it builds against 3.0.4, setup a dual boot system, setup a virtual system with USB pass-through, or do nothing. With my current limited time, I choose learning something else.

Went to install MonoDevelope for some WinForm application maintenance. Originally installed the flatpak version but they no longer support that format and only create packages for Ubuntu, Debian, Raspbin, or CentOS.

Have a number of AppImage and flatpak applications installed. Each have their pros and cons. Having to code and deploy applications for Windows, macOS and Linux, I prefer macOS. It allows for system install or local user, and multiple version retention.

Even rust development also recommends against distro compiler usage. rustup is recommend by the developers and Arch Wiki too, since it allows for multiple compiler versions versus the distro’s only one.

There is a reason I like the GO language. It produces a single binary that allows for CPU architectural portability. Compiling it on a roiling release Arch Linux ARM allows it to run on a point release Raspbin with a simple copy and paste.

For all the WM / DE mud slinging; Gnome is not a platform, nor is Plasma or XFCE or i3 or any other one. Plasma platform components are Qt and KDE libraries, Gnome platform is Gtk3 and GDK, while all others needs common libraries too. And why should a Enlightenment user not be able to pick Nemo as the file manager or Gnome user use Dolphin or Plasma user use Totem?

Even Valve is working on automating and simplifying the deployment of wine based games, since a lot of game developers do not want to get into distro dependence hell. Remember a lot of gamers are your basic or standard users. The only way for Linux to get more AAA games is by increasing the number of desktop users.

What would a standard / basic user do? Run a operating system that can get done what they need to do with least amount of effort.

Wicked problems need wicked solutions.

“We cannot solve the problems we have created with the same thinking we used in creating them.” Albert Einstein.

[oiaohm]

Even Valve is working on automating and simplifying the deployment of wine based games, since a lot of game developers do not want to get into distro dependence hell. Remember a lot of gamers are your basic or standard users. The only way for Linux to get more AAA games is by increasing the number of desktop users.

Please note the simplifying of wine based games is not true. A true wine based game would be rebuild with winegcc. Correct would be wine executed windows games because the game executables are still in windows format not wine PE/ELF hybrid. Valve is using wine like the way dosbox has been used for old games so they can keep on selling old games. Most people would not think that dosbox is a dependency of wine its not really that much of a step to go a little more. Of course wine could allow more not ported games to be run as well.

Those games with lost source code are also a problem on windows with Microsoft dropping dx8 with signs they are planing to drop dx9. So working with those making compatibility shims is about valve keeping on making money.

Valve is also the primary funding party behind libcapsule. Valve problem is a lot more complex. Valve has license to sell many games. Some of those games the source code is lost for good. So wine and libcapsule is not just about a lot of game developers do not want to get into distribution dependence hell there are a lot games where that is not even an option as the source code of the binary application no longer exists. Yet these are old games people still want to play still bring in valve revenue. Some people don't want to play these games with updated game engines they want the old original game engine bugs and all.

“We cannot solve the problems we have created with the same thinking we used in creating them.” Albert Einstein.
This is so true.

Linux mess is caused by the idea that we must have perfect ABI match. Shim over ABI allows imperfect ABI matching appearing to application to be perfect ABI matching.

Valve requirements make them a ideal company to lead the development for distribution neutral deployments. Something that scary is when you get the time it can take to recover the cost of development of a game.
http://vgsales.wikia.com/wiki/Video_game_costs
Some games have to sell of over a decade to recover the cost of production and that is without the games being an absolute flop. Production house has to recover the cost of development of flops out of the profits they make from successful games this explains why a lot of game companies go under and in the liquidation process a lot of times the source code to the game gets lost for good.

AAA game production is worse than a dog eat dog world. AAA game production is something where https://en.wikipedia.org/wiki/Ouroboros Ouroboros is reality. As you are producing you next game its eating the profits of your past ones. If you have too many failures those costs end your company and the liquidation process is normally not good at preserving source code. That reality makes for distribution firms like Valve supporting non repairable binaries is a requirement.

[aksdb]

To quote KDE's Flatpak HOWTO:

Sure, that still requires the administrator to have flatpak itself installed, but that's very different from inherently requiring administrative privileges for each install. (Not to mention that the end goal is to have Flatpak as part of the default system image and it's not as if administrators who would remove Flatpak can't also prevent Appimage's from functioning.)

Good point, I didn't know that. That indeed makes matters a lot better. So yes, in a future when Flatpak is nearly "everywhere", it's indeed good. AppImage still has one nice feature: I can safely stash away applications I want to reuse. If Flatpak repos vanish or get purged, I might lose access to an app I would still like to use (that's also a problem with other package managers .... on the contrast I still have some Windows Installers from 15 years ago ... and also some dmg files for OSX that are no longer available elsewhere).

[oiaohm]

Good point, I didn't know that. That indeed makes matters a lot better. So yes, in a future when Flatpak is nearly "everywhere", it's indeed good. AppImage still has one nice feature: I can safely stash away applications I want to reuse. If Flatpak repos vanish or get purged, I might lose access to an app I would still like to use (that's also a problem with other package managers .... on the contrast I still have some Windows Installers from 15 years ago ... and also some dmg files for OSX that are no longer available elsewhere).

https://www.mankier.com/1/flatpak-create-usb There are ways of backing up flatpaks. So moving applications you want into private repositories that are 100 percent under you control.

Flatpak was designed before flathub existed. So Appimage single file as backup of what you have installed can be replicated with flatpak. If stashing your applications is important features exist in flatpak todo exactly that.

[aksdb]

https://www.mankier.com/1/flatpak-create-usb There are ways of backing up flatpaks. So moving applications you want into private repositories that are 100 percent under you control.

Flatpak was designed before flathub existed. So Appimage single file as backup of what you have installed can be replicated with flatpak. If stashing your applications is important features exist in flatpak todo exactly that.

Ok, I'm sold :-)
Thanks for correcting my not-even-half-knowledge.