Slashdot Mirror
FreeBSD 10.0 Released
An anonymous reader writes "FreeBSD 10.0 has been released. A few highlights include: pkg is now the default package management utility. Major enhancements in virtualization, including the addition of bhyve, virtio, and native paravirtualized drivers providing support for FreeBSD as a guest operating system on Microsoft Hyper-V. Support for the high-performance LZ4 compression algorithm has been added to ZFS and TRIM support for SSD has been added to ZFS. clang is the default compiler. This release has official Raspberry Pi support. For a complete list of new features and known problems, please see the online release notes and a quick FreeBSD installation video is here. FreeBSD 10.0-RELEASE may be downloaded via ftp or via a torrent client that supports web seeding."
Good to hear. I'm sure I'm not the only one who really likes the BSDs in general. After almost 20 years in the IT biz, I would still choose FreeBSD or OpenBSD for my server needs for almost anything over almost anything. I've never been disappointed in the service of either BSD variant. Kudos to the FreeBSD devs!
In 10.0, "pkg install open-vm-tools" should work. There are a few issues, but we're waiting on fixes from upstream for those.
bhyve is technically a type 2, but it makes use of the HW acceled instructions that Type 1s normally use. bhyve is more a of a hybrid between 1 and 2, with more of a bias towards 2. Because of this, it is not very friendly with many Type 2 guests because it lacks legacy support and it's not a true Type 1, so it still needs proper interfaces, but it is faster, lighter weight, and uses about 10x fewer lines of code than most, so it is easy to debug and prove security.
I've been using 10.0-PRELEASE for most things here for a while and it works well... Watch the package system change though if you're upgrading a really old system and used to just using things like portupgrade, I'm still trying to get one of my old 8.something boxes ports all updated properly, though that's probably mostly my fault for being sloppy and not reading ports/UPDATING carefully enough :) The 10.0 kernel and userland themselves are working perfectly and it was a pain free transition all the way from 8 on that box.
pkg IS the default package management utility
pkgng is the project which spawned pkg * replacing the previous pkg_* tools
http://www.freebsd.org/cgi/man.cgi?query=pkg&apropos=0&sektion=0&manpath=FreeBSD+10.0-RELEASE&arch=default&format=html
brandelf -t FreeBSD
With the recent OpenBSD news many people claim OpenBSD has much cleaner code and can be kept more secure as a result. Is this just FUD or is there some evidence that FreeBSD accepts horrible performance patches and so on?
They're different projects with different emphasis. I think it's just a "us and them" type thing.
PS: I don't reply to ACs.
OpenBSD does have cleaner code because they continually audit their code. It's the only way. OpenBSD also does not allow binary blobs, which in today's world would be the height if stupidity because you cannot validate what is in them, view their source, to whom they may communicate with unbeknownst to you. Clean, open source viewable code is a must to establish and maintain trust. Binary blobs and the recent Linux model of cooperating with the MS secure boot initiative scares the crap out of many, including myself. I will likely be buying the same machines that RMS uses from this point forward.
I use qemu now but when I used to use VMWare, I never bothered to install VMWare tools on any guests. It seemed much easier and safer to just use my own script that would use ssh with password less key auth to shutdown, reboot or what not guests.
Do you really need VMWare tools?
It depends on one's individual needs. If you want better graphics/sound support, copy/paste support, seamless use of the mouse, and other features then they are great. In practice I only install them some of the time, mostly for desktop type guest OSes.
Exactly. Versus a properly configured host, It's a "difference" drummed up out of thin air so they can sell you "security".
brandelf -t FreeBSD
Do you really need VMWare tools?
One of the things the VMware Tools packages offer, apparently, is a kernel shim that allows the guest to inform the host of certain I/O-related things pertaining to filesystem use (ex. file deletions). Otherwise what you end up with is a disk image on the host (of the guest) which continually grows and performs worse and worse the more file creation/expansion/deletion is done on the guest.
I've yet to see the VMware Tools package work correctly on Linux (particularly Debian). I've tried for years to get the software to work, but it never starts up properly (always in "failed" state on boot). The same situation applies to VirtualBox, as I understand it.
So even if you're not using X / the GUI on the guest, it's still worthwhile having the Tools installed and used there.
I'll wait for the x.1 release
Which is fine. Avoiding a rush to implement a .0 release for anything critical is sound advice, regardless of vendor or closed/open source. But if nobody runs it, you do not uncover bugs and you never get a .1 release.
FreeBSD's goal is to create a solid Unix based general server OS. And it's around a lot in the storage markets and routing markets, it's just not usually called FreeBSD. I know more than a few Solaris shops that have been converting over to FreeBSD after the Oracle purchase because FreeBSD had DTrace and ZFS support that Linux didn't have at the time.
OpenBSD's goal is security above all else.
"The problem with socialism is eventually you run out of other people's money" - Thatcher.
According to wiki: Kernel-based Virtual Machine (KVM) and bhyve are implemented as a kernel modules for Linux and FreeBSD respectively which, when loaded, allows its host operating system to act as a bare metal (i.e., Type 1) hypervisor
So the only difference is the kernel is not just a hypervisor, but also an OS. If you don't make use of the OS part, it works like a normal Type 1 hypervisor.
Yeah, we're talking the NIMFY effect: not in my front yard.
Really, with the .0 releases, if you try to stay fairly mainstream in your deployment, and you're mindfull about the necessary mitigations if it doesn't go well, the risk is not outrageous. But first test your backups.
If I had to choose between 10.0 (which I hardly know) and 5.3 (all too well known) I'd pick 10.0 in a heartbeat. That series should have started out at 5.-5 (five dot negative five).
The .0 thing is just a loose heuristic.
...that's the one that's a bit like Linnux but not quite, right?
systemd is Roko's Basilisk.
Do you really need VMWare tools?
Yes.
Things like Gui integrations are fine and handy/essential if you are virtualizing a desktop OS.
But even if setting up a headless virtual server that you never access on the console after sshd is running you should still use them in order to benefit from virtualized disk and network I/O. This can deliver decent speedups if your VM is bottlenecking in that area.
The drivers you want should be in ports, or a precompiled package for all common OS's. If this is not true for your VM system then you should be questioning the VM provider, not the guest OS, about why they are so hard to setup.
"Oops, I always forget the purpose of competition is to divide people into winners and losers." - Hobbes
The major release numbers in FreeBSD mean breaks in binary compatibility. Any binary, including kernel modules, that runs on FreeBSD x.y is expected to run on FreeBSD x.(y+1). Userspace binaries should also work on (x+1).z, but may require compatibility packages to be installed (for userspace libraries that had ABI changes or were removed) and may require the kernel to be built with compatibility options enabled. This is the default for the GENERIC kernel, but some embedded builds disable them, and for some architectures there's no point in enabling them if FreeBSD didn't run on that architecture at the time.
I am TheRaven on Soylent News
Some guys at Spectra Logic and Citrix have been pushing Xen PVH support into FreeBSD recently. It didn't make it for 10.0, but hopefully should be in 10.1. In PVH mode, a guest boots as if it is a PV guest, with Xen's entry point and event channels instead of interrupts, but then uses the hardware page tables and either PCI pass-through devices or PV devices. This is important, because PVH guests can also run as dom0, if they implement the management interfaces (which are mostly userspace and shared across platforms). Getting PVH working in domU is much more effort than going from a working domU PVH to a working dom0 PVH.
That said, with bhyve and the new vps work (shared kernel like jails, but with some nifty features like live migration between hosts), there's a lot less of a reason for me to care about Xen, in relation to FreeBSD.
I am TheRaven on Soylent News
http://www.gnu.org/distros/common-distros.html#BSD
FreeBSD is free according to the definition used by the FreeBSD developers. Firmware is not loaded into the kernel so it's not concidered to be a concern, and the FreeBSD developers have no interest in saying what programs users should or should not use.
My primary attraction is the strengthened random number generation for cryptography. This eliminates the NSA introduced weaknesses in the underlying hardware.
That alone is enough to turn me into a rapid FreeBSD supporter.
TCAP-Abort
I think your numbers for KVM are for the entire kernel, not just the VM support, but your bhyve numbers are for the bhyve kernel module, which depends on a lot of other stuff in the kernel (the VM subsystem, device drivers, at least one out of the network and storage stacks). The Xen number includes, I think, includes just the hypervisor, not the domain 0 guest that is responsible for running the control plain, providing all of the emulated devices, and so on.
I am TheRaven on Soylent News
Capsicum, POSIX and NFS4 ACLs are all about adding complexity to allow for greater administrative policy enforcement
This is almost true for ACLs. ACLs are no more expressive than standard UNIX permissions, but they are significantly simpler for implementing the same thing - you no longer need to create a group for every set of people who want to share things. This lets you leave your default at share-nothing, and explicitly share the things that you need to share with the people that you need to share it with. The code for implementing them is significantly less complex than the work arounds that you need for their absence if you want the same level of access control, and if you don't want the same level of access control it's because you're fine with leaving things more widely readable than they need to be. Neither of these attitudes is good for security.
Capsicum is definitely not about adding complexity. The implementation adds an extra bitmask check on file accesses and restricts system calls to a whitelisted set. The total code changes in the kernel are very small and easy to audit (and have been audited by several groups). The code changes in userspace code are far more significant. The sandboxing in Chromium, for example, is six times more lines of code on OpenBSD using chroot() than it is on FreeBSD using Capsicum, and offers less isolation (for example, the renderer processes on OpenBSD can create network sockets, so an image in an email that exploits libpng or libjpeg vulnerabilities can phone home and send copies of all of your emails if you use webmail from OpenBSD, with Capsicum is can't). The privilege separation code in OpenSSH is also cleaner and easier to audit when it uses Capsicum.
In OpenBSD, security means that you eliminate bugs so that the most basic promise is held true.
In FreeBSD, we care about mitigation. Useful software is never bug free, no matter how simple you make it. The goal is to ensure that once an attacker finds a bug, they can't use it to exploit the system. That doesn't mean 'they can't get root', because on a huge number of modern systems, from single-user laptops to single-service VMs, getting ambient authority for a single user can mean the same as getting root, when it comes to having access to the data that the user cares about. Jails, Capsicum, and so on are all about enforcing the principle of least privilege, so when a bug is discovered the attacker only gets control of a sandbox with no access to the rest of the user's data. This used to be something that OpenBSD people cared about.
I am TheRaven on Soylent News
Binary firmware blobs, OpenBSD allows. You would run them anyways on your hardware, no matter what software you choose.
Binary kernel blobs, OpenBSD eschews. Example - While FreeBSD is basically happy to suck the dick of Nvidia, running proven crap, OpenBSD will wait for a Nouveau port coming in perhaps the near future.