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."
It is really nice that the recent Linux distros have them.
It is a pain in the butt on FreeBSD to manually switch compilers and hack /etc files and then do a manual compile to get them to work in VMWare workstation 10 in comparison.
http://saveie6.com/
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!
It would be nice if FreeBSD had a Xen-like tier 1 hypervisor. Running as a client is one thing. Running as something with ZFS underneath would be very useful as an alternative to QEMU or Bochs.
pkg is NOT the default package management
"pkgng is the next generation replacement for the traditional FreeBSD package management tools, offering many features that make dealing with binary packages faster and easier.
pkgng is not a replacement for port management tools like ports-mgmt/portmaster or ports-mgmt/portupgrade. "
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?
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.
I agree...FreeBSD seems like a great Xen host.
PS: I don't reply to ACs.
Ahh...the downside of allowing anonymous posting.
For my amusement, please tell me you actually believe this and aren't trolling.
Is there any real difference between a Type 1 hypervisor and a Type 2 where you never run anything? If you took FreeBSD and ripped out everything but the minimum binaries and scripts needed to boot and run bhyve instances, how would that be different from a Type 1 hypervisor?
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
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.
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.
does USB 3.0 work properly yet?
http://en.wikipedia.org/wiki/Hypervisor#Classification
I don't know how bhyve operates, I haven't had time to look into it, but it sounds like all resources will still be allocated and accessible by the primary host. You won't be able to do things like restrict how much memory the primary machine/domain has access to, like what you can do with dom0 in Xen.
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.
Before anyone considers upgrading or installing FreeBSD 10.0-RELEASE, it is recommended you first read the Errata (particularly the Open Issues section):
http://www.freebsd.org/releases/10.0R/errata.html
Some of these might come as a shock to readers, especially the killall argv parsing bug and the ipfw fwd link-layer bug.
other projects just increment numbers without any radical changes. OpenBSD for example just slowly increments by 0.1
...that's the one that's a bit like Linnux but not quite, right?
systemd is Roko's Basilisk.
http://www.gnu.org/distros/common-distros.html#BSD
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
The distinction between Type 1 and Type 2 hypervisors doesn't really make sense anymore, and is largely marketing. For example, Xen running on a system with no IOMMU is still a Type 1 hypervisor, but the whole of the dom0 kernel and a chunk of its userspace are in the trusted computing base (TCB), where a compromise can extend to every other domain. In the case of Linux's KVM and bhyve, the host kernel (and anything that can poke kernel memory, or exploit kernel vulnerabilities) are in the TCB.
The distinction makes more sense for certain ARM, SPARC, and PowerPC hypervisors, where the hardware handles most of the virtualisation (devices all support multiple isolated command queues and run behind an IOMMU), so a small Type 1 hypervisor can be a few tens of thousands of lines of code and that's the entire shared TCB. Guests run their own device drivers, the hypervisor just handles the control plane.
The important distinction is between hypervisors that do software partitioning of devices (either via emulation or paravirtualised devices), and ones that don't. Xen, KVM, and byhve all fall into the former category and so have a TCB that's several MBs of object code.
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
Why? This isn't Linux you know.
If you took FreeBSD and ripped out everything but the minimum binaries and scripts needed to boot and run bhyve instances, how would that be different from a Type 1 hypervisor?
A lot of Type 1s don't have much in the way of tools for debugging.
With the approach that Bhyve is taking in their Type 2, you get the full power of a Unix OS (tcpdump, s/p/dtrace, etc.) to examine issues that your guests/tenants are having.
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 read about Fuse support being added before now, but I wondered if anyone has setup Gluster with FreeBSD since then? I am very interested in the combo of ZFS and Gluster, but up until now it seemed like only Centos/RHE were the options and like another poster said, ZFS on Linux has more in the way of potential licence issues and other tech limitations. But in the reverse, Gluster on FreeBSD is still "weird"
The important distinction is between hypervisors that do software partitioning of devices (either via emulation or paravirtualised devices), and ones that don't. Xen, KVM, and byhve all fall into the former category and so have a TCB that's several MBs of object code.
It is interesting to note that KVM is over 12mil lines of code and XEN is about 515k LOC, while byhve is only 1,300.. yes.. 1 thousand three hundred. byhve also compiles to just under 500KB. XEN is around 1MB, but I can't find info on KVM.
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
Since FreeBSD is one of the top distributions, even appearing on Linux-centric sites as mentionable: http://distrowatch.com/dwres.p...
The way God *intended* version numbers to work! ;) None of this always-a-major-version Chrome/Firefox nonsense.
I liked the old base Linux versioning scheme too, but they killed that as well. Sigh.
Unity? Screw that: XFCE. Slashdot Beta? Screw that: SoylentNews. Australis? Screw that: Pale Moon. UX developers DIAF
Let me know when a BSD gets opencl and cuda support. That's the main thing keeping me from using it in more than just a VirtualBox machine.
Ops, I shuld have usd the prevuwe but in.
Being able to use ZFS on Raspberry PI, even running on USB disk and low performance, would be really nice for mediacenters and backup NAS. Anybody has experience with that, I guess 512MB is not enough for it...
I don't care a lot about performance in this context, but stability.
Opinions?
Being able to use ZFS on Raspberry PI, even running on USB disk and low performance, would be really nice for mediacenters and backup NAS. Anybody has experience with that, I guess 512MB is not enough for it...
I don't care a lot about performance in this context, but stability.
Any opinion or experience?
Does FreeBSD/PC-BSD have anything like a QEMU/KVM?
So, yes, FreeBSD now ships clang (and llvm) by default.
Looks like that is the real reason why the GCC guys are now angry and fearful that some linux distribution may follow.
That is why distros like open suse start at x.1, to trick morons like you.