Comment by gambiting | Hacker News Reader

Comment by gambiting | Hacker News Reader

Parent Full thread

So my personal anecdote also involves mint - I've set one up for someone years ago(probably around 2013-2014) and you're right, it had no issues. However, when I came over to visit last year I wanted to do some maintenance, so "apt-get update" and "apt-get upgrade" would be the start. Nope, turns out that the update servers for that version of Mint have been switched off long time ago and none of the links resolve anymore. Upgrading the apt server list just resulted in hundreds of errors when actually trying to upgrade the system. At this point I stopped, worried that I'm just going to break everything.

After that, I had a realization - yes, the system ran for 4 years without any maintenance, but it also received no updates and no patches whatsoever during that time, because linux does not do that by default(or at least Mint didn't). And then the only issues my windows-using family have is 90% of the time due to....windows updates. Things are not where they used to be, some application changed so it's now different, they had something open and the computer restarted itself....the usual. And while that is a problem....at least their machines are always patched and up to date. That Mint installation was running in the same state that it was in the day I set it up, and after just few years it couldn't even be updated any more(to my best effort). That's pretty bad too.

This was what turned me off from Linux Mint for my own use. The catch-22 of you need to upgrade to a supported version, but the servers / packages you would need in order to do the upgrade were turned off in the meantime. To be fair, Linux Mint states that a complete reinstall is the recommended way, but since I do development, it's a pain to have to locate and reinstall from scratch all the packages I need.

Also I think Ubuntu suffers the same problem, if you wait long enough. I'm pretty sure I have an Ubuntu install that I waited too long to upgrade.

It is enough to make me serious consider switching to FreeBSD, except I don't think the 3D (game engine) library I want to use is supported.

it's a pain to have to locate and reinstall from scratch all the packages I need.

    dpkg --get-selections | cut -f1 > ~/installed_pkgs.log
    cat installed_pkgs.log | xargs sudo apt install

Except it doesn't work that way as some package name have changed and the command fails due to some package not existing anymore.

It give something to start with but still requires human intervention from someone who knows how to navigate in this mess.

I actually remember running into this issue a lot when building Docker images. Generally you want your docker image to be reproducible so you'd want to lock versions of your dependencies. But when doing this with apt-get install, a lot of the time I find that when a new version of a package is released, the old one gets removed and becomes no longer accessible, so locking versions actually ends up resulting in _more_ build flakiness than just using the latest of whatever package available at build-time, which is obviously not ideal.

Deleting older versions of packages that people may still be relying on seems like a very obvious no-go in a dependency management system. Any idea why this happens regardless? Is it just a matter of costs? Or is there more nuance to it that I'm missing?

The entire software industry has shifted to a stance of not caring when updates break user workflow, experience, functionality and habits. For basically any modern piece of software, whether/when to take each update, rather than being a no-brainer, is a very difficult decision: it is impossible for the end user to separate security/functionality fixes from workflow/functionality-breaking behaviour changes. Everything, across the board, universally, suffers from this: web browsers (few plugins survive browser updates), office software (ui rearranged every time), operating systems (packages and entire applications just vanish)...

Visible behaviour and functionality is changed or removed without user involvement, choice or recourse, turning every update into a game of Russian Roulette. Even LTS builds don't mean no breakage of behaviours users rely on.

From the developer's POV maintaining security/bugfix-only forks of every feature branch rapidly becomes intractable as a project gains complexity / matures. Meanwhile, for startups, "move fast and break things" is the creed. So as we demand more from our software overall, this situation can only get worse, not better.

The temptation for modern users to say "you know what? it's MY bloody computer, not yours; my problems are actually more important to me than whatever you think you're solving" and unplug from the update streams is overwhelming.

Yep. I think I'll literally stop taking Android upgrades because of this. Just few years ago I'd get really excited every time new version of firmware was released for my phone, but now I loathe it - every single damn time the interface changes and you can't do anything about it. Like now I have taken the upgrade to Android Pie for my OnePlus 5T, and....the clock moved to the left now. Ok, google for a solution - nope, can't move it back to the right. Someone somewhere decided that this is "better" so the customer has to accept it. Like you said, I'm getting really fed up with this - is it my phone, or not????

Isn't this what semantic versioning tried to address?

But when doing this with apt-get install, a lot of the time I find that when a new version of a package is released, the old one gets removed and becomes no longer accessible, so locking versions actually ends up resulting in _more_ build flakiness than just using the latest of whatever package available at build-time, which is obviously not ideal.

I would maintain a local apt repository for that situation.

It gets worse when dependencies have changed and now you've installed a library that's incompatible with the dependencies of an app you need and everything grinds to a halt.

Yeah, I've found that enough things change between installs that it's really tough to automate the process. Instead I keep a document that lists all the steps I need to set up my dev machine from scratch (with a data backup), and each time I go through the process I update the document. That makes it much less taxing than trying to figure out and remember everything without a guide, but is flexible enough to handle the inevitable differences from one time to the next.

If you're provisioning machines on a regular basis it's a different story, but if it's your own personal machine that you're reinstalling maybe every couple years this seems like the most straightforward approach.

Also: Use LVM and snapshot before updating to save yourself a lot of headaches.

I went one step farther and built an Ansible role for my workstation and try to install everything via that role. I don’t always, but it sure makes reloads and new machines easier to deal with. I have since split it into a couple roles for full desktop vs somewhere I just ssh into but have enough access to install things to suit me.

When package names change, or don't exist any more, it requires human intervention even when the rest of the update process is automatic. This is the difference between `apt-get upgrade` and `apt-get dist-upgrade`. All you're really doing by putting off the update in that case is compressing all the little bits of human intervention you'd have been doing during every update, into one big push.

`dpkg --get-selections` also lists explicitly deinstalled packages, so you'll want to grep the list first.

Tell that to your grandmother over the phone and see how much of a pain it is :)

