Comment by wowczarek | Hacker News Reader

Comment by wowczarek | Hacker News Reader

Parent Full thread

Back when I was a sysadmin (sort of 2007-2010), the preference of a colleague (RIP AJG...) who ran a lot of things before my time at the org, was FreeBSD, and I quickly understood why. We ran Postgres on 6.x as a db for a large Jira instance, while Jira itself ran on Linux iirc because I went with jrockit that ran circles around any JVM at the time. Those Postgres boxes had many years of uptime, locked away in a small colo facility, never failed and outlived the org that got merged and chopped up. FreeBSD was just so snappy, and just kept going. At the same time I ran ZFS on FreeBSD as our main file store for NFS and whatnot, snapshots, send/recv replication and all.

And it was all indeed on Supermicro server hardware.

And in parallel, while our routing kit was mostly Cisco, I put a transparent bridging firewall in front of the network running pfSense 1.2 or 1.3. It was one of those embedded boxes running a Via C3/Nehemiah, that had the Via Padlock crypto engine that pfSense supported. Its AES256 performance blew away our Xeons and crypto accelerator cards in our midrange Cisco ISRs - cards costing more than that C3 box. It had a failsafe Ethernet passthrough for when power went down and it ran FreeBSD. I've been using pfSense ever since, commercialisation / Netgate aside, force of habit.

And although for some things I lean towards OpenBSD today, FreeBSD delivers, and it has for nearly 20 years for me. And, as they say, it should for you, too.

> uptimes of over 3000+ days

Oof, that sounds scary. I’ve come to view high uptime as dangerous… it’s a sign you haven’t rebooted the thing enough to know what even happens on reboot (will everything come back up? Is the system currently relying on a process that only happens to be running because someone started it manually? Etc)

Servers need to be rebooted regularly in order to know that rebooting won’t break things, IMO.

Yep. I once did some contracting work for a place that had servers with 1200+ day uptimes. People were afraid to reboot anything. There was also tons of turnover.

Depends how they are built. There are many embedded/real-time systems that expect this sort of reliability too of course.

I worked on systems that were allowed 8 hours of downtime per year -- but otherwise would have run forever unless there was nuclear bomb that went off or a power loss...Tandem. You could pull out CPUs while running.

So if we are talking about garbage windows servers sure. It's just a question of what is accepted by the customers/users.

> I worked on systems that were allowed 8 hours of downtime per year -- but otherwise would have run forever unless there was nuclear bomb that went off or a power loss...Tandem. You could pull out CPUs while running.

Tandem servers were legendary for their reliability. I knew h/w support engineers years ago that told me stories like your recounting being able to pull components (such as CPU's) without affecting system availability.

>> uptimes of over 3000+ days

> Servers need to be rebooted regularly in order to know that rebooting won’t break things, IMO.

  the only thing we have to fear is fear itself[0]

Worrying about critical process(es) being started manually which will not be restarted if a server is rebooted has the same risk as those same process(es) crashing while the server is operational. Best practice is to leverage the builtin support for "Managing Services in FreeBSD"[1] for deployment-specific critical process(es).

Now if there is a rogue person which fires up a daemon[2] manually instead of following the above, then there are bigger problems in the organization than what happens if a server is rebooted.

0 - https://www.gilderlehrman.org/history-resources/spotlight-pr...

1 - https://docs.freebsd.org/en/books/handbook/config/#configtun...

2 - https://docs.freebsd.org/en/books/handbook/basics/#basics-pr...

I still remember AJG vividly to this day. He also once told me he was a FreeBSD contributor.

My journey with FreeBSD began with version 4.5 or 4.6, running in VMware on Windows and using XDMCP for the desktop. It was super fast and ran at almost native speed. I tried Red Hat 9, and it was slow as a snail by comparison. For me, the choice was obvious. Later on I was running FreeBSD on my ThinkPad, and I still remember the days of coding on it using my professor's linear/non-linear optimisation library, sorting out wlan driver and firmware to use the library wifi, and compiling Mozilla on my way home while the laptop was in my backpack. My personal record: I never messed up a single FreeBSD install, even when I was completely drunk.

Even later, I needed to monitor the CPU and memory usage of our performance/latency critical code. The POSIX API worked out of the box on FreeBSD and Solaris exactly as documented. Linux? Nope. I had to resort to parsing /proc myself, and what a mess it was. The structure was inconsistent, and even within the same kernel minor version the behaviour could change. Sometimes a process's CPU time included all its threads, and sometimes it didn't.

To this day, I still tell people that FreeBSD (and the other BSDs) feels like a proper operating system, and GNU/Linux feels like a toy.

All hail the mighty Wombats!

The "completely drunk" comment made me chuckle, too familiar... poor choices, but good times!

This is more about OpenBSD, but worth mentioning that nicm of tmux fame also worked with us in the same little office, in a strange little town.

AJG also made some contributions to Postgres, and wrote a beautiful, full-featured web editor for BIND DNS records, which, sadly, faded along with him and was eventually lost to time along with his domain, tcpd.net, that has since expired and was taken over.

> My journey with FreeBSD began with version 4.5 or 4.6, running in VMware on Windows and using XDMCP for the desktop. It was super fast and ran at almost native speed.

Wow, this brings back some memories. I remember being on a gig which mandated locked-down Windows laptops, but VMWare was authorized.

So I fired up FreeBSD inside VMWare running X with fluxbox[0] as the window manager. Even with multiple rxvt terminals and Firefox running, the memory used by VMWare was less than MS-Word with a single empty document!

0 - https://fluxbox.org/

Reply on news.ycombinator.com