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."
VMware tools included (Score:2)
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.
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: (Score:2)
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?
Re: (Score:3)
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.
Re: (Score:2)
Well, I use VNC or remote desktop for windows guests, running on the guests for those. I find I get a better mouse+cut and paste behavior and decent graphics and I do not have to be logged into the host to access the guests GUI.
I have to admit that I never used sound support and maybe graphic acceleration neither. I develop all day working on guests that I access either with VNC or remote desktop although and it works just fine with no VM tools installed.
Re: (Score:2)
Sure, I've used VNC and RDP with VMs as well. It all depends on what I want out of a given VM.
Re: (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 th
Re: (Score:2)
As far as I know, VMware tools doesn't provide any filesystem paravirtualization. It will improve mouse and video performance and implement some memory management tools to help the hypervisor know what used memory is active vs. inactive, memory ballooning and time sync.
I think disk virtualization is a pretty simple mapping of SCSI block access to the virtual disk file. I've run a number of FreeBSD systems on ESX without any issues of growing disk files.
The only issues I've ever had on VMware have been wi
Re: (Score:2)
Running NTP on ESX guests is often nasty and a great reason to use the vmware-tools:
vmware-toolbox-cmd timesync status
vmware-toolbox-cmd timesync enable
Re: (Score:2)
You forgot the Network optimization. Moving from essentially a 10meg nic to a gigabit with drivers in Vmware Tools.
Re: (Score:2)
You only need that if you're going to run the vmxnet3 interface.
The e1000 virtual NIC is supported without any problems with the em driver in FreeBSD. ESXi generally reports a link speed at the maximum throughput the driver supports (ifconfig shows 1000Mbit for me on two FreeBSD guests), but this is just a reported link speed.
IIRC, the *actual* throughput capable isn't limited to this reported link speed, although there may be limits imposed by the way the driver in the guest implements timing and interrup
Re:VMware tools included (Score:4, Interesting)
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.
Re: (Score:2)
VMware tools give you the balloon driver in the guest, which massively improves memory utilisation between guests. It also enables VMware to tell a VM that it's host is under pressure, and essentially "asks" the VM to start paging stuff out that is not active(via the balloon driver consuming memory on the guest, forcing it to swap. The memory "used" by the balloon is memory VMware knows it can re-allocated).
If you do not have the VM tools installed, VMware has no way of telling its guest it is under me
Outstanding (Score:4, Interesting)
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!
Re: (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: (Score:2)
ZFS has been dangerous for me on many occassions. FYI
Re: (Score:2)
The alternative is to store data without checksums, and that is also dangerous. With ZFS at least you know it when your data is toast.
Re: (Score:2)
ZFS now is pretty solid, but there were some interesting teething problems with ZFS. The rule of thumb that filesystems people tell me is that it takes 10 years for a new FS to be solid. ZFS is now 9 years old, so is very close...
In early versions, there was a problem that a write, including a delete, would cause the filesystem to grow (if it's a delete, it would then shrink) and you could get into a state if you let your filesystem (almost) completely fill up where you didn't have enough space to be abl
Re: (Score:2)
Re: (Score:1)
Agreed. ZFS is a lifesaver when you're needing a robust trusted filesystem. There is nothing at present in Linux that comes close. It's not lost on me that BSD is chosen as the embedded OS for mission-critical infrastructure applicances. Linux has some of this market, but mostly in the entertainment sector. Even BSD in the Playstation.
Re: (Score:2)
I've run the ZFS kernel module for a while. No crashes or other issues.
I wish FreeBSD had a decent VM server/hypervisor (Score:1)
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.
Re:I wish FreeBSD had a decent VM server/hyperviso (Score:5, Informative)
Re: (Score:2)
Re: (Score:3)
Exactly. Versus a properly configured host, It's a "difference" drummed up out of thin air so they can sell you "security".
Re:I wish FreeBSD had a decent VM server/hyperviso (Score:5, Insightful)
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.
Re: (Score:2)
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 dist
Re: (Score:2)
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.
Re: (Score:3)
Re: (Score:2)
I agree...FreeBSD seems like a great Xen host.
Re: (Score:3)
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 acro
Re: (Score:2)
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: 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: (Score:2)
Back in the stone age when I ran a lot of FreeBSD -- say 4.x days -- there was a preference for installing ports instead of packages. The reason given was that compiling source on the target system provided maximum compatibility. Has the FreeBSD community shifted any, in favor of using packages (pre-compiled binaries)? Does the package installer pull in dependencies, and update them as needed, the way portupgrade does?
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: (Score:3)
Before upgrading, read the Errata (Score:1)
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 [freebsd.org]
Some of these might come as a shock to readers, especially the killall argv parsing bug and the ipfw fwd link-layer bug.
Re: (Score:2)
Wow, you weren't joking!
* A bug in killall(1) has been discovered. It makes killall -INT to deliver SIGTERM rather than the desired SIGINT, and may cause blocking behavior for scripts that uses it, as -I means âoeinteractiveâ. A workaround of this would be to use -SIGINT instead. This bug has been fixed on FreeBSD-CURRENT and will be fixed in FreeBSD 10.0-STABLE.
* A regression in pw(8) does not remove a user from groups not specified in the provided group list when the -G flag is used. This is expected to be corrected in FreeBSD-CURRENT and FreeBSD 10.0-STABLE.
* ipfw(8) fwd action can send packets to the correct interface with a wrong link-layer address when the route is updated. This bug has been fixed on FreeBSD-CURRENT and will be fixed in FreeBSD 10.0-STABLE.
Bugs in killall() and pw()? Wow.
FreeBSD... (Score:3)
...that's the one that's a bit like Linnux but not quite, right?
Re: (Score:2)
no that's solaris 11
Re: (Score:2)
Hehe, I used to move config files between my Solaris 9 system and the RH based release we were developing for desktop use at a large networking company, ~80% of the time the config would work without modification.
Re: (Score:2)
same thing wonkey_monkey said
Re: (Score:2)
Includes strengthened cryptography (Score:4, Interesting)
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.
Re: (Score:1)
Re: (Score:3)
Re: (Score:2)
That alone is enough to turn me into a rapid FreeBSD supporter.
Rabid perhaps? ;)
Gluster? (Score:1)
Re: (Score:2)
You've given me an interesting thought - if time permits I might try it to see what happens.
Re: (Score:3)
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.
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: (Score:2)
OpenBSD's goal is security above all else.
This phrasing implies that FreeBSD doesn't care about security, which is somewhat misleading. Take a look at the number of papers at Oakland that use FreeBSD as a base and the number of those that we've accepted into the base system sometime.
For example, FreeBSD has a modular mandatory access control framework with pluggable policies. This is used by some downstream projects for things like the OS X / iOS sandboxing subsystem and the JunOS code signing infrastructure. It's also used for the type enforc
Re: (Score:1)
Capsicum, POSIX and NFS4 ACLs are all about adding complexity to allow for greater administrative policy enforcement. To put the OpenBSD point of view into perspective with a modern example, this is exactly the kind of policy that makes NSA admins rest easy at night and exactly the kind of security that allows Edward Snowden to secretly make out with 200,000 top secret documents. Real security means the software *does*what*it*promises* which a large and complex administrative policy enforcement system can a
Re:Quality vs OpenBSD? (Score:4, Interesting)
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.
Re: (Score:2)
Re: (Score:3, Interesting)
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, includin
Re: (Score:2)
OpenBSD also has a lot less functionality.
It's a trade-off - you decide what your requirements are and you make your choice.
For me, FreeBSD is "good enough" in terms of security (track record is pretty good), and has functionality that I require on some machines, that OpenBSD does not. Your mileage may vary. For me, shared knowledge across all my *NIX systems is a big plus, so I've standardized on FreeBSD unless there are vendor support requirements that dictate Linux.
Re: (Score:2)
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.
Re: (Score:1)
Ahh...the downside of allowing anonymous posting.
For my amusement, please tell me you actually believe this and aren't trolling.
Re:Never use a .0 (Score:4, Insightful)
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.
NIMFY (Score:5, Interesting)
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.
Re:NIMFY (Score:5, Insightful)
To each his own but X.0 releases in the BSD world are pretty stable things. Sure, wait a couple weeks just to be on the safe side but if there aren't any real horror stories then upgrade - 10.1 will not be around for some time. BSD is not like Linux - even point releases can be a year apart.
Re: (Score:1)
I think waiting is probably the safe way to go this time around. 10x has some very aggressive changes compared to other releases. Not as bad as 4x to 5x, but I've hit some fairly severe problems on some systems (not all just some). Thus far it hasn't been anything I couldn't fix, but it certainly has led to additional downtime. That's fine for test migrations, but I'm probably going to hold out for 9.3 to 10.1 otherwise.
Re: (Score:1)
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.
Re: (Score:2)
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.
Sounds like it would be much easuier/quicker to compile the ports tree elsewhere and then copy it back, or if you can't do that, temporarily transplant the disk into a fast machine.
Re: (Score:2)
Re: (Score:3)
But first test your backups.
Always a good idea. Not as good as a back-up, but you can snapshot your current system and rollback to that exact snapshot if bad things happen. One of the beautiful parts of ZFS on root.
Re: (Score:3)
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
other projects just increment numbers without any radical changes. OpenBSD for example just slowly increments by 0.1
Re: (Score:3)
Re: (Score:2)
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.
Re: (Score:3)
http://www.gnu.org/distros/common-distros.html#BSD [gnu.org]
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.
Re: (Score:2)
BSD is free by any rational definition.
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
The differences do have significance. The differences can be usefully and rationally discussed back and forth. What impresses me is that one side in the divide gets off on dissing the other, but it's not reciprocal.
Re: (Score:2)
The idea of "forced freedom" is a bit funny if you think about it, yeah, but we live in a (justly) cynical world.
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
--That's not the point. USB3 is now becoming common hardware, and needs to be supported as such. God, I hate elitist answers like the one you just gave. " YOU'RE doing it wrong... " No!! It's 2014 FFS, Freebsd has several years of catching up just to get close to where Linux is NOW.
--Ten minutes of experimenting with the latest Freebsd10--64 DVD install ISO and Vmware Player revealed several obvious bugs in the installer. I had to trash the VMDK entirely and start over after the install bombed because it w
Re: (Score:2)
p.s. - more on Freebsd's /dev/disk.
--Look it up**, the *recommended* way to discover disks in Freebsd is to grep 'dmesg' for da* and ad* entries. There are multiple different ways to do this simple thing in Linux, which also provides more information as a bonus:
o ' fdisk -l ', /dev/disk/by-id|grep sdX '.
o ' blkid ', even
o ' ls -al
** Google " freebsd list disks ". Srsly, the mind boggles.
--Truly this is a sorry state of affairs, and nobody seems interested in making it better on the Freebsd side. This is mak
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
--I appreciate your responses. Just saying that there are a lot of good things that Linux is doing (and has done for years) that Freebsd would do well to incorporate. God knows how many people get to know Linux, then want to try Freebsd (like I did) for $featureset and end up getting frustrated because it seems way primitive in comparison. PCBSD gets this to a certain extent, but they still suffer from lack of testing and compatibility with various system chipsets. I get on the forums and let them know, but
Re: (Score:2)
Yeah, comparing a typical Linux distro to FreeBSD is a little bit "unfair" for lack of a better word, unless the distro is LFS or Gentoo stage 2 (? its been a while).
If you're going to compare Fedora, Ubuntu, Mint, etc. the better comparison is PC-BSD as they are aimed at similar users.
Whilst Linux has a bunch of interesting work, so does the FreeBSD code-base - capsicum, dtrace, zfs, grand central, clang, beadm, etc. Also, for a light-weight multi-platform box, FreeNAS 9.1 plus jails = awesome. Poin
Re: (Score:2)
Capsicum is a lightweight OS capability and sandbox framework implementing a hybrid capability system model. Capsicum can be used for application and library compartmentalisation, the decomposition of larger bodies of software into isolated (sandboxed) components in order to implement security policies and limit the impact of software vulnerabilities.
That there's a BSD system component named after the primary component of a pepper that causes pain (okay, capsaicin, but whatever) makes me laugh, and wonder whether the name is as apropos as it sounds.
Re: (Score:2)
They don't even install BASH by default yet.
Ouch. What is there instead, dash?
Re: (Score:2)
csh. (shudderz)
Re: (Score:2)
Oh God.
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
Other points... Xorg is available as a package (no you do not need to compile), VMware does not yet support FreeBSD 10, ZFS is NOT recommended for use in a virtual environment.
If you're setting up a desktop, you're better off with PC-BSD anyway.
On the contrary, I just (last night in fact) installed PC-BSD 10 pre-release (2014-01-25 nightly build) on bare metal on my Core i5-4430 with GT760 NVidia card and everything was detected and worked out of the box. It was essentially the same experience I had w