FreeBSD RELEASE-10.0: the worst release of FreeBSD yet

Okay, so since FreeBSD 10.0 has been released, we decided to analyze what the FreeBSD project has done and report new features. All we found was a system that was more unusable then it’s earlier versions.

The hardware we used was a ThinkPad T510 with the following specs:

CPU: Intel® Core™ i7-620M, Dual-core, 2.66GHz

RAM: 8GB PC3-10666(1333Mhz)

Hard Drive: 250GB 5400rpm 2.5″ SATA HDD

Graphics Processor: Intel HD Graphics

Ethernet: Intel Gigabit Ethernet

Wireless: Intel Centrino Advanced-N 6200

Sound Card: Intel HD Audio

We first downloaded the DVD ISO image called “FreeBSD-10.0-RELEASE-amd64-dvd1.iso”, burned it to a DVD, boot from it and encountered the first big change with FreeBSD 10. The speed. It is much slower then previous versions. A quick skim through of dmesg reveals why:

############################################

FreeBSD 10.0-RELEASE #0 r260789: thu Jan 16 22.34.59 UTC 2014

root@snap.freebsd.org:/usr/obj/usr/src/sys/GENERIC amd64

FreeBSD clang version 3.3 (tags/RELEASE_33/final 183502) 20130610

############################################

Yes stock versions of FreeBSD are now compiled with CLANG not GCC. As of 2014, CLANG still produces vastly inferior binaries compared to GCC. These CLANG binaries have problems with speed, size and memory consumption. They are also notorious for memory leaks. Compiling FreeBSD with clang has made FreeBSD slower then before which shows just how much BSD developers are willing to sacrifice usability and performance for the sake of being more proprietary friendly.

With the kernel fully booted and the slow and obsolete BSD init finally activating all required services, we started the installation and ran into the next big change. Arrow keys do not work anymore. It is unknown whether this is the case with our hardware or a global problem but one thing we do know is that the arrows keys worked when we were assessing FreeBSD 9.1 on this same laptop. Luckily for us, the other keys were still functioning as they should and thus the installation was continued. During the installation, we chose to use the ZFS on root option which was not present in the 9.x installers. It was a decision that would be regret later as file operations of every type (even simple ones) would use huge quantities of RAM and CPU. The installation on the whole went smoothly but took much longer then previous versions.

Finally with the installation done, we now boot from the hard drive and encounter probably the biggest change to FreeBSD 10.0. Booting from the hard drive is now far slower then booting from the CD. The boot loader and kernel are both so slow with the kernel being the worst. The computer screen spent 2 minutes on the following line:

#################################

/boot/kernel/kernel text=0xed9008 data=…

#################################

So it now takes 2 minutes to boot just the FreeBSD kernel which makes you wonder what’s the blood alcohol level of the FreeBSD developers when they created this crap (By the way, it’s worth nothing that the majority of funding received by the FreeBSD project goes into buy beer for the developers). We also believe that this is a side effect of building the kernel and userland with clang.

With the OS fully booted, we can now take a look at some the so called “new” features. First and foremost intel wireless iwn0 device nodes now disappears after 5 minutes of booting so wireless is useless. And there’s still old, vulnerable and useless software like SendMail still included in the base system. PKGNG is still slow and terrible.

KMS on BSD: Failure of Epic Proportions

If you are expecting something pleasant when using KMS on FreeBSD, you can forget about it because all you get is misery. If you are using a graphics card in which supports KMS on FreeBSD (now Intel and AMD), versions of Xorg obtained from precompiled packages don’t work anymore. You now have to add the following to /etc/make.conf:

#######################################

WITH_NEW_XORG=yes

WITH_KMS=yes

#######################################

And then compile all of Xorg and Xorg’s dependencies from ports. To reduce the suffering of others, we recommend doing a:

# pkg install gcc48

And adding the following extra lines to /etc/make.conf:

#######################################
CC=gcc48
CXX=g++48
CPP=cpp48

#######################################

Using our machine, it took us nearly 20 hours to build Xorg. Once Xorg has been build, the troubles are only just beginning. When started, Xorg is far slower then it was without KMS. Wost still is that the virtual consoles are no longer functional when the KMS module is loaded and unloading the KMS resulted in the crash of the entire system. The system was so unbearable and unusable with Xorg that we had to disable it permanently.

