Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Ubuntu is losing its shine as years go on.

It once was a Debian that just worked, nowadays is some kind of a trap. As you start getting deeper you start to notice non-standard things that get in the way more than they should, besides being utterly non-standard.

Things i noticed so far:

- auto-update enabled by default. if I boot a vm it's going to be nearly unusable (can't install packages) because it's going to spend the first 30 minutes doing a full upgrade

- netplan -- not sure why that's there

- snaps. for everything. the last straw for me was realizing that gnome-calculator packaged as a snap. it took almost 20 seconds to show the f-ing calculator. every time an app is slow i suspect that's because it's packaged as a snap.

- doing weird stuff with motd. why?

At this point my next reinstall will be a good old Debian.



Snaps also can't be installed from anywhere besides Snapcraft. That's a huge red flag to me.

I initially disliked Flatpak, but I've come around to it recently in light of where Snaps seem to be heading.


Slight correction: you can easily download a Snap from a website and install it like you would do with a Deb package.

It's the repository that's locked; Snap only supports a single repository; the "Snap Store".


While flatpak runs on the traditional repo model where you can add as many repo sources as you want.

I can't see a single thing Snap has going for it when Flatpak is the same idea but better in every single way.


The more i look at snap, the more i dislike it.

The same goes for flatpak too unfortunately.

Currently I feel like AppImage, while kind of a hack, might just be the best solution.


The funny thing is, that NixOS did actually solve the goddamn dependency hell problem in the best possible way and yet there are n different ways that try to do something, but fail. Linux should at least converge on this one actuall good solution.


AppImage is the best, and I wish more developers would use it. At least for desktop/end-user software. Maybe Guix is a better choice for a server, though I don't have much experience with it.


Appimage is basically a linux port of the windows workflow where you download an exe file from random sites and run it. No update mechanism, no discovery, no install/remove mechanisms no sandboxing.

Appimage is super cool for being able to quickly test builds of stuff but for software you actually use its not great.

I have been using Fedora Silverblue for a few months now and using flatpak to install every gui tool and its been excellent. I use a tool called flatseal which lets me tighten or loosen permissions for apps based on what I need which has been awesome. I can just flat out disable networking on apps if I don't need the networked parts.


> Appimage is basically a linux port of the windows workflow where you download an exe file from random sites and run it. No update mechanism, no discovery, no install/remove mechanisms no sandboxing.

Not 100% true. See e.g.

https://github.com/probonopd/go-appimage/blob/master/src/app...

Since the AppImage format is always the same and not just a random .exe it is possible to build tools around them.


I use it on https://mudlet.org and it's amazing. No Linux users are ever issues with them - it's an effectively solved distribution problem.

The one drawback is that you need to use an ancient compiler, but for our purposes that ancient compiler supports C++17 so that is okay for the time being.


It was a huge enough red flag that Mint removed snap store out of the box.

https://linuxmint-user-guide.readthedocs.io/en/latest/snap.h...


   - auto-update enabled by default. if I boot a vm it's going to be nearly unusable (can't install packages) because it's going to spend the first 30 minutes doing a full upgrade
There is something seriously wrong with the Ubuntu auto updater. It literally will run for hours at 100% cpu on a system that hasn't been updated in a few months vs an apt update && apt upgrade that can do the same work in a few minutes. It acts almost like some sort of O(n^x) behavior where x > 2.

I just disabled it and moved on with my life as bugs like these in my experience get ignored forever when you report them.


Netplan on paper is a nice abstraction layer for various network configuration tools.

In reality, it's a pain in the backside which may not yet support a config option you want to use for the chosen backend.

These days my preference is to bypass the unnecessary abstraction and just use raw systemd-networkd instead.


Can you explain to me why netplan is bad?

When it came out in an LTS, I was impressed by being able to declaratively describe networking. And there's even a way to test a configuration with auto rollback.

These are features that I find great in thing like juniper routers.

But when I went online to see what people thought there just was annoyance.

It made no sense to me.


> Can you explain to me why netplan is bad?

I don't see the advantage over networkmanager, honestly. And now there's another thing I have to learn and support, with no real benefit.


