Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Blog ran on Ubuntu 16.04 for 10 years. I migrated it to FreeBSD

crocidb.com

Post reply on HN
Print view View original

221–230 of 241 posts

Re: Blog ran on Ubuntu 16.04 for 10 years. I migrated it to FreeBSD

#221

Post by tombert »

andix wrote: post #209
tombert wrote: post #94

Earlier quoted context omitted.

I've only been running NixOS (in any serious capacity) for three years, but I have installed it on every computer that I am allowed to install it on now. It has been the most headache-free Linux I've used, simply because I'm less scared to play with and fix stuff. The fact that rollbacks are trivial and snapshots are automatic, and since everything is declarative in a text file anyway, I am way braver. If I do someth…

> simply because I'm less scared to play with and fix stuff. The main reason of a LTS distribution is not having to play around and fix stuff. Install something once, and it keeps running without any changes, but still gets security updates.

Yeah, but I find that particularly with laptops, even with LTS releases, there's almost always something you need to fix.

For example, there's a weird quirk with my laptop that if I am using a USB keyboard and stop typing for more than a minute, it "powers down", and if when I start typing again it misses the first four or five characters, which is very annoying.

The solution involved putting a few boot parameters and then it works fine and as expected, but I would be reluctant to do that with Ubuntu or really any non-NixOS distro, because if I screw up a boot param I get into a situation where the computer won't, you know, boot, meaning I'm stuck screwing around with grub commands and trying to fix things, which is annoying. With NixOS, if I screw things up it's like a minute of rebooting and choosing the old generation.

Not to mention that if you have a non-declarative OS, it can be hard to know what exactly is on the computer. When I ran an Ubuntu LTS server, I eventually had installed dozens of packages that I don't think were being used but it was hard to know for sure which ones were necessary and which ones weren't. When I'm using NixOS all the packages are unambiguously in the configuration.nix. "Uninstalling" a program (including its transitive dependencies) is just removing that package out of the configuration.nix and rebuilding.

I have nothing against LTS releases, but I do think that at least for laptops (which can have kind of arcane hardware quirks) it's better to use NixOS.

Re: Blog ran on Ubuntu 16.04 for 10 years. I migrated it to FreeBSD

#222

Post by Squeeeez »

kjs3 wrote: post #196
da_chicken wrote: post #155

Earlier quoted context omitted.

The problem with live patching is twofold. First, you might not reload everything in memory, so it will be patched on disk but not in process. Second, you have not tested that the system can boot to a functional system. Say you have done live patching for 5 years and never rebooted, and then you have a power loss or hardware failure/upgrade that takes the system down. When you try to bring it back up, it doesn't work…

And, yeah, everything is hot swappable on VAX. Only the last generation or 2 of the highest end VAXen had any significant hot swap (VAX 9000/400 and later, which sold very poorly). The vast majority of VAX machines didn't. Even hot-swapping DSSI disks was at best iffy. When someone whose been there talks about VAX 'high availability', they're usually talking about VAX/VMS clustering. Very cool and generally effective…

How would you implement no-downtime hot swap with only one item?

Re: Blog ran on Ubuntu 16.04 for 10 years. I migrated it to FreeBSD

#223

Post by andix »

tombert wrote: post #221
andix wrote: post #209

Earlier quoted context omitted.

> simply because I'm less scared to play with and fix stuff. The main reason of a LTS distribution is not having to play around and fix stuff. Install something once, and it keeps running without any changes, but still gets security updates.

Yeah, but I find that particularly with laptops, even with LTS releases, there's almost always something you need to fix. For example, there's a weird quirk with my laptop that if I am using a USB keyboard and stop typing for more than a minute, it "powers down", and if when I start typing again it misses the first four or five characters, which is very annoying. The solution involved putting a few boot parameters an…

I would never put a LTS system on a general purpose desktop.

This would only make sense for some corporate environments, where the hardware purchases are aligned with the driver support of the LTS distribution. And even then it's questionable.

LTS distributions are mainly used on servers or on (network) appliances.

Re: Blog ran on Ubuntu 16.04 for 10 years. I migrated it to FreeBSD

#224

Post by [deleted] »

not_kurt_godel wrote: post #215
mx7zysuj4xew wrote: post #182

Earlier quoted context omitted.

Sounds to me that you're giving bullshit excuses because you lack the skills to run a basic httpd

Lol, I have years of experience managing/being oncall for business-critical production hosts that generated thousands of dollars of revenue per minute. While I don't profess to be a particularly skilled sysadmin, I will say the worst incident I was responsible for over those years was a minor 30-minute brownout that cost about $5k in lost revenue. So sure, you can call me a bullshitter if that makes you happy, as lon…

[deleted]

Re: Blog ran on Ubuntu 16.04 for 10 years. I migrated it to FreeBSD

#225

Post by andix »

ezst wrote: post #64
andix wrote: post #4

Slightly off topic: What's currently the free Linux distribution with the longest support cycle? For a while I used CentOS 7 on all of those small VMs, because it got security updates for a really long time. With minimal risk of breaking things on updates. PS: after a bit of research Alma/Rocky Linux are probably the best choices for now. 10 years of support. But are they maintained well?

