• This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn more.

FreeBSD vs. Linux: 10 points of superiority (including motiv)

ShelLuser

Daemon

Thanks: 806
Messages: 2,014

#1
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 # 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.
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 # 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.
 

ShelLuser

Daemon

Thanks: 806
Messages: 2,014

#2
7 - Backwards compatibility

Developing new features and such is really a good thing. But it can become cumbersome if you simply build something new and then throw the old stuff away, which is what many Linux environments tend to do (but in all fairness: also many open source projects as a whole). For example; why do we need several versions of the Berkeley database installed on one system?

Solaris was a master in backwards compatibility, but one could also argue that they overdid it a little bit. Even so, it's what I consider to be the "Unix methodology": instead of replacing something in its entirety try extending on it while keeping the original functionality intact. That way you can ensure that even older software can still run on your modern environment.

It's for this reason why you'll find this in a common FreeBSD kernel configuration:

Code:
options         COMPAT_FREEBSD32        # Compatible with i386 binaries
options         COMPAT_FREEBSD4         # Compatible with FreeBSD4
options         COMPAT_FREEBSD5         # Compatible with FreeBSD5
options         COMPAT_FREEBSD6         # Compatible with FreeBSD6
options         COMPAT_FREEBSD7         # Compatible with FreeBSD7
Or what to think about building your own kernel using the previously mentioned source code?

According to the developers handbook there are two options; the traditional one and the "new" way. Guess what? The traditionally used program config(8) still exists today.

Another example would be pkgng in comparison to the traditional pkg_* set of tools.

Linux on the other hand has a long history of being plagued with replacements, or removed API's for no other reason than a programmer who wasn't satisfied any more with the way things worked.

This development is even strongly enhanced with all the different distributions out there. Most of them are not compatible; a package made for SuSE will have major issues on CentOS even though they both use the RPM package manager. But a package made for an older version of SuSE will most likely (though not always!) also have major issues when being run on a modern version.

A general argument is: "Get the source, compile it and be done with it". Sure. But what if specific APIs in the kernel suddenly drastically change, which has happened in the past (though it never bothered me directly)?

When looking at Linux then most people don't see the need nor really want to bother. But it's this aspect which can make an operating system more mature. In my personal opinion of course.

8 - Better (easier) customization

I'm using a customized kernel, so what to do when there are new updates to the kernel made available? Well, that entirely depends on you. As I mentioned in point 6 you have complete control over the way you update your system. As such I can tell it to update the source code and world (binaries of the base system) and leave my kernel alone; as soon as the system has been updated I can then proceed to (re)build the new kernel.

And that same control can be found in the ports collection. Because we're dealing with a "Makefile structure" you can put a lot of options in your /etc/make.conf after which you don't have to remember them whenever you're installing updates from your ports collection.

For example:

Code:
# Pre-define Apache's suexec root directory
SUEXEC_DOCROOT=/home

# VIM configuration
VIM_PORT_SCRIPT_LANGS="lua perl python"

# Disable use of X.org
WITHOUT_X11=yes

# Kernel build options
KERNCONF=SMTP2
MODULES_OVERRIDE=nullfs zfs opensolaris ipfilter
This makes sure that Apache plays nice with my admin panel (Webmin), that Vim is built with only a small subset of the languages which it supports, obviously I don't need the X window environment on my server and finally one can even put specific kernel build options in here so that the only thing you need to do after updating the source code is simply to build the kernel (using # make buildkernel for example).

On Linux it can get awkward. Let's say you build your own kernel and to make sure you fully played by the rules also build a full package from it. Now your kernel is indeed fully manageable. Because you have no need for the previous (more 'generic') kernel you simply remove that package and all is right with the system. Or is it?

How exactly are you going to keep up with kernel updates? Because you can rest assured that your custom built kernel package will never get any updates through the official channels. And because you have removed the other, official, kernel package you also won't be notified if that receives any new updates. Well, actually, you will be 'notified' but since it sits together with thousands of other packages it simply gets lost in the masses. Unless you separately start to look out for it of course.

But wouldn't that become a bit more tedious? What do you say; follow the official kernel release, as mentioned on the Linux kernel website? Sure. But you do realize that when a new Linux kernel is released it won't be instantly available on the several distributions? You'll still need several days of monitoring.

As such most people simply build their own kernel, don't remove the generic one from the package system, and then maintain several versions. (Which, in all honesty, isn't a bad idea at all. But it could be done a little more optimally).

And it becomes yet another story when you build your own software packages. Because you can't easily apply settings which you already had to a new version. In general (but here's looking at Debian in particular) you grab a source package, re-configure that and then build stuff. So effectively copying (parts of) configuration files which you previously made.

