The Leading Linux Desktop Platform Issues Of 2018

[Guest]

Completely agree with him about 99% of his points but I can see how the typical Phoronix neckbeard might be offended and disagree strongly (with some foaming around the mouth).

[dungeon]

Completely agree with him about 99% of his points but I can see how the typical Phoronix neckbeard might be offended and disagree strongly (with some foaming around the mouth).

I can agree or disagree, but i dunno how this is different than what he talked 12 about 14 years ago about 32 years ago

The ease of the first Mac inspired me: On the Mac in 1986, you could simply copy an application file to your hard disk and it would run. If you wanted it no more, you could simply move the application icon to the trash. In contrast, Linux 2003 required you to become root, type in cryptic commands, and understand what “broken packages” meant. And you never knew what went on “behind the scenes”: what files were installed all over the place on the system.

http://freesoftwaremagazine.com/arti...ter_interview/

He wants this like it was on Mac back in 1986. and so on... so today he still wants to present that old approach as something new

Still, others might don't want to click, but to type something... like on DOS or like on Commodore basic computers

[ssokolow]

I also see a large number of packages in a distributions repository as a strength. Run one update command, be it dnf -y update or apt-get update and everything's updated. Similarly, as good as everything I want installed can be with basically the same command. If I have to go to 50 different websites and check if there is a new version and download a file from each and install that to update then... why not just use Windows?

Not to mention that I trust the Debian maintainers to vet my updates for "tentacles of evil" attacks (term taken from the Debian Free Software Guidelines) like the one that happened to Firefox's Stylish extension much more than I'd trust something like Flathub.

Basically, if it's not from the distro repo or one of my own creations, I prefer to have something that is entirely in the distro repo ensuring that it's sandboxed off from everything but the network. If it doesn't come from the distro repo, my own creations, or GOG.com, I also want it sandboxed off from the network.)

EDIT: For those who don't want to look it up, the term "tentacles of evil" was coined via this DFSG compliance test, as quoted from Wikipedia (emphasis mine):

"The Tentacles of Evil test". Imagine that the author is hired by a large evil corporation and, now in their thrall, attempts to do the worst to the users of the program: to make their lives miserable, to make them stop using the program, to expose them to legal liability, to make the program non-free, to discover their secrets, etc. The same can happen to a corporation bought out by a larger corporation bent on destroying free software in order to maintain its monopoly and extend its evil empire. To be free, the license cannot allow even the author to take away the required freedoms.

[basildazz]

I'm quite happy with it the way it is, different distributions catering for different usage styles, theres even OPENelec built on linux that isn't even a desktop just a media player, how would you standardise the usage of this product.

The only problem I have is that for persistently evolving apps it is just the ticket, but for an application that is built onetime for distribution alone, often times evolution of the platform can exceed the capability of the application to use it and run. For Windows software there is WINE and a GUI wrapper 'playonlinux' allows for the download of any state of wine for emulation (not an emulator) for your Windows product, this would be wonderful in some historical manner in Linux.

[oliw]

Nobody gives a shit about enterprise. Thread title says Linux DESKTOP. D.E.S.K.T.O.P. Platform Issues.

I think we swing in different circles. What I see in enterprise (and yeah, enterprise uses Linux desktops too) is a lot of shared key interests with your average, non-technical users, home-gamers who just want a secure computer that doesn't change so much they have to rethink their workflows every six months because Nautilus lost another dozen features. Maintained, cadence-release packages gives you stability. It cuts costs and waste in very real ways.

I'm not saying distro packages are perfect —they need improvements, sandboxing, permission requests, cap limits, configurable install paths— but the existing package formats aren't going away any time soon so this is stuff we should be adding on to improve our existing workflows and security. Not titting around with yet another "standard" package that doesn't quite get anything right.

And you don't really think packaging has owt to do with market share, do you?

[Weasel]

And you don't really think packaging has owt to do with market share, do you?