This just shows us how much BSD developers are trying to force users away from FOSS respecting GPU manufacturers like Intel and AMD and instead make them use drivers from proprietary terrorists like NVidia.

BHyVe: Too Little too Late

Now for the feature that is so big in FreeBSD 10.0 because BSD lacked in that area for more then 10 years. Virtualization. In FreeBSD this now finally being done with the BSD Hypervisor. Stupidly called BhyVe or Bhyve. Bhyve is a type-2 hypervisor that tries to match Xen and KVM that was created for Linux near the begin of the 2000s. Our assessment of Bhyve shows that that is nothing new to it and has virtually no potential to be on par with KVM or Xen in Linux.

One of the worst problem with Bhyve is that you have to set it up BSD style (manual edit config files and reboot) which everyone knows is time consuming, tedious and prone to errors. We demonstrated this by doing an example.

First, search for documentation. Bhyve documentation is a mess not understandable. Next, you have to add the right configuration lines to both /etc/rc.conf and /boot/loader.conf.

/etc/rc.conf

##########################################

ifconfig_vnet0=”DHCP”

zfs_enable=”YES”

linux_enable=”YES”

##########################################

/boot/loader.conf

##########################################

virto_load=”YES”
if_vnet_load=”YES”
virto_pci_load=”YES”
virto_blk_load=”YES”

##########################################

And then reboot and wait for 3o minutes. By the way, you have to create both /etc/rc.conf and /boot/loader.conf as they do not exists by default.

You can see the difference here between Linux and BSD. Linux with KVM or Xen only requires loading up a kernel module and the system is set to vitalize. In FreeBSD, you have to jump through hoops and into crap to do the same thing.

Once system has finished rebooting, you have to load up not one but tree kernel modules: vmm, if_tap and if_bridge and manually create network interfaces for the virtual machines:

#######################################
ifconfig tap0 create
ifconfig bridge0 create
ifconfig bridge0 addm em0 addm tap0 up
ifconfig tap0 up

sysctl net.link.tap.up_on_open=1

#######################################

Once again, you can see the difference from Linux. In Linux the network interfaces are created automatically. In BSD you create them by yourself.

By this time keep many knives and cutting weapons far from yourself because you will now be having the urge to harm yourself (Serious).

Download another Freebsd ISO and create a disk image by typing into the same directory:

# truncate -s <size> <disk-image>

Now here’s where the half brain creator’s of Bhyve admit that the pile of crap they created is unusable so they created a script that would make this easier. Copy the script to the same directory as the disk and ISO images.  The shell script is located at /usr/share/examples/bhyve/vmrun.sh. Now edit that shell script:

###########################################
DEFAULT_MEMSIZE=512M
DEFAULT_CPUS=2

DEFAULT_VIRTIO_DISK=”<change to your disk image>”
DEFAULT_ISOFILE=”<ISO image>”

###########################################

Now you finally start virtual machine.

###################################

sh ./<shell script> -i -I <ISO images>

###################################

And see your system slow down by a 1000 times

We tried out these instructions and got one FreeBSD virtual machine to boot after 10 hours (just pointless). By contrast, KVM in Linux took only 30 minutes. Other problems with Bhyve are:

-Can only work on Intel i5 and i7 CPUs

-No AMD support

-No ARM support

-Can only run FreeBSD as a guest

-Huge resource consumption

-Virtual machines require constant attention

-Adjustments are very manual, tedious and time consuming

So as you can see, Bhyve just isn’t fit for use in the real world as each virtual machine takes would unnecessary amounts of work and hours to setup. Bhyve is just simply uncompetitive with Linux KVM or Xen in the area of virtualization. The only positive thing about Bhyve is that it was introduced in a BSD operating system but in terms of it’s virtualizing capabilities and ease of setup, it is just pure bullshit incapable of rapid deployment.

Conclusion

So the sum up everything, FreeBSD 10.0:

-Is much slower

-Xorg is noew virtually unusable except with NVidia

-Intel wifi deos not work anymore

-Bhyve is usless, and not production ready.

Advertisement