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

151–160 of 241 posts

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

#151

Post by peanut-walrus »

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?

I see no reason not to go with a rolling release distro for personal servers. Run all the services in containers and have the base OS auto-update itself as often as it needs.

Went with openSUSE MicroOS myself, it updates and reboots almost daily so I can be pretty confident my server is healthy and it's atomic so if something does break and I don't feel like dealing with it, I can just click rollback button from cockpit and deal with it whenever I have time.

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

#152

Post by pjmlp »

silvestrov wrote: post #146
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.

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.

Interesting, it there any public info on the case?

Not doubting it, only curious about some kind of postmorten.

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

#153

Post by ErroneousBosh »

pjmlp wrote: post #128
gerdesj wrote: post #81

Earlier quoted context omitted.

"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…

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.

> One reason mainframes and micros are still around us, is that you can change almost everything between hardware and software without downtime.

We have some Sun V880s at work and I'm fairly sure the only part you cannot change with the power on and system running is the motherboard itself.

And I would not be surprised if some ex-Sun Gandalf Beard "well akshully"s this comment.

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

#154

Post by MrDOS »

jadedragon942 wrote: post #109
not_kurt_godel wrote: post #87

Earlier quoted context omitted.

I mean, obviously we're not gonna see eye-to-eye if you're talking about a non-static, non-hugo site, which was the subject of my comment. I've owned and operated enough stacks e2e both personally and professionally to have gotten over the novelty. The less shit that can go wrong, the better. I sleep better at night not wondering whether any of the constant stream of IPs in my fail2ban log is wielding a yet-to-be-CVE…

Sorry to jump in... But why are you ssh'ing into your hosts over the open net? Why not tailscale? Why not wireguard?

Assuming password authentication is disabled, why wouldn't you SSH into your hosts over the open net? Why Tailscale? Why Wireguard?

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

#155

Post by da_chicken »

pjmlp wrote: post #128
gerdesj wrote: post #81

Earlier quoted context omitted.

"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…

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. Which configuration change in the past 5 years caused that? Which backup do you use?

And, yeah, everything is hot swappable on VAX. Those machines also cost 6+ figures, and often require a service contract that includes a permanent on site tech.

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

#156

Post by coldtea »

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…

>First, you might not reload everything in memory, so it will be patched on disk but not in process.

You design for this with generational tagged objects or something similar.

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

#157

Post by exyi »

peanut-walrus wrote: post #151
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?

I see no reason not to go with a rolling release distro for personal servers. Run all the services in containers and have the base OS auto-update itself as often as it needs. Went with openSUSE MicroOS myself, it updates and reboots almost daily so I can be pretty confident my server is healthy and it's atomic so if something does break and I don't feel like dealing with it, I can just click rollback button from cock…

Then you also have to auto-update the containers, if it's a public facing service. Either you'll have to build containers yourself or hope the developer pushes a new update whenever the base image has relevant security fixes.

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

#158

Post by AltruisticGapHN »

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?

I mean Ubuntu Pro is free for personal use and it extends the LTS support of 5 years so a total of 10 years afaik.

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

#159

Post by pjmlp »

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…

Yes, some things actually cost money, especially if they aren't easy to implement.

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

#160

Post by silvestrov »

pjmlp wrote: post #152
silvestrov wrote: post #146

Earlier quoted context omitted.

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.

Interesting, it there any public info on the case? Not doubting it, only curious about some kind of postmorten.

In Danish: https://danskebank.com/da/news-og-insights/nyhedsarkiv/press...

or translated: https://danskebank-com.translate.goog/da/news-og-insights/ny...

TLDR: power supply failed completely and DB2 failed running recovery operations due to multiple old/existing software bugs.

Post reply on HN