Slashdot Mirror

Am currently installing PC-BSD 9 on ZFS. The installer has been slick, so far, with simple and reasonable choices to select from, and with Knoppix-like magic in hardware detection. It is taking forever, but then I seem to recall every BSD install I've ever done taking forever as well...and the box itself isn't particularly fast by today's measures (Athlon XP 1800, 1.5g RAM). (I strongly suspect it will get faster with a bit of ZFS tweaking and maybe a lighter kernel.)

A good rule to follow with ZFS is 2GB RAM for every 1TB in the pool. More information here

Yes, I've often heard as much but this assertion has never come with any evidence. For anyone who forms their beliefs based off evidence, here is some as it pertains to the topic:

http://lists.freebsd.org/pipermail/freebsd-advocacy/2008-August/003674.html

Which is pretty much useless; it's just counting code lines. It tells you nothing about what the code does; code size does not equal importance. With a microkernel like Mach, you expect the userland tools to be bigger than the kernel itself.

Yes, I've often heard as much but this assertion has never come with any evidence. For anyone who forms their beliefs based off evidence, here is some as it pertains to the topic:

http://lists.freebsd.org/pipermail/freebsd-advocacy/2008-August/003674.html

The documentation is fantastic. I almost never have to ask for help on a forum because of it. The community is smaller, but I have never had a forum post go unanswered.
Not to nitpick, but that release cycle sounds like Ubuntu specifically not GNU/Linux as a whole. Now if you don't mind getting a little nerdy there are lots of other GNU/Linux distros out there, with much nicer release cycles. You might feel more at home with Debian.

I couldn't answer about doing a GUI only upgrade, I know there are GUI package managers and I would assume with PC-BSD that would be preinstalled but I never used them. However, since BSD is one group of developers building essentially the same code base, upgrading from a major release to the next isn't nearly as traumatic as Ubuntu, since everything is essentially linked against the same libraries that are being updated.
As for hardware support, I don't know exactly what you have, but there is a big old list of supported hardware:
http://www.freebsd.org/releases/9.0R/hardware.html

http://lists.freebsd.org/pipermail/freebsd-bugs/2009-September/036507.html has the original complaint about Taiwan.

Your comment makes no sense when thinking of a transition from IPv4 to IPv6. FreeBSD has made it so that it can run without IPv4 to make sure that there is nothing relying on IPv4. There will be a day when IPv4 is not needed, so why not make sure that nothing in IPv6 relies on it? FreeBSD has gotten over this hurdle and is now working on getting IPv6 performance up to the level of IPv4. They have assigned grant money to Bjoern Zeeb to get this project done, and the target is the end of Feb. They are lightyears ahead of other projects out there.

Considering that the BSD network stack is pretty much THE reference, whatever you code has to stay compatible with it.

