Hacker News Reader

Comment by zevv | Hacker News Reader

I have been running Debian on all of my laptop computers since 1999, just copying the whole file system to new hardware when upgrading. I only re-installed it once when switching from 32 to 64 bit.

View on HN

Are you saying that you have been upgrading the same install since 1999 without having to ever reinstall from scratch? I find that to be impressive. Does it take a massive amount of effort?

At least in my experience, it's a matter of separation of data vs os. I can reinstall the os or upgrade as needed. Then copy my data over separately from the OS itself.

The Debian upgrade process is very effortless, and if you're not running anything from an outside repository is just a matter of updating the release codename in your sources.list and doing an `apt update` then `apt dist-upgrade`

Obviously your mileage may vary, but the 8 upgrades of Debian 10 to 11 I did were exactly that for me.

Edit: realized I lied and the Canon driver wasn't ready for Debian 11 so rolled my print server back. You'll have to decide for yourself whether this is a Debian problem or not

I was managing many systems from 2012 to 2019, upgrading from Debian 6 to 10 in the process, and it was always smooth (I was hitting some bugs, but I would hit these with a clean install too).

I have written an article on this, unfortunately in Czech, but you can try Google Translate: https://www-abclinuxu-cz.translate.goog/blog/jenda/2020/12/2...

TL;DR:

- perform apt-get dist-upgrade, apt-get autoremove, apt-get clean

- migrate postgresql database to a new version, if installed

- run `aptitude search "?narrow(?installed,?not(?archive(stable)))"` to find leftover packages from older releases. Install alternatives and remove these old packages.

- once in a while, run

to find libraries that nothing depends on

- when taking over a system from a previous sysadmin, run debsums -c and maybe also a complete audit of all files that are not managed by a package manager (though this has lots of false-positives, so it needs an expert judgement)

# sort -u /var/lib/dpkg/info/*.list > /tmp/allfiles2

# comm -23 /tmp/allfiles /tmp/allfiles2 |less

You need a bit of continuous effort to be thoughtful of how you install software - not letting random make installs scribble over your install.

Yes, this is my main issue with most Linux distros.

Building and installing stuff yourself using the default directory prefix is potentially dangerous. It can turn your installation into a mess, and there's no way to undo it (unless you're using a filesystem that supports snapshots, but even then it is tricky if the problems appear much later).

However, I suspect this issue also exists with macOS.

A modern way to work around this problem is using distro agnostic containerized packages like snaps, flatpaks, nix, guix or homebrew.

I've been using old Ubuntu distros which still get security patches with flatpaks. This gives me a good balance of stability and modern user space software.

As an experiment, I'm keeping a Debian 11 in which I installed flatpak and GNU Guix. I can use very recent GCC versions and still have a very stable system. I still plan to install homebrew on it to watch how the different parts will interact.

How do you install stuff that you compile from source?

Most things compiled from source default to /usr/local , so they may interfere but not break package manager installed packages. It is also possible to use --prefix while configuring, so I can install it without using sudo , but I have to change some environment vars to use it.

I still haven't tried it, but my next step will be to try homebrew.

Homebrew also messes with /usr/local (it stores symlinks there), so this could interfere with the native package manager, I suppose. For example, if you install and then purge a package, it could overwrite symlinks and then remove them (also if the package is a dependency of the package you're interested in).

Also, how would you install Python wheels in a system-wide manner?

> Homebrew also messes with /usr/local (it stores symlinks there), so this could interfere with the native package manager, I suppose. For example, if you install and then purge a package, it could overwrite symlinks and then remove them (also if the package is a dependency of the package you're interested in).

This is the output of "tree /usr/local" on my non-experimental system:

  marco@marco-Inspiron-3421:~$ tree /usr/local/
  /usr/local/
  ├── bin
  ├── etc
  ├── games
  ├── include
  ├── lib
  │   ├── python2.7
  │   │   ├── dist-packages
  │   │   └── site-packages
  │   └── python3.8
  │       └── dist-packages
  ├── man -> share/man
  ├── sbin
  ├── share
  │   ├── ca-certificates
  │   ├── fonts
  │   ├── man
  │   ├── sgml
  │   │   ├── declaration
  │   │   ├── dtd
  │   │   ├── entities
  │   │   ├── misc
  │   │   └── stylesheet
  │   ├── texmf
  │   └── xml
  │       ├── declaration
  │       ├── entities
  │       ├── misc
  │       └── schema
  └── src
  
  29 directories, 0 files

It has a lot of packages installed but, as you can see, the package manager never wrote a file in /usr/local. So I think it is safe to assume things installed to /usr/local will not interfere with the package manager.

> Also, how would you install Python wheels in a system-wide manner?

No sure, but I think it can be done with guix.

Do you also bump the kernel version? I think container managers make use of new kernel security measurements. Some functionality probably won't work(or silently disabled) if the kernel is way too old.

On my stable system, I leave the kernel to the package manager. On my experimental system, I compiled a recent kernel.

Right - good hygiene is key here. Make proper use of /usr/local and /opt to get stuff separated, and sit on your hands before you type when it comes to pip and the like. When I suspect problems I usually run a few `debsums` to make sure my installed files are still the originals from upstream.

Why would it? Software doesn't rot with time (unless it's made to).

My current Intel Mac still has some remnants from running Mac OS X 10.2-10.4 on a G4 equipped Powermac 7300 using XPostFacto.

Every so often I run into very odd plists and remnants of long obsolete programs. I’ve used the migration assistant each time I moved from Mac to Mac. All the PPC only apps went away when Rosetta was removed and the 32bit Carbon apps were similarly discarded. Support files sometimes stick around but the transfer agent is generally pretty tidy.

Time Machine quietly bridges these architectural transition. It's no mean feat to migrate PPC->Intel and then Intel->M1. It silently works and this is the Mac at its best.

What probably helps is that I'm running Debian "unstable", which provides more or less a continuous flow of updates instead of dropping a full release periodically. I just apt-update/apt-upgrade every few weeks, usually resulting in tens or hundreds of packages getting updated. I had to resolve some minor issues with broken dependencies a handful of times, but for the rest it has been pretty much effortless.

One of the nicer things about Linux is that it's just software. It's not trying to implement any corporate ownership over your hardware.

Well they try. Almost all distros have tried/had someone try, over time.

How’s your init process looking?

I find it hard to believe (but give you the benefit of the doubt), as Debian on 1999 (I was using it from 1999 to 2004, professionally on servers and desktops) was a hot mess upgrading, with tons of crap from the package manager.

Same here, on a number of machines. One of them - an Intel SS4200, now retired - I migrated from 32bit to 64bit without a reinstall. This seamless upgrade path was my main reason to move from an RPM-based distribution to Debian somewhere back in 1998, having moved to Redhat from Slackware before than and from SLS to Slackware before that, from nothing to SLS somewhere in 1992.

I am running the same home folder on my M1 Mac as I started with on Red Hat Linux in 1998. The Linux, then FreeBSD, then Mac systems were each continuous upgrades within each OS, too.

So if you got malware the last 20 years your system could still be infected? Not saying that risk outweighs the pros, but that is something I think is nice each fresh install.

You can audit that the installed files match these from the packages (with the debsums program), though I don't know where to easily get the checksum file from an independent trusted source (as the checksums themselves can be tampered with the malware to match).

It is good to run this once a while even for non-security reasons: you can detect hardware problems (notoriously failing SD cards in Raspberry Pis) and mistakes, like installing a custom program to /usr instead of /opt and accidentally overwriting system files.

That only works for files altered in place, not extra .so files, cronjobs, lines injected into global bashrc/profile, that kind of thing.

(Granted, those are unlikely to survive for many years without breaking or otherwise getting caught)

You can scan for extra files too.

Yeah, backdooring configuration/bashrc is a problem, unfortunately, you will probably copy the configuration after the reinstall, thus copying the backdoor too.

That kind of reminds me of this story from 2019:

https://changelog.complete.org/archives/9969-goodbye-to-a-15...

Reply on news.ycombinator.com