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

136 comments

  1. VMware tools included by Billly+Gates · · Score: 1

    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.

    1. Re: VMware tools included by Anonymous Coward · · 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.

    2. Re:VMware tools included by ls671 · · Score: 1

      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?

      --
      Everything I write is lies, read between the lines.
    3. Re:VMware tools included by dreamchaser · · 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?

      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.

    4. Re:VMware tools included by Anonymous Coward · · 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.

    5. Re:VMware tools included by ls671 · · Score: 1

      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.

      --
      Everything I write is lies, read between the lines.
    6. Re:VMware tools included by EasyTarget · · Score: 3, 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.

      --
      "Oops, I always forget the purpose of competition is to divide people into winners and losers." - Hobbes
    7. Re:VMware tools included by dreamchaser · · Score: 1

      Sure, I've used VNC and RDP with VMs as well. It all depends on what I want out of a given VM.

    8. Re:VMware tools included by swb · · Score: 1

      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 with time stability, and IIRC there's a HZ= kernel option that fixes this. Brute force NTP syncing worked too, although inelegant.

    9. Re:VMware tools included by smash · · Score: 1

      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 memory pressure, and the hypervisor will start swapping memory out itself - memory which the guest may be actively using.

      It also gives you better driver support.

      TLDR version: install the tools unless you are unable to.

      --
      I run: Windows, OS X, Linux, FreeBSD. Just because you have a hammer, doesn't mean everything is a nail.
    10. Re:VMware tools included by ptudor · · Score: 1

      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

    11. Re:VMware tools included by icebike · · Score: 1

      You forgot the Network optimization. Moving from essentially a 10meg nic to a gigabit with drivers in Vmware Tools.

      --
      Sig Battery depleted. Reverting to safe mode.
    12. Re:VMware tools included by swb · · Score: 1

      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 interrupt handling. Windows guests would often exceed this with the "flexible"/Vlance interface.

      The vmxnet3 interface is superior for very heavy network loads and supports functionality not found in the e1000 interface. I use this with Windows guests exclusively but usually stick to the e1000 in FreeBSD if I plan to avoid dealing with the tools install.

  2. Outstanding by Anonymous Coward · · 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!

    1. Re:Outstanding by Anonymous Coward · · 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.

    2. Re:Outstanding by Shaman · · Score: 1

      ZFS has been dangerous for me on many occassions. FYI

      --
      ...Steve
    3. Re:Outstanding by Anonymous Coward · · 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.

    4. Re:Outstanding by kthreadd · · Score: 1

      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.

    5. Re:Outstanding by 0100010001010011 · · Score: 1

      I've run the ZFS kernel module for a while. No crashes or other issues.

    6. Re:Outstanding by TheRaven64 · · Score: 1

      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 able to do the copy-on-write deletion and the only way to recover was to copy all of the data off, recreate the pool, and copy it back on. You didn't lose data, but you did lose the ability to write to the pool. There have also been some cases where data loss (including the entire pool) could happen, although those are far rarer.

      --
      I am TheRaven on Soylent News
    7. Re:Outstanding by smash · · Score: 1

      UFS, ext2, NTFS and FAT have been dangerous for me on many occasions. FYI

      --
      I run: Windows, OS X, Linux, FreeBSD. Just because you have a hammer, doesn't mean everything is a nail.
  3. I wish FreeBSD had a decent VM server/hypervisor by Anonymous Coward · · 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.

  4. pkg is the default "binary" package by Anonymous Coward · · 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. "

    1. Re: pkg is the default "binary" package by Galactic+Dominator · · Score: 4, 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

      --
      brandelf -t FreeBSD /brain
    2. Re: pkg is the default "binary" package by dunng808 · · Score: 1

      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?

      --

      Gary Dunn
      Open Slate Project

  5. Quality vs OpenBSD? by Anonymous Coward · · Score: 0

    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?

    1. Re:Quality vs OpenBSD? by ThorGod · · Score: 2

      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.
    2. Re:Quality vs OpenBSD? by Anonymous Coward · · 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, including myself. I will likely be buying the same machines that RMS uses from this point forward.

    3. Re:Quality vs OpenBSD? by ducomputergeek · · Score: 4, 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.

      --
      "The problem with socialism is eventually you run out of other people's money" - Thatcher.
    4. Re:Quality vs OpenBSD? by Anonymous Coward · · Score: 0

      I've never seen servers specifically being a goal for FreeBSD. It's targeted to all kinds of computers; servers, desktops, laptops, embeddeds.

    5. Re:Quality vs OpenBSD? by Anonymous Coward · · Score: 0

      To put it simpler...

      The goal of the OpenBSD project is to create a secure OS.

      The goal of the FreeBSD project is to create a usable OS.

    6. Re:Quality vs OpenBSD? by TheRaven64 · · Score: 1

      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 enforcement mechanism in FreeBSD and a few other things.

      FreeBSD has had jails for a long time, which are an easy way of creating a completely isolated environment (distinct root user, filesystem hierarchy, and so on), sharing the same kernel (so much cheaper than a VM). With ZFS and cheap clones, it's easy to keep a stock FreeBSD install around, clone it, and have a new jail up and running in a few seconds. Poudriere (French for Powderkeg), the package building program uses this mechanism to create a pristine environment for building each package, allowing untrusted intermediate binaries to be run on the build server without giving them any access to the host environment.

      In FreeBSD 10, Capsicum is enabled by default in the kernel, and a number of base system utilities are sandboxed out of the box. Capsicum sandboxing means that things run without the ability to create file descriptors and have to request a more-privileged daemon pass them the ones that they need. For example, tcpdump (which doesn't have the best security record in the world and is often used to inspect malicious network traffic) runs in compartmentalised mode and just delegates DNS lookups to a daemon that runs outside of the sandbox. The daemon only accepts records in fixed formats (IP addresses) and returns a string, so it has a very small attack surface.

      FreeBSD supports both POSIX and NFSv4 ACLs, for people who want finer-grained filesystem security. With 10 (and, I think, 9.2?), the audit log daemon is complemented by auditdistd, which allows you to distribute cryptographically signed audit logs across machines, allowing you to detect suspicious activity.

      The binary packages that we're distributing are signed, by a key that is distributed via a different mechanism to the packages, and the pkg audit command allows you to display known vulnerabilities in any of your installed third-party packages.

      --
      I am TheRaven on Soylent News
    7. Re:Quality vs OpenBSD? by chriscappuccio · · 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 almost never do.

      In OpenBSD, security means that you eliminate bugs so that the most basic promise is held true. Adding complexity almost always does the opposite. We are talking about two completely different ideas of "security" here. This is not to say that ACL systems have no place, but rather, the systems that are smaller, easier to audit and easier to implement are going to find a place in OpenBSD long before the large and unwieldy systems could ever be incorporated.

      That being said, FreeBSD 10 was the first FreeBSD system to distribute signed packages. OpenBSD 5.5 will be the first version of OpenBSD that distributes a signed base, signed firmware and signed packages. The code is small, the benefit is clear, and the implementation (at least in OpenBSD) is obvious.

    8. Re:Quality vs OpenBSD? by smash · · Score: 1

      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.

      --
      I run: Windows, OS X, Linux, FreeBSD. Just because you have a hammer, doesn't mean everything is a nail.
    9. Re:Quality vs OpenBSD? by chriscappuccio · · Score: 1

      OpenBSD turns on a number of security features by default that FreeBSD avoids for really early backward binary compatibility (or just plain laziness). The newest feature in OpenBSD 5.5 is PIE-by-default executables on major platforms. Even Microsoft Windows implements more than FreeBSD! See Theo deRaadt's talk slides http://tech.yandex.com/events/ruBSD/2013/talks/103 for some more examples.

    10. Re:Quality vs OpenBSD? by chriscappuccio · · Score: 1

      OpenBSD has usability as a very high goal. I'd say it's more usable out of the box than FreeBSD, but that depends on what makes it usable for you...

    11. Re:Quality vs OpenBSD? by TheRaven64 · · Score: 3, 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.

      --
      I am TheRaven on Soylent News
    12. Re:Quality vs OpenBSD? by chriscappuccio · · 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.

    13. Re:Quality vs OpenBSD? by unixisc · · Score: 1

      PC-BSD is the FreeBSD distro targeted at desktops & laptops. FreeBSD itself is targeted at servers. I'm not sure whether any FreeBSD distro is targeted at embeddeds

  6. Re:I wish FreeBSD had a decent VM server/hyperviso by Bengie · · Score: 4, Informative

    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.

  7. Actually 10.0 is pretty good... by drussell · · 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.

    1. Re:Actually 10.0 is pretty good... by Anonymous Coward · · Score: 0

      I usually just
          - stop daemons
          - back up and mv data, config files and databases
          - pkg_delete -f -a; rm -rf /var/db/pkg /var/db/ports /usr/local
          - update ports tree, install needed ports
          - merge config files, mv back data and databases
          - start daemons

      Saves lots of headaches

    2. Re:Actually 10.0 is pretty good... by TheRaven64 · · Score: 2

      With 10.0, you most likely want to be using binary packages, either from FreeBSD.org, or by rolling your own with poudriere. If you're used to using ports with custom options, the best thing to do is install poudriere and put all of the configuration options in a make.conf, dump the installed package list to a file, and then use poudriere bulk to build that set. You can then point pkg at the local repository and install things. Ideally, make a cron job that updates the ports tree and reruns the build overnight, so you can update whenever you want.

      --
      I am TheRaven on Soylent News
  8. Re:I wish FreeBSD had a decent VM server/hyperviso by ThorGod · · Score: 1

    I agree...FreeBSD seems like a great Xen host.

    --
    PS: I don't reply to ACs.
  9. Re:BSD is dead! by Ralph+Wiggam · · Score: 0

    Ahh...the downside of allowing anonymous posting.

    For my amusement, please tell me you actually believe this and aren't trolling.

  10. Re:I wish FreeBSD had a decent VM server/hyperviso by wagnerrp · · Score: 1

    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?

  11. Re:I wish FreeBSD had a decent VM server/hyperviso by Galactic+Dominator · · Score: 2

    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 /brain
  12. Re:Never use a .0 by Sponge+Bath · · Score: 3, 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.

  13. Re:I wish FreeBSD had a decent VM server/hyperviso by Bengie · · Score: 4, Insightful

    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.

  14. Sounds interesting, but.. by Anonymous Coward · · Score: 0

    does USB 3.0 work properly yet?

    1. Re:Sounds interesting, but.. by smash · · Score: 1

      For the vast majority of FreeBSD installations, USB3 is entirely irrelevant.

      --
      I run: Windows, OS X, Linux, FreeBSD. Just because you have a hammer, doesn't mean everything is a nail.
    2. Re:Sounds interesting, but.. by Wolfrider · · Score: 1

      --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 was hopelessly stuck - even after a reboot, because it DIDN'T destroy all existing data on the (aborted install) ZFS root disk like it should. Increasing the VM RAM from 1GB to 1.5GB finally got a successful basic install, but DAMN they need to do some more basic testing before releasing this stuff to the general public. PCBSD has the same (lack of testing) problem.

      --Even after the install completed and switching to the new ' pkg ' system, I can't even get Xorg to install**. Still craptastic 80x25 text consoles, and the Delete key STILL doesn't even work as expected at the command prompt. They don't even install BASH by default yet. This is *pathetic.*

      ** What, you want me to *compile* Xorg on a 4GB RAM laptop in a VM? Sod off. And yes, I was following the official handbook.

      --Don't even get me started on the lack of decent /dev/disk entries, Linux kernel has /dev/disk/by-id that is making ZFS on *Linux* way more appealing these days. And this is coming from someone who had my main RAID server running PCBSD 9.0--64 + ZFS RAIDZ3 + Samba for a year and a half with an unrecoverably broken ports tree(due to an unavoidably ^C'ed compile), until I finally converted it to ZFS on Linux a couple of weeks ago. Package manglement was a nightmare compared to apt-get. I even tried giving Kfreebsd the benefit of the doubt for a couple of years, but that distro is a long way from even being home-user ready. Nobody is going to take them seriously until they can at least have a viable install in Vmware with everything working out of the box as expected.

      --I really want to be a fan of Free/PCBSD, but they arguably have a long way to go before they can even begin to match the current Linux comfort level. Srsly.

      --
      .
      == WolfriderV6 == I'm willing to admit that *I just might* be wrong... Are you??
    3. Re:Sounds interesting, but.. by Wolfrider · · Score: 1

      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 ',
      o ' blkid ', even
      o ' ls -al /dev/disk/by-id|grep sdX '.

      ** 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 making it difficult to have a sane naming scheme if you want to have a fairly large ZFS installation, since disk entries can change after a reboot. Even adopting Solaris' c1t1d1 method would be a start.

      --
      .
      == WolfriderV6 == I'm willing to admit that *I just might* be wrong... Are you??
    4. Re:Sounds interesting, but.. by TangoMargarine · · Score: 1

      They don't even install BASH by default yet.

      Ouch. What is there instead, dash?

      --
      Unity? Screw that: XFCE. Slashdot Beta? Screw that: SoylentNews. Australis? Screw that: Pale Moon. UX developers DIAF
    5. Re:Sounds interesting, but.. by Anonymous Coward · · Score: 0

      I use gpart for finding disks. And as far as drives being all over the map when you reboot, I don't have that problem. Something to do with labeling disks IIRC.

    6. Re:Sounds interesting, but.. by Wolfrider · · Score: 1

      csh. (shudderz)

      --
      .
      == WolfriderV6 == I'm willing to admit that *I just might* be wrong... Are you??
    7. Re:Sounds interesting, but.. by TangoMargarine · · Score: 1

      Oh God.

      --
      Unity? Screw that: XFCE. Slashdot Beta? Screw that: SoylentNews. Australis? Screw that: Pale Moon. UX developers DIAF
    8. Re:Sounds interesting, but.. by smash · · Score: 1

      I never said "you're doing it wrong". Just that for the 99% use case of FreeBSD, USB3 is entirely irrelevant, hence effort is put into things that are MORE relevant. Thus, "wake me up when it supports USB3" or whatever is just being a dick for the sake of it.

      --
      I run: Windows, OS X, Linux, FreeBSD. Just because you have a hammer, doesn't mean everything is a nail.
    9. Re:Sounds interesting, but.. by smash · · Score: 1

      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 with Ubuntu 13.10, except I got root on ZFS out of the box.

      --
      I run: Windows, OS X, Linux, FreeBSD. Just because you have a hammer, doesn't mean everything is a nail.
    10. Re:Sounds interesting, but.. by smash · · Score: 1

      Bash = GNU, and therefore not in the default install. it is available as a package, just like it is on Linux (the Linux package just happens to be installed by default).

      --
      I run: Windows, OS X, Linux, FreeBSD. Just because you have a hammer, doesn't mean everything is a nail.
    11. Re:Sounds interesting, but.. by smash · · Score: 1

      Yup, gpart list. Maybe the documentation needs updating.

      --
      I run: Windows, OS X, Linux, FreeBSD. Just because you have a hammer, doesn't mean everything is a nail.
    12. Re:Sounds interesting, but.. by smash · · Score: 1

      And yes, looks like the parent poster has a heap of gripes about FreeBSD because it doesn't work the Linux way. ZFS with gpart is entirely usable, and no you don't need to grep through dmesg. However, expecting FreeBSD to work like Linux, or Linux to work like FreeBSD will just end in tears. They are not the same and never will be.

      --
      I run: Windows, OS X, Linux, FreeBSD. Just because you have a hammer, doesn't mean everything is a nail.
    13. Re:Sounds interesting, but.. by smash · · Score: 1

      Oh and by the way. USB3 is supported in FreeBSD 10 anyway, just checked my box's dmesg. I hadn't noticed because I don't have any USB3 peripherals.

      --
      I run: Windows, OS X, Linux, FreeBSD. Just because you have a hammer, doesn't mean everything is a nail.
    14. Re:Sounds interesting, but.. by Wolfrider · · Score: 1

      --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 the last bug I posted there has been no response.

      --
      .
      == WolfriderV6 == I'm willing to admit that *I just might* be wrong... Are you??
    15. Re:Sounds interesting, but.. by smash · · Score: 1

      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. Point and click jail generation = far lighter weight than virtualization and most of the benefit - and your entire jail is able to be snapshotted/rolled back/etc. with ZFS.

      --
      I run: Windows, OS X, Linux, FreeBSD. Just because you have a hammer, doesn't mean everything is a nail.
    16. Re:Sounds interesting, but.. by Anonymous Coward · · Score: 0

      I did not use csh, but tcsh (also included - tcsh is to csh as bash is to sh) is actually quite nice, it only has ridiculous default settings with pretty much all features disabled by default. In terms of functionality it was actually ahead of bash, but bash 4 caught up and it has everything that I was previously missing in it.

      Still, since I would have to install bash, I just decided to move to zsh, but I still use tcsh for the root account.

    17. Re:Sounds interesting, but.. by TangoMargarine · · Score: 1

      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.

      --
      Unity? Screw that: XFCE. Slashdot Beta? Screw that: SoylentNews. Australis? Screw that: Pale Moon. UX developers DIAF
  15. Re:I wish FreeBSD had a decent VM server/hyperviso by Anonymous Coward · · Score: 0

    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.

  16. NIMFY by epine · · Score: 4, Interesting

    But if nobody runs it, you do not uncover bugs and you never get a .1 release.

    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.

    1. Re:NIMFY by Lawrence_Bird · · 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.

    2. Re:NIMFY by archen · · 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.

    3. Re:NIMFY by Anonymous Coward · · 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.

    4. Re:NIMFY by Bengie · · Score: 2

      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.

    5. Re:NIMFY by archen · · 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.

    6. Re:NIMFY by TheRaven64 · · Score: 3, 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.

      --
      I am TheRaven on Soylent News
    7. Re:NIMFY by TheRaven64 · · Score: 2

      The down side is that 10 uses a newer version of the ZFS on-disk format that 9 can't load. I managed to hit this, accidentally doing an installkernel with a custom kernel config from a 9-STABLE tree just after doing a binary update to 10-RC3. The 9 kernel couldn't mount the 10 ZFS root, and I then had to find a bootable 10 CD (it turns out the machine I did this on can't boot from USB) to reinstall the 10 kernel. Worst of all, I discovered that the kernel option I wanted actually was in the default config in 10, I just didn't think it was because I'd told freebsd-update not to update my src tree to speed up the updates. A whole sequence of operator errors, and fortunately a recoverable one (once I'd replaced the kernel with the one from the CD, it worked perfectly).

      --
      I am TheRaven on Soylent News
    8. Re:NIMFY by smash · · Score: 0

      So, just how long have you been running 10.0 RELEASE?

      --
      I run: Windows, OS X, Linux, FreeBSD. Just because you have a hammer, doesn't mean everything is a nail.
    9. Re:NIMFY by serviscope_minor · · Score: 1

      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.

      --
      SJW n. One who posts facts.
    10. Re:NIMFY by drussell · · Score: 1

      I managed to hit this, accidentally doing an installkernel with a custom kernel config from a 9-STABLE tree just after doing a binary update to 10-RC3. The 9 kernel couldn't mount the 10 ZFS root, and I then had to find a bootable 10 CD (it turns out the machine I did this on can't boot from USB) to reinstall the 10 kernel.

      Couldn't you just have booted from kernel.old?

    11. Re:NIMFY by TheRaven64 · · Score: 1

      That's created by freebsd-update, not by installkernel, and so was also a 9.x kernel in my case.

      --
      I am TheRaven on Soylent News
    12. Re:NIMFY by drussell · · Score: 1

      That's strange... make installkernel does back it up to .old when I do it here. Just tried it again to be sure. :)

    13. Re:NIMFY by archen · · Score: 1

      9x Generic wouldn't boot on the laptop. Something always got hung up in the process, and it appeared to be something with the hard drive. When I did an upgrade from source from 8 to 9 everything worked just fine. I messed with a few options trying to figure out the exact issue, but decided it wasn't worth the effort or a bug report for some buggy decade old laptop.

      Also if anyone read my previous post, I'm fairly sure clang doesn't compile properly for a Geode LX if the cputype is set to k6-2. I tried k6 as well and that didn't work either. I unset cputype and let it go to the default and it works fine. If you have such a processor and set cputype in make.conf, I'd test compile something (using clang) to make sure it works. This was on a Soekris Engineering net 5501

    14. Re:NIMFY by Freultwah · · Score: 1

      The newer kernel does not convert the zpools automatically to the newer on-disk format.

    15. Re:NIMFY by smash · · Score: 1

      That said, .0 releases in FreeBSD do not get supported for as long as the other point releases, and the .1s generally tend to get longer support than the rest.

      --
      I run: Windows, OS X, Linux, FreeBSD. Just because you have a hammer, doesn't mean everything is a nail.
    16. Re:NIMFY by smash · · Score: 1

      The big reason I avoid .0 releases in FreeBSD is not due to stability or bugs, but due to support time-frame. .0 is not supported anywhere near as long as .1.

      --
      I run: Windows, OS X, Linux, FreeBSD. Just because you have a hammer, doesn't mean everything is a nail.
  17. Before upgrading, read the Errata by Anonymous Coward · · 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

    Some of these might come as a shock to readers, especially the killall argv parsing bug and the ipfw fwd link-layer bug.

    1. Re:Before upgrading, read the Errata by lgw · · Score: 1

      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.

      --
      Socialism: a lie told by totalitarians and believed by fools.
  18. Re:Never use a .0 by iggymanz · · Score: 1

    other projects just increment numbers without any radical changes. OpenBSD for example just slowly increments by 0.1

  19. FreeBSD... by wonkey_monkey · · Score: 2

    ...that's the one that's a bit like Linnux but not quite, right?

    --
    systemd is Roko's Basilisk.
    1. Re:FreeBSD... by Anonymous Coward · · Score: 0

      Not really. It's more like Unix, for some definition of Unix.

    2. Re:FreeBSD... by Anonymous Coward · · Score: 0

      Nah. It is the one not trying to forfeit networking features to become a desktop OS.

    3. Re:FreeBSD... by BestNicksRTaken · · Score: 1

      no that's solaris 11

      --
      #include <sig.h>
    4. Re:FreeBSD... by afidel · · Score: 1

      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.

      --
      There are 4 boxes to use in the defense of liberty: soap, ballot, jury, ammo. Use in that order. Starting now.
    5. Re:FreeBSD... by drussell · · Score: 1

      ...that's the one that's a bit like Linnux but not quite, right?

      Why would it want to be Linux? Linux is the one that's not quite BSD. :)

    6. Re:FreeBSD... by doti · · Score: 1

      same thing wonkey_monkey said

      --
      factor 966971: 966971
    7. Re:FreeBSD... by unixisc · · Score: 1

      X vs Wayland is irrelevant to the Linux vs BSD debate

  20. Is freebsd free yet however? by Anonymous Coward · · Score: 0
    1. Re:Is freebsd free yet however? by Anonymous Coward · · Score: 0

      In that you're free to do whatever the fuck you want with it, and not encumbered by the GPL, yes.

    2. Re:Is freebsd free yet however? by kthreadd · · Score: 2

      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.

    3. Re:Is freebsd free yet however? by Anonymous Coward · · Score: 0

      Give up on those people; they're the ones who don't know the difference between 'then' and 'than'. Something actually complex like freedom? You'd be better off talking to a stone.

    4. Re:Is freebsd free yet however? by Anonymous Coward · · Score: 0

      FreeBSD, NetBSD, and OpenBSD all include instructions for obtaining nonfree programs in their ports system.

      If you ever talk about non-free software, the FSF will declare you to be "nonfree". You are free to say exactly what they tell you to say.

    5. Re:Is freebsd free yet however? by vinehair · · Score: 1

      The whole debate about what is actually 'free' software is hilarious and comes down to miniscule differences in dogma. It's pathetic.

    6. Re:Is freebsd free yet however? by smash · · Score: 1

      So RMS writes his own hard drive firmware, yeah?

      --
      I run: Windows, OS X, Linux, FreeBSD. Just because you have a hammer, doesn't mean everything is a nail.
    7. Re:Is freebsd free yet however? by fnj · · Score: 1

      BSD is free by any rational definition.

    8. Re:Is freebsd free yet however? by fnj · · Score: 1

      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.

    9. Re:Is freebsd free yet however? by TangoMargarine · · Score: 1

      The idea of "forced freedom" is a bit funny if you think about it, yeah, but we live in a (justly) cynical world.

      --
      Unity? Screw that: XFCE. Slashdot Beta? Screw that: SoylentNews. Australis? Screw that: Pale Moon. UX developers DIAF
    10. Re:Is freebsd free yet however? by unixisc · · Score: 1

      They are Free even by the FSF definitions. What they are not is that they are not CopyLeft. That is a different beast

    11. Re:Is freebsd free yet however? by unixisc · · Score: 1

      If the firmware can be moved from Flash to ROM, RMS will redefine it as 'hardware' and then it won't have to fall under the definition of 'free'. Or 'libre', as they prefer saying in non-English

  21. Re:Never use a .0 by TheRaven64 · · Score: 2

    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
  22. Re:I wish FreeBSD had a decent VM server/hyperviso by TheRaven64 · · Score: 1

    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
  23. Re:I wish FreeBSD had a decent VM server/hyperviso by TheRaven64 · · Score: 2

    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
  24. Re:Never use a .0 by Anonymous Coward · · Score: 0

    Why? This isn't Linux you know.

  25. observability by Anonymous Coward · · Score: 0

    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.

  26. Includes strengthened cryptography by johnjaydk · · Score: 3, 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.

    --
    TCAP-Abort
    1. Re:Includes strengthened cryptography by Anonymous Coward · · Score: 1

      I'm all pro-BSD as the rest, but I thought Linux has also been doing very well on this front.

    2. Re:Includes strengthened cryptography by chriscappuccio · · Score: 1

      OpenBSD has kept the Intel hardware RNG at play to increase entropy, yet at bay as a primary entropy source, for years since RDRNG was introduced. It takes a similar approach throughout the system.

    3. Re:Includes strengthened cryptography by plasticsquirrel · · Score: 2

      You do know that Linux and OpenBSD always used this method, right? FreeBSD was relying too much on hardware random number generation. Now they are finally catching up. If anything, it should make people wary of FreeBSD security.

      --
      Systemd: the PulseAudio of init systems
    4. Re:Includes strengthened cryptography by strikethree · · Score: 1

      That alone is enough to turn me into a rapid FreeBSD supporter.

      Rabid perhaps? ;)

      --
      "Someone needs to talk to the tree of liberty about its ghoulish drinking problem." by ohnocitizen
  27. Gluster? by pooh666 · · Score: 0

    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"

    1. Re:Gluster? by armanox · · Score: 1

      You've given me an interesting thought - if time permits I might try it to see what happens.

      --
      I'm starting to think GNU is the problem with "GNU/Linux" these days.
  28. Re:I wish FreeBSD had a decent VM server/hyperviso by Bengie · · Score: 1

    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.

  29. Re:I wish FreeBSD had a decent VM server/hyperviso by TheRaven64 · · Score: 2

    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
  30. I guess,... very many people by koinu · · Score: 1

    Since FreeBSD is one of the top distributions, even appearing on Linux-centric sites as mentionable: http://distrowatch.com/dwres.p...

  31. Re:Never use a .0 by TangoMargarine · · Score: 1

    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
  32. opencl by trigggl · · Score: 1

    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.
  33. ZFS on Raspberry PI by jcea · · Score: 1

    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?

  34. ZFS on Raspberry PI by jcea · · Score: 1

    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?

  35. Re:I wish FreeBSD had a decent VM server/hyperviso by unixisc · · Score: 1

    Does FreeBSD/PC-BSD have anything like a QEMU/KVM?

  36. clang by default by Anonymous Coward · · Score: 0

    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.

  37. drrp by Anonymous Coward · · Score: 0

    That is why distros like open suse start at x.1, to trick morons like you.