FreeBSD 10.0 Released 136
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."
pkg is the default "binary" package (Score:1, Informative)
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. "
Re: VMware tools included (Score:2, Informative)
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.
Re:I wish FreeBSD had a decent VM server/hyperviso (Score:5, Informative)
Actually 10.0 is pretty good... (Score:3, Informative)
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.
Re: pkg is the default "binary" package (Score:5, Informative)
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 [freebsd.org]
Re:VMware tools included (Score:2, Informative)
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.
Re:Outstanding (Score:3, Informative)
ZFS is reason alone to use BSD in critical data storage situations, as far as I'm concerned.
Linux ZFS implementation is severely lacking in stability and features.
Of course, some Oracle products have ZFS features that BSD in turn lacks, but I can do without those.
Re:Quality vs OpenBSD? (Score:5, Informative)
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.
Re:NIMFY (Score:0, Informative)
Please post with concrete examples rather than saying "I've hit some fairly severe problems on some systems". You are simply sowing FUD and probably lying if you are unable to specify what you're talking about.
Re:NIMFY (Score:5, Informative)
I haven't found an elegant way to migrate to iconv going into the base system aside from plowing through a reinstall of ports.
One laptop I have which is very old has 128Mb of RAM and a P3m. I've never had a problem building the system, until clang entered the picture (which I just worked around in 9x by not building clang). Gcc compiles Gcc fine. Clang compiles Clang fine. Gcc compiling clang hits swap very hard and it literally takes days to compile. It bombed out once or twice, and my last attempt I just decided to let it go even though I thought the system was hung. Since then I've had no problems rebuilding the system, and with clang as the default compiler it takes about as long as before so that appears to have been a one time situation.
I have a virtualized web server I've had around since 8x. The network interface has always been em0, but with xen support the name changed to xn0 (leading to no networking). As I've never seen the network interface name change, that wasn't an expected issue.
I'm not 100% sure, but compiling with clang for an AMD Geode (LX) processor using the k6-2 seems to lead to a broken build (which is what I've used with GCC for quite a while) Still working through this at the moment. Plugging the drive into an Athlon X2 and everything works, so I suspect this is the issue.
Re:NIMFY (Score:4, Informative)
For the P3, I'd recommend using freebsd-upgrade and pkg, unless you really need a custom kernel. You can also do make toolchain on a faster machine and then copy your obj tree across and use the XDEV stuff if you really need to be building kernel and world on it.
The en0 becoming xn0 thing surprised me too, when I switched from a GENERIC kernel to a XENHVM one on 9.0. With 10.0, I think we're compiling the Xen HVM drivers into the GENERIC kernel, so you'll get the new devices. In the Xen block device drivers, I think there's some extra magic so that they'll appear with a different device node name if the device was previously used with the emulated devices, but that isn't present in the network drivers, which I think is a shame.
For the Geode, it shouldn't be an issue since September. Prior to that, clang would emit long nops for some things that would break the Geode.