Actually, it does, and no I'm not even exaggerating. That's what makes it so dumb. Really for the casual user there's just 2 things that keeps him off Linux: hardware (in)compatibility, and application compatibility, aka "I just want to download and run my favorite app, why is it not available in Linux WTF?"

Package Management and distro packaging and the unstable userland is the reason a lot of devs, not just commercial ones, don't port to Linux, which LEADS TO lack of apps for Linux and why people bitch about their "favorite apps not working" and thus yes it's the most serious issue TODAY because hardware compatibility is quite decent these days.

Of course, changes aren't gonna happen overnight. I don't think anyone said that. Look at a span of 10 years or so.

[Weasel]

Can you prove the existence of namespaces in executable formats? You are the only one who talks about namespaces, so I am not sure.

Sorry, I'm not sure I understand what it is you want me to prove here? Are you talking about DLLs or other formats than ELF? In DLLs it is impossible to have global symbols since to import a symbol, you must first specify the module (library or executable) it is imported from.

So importing "some_function" symbol from libfoo is totally separate from "some_function" symbol from libbar.

If it is true that ELF uses a global namespace, is it possible to work around this problem from ld-linux.so/ld-2.28.so? (the library that does dynamic linking and stuff)

Nope, don't think so, because the fault lies also on the library developers.

ELF has something called "symbol versioning" where you get each symbol prefixed with the module name, e.g. libfoo@some_function -- which actually solves the global namespace clash crap. But unfortunately almost nobody uses it, because library devs are lazy and morons, so it's pointless.

Yes this requires recompilation/relinking...

The fact is, this feature has to be forced, that's why I ask for removal of global symbols and not merely "an alternative" which we have already, but it's pointless cause almost nobody uses it (libc does...)

Most Windows library devs are also morons but at least Microsoft forced them to import symbols by module, by design.

[oiaohm]

You don't have to be careful at all, you just don't have to be a retard to free a pointer with your own library allocated by another library.

There is no need to have this limitation at all with the libcapsule route. So you don't have to export free functions from your library instead use a global free.

Really its retard that you have to export frees the way you do under windows. If the windows loader was designed differently you would not have to.

libcapsule is only needed on Linux due to how ELF is a retarded braindead fucking piece of hot garbage designed format. In fact what libcapsule does is impossible on DLLs unless the app specifically targets libcapsule (which means recompilation). It's not even needed on DLLs.

Clueless wonder. It not impossible on DLLs. What libcapsule is doing to the relocation tables goes back to common ancestor between ELF and PE being Coff.

Here's a better solution: Either use DLLs on Linux (like Wine does), or REMOVE THE FUCKING GLOBAL SYMBOL NAMESPACE from ELF.

Wine uses elf pe hybrids the dll.so format and the exe.so format. Turns out that global symbol namespace is why at times wine can load particular applications faster than windows. Basically if you had a clue how wine worked you would not have said this at all.

PE and ELF formats statically linked only have 1 symbol namespace.

The default ELF loaders the ld.so historically have also only provided 1 symbol namespace this means items like LD_PRELOAD work where the windows equal AppInit_DLL is path to dead locks. Cause the massive multi namespacing windows loader does.

Also what windows loader does results in fragmented memory allocation. You could create something like libcapsule for windows to force all memory allocations in every load dll to be using the 1 run-time so allowing free a pointer from another library always.

The biggest problem with the elf loaders and only 1 functional namespace.

https://docs.oracle.com/cd/E19455-01/806-0627/6j9vhfmos/index.html

Do note the date at the bottom of this 1997 dlmopen exists. dlmopen is a way under elf to request that the so you are opening is placed in its own symbol namespace what is a link-map.

libcapsule is providing all the tooling around dlmopen. The majority of what libcapsule need was fixed up in 2014-02-07 with 2.19 glibc. Before that dlmopen was broken and no one was using it so no one noticed.

The reality is there is no need to have either problem. The windows problem of having to be careful to free pointers with the right library or the Linux problem of conflicting libraries. When SUN designed elf dynamic loading they include dlmopen for calling items like host opengl or application plugins. But the require frameworks around it were not made.

