Live data from Hacker News

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

crocidb.com

211–220 of 241 posts

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

#211
post #48

Earlier quoted context omitted.

5 years is not a lot. It releases every 2 years, so it requires upgrading at least every 4 years. In the worst case it's just 3 years of support, if you install right before the next release. ELTS is 10 years and paid. It's great that it exists, but not relevant for my toy projects.

I don't work on a server team, but in network/network security. My company made an announcement that they are extending our product's software lifetime to four years: 3 years standard support + 1 year high sev patches. It seems to me in the 2020s that 5-7 years is plenty of support for a single OS release, and that OS support teams should be nimble enough to roll out new instances and migrate data at that cadence.

Did you read the blog post? Not upgrading a server for 10 years does happen. And it's fine if you get the right distribution with security updates.

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

#212

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…

Which is moot, because of the system is important enough you'll have an automatic failover to another system running on standby All this "we must reboot to test" is bullshit excuses by unqualified workers

Ah, spoken with the confidence of a freshly minted qualified worker :). Anything you don’t test is a wish, not a production system. You either know that your systems work end to end because you tested periodically, or you pray they will.

How do you know the automatic failover works? How do you know the standby system works?

I’ve seen many a “qualified workers” getting sent packing because they never fully tested the prod system because they just knew everything will work, and never tested the backup systems because qualified workers do the job right the first time, no need for backup.

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

#213
post #53

Earlier quoted context omitted.

I would say NixOS, where it is trivial to switch across releases, run software from different releases, and perform rollbacks. I have been running NixOS on several servers for more than a decade. No reinstalling, upgrading, or any breaks whatsoever.

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 installation frozen in time for 5 years that then you want to update to latest all of a sudden

I have done this recently as I kept an airgapped machine, which I decommissioned, connected to the Internet and updated to the latest channel. Everything worked just fine. I just had to change a couple of options in my configuration which had become outdated. Nix is functional, so it's much less prone to all stateful issues that plague other package managers.

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

#215

Earlier quoted context omitted.

Servers are work, including security overhead, so yes, don't spin them up if there is an alternative solution that is superior in every way except for not being able to churn digital butter.

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 long as you're OK with me calling you a bullshitter for understating the cost, risk, effort and complexity of running an Internet-facing server properly, especially compared with the enormous advantages of using a CDN for static content.

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

#216
post #81
post #62

The biggest mistake I made was high uptime. arjie.com was up for 10 years plus on a Hetzner VPS so that by the time they wanted to sunset the machine underlying I had no idea what my teenage self had set up. I have the backups but the site hasn’t been up in a decade… Nowadays I build things so that they move and I have moved things about a bit so I know they work.

"The biggest mistake I made was high uptime" Quite. I'm old enough to remember machine uptime being a badge of honour. However, being older and not really wiser, I look for service uptime these days. Yes we did have similar back in the day, that's why MX and the like DNS records exist. Old school clusters were pretty esoteric but the lessons were learned (split brain n that) and that's why we still argue the toss wit…

My raspberry pi serves only to be the tiebreaker my possible split brain 2 node cluster lol. It is literally called tiebreaker

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

#217

Earlier quoted context omitted.

You can make it zero deploy steps beyond git push with CodePipeline, and vibecoding makes the annoying config setup trivial if you know like 20% of what you're doing. There is really zero reason to be using a VPS for this unless you hate money, want your site to choke during once-in-lifetime opportunities to go life-changingly viral, and like contributing to the global population malicious botnets.

Why would a VPS choke hosting static HTML? For 5 EUR you get 20 TB traffic on Hetzner.

You tell me. Here's a list of maybe 15 sites it's happened to on HN in just the last month: https://hn.algolia.com/?dateRange=pastMonth&page=0&prefix=tr...

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

#218

FreeBSD uses ZFS. I've been using ZFS for about a decade on several systems and can't say enough good things about it: rock solid, feature rich and easy to use are the top benefits. It really needs more love!

And it's been used by many commercial networking and storage appliances too. Juniper using various devices (routers, firewalls, switches, etc), Citrix Netscreen load balancers, Dell storage Isilon just to name few. Knowing FreeBSD pays dividends if you work enterprise gear. Makes your life so much easier even there is vendor specific UI's and shell, but you know your way around so much better when you encounter any issues which requires using shell and it helps you debugging things you would otherwise not being able to accomplish.

Knowing you way around *BSD how check things, mount a USD drive, collect data & or evidence when need arises is well worth having beyond just surviving bare Linux skills. BSD's are alive and kicking on commercial appliances and devices.

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

#220
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.

A Danish bank found out that this can bite you in the ass. When you hotpatch the system for years then you have no idea if the system can boot up or it will fail somewhere in the booting process. i.e. you can only trust what you regularly test.

US telcos as well.

There were several switch failures in the 1980s / 1990s in which systems which had been upgraded in place without a full restart failed. (IIRC, one burnt down, literally.)

Engineers were uncertain as to whether or not a cold-boot restart was even possible.

Account concerning an AT&T system upgrade sourcing Risks Digest (Vol 9, Issue 62, February 26, 1990) by the recently deceased Peter G. Neumann: https://telephoneworld.org/landline-telephone-history/the-cr...>.

Post reply on HN