FreeBSD 8.4 is now available(freebsd.org)
freebsd.org
FreeBSD 8.4 is now available
http://www.freebsd.org/releases/8.4R/relnotes-detailed.html
5 comments
Thank you to everyone at FreeBSD (and some folks behind the scenes at IXSystems) that made this happen.
A lot of people really appreciate seeing the 8 branch extended in its lifecycle like this, and it marks a subtle, but important culture change in FreeBSD development.
A lot of people really appreciate seeing the 8 branch extended in its lifecycle like this, and it marks a subtle, but important culture change in FreeBSD development.
What, specifically, did iX Systems do?
There are notable improvements in this version for ZFS, including the LZ4 compression algorithm that is both faster and better than the previous one. (Benchmark: http://code.google.com/p/lz4/)
What zpool version is it at?
Note that FreeBSD 8.4 is from the older stable release branch, and 9.2 will release from the more recent stable branch with a lot of additional functionality and enhancements.
The topic of the zpool version for 8.4 is covered directly in the release notes:
FreeBSD ZFS subsystem has been updated to support feature flags for ZFS pools (the SPA version is 5000). Asynchronous destroy of ZFS dataset, LZ4 compression, ZIO NOP-write optimization have been implemented as new features. loader(8) tunables vfs.zfs.sync_pass_deferred_free, vfs.zfs.sync_pass_dont_compress, vfs.zfs.sync_pass_rewrite, and vfs.zfs.nopwrite_enabled have been added.[r243717, r244088, r247310]
Note that this upgrade can cause interoperability issues when upgrading a FreeBSD 8.4 system to 9.0 or 9.1. This is because FreeBSD 9.0 and 9.1 support SPA version 28 and do not recognize version 5000. To mitigate this issue, the default SPA version for a newly created ZFS pool on FreeBSD 8.4 is set to version 28. To create a ZFS pool with version 5000, use zpool(8) upgrade command after the creation.
The topic of the zpool version for 8.4 is covered directly in the release notes:
FreeBSD ZFS subsystem has been updated to support feature flags for ZFS pools (the SPA version is 5000). Asynchronous destroy of ZFS dataset, LZ4 compression, ZIO NOP-write optimization have been implemented as new features. loader(8) tunables vfs.zfs.sync_pass_deferred_free, vfs.zfs.sync_pass_dont_compress, vfs.zfs.sync_pass_rewrite, and vfs.zfs.nopwrite_enabled have been added.[r243717, r244088, r247310]
Note that this upgrade can cause interoperability issues when upgrading a FreeBSD 8.4 system to 9.0 or 9.1. This is because FreeBSD 9.0 and 9.1 support SPA version 28 and do not recognize version 5000. To mitigate this issue, the default SPA version for a newly created ZFS pool on FreeBSD 8.4 is set to version 28. To create a ZFS pool with version 5000, use zpool(8) upgrade command after the creation.
If it has LZ4, I don't think it has a zpool version. Versions were deprecated, and now ZFS uses feature flags instead.
[deleted]
Does someone knows why FreeBSD doesn't offer any virtualization platform based on Intel VT or AMD-v? Is there any architectural incompatibility or is it just a case of virtualization not being a high priority?
They're still working on BHyVe, but it'll probably be a few releases.
They do however have fairly-powerful jails(not as powerful as LXC though), and I think you can run VirtualBox... Or maybe not.
They do however have fairly-powerful jails(not as powerful as LXC though), and I think you can run VirtualBox... Or maybe not.
> fairly-powerful jails(not as powerful as LXC though)
IMHO LXC wishes it were jails with vimage, and if you really wanted some hillarity you could actually run a linux container-like system under a jail using the linuxulator.
IMHO LXC wishes it were jails with vimage, and if you really wanted some hillarity you could actually run a linux container-like system under a jail using the linuxulator.
Linux namespaces allows namespacing almost any subsystem, although I don't know what FreeBSD offers w.r.t that.
> Linux namespaces allows namespacing almost any subsystem
Namespacing has nothing to do with it. Not even a decent try.
Namespacing has nothing to do with it. Not even a decent try.
>not as powerful as LXC though
I think many would completely disagree with this.
> They do however have fairly-powerful jails(not as powerful as LXC though)
To be honest, I grew up on BSD's, FreeBSD especially, and only later turned to Linux due high marked demand. In my projects, I've tried using LXC as the light (kernel) virtualization of choice, but I've found it extremely buggy, with a lot of security issues, implementation different in almost every flavor of Linux, documentation lacking... Not even close to maturity of Jails, to which I eventually turned back to. Dont get me wrong, I am still big fan of LXC and I can see it working in future, and having features I would like to see in Jails (they're getting there, especially recently) like fine grained resources control and restriction and so on, but as of today, it needs a lot of work in polishing and maturing the code.
To be honest, I grew up on BSD's, FreeBSD especially, and only later turned to Linux due high marked demand. In my projects, I've tried using LXC as the light (kernel) virtualization of choice, but I've found it extremely buggy, with a lot of security issues, implementation different in almost every flavor of Linux, documentation lacking... Not even close to maturity of Jails, to which I eventually turned back to. Dont get me wrong, I am still big fan of LXC and I can see it working in future, and having features I would like to see in Jails (they're getting there, especially recently) like fine grained resources control and restriction and so on, but as of today, it needs a lot of work in polishing and maturing the code.
For FreeBSD, I think your choices for virtualization are limited to jails or Virtualbox. Virtualbox on FreeBSD does support Intel/AMD processor virtualization extensions I believe.
Cool, I thought it could not use the extensions and thus would be slower than other options like Xen or KVM.
Virtualization is a priority, both as a host and a guest, but especially on the host side there's a fair amount of work to be done.
BHyVe is FreeBSD's own hypervisor, and can run FreeBSD and Linux guests, but is not yet available in a release.
VirtualBox works well for end-user applications on current FreeBSD releases, and is being used by kernel developers in their workflow.
BHyVe is FreeBSD's own hypervisor, and can run FreeBSD and Linux guests, but is not yet available in a release.
VirtualBox works well for end-user applications on current FreeBSD releases, and is being used by kernel developers in their workflow.
There are not a lot of options but VirtualBox works pretty excellently. There's also BHyVe and you can always use Qemu :)
The lack of hypervisor support is really more due to people not keeping up with the porting work. I would love to see Xen actively supported but I think BHyVe is going to be where the most work gets done.
The lack of hypervisor support is really more due to people not keeping up with the porting work. I would love to see Xen actively supported but I think BHyVe is going to be where the most work gets done.
Does anyone have a good recommendation for a lightweight laptop (ideally 11", but 13" is OK I guess) that would run a BSD system out of the box (as much as possible)?
Trying to slowly start a switch from OS X for basic stuff (internet, writing LaTeX, writing some elementary code, etc.), something to replace my Macbook Air would be awesome.
Trying to slowly start a switch from OS X for basic stuff (internet, writing LaTeX, writing some elementary code, etc.), something to replace my Macbook Air would be awesome.
BSD is great, but if you're on a laptop, I have to say I can't recommend anything other than GNU+Linux. That is the only Unix-like system besides OS X I've run on my MacBook Air that has good power management. Everything works out of the box. Xubuntu is an excellent choice; the 13.04 release works flawlessly with all hardware and I easily get about 6+ hours of battery life out of a 1.5-year old Air.
I've tried OpenBSD on the same machine, and got decent power management with it. It's not as ubiquitous nor as supported in terms of a software perspective as FreeBSD (e.g., can't run some Linux binaries, etc.) but it's still a good choice if you want to stay away from GNU and the GPL.
Personally, I can't live without the GNU tools, so I've never switched.
I've tried OpenBSD on the same machine, and got decent power management with it. It's not as ubiquitous nor as supported in terms of a software perspective as FreeBSD (e.g., can't run some Linux binaries, etc.) but it's still a good choice if you want to stay away from GNU and the GPL.
Personally, I can't live without the GNU tools, so I've never switched.
FreeBSD works fine on my laptops, m610 and studio 1555. The 1555 is a win 7 dual boot. I did have to replace the crappy wifi nic in it though to something better and something FBSD would recognize.
> Personally, I can't live without the GNU tools, so I've never switched.
Do you mean a GNU userland or toolchain? FreeBSD definitely has GNU toolchain although the ones in base are being deprecated. Still available in ports though. And I'd take the BSD userland over the clusterF GNU's is any day.
> Personally, I can't live without the GNU tools, so I've never switched.
Do you mean a GNU userland or toolchain? FreeBSD definitely has GNU toolchain although the ones in base are being deprecated. Still available in ports though. And I'd take the BSD userland over the clusterF GNU's is any day.
I meant both userland and toolchain. I like the BSD userland for its simplicity, but the GNU userland has a lot of features that BSD doesn't have. It's bigger, and some may say more bloated, but it works well and is fully-featured.
> GNU userland has a lot of features that BSD doesn't have.
Do you have an example of this or a lot of them?
> some may say more bloated
I'm not worried about "bloat". What I am worried about it lack of functionality. If BSD is lacking in that area, it should be easy to identify.
Do you have an example of this or a lot of them?
> some may say more bloated
I'm not worried about "bloat". What I am worried about it lack of functionality. If BSD is lacking in that area, it should be easy to identify.
[deleted]
I've had good luck with FreeBSD on Lenovos. Its run on every one I've had since my T42 (so T42, R60, T500, T510, T520).
Power management works "fine", I usually get 5-6 hours of battery life out of my battery, but I never bothered to monkey with suspend/resume since my laptop boots so fast anyways.
Frankly the Air is one of the best laptop formfactors I've seen in a while, just load a virtualization system on it (VBox is free) and run FreeBSD in that.
Frankly the Air is one of the best laptop formfactors I've seen in a while, just load a virtualization system on it (VBox is free) and run FreeBSD in that.
FreeBSD works well enough for me on my Thinkpad X220, with the notable current exception of suspend and resume. If you can live with that for now I believe it will serve you well for your use case.
There have been reports that removing VESA from the kernel allowed suspend/resume to work fully for the KMS stuff. Not sure if that's applicable to your setup.
Not sure if FreeBSD has power management worth a rectal excretion, you probably wouldn't want to run it on a laptop.
Try GNU/Linux, really.
Try GNU/Linux, really.
Or OpenBSD. That runs really well on most laptops.
As long as they're connected to a wall socket. Otherwise, citation needed. Power Management in hard. Who does the myriad of hardware quirks for OpenBSD?
If you are referring to suspend/resume, then OpenBSD has great support[1]. Its one of the very few ACPI stacks not derived from Intel's ACPICA reference code.
[1] http://www.openbsd.org/papers/zzz.pdf (older, 2011)
[1] http://www.openbsd.org/papers/zzz.pdf (older, 2011)
Suspend and resume are basic features, by power management I mean idle and active power management, optimizing the race to zero, reclocking...
Working suspend and resume is not a basic feature as far as linuxen go.
Would you like to explain that, and maybe cite some references?
Suspend and resume have been stable for me as long as I've had a computer capable of supporting them.
And I'm not aware of any way to make them fail without doing something obviously intended to disable them.
Reference: Every time I've tried Linux on a laptop, Suspend, Resume, or Both has been broken in whatever $FLAVOR_OF_THE_MONTH distro/package/kernel the community insists is the next big thing.
The BSDs tend to implement these things later but far more reliably.
The BSDs tend to implement these things later but far more reliably.
Never been broken on Arch, Fedora, Debian... or any of the upstream distributions I've used, when I've used them.
Your personal exacerbation of whatever imaginary and nonspecific issues you're talking about is not relevant to a conversation about people other than you.
The world doesn't need your BSD FUD. "The BSDs" is also absolutely silly as ideas go, there are BSDs which have never supported suspend/resume.
Your personal exacerbation of whatever imaginary and nonspecific issues you're talking about is not relevant to a conversation about people other than you.
The world doesn't need your BSD FUD. "The BSDs" is also absolutely silly as ideas go, there are BSDs which have never supported suspend/resume.
What the world doesn't need is this continuing holy war from a particularly small but sadly vocal minority of the Linux community. You really don't help the cause. I find it particularly irononic of you to accuse someone of spreading "BSD FUD" on a thread about FreeBSD. I'll 'cite' you an example of real 'FUD'; https://news.ycombinator.com/item?id=5839565
I had to install Debian on a laptop last week actually, suspend/resume absolutely did not work on it...
> The world doesn't need your BSD FUD.
You have just doomed yourself to the "I have no idea what I'm talking about" club.
> The world doesn't need your BSD FUD.
You have just doomed yourself to the "I have no idea what I'm talking about" club.
My Thinkpad X220 usually has a wall socket nearby, but I have been able to work on a flight from Toronto to San Francisco (a bit over 5 hours) without running out of battery.
"acpiconf -i0" tells me my battery has a design capacity of just over 93Wh, and it's using just over 14W while idle.
"acpiconf -i0" tells me my battery has a design capacity of just over 93Wh, and it's using just over 14W while idle.
And AWS ami IDs are in the usual spot on cperciva's page: http://www.daemonology.net/freebsd-on-ec2