I really think that netplan exists because "everyone knows" networkmanager is bad. Ironically, I think it's for the same reason that netplan is now bad; it's a leaky abstraction which doesn't always support the feature you want. I've worked with people who disable nm as a matter of muscle memory on new systems, and I wonder how long it'll be until netplan goes that route (hehe).


Well, unless you used to do bridges with nmcli (and if you did, i'm really impressed), netplan do have some advantages.

And for all the swearing i did when i add to change the packer conf, then the ansible conf, i do think netplan is in fact easier to understand, read and change than brctl/bridge-utils.

I hate snaps though.


Uhm, so far I've used network manager for wired and wireless ethernet, vpns via openvpn and fortinet, and network bonding (lacp etc).

Yeah you have to look the details for the specific kind of configuration, but reading the fine manual is the norm, not the exception.


Would you use NetworkManager on a server?


Most of the enterprise world does, it's the default in RHEL (in 7 for sure, it probably still is in rhel8).

And regarding me personally: yes I would and I do. It's not that bad.


netplan brings "generate" and "apply" and so on but that's about all the usefulness it brought while doing so completely upended the configuration format and supported functionality. It seems like there could have been a less disruptive way to add that functionality, or at least netplan could have been more feature complete when they switched to it.


Ubuntu really is starting to look like canonical wants to do its own version of everything. That's my reading.


I went to Ubuntu years ago for the availability of packages.

Snaps killed it for me. I moved my daily driver(s) on Fedora a few months after 20.04. It turns out, RPMfusion does have all the packages I want.


Snaps pissed me off too, and I vowed to switch to another distro (probably Debian) when this installation stopped working. In particular, it annoys the hell out of me when they pull a bait-and-switch by automatically converting `apt install X` commands to `snap install X` for certain popular packages.

...but this Kubuntu system (my primary workstation) has been rock steady for the past ~5 years with no signs of problems. So as annoyed as I am, I gotta hand it to them for keeping things working smoothly.


I'm really enjoying Pop! OS. It's Ubuntu (and I installed the default ubuntu-desktop over Pop's), but it has its own "store" with .debs and flatpaks, no snaps. It's still possible to accidentally install a snap, but it's also easy to revert that. It's also very nice how effortlessly the graphics drivers and full-disk encryption work.

I haven't tried Debian on desktop, but it is great for servers.


Good christ snaps are horrible. I had been using ubuntu for nearly 14 years, and that was the thing that pushed me back to debian.


When I have a new computer and want to install Linux on it, I reach for Ubuntu out of habit, because I have this vague idea that it will have the drivers that I might need for my screen, keyboard, WiFi, etc. to work. But, because of the issues you raise, I’d much rather install Debian. Is it practical to do so?


I have found it practical to do so. The one note I have seen is you may want the images with non-free firmware if you have devices dependent on that:

https://cdimage.debian.org/images/unofficial/non-free/images...


Thank you. In a few days I'll be installing Linux on a Lenovo mini desktop system, and I'll try it.


You're welcome! Depending on how new it is, you may need to use testing versus stable.


On all my home boxes I run vanilla Debian and it’s great. No fuss. I’ve started to dabble outside my comfort zone with a Fedora box and it’s also pretty great, despite the culture shock.


Part of losing that "shine" is them abandoning Unity and other Ubuntu-specific things. Back when it first got popular one of its selling points was how easy it was to install the proprietary nvidia driver. It always had something a little extra compared to other distros. Now it's using the same stuff as everything else and meanwhile I've ditched nvidia a long time ago and now even Gentoo is as easy to install (for me at least) as Ubuntu was back then.


“ if I boot a vm it's going to be nearly unusable (can't install packages) because it's going to spend the first 30 minutes doing a full upgrade” - wouldn’t be an issue if you install from the newest image. Also if your cloud provider is so crappy that it actually takes 30 minutes to apply a few updates maybe find a new one.


I'm sorry but this is neither on point nor a good advice.

I can't be bothered making a new packer image each time a new ubuntu image is up. And people to use USB keys to make their friend and family try Ubuntu (or you know, as a backup).

Also, because even if your point is wrong, you're kinda right: you can disable autoupdate in the seed file or during install. And also, minimal image are a good idea/good practice and won't ever take 30 minute even if your image is really old.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: