6 ms·

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 o

by zevv 5y ago

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.

skohan 5y ago
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.
- vmception 5y ago
  Well they try. Almost all distros have tried/had someone try, over time.
- felixgallo 5y ago
  How’s your init process looking?
copperx 5y ago
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?
- Moto7451 5y ago
  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.
  - ridiculous_fish 5y ago
    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.
- zevv 5y ago
  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.
- PenguinCoder 5y ago
  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.
- doubled112 5y ago
  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
- Jenda_ 5y ago
  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/28/462560?_x_tr_sl=auto&_x_tr_tl=en&_x_tr_hl=cs&_x_tr_pto=nui 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 for p in `dpkg -l | grep ^ii | cut -d " " -f 3 | grep -E "^lib"`; do echo "if [ \`apt-get -s purge $p | grep -E \"^(Purg|Inst|Conf)\" | wc -l\` -eq 1 ]; then echo $p; fi" done | parallel 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) # locate * | grep -vE "^/(home|tmp|mnt|boot|opt|root|srv|usr/local|var/cache|var/lib|var/log|var/tmp|var/mail|var/www)/" | sort -u > /tmp/allfiles # sort -u /var/lib/dpkg/info/*.list > /tmp/allfiles2 # comm -23 /tmp/allfiles /tmp/allfiles2 |less
- kzrdude 5y ago
  You need a bit of continuous effort to be thoughtful of how you install software - not letting random make installs scribble over your install.
  - amelius 5y ago
    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.
    - marcodiego 5y ago
      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.
      - amelius 5y ago
        How do you install stuff that you compile from source?
        marcodiego 5y ago
        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.
- seba_dos1 5y ago
  Why would it? Software doesn't rot with time (unless it's made to).
zulln 5y ago
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.
- Jenda_ 5y ago
  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.
  - yjftsjthsd-h 5y ago
    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)
    - Jenda_ 5y ago
      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.
hagbard_c 5y ago
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.
Crontab 5y ago
That kind of reminds me of this story from 2019: https://changelog.complete.org/archives/9969-goodbye-to-a-15-year-old-debian-server https://changelog.complete.org/archives/9969-goodbye-to-a-15...
coldtea 5y ago
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.
incanus77 5y ago
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.

by zevv 5y ago

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.

skohan 5y ago

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.

vmception 5y ago
Well they try. Almost all distros have tried/had someone try, over time.
felixgallo 5y ago
How’s your init process looking?

copperx 5y ago

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?

Moto7451 5y ago
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.
- ridiculous_fish 5y ago
  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.
zevv 5y ago
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.
PenguinCoder 5y ago
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.
doubled112 5y ago
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
Jenda_ 5y ago
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/28/462560?_x_tr_sl=auto&_x_tr_tl=en&_x_tr_hl=cs&_x_tr_pto=nui 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 for p in `dpkg -l | grep ^ii | cut -d " " -f 3 | grep -E "^lib"`; do echo "if [ \`apt-get -s purge $p | grep -E \"^(Purg|Inst|Conf)\" | wc -l\` -eq 1 ]; then echo $p; fi" done | parallel 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) # locate * | grep -vE "^/(home|tmp|mnt|boot|opt|root|srv|usr/local|var/cache|var/lib|var/log|var/tmp|var/mail|var/www)/" | sort -u > /tmp/allfiles # sort -u /var/lib/dpkg/info/*.list > /tmp/allfiles2 # comm -23 /tmp/allfiles /tmp/allfiles2 |less
kzrdude 5y ago
You need a bit of continuous effort to be thoughtful of how you install software - not letting random make installs scribble over your install.
- amelius 5y ago
  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.
  - marcodiego 5y ago
    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.
    - amelius 5y ago
      How do you install stuff that you compile from source?
      - marcodiego 5y ago
        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.
seba_dos1 5y ago
Why would it? Software doesn't rot with time (unless it's made to).

zulln 5y ago

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.

Jenda_ 5y ago
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.
- yjftsjthsd-h 5y ago
  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)
  - Jenda_ 5y ago
    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.

hagbard_c 5y ago

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.

Crontab 5y ago

That kind of reminds me of this story from 2019: https://changelog.complete.org/archives/9969-goodbye-to-a-15-year-old-debian-server https://changelog.complete.org/archives/9969-goodbye-to-a-15...

coldtea 5y ago

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.

incanus77 5y ago

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.