I don't think I have to tell you; but it's no fun to copy snippets of a 12 KB long configuration file.

9 - Jails

Now, I'm well aware that Linux also provides several options for virtualization using the Kernel Based Virtual Machine (KVM). But in all honesty; it's not something exclusive to Linux. You can even easily run KVM on FreeBSD as well. All it takes is basically emulators/kqemu-kmod and emulators/qemu.

A small sidestep; that link is another classic example as to the maturity of documentation related to some Linux (-based) projects. Why would you update your ports collection if you're going to rely on binary packages?

The reason why I consider jails to be superior is simply due to the way the environment is set up. I don't need any extra binaries or utilities. In fact; the only thing I need is to setup a userland structure, and I can easily do that by either compiling the world (from /usr/src) or by using a binary release through bsdinstall.

But all the utilities I'd need (here's looking at jail and jexec for example) are already provided by the base system. Jails work "out of the box" so to speak.

10 - The community

Last but most certainly not least. I think the community, in general, is much more enjoyable. That could also have something to do with the fact that FreeBSD isn't as mainstream as Linux is, or maybe with the strict (but just! ;)) way this forum is being maintained, but to be very honest I think it's none of the above.

Even if you check out the mailing lists (I've been lurking on the ports list for quite a while now because I'm preparing a port of my own) you'll find the same motivated, friendly and helpful people whom you can also find around these parts.

And that is a give and take kind of situation I think. For example, although I also enjoy working with Windows I'm much more motivated to help out and report oddities when it comes to FreeBSD than if it comes to Windows. Partly because the whole approach is different (I paid for my Windows licenses after all) but also because you can expect much more feedback from these parts.

That experience is, in my opinion, also a very important aspect to that which is FreeBSD.

And there you have it. 10 points where I consider FreeBSD to be superior in comparison to Linux.

Please keep in mind that this is all my opinion only. I'm not stating nor claiming that FreeBSD is superior to Linux in any way, shape or form, because those are claims I honestly can't make.

But I will say that it sure reflects the way I personally think about all this.

Edit: fixed tags
 

SirDice

Administrator
Staff member
Administrator
Moderator

Thanks: 5,508
Messages: 25,688

#5
ShelLuser said:
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.
For the past decade or so I've been using the following strategy: I choose the fastest, heaviest machine I have to do the building. Create kernel configurations for all your machines. Do the 'regular' make buildworld. Edit /etc/make.conf and set KERNCONF:
Code:
KERNCONF=GENERIC MOLLY MAELCUM CORTO
You can set multiple kernel configurations, all of them will be built with a single make buildkernel. The first one on the list is the one that gets installed with make installkernel but you can override it by setting KERNCONF on the commandline, i.e. make installkernel KERNCONF=MYKERNEL. NFS export /usr/src/ and /usr/obj/, this can be done read-only. When the 'build' server is done with build(world|kernel) mount /usr/src/ and /usr/obj/ on your other servers and run install(world|kernel) there. The installworld will be a little slower over NFS but it will work like a charm. At least you don't have to wait several hours on slow machines for buildworld to complete. And you only have to wait once for it to complete. Make sure your clocks are synced though, I've had some weird errors when one of the clocks was a bit off the mark.
 

germanopratin

Member

Thanks: 8
Messages: 20

#7
ShelLuser said:
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.
You are lucky and I envy you, because I am still in the process of fighting with the system. And there's always the "danger" of falling back to my Slackware. :)

I like this thread. It's always fun to compare Unix systems or (as for Linux) clones.

The separation between userland and system is a big advantage over Linux. Agreed. In a way the Linux chaos has its point, too. But it's clear that FreeBSD is more stable and clean in this respect. As you mention getty, well, in Linux there is a host of gettys at the moment. And things can break because of what you point out. Though, it never happened to me with Slackware. Maybe because Slackware tries to be the BSD of the Linux world.

Man and Info: 100% agreed. I never liked info. It's GNU overkill. And I don't want to learn another help system. You can't claim that your OS is UNIX and then provide silly man stub pages. Stick to man and make it well! But let me say that not all FreeBSD man pages are totally satisfying. A couple of days ago I read the Vi man page, which is too small. And not all man pages have examples, whereas according to the stated FreeBSD policy they ought to. But apart from that: yes, documentation seems to be superior to Linux. Especially in Slackware Linux it's just awful.

Ad user limits: Yep, that is just astounding. It lets you set stack space and things. I like that! As I don't employ a server I don't need this feature but this is impressive.

One thing that sucks with security is that Xserver blows securelevels. That's terrible. The FreeBSD security team devised such a great security system - and X just blows it. But of course, it is X that is to blame. Time for a new graphics system. OK, I don't have a server. With a server you don't have that GUI and X problem. But I want to run [size=-1][Free?][/size]BSD on my workstation. I was excited when I got to know securelevels - and then disappointed when I found out that X won't let you apply them.

