Upgrading what might be the oldest running Linux install

https://www.theregister.com/2022/07/25/upgrading_probably_the_worlds_oldest/

by theandrewbailey • 4 years ago

105 14 4 years ago

theregister.com

hericium• 4 years ago

"chiark’s skip-skip-cross-up-grade"[1] - blog post the article is about

HN discussion[2]

[1] https://diziet.dreamwidth.org/11840.html

[2] https://news.ycombinator.com/item?id=32256026

tcmb• 4 years ago

The Register's article contains some interesting information about the system being upgraded (it's where the Windows PuTTY client is hosted...) as well as about the original blog post's author, that I was not aware of:

Jackson is highly qualified to perform such a complex upgrade: as well as being a former Debian project lead, he also wrote Debian's underlying package-management tool dpkg. Jackson stewarded the release of Debian 2.0, the first multi-architecture version of the distribution, and the first to use libc6

bdg4• 4 years ago

The history of dpkg is really interesting, it has its roots in a a biologist trying to avoid ripping his hair out with dependencies so he wrote "StopAlop" (http://www.verycomputer.com/195_d4343843af185e14_1.htm). A few months after he posted it others took on the task of porting it to a more robust shell script which was eventually re-written into C, and slowly evolving into what we have today.

What's more interesting is that a lot of package managers for programming language package managers use (or used) the fundamental concepts in dpkg. For example, for a long long time Composer (the thing that saved PHP from death) was a re-implementation of some parts of dpkg with a language-specific world view. I don't know for sure about others but I think this is also true for NPM, pip and ruby gems.

Something else that I think about a lot: the industry spends a lot of CPU cycles to compute the suitable dependencies, but there are several alternative ways to solve dependencies. But those alternatives don't generate interest because the StopAlop lineage is so built in to how we work on software it almost goes unnoticed as a natural law of the world like gravity, so there's no prompt to directly challenge it.

formerly_proven• 4 years ago

Something else that I think about a lot: the industry spends a lot of CPU cycles to compute the suitable dependencies, but there are several alternative ways to solve dependencies. But those alternatives don't generate interest because the StopAlop lineage is so built in to how we work on software it almost goes unnoticed as a natural law of the world like gravity, so there's no prompt to directly challenge it.

If I recall correctly, Composer uses a SAT solver to do this, resulting in absurd amounts of CPU and memory time needed to create lockfiles in some situations. Dunno if they still do that.

Macha• 4 years ago

npm's direct ancestor is yinst, a Yahoo-internal package manager: https://manpages.org/npm-faq/7

pxc• 4 years ago

I've done cross-grades on old ARM devices, as Debian gained repos built with more optimizations, and I've done in-place 'upgrades' between different Debian-based distros (e.g., Mint Debian -> Kubuntu).

As long as you have a busybox with a working dpkg in it, it's pretty easy to deal with any dpkg or apt errors you encounter as you see them. If you use these same strategies between Ubuntu releases, you can also 'push through' any brokenness or quirks that the normal wrappers for this process bail and reverse on.

If you run any Debian-based distro, just doing one or two upgrades like this will really liberate you from worrying much about your package manager getting 'broken', and spare you from ever doing clean reinstalld unless you really want to.

Upgrading what might be the oldest running Linux install

Related Stories