Hi gang,
I've been using FreeBSD since February or March of this year and from the very start I got that strong feeling of satisfaction from it. My all-time favourite Unix environment is Sun Solaris, even though I'll most likely never use it again. But ever since I started using FreeBSD it gave me that same feeling of satisfaction.
Alas; this week (last night at the time of writing) I actually reached a point where satisfaction became pure excitement, and me getting excited over an operating system has only happened to me once so far. Last night I build my own kernel to include some specific features (see below) and managed to get FreeBSD to provide me with the exact same feature set which I came to love and respect from Sun Solaris 10.
Now; a long time ago (2005/2006) I ranted on a (now non-existing) Sun forum about 10 points where I considered Sun Solaris to be superior to GNU/Linux in general. I think you'll see where this is going; now I'd like to redo the whole thing again, only this time focussing on my current preferred Unix (-like) operating system: FreeBSD.
In a total random order but still trying to go from easy to more advanced issues. I split the list over two parts because it didn't fit
1 - Separation between base and ports
On FreeBSD we have a base system which is completely 'standalone' (no specific dependencies) while all the software we want to use (think Apache, GnuPG, MySQL, PostgreSQL) sits in a specific location (/usr/local). This also means that updating these two components can be done completely independently.
On Linux you basically have a complete mixture, and the only real separation you'll get is between the kernel and the userland programs (to some extent anyway).
I consider this an advantage because on FreeBSD it can never ever happen that programs such as getty stop working (or get removed) because one of the libraries it depends on got accidentally removed or replaced. The other advantage is that you can also make a clear separation between 'regular' updates (the ports collection; so software as Apache, PHP, MySQL) and 'critical' updates (the base system itself; which also includes the kernel).
2 - Good documentation and consistency
We all know the FreeBSD handbook I hope? Now, the thing is; this handbook is mostly aimed at end-users (meaning so much that it explains the overall functionality of the operating system). It's (very) good; but there is more to FreeBSD than the base system alone.
What if you want to get involved with the ports or become a FreeBSD developer? Well, then you might like the Porters handbook or the Developers handbook.
What if you want to get your hands on this documentation so that you don't need the Internet but can use an intranet (or your local host) instead? Then you might like textproc/docproj.
Linux? Let's say you want to compile the Linux kernel, and to make sure to prepare yourself you go over to the Linux kernel documentation. I really don't care why Mr. Torvalds created Git when all I want to know is how to compile the Linux kernel. And well; clicking Documentation but only to end up with a huge list of files and directories, where you actually have to search for the things you want to know doesn't quite compare to this. Chapter 9.5 of the handbook: completely devoted to the primary steps to take in order to compile your kernel.
(Yes, I know that all it takes is to get the source, set up the links, go to /usr/src/linux and run
About that consistency?
Just compare the tty(1) manual page for FreeBSD and the Debian TTY manual page. In case you don't want to click links, from the Debian manual page:
Why do they want me to use two documentation systems?
3 - Better portable kernel configuration
So I've set up four servers which hardware is quite similar but there are still a few differences. Long story cut short: I want to compile my kernel on all servers, and have determined that I can share the configuration quite easily.
On FreeBSD you get the source, go to /usr/src/sys/$architecture/conf and can build your own configuration based on one already available, usually GENERIC. Better yet: copy GENERIC to a different directory and optional name, create a (new) link in the original directory, and simply address your configuration as normal.
Even better: copy this file to your other servers, follow the same procedure regarding linking, and enjoy.
On Linux this works differently. In all honesty: I think their configuration system has many strong points and is better accessible. Being able to run
Just too bad that the eventual configuration file ends up being called .config. It's but a detail, but a hidden file? I don't consider this to be easily portable to be honest. Or what to think about the ability to use multiple configuration settings? It's doable, but not as easily done by merely using one specific build parameter (such as KERNCONF).
4 - Advanced security
Simple example: how to protect single user mode (console)? On Linux they simply devised a scheme where getty starts sulogin (see /etc/inittab).
FreeBSD? I can set this up by merely marking console as insecure in /etc/ttys. And it doesn't stop there either: by marking other terminals as insecure you can even lock out root logins altogether, on a per-terminal basis.
Totally unfair sneer (to some extend anyway): Am I the only one who gets a weird idea about NSA SELinux Support these days?
But speaking of which; on FreeBSD one can apply limits on individual users, processes, even whole jails. That fine grained access is simply not possible with SELinux (which can be compared to the user limitations as defined by /etc/login.conf where limitations are applied per user class).
5 - Extensive filesystems
For many years some people kept mocking Solaris by naming it "Slowaris", this sneer originated from the earlier versions where the system did not optimize itself for the environment on which it was used. This is also one of the reasons why many so called "professionals" will easily claim that the UFS filesystem as it was used on Solaris ("SunOS" back then) did not support journaling. While in fact it actually did; just not out of the box (you had to turn it on yourself).
I've seen too many (Solaris) examples where people tuned UFS to such extents that it could actually outperform a Linux powered computer using the ext3 filesystem, although the Linux computer had much higher specs. Keep in mind: I'm talking 2004-2005 here. In my opinion UFS is a file system which way too many people heavily underestimate.
And well, then there's ZFS which I personally consider to be superior by design
6 - Fine-grained update control
Applying an update on Linux is basically replacing the currently installed packages with new ones. So what if you want the previous one back? Another issue is that kernel updates are treated the same as updates to, say, Apache or MySQL. Even though the impact can be much heavier. Of course it does provide you with options to manually select which packages you (don't) want to upgrade but depending on the system you use you'll more than often run into dependency issues.
Focussing on the FreeBSD base system: freebsd-update can take care of several parts of your system. By editing /etc/freebsd-upgrade.conf you can start by selecting the main components (src, world and kernel). But what if you need more control?
Then you can select sub-components. Say you're a game lover; you might fancy only keeping world/games up to date, so that you can always enjoy the latest fortune for example A bit more seriously: all major components can be divided into sub-components. Do you only want the kernel source to be kept up to date for example? Use src/kernel. Only the rescue system? Should be world/rescue.
And as if this wasn't enough, you can even take it one step further and go straight to the source, which is what I've been experimenting with. Either use the source code which was initially installed with your FreeBSD version or grab devel/subversion and check out the latest release (for example as explained in the Handbook).
Oh, and about those previous packages? Because your ports collection is maintained by Subversion you can easily roll back one component (or the whole tree) to a previous release, thus allowing you to build it. But of course that's doing it the hard way: have you ever looked into /usr/ports/distfiles?
Edit: fixed tags.
I've been using FreeBSD since February or March of this year and from the very start I got that strong feeling of satisfaction from it. My all-time favourite Unix environment is Sun Solaris, even though I'll most likely never use it again. But ever since I started using FreeBSD it gave me that same feeling of satisfaction.
Alas; this week (last night at the time of writing) I actually reached a point where satisfaction became pure excitement, and me getting excited over an operating system has only happened to me once so far. Last night I build my own kernel to include some specific features (see below) and managed to get FreeBSD to provide me with the exact same feature set which I came to love and respect from Sun Solaris 10.
Now; a long time ago (2005/2006) I ranted on a (now non-existing) Sun forum about 10 points where I considered Sun Solaris to be superior to GNU/Linux in general. I think you'll see where this is going; now I'd like to redo the whole thing again, only this time focussing on my current preferred Unix (-like) operating system: FreeBSD.
In a total random order but still trying to go from easy to more advanced issues. I split the list over two parts because it didn't fit
1 - Separation between base and ports
On FreeBSD we have a base system which is completely 'standalone' (no specific dependencies) while all the software we want to use (think Apache, GnuPG, MySQL, PostgreSQL) sits in a specific location (/usr/local). This also means that updating these two components can be done completely independently.
On Linux you basically have a complete mixture, and the only real separation you'll get is between the kernel and the userland programs (to some extent anyway).
I consider this an advantage because on FreeBSD it can never ever happen that programs such as getty stop working (or get removed) because one of the libraries it depends on got accidentally removed or replaced. The other advantage is that you can also make a clear separation between 'regular' updates (the ports collection; so software as Apache, PHP, MySQL) and 'critical' updates (the base system itself; which also includes the kernel).
2 - Good documentation and consistency
We all know the FreeBSD handbook I hope? Now, the thing is; this handbook is mostly aimed at end-users (meaning so much that it explains the overall functionality of the operating system). It's (very) good; but there is more to FreeBSD than the base system alone.
What if you want to get involved with the ports or become a FreeBSD developer? Well, then you might like the Porters handbook or the Developers handbook.
What if you want to get your hands on this documentation so that you don't need the Internet but can use an intranet (or your local host) instead? Then you might like textproc/docproj.
Linux? Let's say you want to compile the Linux kernel, and to make sure to prepare yourself you go over to the Linux kernel documentation. I really don't care why Mr. Torvalds created Git when all I want to know is how to compile the Linux kernel. And well; clicking Documentation but only to end up with a huge list of files and directories, where you actually have to search for the things you want to know doesn't quite compare to this. Chapter 9.5 of the handbook: completely devoted to the primary steps to take in order to compile your kernel.
(Yes, I know that all it takes is to get the source, set up the links, go to /usr/src/linux and run
# make menuconfig
or one of its variants, that's really not the point here.)About that consistency?
Just compare the tty(1) manual page for FreeBSD and the Debian TTY manual page. In case you don't want to click links, from the Debian manual page:
Code:
SEE ALSO
The full documentation for tty is maintained as a Texinfo manual. If
the info and tty programs are properly installed at your site, the com-
mand
info coreutils 'tty invocation'
should give you access to the complete manual.
3 - Better portable kernel configuration
So I've set up four servers which hardware is quite similar but there are still a few differences. Long story cut short: I want to compile my kernel on all servers, and have determined that I can share the configuration quite easily.
On FreeBSD you get the source, go to /usr/src/sys/$architecture/conf and can build your own configuration based on one already available, usually GENERIC. Better yet: copy GENERIC to a different directory and optional name, create a (new) link in the original directory, and simply address your configuration as normal.
Even better: copy this file to your other servers, follow the same procedure regarding linking, and enjoy.
On Linux this works differently. In all honesty: I think their configuration system has many strong points and is better accessible. Being able to run
# make menuconfig
after which you can configure your kernel interactively is definitely a very user friendly option. And to include options for the X environment as well is simply very slick.Just too bad that the eventual configuration file ends up being called .config. It's but a detail, but a hidden file? I don't consider this to be easily portable to be honest. Or what to think about the ability to use multiple configuration settings? It's doable, but not as easily done by merely using one specific build parameter (such as KERNCONF).
4 - Advanced security
Simple example: how to protect single user mode (console)? On Linux they simply devised a scheme where getty starts sulogin (see /etc/inittab).
FreeBSD? I can set this up by merely marking console as insecure in /etc/ttys. And it doesn't stop there either: by marking other terminals as insecure you can even lock out root logins altogether, on a per-terminal basis.
Totally unfair sneer (to some extend anyway): Am I the only one who gets a weird idea about NSA SELinux Support these days?
But speaking of which; on FreeBSD one can apply limits on individual users, processes, even whole jails. That fine grained access is simply not possible with SELinux (which can be compared to the user limitations as defined by /etc/login.conf where limitations are applied per user class).
5 - Extensive filesystems
For many years some people kept mocking Solaris by naming it "Slowaris", this sneer originated from the earlier versions where the system did not optimize itself for the environment on which it was used. This is also one of the reasons why many so called "professionals" will easily claim that the UFS filesystem as it was used on Solaris ("SunOS" back then) did not support journaling. While in fact it actually did; just not out of the box (you had to turn it on yourself).
I've seen too many (Solaris) examples where people tuned UFS to such extents that it could actually outperform a Linux powered computer using the ext3 filesystem, although the Linux computer had much higher specs. Keep in mind: I'm talking 2004-2005 here. In my opinion UFS is a file system which way too many people heavily underestimate.
And well, then there's ZFS which I personally consider to be superior by design
6 - Fine-grained update control
Applying an update on Linux is basically replacing the currently installed packages with new ones. So what if you want the previous one back? Another issue is that kernel updates are treated the same as updates to, say, Apache or MySQL. Even though the impact can be much heavier. Of course it does provide you with options to manually select which packages you (don't) want to upgrade but depending on the system you use you'll more than often run into dependency issues.
Focussing on the FreeBSD base system: freebsd-update can take care of several parts of your system. By editing /etc/freebsd-upgrade.conf you can start by selecting the main components (src, world and kernel). But what if you need more control?
Then you can select sub-components. Say you're a game lover; you might fancy only keeping world/games up to date, so that you can always enjoy the latest fortune for example A bit more seriously: all major components can be divided into sub-components. Do you only want the kernel source to be kept up to date for example? Use src/kernel. Only the rescue system? Should be world/rescue.
And as if this wasn't enough, you can even take it one step further and go straight to the source, which is what I've been experimenting with. Either use the source code which was initially installed with your FreeBSD version or grab devel/subversion and check out the latest release (for example as explained in the Handbook).
Oh, and about those previous packages? Because your ports collection is maintained by Subversion you can easily roll back one component (or the whole tree) to a previous release, thus allowing you to build it. But of course that's doing it the hard way: have you ever looked into /usr/ports/distfiles?
Edit: fixed tags.