ananm1 said:
What is your favorite aspect or feature of FreeBSD? Is there anything you would change?
Like many other posters I have several features which almost immediately drew me right in..
Acts and feels like a Unix system
The most important thing to know about Unix, in my opinion, isn't so much how everything works but the way you can find out about it. The hierarchy, the manual page structure (and their contents) and most importantly: they way all that is executed. That is in my opinion an excellent aspect.
Put differently: I could easily stop using FreeBSD for one or two years, thus totally forgetting about all the specific tricks. And easily find them again the very moment I'm back behind the console.
For example; I want to know about bootstrapping my system but I forgot all about
gpart. Of course I do recall
fdisk but that's more PC oriented. So when I use
$ apropos bootstrap I get to see this:
Code:
smtp2:/home/peter $ apropos bootstrap
boot(8) - system bootstrapping procedures
bootptab(5) - Internet Bootstrap Protocol server database
loader(8) - kernel bootstrapping final stage
loader.conf(5) - system bootstrap configuration information
ExtUtils::Mkbootstrap(3) - make a bootstrap file for use by DynaLoader
So if I then check out the
boot(8) manualpage I get this important part at the end:
Code:
[B]SEE ALSO[/B]
ddb(4), boot.config(5), make.conf(5), ttys(5), boot0cfg(8), [I]bsdlabel(8)[/I],
btxld(8), config(8), halt(8), loader(8), nextboot(8), reboot(8),
shutdown(8)
And based on my experience
bsdlabel() would be more than enough to catch my attention. And its "SEE ALSO" block will then directly point me to both
fdisk(8) and
gpart(8). And this is but one example, there is so much more where this came from.
It's this consistency which also immediately made me embrace Solaris/x86 when it first got out, even though it didn't ran as smoothly as Linux did back then. If you knew your way around Solaris on a Sparcstation and were put behind a Solaris 10 console (without any prior knowledge on ZFS or Zones and such) you'd still have all the options at your disposal to learn about those.
Strict separation between Ports and base system
I'm sure its something most FreeBSD users take for granted, but with a very deep Linux history I can tell that from this perspective it's an
invaluable feature. Sure; Linux also bootstraps the kernel though a bootloader, control then eventually gets transferred to init and then your system starts.
But here's the problem...
Code:
root@debian:~# dpkg-query `which getty`
util-linux: /sbin/getty
root@debian:~# dpkg -p util-linux | grep Depends
Depends: lsb-base (>=3.0-6), tzdata (>=2006c-2), initscripts, dpkg (>=1.15.4) | install-info, debconf (>= 0.5) | debconf-2.0
Pre-Depends: libblkid1 (>=2.17.2), libc (>= 2.11), libncurses5 (>= 5.7+20100313), libselinux1 (>= 1.32), libslang2 (>= 2.0.7-1), libuuid1 (>= 2.16), zlib1g (>= 1:1.1.4)
Do you see
libc up there? Its a common library which is used by many programs on your system. So what would happen if a package would depend on another version of the
libc6 package which can't co-exist with this one? Or for that matter any of the other dependencies listed above..
Then you'd risk
getty not working any longer thus effectively making it impossible to logon to your system.
Now, obviously it's not something which happens all the time on Linux, nor should it be used as an argument as to why one OS (or package environment) would be better than the other. That's bollocks because although the risk is real, its something which hardly happens. But during upgrades this becomes a very potential issue which is more than often waved away with "
Then you're better of with a clean install".
Ports
For years it always felt like a waste of time to me: compiling your own programs while you could easily grab a binary package and be done with it. Ever since I started doing it myself I had to re-adjust that opinion quite drastically (180 degree turn).
Apart from the previous (related) reason there's more to Ports. It doesn't provide software, it provides a means to install and use software whereas a common Linux environment provides software, with several risks attached.
On Linux you're not putting trust in the distribution, but in the dozens of package maintainers. Most of those will change the way a software package works in order to make it "fit in" with the distribution. This is why configuring Apache on Debian will be a completely different experience than doing the same on SuSE.
But there's more.. Maintainers will also easily change the way the software works if they deem it required to be used on the distribution. And because you're using binary packages chances are high that you won't be (able to) seeing what has changed and why. Sure; sometimes you get a file explaining the build options, that's hardly enough.
Take for example the
Debian OpenSSL disaster (link to Slashdot, not my favourite resource but its a good one for this due to the comment section). This disaster even went as far as big names like GoDaddy (which I hold in good esteem for certificates and domain registrations) revoking and re-issuing
all certificates which had been created for use on a Linux / Apache environment.
And all because one package maintainer thought he knew better and changed the package to make it more "suitable".
Sure; on Ports there are also changes (patches) being applied, but I have full access to the patches up front. I can see
exactly what is or isn't being done. Most of all; because it grabs the original tarballs there's nothing stopping me from compiling and setting up the whole thing myself if I'd really insist on that (which is bad practice, but simply as an example..).
And that's my top 3
