Live data from Hacker News

Using the same Arch Linux installation for a decade

meribold.org

221–230 of 422 posts

Re: Using the same Arch Linux installation for a decade

#221
post #78

I'm the same but with Gentoo, which is another rolling distribution. I've had it installed for over 12 years on multiple servers without any issues.

My preferred distro journey went: Mandrake -> Gentoo -> Debian -> Gentoo -> NixOS I rage-quit Gentoo the first time (2002ish?) for Debian when stable portage got a broken version of gcc, making it very hard to recover. The second Gentoo was by far the longest, maybe 2003 through 2018? I'm 4 years into NixOS now and very happy with it. I actually run into issues with switching to new release channels almost as often a…

Windows -> Solaris -> Windows -> Gentoo -> Arch -> NixOS

I feel much more satisfaction pouring hours into NixOS over doing the same on Gentoo and Arch. The hours on nix are in a source file I can carry around. The hours on Gentoo and Arch I'm doomed to forget and have to repeat.

I do miss the AUR though. I haven't been able to package a rust program that has a build with a transitive dependency that expects internet access (https://github.com/foundry-rs/foundry). Something something sandbox, crate2nix. But a frivolous install of a little binary that isn't packaged is not necessarily an easy endeavour.

Overall I'm very happy. Nix unstable feels equivalent to Arch more or less. You can pull in master with flakes easily enough too.

Re: Using the same Arch Linux installation for a decade

#222

I always reinstall from scratch although I could just Debian "dist upgrade". My thinking is this: if, ten years ago, I somehow missed a security patch or some 0-day owned my machine before it was patched, then I'd potentially have been copying / dd'ing / rsync'ing a rootkit for ten years. By installing from scratch at every new stable (or unstable) release, I get rid of a lot of potential security issues. Now as an a…

If you have a rootkit that you're concerned about copying around, that can somehow persist through pretty much everything on the system being upgraded at some point or another... you should probably also be worried about the various vectors that the rootkit could use to persist across OS reloads.

It doesn't really need to be well hidden if you're not actively looking. A shell script and a crontab entry / bashrc exec / init system entry is very low tech.

Pair that with a slightly higher (but still low overall) tech LD_PRELOAD libc shim so it hides itself and you got something just stealthy enough that you wouldn't find it if you don't look for it.

Remember, the easiest privilege escalation is aliasing sudo and patience.

Re: Using the same Arch Linux installation for a decade

#223

Earlier quoted context omitted.

The glibc upgrade which was painful (and essentially required recompiling everything) was much further back than 10 years. I think I was running LFS at the time, but recall it was painful for all distros. I don't think there was a glibc upgrade that was disruptive since then. There was the introduction of multi arch on Debian some years back which caused a bit of disruption (I was running Debian unstable at the time…

> The glibc upgrade which was painful (and essentially required recompiling everything) was much further back than 10 years. Ah. I'm old. Somehow traumatic glibc upgrades were not how I expected to find out.

Glibc upgrades are how you become old.

Re: Using the same Arch Linux installation for a decade

#224

I always reinstall from scratch although I could just Debian "dist upgrade". My thinking is this: if, ten years ago, I somehow missed a security patch or some 0-day owned my machine before it was patched, then I'd potentially have been copying / dd'ing / rsync'ing a rootkit for ten years. By installing from scratch at every new stable (or unstable) release, I get rid of a lot of potential security issues. Now as an a…

I reinstall every 2 years or so simply to re-evaluate what tools I have and decide if I really want them enough to install and configure them again. It's part of the reason I resist systems like Nix, Guix, or even dotfile management tools.

Re: Using the same Arch Linux installation for a decade

#225
post #179

Earlier quoted context omitted.

stable, by dictionary definition, means "not changing or fluctuating", no bugs would be "bug free", there is no "bug free" distro.

it's a problem of scale: it can mean "changing or fluctuating" as in, the software itself won't change over, say, a time scale of months (what Debian means), OR "changing or fluctuating" in the sense that a stable chair does not fluctuates, breaks or tips over when you sit on it, e.g. at the time scale of an human interaction. I'd wager than people mean the latter in general with the word "stable".

But if they think that they can have the second definiton without the first, they're fooling themselves. The reason Debian Stable is both kinds of stable is because they test forever, eventually put the most finely tested software into a release, then keep working on fixing any bugs in that release until the next one.

edit: your new, experimental chair just released yesterday may be stable enough to sit on, but it's nothing to bet on.

Re: Using the same Arch Linux installation for a decade

#226