Backwards compatibility: Good point. One of the major downsides of Linux. And it is getting worse and worse. Many Linux people sport this attitude of fast paced change and innovation. There are conservative distributions like Slackware. But the majority seems to be infected by that very same attitude that plagues Windows users. Change things, just for the sake of changing. Even if things break, or you are left with less than before. Move on. I also never understood the concept of "bleeding edge" many Linux distributions and users are so keen on. What's the point in having a new version of sed or Vim or whatever? There are only a few pieces of software that really merit regular updates. For the major part it is just pointless.

Kernel updates: Hm, I don't think that most Linux users do make their own kernels. I guess that changed. It's a big problem that many distributions ship with costumized kernels. If you compile your own kernel you will be left to your own devices.

Community: Again, I can only speak of the Slackware community. I think they are nice guys, too. And I also guess that with Slackware there is an older and more experienced community.

But speaking of Ubuntu or else, there's often a lower level of sophistication. It seems to me that the BSD communities are on a higher technical level than Linux in general, speaking of technical sophistication, which might stem, in large parts, from the UNIX heritage.

What strikes me is the many threads about servers. Is it still the case that the majority of BSD users are server admins???

Thanks for your great posts! A lot of things I don't know well enough and would like to check out. I really like threads like that because they are a good way to find a decision on which system to use, and they can give you a better grounded opinion on systems.
 

fonz

Son of Beastie

Thanks: 366
Messages: 2,562

#8
germanopratin said:
Man and Info: 100% agreed. I never liked info. It's GNU overkill. And I don't want to learn another help system.
To some extent I agree. In and by itself I think GNU Info isn't that bad an idea, at least it offers navigation between sections, subsections etc. Take the Vi example you mentioned (although there are plenty of other examples). Putting everything into one big-ass man page probably wouldn't improve ease of reading. What's more, when it comes to something like GNU Make, the documentation is so extensive that I rather like being able to navigate through it. On the downside, it is indeed Yet Another Documentation System adding nothing that can't be done by, say, HTML documentation.

