×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

FreeBSD 10.0 Released

samzenpus posted about 2 months ago | from the brand-new dept.

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

cancel ×
This is a preview of your comment

No Comment Title Entered

Anonymous Coward 1 minute ago

No Comment Entered

136 comments

Never use a .0 (-1)

Anonymous Coward | about 2 months ago | (#46015361)

I'll wait for the x.1 release

Re:Never use a .0 (3, Insightful)

Sponge Bath (413667) | about 2 months ago | (#46016003)

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 (4, Interesting)

epine (68316) | about 2 months ago | (#46016119)

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.

Re:NIMFY (5, Insightful)

Lawrence_Bird (67278) | about 2 months ago | (#46017141)

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:NIMFY (1)

archen (447353) | about 2 months ago | (#46017939)

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:NIMFY (0, Informative)

Anonymous Coward | about 2 months ago | (#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 (5, Informative)

archen (447353) | about 2 months ago | (#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 (3, Informative)

TheRaven64 (641858) | about 2 months ago | (#46019175)

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:NIMFY (1)

serviscope_minor (664417) | about 3 months ago | (#46022339)

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:NIMFY (2)

Bengie (1121981) | about 2 months ago | (#46018423)

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:NIMFY (2)

TheRaven64 (641858) | about 3 months ago | (#46020409)

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

Re:NIMFY (1)

drussell (132373) | about 3 months ago | (#46022885)

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?

Re:Never use a .0 (1)

iggymanz (596061) | about 2 months ago | (#46016193)

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

Re:Never use a .0 (2)

TheRaven64 (641858) | about 2 months ago | (#46016711)

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.

Re:Never use a .0 (0)

Anonymous Coward | about 2 months ago | (#46017033)

Why? This isn't Linux you know.

VMware tools included (1)

Billly Gates (198444) | about 2 months ago | (#46015387)

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 (2, Informative)

Anonymous Coward | about 2 months ago | (#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.

Re:VMware tools included (1)

ls671 (1122017) | about 2 months ago | (#46015715)

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:VMware tools included (2)

dreamchaser (49529) | about 2 months ago | (#46015875)

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:VMware tools included (1)

ls671 (1122017) | about 2 months ago | (#46016055)

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:VMware tools included (1)

dreamchaser (49529) | about 2 months ago | (#46016403)

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

Re:VMware tools included (2, Informative)

Anonymous Coward | about 2 months ago | (#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:VMware tools included (1)

swb (14022) | about 2 months ago | (#46016921)

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.

Re:VMware tools included (1)

ptudor (22537) | about 3 months ago | (#46020783)

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:VMware tools included (1)

icebike (68054) | about 3 months ago | (#46020913)

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

Re:VMware tools included (3, Interesting)

EasyTarget (43516) | about 2 months ago | (#46016273)

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:VMware tools included (1)

smash (1351) | about 3 months ago | (#46020685)

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.

BSD is dead! (-1)

Anonymous Coward | about 2 months ago | (#46015391)

Proof that BSD is dead!

Re:BSD is dead! (-1)

Anonymous Coward | about 2 months ago | (#46015415)

Incorrect - Almost all of this can be attributed to UN Agenda 21 (please Google or Wikipedia this if you are unsure what it is). It is nothing more or less than a plot to subsume all of the world's cultures into a single overriding World Government - a prize that the far left has had in their sights for a long, long time. We must be relentless in our quest to foil the socialist dream - to stomp it into the ground where it belongs. Wealth redistribution from the Wealthy Capitalist Countries to the third world socialist hovels is the ultimate goal of Agenda 21 - and something that has been signed onto full-bore by the people who do not want to better themselves through hard work. Hard work is anathema to people like this - they would rather you did the hard work, and just give them their allowance on a silver platter.

Re:BSD is dead! (0)

Ralph Wiggam (22354) | about 2 months ago | (#46015753)

Ahh...the downside of allowing anonymous posting.

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

Re:BSD is dead! (-1)

Anonymous Coward | about 2 months ago | (#46016221)

I actually believe this and amn't trolling.

Outstanding (4, Interesting)

Anonymous Coward | about 2 months ago | (#46015421)

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:Outstanding (3, Informative)

Anonymous Coward | about 2 months ago | (#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.

Re:Outstanding (1)

Shaman (1148) | about 2 months ago | (#46016825)

ZFS has been dangerous for me on many occassions. FYI

Re:Outstanding (1)

kthreadd (1558445) | about 2 months ago | (#46016927)

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:Outstanding (1)

TheRaven64 (641858) | about 3 months ago | (#46020443)

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.

Re:Outstanding (1)

Anonymous Coward | about 2 months ago | (#46016859)

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.

I wish FreeBSD had a decent VM server/hypervisor (1)

Anonymous Coward | about 2 months ago | (#46015435)

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 (4, Informative)

Bengie (1121981) | about 2 months ago | (#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.

Re:I wish FreeBSD had a decent VM server/hyperviso (1)

wagnerrp (1305589) | about 2 months ago | (#46015851)

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?

Re:I wish FreeBSD had a decent VM server/hyperviso (2)

Galactic Dominator (944134) | about 2 months ago | (#46015897)

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 (4, Insightful)

Bengie (1121981) | about 2 months ago | (#46016033)

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.

Re:I wish FreeBSD had a decent VM server/hyperviso (0)

Anonymous Coward | about 2 months ago | (#46016113)

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.

Re:I wish FreeBSD had a decent VM server/hyperviso (1)

TheRaven64 (641858) | about 2 months ago | (#46016829)

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.

Re:I wish FreeBSD had a decent VM server/hyperviso (1)

Bengie (1121981) | about 2 months ago | (#46018353)

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:I wish FreeBSD had a decent VM server/hyperviso (2)

TheRaven64 (641858) | about 2 months ago | (#46019117)

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.

observability (0)

Anonymous Coward | about 2 months ago | (#46017411)

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.

Re:I wish FreeBSD had a decent VM server/hyperviso (2)

TheRaven64 (641858) | about 2 months ago | (#46016917)

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.

pkg is the default "binary" package (1, Informative)

Anonymous Coward | about 2 months ago | (#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. "

Quality vs OpenBSD? (0)

Anonymous Coward | about 2 months ago | (#46015475)

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?

Re:Quality vs OpenBSD? (2)

ThorGod (456163) | about 2 months ago | (#46015683)

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? (4, Informative)

ducomputergeek (595742) | about 2 months ago | (#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:Quality vs OpenBSD? (0)

Anonymous Coward | about 2 months ago | (#46016259)

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

Re:Quality vs OpenBSD? (0)

Anonymous Coward | about 2 months ago | (#46017865)

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.

Re:Quality vs OpenBSD? (1)

chriscappuccio (80696) | about 3 months ago | (#46021755)

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

Re:Quality vs OpenBSD? (1)

TheRaven64 (641858) | about 3 months ago | (#46020547)

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.

Re:Quality vs OpenBSD? (1)

chriscappuccio (80696) | about 3 months ago | (#46021643)

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.

Re:Quality vs OpenBSD? (3, Interesting)

TheRaven64 (641858) | about 3 months ago | (#46021763)

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:Quality vs OpenBSD? (3, Interesting)

Anonymous Coward | about 2 months ago | (#46015719)

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.

Re:Quality vs OpenBSD? (1)

smash (1351) | about 3 months ago | (#46021693)

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:Quality vs OpenBSD? (2)

chriscappuccio (80696) | about 3 months ago | (#46021767)

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:Quality vs OpenBSD? (1)

chriscappuccio (80696) | about 3 months ago | (#46021753)

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.

Actually 10.0 is pretty good... (3, Informative)

drussell (132373) | about 2 months ago | (#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.

Re:Actually 10.0 is pretty good... (0)

Anonymous Coward | about 2 months ago | (#46017723)

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

Re:Actually 10.0 is pretty good... (2)

TheRaven64 (641858) | about 2 months ago | (#46019241)

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.

Sounds interesting, but.. (0)

Anonymous Coward | about 2 months ago | (#46016091)

does USB 3.0 work properly yet?

Re:Sounds interesting, but.. (1)

smash (1351) | about 3 months ago | (#46021697)

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

Re:Sounds interesting, but.. (1)

Wolfrider (856) | about 3 months ago | (#46022801)

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

Re:Sounds interesting, but.. (1)

Wolfrider (856) | about 3 months ago | (#46022917)

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.

Before upgrading, read the Errata (1)

Anonymous Coward | about 2 months ago | (#46016155)

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:Before upgrading, read the Errata (1)

lgw (121541) | about 2 months ago | (#46017899)

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... (2)

wonkey_monkey (2592601) | about 2 months ago | (#46016211)

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

Re:FreeBSD... (0)

Anonymous Coward | about 2 months ago | (#46016337)

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

Re:FreeBSD... (0)

Anonymous Coward | about 2 months ago | (#46016469)

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

Re:FreeBSD... (1)

BestNicksRTaken (582194) | about 2 months ago | (#46018117)

no that's solaris 11

Re:FreeBSD... (1)

afidel (530433) | about 2 months ago | (#46019071)

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:FreeBSD... (1)

drussell (132373) | about 3 months ago | (#46022735)

...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. :)

Is freebsd free yet however? (0)

Anonymous Coward | about 2 months ago | (#46016559)

Re:Is freebsd free yet however? (0)

Anonymous Coward | about 2 months ago | (#46016629)

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

Re:Is freebsd free yet however? (0)

Anonymous Coward | about 2 months ago | (#46017131)

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.

Re:Is freebsd free yet however? (1)

vinehair (1937606) | about 3 months ago | (#46020435)

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

Re:Is freebsd free yet however? (1)

fnj (64210) | about 3 months ago | (#46022381)

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:Is freebsd free yet however? (2)

kthreadd (1558445) | about 2 months ago | (#46016985)

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:Is freebsd free yet however? (0)

Anonymous Coward | about 2 months ago | (#46018171)

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.

Includes strengthened cryptography (3, Interesting)

johnjaydk (584895) | about 2 months ago | (#46017439)

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:Includes strengthened cryptography (1)

Anonymous Coward | about 2 months ago | (#46018571)

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

Re:Includes strengthened cryptography (1)

chriscappuccio (80696) | about 3 months ago | (#46021777)

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.

Re:Includes strengthened cryptography (2)

plasticsquirrel (637166) | about 3 months ago | (#46021955)

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.

Gluster? (0)

pooh666 (624584) | about 2 months ago | (#46017827)

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"
Load More Comments
Slashdot Account

Need an Account?

Forgot your password?

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>
Sign up for Slashdot Newsletters
Create a Slashdot Account

Loading...