What he's saying is true, but also i think the app-store type approach that apt-get provides is a major benefit.<p>With windows i have to find some random program, hope its not malware, possibly pay for it, etc. With linux, i have reasonable assurance that packages (from main repos) aren't evil, they are free (as in beer), and i can easily search through and find something for my usecase. I can't really do that in windows.
Worth watching. But if you don’t... [Linux desktop sucks because application writers don’t make binaries that “just work”, pushing the user to always just have to recompile for their system, they try and address this in the kernel by not breaking things, but the distributions to and screw it all up, because breaking is fine so long as it’s “improving”]<p>Tons of contrary points I’m sure, but duh. It’s really nice to be able to run Windows 3.1 code on a Windows Server 2019, the idea is nice, practicality aside.<p>As someone who could run Linux desktop, I see it as the same reason I don’t root an android phone, I do enough tweaking and tinkering in my own code that sometimes I just want tools that immediately work. So I can do my other work. Linux as a system, great, as a desktop, I’ll never set one up for someone I don’t want to hear from all the time.
While I think a lot of the complaints he raises here are still relevant 7 years later, it's interesting that both MacOS and Windows have trended more <i>towards</i> a package management system with their respective app stores--with MacOS especially discouraging downloading or running any apps from outside that ecosystem.<p>Since one can reasonably expect to target "Windows" or "MacOS" the packages in these app stores can be maintained directly by their developers which avoids a lot of the problems that Linus talked about in this video. When you get past the surface layer concept of, "We've sort of overblown this whole package management thing," it's really an argument that the fragmentation of the distributions and shared libraries that can't reasonably be shared.<p>Even using Arch with its rolling release model and making liberal use of the AUR for the most bleeding edge, I've found myself in exactly the situation Linus describes of needing a newer version of a package because the older one flat out doesn't work for me. I <i>can</i> make it work because I'm technical enough to roll my own package if I need to; but, even my wife who is pretty tech-savvy herself wouldn't be willing or able to go down that route.<p>IMO, the fact that the conversion in these comments will be rich with opinion and debate (almost all of which will be informed and intelligent) is the crux of the problem. Too many cooks have built too many kitchens--or some such metaphor. :)
What exactly is the Linux Desktop? There are too many of them.<p>"If you have several watches you cannot tell exact time".
Likewise "several Linux WMs - no Linux Desktop at all".<p>Creating Linux desktop application these days is the same task as to create multiplatform application that will run on Windows, MacOS, Linux/GTK, Linux/KDE, Linux/... (~40 of those more).<p>Conceptually we can use XWindow primitives (if it is used in particular WM),
but that does not help at all when your application need to show "file open" dialog or the like.<p>If someone would ask me to establish Linux Desktop architecture I'll start from defining WindowProc(HWND,MSG,WPARAM,LPARAM,LPRESULT*):BOOL abstraction. Similar to VERY stable WndProc concept of Microsoft Windows. Plus defining stable API that all WMs should implement.<p>Only after that we may see real Linux Desktop - not just WM but bunch of useable applications.
My family and I have used Linux desktops since 2008, when Windows Vista failed to run full screen video with BSOD.<p>There was a learning curve for a few months, but I've never regretted the shift and it has made for significant contributions to my career.<p>YMMV.
The real issue, macos has one distribution, Windows has one distribution, Linux has so many I doubt anyone really keeps track. The issue with Linux is they’re working in fragments instead of as one. The problem is oss not the operating system but the culture it was developed in.
I hear what he is saying, although I haven't run into issues with applications so much. It makes you respect how much trouble Microsoft has gone to through the years.<p>If I've had a problem with desktop Linux, it's been on the driverish edges. Sleep behavior, printers, graphics cards, wifi, multiple monitors. That's also what seems to make OpenBSD a pain.
It sounds like he's saying Linux desktop DEVELOPMENT sucks, not that using Linux desktop sucks.<p>I've been running (mostly ubuntu based) Linux since 2014. The only major problems I've had have been driver issues, userspace applications have largely worked out of the box. Maybe the devs behind everything I use are doing an exceptional job, but I've never noticed an update break a common application due to library changes.
Does appimage not solve this problem? Linus himself released software by appimage the next year (2015).<p><a href="https://en.wikipedia.org/wiki/AppImage" rel="nofollow">https://en.wikipedia.org/wiki/AppImage</a>
Linus is right about being angry when binaries break. I remember google music actually provided a linux upload client... in a later fedora release, it broke. ISTR a library it depended on broke it in some way in the newer version. The issue is there's no Linus in library land and there couldn't be anyway.
I run RHEL 7 desktop, because it's what my vendors support (scientific / engineering desktop applications, simulators). I'm about to get a new Thinkpad, and highly considering running Fedora because packages on it weren't written in 2002 (sarcasm) and use it side by side to my RHEL 7 dekstop, even if some of my work applications won't run on it.<p>Linus is completely correct, though. I think the open source world has gotten way to mixed up with the "free" world. I understand that gcc and some of the HUGE packages are free and open source. They are cost shared by companies and have many people that use them and are maintained well. But other packages with small user bases? His dive example was perfect. Unless someone uses it personally, how can you expect to maintain it unless you pay for it? Or, if the software is paid, how can you expect the company to maintain it for Linux, when their user base is going to be for Mac / Windows?<p>I think Ubuntu LTS is the most sane approach I've seen. You can get relatively new packages in a pretty stable environment. It's not RHEL stable, and Canonical is starting to care less and less about desktop Linux, but it's not too bad. Ubuntu needs Vanilla gnome option by default, though. Their default look is horrendous. I know I know, it's Linux, you can customize it! Why should I have to waste my time?
This has improved a lot. Hardware support has caught up. I'm using a 1 year old laptop with hard to support hybrid graphics (AMD integrated, NVIDIA dedicated). In Fedora, it all worked out of the box. And you get an extra 50% battery life over Windows. In 2010, when I last ran a laptop with hybrid graphics, setting up Bumblebee was a disaster.<p>The only line I had to type into a terminal in Fedora 34 to make it a GUI-usable system was adding the default flathub repo. That fixes the package manager issue. Most people have so much bandwidth and storage coming with their devices, shared libraries make less and less sense anyway.
TLDR;<p>Linux distribution landscape is diverse (complex) and emphasis is on shipping source code and not something (binary) that real people use. For example something is broken so do you tell grandma to download source code and compile it or do you give her a compiled binary that fixes the problem in one click?<p>tldr; tldr;
Not simple (more than few).
This is still the case. Snaps and flatpaks help a bit. But for a lot of stuff, the <i>easiest</i> way is to run the Windows binary under Wine. Including open-source stuff.
it'd be interesting to try to make a hybrid static/dynamic library program. assume you can find the libraries you want on the system, but have a fallback where you go download some Debian packages & install them into your XDG_CACHE_DIR & load libraries from there, when the system (whatever os it is) didn't have it.<p>part of the trick would be making this code significantly smaller than doing a static build.
One of the greatest problems of desktop Linux is the huge
fragmentation. Linux desktop has fewer users than MacOSX and Windows, and lots of distributions, each one with a different packaging methods and incompatible dependencies which may result in work duplication and dependency hell, that can happen if one needs to install an application outside of repository, but it needs a dependency that
overrides an already installed library. Other problems of Linux distributions is that they not allow keeping multiple versions of the same application and multiple versions of the same compiler. The packaging issue is not relevant for people using Linux as server due to Docker, that can package any application alongside the configuration, dynamic linker, GlibC and shared libraries.<p>Another reason why is hard to find binaries for Linux is the lack GlibC backward compatibility. Even a fully statically linked application or packaged with all shared libraries dependencies via LD_LIBRARY_PATH or RPATH may crash if the application was linked against a newer version of GLIBC and is deployed on an Linux distro with an older version of GLIBC. The linking error happens due to the
lack of backward compatibility of the GLibC, which is the main bridge between the user-space and kernel-space on Linux.<p>A possible solution for packaging an application for multiple distribution with minimal work duplication might be: 1 - minimize the number of dependencies; 2 - static link as much as possible; 3 - instead of linking directly against shared libraries such as Curl, Gtk or SSL, load those libraries through dlopen(), dlsym() Unix APIs;
4 - build the application on distro or docker containing an older version of GlibC for dealing with GlibC compatibility problems; 5 - pack all shared libraries dependencies on the same directory as the application setting RPATH to a relative path to the shared libraries dependencies; 6 - embed all files additional non-source files such as
images or text in the binary using resource compilation; 7 - distribute the application in a zipped archive; 8 - use GO (Golang) which is able to static link almost all dependencies and also bypass the GlibC by performing system calls directly. A golang binary will just run everywhere with minimal effort.<p>Linux distributions could make the developers life easier if they copied the MacOSX app bundle idea where applications are distributed as <APPLICATION-NAME>.app directories containing metadata, the executable and all shared libraries dependencies. The advantage of
this approach, is that the application can be installed by just dragging and dropping a folder to the /Applications directory and uninstalled by just deleting a directory. Another benefit is that the user can keep multiple versions of same application and not fear dependency hell or overriding a previously-installed library.
People who haven't tried Linux on desktop for some years might like these distros:<p>Pop OS<p>KDE Neon<p>Linux Mint (Cinnamon version)<p>MX Linux (ahs/Advanced Hardware Support version)
We have Linux on all desktops and laptops. This has been the case for more than 10 years by now. There are still a couple Windows VM's (mainly for checking how some things work on Windows in case need be).
I'm going to vent a bit about this. My perspective is as someone who was a Windows user who moved to Linux 6 years ago after getting fed up with Microsoft.<p>I love the package managers on Linux distros. They are amazing. I feel physical pain whenever I have to jump through hoops to get software up and running outside of a package manager. That being said, I do a lot of hobby work on a Raspberry Pi 4. Not every package is built for arm64. Packages break, have issues with their dependencies, or fail cryptically for me. Building software from source for programs that do run on linux systems can be hit or miss. I understand I chose this with my specific platform of choice, and I have accepted this. But if I can support a solution that will make my life easier I will.<p>It's 2021 and we have Flatpak, Snap, and AppImage, and it's super frustrating. None of these tools solve the problem entirely and they all come with their own sets of drawbacks. That's okay it doesn't have to be perfect. But there are people who hate the entire concept of using these tools and will crap all over them every time they come up. They have valid criticism don't get me wrong, but in my opinion doing something and shipping it is better than doing nothing at all. I would love to see the solution to Snap, Flatpak and AppImage by I've yet to see anything from their biggest proponents. I just can't be bothered anymore wasting my energy listening to people who aren't actively trying to find solutions. If you are reading this and are working on a solution, I appreciate you.<p>So which to choose? I think based on Canonical's past and present behavior Snaps just have too much baggage for most people in the Linux community. This sucks as you have software packaged in Snaps from Microsoft, Nvidia, etc that aren't available as a Flatpak or AppImage.<p>AppImage has the blessing of Linus Torvalds, but if you say that aloud then you will have people say "So what?" as if Linus Torvalds is some just some guy. For better or for worse it means something when he supports things, and he does provide his software as an AppImage so take that for what you will.<p>Then there is Flatpak. If you look at Flatkill.org then the tool is just a pile of lies and security holes. With that being said my money is on either AppImage or Flatpak