Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!


Forgot your password?
Programming Software BSD

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."
This discussion has been archived. No new comments can be posted.

FreeBSD 10.0 Released

Comments Filter:
  • by Anonymous Coward on Monday January 20, 2014 @01:42PM (#46015439)

    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. "

  • by Anonymous Coward on Monday January 20, 2014 @01:43PM (#46015447)

    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.

  • by Bengie ( 1121981 ) on Monday January 20, 2014 @01:57PM (#46015571)
    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.
  • by drussell ( 132373 ) on Monday January 20, 2014 @02:00PM (#46015605)

    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.

  • by Galactic Dominator ( 944134 ) on Monday January 20, 2014 @02:09PM (#46015677)

    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]

  • by Anonymous Coward on Monday January 20, 2014 @02:39PM (#46015985)

    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)

    by Anonymous Coward on Monday January 20, 2014 @02:42PM (#46016015)

    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.

  • by ducomputergeek ( 595742 ) on Monday January 20, 2014 @02:43PM (#46016029)

    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)

    by Anonymous Coward on Monday January 20, 2014 @05:36PM (#46018055)

    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)

    by archen ( 447353 ) on Monday January 20, 2014 @06:31PM (#46018675)

    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)

    by TheRaven64 ( 641858 ) on Monday January 20, 2014 @07:21PM (#46019175) Journal

    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.

"I will make no bargains with terrorist hardware." -- Peter da Silva