"Compatible" at the API level or "compatible" at the network level? ("Compatible" at the API level is irrelevant, as it's not going to happen; PE is not a.out or ELF.)

So you're going to need to copy ALL the BSD constants,

No, you're not. Nobody's going to give a damn about AF_DATAKIT/PF_DATAKIT, for example. You're only going to have to copy the names of the ones that matter, namely AF_INET and AF_INET6.

and ALL the BSD typedefs,

Again, you'll only have to copy the ones used in socket calls.

So, tell us, how are you going to write something that complies with the standard without those constants, typedefs, and api? Magic? Time machine? Million Monkeys?

So, tell us, how are you going to write something that complies with various UN*X standards without using the code of an existing implementation?

As indicated, you don't have to copy the exact definitions of the constants; even the existing *BSDs don't all have the same numerical value for AF_INET6 (28 in FreeBSD and DragonFly BSD and 24 in NetBSD and OpenBSD; it's 30 in Mac OS X and presumably iOS).

In any case, even if they copied and pasted some typedef calls, that, in and of itself, doesn't mean that it's derived from the BSD code in any interesting way.

As for the "api", an API isn't code, it's documentation. There are a number of cases where multiple implementations of an API exist without sharing code. (You may have heard of some software called "the Linux kernel" and "the GNU C library" - and those APIs include more than the socket calls, so arguing that the Linux networking code may have been in part based on the BSD socket code is insufficient to dismiss those examples.)

Yes, yes, yes, and yes.

http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/x11-wm.html
http://www.freebsd.org/doc/handbook/desktop-browsers.html
http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/virtualization-host.html

Yes, yes, yes, and yes.

http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/x11-wm.html
http://www.freebsd.org/doc/handbook/desktop-browsers.html
http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/virtualization-host.html

Yes, yes, yes, and yes.

http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/x11-wm.html
http://www.freebsd.org/doc/handbook/desktop-browsers.html
http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/virtualization-host.html

As noted in the release notes, FreeBSD 9.0 includes Clang/LLVM, the goal is to be rid of all GPL dependencies by version 10.0. At the 2011 LLVM Developers' meeting, Brooks Davis covered the effort in bringing in LLVM for 9.0 and the work remaining for 10.0 to replace GCC. The move was originally intended for 9.0, but there wasn't enough time to get it all done, particularly due to the thousands of pieces of software in the ports tree that still require work. GPLv3 is cited as the catalyst for all this, for preventing cooperation between free and proprietary software sectors.

As noted in the release notes, FreeBSD 9.0 includes Clang/LLVM, the goal is to be rid of all GPL dependencies by version 10.0. At the 2011 LLVM Developers' meeting, Brooks Davis covered the effort in bringing in LLVM for 9.0 and the work remaining for 10.0 to replace GCC. The move was originally intended for 9.0, but there wasn't enough time to get it all done, particularly due to the thousands of pieces of software in the ports tree that still require work. GPLv3 is cited as the catalyst for all this, for preventing cooperation between free and proprietary software sectors.

It appears you aren't aware of the fact that very key members of the ZFS developers community (read: kernel code hackers) on FreeBSD have regular and direct interaction with folks doing IllumOS. Martin Matuska (mm@freebsd.org) is currently the front-man for this task.

It's all presented and documented publicly on the zfs-devel mailing list on freebsd.org. Read it if you wish. Check out November 2011, for example.

So, there is a sharing of ideas, code, and implementations/models on a regular basis. Therefore, the only "beast" you need to worry about is interoperability between ZFS on Solaris (meaning Oracle's commercial product) and ZFS on IllumOS/OpenIndiana or ZFS on FreeBSD. Got it? Good. :-)

People considering either dedup or compression on FreeBSD should be made blatantly aware of one of the issues which exists solely on FreeBSD. When using these features, you will find your system "stalling" intermittently during ZFS I/O (e.g. your SSH session stops accepting characters, etc.). Meaning, interactivity is *greatly* impacted when using dedup or compression. This problem affects RELENG_7 (which you shouldn't be using for ZFS anyway, too many bugs), RELENG_8, the new 9.x releases, and HEAD (10.x). Changing the compression algorithm to lzjb has a big improvement, but it's still easily noticeable.

My point is that I cannot imagine using either of these features on a system where users are actually on the machine trying to do interactive tasks, or on a machine used as a desktop. It's simply not plausible.

Here's confirmation and reading material for those who think my statements are bogus. The problem:

http://lists.freebsd.org/pipermail/freebsd-fs/2011-October/012718.html
http://lists.freebsd.org/pipermail/freebsd-fs/2011-October/012752.html

And how OpenIndiana/Illumos solved it:

http://lists.freebsd.org/pipermail/freebsd-fs/2011-October/012726.html

People considering either dedup or compression on FreeBSD should be made blatantly aware of one of the issues which exists solely on FreeBSD. When using these features, you will find your system "stalling" intermittently during ZFS I/O (e.g. your SSH session stops accepting characters, etc.). Meaning, interactivity is *greatly* impacted when using dedup or compression. This problem affects RELENG_7 (which you shouldn't be using for ZFS anyway, too many bugs), RELENG_8, the new 9.x releases, and HEAD (10.x). Changing the compression algorithm to lzjb has a big improvement, but it's still easily noticeable.

My point is that I cannot imagine using either of these features on a system where users are actually on the machine trying to do interactive tasks, or on a machine used as a desktop. It's simply not plausible.

Here's confirmation and reading material for those who think my statements are bogus. The problem:

http://lists.freebsd.org/pipermail/freebsd-fs/2011-October/012718.html
http://lists.freebsd.org/pipermail/freebsd-fs/2011-October/012752.html

And how OpenIndiana/Illumos solved it:

http://lists.freebsd.org/pipermail/freebsd-fs/2011-October/012726.html

People considering either dedup or compression on FreeBSD should be made blatantly aware of one of the issues which exists solely on FreeBSD. When using these features, you will find your system "stalling" intermittently during ZFS I/O (e.g. your SSH session stops accepting characters, etc.). Meaning, interactivity is *greatly* impacted when using dedup or compression. This problem affects RELENG_7 (which you shouldn't be using for ZFS anyway, too many bugs), RELENG_8, the new 9.x releases, and HEAD (10.x). Changing the compression algorithm to lzjb has a big improvement, but it's still easily noticeable.

My point is that I cannot imagine using either of these features on a system where users are actually on the machine trying to do interactive tasks, or on a machine used as a desktop. It's simply not plausible.

Here's confirmation and reading material for those who think my statements are bogus. The problem:

http://lists.freebsd.org/pipermail/freebsd-fs/2011-October/012718.html
http://lists.freebsd.org/pipermail/freebsd-fs/2011-October/012752.html

And how OpenIndiana/Illumos solved it:

http://lists.freebsd.org/pipermail/freebsd-fs/2011-October/012726.html

However, they're trying to get rid of GPL software in the src tree as fast as they can.

This is why it is very important that the use of the GNU system is spread in favor of non-free non-GPL systems which do not respect the users freedom.

However, they're trying to get rid of GPL software in the src tree as fast as they can.

What Linux really could use for secure logging is mounting /var/log as an append-only file system. If you can only read from and append to a file, it makes it awfully difficult to tamper with it. http://www.freebsd.org/doc/handbook/securing-freebsd.html

Truly append-only makes log rotation difficult, and without it you are not completely secure -- replacing a file is almost as easy for an attacker as in-place editing. Mandatory Access Control makes it possible to ensure that only the log rotation daemon can replace files and everyone else can only append to their log files. Both FreeBSD and Linux provide MAC.

Interesting!

I moved over to FreeBSD .....It's a good operating system, but package management is a pain. If only if someone could port APT over to FreeBSD... sigh.

Totally.

apt-get install sumpackage
is so much more comprehensible and understandable, and totally not a pain, whereas,

pkg_add sumpackage
is out of control, a total pain, and whomever came up with such a nonsensical and grotesque idea is a really disturbed individual.

I keep telling people... read the book first. If you watch the movie first, you'll forever incorrectly believe the movie was better than the book. The movie is apt, but the book is the true source. And even the sequel is better than the movie.

Since you haven't selected any specific distributions I've googled for guides and selected OpenSUSE, Ubuntu, Fedora. Seems like there are typically more steps involved in both building the kernel and installing it for these systems compared to FreeBSD. I didn't spend a lot of time googling examples, I searched for "%distro% installing custom kernel guide" and selected the most relevant results returned from the first page.

FreeBSD:
Pre-requisites is having the source installed. The easiest way to install the full source tree is to run sysinstall as root, and then choosing Configure, then Distributions, then src, and finally All. sysinstall is FreeBSD's terminal based installer.

Already have a kernel configured? Skip to step 4.
1 # cd /usr/src/sys/i386/conf
2 # cp GENERIC CUSTOMKERNEL //duplicate default generic kernel as a starting point
3 # ee CUSTOMKERNEL // load kernel file into easyedit (you could use vi, pico etc.) and modify kernel
4 # cd /usr/src
5 # make buildkernel KERNCONF=CUSTOMKERNEL
6 # make installkernel KERNCONF=CUSTOMKERNEL

It is implied that you want to do more than just run your CPU to replicate a binary that you already have. In other words, the goal is to tweak. The goal isn't to waste electricity.

Is it also implied that on the Linux side of things that one needs to run a script to generate a kernel configuration file since it's apparently too complicated to do so directly?

Required to upgrade due to some security thing, Oh wait, some obscure library has also updated and now the entire OS needs to upgrade

Do you upgrade a foundation of a house without expecting to touch anything built upon it? When a dependency is upgraded software which depends upon it is rebuilt to make use of the new library (ports and whatnot are built with compile time flags which tell it what libraries to use). You can work with binary packages to reduce the compile time, but as soon as you start manually upgrading things you need to be aware of what you're doing since you now have a "custom" configuration.

First responses are usually "It's in UPDATING, come back when you've read that." If you haven't seen the snide, arrogant crap that happens on the mailing lists you are not paying attention.

Each operating system has it's own quirks and FreeBSD is no exception. When upgrading your FreeBSD system you would be wise to consult UPDATING file located in the ports directory. This file contains the most recent notes and issues to be aware of before beginning any updates to minimize conflicts and redundant questions. Pretty obscure eh? It wouldn't be if you began here. You may be shocked to discover people being snide or arrogant are not limited to FreeBSD mailing lists... have you heard xbox live?

And KDE too. WTF? When did Gnome get installed? Ah well, I wasn't going to use the computer this week anyway. One week later, nothing works, so I go to the mailing lists.

You install oodles of software and are shocked (SHOCKED!) there are oodles of dependencies. It doesn't take a week to update a system but i'm not familiar with your configuration or the hardware this machine has, or your abilities. Back in the day bsdforums.org was a great place to turn to help, you might consider the "official" forums.

(mailing lists? are your reading what you are typing? mailing lists? This isn't 1988.)

Google makes navigating these pretty easy if you don't want to configure a client. We're still using wheels and those predate mailing lists! People still use SSH, FTP and VI and those aren't exactly new either but I digress.

And RTFM? If you need to RTFM to install software and keep a system running, the system is crap.

Perhaps this is the reason you're experiencing the issues you've encountered. Disregarding the advice and best practices of the developers and maintainers who have created the system you're "administering" through your own ignorance is telling and a recipe for disaster. Luckily FreeBSD has a nice handbook which covers everything from upgrading a system on the fly to common administration tasks should you need assistance. Honestly, do you just dump fluids into your engine and when something strange happens lament the vehicle?

I've switched to a Mac and Windows 7. Haven't had to R any FM since. No. FreeBSD is not a desktop system. If you want it to do useful things, don't install a gui and try to limit yourself to the base OS. Do everything from the command line. Aint that quaint.

I'm glad you've found something you can get work done with little hassle, which is ideally what computers are there for - getting work done. Each of these OS have different ways of getting these things done, and typically I prefer the *nix side of things. Windows/OSX Philosophy: "I don't think you shoul

Required to upgrade due to some security thing, Oh wait, some obscure library has also updated and now the entire OS needs to upgrade

Do you upgrade a foundation of a house without expecting to touch anything built upon it? When a dependency is upgraded software which depends upon it is rebuilt to make use of the new library (ports and whatnot are built with compile time flags which tell it what libraries to use). You can work with binary packages to reduce the compile time, but as soon as you start manually upgrading things you need to be aware of what you're doing since you now have a "custom" configuration.

First responses are usually "It's in UPDATING, come back when you've read that." If you haven't seen the snide, arrogant crap that happens on the mailing lists you are not paying attention.

Each operating system has it's own quirks and FreeBSD is no exception. When upgrading your FreeBSD system you would be wise to consult UPDATING file located in the ports directory. This file contains the most recent notes and issues to be aware of before beginning any updates to minimize conflicts and redundant questions. Pretty obscure eh? It wouldn't be if you began here. You may be shocked to discover people being snide or arrogant are not limited to FreeBSD mailing lists... have you heard xbox live?

And KDE too. WTF? When did Gnome get installed? Ah well, I wasn't going to use the computer this week anyway. One week later, nothing works, so I go to the mailing lists.

You install oodles of software and are shocked (SHOCKED!) there are oodles of dependencies. It doesn't take a week to update a system but i'm not familiar with your configuration or the hardware this machine has, or your abilities. Back in the day bsdforums.org was a great place to turn to help, you might consider the "official" forums.

(mailing lists? are your reading what you are typing? mailing lists? This isn't 1988.)

Google makes navigating these pretty easy if you don't want to configure a client. We're still using wheels and those predate mailing lists! People still use SSH, FTP and VI and those aren't exactly new either but I digress.

And RTFM? If you need to RTFM to install software and keep a system running, the system is crap.

Perhaps this is the reason you're experiencing the issues you've encountered. Disregarding the advice and best practices of the developers and maintainers who have created the system you're "administering" through your own ignorance is telling and a recipe for disaster. Luckily FreeBSD has a nice handbook which covers everything from upgrading a system on the fly to common administration tasks should you need assistance. Honestly, do you just dump fluids into your engine and when something strange happens lament the vehicle?

I've switched to a Mac and Windows 7. Haven't had to R any FM since. No. FreeBSD is not a desktop system. If you want it to do useful things, don't install a gui and try to limit yourself to the base OS. Do everything from the command line. Aint that quaint.

I'm glad you've found something you can get work done with little hassle, which is ideally what computers are there for - getting work done. Each of these OS have different ways of getting these things done, and typically I prefer the *nix side of things. Windows/OSX Philosophy: "I don't think you shoul

Required to upgrade due to some security thing, Oh wait, some obscure library has also updated and now the entire OS needs to upgrade

Do you upgrade a foundation of a house without expecting to touch anything built upon it? When a dependency is upgraded software which depends upon it is rebuilt to make use of the new library (ports and whatnot are built with compile time flags which tell it what libraries to use). You can work with binary packages to reduce the compile time, but as soon as you start manually upgrading things you need to be aware of what you're doing since you now have a "custom" configuration.

First responses are usually "It's in UPDATING, come back when you've read that." If you haven't seen the snide, arrogant crap that happens on the mailing lists you are not paying attention.

Each operating system has it's own quirks and FreeBSD is no exception. When upgrading your FreeBSD system you would be wise to consult UPDATING file located in the ports directory. This file contains the most recent notes and issues to be aware of before beginning any updates to minimize conflicts and redundant questions. Pretty obscure eh? It wouldn't be if you began here. You may be shocked to discover people being snide or arrogant are not limited to FreeBSD mailing lists... have you heard xbox live?

And KDE too. WTF? When did Gnome get installed? Ah well, I wasn't going to use the computer this week anyway. One week later, nothing works, so I go to the mailing lists.

You install oodles of software and are shocked (SHOCKED!) there are oodles of dependencies. It doesn't take a week to update a system but i'm not familiar with your configuration or the hardware this machine has, or your abilities. Back in the day bsdforums.org was a great place to turn to help, you might consider the "official" forums.

(mailing lists? are your reading what you are typing? mailing lists? This isn't 1988.)

Google makes navigating these pretty easy if you don't want to configure a client. We're still using wheels and those predate mailing lists! People still use SSH, FTP and VI and those aren't exactly new either but I digress.

And RTFM? If you need to RTFM to install software and keep a system running, the system is crap.

Perhaps this is the reason you're experiencing the issues you've encountered. Disregarding the advice and best practices of the developers and maintainers who have created the system you're "administering" through your own ignorance is telling and a recipe for disaster. Luckily FreeBSD has a nice handbook which covers everything from upgrading a system on the fly to common administration tasks should you need assistance. Honestly, do you just dump fluids into your engine and when something strange happens lament the vehicle?

I've switched to a Mac and Windows 7. Haven't had to R any FM since. No. FreeBSD is not a desktop system. If you want it to do useful things, don't install a gui and try to limit yourself to the base OS. Do everything from the command line. Aint that quaint.

I'm glad you've found something you can get work done with little hassle, which is ideally what computers are there for - getting work done. Each of these OS have different ways of getting these things done, and typically I prefer the *nix side of things. Windows/OSX Philosophy: "I don't think you shoul

FreeBSD has you editing a makefile with minimal documentation.

No, it has you editing the kernel description file with lots of documentation. Here is the GENERIC kernel config for x86-64. If you want to compile a custom kernel, copy that file and modify it. You'll find a comment on every single line explaining what it does, and a longer comment above every section. Linux's menuconfig requires more keystrokes to remove options than editing that file in a text editor.

Use freebsd-update(8). It's been available since 6.4. http://www.freebsd.org/cgi/man.cgi?query=freebsd-update&apropos=0&sektion=0&manpath=FreeBSD+8.2-RELEASE&arch=default&format=html

There are some benchmarks of FreeBSD 7 against Linux of the same era (that graph includes the version of Linux that was specifically released after the previous set of benchmarks showed FreeBSD beating Linux by even more). Both Linux and FreeBSD have improved in SMP support since then, so I don't know how they compare anymore. I suspect that both are in the state where the kernel is not likely to be the cause of any scalability issues that you encounter.

It's also nonsense. The ULE2 scheduler in FreeBSD has very good SMP support. Up to 8 cores, it gives a pretty linear speedup on the MySQL benchmarks I saw. Allegedly it should continue to scale well up to at least 64 cores, but I've not seen any real tests on bigger machines. This has been true since FreeBSD 7, although SMP performance improved a lot in the 8-9 window.

I've been using Linux (Ubuntu LTS) professionally on the desktop for a few years to support my company. It wasn't a full time job when this started so I also had plenty of time to spent on administrating it.

But now that I am working full time one of the first things I discovered was that Linux may be free of charge to get it up & running. Support is a totally different aspect! For example trying to get Ubuntu 8 LTS upgraded to Ubuntu 10 LTS. I tried, hard, with several years worth of experience. From a direct upgrade to upgrading from one version to the other until 10 was reached. It failed, horribly. The only way I would have succeeded was to do a clean installation and then try to figure out how I could manually restore my configuration (thus also hoping that it wouldn't break things).

Long story shorter; I moved the desktop to Windows 7 & Office 2010. Sure; it costs money. But now I can also rest assured that I'll be able to continue to use this environment until 2018 or so (- 7 - years) before any upgrade might be required.

Now; lets take a look at the FreeBSD Support cycle. Release 8.2; Feb. 24 2011 released and expected EOL is Feb. 29 2011. That is one year.

If you use a desktop professionally then one year is totally out of the question. Quite frankly, with such a short lifespan I wouldn't even consider it for personal use either.

Mr. Venezia doesn't seem to understand the basis of desktop usage: Most desktop users want to use their computers (desktop) instead of tinkering with it.

There is a very good reason why Microsoft continues to support their OS's for so long.

I assume they still don't have it. Wake me up when that happens and I will use FreeBSD on the desktop.

Your assumption is wrong. A simple search on the internet would have shown you that Flash works on FreeBSD, and it works for a while now (both 32 and 64bit). I've used it with Firefox and with Opera.

See the handbook.

So, um... wake up lazy!

http://www.freebsd.org/doc/en/articles/pam/pam-appl-prog.html

I suppose it's accurate at least!

I do agree though that Postgres has excellent documentation.

You mean like this?

http://people.freebsd.org/~kris/scaling/os-mysql.png

The linuxolator in FreeBSD is located here:
http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/compat/linux/

You can actually see how it's implemented.

Before even remotely considering jails on FreeBSD, I would recommend people read about a serious bug that is affecting a company of 140+ servers with kernel panics. Kernel developers are actively trying to figure out what the root cause is. This statement by a kernel developer says it all, and justifies why you will find no jails on any of the systems I manage.

Likewise, before even remotely considering VirtualBox on FreeBSD, I would recommend people read about a serious bug that affects the network stack and resource (memory) allocation for data transfers; the thread continues here. One of the reporters confirms VirtualBox is responsible. Reporters did not state if the issue was limited to applications within VirtualBox or if the entire system is affected, but it is implied that it affects only applications within VirtualBox. The workaround proposed by another user has severe consequences to the entire system (not just within VB). No kernel developer has commented or stepped up to the plate.

So if you're going to consider virtualization, consider using Linux or Windows -- or better yet something like VMware ESXi. Even Xen on FreeBSD is not ready for prime-time (review the list of issues, all of which are major).

Over the years I have learned that people who advocate FreeBSD often pay little-to-no-attention to the mailing lists, which provide great insight to just how behind-the-times FreeBSD is when compared to other offerings. Does FreeBSD suck? No, but it does suck more in some regards than Linux or OpenSolaris, while less in others. TL;DR - before considering FreeBSD, read mailing lists (-stable, -fs, -net, and -questions are the main 4) and look for repeatedly-reported issues. You might be surprised.

Before even remotely considering jails on FreeBSD, I would recommend people read about a serious bug that is affecting a company of 140+ servers with kernel panics. Kernel developers are actively trying to figure out what the root cause is. This statement by a kernel developer says it all, and justifies why you will find no jails on any of the systems I manage.

Likewise, before even remotely considering VirtualBox on FreeBSD, I would recommend people read about a serious bug that affects the network stack and resource (memory) allocation for data transfers; the thread continues here. One of the reporters confirms VirtualBox is responsible. Reporters did not state if the issue was limited to applications within VirtualBox or if the entire system is affected, but it is implied that it affects only applications within VirtualBox. The workaround proposed by another user has severe consequences to the entire system (not just within VB). No kernel developer has commented or stepped up to the plate.

So if you're going to consider virtualization, consider using Linux or Windows -- or better yet something like VMware ESXi. Even Xen on FreeBSD is not ready for prime-time (review the list of issues, all of which are major).

Over the years I have learned that people who advocate FreeBSD often pay little-to-no-attention to the mailing lists, which provide great insight to just how behind-the-times FreeBSD is when compared to other offerings. Does FreeBSD suck? No, but it does suck more in some regards than Linux or OpenSolaris, while less in others. TL;DR - before considering FreeBSD, read mailing lists (-stable, -fs, -net, and -questions are the main 4) and look for repeatedly-reported issues. You might be surprised.

Before even remotely considering jails on FreeBSD, I would recommend people read about a serious bug that is affecting a company of 140+ servers with kernel panics. Kernel developers are actively trying to figure out what the root cause is. This statement by a kernel developer says it all, and justifies why you will find no jails on any of the systems I manage.

Likewise, before even remotely considering VirtualBox on FreeBSD, I would recommend people read about a serious bug that affects the network stack and resource (memory) allocation for data transfers; the thread continues here. One of the reporters confirms VirtualBox is responsible. Reporters did not state if the issue was limited to applications within VirtualBox or if the entire system is affected, but it is implied that it affects only applications within VirtualBox. The workaround proposed by another user has severe consequences to the entire system (not just within VB). No kernel developer has commented or stepped up to the plate.

So if you're going to consider virtualization, consider using Linux or Windows -- or better yet something like VMware ESXi. Even Xen on FreeBSD is not ready for prime-time (review the list of issues, all of which are major).

Over the years I have learned that people who advocate FreeBSD often pay little-to-no-attention to the mailing lists, which provide great insight to just how behind-the-times FreeBSD is when compared to other offerings. Does FreeBSD suck? No, but it does suck more in some regards than Linux or OpenSolaris, while less in others. TL;DR - before considering FreeBSD, read mailing lists (-stable, -fs, -net, and -questions are the main 4) and look for repeatedly-reported issues. You might be surprised.

Before even remotely considering jails on FreeBSD, I would recommend people read about a serious bug that is affecting a company of 140+ servers with kernel panics. Kernel developers are actively trying to figure out what the root cause is. This statement by a kernel developer says it all, and justifies why you will find no jails on any of the systems I manage.

Likewise, before even remotely considering VirtualBox on FreeBSD, I would recommend people read about a serious bug that affects the network stack and resource (memory) allocation for data transfers; the thread continues here. One of the reporters confirms VirtualBox is responsible. Reporters did not state if the issue was limited to applications within VirtualBox or if the entire system is affected, but it is implied that it affects only applications within VirtualBox. The workaround proposed by another user has severe consequences to the entire system (not just within VB). No kernel developer has commented or stepped up to the plate.

So if you're going to consider virtualization, consider using Linux or Windows -- or better yet something like VMware ESXi. Even Xen on FreeBSD is not ready for prime-time (review the list of issues, all of which are major).

Over the years I have learned that people who advocate FreeBSD often pay little-to-no-attention to the mailing lists, which provide great insight to just how behind-the-times FreeBSD is when compared to other offerings. Does FreeBSD suck? No, but it does suck more in some regards than Linux or OpenSolaris, while less in others. TL;DR - before considering FreeBSD, read mailing lists (-stable, -fs, -net, and -questions are the main 4) and look for repeatedly-reported issues. You might be surprised.

Before even remotely considering jails on FreeBSD, I would recommend people read about a serious bug that is affecting a company of 140+ servers with kernel panics. Kernel developers are actively trying to figure out what the root cause is. This statement by a kernel developer says it all, and justifies why you will find no jails on any of the systems I manage.

Likewise, before even remotely considering VirtualBox on FreeBSD, I would recommend people read about a serious bug that affects the network stack and resource (memory) allocation for data transfers; the thread continues here. One of the reporters confirms VirtualBox is responsible. Reporters did not state if the issue was limited to applications within VirtualBox or if the entire system is affected, but it is implied that it affects only applications within VirtualBox. The workaround proposed by another user has severe consequences to the entire system (not just within VB). No kernel developer has commented or stepped up to the plate.

So if you're going to consider virtualization, consider using Linux or Windows -- or better yet something like VMware ESXi. Even Xen on FreeBSD is not ready for prime-time (review the list of issues, all of which are major).

Over the years I have learned that people who advocate FreeBSD often pay little-to-no-attention to the mailing lists, which provide great insight to just how behind-the-times FreeBSD is when compared to other offerings. Does FreeBSD suck? No, but it does suck more in some regards than Linux or OpenSolaris, while less in others. TL;DR - before considering FreeBSD, read mailing lists (-stable, -fs, -net, and -questions are the main 4) and look for repeatedly-reported issues. You might be surprised.

.
Both FreeBSD and FreeNAS, in addition to OpenSolaris, support ZFS.

Phoronix has a history of questionable choices for their benchmark setups. Hardware, versions, and tuning are... cleverly chosen, almost as if there was a preconceived agenda with inevitable results. Not that there is one-- just like it seems like there is. And so colorfully presented! I remember when they tested ZFS on an i386 version of FreeBSD on a 1G laptop! Others have also noticed this Phoronix phenomenon:

http://forums.freebsd.org/archive/index.php/t-16396.html
http://www.kev009.com/wp/2008/12/phoronix-benchmarking-statistically-significant-and-other-performance-concerns/

The whole point of Hurd, at least right now, is tangential to benchmarks. Nothing wrong with testing, of course, but I think the results should not be used for any long term planning. Nobody is planning on launching a business running on Hurd servers... yet.

You all should know that Lennart Poettering's creations are widely criticized on FreeBSD, for example.

http://forums.freebsd.org/showthread.php?t=22444 - "Some things may break in mysterious ways." (because he refuses to accept /usr directory in systemd or wtf it may mean)

Here a thread about PulseAudio: http://forums.freebsd.org/showthread.php?t=2613

I guess, he is a bit disappointed and fights back now.

You all should know that Lennart Poettering's creations are widely criticized on FreeBSD, for example.

http://forums.freebsd.org/showthread.php?t=22444 - "Some things may break in mysterious ways." (because he refuses to accept /usr directory in systemd or wtf it may mean)

Here a thread about PulseAudio: http://forums.freebsd.org/showthread.php?t=2613

I guess, he is a bit disappointed and fights back now.

Stick with FreeBSD and use ZFS. It includes filesystem-level checksumming, deduplication (just rolled into STABLE) and encryption (still in CURRENT) http://en.wikipedia.org/wiki/ZFS http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/filesystems-zfs.html

How is it that you didn't get TrueCrypt working? The current version is in the ports collection and works fine for me: http://www.freebsd.org/cgi/url.cgi?ports/security/truecrypt/pkg-descr

I went through the trouble of setting up one-time passwords on a couple of my hosts. I carry a little printout in my wallet and scratch off passwords as I use them. More commonly, I use an SSH client on my iPhone that gets me into my home server, then branch out from there.

You do realise that nvidia has had freebsd amd64 drivers for over a year and a half now? The latest of which is 270.4106

Yup, that's Ubuntu before the suckage added.

  Or Unbuntu with the suck massaged out: http://www.linuxmint.com/

    Too light to contain suck: http://www.archlinux.org/

    Too tiny to hold suck: http://puppylinux.com/

    Got their suck fixed a few releases ago, it's all good now: http://www.fedoraproject.org/

    fixed their suck a while ago too, lookin' good: http://www.freebsd.org/
 
    supports all kinds of desktops that don't suck: http://www.mandriva.com/

    roll your own without the suck: http://www.gentoo.org/

I started with, "Pay for the FreeBSD, not the Linux". But FUCK, that doesn't work. You don't have to pay for the FreeBSD! It's already free!

These people will happily let you pay for FreeBSD. The FreeBSD Foundation has just paid for some of my work, so I'm pretty sure that it is possible to pay for FreeBSD.

Then I tried, "Pay for the LLVM, not the GCC". But FUCK, that doesn't work, either! LLVM is free, too!

XCode 4 includes LLVM and Apple will let you pay for it. Some of that money goes to funding LLVM development. If you need extra features added to LLVM, I (and others) will happily give you a quote.

Finally I tried, "Pay for the Python, not the Ruby". But FUCK ME AGAIN, that doesn't work. Python is totally free.

I currently have a contract that is paying me to hack on Python, so I can assure you that it is possible to pay for Python.

FUCK

I've not tried, but I'm pretty sure you can pay for that too...

In UNIX-land, no it isn't.

Sorry, but shipping code beats standards based theory, and pretty much every *nix vendor ships dc with the OS.

Oracle (nee Sun) Solaris, IBM AIX, HP HP/UX, SGI IRIX, Apple MacOS X, SCO Openserver, SuSE Enterprise Linux (dc listed on bc page), FreeBSD, OpenBSD ...

You also appear to missed a few things about the Open Group Base Specifications Issue 7 / IEEE Std 1003.1-2008 standard - it is in essence a floor, not a ceiling - vendors can ship more tools if they care to. Also, the discussion on bc notes that some implementations of bc are built on top of dc, and that is OK, as long as the behavior of bc is correct.

It is worth noting that dc was one of the earliest programs to run in Unix, making it in while Unix was still written in assembly language. If for some reason it was to be not only omitted, but actually excluded by the standard, it would still be found in the vast majority of shipping systems for years to come until said vendor decided to migrate their Unix system to the current standard, a process that often takes years.

So yes, for the vast majority of people using Unix, an RPN calculator is often only as far away as a shell prompt.