Linux Sucks 2020 [video] | Hacker News Reader

Linux Sucks 2020 [video]

youtube.com

31 pointstosh63 comments

Previous discussion: https://news.ycombinator.com/item?id=23346567

I watched this a couple weeks ago and it just seems to have so little information density - like this guy talks and talks and talks and the actual content is like 15 minutes of this.

Agree, I had to switch off the video, it was all talk and no content. I mean he’d got to “cover Linux on desktop only” and “search interest for Linux is declining since 2004” and that was 50% through the video. He should consider a career in politics being able to use this many words to say nothing...

Same. I liked the previous iterations, however.

Yep, that!

Maybe you have some fun with BSD-Lore (Kirk McKusick):

https://www.youtube.com/watch?v=DEEr6dT-4uQ

Or Solaris/illumos (Bryan M. Cantrill):

https://www.youtube.com/watch?v=-zRN7XLCRhc

The Illumos talk is fantastic. I especially enjoy his take on Oracle, 36:30 through 39:00.

The lawn mower ;)

If you use the icons on YT scroll bar at the bottom to spot when the slide changes, you can get through to the useful content in less than 5 mn.

Yeah, but TBH this is true about most of these conference talks: they are just mediocre attempts into stand-up comedy.

Agree. The guy needs to get a room with himself, get over it, and come back with something to say. Linux also isn't for desk tops by and large.

I'll say it has some wins - it's become a much better development platform than MacOS for example since it's closer to what you deploy to. And you can run Chrome, Zoom, Slack more or less natively and things work.

I've used an Ubuntu desktop at work for a few years and it's a nice environment.

I have found it especially worrying that IT giants increasingly encroach OSS instead of developing their own solutions. Devices remain closed while using 95% OSS code (yes, Android, the other 5% are hardware vendor firmware). It's not exclusively their fault, as Lunduke correctly points out. If the Linux Foundation is selling seats at the board of directors instead of granting them for outstanding support, well then Linux is the sucker here.

I struggle to understand how a TiVo-ized device running a mixture of GPL2 and proprietary code isn't a license violation. The code is distributed to the end user as a single uninspectable blob, i.e. the firmware image. Yes, "under the hood", there are separate binaries - but this is purely an accounting fiction that holds no relevance for the user. Is any combination of GPL and non-free code allowed, so long as it emulates a Unix OS at some level?

Always assume an organization is controlled by a cabal of its enemies. The managerial elite will cater to their own personal interests, not those of idealists who give away stuff for free.

Reasons start ~ 30 min mark.

Linux backward compatibility really sucks. I still don't understand why fedora binaries can't run that easily on debian.

They all package different versions of the shared libs...

Why are shared libs so unstable? I thought the point of library code was that it was stable and reusable... maybe all these libraries are just too big and people should be including the source inside their apps instead?

I don't think any package manager does that. That would definitely be useful. Compile and ship binaries down to libc and use binaries on any GNU / Linux System.

I don't see why as long as you output an ELF file an App can't run. Maybe AppImage does that.

glibc has really good backward compatibility. But, yeah, few other libraries even bother, let alone make a serious attempt at this. One of the major exceptions is libvirt, which promised 100% backward compatibility from day 1. Here's a great overview (2011) of how they accomplish that: https://www.berrange.com/posts/2011/01/13/versioning-in-the-...

Note that it wasn't until GCC 10 (2020) that you could implement ELF symbol versioning without using an ugly inline asm hack in your function definition. From the GCC 10 release notes at https://gcc.gnu.org/gcc-10/changes.html:

> The symver attribute can be used to bind symbols to specific version nodes on ELF platforms. This is preferred to using inline assembly with GNU as symver directive because the latter is not compatible with link-time optimizations.

In combination with confusion around the differences between file suffix versioning, soname versioning, and symbol versioning, it's not surprising few developers even attempt to get this right. OTOH, most ABI breakages are because of dumb mistakes early on or gratuitous changes to the API. If you commit to API stability from the beginning, then ABI stability can and will come more naturally, at least for C code. Versioning of any sort becomes less complicated and even less important.[1] C++ is different because of how heavily header-defined templates are used these days.

