The Leading Linux Desktop Platform Issues Of 2018

[brrrrttttt]

- Hundreds of distributions causing further fragmenting of the already small (compared to macOS and Windows) user-base as well as "tens" of desktops.

This is an important strength which lead to such wide adoption of Linux.

- Linux distributions focusing more on getting their own packages for everything rather than making a platform where it's easy for third-party binaries to run on.

This is the greatest strength of Linux.

- Linux user-space often breaking and the various library versioning challenges. There's also the different library paths and problems with that across distributions.

This has not been a big problem in practice at all. The only notable one that comes to mind currently is openssl, and it's easily worked around by the distros providing both packages. The second part only comes if you try to circumvent distro-packaging, and I don't want your software if that's the case.

[Luke_Wolf]

lolwut? I mean really? All this really is at the end of the day is a badly concealed attempt to justify AppImage's existence. That's all. None of the aforementioned issues really are except for the userspace issue.

There's one big issue... ONE that has been preventing Linux adoption for the past 2 decades: OEMs. Ultimately what really is gatekeeping users from using Linux has never really been the technical problems. It's that there isn't hardware readily available for which it is pre-installed that they can purchase from their local electronics store. Every other excuse is a load of garbage. Why? Installing your own OS on a computer is a niche enthusiast thing. It will never not be, and OEMs aren't going to start supporting Linux just because it's super awesome and great. If you build it, no they won't come.

We can sit here masturbating over "Oh this technical issue is preventing adoption, and so is this one" all day, but let's be real here:
Was Windows 98 better than Linux at the time? No not really.
Was Windows XP better than Linux at the time? Fuck no. XP was awful. Especially before SP3. Good luck if you wanted sound in your dos games.
Was Windows 7 better than Linux at the time? Arguable.
Is Windows 10 better than Linux? Arguable.

No matter how much we polish Linux into being an ivory tower, it will only succeed in the desktop space once it has mainstream exposure through the OEMs, how do you convince the OEM's to do that? The real answer is money. Canonical, Red Hat, or SUSE putting in the money to set up contracts with companies like Dell and Best Buy.

[tildearrow]

The leading linux desktop platform issues of 2018. are the same as in year 2004.

So move on, there is no issues - if you want install it, if you don't want then don't Really there is nothing to do there, other than maybe to push people to use it

If there is an issue and hasn't been fixed in years it does not mean it is no longer an issue

Pushing people to use Linux will result into them returning to Windows/macOS after they find out there is a lack of big-name software Of course unless they succeed at convincing big-name brands to release their software to Linux as a result of growing marketshare This is happening by the way

He, he, if click it does not work then just push it - maybe it will work that way. Otherwise find your brain somewhere and type in something

I don't understand the "type in something" sentence

While Linux as Linux of course nope, that just pushes software but not hardware

System76 Purism etc

The problem is that they are niches <- I really meant to type this smiley

(yeah, smileys aren't better replacements to punctuation haha)

[oiaohm]

I keep hearing on here how good flatpak is, yet I've never heard of anyone actually using it,

https://community.kde.org/Guidelines_and_HOWTOs/Flatpak

This is that you really have not looked that far. KDE was using Appimage and has fairly much swapped to flatpak. Flatpak builder and Flatpak bundling tools are quite decent.

nor seen any tools like linuxdeployqt[1] to make it easy for me to package. It makes AppImage much more attractive to me as a developer. What gives?

[1] https://github.com/probonopd/linuxdeployqt

Really have you worked with linuxdepolyqt that much. KDE developers has and has ceased using linuxdeployqt for good reasons. Mind you those reasons could change in future.

https://media.ccc.de/v/ASG2018-173-libcapsule

You really need to watch this video. The same problem comes up over and over again. Your qt application will be using libstdc++-v3 or libc++ and host opengl drivers will be built depending on a different version and without libcapsule technology the complete application explodes for that user. Yes this is why flatpak runtime bundles opengl drivers.

Flatpak runtime solution gets around the clashing c++ runtime problem by sandboxing. libcapsule get around the clashing c++ runtime problem by allowing the opengl drivers to have a independent library dependencies to your core application by using dlmopen to create a new dependency tree.

So linuxdepolyqt to be a functional item needs libcapsule. Majority of your appimage problems are not solved just by fixing the soname problem.

You need to decide how you will prevent/control conflicting runtime.

Flatpak prevents conflicting runtime problem by sandbox this does come with shipping size issues.
libcapsule is control conflicting runtime.

Appimage has been yell at distributions/library makers demand that they set imported/exported functions in stone... Basically this cannot happen result is Appimage solutions failing to deliver on the promises over and over again.

Application particular shims can set imported/exported functions in stone from the point of view of the application while allowing the host to side to still change things.

Yes libcapsule shims can deal with all kinds of evil including distributions renaming libraries all the problems the appimage developer talked about can be managed by shims.

Appimage + libcapsule could at long last give an Appimage files that match the promise.

Linux standard base and appimage have both made the same basic mistake with the idea that you can set imported and exported functions in stone. Windows compatibility layer has shims.

Windows and OS X has seperation between the runtime c/c++ libraries a system library uses and the runtime c/c++ libraries your application uses. This is a key feature without it you have to follow the flatpak/snap path if you want sanity.

The separation libcapsule shim provide is a critical missing feature until it ready if you want dependable deployment on multi distributions flatpak/OCI(OCI Image Format) is kind of calling to you.

[Spooktra]

How does anyone know just how prevalent Linux is on the desktop? You can make an educated guess about Windows by looking at how many Windows licenses MS has sold, with Mac you can make an educated guess by how many Macs Apple sells but with Linux it's nearly impossible. It's estimated that about 12 million Chrome Books were sold in 2018, that's at least 12 million users of a Linux based OS, Canonical estimates that there are about 20 million computers that run Ubuntu on a daily basis, God only knows how many Debian, Fedora, users there are, people keep saying when is Linux going to make it on the desktop, I say it already has made it on the desktop.

[brrrrttttt]

https://community.kde.org/Guidelines_and_HOWTOs/Flatpak

This is that you really have not looked that far. KDE was using Appimage and has fairly much swapped to flatpak. Flatpak builder and Flatpak bundling tools are quite decent.



Really have you worked with linuxdepolyqt that much. KDE developers has and has ceased using linuxdeployqt for good reasons. Mind you those reasons could change in future.

https://media.ccc.de/v/ASG2018-173-libcapsule

You really need to watch this video. The same problem comes up over and over again. Your qt application will be using libstdc++-v3 or libc++ and host opengl drivers will be built depending on a different version and without libcapsule technology the complete application explodes for that user. Yes this is why flatpak runtime bundles opengl drivers.

Flatpak runtime solution gets around the clashing c++ runtime problem by sandboxing. libcapsule get around the clashing c++ runtime problem by allowing the opengl drivers to have a independent library dependencies to your core application by using dlmopen to create a new dependency tree.

So linuxdepolyqt to be a functional item needs libcapsule. Majority of your appimage problems are not solved just by fixing the soname problem.

You need to decide how you will prevent/control conflicting runtime.

Flatpak prevents conflicting runtime problem by sandbox this does come with shipping size issues.
libcapsule is control conflicting runtime.

Appimage has been yell at distributions/library makers demand that they set imported/exported functions in stone... Basically this cannot happen result is Appimage solutions failing to deliver on the promises over and over again.

Application particular shims can set imported/exported functions in stone from the point of view of the application while allowing the host to side to still change things.

Yes libcapsule shims can deal with all kinds of evil including distributions renaming libraries all the problems the appimage developer talked about can be managed by shims.

Appimage + libcapsule could at long last give an Appimage files that match the promise.

Linux standard base and appimage have both made the same basic mistake with the idea that you can set imported and exported functions in stone. Windows compatibility layer has shims.

Windows and OS X has seperation between the runtime c/c++ libraries a system library uses and the runtime c/c++ libraries your application uses. This is a key feature without it you have to follow the flatpak/snap path if you want sanity.

The separation libcapsule shim provide is a critical missing feature until it ready if you want dependable deployment on multi distributions flatpak/OCI(OCI Image Format) is kind of calling to you.

Thanks for all the info! I now have some testing to do.

[srakitnican]

I would say companies can already target a Linux platform, that is RHEL and its derivatives like CentOS, Oracle and Scientific. If they want their software to work 7+ years that is the way to go.

[aksdb]

I think its rich in irony for a guy that developed the shitty Appimage complains about fragmentation when he won't give up Appumage and work on Flatpak. Flatpak is the future. It's already won that horse race with Snap a distant second.

They don't compete.
If I'm on a machine where I don't have administrative permissions, I have no way of using flatpak or snap. I can, however, simply download an AppImage and run it. IMHO that's exactly what OSX does right in regards to application handling.

[DMJC]

Sadly this article doesn't address the giant elephant in the room: GTK C++ development is horrible. There is no way to auto-connect callbacks (Signal Handlers) to class member functions (Methods) automatically using glade. So in a large project, you have to write thousands of lines of boilerplate code to do simple gui development. This hampers attempts at writing complex GUI Applications. The alternatives are to use C, and have to manage god awful C style strings, and memory a lot closer, which IS harder and leads to more errors. Or learn QT's bastardisation of the C++ language, or learn GNUstep and Objective-C, which is an unstable programming environment and completely alien to most programmers. Programming on GTK/QT/GNUstep is still awful in 2018, and the developers are making no moves to address these problems. Sure there are great apps written by great developers on the Linux Desktop, but the lack of easy to use APIs has severely restricted the complexity and type of software that gets written.

[agge]

That is exactly the problem with Windows. Every application needs to be managed separately, and every application implements it's own gimped upgrade mechanism which annoys me every time I run it.

The end-user doesn't care, as long as it's painless to go through it's good. And once the developer/s of the app setup their standard way of updating in such a way, it's not even a hassle for them either.