Hacker News Reader

Comment by alkonaut | Hacker News Reader

It's a tough time for desktops generally. If the question had been "when will be the year of mass market GUI linux?" then it would have happened already with Android.

The author lists all the reasons traditional desktop linux failed and keeps failing, but the short form of the argument can be summed up like this:

Linus Torvalds, who knows a bit about Linux, also makes his own desktop app (perhaps not as famous as the kernel and git), a scuba log app. He would like to release the damn thing built for Mac, Windows and Linux. But can he? Of course not. He releases it compiled for Windows and Mac, and then as source for Linux.

Linux on the desktop might succeed when Linux has a desktop. As in, at the OS level, a developer can make assumptions about how the clipboard, resolution scaling, sound, notifications, application install/uninstall etc works. Until then, no.

View on HN

The trouble is "Linux" isn't a desktop OS. Ubuntu, Fedora and openSUSE are desktop OSes. They're separate OSes even if they are related.

There is hope however. Modern application containers like Flatpak aim to bridge the differences between Linux OSes by being self contained.

Right. And that’s exactly the problem. Another problem is that ALL those desktop distributions chose application (package) managers that are ill suited to desktop. You don’t want shared libraries for desktop. That might be good for server (central patching, fairly stable environment once set up).

On desktop you need to be able to install and uninstall apps by the dozen every week and never ever worry that your “system” can’t run the app, or that the app will ruin it for some other app. This requires duplicating libs or statically compiling. However package systems tend to dislike packages that include a private copy of 100 libs. That’s broken.

Flatpak is exactly what’s needed. And it needs to grow to encompass APIs on the same level as Windows and OS X (e.g good notification apis, dpi change events for multi monitor across all window managers etc etc). Modern desktop APIs are pretty intricate on win/mac, so Linux needs to catch up. The problem with catching up is that design by committee is never quick to drop old cruft, unite on standards etc. This is why I think Mozilla, Valve, Google etc has a better chance of making the successful Linux desktop, than the OSS community has. Just like the OSS community won’t ever make a AAA game.

macOS and Windows have shared libraries.

Packaging third party libraries with your binary is just going to lead to a race to see which fucks a user first: running out of disk space or that one app with an unpatched TLS library that allows RCE for an attacker.

Exactly. And yet for 99% I’d desktop use I’ll rather buy disks and risk security holes, than suffer shared library hell. I have been screwed by library compatibility hell 100 times for every time I suffered a disk space issue or a vulnerability issue. At the end of the day if it’s a hard requirement that you want to be able to just run binary packages that were created by idiots - then the smartphone app model is the only viable one.

It’s important that components that do have significant attack surface such as TLS are provided and patched by the OS.

The shared libraries of e.g windows come in pretty well defined tiers. Things that the OS provides, various optional runtimes that must or can be shared such as msvcrt and then there is not much else. No app is going to install a “system wide” image decoder or other utility lib (In the past, it was a thing to dump a dll into the OS folder, often overwriting older ones, which is where the term “DLL hell” comes from. Luckily that doesn’t happen these days).

Only developers without Android experience can think there is some kind of desktop victory with Android.

Linux kernel is pretty much hidden from userland, including C and C++ code.

Google can easily replace Linux with any kernel that offers the POSIX subset required by Android. Everything else are just libc, libc++ and Android specific native libraries.

Only OEMs writting Android drivers would notice the difference.

That seems like a feature, not a bug. Can’t see that desktop apps should need kernel features at all (other than what could be provided by any kernel)

If the kernel features are irrelevant for userspace, then being there is a pyrrhic victory.

Having a free (as in speech) desktop OS, with the properties of a good desktop OS would be nice.

Can’t see how it would be bad to have it on top of a replaceable kernel or why it would be good to expose things that would make it harder to do so.

Because the whole point is that is completely irrelevant that Android runs on top of Linux, and as such doesn't make any sense to tout it as "Desktop Linux".

The point of a ”better” desktop linux would be to have a FOSS desktop OS. Linux isn’t important in itself. The Kernel in that OS would without doubt be (more or less) replacable, just like it is in android.

To rephrase the topic to a more relevant form “when will there be a FOSS desktop OS in widespread use?”.

Subsurface does distribute compiled Linux binaries, for a couple of years now:

https://plus.google.com/+LinusTorvalds/posts/WyrATKUnmrS

Thanks, I may be out of date. I heard it in his DebConf14 Rant, so the info is 3 years old.

https://m.youtube.com/watch?v=5PmHRSeA2c8

This is a good point about desktops in general.

If someone with major resources announced a focused effort to enter the desktop OS space right now, I wouldn't put their odds in a good place. Why would an unfocused effort work?

I cringe at the idea of Linux itself containing a desktop, rather than distros adding one, so if that's the solution hopefully it keeps not being its year.

EDIT: clarification

Linux doesn’t need to provide a desktop. All that’s needed initially is an effort to specify a modern desktop api, that implementers then implement. “This is what a window manager and desktop Linux should provide, and these interfaces will be backwards compatible forever”.

Flatpack is an example of such an effort, but it needs to be more ambitious and preferably more “official”.

Freedesktop.org has been doing what you're calling for for a very long time now, and with a lot of success. I remember a time when you couldn't take cut'n'paste across applications for granted... that kind of problem has been 100% eradicated for a long time now, thanks to fd.o. I'd argue that the API and protocol problem has been solved.

Flatpak isn't about APIs. It's about making easy-to-use application bundles.

Flatpak: yes, it's about making that. But to make an app for a distribution where I don't know the environment, you need some kind of common denominator for the environment. So flatpack does some of that, and freedesktop does some more.

The needed outcome is for freedesktop to have an application distrubution story - which is effectively the same as if flatpak had a larged application interoperability idea. The fact that this is two separate efforts highlights the problem - you need everything to be a coherent whole.

A combination of a larger and more modern desktop api compliance effort PLUS an app distribution effort like for example flatpak, would be perfect. E.g. "here is how you build an app for linux desktop v5". You include the right headers linux_desktop_sound.h, linux_desktop_dpi_notifications.h, linux_desktop_dpi_scaling_events.h (etc.). I know in the end an API on top just makes you have N+1 apis - but that's the reason this whole thing needs more dictator/ivory tower. It shouldnt' be be called "freedesktop-flatpack", or "somenewname" it should be called "linux desktop apps v1.0". This is probably the hardest part: getting the politics together. For desktop to succeed you need to have an ivory tower somewhere, in the middle of the bazaar.

Reply on news.ycombinator.com