[1] In other words, if you think API and ABI stability is principally a question of versioning, such as semantic versioning, you're doing it wrong. Commit to 100% backward compatibility at the API level and the answers to most of your design dilemmas become obvious. With the reduced cognitive burden, minding ABI compatibility becomes easier.

> glibc has really good backward compatibility.

That has really not been my experience.

I've consistently hit problem with older software not running because it detected an incompatible version of GLIBC.

Not running or not compiling?

I've often had issues with compiling, either because of unwarranted assumptions in the third-party projects or because glibc made changes to their absurdly complex naming and feature gating hacks in their header files.

But glibc uses symbol versioning so even if the prototype of function foo changes, older software built against version X.Y should still link to fooX.Y at runtime. I don't follow glibc closely enough to know how many times they've accidentally broken things, though. I'm sure it's happened.

More complex runtime behaviors, like with the DNS resolver, are definitely common, but usually it's debatable whether glibc is fairly blameworthy.

Well, it's backward compatibility, not forward one, so you can't compile on Arch Linux and run on Red Hat 4. But you can other way round.

Because they are two separate operating systems.

What they are not Gnu/Linux?

Man i did not knew that.....

The Linux Kernel and syscall interface is the same. They even use the same userspace libraries.

I got that huge bundle of games the other day, many of which have native Linux binaries. Binaries that probably worked fine in lots of distributions when they were released.

Tried three games so far -- Cook, Serve, Delicious 2 (2017), Nuclear Throne (2013) and uh, another one (201x): all of them refused to start, lacking one shared library or another.

I got CSD2 to start by copying .so files around and using LD_LIBRARY_PATH but it still did not work properly. Whatever. Bizarrely, it may be easier to get the respective Windows binaries to start in Wine. But I'm really past "getting things to work", there's enough stuff out there that doesn't require those kind of summoning rituals.

Is it a disadvantage of the bazaar model ? In a cathedral so to speak old things are valued. In a bazaar things are sold based on trends. I see this a lot with open source software, where things are not made with the mindset of making things last a long time.

It's a fun application of the metaphor. But I can still apt install nethack, a thing that was made in 1987. Or apt install lynx, a text mode browser first released in 1992. Or apt install midnight-commander, a Norton Commander[1] clone first released in 1994. All of these still receive updates, so I guess they don't qualify as old things per se, but that's the point: as long as there is still a use for them, they keep getting updated.

If CSD2 or Nuclear Throne had been released as open source software, chances are somebody would have updated their dependencies and they'd run fine. Heck, I'm a developer, I could probably have fixed it myself. But they're proprietary, and have gotten stale, and are a pain to get working. So I guess it's more of an incompatibility between the two models than an attribute of the bazaar.

[1] an old thing that's valued in the Cathedral, if at all, then only as a curiosity

That's true. Well to stretch the metaphor ;) some shops in the bazaars become boutiques to differentiate from other competitors. Boutiques price their uniqueness and that's certainly true of things like vim which is certainly an old software.

A lot of Linux ports are by Windows developers who don't seem to understand that they need to statically link basically everything for semi-reliable compatibility.

Steam kinda got around this by providing a standard base of libraries Linux games could link against that would be the same on every distro, but even there some developers STILL assume that everyone has the same libraries as their Ubuntu system.

Huh? Running against a different set of shared libraries?

- it has nothing to do with "backward" compatibility

- it has nothing to do with Linux. If you change shared libraries with incompatible versions software will break on windows and bsd as well

It's time to remind people again that "Linux" isn't one OS. At best it's kernel source that you get to compile for different architectures. There are distributions ("distros") that package up different sets of kernel, kernel parameters, modules, libraries, utilities, config and glue-scripts, though none of them actually claim backwards or cross-binary compatibility, unless for their own (ie. within major RHELS versions).

It could be nice to not have to worry about all that compatibility and even some upgrade-issues that inevitably ensue. Though the costs can quickly outweigh the benefits, ie. as in the awfulness of "snap" and similar.

Windows do have compatibility and emulation layers, though some older software may still have some issues, it often works. Security-wise it's a good idea to keep patches and upgrades fresh.

That has everything to do with backwards compatibility. You have one piece of software made for an old linux target that does not run anymore on modern Linux. Heck, most of the Feral games don't run on my Linux because they rely on shared libs that my system does not have, and those aren't even old!

And it's only Linux that has that problem in that dimension. Windows just kept everything around. Other systems don't evolve as much as Linux has, and they do not have the distribution differences that kill compatibility on Linux.

AppImage is great and solves that problem. It should be used more.

You don't understand the definition of backward compatibility.

There are examples of binaries written against a UNIX kernel from 30 years ago that run just fine.

If you start adding dependencies on libraries you are choosing to have one of these problems:

- use dynamic libraries and refuse to cooperate with maintainers and things will break, rightfully so

- use dynamic libraries and the OS keep them around forever and it will become a security dumpster fire over time (and also will never scale down to embedded systems and phones)

- use dynamic libraries and ship them in a tarball and it will become a security dumpster fire over time

- use static libraries and it will become a security dumpster fire over time, plus it's even more difficult to tell what libraries are used

- use dynamic libraries and ship them with docker or appimage or similar and it will become a security dumpster fire over time, plus you have unnecessary complexity

- use dynamic libraries and package your stuff properly. Target LTS releases. Most good distributions will guarantee 5 years of stability of all the dependencies without version changes. Plus you get free backported security fixes and free testing.

> And it's only Linux that has that problem in that dimension

Not at all.

> AppImage is great and solves that problem. It should be used more.

Not at all.

At least Linux in 2020 sucks a bit less than other operating systems.

Sounds like the decision between democrats and republicans ;)

Super happy finally to see someone call out backward compatibility (around 31:20)

Linux is terrible on this axis, way worse than Windows.

EDIT: and statically linking your app doesn't cut it.

First, it's barely possible to do that with "modern" glibc.

Second, glibc itself breaks old apps.

That would, make sense? Microsoft has valued backwards compatibility way more than most would consider reasonable.

Yes right, but you know, i thinks Microsoft should just cleanup the OS (no backward compatibility) and provide free vm's from Dos2/3/5 to Windows7

In that way MS do not have to care anymore for older software and security problems.

EDIT: Why the down-vote? A lighter OS would make a lot of sense.

glibc is not what I would use for statically linking

musl works just fine for that

We are not there yet. Musl works great for new projects sure, people should definitely default to it instead of glibc. But a lot of existing software doesn't just work with it, sometimes requiring way too much work and expertise to get there. I completely gave up trying to use it on arm for example, or rather on anything non-amd64, and on amd64 most software had to be patched to even compile with musl.

> Linux is terrible on this axis, way worse than Windows.

Maybe GNU/Linux, but I can run binaries cross-compiled with GCC 10 on Arch Linux on some weird MIPS PoS terminal that's running Linux 2.6.30 without issues, as long as I don't use then non-existent syscalls, so I'm quite happy how Linux kernel handles backwards compatibility.

The Linux Kernel holds backwards compatibility to a very high regards. It's userspace that throws all this out of the window.

I was once afraid of uploading my Linux box, coming from Windows and fearing that any update would break my system. So I had a pretty old Linux system that at some point couldn't work properly (e.g. Firefox was so old that it didn't work on a lot of websites).

But then for some reason I started to keep in sync with my distro. The update is painless, reasonably quick, and safe. Usually I only have to fix the outdated python version of my virtualenvs, and to this day I never had to rollback. I have a laptop from 2009 that runs the latests distros without problems. But it cannot run W10 properly, let alone do any work.

My point is that Linux is beyond Windows in terms of "upgradeability". Giving the limited resources, why go after Microsoft level of backward compatibility, when any machine can run on the latest distro and libraries? On the other hand, why would anyone keep a XP system around if, acording to the video, a W10 would run their programs so easily? Something doesn't add up.

I've run into the problem a few times, trying to run an old version of a software for research purposes. But for daily usage, this misses the concept of open source.

Most decades old software is still maintained, rebuild and packaged by every distribution. You can't easily run a 30 years old program, but you can run its latest version, for free.