Story-time:

If she's like mine she's going to tell you everything is fine and when you visit her in a few months you'll see it isn't working.

I once helped my grandma, on the phone, navigate through a VCR to record a star trek episode. Everything was going well but I came home to an empty VHS.

"I told you it was fine so you wouldn't worry."

I miss my grandma more than that episode of star trek.

I'm just jealous you had a grandma who watched Star Trek!

Talk your grandmother through anything GUI related over the phone and compare. Spend half an hour trying to help her figure out which button she should press only to find out at step 3 she opened facebook instead of the start menu, and that she actually has been pressing buttons randomly for 15 minutes while producing assorted nonspecific vocalizations of agreement while doing literally none of the things you've asked.

Or even get the legendary confusion of them never having turned the machine on in the first place.

Generally, after years of experience doing exactly this, I've found it is a lot easier to dictate a literal sequence of characters over the phone than coordinate a complex visual action with only confused verbal feedback.

Of course, with terminal stuff, you have even further options in, say, sending an email with an attached bash file for them to download and click, or if this continues, set up a script for them (and ad an icon for it in their start menu) that ssh's them into a handy aws or digital ocean instance so you can then ssh into their machine from the comfort of your own home and do it yourself.

This isn't a great example (or maybe it is considering how non-trivial the operation is), but running stuff from the command line can often be great for tech support. There is a reason support normally asks people to open things from the run dialog instead of asking them to go through the start menu.

This might be a bit too much to expect grandma to perfectly type, but "sudo apt-get update" and "sudo apt-get upgrade" to update her system is certainly easier then trying to describe what to click on a graphical UI.

If they're running Linux, I can ssh in and do it myself. :)

There's also dpkg --set-selections.

Update Ubuntu eol by switching the sources to the archive servers: https://help.ubuntu.com/community/EOLUpgrades

> I don't think the 3D (game engine) library I want to use is supported

Which one? It's entirely possible that it is (or that it's not 'supported', but you could easily compile it there anyway).

Arch Linux is based on a rolling update, so my understanding is that you shouldn't have to jump to FreeBSD (nice as it is in some ways) to avoid a release-based upgrade.

I've only been using it for a little while on a couple systems, but seems nice enough. (Mint or regular Debian for years otherwise.)

You might have had that problem in 2013, since Mint editions were based on the latest Ubuntu release. But since May 2014, all releases of Mint are based instead on Ubuntu LTS release. This means they get support for five years, rather than 9 months. For example Mint 17 (May 2014) has support and updates that will only cease this April. The latest release, 19.1, is supported for 10 years, until 2028.

That's pretty much true of everything Linux related. It has or will get better. The state of WiFi on Linux around 2009 was horrid. It would break with every update. It got better.

I've been using Linux for almost 2 decades and I've abandoned numerous projects over the years because the community was so unhelpful. The most recent was an Asterisk box for a home VoIP server back around 2012, before that it was a MythTV box in 2008.

The main problem is that until it gets better it ends up alienating a lot of people because the standard support from the community is "did you RTFM?"

Similar story, also grandmother's computer.

I ditched ubuntu in the deepest hole I could find because every 6 months was a nightmare, and I replaced it with linux mint which seemed to actually work.

Then I had to deal with such system upgrade and this was a real pain, so instead I replaced linux mint with linux mint debian edition and things went well for a while.

Then came the system upgrade time again, it was not as painful as with regular mint but it was still a pain to manage.

My grandma managed to deal with her everyday use of the computer but there is no way she could manage the mint system upgrade part by herself. So the computer lived for a while with only the non system upgrade until I switched her to manjaro which allows her to have a roling release and deal with system upgrades herself.

This right here is why I switched to Debian. Got tired of downstream forks breaking the upgrade process, which hasn't been an issue since switching a few years back.

The Gnome software center makes it easy to find and install apps too, reminds me of click n run from Linspire.

It's not very often you see Click-N-Run mentioned. Early versions had an easter egg if you queued apps to install whose first letters spelled ClicknRun, then pressed Ctrl-Alt-Shift-C.

CNR was years ahead of any of these app stores, really wish it had continued on rather than others having to build APT clients that still don't work quite as well.

Careful　with Manjaro you are close to bleeding edge packages, and updates may break things. Not Manjaro but on Arch I lost bluetooth after an update last week - I had to downgrade packages for a day to fix it. You don't want this to happen to normal users.

Reply on news.ycombinator.com