Funny enough wine has a Libcapsule shim equal they are the wine fake dlls shims. So yes scribbling over relocation records happens.

Reality here is libcapsule is really allowing .so files to be used the same way as wine does fake dlls. So no need to remove global symbol namespace or use dll files on Linux.

Once you wake up how old dlmopen is you have to ask the question why is appimage still not functional. Appimage should have been using dlmopen from the start to call out to host parts so avoiding conflicts with application contained parts and if that was the case dlmopen would not have gone unnoticed as broken for almost 10 years.

Elf format design by Sun and AT&T in System V Release 4.0 that announced on October 18, 1988 include dlmopen. So the problem of conflicting run-time parts in elf design was solved before Linux even existed. Issue has been implementation of design.

Dlmopen alone without a framework around has been a nightmare to use and resulted in lack of testing.

Basically we need libcapsule work to make what was designed into the elf format easy to use.

The global symbol name space to multi libraries is not a mistake as this speeds up loading time and reduces memory usage.

Not having easy to usel support for creating multi global symbol name space as the elf design allows has been implementation defect. Part of early dlmopen ideas was the ability for the name spaces to share the same allocation solution.

There is no need to copy exactly what windows did to avoid this problem. Windows is paying a price in higher application memory usage and slower application load times. Currently libcapsule is not as optimised as it could be either.

Libcapsule developer has been surprised how simple it has been over all that is because basic framework is part of elf the problem has been implementation to use that framework has been missing. Yes what is in libcapsule could end up part of glibc and other libc on elf platforms.

Like it or not of the problem traces to one part not being implemented even that it was in the elf format specification from the start.

[Weasel]

There is no need to have this limitation at all with the libcapsule route. So you don't have to export free functions from your library instead use a global free.

Really its retard that you have to export frees the way you do under windows. If the windows loader was designed differently you would not have to.

That's not a limitation and it has nothing to do with windows.

It's absolutely retarded to call a function that YOU IMPORT (free) on data allocated by a library which possibly imports SOMETHING ELSE (because you do not control what standard library it imports, and even the C standard doesn't mandate one implementation of a standard library).

It has nothing to do with Windows, it's about computer design. It's always the idiots who think that MEMORY is the ONLY RESOURCES but no, that's far off, and it SHOULDN'T BE SPECIAL.

Here's the kind of bullshit you promote which is literally the same thing by "mixing" functions:

abc = new Foobar();

// ...

fclose(abc);

I honestly don't know how to make it clearer just how retarded it is. You allocate a resource with the new operator (and the resource happens to be memory) and then destroy it with fclose (which happens to be a file resource), and that's exactly what "global free" does.

There's no such thing as "global free". The standard library is not "global". Standard library is like any other fucking library and it can have 1 million different implementations.

Wine uses elf pe hybrids the dll.so format and the exe.so format. Turns out that global symbol namespace is why at times wine can load particular applications faster than windows. Basically if you had a clue how wine worked you would not have said this at all.

Baseless bullshit as usual.

PE and ELF formats statically linked only have 1 symbol namespace.

Static linking has zero symbols (debug symbols are irrelevant, they won't affect anything at runtime).

The default ELF loaders the ld.so historically have also only provided 1 symbol namespace this means items like LD_PRELOAD work where the windows equal AppInit_DLL is path to dead locks. Cause the massive multi namespacing windows loader does.

Also what windows loader does results in fragmented memory allocation. You could create something like libcapsule for windows to force all memory allocations in every load dll to be using the 1 run-time so allowing free a pointer from another library always.

Yuck. See above how retarded it is.

The reality is there is no need to have either problem. The windows problem of having to be careful to free pointers with the right library or the Linux problem of conflicting libraries.

No, you free a resource with the same library that allocated that resource. There is no global memory allocator or "global free". Stop this. Standard library is not "global".

The global symbol name space to multi libraries is not a mistake as this speeds up loading time and reduces memory usage.

Not having easy to usel support for creating multi global symbol name space as the elf design allows has been implementation defect. Part of early dlmopen ideas was the ability for the name spaces to share the same allocation solution.

There is no need to copy exactly what windows did to avoid this problem. Windows is paying a price in higher application memory usage and slower application load times. Currently libcapsule is not as optimised as it could be either.

Ahem.

Some proofs of this "increased memory usage" and "slower load time" would be nice you know.

Having to search only in a specific module (as with DLL) sounds like it should be faster, to me. I can't argue with claims tho.

[oiaohm]

That's not a limitation and it has nothing to do with windows.

It's absolutely retarded to call a function that YOU IMPORT (free) on data allocated by a library which possibly imports SOMETHING ELSE (because you do not control what standard library it imports, and even the C standard doesn't mandate one implementation of a standard library).

It has nothing to do with Windows, it's about computer design. It's always the idiots who think that MEMORY is the ONLY RESOURCES but no, that's far off, and it SHOULDN'T BE SPECIAL.

Here's the kind of bullshit you promote which is literally the same thing by "mixing" functions:

abc = new Foobar();

fclose(abc);

I honestly don't know how to make it clearer just how retarded it is. You allocate a resource with the new operator (and the resource happens to be memory) and then destroy it with fclose (which happens to be a file resource), and that's exactly what "global free" does.

There's no such thing as "global free". The standard library is not "global". Standard library is like any other fucking library and it can have 1 million different implementations.

There are such things as global free. On Linux platforms you will find most libraries due to being design with posix standard in mind are using a common memory management system.

So you don't have 1 million different implementations. Its not the same as mixing functions. fclose(abc) is to kernel function for a file. Allocation of memory is a libc wrapped kernel function on Linux. Linux is posix based this means you malloc and free should be a application wide solution.

This is not about standard libraries this is about platform standards. Part of Unix/Posix standards are global free parts that should just work. You should be able to malloc in 1 library and free in a different one. Please note you open a file in 1 .so file you close it in another heck it could be closed in a complete different process because it got passed over. Yes due to different runtimes under windows closing files in different dll to where they were open can fail badly as well.

No, you free a resource with the same library that allocated that resource. There is no global memory allocator or "global free". Stop this. Standard library is not "global".

That is not the case under posix operating systems. The kernel provide global allocation posix standard mandates that you should be able to allocated in 1 library and free in another.

Some proofs of this "increased memory usage" and "slower load time" would be nice you know.

Having to search only in a specific module (as with DLL) sounds like it should be faster, to me. I can't argue with claims tho.

Really this is because you fail to think.

Each DLL has it own look up table this sounds like it could be faster. Lets say each dll uses malloc and free from runtime. You have 10 dlls you have just perform relocation 20 times to fill in the link-maps of the dlls. Yet when you have a global link-map that gives you your global symbol namespace the malloc and free relocation would have been performed only once.

The search of the link-map is not that expensive. Costly is relocation calculations. This relocation record cost comes from coff so there is no real difference here between PE and ELF. Difference is implementation.

Windows loader just creates a link-map per dll. So Windows have higher relocation calculation costs because windows is calculating more relocation. Also each duplicate link-map consumes ram.

Please note this is called dynamic linking.

Static linking has zero symbols (debug symbols are irrelevant, they won't affect anything at runtime).

When you make a static binary you make a link map. You have a total of 1 link map for symbols. Link-maps is your limitations when you are linking dynamically or staticly. So static linking does have symbols when its linking those are stripped from final binary.

If you are making applications than can be dynamically linked or static linked as lots of Linux programs are you have to see that static linking you have only 1 global symbol namespace that is static solved. So having 1 global symbol namepace/link-map when dynamically loading for performance also makes sense.

I will say having only 1 functional link-map when dynamic linking has caused problems. Having a link-map for your application code and a different one for host would be great for portable binary. Also having a link-map per plugin would also be great.

Having a link map per dll is over kill it costing cpu time and memory. The usage of link map should be planned because its not a free item.