Comment by e63f67dd-065b | Hacker News Reader

Comment by e63f67dd-065b | Hacker News Reader

In my mind, Ubuntu Desktop, and desktop linux in general, has always been a hobbyist project masquerading as a real production-ready environment. There's no money in building a desktop distro, so nobody really cares what happens there.

The real power of Ubuntu has really always been as a server distro. I used to run desktop Ubuntu when I was younger and had more spare time to tinker with this nonsense, but nowadays I administer enough ubuntu servers at work, I don't need to do it at home too. Ubuntu server is great -- everything is very well-documented, LTS is stable, snaps are sometimes pretty useful (I recently had to quickly spin up redis temporarily for a project and it was a one-liner), and everything just works in general.

I used to run CentOS (rip) servers, and Ubuntu, whilst noticeably worse, is still great to administer. It's not all sunshine and rainbows for sure, but things generally work the way you expect them to and things are generally sane.

What would you consider a "real production-ready environment" for the desktop?

I don't know if I'm just lucky, but my last 4 HP computers (3 laptops and a desktop) have all worked perfectly on Linux since day 1, whereas Windows has been a complete shitshow, having to wait as long as 1 year for some peripherals to be supported. In one case, I didn't care, since it was the webcam, which I never use. In the other, it was a PITA since it was something graphics-driver related, and I couldn't reliably use an external 4k screen without doing a plug-unplug-replug-just-right circus. Sleep is hit-and-miss, with one laptop being almost guaranteed to wake up and crash at night while left asleep. The desktop PC still has unreliable thunderbolt support.

Then there's the UI that lags like no tomorrow, the windows jumping around when switching virtual desktops, new browser windows never showing up where you expect them, windows seemingly in the foreground not getting input, inconsistent input field behavior, etc. Oh, and half the dialogs are still from the windows 95 era, so it's not even "prettier" or more "cohesive" than my i3 / gnome frankendesktop. Also, the start menu search, aside from being slow, has a good probability of not finding the app I'm looking for.

For server, Debian is the simpler and more stable solution.

FreeBSD is a great option on the server as well. Simple, stable, mature, and great documentation.

If I tried to run FreeBSD in prod I might have actually been fired. None of the BSDs are production ready: basically nothing is validated to work with them, there’s no commercial support, less available sysadmins, no software officially supports it, etc. It’s a hobby system, nothing more.

It's theoretically possible to use it in prod; I know that some companies (Netflix?) do it. But it's certainly not common and takes a lot of engineering resources to make it work.

It definitely depends on your needs. FreeBSD absolutely does support production workloads. Netflix as you mentioned, WhatsApp (Meta), and several ISPs and hosting providers make use of it.

Any competent Linux sysadmin could learn to admin a BSD in no time. The FreeBSD handbook and the man pages are excellent. In my opinion they are far better quality than their Linux equivalents.

You also won't have any issues if your server runs on an open source stack such as Python, PHP, Perl, Ruby, Java (OpenJDK), NodeJS, etc.

You're absolutely right about FreeBSD not having first party commercial support. If you need that, you're basically stuck with RHEL, SUSE, Ubuntu, or Oracle.

It's not just administration, it's everything else living on your server. It's the difference being surprised when package x doesn't support ubuntu and being pleasantly surprised when it does support BSD. It's the difference between being the most well-tested and well-supported configuration of all your tools and a niche thing that a couple volunteers got working.

Many of the things I did as a traditional university sysadmin long ago probably works on FreeBSD, and if you wanted to deploy a LAMP (FAMP?)/Django/Ruby on Rails/etc stack it would probably be good enough, but the world has moved on since then. Once you want k8s, ansible, distributed filesystems, HPC, scientific, etc. it starts to break down really quickly. Many of the things I listed above may work, but it's the less documented, less supported, more annoying, and more likely to break path. The extra time spent getting it to work on FreeBSD and maintaining it is not time well spent unless there's a very specific reason FreeBSD is better, just grab RHEL/SLES/Ubuntu and skip all the hassle.

FreeBSD has its place in very limited scenarios and where you have the engineering resources to deploy it, but it should not be the default choice for a production deployment.

I work at the FreeBSD Foundation. There are a couple points I'd like to make. First, FreeBSD support in Ansible and Salt is very good. There is work to do on K8s, but runj represents a great start and there are a bunch of resources available on how to use FreeBSD for cloud native. Last, I think your final point that "[FreeBSD] should not be the default choice for a production deployment" could be worded better. I gather your meaning is "...for a general purpose enterprise deployment". Assuming that’s what you mean, FreeBSD limitations that make it difficult for general purpose enterprise use is something I have heard and that I am personally involved in trying to improve. To me, that's different from "production deployment". There is a long list of production deployments of FreeBSD at the infrastructure and device layers - routers, VPNs, firewalls, storage systems, hosted security solutions, industrial control systems, CDNs, payment networks, and embedded devices.

Debian is not really an alternative. There’s no maintenance guarantee, no support contract, and is usually not validated to work with packages the way Ubuntu and RHEL is. These are the kinds of things that matter for production.

Freexian offers a support contract for Debian ELTS.

Problem is Debian is usually so far behind on software and it's harder to install new ones that are not from source. That was the great thing about Ubuntu. You could get an LTS and pick and choose what you wanted to have newer.

How do you deal with init scripts that try to uninstall packages, but ubuntu having unattended upgrades immediately, so at times apt-get is locked at first boot?

Reply on news.ycombinator.com