Live data from Hacker News

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

crocidb.com

141–150 of 241 posts

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

#141
post #46

Earlier quoted context omitted.

I pay $35/month for a dedicated server for my nothing webpages. One the one hand, I could really host at home for $0/month extra. Or on a VPS for $5/month. I do need my own thing because I run a network testing tool that needs some amount of direct access. On the other hand, dedicated servers are more fun, even if the cpus I get for $35/month are ancient. Is it $30/month fun? Probably not, but it's near zero given my…

Good on ya. Personally I'm happier with my extra ~$6k, sparing of however many hours of pointless maintenance work over the years, and 100% uptime over past/present/future even if I go into a coma.

You are vastly overstating how much maintenance a FreeBSD box has.

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

#142
> I don’t know why fastfetch always report more memory being used than the actual values. I’ve never seen more than 3GiB used in btop for this server

Probably, it's because of ZFS ARC (Adaptive Replacement Cache). It's similar to Linux's page cache, can be claimed back any moment and different tools name it differently: https://www.linuxatemyram.com/

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

#143

I'm in the same boat. I have 2 old servers that I let get "too" old, and now I'm afraid to touch them to update them. However, with some of the shenanigans that the Linux distributions are pulling around age verification/attestation, I'm considering bailing on them entirely. Note, I did try Artix, but when it broke last week after a restart (in which evidently something had gone wrong with an earlier kernel update),…

> something had gone wrong with an earlier kernel update

That's mostly problem of Arch/Artix, they're the bleeding edge, which is not always the best for stability. But no one said that rolling distro is supposed to always ship latest versions of everything. I've been using Void Linux past months - and while it's a rolling distro, it runs LTS kernel (mainline is also available) and maintainers are more focused on stable versions of apps than on faster updates.

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

#144

Personally, I've been running with Caddy in front of Docker (compose) for most of my personal/hobby usage. If it's a straight website, I'll let Caddy serve the contents directly... for "web apps" I'll pretty much containerize all the things and use caddy for TLS termination and reverse-proxy duties to the app running under Docker... Mostly ~/apps/appname, where each appname has a docker compose file, and the data dir…

This is more or less how I do it, too. Debating switching from Debian to something like Flatcar which is container-first with an immutable system/OS. I think FreeBSD has some interesting technical merits, but like it or not Docker is the default for a lot of open source software, and I have neither the time nor the inclination to translate everything to freebsd jails.

I've had my private servers running Arch (managed by Ansible) for the last 5 years but have recently been looking into Talos for the same reasons. Setting up a single node k8s using Talos was actually pretty straight forward. In the end I decided against it just because I couldn't justify the continuous load caused by k8s components when my stuff is only sporadically in use... Instead I now have them on NixOS and I really enjoy the declarative approach (although the language annoys me).

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

#145
post #140
post #8

The benchmarks are completely off, and a recent version of Ubuntu with sane config would easily beat Freebsd.

Show me those benchmarks

From every benchmark I've seen so far, Linux has always been faster than the BSDs.

For example, look at these benchmarks from 2003[1]. The newest benchmarks I could find[2], [3] point in the same direction.

[1] http://bulk.fefe.de/scalability/

[2] https://matteocroce.it/blog/freebsd_linux_networking/

[3] https://www.phoronix.com/review/freebsd-15-amd-epyc-linux

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

#146
post #128
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.

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.

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

#147
post #63

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. Either the 1-2 hours is a drop in the bucket compared to what you spend on it anyway (like a blog you still regularly update), or you don't actively update the project but still care enough about it to spend half an evening every few years, or you should just…

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

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

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

I'd say not much: you update the channel, run nixos-rebuild switch, fix all the warnings/errors due to renamed/changed options until it succeeds and you're done. If you have a database like postgres you may have to do a schema upgrade manually, since the default version is updated every 4/5 releases or so.

It's very rare to find something that prevents you from directly updating. Nixpkgs tries very hard to no require new Nix features, so it evaluates with even Nix versions from a decade ago. Also, NixOS options and packages are frequently changed, but the automatic migrations (mkChangedOptionModule, mkRenamedOptionModule, alias, etc.) are never removed in practice.

Since the binary cache has never been cleared since its creation (2002?), it should actually be easy to install a super old NixOS release and upgrading it to the latest to see what happens.

By the way, there are LTS versions of NixOS, just not officially supported. See https://docs.ctrl-os.com/.

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

#149

Boggles my mind that people pay money to host hugo static sites on a VPS, which is objectively inferior and harder in every meaningful way compared to hosting for free on GitHub pages or S3+CloudFront.

some people (myself included) like hosting their own stack for fun or for learning. There's additional concern with tying your work to something like github it makes it more of a pain to pull it off and put it somewhere else. I'm not really sure what you mean by objectively inferior. It's trade offs like everything in this field. As far as harder, I don't really think the lift for a personal VPS is that high. Again i…

> for learning.

That's great if that's what you want, but you are commenting in a thread full of people gleefully spouting off about decades-old installations that they self-admittedly have “no idea” how to upgrade. Most people in here would be better off if they admitted to themselves that they are not actually taking advantage of the opportunity to learn, and are instead undertaking a liability.

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

#150
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…

two is the right minimum number for a high availability dataplane but three is the right minimum number for a HA control plane.

With that said, if high availability is not a concern then 1 can be just fine.

Post reply on HN