germanopratin said:
One thing that sucks with security is that Xserver blows securelevels. That's terrible.
Agreed. If you are running X, you can't raise kern.securelevel beyond 0. I'm not sure how much effort it would take to adapt X.Org to this, but judging by how long this "problem" has been around (it applied to X.Org's predecessor XFree86 too) my money is on "it would be one royal pain in the patootie".

germanopratin said:
Community: Again, I can only speak of the Slackware community. I think they are nice guys, too. And I also guess that with Slackware there is an older and more experienced community.
My experience is that Linux communities differ significantly between distrubutions. The Slackware community is indeed one of the more pleasant and more mature ones. This may have something to do with Slackware having a bit more of a do-it-yourself-and-use-the-command-line attitude, which I presume keeps a lot of wannabes out. You know, the kiddies who answer every question with "With Ubtuntu, bla bla bla" no matter how explicitly, CAPITALISED, BOLD and [red]RED[/red] you say you are using <insert something other than Ubuntu>.
 

germanopratin

Member

Thanks: 8
Messages: 20

#9
Point #11

This is really special and of no importance, but let me point out another difference:

Some years ago, I read Kernighan/Pike's "The UNIX Programming Environment" and tried a lot of examples. What excited me was the possibility to octal dump directly into the directory structure. So I tried it out on Linux. This is what I got:
Code:
[CMD=bash-4.1#]od .[/CMD]
od: .: read error: Is a directory
0000000
[CMD=bash-4.1#]wtf!?!?![/CMD]
bash: !?!?: event not found
So, that's annoying. Try this with FreeBSD 9.0 - and this little example of 1984 (!) still works as expected. OK, this is not a key selling point *g* I know, but I like that. Sometimes it's these little things that matter, too.

GP
 

germanopratin

Member

Thanks: 8
Messages: 20

#10
@fonz: Yes, you are right, too. Maybe man is difficult to handle when it comes to huge files. But sometimes they even force you to read info for small files. I don't know. I guess it's more of an emotional objection for an otherwise pretty good system. I like man. Probably it's retro nostalgia :)

Yes, what can you do about X. The handbook says something about XDM. But I don't use XDM. Real men use startx ;-) Just kiddin

It's a problem. We should be grateful for X anyway. But it would be even more awesome if some aspects of the system could be modified, especially as for listening to outbound TCP connections and requiring root privileges.

Some Linux communities are really like Windows communities. "How to change volume?" "How to config Firefox?" I don't want to bash them. It's okay. Windows is okay, too, with me. But when you stick to that level you miss the great thing about UNIX, which is that you are forced to learn a lot. Whereas Windows dumbs you down. Again, this is fine when you don't want to learn. But it is dreadful when such a system insinuates that there ARE no things to learn, even if you would like to.

Anyway, I prefer more technical (or "philosophical") discussions, even though I have to admit that the level of technicality here is FAR above my own level of knowledge.
 
Last edited by a moderator:

ShelLuser

Daemon

Thanks: 806
Messages: 2,014

#11
fonz said:
In and by itself I think GNU Info isn't that bad an idea, at least it offers navigation between sections, subsections etc. Take the Vi example you mentioned (although there are plenty of other examples). Putting everything into one big-ass man page probably wouldn't improve ease of reading.
True, but it does improve the ability to look things up while reading (provided you know your way around, more or less ;)).

It's happened to me several times that I tried to construct a commandline and wanted to know more about a specific option. For example; when looking at zfs create you'll have a reference which tells you that you can set a property by using -o. And if I reached that point in my commandline I might want to look through the list of properties.

In this particular example I can simply type ? properties (after which you might need to press n a few times) and eventually I'll reach the list. I like that better than having to go through several sections and chapters to find what I'm looking for. Also because I'm already quite familiar with the way more or less works (more or less ;)).

Which is what has always annoyed me a little: the completely different set of keys to use. Top nodes, directory nodes, going up, going to the previous node of the node... I simply don't like it, I always end up somewhat confused and pressing the wrong keys.

And I also don't like the search feature. Basically you keep pressing s and enter to go to the next result, because it's much quicker than control-x n. I prefer things easy; using / to start the search and then using n for the next result.

(but then again; I am lazy).

fonz said:
You know, the kiddies who answer every question with "With Ubtuntu, bla bla bla" no matter how explicitly, CAPITALISED, BOLD and [red]RED[/red] you say you are using <insert something other than Ubuntu>.
That's because Ubuntu contains the universal answer. Best of all; it can do most things for you so there's no need to trouble yourself with questions any longer ;)

But yeah, I fully agree (though I never used Slackware but can still relate to this).
 

kpa

Beastie's Twin

Thanks: 1,673
Messages: 6,084

#12
fonz said:
To some extent I agree. In and by itself I think GNU Info isn't that bad an idea, at least it offers navigation between sections, subsections etc. Take the Vi example you mentioned (although there are plenty of other examples). Putting everything into one big-ass man page probably wouldn't improve ease of reading. What's more, when it comes to something like GNU Make, the documentation is so extensive that I rather like being able to navigate through it. On the downside, it is indeed Yet Another Documentation System adding nothing that can't be done by, say, HTML documentation.
I have always had nothing but hatred towards the GNU Info system, it is hypertext done wrong from the very beginning. It should die out and be replaced with something that is human readable in source form and can be transformed to various output formats (HTML, ascii, younameit) easily. One good candidate for replacement is textproc/asciidoc.
 

CurlyTheStooge

Member

Thanks: 12
Messages: 79

#13
Though I don't use FreeBSD as my main operating system, I always keep the *BSDs in high regard because of their legacy. May be its something to do with me being a Slackware user (albeit a younger one), who with time learned to respect the *BSD approach by hanging around learning from old folks, reading and relying on D.I.Y system.
The only gripe with Slackware Linux is scarcity and age of the official documents but nothing show stopper.

Regards.
 

jb_fvwm2

Daemon

Thanks: 171
Messages: 1,672

#14
I, for one, am slightly worried that FreeBSD continues staying *fixable* much more than Linux appears to be (from what I read daily in a linux forum...) ... for instance, I've been trying this-and-that all without success to update perl-5.12.5 to perl-5.14.4, and pkg_which && xargs in a long pipe, which never failed before, suddenly has returned a "?" meaning it does not know the package by which the older files Socket.pm (etc) were installed. By chance just then, this is working at least for the vast majority of the upgrade, vs. what I posted in the scripts thread, this one is completing without intervention and twice as speedily (so far). But maybe someone reading this thread, who is already running pkg and does not have /var/db/pkg subdirectories any longer, could verify an equivalent command working with the soon-default or soon-common package tools. (Maybe it could even be put in UPDATING as a method of perl-after-upgrade (etc.) if it works as well for others as it does here, at least in this instance.).
Sorry for the limited testing so far. (And typos. And additional port or two...)
Code:
#/# find /var/db/pkg -type d -name "p5*" | xargs -J % find -type f -name "+CONTENTS" -exec grep -H "5.12" {} \; | grep pm | gtr -s \/ "\n" | grep p5 | sort | uniq | xargs -J % portmaster -d -B -P -i -g % && yell || yell
 

steveh

New Member

Thanks: 4
Messages: 10

#15
Indeed a good read.

One thing I would say is with regards custom kernel configs we used to copy and then modify generic but we now have:-
1. A "clean" config which includes GENERIC and then removes all the devices and options we don't use across the farm.
2. Multiple custom configs which include the "clean" config customizing to individual requirements.

We find this better as its generally easier to upgrade this layout to newer releases than having to edit each individual custom config.

Hope this helps.
 

Vamp898

New Member

Thanks: 2
Messages: 1

#16
I really hate to be the bad guy, but actually most of these points are not valid with real Linux Systems (best example is Gentoo)

1 - Separation between base and ports
This exists in Gentoo

There is a Set Called "system" and everything else is in @world. But this is made even more elegant as in the world, only the packages you really installed (not the dependencies) are listed there. You can copy the world from one system to another, run an update and they have the identical set of packages installed (no influence on system at all).

So comparing FreeBSD to Gentoo I'd say that Gentoo is even more advanced in this aspect (not just because the example mentioned above)

2 - Good documentation and consistency
I think the FreeBSD Handbook is one thing that really doesn't exist in the Linux world. But also it is mainly aimed at beginners, for reference there are faster ways to look up things than in the FreeBSD Handbook.

It's not as elegant, I have to admit that, but I'm fine to give newbies the Debian Handbook (which is almost as good as FreeBSDs, just for a worse system) and if they are experienced enough they can advance with LFS. And after you have the basics, every distro have documented their distro-specific things quite well afaik.

But yes, I give this point to FreeBSD.

3 - Better portable kernel configuration
You can just link .config to whatever you want and call the config file however you want. Or you just use an modular design so you have one config for all systems, but every system only uses what it needs.

I can't really recall any real scenario where I thought "dammit, I wish Linux had a better portable kernel configuration"

4 - Advanced security
You are talking about MACs, imho tomoyo is more advanced than what FreeBSDs MACs can offer. But what about Gentoo's "Hardened" system which uses different compile flags, additional patches and so on to enhance security?

I think Advanced Security is an large topic and to deep to simply say "FreeBSD offers better advanced security". Both have their advantages and disadvantages.

5 - Extensive filesystems
Doing a lot of benchmarks on our server systems we can say that I/O (especially with Software RAID) is faster on a current Linux with ext4/btrfs than FreeBSD with UFS/ZFS.

6 - Fine-grained update control
I don't know where to start with Gentoo, but it's better in almost every aspect you can think of.

On Gentoo you can install multiple packages at a time, you can go back a lot of versions and all this is config-file controlled for "everything".

I can for example mask (block) packages like these (pseudo code)

>=apache:2.4
>=linux-kernel-3.12.0

When running an update, explicit installed packages are shown different to dependencies, i see changed compiled flags and so on in a clear and colorful overview.

There is nothing even close to that on FreeBSD.

And I can do that for every package. I get news about when things change, new config files are copied to a special place and are shown to me using diff.

If those are only additional changes, it takes my old config, adds new stuff to it and then shows me the diff and so on.

Upgrades on Gentoo are better in almost every aspect, I think that's a huge loss for FreeBSD imho.

But to be fair, FreeBSD is better than every other Distro except Gentoo (by far!). So if you are not a fan of Gentoo, this point is 100% valid.

Example found on Google

http://www.tecmint.com/wp-content/uploads/2014/06/Install-Skype-in-Gentoo-Linux-02.jpeg

7 - Backwards compatibility
I can run binaries from 1991 on my System from yesterday.

There is one big rule in the Linux Kernel Development: "Never break userspace©®™"

But this doesn't apply to every distro.

8 - Better (easier) customization
Not true compared to Gentoo, not at all.

Code:
CFLAGS="-O2 -pipe -march=native"
CXXFLAGS="${CFLAGS}"
CHOST="x86_64-pc-linux-gnu"

CPU_FLAGS_X86="aes avx fma3 fma4 mmx mmxext popcnt sse sse2 sse3 sse4_1 sse4_2 sse4a ssse3 xop"
USE="-ipv6 threads udev numa logrotate"

LINGUAS="de"
MAKEOPTS="-j24"
GRUB_PLATFORMS="pc"
FEATURES="splitdebug"
RUBY_TARGETS="ruby19"
GENTOO_MIRRORS="http://de-mirror.org/gentoo"
APACHE2_MPMS="event"
EMERGE_DEFAULT_OPTS="--with-bdeps=y"

PORTDIR="/usr/portage"
DISTDIR="${PORTDIR}/distfiles"
PKGDIR="${PORTDIR}/packages
My /etc/portage/package.use for package-specific compile-flags
Code:
app-portage/eix optimization strong-optimization strong-security
mail-mta/postfix dovecot-sasl mbox
net-mail/dovecot mbox mdbox sdbox solr sieve managesieve
app-eselect/eselect-php apache2 fpm
dev-lang/php apache2 calendar exif gd gmp imap mysql mysqli soap zip fpm pdo sockets sqlite spell curl xmlwriter
mail-client/roundcube spell sqlite vhosts
app-admin/puppet augeas diff rrdtool shadow
net-analyzer/rrdtool ruby
www-apps/owncloud vhosts
net-misc/dhcp -client
net-dns/bind -berkdb caps
sys-boot/grub -multislot
app-emulation/qemu numa spice sshusb usbredir vde
app-emulation/spice gui
app-emulation/libvirt pcap virt-network
dev-python/python-slip dbus
sys-auth/consolekit policykit
net-dns/dnsmasq conntrack dhcp-tools script
net-firewall/iptables ipv6
net-misc/asterisk dahdi http syslog vorbis
net-misc/dahdi flash
net-im/ejabberd mod_irc mod_muc mod_pubsub
Nothing on FreeBSD is even close to this.

9 - Jails
You can not run KVM on FreeBSD (proof? I tried myself, doesn't work as KVM is an Linux-Kernel Feature not ported to FreeBSD. You can only run the userspace-tools for KVM (QEMU), but not the Kernel Feature which is "the" thing.)

Also there is a competing project to jails on Linux: https://linuxcontainers.org/

10 - The community
Both have their ups and downs. I don't think there is really a difference between the communities. FreeBSD people think they are better, Linux people think they are better...

As this is an FreeBSD Board, I won't come up with the endless points against FreeBSD (which GNU/Linux Systems (especially Gentoo) does better)

But to be honest, there are some real advantages on FreeBSD, but you mist quite some of them. One of my favorites, just as an example, is PF (but that actually is an OpenBSD feature to be honest :p)

This might sound like I'm an Linux Fanboy, but actually I'm just pointing out that most things mentioned here are distro specific.

Most things apply to the way distros deliver an flavor of Linux, not the capability of the system itself.

Gentoo for example taken the ports system of FreeBSD as an base and extended it extremely. Gentoo is rather an collection of scripts to build your system than an system itself, giving you more freedom than FreeBSD ever could.

Also a lot of features are not ported back to FreeBSD just because the community didn't wanted them (but as they are awesome, an FreeBSD Fork using Gentoo (or Gentoo fork using FreeBSD Kernel?) have been created).

So comparing to Gentoo (which is an special distribution aimed as high-level experts), FreeBSD actually is lacking a lot of stuff.

I think there is a reason why so many Linux distros exist, and this reason is the same why FreeBSD exists. There is no perfect/ideal system.

If Gentoo wouldn't exist, I would most likely use FreeBSD (especially on Servers) but for me, after getting really deep into FreeBSD, there is no real reason to use FreeBSD except having fun using other systems.

But still I use FreeBSD on systems where the advantages of Gentoo are not needed (or I'm just to lazy to maintain it).

FreeBSD really is an very cool systems and nearly every point is 100% true compared to a non-Gentoo (or LFS) System. But Gentoo exists, and its goddamit awesome, so for nearly none of these points agree for me.
 

gkontos

Daemon

Thanks: 437
Messages: 2,069

#17
Yet another mine is bigger than yours thread. A real experienced Technical Architect, former sys & net admin, will choose the OS that is right for the job.
 

Oko

Daemon

Thanks: 594
Messages: 1,518

#18
Doing a lot of benchmarks on our server systems we can say that I/O (especially with Software RAID) is faster on a current Linux with ext4/btrfs than FreeBSD with UFS/ZFS.
While I find most of OP uniformed or even totally inaccurate which is to be expected as made by a total new comer (by his own admission) who has no business making such high view compassion I have to call BS on this part of your post. Ext4 is legacy file system in Linux. I should know it as we have bunch of servers in my lab running latest Red Hat 7.1 which defaults to old trusted XFS ported to Linux from IRIX by Silicon Graphics. As of BTRFS I have heard such Linux fairy tales million times over the years. Unless I see it I don't believe it. As a matter of fact I wage $100 on the spot that HAMMER2 a brain child of a single developer Matt Dillan has far greater chance to be finished than any imaginary BTRFS.

Between Gentoo is a hobby project in nobody in his right mind would use that thing on production servers.
 

Beastie7

Well-Known Member

Thanks: 88
Messages: 283

#19
The majority of points in the OP aren't even technical, but more methodical. It doesn't even scratch the surface of technical advancements and historical innovation.

Anyway, Gentoo is a toy. A mere shoehorned clone (by methodology) of disjointed parts hacked together. Is it not a base system.
 

Terry_Kennedy

Aspiring Daemon

Thanks: 253
Messages: 874

#20
Yet another mine is bigger than yours thread. A real experienced Technical Architect, former sys & net admin, will choose the OS that is right for the job.
Indeed. I made a post recently over in comp.os.vms where I said:
me said:
other user said:
VMS is better at solving VMS problems than at solving Unix problems ..
Neither of which is particularly relevant to the business community. They have business problems, not VMS or Unix problems. Most will want to solve their business problems for the smallest cost that accomplishes their goals of features / performance / security (probably in that priority). [...]
People generally stick with the system they're familiar with, until it becomes so difficult that they decide to switch to something else. Minor shortcomings are usually overlooked.

In my case, I went from 4.3BSD-Reno on a VAX to BSD/OS on i386 because 4BSD dropped VAX support in 4.4. Another programmer and I actually put most of the removed VAX stuff back into a very early build of 4.4, which we jokingly called 4.3-Carson City. When WindRiver shut down BSD/OS, the BSDi technology moved to FreeBSD and I followed along.

My opinion of Linux was formed very early on (mid-1990's) when a customer (I was head developer for an ISP at the time) complained that our newsfeed to him wasn't working. After a lot of digging around on his Linux system, I discovered that writes to stdout (when stdout was a network connection) sometimes didn't transmit all of the buffered data. Even fflush(stdout) didn't get the data sent. I reported this on the mailing list for whatever flavor of Linux the customer was using, and after dealing with some "your application must be broken" (Really? C News?) I got trapped in an infinite loop of kernel people telling me it was a libc problem, and libc people telling me it was a kernel problem.

That's why I like the FreeBSD concept of "base" - it is all one release, tested to work together as opposed to the "Chinese menu" of "one from column A, two from column B, one from column C" type of release packaging that I saw on Linux. I'm sure that bug has been fixed in the 20 years or so since I found it. Certainly a lot of embedded stuff runs Linux just fine. But I'm familiar with FreeBSD and I'll stick with it whenever it can solve whatever business problem I'm working on. I haven't had to look at anything else yet...
 

j7j3

New Member

Thanks: 6
Messages: 17

#21
Interesting read for which I gave you a thanks, but the mine vs yours debate is like a schoolyard peeing contest - pointless and can get very messy!
 

Remington

Well-Known Member

Thanks: 134
Messages: 463

#22
Vamp898... It's like comparing Mercedes-Benz and BMW. I never liked Linux for number of reasons so let's leave this thread alone as you're not going to win any arguments with predominately FreeBSD users here.

Like gkontos said, any system admin will choose any OS for the right job.
 

drhowarddrfine

Daemon

Thanks: 643
Messages: 2,401

#23
First time poster, Vamp898

Last year, I did some work for a large technology company you've heard of that had a mix of FreeBSD and Linux servers for a total of fifty or so. Most or all of the Linux servers were Gentoo. While Gentoo ran fine overall, the only issues they ever had with their operations were with the Gentoo servers and Linux overall. One year later, they started the process of switching everything over to FreeBSD because it was superior in every way and, to quote the engineering manager, "it's not Linux".

Now, I don't know cause I was a freelancer and didn't have time to pay attention, but these were pretty smart people and, if they disliked Gentoo (and Linux overall), it was enough to make me feel good about my choice and I'm positive they would like to pick apart your points and shred them to pieces.

I would be careful about doing things like deriding FreeBSD for using something from OpenBSD while praising Gentoo for using FreeBSD's port system.
 

ANOKNUSA

Aspiring Daemon

Thanks: 359
Messages: 671

#24
Vamp898, it really seems that you just signed up here to to contest the original post, and have little experience with FreeBSD. The most obvious give-away is this point--regarding Portage and USE flags, you state:

Nothing on FreeBSD is even close to this.
...where do you suppose Daniel Robbins got the idea? FreeBSD has make.conf(5) and src.conf(5).

I'll leave it at that. I understand the irony of what I'm about to say, but threads like this should be left to rot. Don't let crap like this thread bait you. People use what they like. and evangelizing, proselytizing and issuing fatwas will never change that. There's nothing wrong with preferring Gentoo, but nobody wins when all the pro-Gentoo features you list are things Robbins took directly from FreeBSD.
 

sysconfig

Member

Thanks: 12
Messages: 22

#25
Some interesting points there (in the original post), although it has indeed potential to become a pissing contest. First signs are there already :)


My answer turned out to be much longer than expected, so:

TLDR; Interesting OP, though some conclusions are premature IMHO. Whether it's FreeBSD or Linux depends on the workload and requirements, which may not even be of a technical nature. On a technical side, there's pros and cons for both sides, though my preference is generally FreeBSD, too. Welcome to FreeBSD! :)


Long version...

I've been using FreeBSD on servers since 4.0 on and off, and more seriously in production workloads since 7.1. There are a lot of good reasons for FreeBSD. But there are also a lot of valid reasons for using or sticking with Linux in other areas (though I found they were mainly political for clients I have worked with -- like: being able to pay for guaranteed support [RHEL], having a bigger pool of consultants and or permanent employees available, not wanting to run mixed server estates etc).

If I were to name the reasons why I personally would prefer FreeBSD over Linux any day, if it was entirely my choice and the workload left me that option:
  • ZFS -- this really is far superior to anything else (though it may require tuning for some workloads), IF you have enough memory available
  • simple and robust init system (the spreading disease called systemd just gives me the creeps, and while some distros are trying to fight it, they will eventually give in, because userland applications start depending on it already; mark my words :))
  • tidy system (base + ports, including file system hierarchy; not kernel + random gnu collections which are patched in arbitrary ways for all sorts of different Linux flavours to the point where configuration files between different distributions are inconsistent)
  • ports (especially with pkg-ng) blow RPMs and DEBs out of the water -- much easier to use and to modify
  • documentation (though RHEL, and CentOS as a free offspring, is pretty good on that front, too)
  • freedom of choice -- in Linux there's just too many dependencies on things you may not want (pulseaudio for example, or more recently systemd -- there it is again) and it's hard or impossible to get rid of them; in FreeBSD you can just choose to disable things and compile ports the way you want. (Gentoo users might argue that they have similar freedom. Maybe. I generally didn't like Gentoo much, because their community seemed somewhat aloof, so I only scratched the surface of Gentoo.)
  • much more intuitive kernel configuration (and it takes a fraction of the time to build it)
  • pf -- sure, it's from OpenBSD... so what?
  • BSD licence - I could do whatever I like with the code and use it wherever I want, without being accountable to anybody and having to make the modifications available to world&dog for the rest of my lifetime.
  • Community. Whether it's here in the forum (don't be fooled by my few posts; I read far more than I write), IRC, mailing list... people are genuinely helpful and friendly and usually know pretty damn well what they are talking about when they offer advice.
  • Consistency. The vast majority of what you learned about FreeBSD three or more major versions ago is still applicable. Linux? Almost everything seems to be constantly changing (I'm not going to mention systemd again here :), which is quite a major change). I'm not opposed to change per se, but if the changes don't bring any actual benefits for what I want to achieve (your mileage may vary), what's the point?
There are of course workloads where FreeBSD just isn't an option. For the stuff I do, it was usually company policies or other non-technical reasons. Linux is far superior at the moment for the majority of desktops and laptops, simply because it supports more recent hardware.
(Though I might just prove this point wrong for myself: I've just finished switching to FreeBSD entirely on the desktop a few weeks ago :) ; Laptop is work-in-progress still.)


To comment on some of the points in the original post:

Virtualisation: I'm reluctant to consider KVM available in FreeBSD. To quote svn log for the kernel module:

Code:
r339459 | nox | 2014-01-11 22:03:26 +0000 (Sat, 11 Jan 2014) | 6 lines

Mark BROKEN on 10+: KPI changes in 10 and up, use bhyve or vbox.
(If someone wants to fix it: patches welcome! :)
All commits after that (a year and a half ago now) were svn property fixes and other cleanup jobs, no actual patches from what I've seen.

I haven't tried bhyve yet, but I can testify to VirtualBox's robustness on FreeBSD. I've been using it for years. That's no a pro or con for FreeBSD though, because VirtualBox is available on all major operating systems, which is part of its beauty really.


Security: I find statements like "my OS is more secure than yours" highly dangerous. There's no such thing as absolute security anywhere, and a Linux with tight SELinux policies can be pretty damn secure, too. A default RHEL setup with SELinux enabled is arguably more secure than a default FreeBSD setup. It's up to the admin to assess the exact purpose of a setup and make sure that it can't be used in any other than the intended way (maliciously or by mistake). You can, and must, do that with any OS, even with Windows. But of course there will potentially be more known flaws and security issues on more widely used OS, simply because more people are looking and more people will be affected (hence a bigger incentive for naughty guys). By that measure, FreeBSD might seem more secure, of course. My gut instinct tells me that it probably is, but just an isolated look at how consoles are handled does not allow any conclusion as to how secure a system is as a whole.
I guess it'd take a pretty damn good security researcher who knows both Linux and FreeBSD inside out to come to a valid conclusion when comparing the two.