Linus Torvalds on why desktop Linux sucks (2014)
youtube.com
youtube.com
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.
Not knowing what it was, I had to spend some time reading about chocolatey.
I know it must be some 3rd generation pun or something but it really put me off going any further. Names are important.
2 of them are essentially community run, and could theoretically at any time be taken over by a hostile (or even just an incompetant) entity and be used to distribute malware. Not that this couldn't happen through an official channel, but it's certainly far less likely.
Since the software distribution is not even, I currently have to check choco, scoop and winget for updates. It's slow and irritating, and if I need to uninstall or check a package, I need to figure out which tool I installed it with.
The software that does crossover between package managers can cause compatability issues. Just today I accidentally broke Rider since I had the .NET Core runtime installed through choco, but the .NET Core SDK installed through scoop.
I get they're trying to finally fix this through WinGet, but I can't help feel it's too little, too late.
yum, apt, snap, flatpack, probably more?
Yeah, thankfully it doesn't happen on GNU/Linux.
By contrast on Windows, it usually means finding some GUI-based utility on some sketchy website filled with ads, and maybe a fake download button. Probably it's freemium, so during the task maybe I have to dodge several calls to action to upgrade to the paid version. And then a week later, maybe I check the task manager, and find out it's gone and set itself to run in the background at startup, doing god knows what, without asking.
It's just one of the ways that Windows feels less like it's my computer.
https://chocolatey.org/ https://brew.sh/2019/02/02/homebrew-2.0.0/
Also in general I would say windows is not lacking for software registries. Or software.
A seemingly minor update might cause a huge cascade of dependency updates which causes common Linux distributions to tend to one of these two extreme solutions: Either fix all packages in place and freeze their version numbers or just "give up" and update everything all the time. Both solutions feel like compromises to me.
Other end-user OSes don't act like this. On Android/iOS/macOS/Windows, I can have the latest 3rd party software without having to deal with intrusive updates to the OS infrastructure all the time. The BSDs handle this better, and maybe something like Ubuntu LTS + Nix on top of it might be a way around this.
That's not really true. The .NET runtime isn't redistributable, and so has to be installed on the host OS, which usually works but not always (and pre-Windows 10, newer versions of .NET required a bunch of KBs, which meant that Windows Update was actually working and able to install those, which fairly frequently broke on Windows 7 due to the lack of Service Packs). Nowadays this is less of a problem, due to improved .NET compatibility and .NET 4.x coming pre-installed on Windows 10. Which honestly is great - you can compile and run .NET 4.x programs on any Windows 10 machine. Granted, it's some relatively outdated version by now, but it is still very nice to have a "proper" programming language out of the box, and also the ability to compile to small .exe's.
Similarly, MSVC runtimes (except the installers are redistributable, but you are still in the situation of "have to globally install it").
The old one “.NET Framework” is an OS component but has enough compat that you can always upgrade it.
The newer one (net5+) is typically fully bundled with each app so no sharing.
MSVC also went this way - you bundle them rather than take a dependency on a system wide runtime. These two (.NET and c++ runtimes) were basically the last shared libs on windows, and it’s now basically obsolete tech (.NET 4.X) or no-longer-recommended deployment method (Msvc).
[0] https://arstechnica.com/gadgets/2021/03/blue-screen-of-the-d...
[1] https://arstechnica.com/gadgets/2018/10/microsoft-suspends-d...
Fallacy.
https://blogs.sap.com/2020/06/26/attacks-on-open-source-supp...
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.
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.
Now yeah that's not true for people who will want to plug in different printers all the time, and install Microsoft Office specifically, etc. Surprisingly I think it's actually the people with a medium amount of technical knowledge that have the most trouble adapting to Linux.
But even as someone who virtually never uses anything but Linux, I don't really get the constant drive to have this "year of the Linux desktop". It works fine for me and I love it. I make my smug comment when Windows and OS X users have problems but I'm not in a rush to help them with their problems or give them new ones. If you're bothered enough by the mainstream options to switch, you can learn a few new things. If not, I don't see the problem.
Edit: and I think Linus focuses too much on Debian here. Even in 2014, Ubuntu was already a very easy to use and out-of-the-box distro. Even Fedora was pretty good. My distribution doesn't package Zoom, but if I go to their website and click install I get the right binary and the experience is comparably easy to Microsoft Windows installers. If you're on a fringe distro, you almost certainly love the power that comes with (and requires) building everything from source regularly. So again, I don't see the problem. If you want to be included in Debian, using Debian's shared libraries doesn't seem like an unreasonable policy. It's quite easy to ship an application that is easy to install and upgrade independently. Google Chrome is another app that does it super well. More people would do it if there was demand, but there isn't, and I don't think that's just an app packaging problem at all.
Interestingly, that's exactly the reason I continue to use Linux. Depends on what you're doing, but for the boring work I do, I never have to tinker. Install and use. Once in a while do a boring update.
My work laptop. My wife's PC. Our plex/jellyfin media server.
My sister's pc and my elderly parents PC are also ubuntu.
I have found my support time for all of them dramatically went down after I got them off windows.
Windows slowing down over time. I longer happens, lengthening the age of hardware and pushing off OS reinstalls, which can at times cost money based on the OEM model.
I can still suck more juice out of a machine with a RAM and add drive upgrade, again, without paying for a reinstall, and saving them lots of money in the process.
LTS/stable distros just work, out of the box, for most people.
Its people like me who have an incessant need to tweak everything that will mess up a Linux desktop.
Do you have any source for this? I know a few people who use Linux (or used it in the past, including myself), and number of complaints is definitely a lot higher than from the people on macOS/Windows.
The only real difficulties I've had is someone else buying them a scanner/printer combo and manually having to get drivers from the manufacturer's site and install them creating a problem when the driver packages depend on libraries not available in the repos any longer. But for me, it takesa bout 20 min of googling around to find the solution.
And other than that problem, I rarely if ever, have to support them for anything.
Half the time when i do, it's because they got banned from a website and didn't understand it, or they were having internet problems and it was unrelated to the OS.
My mother doesn't "like" Linux, but she can't articulate why. She's been wanting to "upgrade" my dad's computer for years as this sneaky way of getting away from Linux. But the reality is, as old as my Dad is - the XFCE desktop environment is more familiar to him, coming from Windows XP/7, than Windows 8.1-10 is.
It's also pretty helpful, frankly, that when something - other than updates - requires root access, he just backs away and doesn't mess with things. Same for my sibling.
This, in itself, has prevented a lot of problems IMHO. People just click "yes" and escalate their privs in Windows without giving a second through about it.
Can you? I was under the impression 64bit windows dropped support for 16bit windows.
You can also run the same version of a newest app on Windows 7 and Windows 10. At least, you could back when 7 was still supported, and you probably still can, but I didn't check.
Try installing a package targeting Ubuntu 21.04 on Ubuntu 20.04 LTS? :) (Replace Ubuntu with a distro of your choince in the previous sentence.)
For all its flaws -- and it has many -- Windows is a platform while a Linux distro is a ball of tightly-coupled packages.
>> I just want tools that immediately work.
Totally agree with you here.
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.
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 can 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.
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. :)
>> needing a newer version of a package because the older one flat out doesn't work for me
The reverse situation is also a problem. For me personally, even a bigger problem.
Imagine, you're happy with a supported Ubuntu LTS version and don't want to upgrade to a non-LTS version. If there's a new version of this one package you would really like to use that targets a newer version of Ubuntu, you're out of luck, basically.
For example, maybe KDevelop replaced its home-grown C++ parsing engine with libclang. It's a huge change, you'd really like to give it a shot. Well, the only option is to upgrade to a newer version of Ubuntu.
Yes, there may be a PPA that has the new KDevelop targeting your LTS version. But there's an equal chance such a PPA doesn't exist. Or it has pretty much the whole set of KDE libs as its dependencies; those will not only pollute your system but also can mess up your KDE installation. Also an anonymous person made the PPA and you decide to trust them at your own risk. And when you're finally ready to upgrade, you'll have to re-add PPAs manually. Etc, etc, etc.
Snap solves both problems rather well. And in contrast to flatpak, there're official builds of VSCode and JetBrainds IDEs in the snap store. Maybe other software too -- didn't really look it up.
One problem with snap is forced updates, of course. Ubuntu developers really need to add an option to disable them.
I honestly don't know enough about Snap or Flatpak to really comment on them and their advantages and disadvantages. I've always shied away from them because I can't shake Xzibit in my head, "Yo dawg, I heard you like package managers so we put a package manager in your package manager!"
"If you have several watches you cannot tell exact time". Likewise "several Linux WMs - no Linux Desktop at all".
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).
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.
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.
Only after that we may see real Linux Desktop - not just WM but bunch of useable applications.
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.
YMMV.
Linux was a million times more stable and much more pleasant to use as a programmer (no SDKs to download with complex installation instructions). It also had a package manager which made installs/reinstalls a breeze. You could actually write a bash script to redo your setup automatically, wow! Never looked back.
I recently installed Windows 8 on an older computer I was setting up for my mom (she didn't want Linux, understandably). It was my first time using Windows in two years or so. Windows Update was broken out of the box. It wouldn't run. You had to manually download a patch to get it to work. I don't really understand why desktop Linux gets so much hate when commercial software is this bad.
I did do some research before I bought my printer and found a brother that connects to wifi and works flawlessly with both Mac and Linux. I find you can also make your life much easier as a Linux user by choosing popular distributions. It's always easy to Google specific fixes for Ubuntu.
Same experience with an old Nikon Super CoolScan negative scanner I recently bought used. It came with a Firewire PCI card. I installed the card, plugged in the scanner and it just worked.
No wonder you ran into issues if you installed it and tried getting it "updated" recently.
https://docs.microsoft.com/en-us/lifecycle/faq/windows#windo...
There is a bug in the Windows Update client on Windows 8.1, and it can't update itself.
Defeats the purpose. That’s how it is.
Then just buy two stick of fast RAM and install them yourself. It often doesn't void your warranty (but make sure to check the warranty of your specific laptop, obviously).
Same applies to SSD, actually.
Didn’t look if there was an option without Windows preinstalled since it was for my wife.
Added bonus: lots of ports, onboard HDMI, onboard ethernet
If you need something now probably not a huge help, but if you’re not in a rush might be worth keeping an eye on.
Much cheaper than Apple. I use an Apple 2015 MBP for a client's requirements. It screws up my muscle memory. The OS is ok I suppose but it's no Linux.
Instead, it is not only the distributions, the whole desktop stacks keep being re-invented way more that what Apple or Microsoft have done thus far.
Then there are the whole set of GNOME and KDE forks from those not happy with those reboots.
Not a surprise that only ChromeOS and Android have managed to have stuck as desktop/mobile variants of Linux based OSes.
So those are the only "desktop" Linux that I ended up caring about.
Since that is too much effort, you just get Electron apps instead.
Maybe the way to sort this is to create Linux groups around certain topics like graphics or music production and then the people with the specific skills can contribute to multiple applications at the same time (at least their design work). This way, if one product dies, their work lives on in other products.
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.
This blew me away when I first tried it and then digging deeper realized it's b/c Apple was the maintainer of the CUPS library. Kudos to Apple for that integration!
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.
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?
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?
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.
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?
tldr; tldr; Not simple (more than few).
part of the trick would be making this code significantly smaller than doing a static build.
...just, well, not quite enough that I want to spend time learning how to use it. :/
When I first investigated it like a decade ago, one majorly offputting aspect about it is that I didn't see it as offering the capability to install multiple copies of things. I greatly prefer systems where i can blue-green deploy services locally, or otherwise have special purpose instances, and Nix, at the time, didn't seem to have much interest in that. I believe things have changed a lot in that regard, or perhaps my couple hours spent as an utter neophyte poking around for answers didn't surface the clues.
I would say that, these days, I am far less interested in configuring a system. I am far less interested in the desktop. To me, my time is 100% not worth investing in these goals. I am trying to focus on working with & orchestrating a fleet of machines, in a coordinated fashion. I believe free-software folks should all be re-investing, re-focusing similarly, in running & operating personal/manorial/federalized "cloud" systems. I happen to agree with a lot of the philosophy of Kubernetes- a desired state management system for resources, and controller/operators that autonomically enact & maintain that state- and invest my time & work trying to make it an useful fabric for my & hopefully my friends digital homes.
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.
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.
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.
Pop OS
KDE Neon
Linux Mint (Cinnamon version)
MX Linux (ahs/Advanced Hardware Support version)
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.
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.
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.
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.
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