Linux sucks up your time, yes. But once it's setup, it's unparalleled, if you can stand minor GUI annoyances.

However, the set of people willing to invest that time to reach that stage of setup that I'm aware of, is currently only me. The other professional linux users in my circle are dual booters, hobbyists, or use it through ssh off a Mac/PC.

There is no money in Desktop Linux.

However there is money in running Linux for infrastructure.

Because of this Server linux is great.

The exception is Android but it does a lot of things on its own.

Unless that changes it's not going to be good on the desktop.

Whats the state of Linux on the desktop in 2020? What distribution do you recommend for a normal person to use?

Ubuntu - you have a wide choice of desktops - kde, gnome, etc.

I use Debian myself, but you may want to stick with Ubuntu if you're unsure about it (Ubuntu has more up-to-date versions of things and if you run into trouble, you'll have more support). Just one thing though, if you're wondering which version, go with an "LTS" (Long Term Support) version. While you should be upgrading your distro when you can, if you choose not to the LTS versions keep their packages available for much longer, so you won't be left high and dry. The latest version (Ubuntu 20.04 LTS) is an LTS version, so you should be good to go :)

> Whats the state of Linux on the desktop in 2020?

Pretty decent for anyone who can tolerate default Gnome and has the right hardware. So, no, still not ready to be a drop-in Windows replacement for casual users.

> What distribution do you recommend for a normal person to use?

What's normal? Normal HN reader? Probably Debian-nonfree, which has all the good parts of Ubuntu and almost none of the bad. Soccer mom pinterest poster though? Windows or Mac.

IMHO, Linux on the desktop is still for those with an above-average interest in computers. Hardware support is getting pretty damn good and software support is great, provided you know about the FOSS options. However, you're also pretty likely to run into some kind of snag that you will either have to just tolerate, or fix yourself by gradually learning how to poke about in the terminal.

Openness leads to diversity which inevitably makes standardization harder. Thing is, I prefer that to the ever-increasing user disempowerment in Windows and MacOS.

> Soccer mom pinterest poster though? Windows or Mac.

Why? If she is going to use the browser almost exclusively, she wouldn't even notice what OS she is using.

This has been my experience after I installed Fedora on my folks' laptops. Pretty much the only support they've required is the occasional major version upgrade I do for them when I visit. Regular patches get autoinstalled.

They'll use Wi-Fi or USB tethering with their phones for internet browsing and my dad will occasionally connect the laptop to the TV set to watch some videos, and it all just works.

Because it's far more likely she'll run into some kind of problem with hardware or software incompatibility. And why does her computer make such a noise when she's watching Youtube and Netflix? And why did her touchpad suddenly stop behaving like it used to after a system upgrade?

There are problems with Windows and Mac for casual users too, but it'd be sugarcoating things to say that Linux isn't far more likely to spuriously act up.

I've given quite a few debian laptops to different normal/ computer illiterate users. There are snags, but not more than on windows.

The people who have trouble are the power users. None of the more advanced tricks work anymore, everything is different and weird, and they dont want to relearn from scratch.

Ubuntu, because it's the most common choice, so has the most coverage/support by other people and tools.

If I'm routinely going off-road, I want to stick to relatively known trails. I'll save scaling mountains for my holiday.

Mint with Mate window manager

Mint for sure. I will be setting my grandma up with Mint soon, it's that good.

I vote for openSUSE tumbleweed, with gnome (NOT Kde) and the SLES desktop design.

Try Fedora. It comes with vanilla GNOME by default, and also has variants (they call them "spins") with KDE Plasma, XFCE, LXQT, MATE, Cinnamon, LXDE and even SOAS Desktop. Most software have packages for Fedora, so for a normal person it should "just work".

So KDE have a distro which they don't call a distro.

Essentially it's ubuntu 18.04 but KDE packages are from the KDE team.

https://neon.kde.org/

Mint XCFE

https://blog.linuxmint.com/?p=3834

Isn't this a repost of a discussion from a few days ago?

Wouldn't be so bad if the talk and the discussion here provided any value...

Reply on news.ycombinator.com