Hacker News Reader

Comment by CrLf | Hacker News Reader

I've tried FreeBSD on occasion and that's exactly what kept me away from it. Keeping (multiple) systems current is always where most of the work is (if you do keep them current, that is), not on initial installation/configuration.

Honestly, I don't know if this is still the case.

View on HN

FreeBSD has made leaps and bounds with this.

You can use `freebsd-update` to update the OS itself from binaries instead of having to build world. https://www.freebsd.org/doc/en/books/handbook/updating-upgra...

You can use also `pkg` to install/upgrade software packages like `apt-get` on Debian derived distros. https://www.freebsd.org/doc/handbook/pkgng-intro.html

freebsd-update still implies semi-manual /etc/* merge. Both freebsd-update and pkg are no way close to apt-get and more importantly Debian 'unattended upgrades' feature.

> freebsd-update still implies semi-manual /etc/* merge

freebsd-update.conf

> Both freebsd-update and pkg are no way close to apt-get and more importantly Debian 'unattended upgrades

Exactly, it's better.

It's much better than the old days. pkgng and freebsd-update make it pretty straightforward to keep updated... not really any different than on any of the Linux flavors I use. The ports tree is hooked up with pkgng too, so you can mix and match (before they used to recommend you only use one or the other).

The major problem is at an enterprise scale (hundreds of thousands of servers and above) it becomes untenable due to the nature of ports tracking upstream and constantly in flux.

It makes it difficult to support the applications and services that run on the OS as a result.

Whereas with something like RHEL/CentOS, we're guaranteed stability for years and can patch without too much concern of major breakage.

This is the part that really appeals to most enterprise users.

Everywhere I've worked (from places with a handful of VM startups to 20k machine enterprise) it's also a cop out to completely abandon care and feeding of systems. I call it Long Term Suck, and I've yet to see a place where it has not caused long term harm to an organization big or small. If you aren't equipped to deal with gradual shift in API of dependencies, you shouldn't be doing whatever you're doing or the code has a half life and should be trashed after the employees that understand it have moved on.

What _is_ important is ABI stability of the kernel, because it lets you figure out how to deal or not deal with Long Term Suck on your own terms and lets proprietary software vendors figure out independently how they want to do deal with it. Both Linux and FreeBSD kernels do this pretty well.

The recommendation from the guys in #freebsd in freenode was for [you] to build pkg's yourself from ports, which means you always have versions you know work lying around.

I thought it was a nice idea, and they really push this as being "an easy thing anybody should be able to do".

which fits with my philosophy of "severs should not have/use compilers"

Why do you feel this way? Security?

If I can get a shell on your server I will just download my own compiler.

no, it's that there should never be a need to compile on machines dedicated to a purpose.

I don't need source files, I need a machine to be a compute node.. or a storage node.. what use is a compiler if I do it right..

the new generation of this is: "I should never need to shell into my machine if I did config management right."

I understand and agree with that.

There is a stable/quarterly ports tree now and it's the default package set. It's not so caustic anymore.

Reply on news.ycombinator.com