For a while (a decade+), I was running CentOS on my servers on the same assumption of long time stability and ensuing peace of mind. Then I figured that over such durations, the ecosystem drift becomes significant and keeping applications up to date and running on top of the OS becomes an increasing challenge (with the more "infrastructure" packages like glibc, python/Apache combos, GCC, ... slowly becoming incompati…

> slowly becoming incompatible with the latest applicative stack

LTS distributions are great if your applications don't change (much), or are explicitly compatible with the specific distribution you run them on.

Re: Blog ran on Ubuntu 16.04 for 10 years. I migrated it to FreeBSD

#226

Post by fragmede »

da_chicken wrote: post #155
pjmlp wrote: post #128

Earlier quoted context omitted.

There is something like live patching. One reason mainframes and micros are still around us, is that you can change almost everything between hardware and software without downtime. It is also available in commercial surviving UNIXes, and as paid for feature in some Linux distros, although not to the extent that those grandparent systems are capable of.

The problem with live patching is twofold. First, you might not reload everything in memory, so it will be patched on disk but not in process. Second, you have not tested that the system can boot to a functional system. Say you have done live patching for 5 years and never rebooted, and then you have a power loss or hardware failure/upgrade that takes the system down. When you try to bring it back up, it doesn't work…

You patch it in memory and on disk. What you put on disk is the patch though, so when you restart, the original unpatched version is booted, and then the same live patch is applied. This is how Ksplice worked. It has the advantage that there isn't a config file in /etc to get changed out from under it, so the second problem did not apply.

Re: Blog ran on Ubuntu 16.04 for 10 years. I migrated it to FreeBSD

#227

Post by kjs3 »

Squeeeez wrote: post #222
kjs3 wrote: post #196

Earlier quoted context omitted.

And, yeah, everything is hot swappable on VAX. Only the last generation or 2 of the highest end VAXen had any significant hot swap (VAX 9000/400 and later, which sold very poorly). The vast majority of VAX machines didn't. Even hot-swapping DSSI disks was at best iffy. When someone whose been there talks about VAX 'high availability', they're usually talking about VAX/VMS clustering. Very cool and generally effective…

How would you implement no-downtime hot swap with only one item?

By implementing hot-swap into the one item? Am I missing something in this question?

Re: Blog ran on Ubuntu 16.04 for 10 years. I migrated it to FreeBSD

#228

Post by com2kid »

MrDOS wrote: post #147
com2kid wrote: post #111

Earlier quoted context omitted.

> So there is a project that you care enough about to keep it alive, but 1-2 hours every FOUR YEARS is too much? At some point I just have to call you lazy dude. I want the machine that serves my static blog pages to have, ideally, 0 maintenance. It needs to do one thing, serve some static HTTP pages and have new pages pushed to it. Quite frankly I wish some of those "minimal docker first OSs" had taken off.

If you want 0 maintenance, then you don't want to run your own infrastructure. Go give NearlyFreeSpeech or some other shared host a few cents every month and you'll be much happier.

Hilariously I pay less for a vultr box than what nearlyfreespeech charges.

Vultr is really damn cheap.

Re: Blog ran on Ubuntu 16.04 for 10 years. I migrated it to FreeBSD

#229

Post by darkwater »

nextos wrote: post #213
darkwater wrote: post #134

Earlier quoted context omitted.

This is your personal opinion, a rolling release like NicOS is exactly the opposite of an LTS distro. I actually wonder what would happen to a NixOS installation frozen in time for 5 years that then you want to update to latest all of a sudden.

> a rolling release like NixOS is exactly the opposite of an LTS distro NixOS is not rolling release. This is a common misconception. You can use the unstable channel, which is a rolling release, or the regular channels which get released twice a year. These are really stable and move very slowly. You can also mix and match, running software from different channels. > I actually wonder what would happen to a NixOS in…

Technically it's not rolling but you get substantial updates during the stable channel lifetime, unlike Debian or Ubuntu. And when the stable channel is deprecated (every 6 months) you need to manually change it and get a bigger version bump of most softwares all of a sudden. There is no LTS concept where you can leave almost on autopilot a distro version for 5 years.

Re: Blog ran on Ubuntu 16.04 for 10 years. I migrated it to FreeBSD

#230

Post by da_chicken »

fragmede wrote: post #226
da_chicken wrote: post #155

Earlier quoted context omitted.

The problem with live patching is twofold. First, you might not reload everything in memory, so it will be patched on disk but not in process. Second, you have not tested that the system can boot to a functional system. Say you have done live patching for 5 years and never rebooted, and then you have a power loss or hardware failure/upgrade that takes the system down. When you try to bring it back up, it doesn't work…

You patch it in memory and on disk. What you put on disk is the patch though, so when you restart, the original unpatched version is booted, and then the same live patch is applied. This is how Ksplice worked. It has the advantage that there isn't a config file in /etc to get changed out from under it, so the second problem did not apply.

Ksplice can do that because the kernel is only in memory in one place an it never sleeps. It has to orchestrate a process that's always running, which is complex, but it's never more than one.

Now try patching glibc like that. Not only does almost every thread have it in memory, several of them will have it in process, and some of them will have it swapped to disk while the thread sleeps. You're going to quickly decide that you actually just want a little bit of downtime or else you want to stand up a redundant system. There's a reason that some live patching systems explicitly exclude glibc and similar libraries.

Post reply on HN