[junk_disposal]

In my opinion (mostly Debian user with a bit of FreeBSD playing), people use Debian as a server for the same reason a lot of people like MacOS over Linux - It Just Works.

1. For many years, the only way to install software was ports. Now if you're a full time sysadmin with time on his hands, it's great. But if you just need something up and running fast (and if you don't know your software internals, and don't know if you'll need perl's FLAG_ABC) , it's horrible.

It just feels like Linux in the 90's (been there), where recompiling the kernel/freex86 was a right-of-passage into Linux hackerdom. Nowadays, most of the time it's just not worth it.

2. apt vs ports/pkg. This is actually the biggest thing keeping me on Debian - stable + backports.

If I'm running my server, I want things to be stable. Now I know that there's no other project the size of Debian, which can backport security fixes to two year old software (and sometimes four year old software), but there's nothing like apt update && apt upgrade and 99% of the time have everything update without a hitch.

Yes, FreeBSD is more elegant (why couldn't GNU/RedHat have just modeled ifconfig rather than ifconfig, ifup, ip, etc.). Yes, FreeBSD's man pages are amazing (which is quite important, as there's not as many FreeBSD blogs around), but if you're learning a new system (coming from Windows), Linux isn't that much harder to learn than FreeBSD.

EDIT

And RedHat?

They work like Oracle - You pay them, and they'll hold your hand, and (unlike Oracle) they release their software under an OS license.

If you're a non-tech Fortune 500, that's very important.

Note, by the way, that those two distros have the vast majority of GNU/Linux installs.

[derefr]

> why couldn't GNU/RedHat have just [modified] ifconfig rather than [having] ifconfig, ifup, ip, etc.

This comes down to one of the key differences between Linux and BSD: BSD "owns" its userland—the people who develop the kernel, or some system utility, can literally decide to change something, and then do a global search-and-replace on all usages of that something across all consuming projects. Because all those projects are "part of" BSD in a very literal sense. You can decide that ifconfig(8) should work differently, and bam, there you go, now it works differently. Now the tools that call it and parse its output work differently, too. Everything works differently; but everything still works. Document the new behavior in the man(1) pages.

Linux, meanwhile, is in essence a giant Mexican standoff: nobody can change the interface of the thing they're responsible for, without potentially breaking something someone else is doing that they're not aware of at all. So Linux devs, rather than changing old interfaces for the better, just leave the old interfaces where they are in a sort of "legacy-compat" mode, and build entirely new interfaces that work the way they "should." (And then people start to depend on the details of the new interface, and it all happens again five years later.)

[junk_disposal]

>This comes down to one of the key differences between Linux and BSD: BSD "owns" its userland—the people who develop the kernel, or some system utility, can literally decide to change something, and then do a global search-and-replace on all usages of that something across all consuming projects. Because all those projects are "part of" BSD in a very literal sense. You can decide that ifconfig(8) should work differently, and bam, there you go, now it works differently. Now the tools that call it and parse its output work differently, too. Everything works differently; but everything still works. Document the new behavior in the man(1) pages.

1. Linux doesn't care about ifconfig et. al. It's Debian/RedHat/Arch/Gentoo/Slackware that does. And they can do the same grep across their codebase.

They don't now for the same reason BSD doesn't just run in and change things, because lots of admins have scripts which aren't maintained by BSD which depend on existing config.

2. I would assume that the BSD ifconfig came first, so why didn't existing distros copy their system? Is it a BSD vs. SysV thing?

[_delirium]

The package management is definitely what drove me away from FreeBSD in the early 2000s. BSD people loved ports, but my main recollection of it is that I spent a lot of time waiting for things to compile. A lot of time, hours in some cases. I liked how apt worked a lot better, both in terms of speed and the interface.

Nowadays, FreeBSD does actually have more apt-like package management, with a fairly simple high-level interface that installs prebuilt binary packages (properly resolving dependencies among them, etc.), called pkgng. I recently tried it again, and it's nice, exactly what I was missing at the time. NetBSD's story here is good today as well, with pkgin (the high-level interface to pkgsrc) also being quite nice, nice enough that I use it on OSX despite never having even run NetBSD (so I'm not using it on OSX because of a preexisting love of it) [1]. But 15 years ago, apt was clearly better, at least for my uses.

[1] I use it on OSX via Joyent's packages, https://pkgsrc.joyent.com/

[haroldp]

FreeBSD has had a package system (pkg_add, etc...) since... the mid 90s? The packages were just ports pre-compiled on freebsd.org's computer.

The new package system is much better, and more apt-like. Again though, they are ports pre-compiled on freebsd.org's computer.

Most port options can be selected through an obvious curses interface that comes up when you make the port these days. The defaults are usually reasonable. As long as unix software is distributed with important compile-time options, I will enjoy how easily they are managed through ports.

[dangerbird2]

Even better, you can easily run your own pkg repository with binaries compiled for multiple architectures (with build enviroments isolated with "jail") and providing the full range of compilation customization included in the ports tree.

https://www.freebsd.org/doc/handbook/ports-poudriere.html

[junk_disposal]

>you can easily run your own pkg repository with binaries compiled for multiple architectures (with build enviroments isolated with "jail") and providing the full range of compilation customization included in the ports tree.

Sure, if you're running a few servers. It doesn't help if you're running one though.

And it still takes time to compile and build.

[phicoh]

It's a choice. If you can live with binary packages produced by the FreeBSD project, why not use those?

If you want something special, why not set up poudriere and update during the night. Realistically, if you are running FreeBSD in production, you want a spare server to try new releases, so you can just as well use that box to build binary packages.

[boomboomsubban]

It can help by letting you offload the work to something like a vps, which also negates the compile/build time.

[chrisper]

Debian doesn't always just work, because a lot of packages are very old. I think Ubuntu is (or is supposed to be) more "just works." But I think this is a personal point of view thing.

Also I think the FreeBSD handbook is awesome, even for newcomers. Is there something like that for Debian?

[junk_disposal]

>Debian doesn't always just work, because a lot of packages are very old.

If you need new packages, you don't run stable.

You run stable if you need things, well, stable and "just works".

[chrisper]

My point is that Debian does not always just work. That is my argument. It very well may "just work" in your use case, but it doesn't "just work" for all cases like your original comment seem to point out.

Also, there is a difference between new, like bleeding edge (e.g. Fedora), or newer (like Ubuntu or Debian Testing).

I don't know if *BSD "just works" either, but that is not what I am arguing here. I am making a point against your statement that Debian "just works."

[fictioncircle]

https://debian-handbook.info/browse/stable/

https://www.debian.org/doc/books#english