I always reinstall from scratch although I could just Debian "dist upgrade". My thinking is this: if, ten years ago, I somehow missed a security patch or some 0-day owned my machine before it was patched, then I'd potentially have been copying / dd'ing / rsync'ing a rootkit for ten years. By installing from scratch at every new stable (or unstable) release, I get rid of a lot of potential security issues. Now as an a…

> But it's fun to think I own one of the computer in the world with the biggest uptime. The top 500 entries on that list are almost guaranteed to be mainframes.

According to Guinness, the top is Voyager 2:

> The computer system that has been in continual operation for the longest period is the Computer Command System (CCS) onboard NASA's Voyager 2 spacecraft. This pair of interlinked computers have been in operation since the spacecraft's launch on 20 August 1977. As of 29 October 2020, the CCS has been running for 43 years 70 days.

https://www.guinnessworldrecords.com/world-records/635980-lo...

Re: Using the same Arch Linux installation for a decade

#227

Earlier quoted context omitted.

it's a problem of scale: it can mean "changing or fluctuating" as in, the software itself won't change over, say, a time scale of months (what Debian means), OR "changing or fluctuating" in the sense that a stable chair does not fluctuates, breaks or tips over when you sit on it, e.g. at the time scale of an human interaction. I'd wager than people mean the latter in general with the word "stable".

But if they think that they can have the second definiton without the first, they're fooling themselves. The reason Debian Stable is both kinds of stable is because they test forever, eventually put the most finely tested software into a release, then keep working on fixing any bugs in that release until the next one. edit: your new, experimental chair just released yesterday may be stable enough to sit on, but it's…

> The reason Debian Stable is both kinds of stable

I stop you right there - I ran debian stable for years. Arch Linux has been so much more "stable" in terms of "less bugs and issues" for daily use it's not even funny

Re: Using the same Arch Linux installation for a decade

#228

I always reinstall from scratch although I could just Debian "dist upgrade". My thinking is this: if, ten years ago, I somehow missed a security patch or some 0-day owned my machine before it was patched, then I'd potentially have been copying / dd'ing / rsync'ing a rootkit for ten years. By installing from scratch at every new stable (or unstable) release, I get rid of a lot of potential security issues. Now as an a…

I reinstall every 2 years or so simply to re-evaluate what tools I have and decide if I really want them enough to install and configure them again. It's part of the reason I resist systems like Nix, Guix, or even dotfile management tools.

That doesn't make much sense because Nix doesn't prevent you from reinstalling, and after you reinstall, you are not forced to copy your old configuration.nix to your new /etc/nixos/.

Re: Using the same Arch Linux installation for a decade

#229

Earlier quoted context omitted.

The current glibc version broke Easy AntiCheat support for Proton games, but that's the only break of note in recent memory, and it only affects people playing multiplayer games on Linux, which is a minority (multiplayer gamers) of a minority (Linux gamers) of a minority (Linux users).

glibc updates have recently broken lots of Electron software (and probably other stuff using similar sandboxing), by using a new syscall (clone3? or something) to implement some library methods. Pretty much every glibc update breaks something , honestly.

That breakage is because of the dumpster-fire that is seccomp. Your seccomp policy (in this case, the one that comes with Electron) whitelists syscalls, but which syscalls glibc uses to implement things is considered an implementation detail, not part of the contract. So seccomp was designed in a way that makes it broken-by-design with the most popular libc.

Re: Using the same Arch Linux installation for a decade

#230
post #78

Earlier quoted context omitted.

My preferred distro journey went: Mandrake -> Gentoo -> Debian -> Gentoo -> NixOS I rage-quit Gentoo the first time (2002ish?) for Debian when stable portage got a broken version of gcc, making it very hard to recover. The second Gentoo was by far the longest, maybe 2003 through 2018? I'm 4 years into NixOS now and very happy with it. I actually run into issues with switching to new release channels almost as often a…

Windows -> Solaris -> Windows -> Gentoo -> Arch -> NixOS I feel much more satisfaction pouring hours into NixOS over doing the same on Gentoo and Arch. The hours on nix are in a source file I can carry around. The hours on Gentoo and Arch I'm doomed to forget and have to repeat. I do miss the AUR though. I haven't been able to package a rust program that has a build with a transitive dependency that expects internet…

Yes, builds that expect internet access are not friendly with nix. It's particularly annoying when such packages are in something like cargo:

A: "We built this nice tool named cargo that manages transitive dependencies for you and will automatically fetch and build them from the internet"

B: F-this, I'll just download a tarball from the internet.

Post reply on HN