FreeBSD 11.0 Now Available(lists.freebsd.org)
lists.freebsd.org
FreeBSD 11.0 Now Available
https://lists.freebsd.org/pipermail/freebsd-announce/2016-October/001760.html
162 comments
This would be a good moment to be "that guy" and kindly remind you to donate: https://www.freebsdfoundation.org/donate/
I think the highlights don't mention the release's best bits. The full release notes are way larger and it really depends on what you do, what you might consider the most interesting part.
Also I am happy to see a bunch of "Sponsored by..." Netflix, Yandex, NGINX Inc, Netgate, Citrix, Juniper Networks, Microsoft, Dell, Multiplay, ScaleEngine, etc. in there.
https://www.freebsd.org/releases/11.0R/relnotes.html
Also I am happy to see a bunch of "Sponsored by..." Netflix, Yandex, NGINX Inc, Netgate, Citrix, Juniper Networks, Microsoft, Dell, Multiplay, ScaleEngine, etc. in there.
https://www.freebsd.org/releases/11.0R/relnotes.html
As a full time developer, you are correct that the relnotes don't capture all the great stuff. It is difficult to keep track of all that is going on. The only way I know how is to continuously read the commit logs. But distilling that down into a useful document for end users is quite hard, especially retroactively.
I will say that the release has non-trivial improvements in TCP performance (Mike Karels, Matt Macy, Netflix crew).
VNET jails also should be safe to tear down, and SysV SHM can be jailed/virtualized which should be interesting to many users.
I will say that the release has non-trivial improvements in TCP performance (Mike Karels, Matt Macy, Netflix crew).
VNET jails also should be safe to tear down, and SysV SHM can be jailed/virtualized which should be interesting to many users.
>I will say that the release has non-trivial improvements in TCP performance
For your average home / small business user? Or do you need to be at Netflix scale to see the benefits? (that's not a bad thing).
For your average home / small business user? Or do you need to be at Netflix scale to see the benefits? (that's not a bad thing).
It matters most for people doing 10-100gbps throughput, CPU usage will be lower and more stable in all cases though.
There has been a lot of improvement to many network card drivers in 11, and I am helping to push/fund the final integration of Matt Macy's "iflib" for the common intel em/igb/ixgbe drivers.
There are a lot of goodput improvements coming soon, which will affect all TCP users. I had Matt Macy upgrade TCP CUBIC to match 2016 RFC and most Linux behaviors (HyStart). Hiren Panchasara has been working full time for almost 2 years to address many other goodput and correctness issues in the TCP stack. Some of these are in 11, but the majority will hit in 11.1.
Another company is working on the recently announced BBR congestion control from Google and a TCP stack with RACK/PRR https://wiki.freebsd.org/DevSummit/201606/Transport. The end result of all this will be a more tightly integrated and coherent TCP implementation, which should make FreeBSD have the best network stack again in 2017 after falling behind for a while.
There has been a lot of improvement to many network card drivers in 11, and I am helping to push/fund the final integration of Matt Macy's "iflib" for the common intel em/igb/ixgbe drivers.
There are a lot of goodput improvements coming soon, which will affect all TCP users. I had Matt Macy upgrade TCP CUBIC to match 2016 RFC and most Linux behaviors (HyStart). Hiren Panchasara has been working full time for almost 2 years to address many other goodput and correctness issues in the TCP stack. Some of these are in 11, but the majority will hit in 11.1.
Another company is working on the recently announced BBR congestion control from Google and a TCP stack with RACK/PRR https://wiki.freebsd.org/DevSummit/201606/Transport. The end result of all this will be a more tightly integrated and coherent TCP implementation, which should make FreeBSD have the best network stack again in 2017 after falling behind for a while.
Also on the networking front, FreeBSD now has modern AQMs like CoDel and FQ-CoDel. This means it can now compete against Linux for use in a (wired-only) home router.
>SysV SHM can be jailed/virtualized which should be interesting to many users.
You mean I can run multiple postgresql jails on a machine? YASSS
You mean I can run multiple postgresql jails on a machine? YASSS
IIRC you've been able to do that already, but you need to ensure that the postgres users have different UIDs.
The SysV IPC functionality wasn't sufficiently isolated in jails before; you could enable it, but it would defeat the purpose of a jail as a security and isolation mechanism.
I think the highlights don't mention the release's best bits.
It's always challenging to put together those highlights... different people consider different things important, and the release engineer has to guess what the largest number of people will care about. (And sometimes things don't end up in the release notes at all because developers forget to flag their commits with "Relnotes: yes", but we're getting better at that.)
It's always challenging to put together those highlights... different people consider different things important, and the release engineer has to guess what the largest number of people will care about. (And sometimes things don't end up in the release notes at all because developers forget to flag their commits with "Relnotes: yes", but we're getting better at that.)
Reading the release notes indicates they are still working on their EFI/uEFI support. I've also noticed a lot of other free OSes that seem to be struggling with it.
Is EFI really that complicated? I also ask because it doesn't seem to me that EFI hasn't really made the PC better for anyone other than Microsoft and Apple.
Is EFI really that complicated? I also ask because it doesn't seem to me that EFI hasn't really made the PC better for anyone other than Microsoft and Apple.
UEFI boot just works, for the most part.
11.0 doesn't have support for EFI runtime services, but a lot of that has been added to CURRENT (which will become 12.0 and maybe make it into 11.1 via backport) very recently.
11.0 doesn't have support for EFI runtime services, but a lot of that has been added to CURRENT (which will become 12.0 and maybe make it into 11.1 via backport) very recently.
A couple things HN users might be excited about:
* Docker via ZFS and jails (...running Linux x84-64 binaries): https://wiki.freebsd.org/Docker
--- (See also, https://github.com/3ofcoins/jetpack )
* Add support for trackpads found in Apple MacBook products: https://svnweb.freebsd.org/base?view=revision&revision=26126...
* CloudABI executable support: https://nuxi.nl/cloudabi/freebsd/
This is an awesome release.
* Docker via ZFS and jails (...running Linux x84-64 binaries): https://wiki.freebsd.org/Docker
--- (See also, https://github.com/3ofcoins/jetpack )
* Add support for trackpads found in Apple MacBook products: https://svnweb.freebsd.org/base?view=revision&revision=26126...
* CloudABI executable support: https://nuxi.nl/cloudabi/freebsd/
This is an awesome release.
Don't forget zfsd[1]!
Graphics support for bhyve is also pretty spiffy.
[1]: https://svnweb.freebsd.org/base?view=revision&revision=30090...
Graphics support for bhyve is also pretty spiffy.
[1]: https://svnweb.freebsd.org/base?view=revision&revision=30090...
> https://svnweb.freebsd.org/base?view=revision&revision=30090....
Is this a unique feature or how is this handled on illumos or Solaris?
Is this a unique feature or how is this handled on illumos or Solaris?
Based on this article[0], I suspect something different ("FMA") is used on illumos. But I am not especially familiar with the subject, sorry.
[0]: http://open-zfs.org/wiki/Fault_Management
[0]: http://open-zfs.org/wiki/Fault_Management
Jetpack is in my (personal and completely biased) opinion the even more interesting project. It's the implementation of the App Container specification (like rkt).
Just pointing it out cause it was only mentioned in brackets.
Just pointing it out cause it was only mentioned in brackets.
Yes this is a fascinating project. You've inspired/reminded me to watch the bsdcan presentation: https://www.bsdcan.org/2015/schedule/events/574.en.html
CloudABI deserves more attention and support. One binary format for multiple unix-like systems. That also enforces sandboxing. Why aren't we using it for everything yet?
> Why aren't we using it for everything yet?
There are some features which are so far exclusive to FreeBSD but go under the radar of the wider community of developers. In addition to CloudABI, Capsicum is another one, which, while not perfect, seems largely ignored/unused/reinvented outside FreeBSD. The LLVM-based base system is another one, which is partially matched by Bitrig. FreeBSD needs to market their features better, like pledge(2), libressl or systemd or docker are doing it.
There are some features which are so far exclusive to FreeBSD but go under the radar of the wider community of developers. In addition to CloudABI, Capsicum is another one, which, while not perfect, seems largely ignored/unused/reinvented outside FreeBSD. The LLVM-based base system is another one, which is partially matched by Bitrig. FreeBSD needs to market their features better, like pledge(2), libressl or systemd or docker are doing it.
Unfortunately the Docker daemon support never got merged upstream. It would be great if someone would work on that.
Also, support for running Apple's Swift language.
I thought swills or feld... someone had Swift working. My memory may be getting this wrong.
landonf got it running initially. https://twitter.com/landonfuller/status/672671872660598784
Thank you, Landon then. I knew I saw a tweet about someone working on getting it going.
Is anyone using FreeBSD on their development machine? Are there any gotchas compared to Linux?
I use CURRENT on a Thinkpad X230. It works ok.
Main gotchas:
[0]: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=189811
[1]: https://github.com/FreeBSDDesktop/freebsd-base-graphics/wiki
Main gotchas:
* No SSL CA certificates out of the box. FreeBSD security team has taken the
curious posture of claiming that shipping no CAs is better than just
shipping e.g. Mozilla's CA bundle.[0]
* rc.d is like Linux init from 5 years ago. Dynamic network configuration is
not handled well.
* Intel GPU driver support for anything above Haswell is still waiting to be
merged. But work is ongoing.[1]
* No Xorg or session management out of the box. You get dropped to a terminal
console. Good luck starting a session.
* Some packages conflict with each other needlessly. For example, you cannot
install gitk and git-svn at the same time.
* Finally, the installer has some limited choices. You can't enable full disk
encryption for UFS with the installer (last time I checked, anyway).
[0]: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=189811
[1]: https://github.com/FreeBSDDesktop/freebsd-base-graphics/wiki
Hmph. I remember when "session management" was echo startx >> .loginrc
I sure miss being able to understand and control my machine...
I sure miss being able to understand and control my machine...
I reached the point of not understanding my machine when mounting a disk on Linux required udisks2/dbus and parts of Gnome.
FreeBSD can be pretty spartan, but I do feel like I'm more in control.
FreeBSD can be pretty spartan, but I do feel like I'm more in control.
Is this a thing? I'm running Slackware and mounting a disk is still done with good ol' `mount`, same as it ever was.
I was probably being a bit snarky. I have run into cases where getting a drive to show up in the GUI (so, mounting as a user) needed something via dbus.
Ah. Well, I sympathize. When I first started using Linux, one thing I liked about it was the simplicity. Seems that simplicity has been getting eroded slowly but surely since I first started with it, but it has accelerated quite a bit in recent years.
Slackware feels like one of the last holdouts, along with the likes of CRUX and Gentoo, but I fear that soon I will be forced to switch to some BSD -- which I wouldn't mind if my laptop hardware were better supported (I've been running various BSDs on servers for years, but Linux just seems to work better on my laptop; that said, I downloaded the 11.0-RELEASE ISOs a few days ago and I'll give it a shot on the lappy).
Slackware feels like one of the last holdouts, along with the likes of CRUX and Gentoo, but I fear that soon I will be forced to switch to some BSD -- which I wouldn't mind if my laptop hardware were better supported (I've been running various BSDs on servers for years, but Linux just seems to work better on my laptop; that said, I downloaded the 11.0-RELEASE ISOs a few days ago and I'll give it a shot on the lappy).
I've been in the linux world for less than a decade, and I miss 'mount' being useful. It's full of spam now - so I've started using 'lsblk' instead...
$ mount | wc -l
32
$ lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
sda 8:0 0 698.7G 0 disk
├─sda1 8:1 0 512M 0 part /boot/efi
├─sda2 8:2 0 690.3G 0 part /
└─sda3 8:3 0 7.9G 0 part [SWAP] # this was a mistake...
sr0 11:0 1 1024M 0 rom> # this was a mistake...
That's not an unfixable mistake: sda3 is at the end of the partition table, so if it's deleted, sda2 can be safely resized offline. For example,
That's not an unfixable mistake: sda3 is at the end of the partition table, so if it's deleted, sda2 can be safely resized offline. For example,
parted /dev/sda rm 3
parted /dev/sda "resizepart 2 -0"
resize2fs /dev/sda2 # for ext2/3/4
Cool! I didn't know about `lsblk`. Thanks!
That the BSDs init still works and currently makes many people switch from Linux actually makes it look different.
Also small note on FreeBSDs rc vs Linux old init is that it for example always had support for dependencies.
I'm saying that because BSD's especially FreeBSD's simple, pretty and working rc system have always been a thing that I missed when using Linux. Or in other words I disliked that run level system that makes managing dependencies really hard.
I always hoped OpenRC would become the most common init system on Linux and actually still do, because I think it is the best option, when compared with sysv init and systemd.
Also about the CAs: Everything that wants it has a dependency.
About package conflicts: Choose between official packages or your own with Poudriere
Out of the box the system is like Arch Linux, Debian or Ubuntu Server. It's the FreeBSD base system. You can install packages to make it into a router, a server, a thing hosting your private cloud using jails, a jail itself, etc.
And the plus side. You don't have to get rid of all the stuff when you want your nice little i3 environment. And if you want KDE, just install it and kdm using pkg install and do sysrc kdm_enable=yes.
Or go for TueOS (former pc-bsd).
Or if you just want some FreeBSD tools go on MacOS and enter grep --version.
With the other things I agree. FreeBSD isn't really your multimedia desktop environment. It is maybe for people that like it liked Gentoo or Arch Linux, but you should really check on your laptop's hardware before.
Most driver development really happens in the server or usual suspects (Lenovo, Raspberry, ...) area.
Sorry, didn't mean to even strongly disagree, but wanting to share my own experiences. Not everyone comes with the same views and I'm personally someone who is switching back from Arch Linux, because of the developments in the last few years in the Linux world.
It just in my personal experience felt so much more easy to do stuff and have the system I want. Having used Arch for around a decade with only a relatively short break doesn't make that easy, but I liked it's initial idea about keeping things simple and that's what I miss on many ends.
The main reason for not using FreeBSD on laptops really was the lack of some drivers for me. So that's maybe the biggest gotcha. Oh and for new people maybe that it is not just another Linux distribution so many things work differently.
Biggest is probably the separation between base system and ports/packages.
Also small note on FreeBSDs rc vs Linux old init is that it for example always had support for dependencies.
I'm saying that because BSD's especially FreeBSD's simple, pretty and working rc system have always been a thing that I missed when using Linux. Or in other words I disliked that run level system that makes managing dependencies really hard.
I always hoped OpenRC would become the most common init system on Linux and actually still do, because I think it is the best option, when compared with sysv init and systemd.
Also about the CAs: Everything that wants it has a dependency.
About package conflicts: Choose between official packages or your own with Poudriere
Out of the box the system is like Arch Linux, Debian or Ubuntu Server. It's the FreeBSD base system. You can install packages to make it into a router, a server, a thing hosting your private cloud using jails, a jail itself, etc.
And the plus side. You don't have to get rid of all the stuff when you want your nice little i3 environment. And if you want KDE, just install it and kdm using pkg install and do sysrc kdm_enable=yes.
Or go for TueOS (former pc-bsd).
Or if you just want some FreeBSD tools go on MacOS and enter grep --version.
With the other things I agree. FreeBSD isn't really your multimedia desktop environment. It is maybe for people that like it liked Gentoo or Arch Linux, but you should really check on your laptop's hardware before.
Most driver development really happens in the server or usual suspects (Lenovo, Raspberry, ...) area.
Sorry, didn't mean to even strongly disagree, but wanting to share my own experiences. Not everyone comes with the same views and I'm personally someone who is switching back from Arch Linux, because of the developments in the last few years in the Linux world.
It just in my personal experience felt so much more easy to do stuff and have the system I want. Having used Arch for around a decade with only a relatively short break doesn't make that easy, but I liked it's initial idea about keeping things simple and that's what I miss on many ends.
The main reason for not using FreeBSD on laptops really was the lack of some drivers for me. So that's maybe the biggest gotcha. Oh and for new people maybe that it is not just another Linux distribution so many things work differently.
Biggest is probably the separation between base system and ports/packages.
I use HEAD on a Intel Skull Canyon (Sky Canyon i7) NUC.
Intel GPU driver just works on a 4K screen.
I run ZFS on a pair or mirrored M.2 (NGFF) SSDs. Disk encryption is straight-forward here. pfSense 2.4 will have ZFS as well.
I have a mostly retired x230 as well. 'Only' 16GB ram.
Intel GPU driver just works on a 4K screen.
I run ZFS on a pair or mirrored M.2 (NGFF) SSDs. Disk encryption is straight-forward here. pfSense 2.4 will have ZFS as well.
I have a mostly retired x230 as well. 'Only' 16GB ram.
> No Xorg or session management out of the box.
TrueOS Desktop is your friend. PC-BSD, now called TrueOS, has for years now been the place to go if one cannot hack getting X up and running onesself, as one has to do with FreeBSD. PC-BSD/TrueOS Desktop has X and GUI login pre-configured out of the box.
> rc.d is like Linux init from 5 years ago.
Linux init from 5 years ago was upstart in quite a few places. (Debian is not the entire world.) init is not rc. upstart is nothing at all like Mewburn rc. And Mewburn rc has significant differences to van Smoorenburg rc, from not having any notion of runlevels (which the BSD world never adopted from the AT&T System 5 world) to a different division of work between the individual scripts and the common script libraries.
Dynamic network configuration is handled through devd rules.
> You can't enable full disk encryption for UFS with the installer
... although the FreeBSD/PC-BSD/TrueOS world is rapidly heading to all-ZFS as the norm. The PC-BSD 10.2 installer creates an all-ZFS system.
TrueOS Desktop is your friend. PC-BSD, now called TrueOS, has for years now been the place to go if one cannot hack getting X up and running onesself, as one has to do with FreeBSD. PC-BSD/TrueOS Desktop has X and GUI login pre-configured out of the box.
> rc.d is like Linux init from 5 years ago.
Linux init from 5 years ago was upstart in quite a few places. (Debian is not the entire world.) init is not rc. upstart is nothing at all like Mewburn rc. And Mewburn rc has significant differences to van Smoorenburg rc, from not having any notion of runlevels (which the BSD world never adopted from the AT&T System 5 world) to a different division of work between the individual scripts and the common script libraries.
Dynamic network configuration is handled through devd rules.
> You can't enable full disk encryption for UFS with the installer
... although the FreeBSD/PC-BSD/TrueOS world is rapidly heading to all-ZFS as the norm. The PC-BSD 10.2 installer creates an all-ZFS system.
How about GhostBSD? Anyone familiar with it?
Just run `pkg install -y xdm` and enable it in /etc/ttys to have init (re-)start xdm on the ttyv of your choice.
Using FreeBSD -CURRENT on my ThinkPad X240. Mostly works great. Can't resume from suspend on that particular laptop, but I can live without the sleep thing.
For development, it's excellent! (Favorite things: non-GPL not-breaking-compatibility-every-day libc that doesn't cause any problems ever. Simple init system. Simple configuration files, moving towards using libucl everywhere. And libxo for output. Good documentation. Jails. ZFS. DTrace. Capsicum.)
I do get annoyed at people who use linuxisms like "/bin/bash" in their code though >_<
For development, it's excellent! (Favorite things: non-GPL not-breaking-compatibility-every-day libc that doesn't cause any problems ever. Simple init system. Simple configuration files, moving towards using libucl everywhere. And libxo for output. Good documentation. Jails. ZFS. DTrace. Capsicum.)
I do get annoyed at people who use linuxisms like "/bin/bash" in their code though >_<
We have been dealing with that since Linux was created. And we are still dealing with it today.
Is /usr/bin/env bash good enough? Or should I assume that only a "sh" is available? (I found tcsh tricky when I first started using FreeBSD, and I think a few of my accounts have the default shell set to bash)
Most times yes. In practice I suspect most deployed servers have something like
ln -sf /usr/local/bin/bash /bin/bash
Infinitely more entertaining is running unzip at the command prompt results in /usr/bin/unzip which is extremely limited compared to (installed via pkg) infozip at /usr/local/bin/unzip. At least one specific example I ran into was Play/Activate Scala framework can be convinced via "dist" target to make a zip file of all the jars necessary to run a project, and you guessed it, /usr/bin/unzip doesn't understand that zipfile format and /usr/local/bin/unzip works perfectly. So you can't have a script that automatically runs unzip because you need to run /usr/local/bin/unzip specifically.
Lack of a Debian-like alternatives system is really the only systemic problem I run into on a regular basis. Then again it creates an inconsistency across multiple servers and I would not enjoy playing "update-alternatives whack a mole" to figure out which of my frontends have infozip provide unzip, and which fail.
ln -sf /usr/local/bin/bash /bin/bash
Infinitely more entertaining is running unzip at the command prompt results in /usr/bin/unzip which is extremely limited compared to (installed via pkg) infozip at /usr/local/bin/unzip. At least one specific example I ran into was Play/Activate Scala framework can be convinced via "dist" target to make a zip file of all the jars necessary to run a project, and you guessed it, /usr/bin/unzip doesn't understand that zipfile format and /usr/local/bin/unzip works perfectly. So you can't have a script that automatically runs unzip because you need to run /usr/local/bin/unzip specifically.
Lack of a Debian-like alternatives system is really the only systemic problem I run into on a regular basis. Then again it creates an inconsistency across multiple servers and I would not enjoy playing "update-alternatives whack a mole" to figure out which of my frontends have infozip provide unzip, and which fail.
> Lack of a Debian-like alternatives system is really the only systemic problem I run into on a regular basis.
We'll, there's always Debian/kFreeBSD for that...
We'll, there's always Debian/kFreeBSD for that...
Its likely easier to implement a debian-like alternatives system (by hand or by ansible with symlinks if necessary) than to turn a Debian/SystemD non-unix into something unix-like such as Freebsd. Or Freebsd is much closer to what I want, than Debian, so logically it would be easier to change a little bit of Freebsd than a whole lot of Debian.
Of course, Debian/kFreeBSD is an ambitious project - and probably not what you want if you would rather run FreeBSD -- but Debian/kFreeBSD already exists (I'm not sure of the status of Stretch and/or support for the FreeBSD 11 kernel etc):
https://www.debian.org/ports/kfreebsd-gnu/
https://www.debian.org/ports/kfreebsd-gnu/
if you actually need bash, /usr/bin/env bash works; but often something could actually be a sh script with a bit of care. Some Linux distributions have been changing /bin/sh to something other than bash, which helps.
if bash is installed; if not, at least it's a fairly clear indication that you should install bash
if bash is installed; if not, at least it's a fairly clear indication that you should install bash
I started using it on my X1 carbon. It installed fine. I hadn't used it since 2006, and I was quite impressed with the binary package manager and init/service system (I'm not a big systemd fan).
I'd still be using it, but I got the laptop used and it has had frequent reboot problems (even on Linux) and I get an error when I try to update the bios. I looked up the beep code and it just says the motherboard is bad and to send it in for warranty. :(
I'd still be using it, but I got the laptop used and it has had frequent reboot problems (even on Linux) and I get an error when I try to update the bios. I looked up the beep code and it just says the motherboard is bad and to send it in for warranty. :(
I've used it on and off for many years. It makes for a fine development environment. #1 gotcha is what you'd expect: commodity hardware support. Purchase a machine that's known to be good for FreeBSD...
No suspend/hibernate (suspend is available, but fiddly and does not work with X). Apart from that I've been quite happy to this day since last January when I moved to FreeBSD. Though I intend to check-out OpenBSD when I'll have time, as AFAIK it is more laptop-friendly (has working suspend and/or hibernate).
The BSD land is better than any linux distro with its docs and community, and the OSes are really clean and well put-together from the bottom up. Only Arch can come close to them, but then it has no stable releases and breaking changes are often.
BSDs run nearly all the software that GNU/Linux runs, and ports tree is exhaustive. I only have Emacs and Xombrero that I build and install seperately because I'm patching them.
The BSD land is better than any linux distro with its docs and community, and the OSes are really clean and well put-together from the bottom up. Only Arch can come close to them, but then it has no stable releases and breaking changes are often.
BSDs run nearly all the software that GNU/Linux runs, and ports tree is exhaustive. I only have Emacs and Xombrero that I build and install seperately because I'm patching them.
Really depends on your machine. Suspend (and wakeup!) works great on my Lenovo X220, no fiddling needed at all.
With X? Because the docs themselves say it doesn't work well with X [1]. Would you mind sharing your relevant config?
[1] https://wiki.freebsd.org/SuspendResume
[1] https://wiki.freebsd.org/SuspendResume
No, I don't mind at all, but what would the relevant configuration files be? As I said, there was no fiddling necessary. The only thing I remember doing is putting `echo kern.vty=vt >> /boot/loader.conf`.
It really depends on the system.
I recently got my hands on a Acer Aspire E-571 (Haswell i3-4030U) and suspend/resume in X with i915kms literally just worked installing FreeBSD 11.0-RC3 from installer and xorg/xdm/openbox from packages, no config file touched (apart from adjusting the keyboard layout and setting the lid_close_state sysctl to S3).
What does not work on it yet is the Elan trackpad, since it is the version that is connected via i2c.
I recently got my hands on a Acer Aspire E-571 (Haswell i3-4030U) and suspend/resume in X with i915kms literally just worked installing FreeBSD 11.0-RC3 from installer and xorg/xdm/openbox from packages, no config file touched (apart from adjusting the keyboard layout and setting the lid_close_state sysctl to S3).
What does not work on it yet is the Elan trackpad, since it is the version that is connected via i2c.
It really depends on what kind of development you do. It's great as long as the tools you need are actually supported. And the tools would presumably work the same on linux so it's more a matter of what kind of system you prefer to administer. I just switched to linux on my main machine after 12 years due to getting hooked on the jetbrains crack. That and the lack of dart-sdk/dartium. I'd switch back if those two things got supported.
sudo pkg install intellij :-)
PyCharm/RubyMine/etc. aren't officially supported, you might be able to get them to work by manually doing the same things the intellij port does. But pure IntelliJ IDEA works perfectly.
PyCharm/RubyMine/etc. aren't officially supported, you might be able to get them to work by manually doing the same things the intellij port does. But pure IntelliJ IDEA works perfectly.
I tried the community edition a while back. Can't remember much by now but it definately was'nt the same experience as the commercial one. (Actually I'm using the phpstorm edition).
I use 11-rc on Thinkpad X220. Compare to Linux I miss a lot native Dropbox client (Currently I use rclone, but it is not convenient: sync dropbox->local, change, sync local->dropbox). Skype probably will work via Linux emulation, but I haven't tried yet.
Update: also almost all closed source products are not available for FreeBSD, e. g. I'd like to try Jetbrains CLion - it has version for Linux, but not for FreeBSD.
Update: also almost all closed source products are not available for FreeBSD, e. g. I'd like to try Jetbrains CLion - it has version for Linux, but not for FreeBSD.
I do not think Android dev on freebsd works that well
My understanding was that various android emulator features that are better at supporting on Linux or Windows, and do not work on FreeBSD. Happy to be corrected though.
Also if your development depends (or benefits from) ATI device drivers, freeBSD (or any BSD for that matter) is not the best choice.
My understanding was that various android emulator features that are better at supporting on Linux or Windows, and do not work on FreeBSD. Happy to be corrected though.
Also if your development depends (or benefits from) ATI device drivers, freeBSD (or any BSD for that matter) is not the best choice.
I'd be interested to see if Android can boot in bhyve.
Often gets lost in the release notes - deploying on Google cloud is super easy:
% gcloud compute instances create INSTANCE --image freebsd-11-0-release-p1-amd64 --image-project=freebsd-org-cloud-dev
% gcloud compute ssh INSTANCEThat's really cool.
They also provide official AMI imagex es and how to deploy on VAGRANT!
vagrant init freebsd/FreeBSD-11.0-RELEASE-p1
vagrant init freebsd/FreeBSD-11.0-RELEASE-p1
Wow, nice. Do you know how straightforward it is to get it with ZFS?
ZFS is native in FreeBSD, so it is exactly as straightforward as the above.
Even the last release supports full ZFS+encryption with the default installer.
This is still geli+zfs, and not native zfs encryption that was recently presented in OpenZFS Developer Summit [0].
[0] https://www.youtube.com/watch?v=frnLiXclAMo
[0] https://www.youtube.com/watch?v=frnLiXclAMo
Correct, it is full disk encryption instead of dataset encryption.
But on the other hand, if you install 11.0 from installer and chose Auto(ZFS) with EncryptedZFS and MBR(GPT) then you will get a GeliBoot installation. There is no boot pool anymore, instead the early boot stages decrypt the root zpool to load the rest of the boatloader, which then decrypts the pool to load the kernel. With bootloader-selectable boot environments.
But on the other hand, if you install 11.0 from installer and chose Auto(ZFS) with EncryptedZFS and MBR(GPT) then you will get a GeliBoot installation. There is no boot pool anymore, instead the early boot stages decrypt the root zpool to load the rest of the boatloader, which then decrypts the pool to load the kernel. With bootloader-selectable boot environments.
...and I meant BIOS(GPT). Hmpf.
But you don't use the installer with "cloud" / VPS providers. It's usually more like cloning a VM image where the system is already installed.
EC2(TM) users are urged to read the Errata Notes for FreeBSD 11.0-RELEASE regarding an issue discovered very late in the release cycle that may cause the system to hang during the boot process when upgrading from previous FreeBSD versions. New EC2(TM) installations are not affected, but existing installations running earlier releases are advised to wait until the issue is resolved in an Errata Notice before upgrading.
This is discussed on BSD Now 162 https://www.youtube.com/watch?v=fJ-mgwxhNvo
This is discussed on BSD Now 162 https://www.youtube.com/watch?v=fJ-mgwxhNvo
FreeBSD is not 'just another OS out there' but an important piece of technology powering lots of things we often use: from Sony's PlayStation and WhatsApp, through Netflix and Yahoo, to Juniper and PFSense networking gear and EMC storage and FreeNAS appliance - and many, many more!
So, have you donated yet? We need FreeBSD and FreeBSD needs your support!
https://www.freebsdfoundation.org/donate/
So, have you donated yet? We need FreeBSD and FreeBSD needs your support!
https://www.freebsdfoundation.org/donate/
What really makes me sad is that the BSD license allows corporate leeches like Sony to create incredibly successful and valuable products like the PS4 without ever having to give back to the project that produced the software they rely on. It's obvious that Sony picked FreeBSD over Linux because they don't have to publish their additions to FreeBSD, and can continue to integrate new and improved code from upstream with no obligations whatsoever.
Yes, some corporate users contribute financially back to the project, and we're thankful. But why should we have to be thankful? The GPL already provides a tried and proven legal framework for requiring downstream users to publish their improvements for others to use. Free software is an ecosystem where everyone helps and everyone benefits. When the BSD license allows parasites like Sony to benefit to the tune of billions of dollars without giving a line of code (or a penny) back, that breaks the ecosystem.
I'm calling Sony out particularly because they are not included in the list of corporate sponsors in the article. The Sony games division made $3.2 billion in revenue in quarter 1 2016, this is unacceptable.
Yes, some corporate users contribute financially back to the project, and we're thankful. But why should we have to be thankful? The GPL already provides a tried and proven legal framework for requiring downstream users to publish their improvements for others to use. Free software is an ecosystem where everyone helps and everyone benefits. When the BSD license allows parasites like Sony to benefit to the tune of billions of dollars without giving a line of code (or a penny) back, that breaks the ecosystem.
I'm calling Sony out particularly because they are not included in the list of corporate sponsors in the article. The Sony games division made $3.2 billion in revenue in quarter 1 2016, this is unacceptable.
> It's obvious that Sony picked FreeBSD over Linux because they don't have to publish their additions to FreeBSD, and can continue to integrate new and improved code from upstream with no obligations whatsoever.
It's obvious that FreeBSD contributors picked FreeBSD over Linux because they wanted to publish their software for people to use with no obligations whatsoever.
If Sony is heavily modifying the FreeBSD code, eventually they'll start contributing back, because maintaining a substantial fork is more effort than upstreaming code. Either that, or they'll end up with a largely frozen code base like Apple's copy of the FreeBSD userland, which is probably OK on a console.
It's obvious that FreeBSD contributors picked FreeBSD over Linux because they wanted to publish their software for people to use with no obligations whatsoever.
If Sony is heavily modifying the FreeBSD code, eventually they'll start contributing back, because maintaining a substantial fork is more effort than upstreaming code. Either that, or they'll end up with a largely frozen code base like Apple's copy of the FreeBSD userland, which is probably OK on a console.
> Either that, or they'll end up with a largely frozen code base like Apple's copy of the FreeBSD userland, which is probably OK on a console.
I think this is what they've settled on and are quite happy with.
For PS5 they'll likely do another from-scratch adaptation of whatever the then-current FreeBSD is.
I think this is what they've settled on and are quite happy with.
For PS5 they'll likely do another from-scratch adaptation of whatever the then-current FreeBSD is.
> What really makes me sad is that the BSD license allows corporate leeches like Sony to create incredibly successful and valuable products like the PS4 without ever having to give back to the project that produced the software they rely on.
You should not be, because this is what BSD license is for; otherwise the developers would've chosen GPL.
You should not be, because this is what BSD license is for; otherwise the developers would've chosen GPL.
I agree that's what it's for, I just don't think that's a good thing.
What could be the reason Sony dont contribute back. Surely it is a tiny amount of money. May be there are problems they have in minds we are not aware of? Just wondering.
Wouldn't it be a good idea if they would change their licensing so that commercial usage allowed them to build a stable income stream and pay more and more developers every year? Also it would be very important to build developer schools and other educational facilities to sustain development in future, what would be much easier with a stable and growing budget.
Let me guess... You have no idea why people chose to use, or contribute to FreeBSD, right? Especially no idea why commercial entities build products based on FreeBSD.
Sometimes there's a cultural disconnect between the hacker news world and some $FOO software thing (FSF, GNU, what have you), but this tops them all.
Developer schools? Was this even a serious comment or was I trolled by Poe's law?
Sometimes there's a cultural disconnect between the hacker news world and some $FOO software thing (FSF, GNU, what have you), but this tops them all.
Developer schools? Was this even a serious comment or was I trolled by Poe's law?
[deleted]
I was not able to find any answer to my question in your comment. I assume you assume the wrong things, also you seem to draw conclusions too fast.
I think you received a perfectly valid answer. It was not a direct answer, but since the presupposition of your question is so deeply flawed, a direct answer is simply impossible.
However, the answer could have been more detailed and less ranting about HN. Maybe the answer could be improved to:
Things work completely different there. In particular, there are already people and companies making money with selling FreeBSD, and these are also contributing back a lot to FreeBSD. They are contributing back for moral reasons, pragmatic reasons or simply because they like FreeBSD, even though (and sometimes exactly because) they are not pushed to do so by the license.
However, the answer could have been more detailed and less ranting about HN. Maybe the answer could be improved to:
Things work completely different there. In particular, there are already people and companies making money with selling FreeBSD, and these are also contributing back a lot to FreeBSD. They are contributing back for moral reasons, pragmatic reasons or simply because they like FreeBSD, even though (and sometimes exactly because) they are not pushed to do so by the license.
It would be awesome if there were a cookbook for getting this on to the Dragonboard 410c (its my only AArch 64 board ATM). The wiki page points to the 96boards site which has everything you need to put Ubuntu on but not FreeBSD AFAICT. I just may not be reading it closely enough though.
[1] https://wiki.freebsd.org/arm64/DragonBoard410c
[1] https://wiki.freebsd.org/arm64/DragonBoard410c
booting on the Dragonboard is unlikely to happen any time soon, I started working on it, but don't have the time to get it into a usable state (and lack hardware to test).
Source: I started & mostly work on the the FreeBSD arm64 port.
Source: I started & mostly work on the the FreeBSD arm64 port.
> Wireless support for 802.11n has been added.
Wait, What?
Wait, What?
My guess is this part:
The iwn(4) driver was added, providing support for the
Intel® Centrino™ Wireless-N 105 and 135 chipsets. [r266770]
That driver was on OpenBSD for a long time. I put FreeBSD on a machine a year or so ago and really missed that driver. Maybe now I can get rid of the USB dongle I've been using instead.
I think that should read that these chipsets were added to iwn, considering iwn has been in since at least 8.0 (going by my very non-scientific manpage search).
Typo -- should read additional wireless support has been added.
IIRC, OpenBSD added 802.11n support in a recent release.
I still have hope some or all HardendedBSD features might get ported or reimplemented in FreeBSD 12. Too much low hanging fruit, and now that linux has been steadily closing the gap to grsec, the competition in mainstream kernel branches is on.
HardenedBSD is one of the bigger jokes in the BSD community. If you really care about the things it claims to do, I highly recommend using OpenBSD because it actually has competent and sustainable development.
Are you saying that the measures listed here http://hardenedbsd.org/content/easy-feature-comparison do not work properly?
I'm not GP, but yes. They do not work properly and likely introduce additional vulnerabilities.
Do you have any evidence for this? I've heard rumors here on HN and else where that HardenedBSD's code quality is lacking and that they didn't incorporate all the fixes and suggestions from the FreeBSD community during the various code reviews. But none of that is definitive, do you have any proof or evidence for this statement, "They do not work properly and likely introduce additional vulnerabilities."
Here's an example of poor code quality:
https://github.com/HardenedBSD/secadm/commit/3dd7584b70804cf...
If this check did anything, it appears susceptible to time-of-check, time-of-use attack.
See also https://reviews.freebsd.org/D473 , where Shawn pretty cleary does not incorporate feedback from the FreeBSD community.
https://github.com/HardenedBSD/secadm/commit/3dd7584b70804cf...
If this check did anything, it appears susceptible to time-of-check, time-of-use attack.
See also https://reviews.freebsd.org/D473 , where Shawn pretty cleary does not incorporate feedback from the FreeBSD community.
Fair enough. The more important part of my question: isn't there a focused effort to complete FreeBSD's security feature checklist?
No one is paying for completion of checkbox security features in FreeBSD. So the community is really only interested in effective mitigations and not checkbox features.
We would love to merge in Konstantin's ASLR work. Reviewers have pointed out performance issues and memory fragmentation issues, especially on 32-bit platforms, but it's still better than nothing. I think we should just merge it as is, maybe default to off on 32-bit platforms, and improve from there. With the intent to have it polished for 12.0-RELEASE.
One such mitigation receiving community attention is Capsicum. The Capsicum security sandbox is a viable way to constrain applications. Unlike OpenBSD's pledge, rights are limited on a file descriptor basis. It has been ported to Linux and DragonFlyBSD (although merged to neither). There has been a lot of work in FreeBSD lately to restrict base programs, especially setuid programs, using Capsicum.
We would love to merge in Konstantin's ASLR work. Reviewers have pointed out performance issues and memory fragmentation issues, especially on 32-bit platforms, but it's still better than nothing. I think we should just merge it as is, maybe default to off on 32-bit platforms, and improve from there. With the intent to have it polished for 12.0-RELEASE.
One such mitigation receiving community attention is Capsicum. The Capsicum security sandbox is a viable way to constrain applications. Unlike OpenBSD's pledge, rights are limited on a file descriptor basis. It has been ported to Linux and DragonFlyBSD (although merged to neither). There has been a lot of work in FreeBSD lately to restrict base programs, especially setuid programs, using Capsicum.
What has Linux done to close the gap to GRsec?
Kees Cook and others have been porting or reimplementing features exclusive to grsec in upstream linux.
https://outflux.net/blog/archives/2016/09/26/security-things...
https://outflux.net/blog/archives/2016/09/27/security-things...
https://outflux.net/blog/archives/2016/09/28/security-things...
https://outflux.net/blog/archives/2016/09/30/security-things...
https://outflux.net/blog/archives/2016/10/03/security-things...
https://outflux.net/blog/archives/2016/10/04/security-things...
And naturally some stuff is exclusive to linux upstream, though grsec will benefit from those automatically if they deem it good enough.
https://outflux.net/blog/archives/2016/09/26/security-things...
https://outflux.net/blog/archives/2016/09/27/security-things...
https://outflux.net/blog/archives/2016/09/28/security-things...
https://outflux.net/blog/archives/2016/09/30/security-things...
https://outflux.net/blog/archives/2016/10/03/security-things...
https://outflux.net/blog/archives/2016/10/04/security-things...
And naturally some stuff is exclusive to linux upstream, though grsec will benefit from those automatically if they deem it good enough.
> A kernel panic triggered when destroying a vnet(9) jail(8) configured with gif(4) has been fixed. [r271917]
> A kernel panic triggered when destroying a vnet(9) jail(8) configured with gre(4) has been fixed. [r271918]
I see they fixed the kernel panics when destroying vnet jails but is vnet enabled by default? Or do I have to compile a custom kernel like with FreeBSD 10.x
> A kernel panic triggered when destroying a vnet(9) jail(8) configured with gre(4) has been fixed. [r271918]
I see they fixed the kernel panics when destroying vnet jails but is vnet enabled by default? Or do I have to compile a custom kernel like with FreeBSD 10.x
I started using SmartOS partly because it has really nice VNIC support and you don't have to recompile the 10.x FreeBSD kernels. :-) It'd be good to know if 11.0 changed that.
Sadly it's not yet on by default, but it could still happen in the 11.x lifecycle.
Does linux have similar facilities yet?
Yes, a "network namespace" is the Linux equivalent. http://man7.org/linux/man-pages/man8/ip-netns.8.html
I'm pretty sure you'll still need to compile the kernel specifically for VNET. I'm not sure what's stopping it being enabled by default.
TRIM support in GELI (disk encryption), awesome!
Does anyone know if FreeBSD supports PHP-FPM 7+? I'm so ready to drop Ubuntu if so
It is enabled by default in the php55, php56, and php70 ports. (See the "FPM" OPTION in all three.)
Does that answer your question? (Sorry, I'm not familiar with PHP.)
Does that answer your question? (Sorry, I'm not familiar with PHP.)
Yes. Running a setup with many production grade (ie people making their living off of those) WordPress installations on latest php7 and latest mariadb on it.
Using Poudriere so everything uses the latest packages there.
Poudriere is a charm to use so you really wanna do that.
Using Poudriere so everything uses the latest packages there.
Poudriere is a charm to use so you really wanna do that.
lang/php70 is what you want http://www.freshports.org/lang/php70
Regarding the Vagrant image: I'm trying to use it on OSX (El Capitan) with the latest VirtualBox.
When I do vagrant up, I see the following error:
No base MAC address was specified. This is required for the NAT networking to work properly (and hence port forwarding, SSH, etc.). Specifying this MAC address is typically up to the box and box maintainer. Please contact the relevant person to solve this issue.
If I do vagrant up again, it seems to be working, but then I see a lot of:
default: Warning: Remote connection disconnect. Retrying...
and it eventually times out.
Any ideas on how to solve this issue?
Thanks!
When I do vagrant up, I see the following error:
No base MAC address was specified. This is required for the NAT networking to work properly (and hence port forwarding, SSH, etc.). Specifying this MAC address is typically up to the box and box maintainer. Please contact the relevant person to solve this issue.
If I do vagrant up again, it seems to be working, but then I see a lot of:
default: Warning: Remote connection disconnect. Retrying...
and it eventually times out.
Any ideas on how to solve this issue?
Thanks!
Going to grab the 11.0 release image and try installing it on my ThinkPad. Pre-release versions had issues with my Intel chipset that lead to boot loops.
I've got a 10.3 system that's running a "custom" kernel with VNET enabled for my iocage jails. What am I in for when I upgrade? How do I keep my ZFS pool safe through the upgrade?
Why would your zpool be in any danger from the upgrade?
If you upgrade via freebsd-update and have renamed your custom kernel (and not named it GENERIC), then freebsd-update will tell you when to build and install a new version of your kernel.
If you kept GENERIC as the name of your custom kernel, which is a really really bad idea, then freebsd-update will probably still replace it with a vanilla kernel, haven't checked that in a while. In that case either rebuild your 10.3 kernel again with a fixed name, or upgrade to 11 from source.
If you upgrade via freebsd-update and have renamed your custom kernel (and not named it GENERIC), then freebsd-update will tell you when to build and install a new version of your kernel.
If you kept GENERIC as the name of your custom kernel, which is a really really bad idea, then freebsd-update will probably still replace it with a vanilla kernel, haven't checked that in a while. In that case either rebuild your 10.3 kernel again with a fixed name, or upgrade to 11 from source.
If your pool is layed out in a beadm compatible way you can use beadm. Otherwise just snapshot your root dataset recursively and rollback the whole pool in the unlikely case that the update fails. Once the upgrade succeeded (including the new boot blocks) you can upgrade your pool by enabling the latest feature flags.
How much do you think it will take until Juniper JunOS and netApp will upgrade their kernels to 11.0-p1?
Acknowledging this is somewhat inflammatory, both of those companies are absent and incompetent when it comes to open source interaction when compared to others like EMC Isilon and Netflix.
NetApp does tend to be one of the higher financial contributors to the FreeBSD Foundation but this amounts to the salary of one full time engineer. I think the bhyve code drop was a fluke, but a very fortunate one, and the two developers left NetApp quickly after that happened. Outside of that, especially during the formative '90s and '00 where it could have been politically influential, continuing today there is almost no code reintegration. It's hard to find business justification because NetApp is a prime contributor to Linux, including the NFS server which could be argued has allowed companies like PureStorage to eat their lunch.
Juniper has some storied history of many many-year projects to resync their branch. They have their own TCP stack. Many of the influential FreeBSD devs I know there have fled recently. I heard something about switching to Linux. Sounds like a rudderless company, following a nice anti-pattern example set by Yahoo. It is sad because JunOS and the HW was and is for now quite nice.
I work at a small but highly traditional/bureaucratic company and was able to build a 4 person full time upstream BSD team in 2 years. I cannot fathom why NetApp and Juniper would not have a 10-40 people upstream team.
NetApp does tend to be one of the higher financial contributors to the FreeBSD Foundation but this amounts to the salary of one full time engineer. I think the bhyve code drop was a fluke, but a very fortunate one, and the two developers left NetApp quickly after that happened. Outside of that, especially during the formative '90s and '00 where it could have been politically influential, continuing today there is almost no code reintegration. It's hard to find business justification because NetApp is a prime contributor to Linux, including the NFS server which could be argued has allowed companies like PureStorage to eat their lunch.
Juniper has some storied history of many many-year projects to resync their branch. They have their own TCP stack. Many of the influential FreeBSD devs I know there have fled recently. I heard something about switching to Linux. Sounds like a rudderless company, following a nice anti-pattern example set by Yahoo. It is sad because JunOS and the HW was and is for now quite nice.
I work at a small but highly traditional/bureaucratic company and was able to build a 4 person full time upstream BSD team in 2 years. I cannot fathom why NetApp and Juniper would not have a 10-40 people upstream team.
Sigh, you know, the Juniper story is so sad. I even owned stock in it at one time. It started out great, had such potential, and just imploded. Yeah I have heard the rumor of them moving to Linux too. Good luck with that tire fire! They do that and they are dead to me.
It will take buying the company and making it happen.
No mention of ASLR. Helping to prevent memory corruption bugs apparently isn't on their radar?
It's on their radar, but did not make it into 11.0. It's still under code review here:
https://reviews.freebsd.org/D5603
https://reviews.freebsd.org/D5603
The image is from 29th september, is this the updated version?
Seems like they are releasing faster? Nice!
"Wireless support for 802.11n has been added"
C'mon FreeBSD! We're in the 802.11ac era! As much as I love BSD, they're always a couple of years behind the status quo
C'mon FreeBSD! We're in the 802.11ac era! As much as I love BSD, they're always a couple of years behind the status quo
Hi! FreeBSD wifi person here!
* ath(4)'s 11n support is much, much better now. All the AR93xx/AR95xx PCIe devices are supported and STA/AP 11n should work great. * iwn(4)'s 11n is much, much better. It still has some warts, and I'd love some help in chasing them down. * urtwn(4) in -HEAD does 11n now. * rsu(4) in -HEAD does 11n now. * iwm(4) (intel 7260, etc) is getting better every day in freebsd and dragonflybsd. Thanks to another developer for that !I think we're almost ready for starting the 11n bits? once the 11n bits are done and working, we can start on the 11ac bits. * Another developer is working on urtwn/rtwn unification and support for 11ac USB devices from realtek. * I'm working on an ath10k port from Linux to FreeBSD - I have association working now and I'm about to start on normal data TX. Once that's done, I'll get crypto and 11n station mode operation working.
now, where's 11ac? It's mostly waiting for some stable like 11ac devices to appear in the tree with 11n support. 11ac is partially revolution and partially evolution - if 11n doesn't work, 11ac definitely won't work. So, between iwm 11n work, the rtwn/urtwn 11n/11ac USB work going on and my ath10k work, I think we're heading in the right direction.
I'm hoping that once I get ath10k up in monitor, STA and AP mode, with crypto, QoS and 11n working, the 11ac bits will be trivial - at which point I can start on the 11ac stack pieces. I know what those stack pieces are and I've started writing them down - https://wiki.freebsd.org/WiFi/80211ac .
All of this is non-commercial btw - no-one is sponsoring any work on BSD wireless at the present moment. If you'd like to help or contribute, please consider talking and donating to the FreeBSD foundation, or consider funding someone to help in these efforts.
Thanks!
[email protected]
* ath(4)'s 11n support is much, much better now. All the AR93xx/AR95xx PCIe devices are supported and STA/AP 11n should work great. * iwn(4)'s 11n is much, much better. It still has some warts, and I'd love some help in chasing them down. * urtwn(4) in -HEAD does 11n now. * rsu(4) in -HEAD does 11n now. * iwm(4) (intel 7260, etc) is getting better every day in freebsd and dragonflybsd. Thanks to another developer for that !I think we're almost ready for starting the 11n bits? once the 11n bits are done and working, we can start on the 11ac bits. * Another developer is working on urtwn/rtwn unification and support for 11ac USB devices from realtek. * I'm working on an ath10k port from Linux to FreeBSD - I have association working now and I'm about to start on normal data TX. Once that's done, I'll get crypto and 11n station mode operation working.
now, where's 11ac? It's mostly waiting for some stable like 11ac devices to appear in the tree with 11n support. 11ac is partially revolution and partially evolution - if 11n doesn't work, 11ac definitely won't work. So, between iwm 11n work, the rtwn/urtwn 11n/11ac USB work going on and my ath10k work, I think we're heading in the right direction.
I'm hoping that once I get ath10k up in monitor, STA and AP mode, with crypto, QoS and 11n working, the 11ac bits will be trivial - at which point I can start on the 11ac stack pieces. I know what those stack pieces are and I've started writing them down - https://wiki.freebsd.org/WiFi/80211ac .
All of this is non-commercial btw - no-one is sponsoring any work on BSD wireless at the present moment. If you'd like to help or contribute, please consider talking and donating to the FreeBSD foundation, or consider funding someone to help in these efforts.
Thanks!
[email protected]
Thanks Adrian. I am not a device drivers person. But, quick query - do you reuse the current Linux drivers work [0].
Looking at the current client device deployment, Intel owns around 80% of the Wi-Fi modem market. Is anybody from Intel working on BSD wireless drivers as well.
[0] https://wireless.wiki.kernel.org/en/users/Drivers
Looking at the current client device deployment, Intel owns around 80% of the Wi-Fi modem market. Is anybody from Intel working on BSD wireless drivers as well.
[0] https://wireless.wiki.kernel.org/en/users/Drivers
There is reuse, for example iwm(4) is based on the Linux driver and pulls from it. But the process is manual, not like the Linux-KPI graphics and OFED stuff.
It would be great if Intel stepped up to the plate and helped.
It would be great if Intel stepped up to the plate and helped.
I was thinking about a common driver interface similar to POSIX standard would solve the problem of multiple OS device support on a single hardware platform.
There was an effort for Uniform Driver Interface (UDI)[0], looks like it is dormant.
[0] http://wiki.osdev.org/Uniform_Driver_Interface
There was an effort for Uniform Driver Interface (UDI)[0], looks like it is dormant.
[0] http://wiki.osdev.org/Uniform_Driver_Interface
People will probably wrinkle their forehead :) but NDIS is that and a lot of operating systems support it https://www.freebsd.org/cgi/man.cgi?query=ndis&sektion=4&man...
> Is anybody from Intel working on BSD wireless drivers as well?
No.
No.
Hey Adrian,
thanks for the shout-out in the release notes. And thanks for all you do for FreeBSD.
thanks for the shout-out in the release notes. And thanks for all you do for FreeBSD.
Thank you for your efforts! This is great. I personally don't know a ton about wireless but am not opposed to digging in and contributing or testing when/if I have time/hardware. Which leads me to a question: what about 11ac is revolutionary if it's just a few bits away from a completed 11n codebase? Just curious.
11ac adds to 11n. you have new channel widths, instead of just 20 and 40. It's 20, 40, 80, 80+80, 160.
You have MCS0->9, and then you have 1->n spatial streams. It's like 11n, but they didn't make the MCS numbers just keep going up above MCS15, MCS23, etc. Negotiation is easier - you have to do MCS0..7, then you can say whether you also do 8 and 9.
Everything is block-acked when you negotatiate it - even individual frames. It still negotiates AMPDU and AMSDU like 11n, but then everything is BA'ed versus 11n where some frames are and some frames aren't. The 11ac AMPDU is almost the same as 11n, but it adjusts the maximum AMPDU sizes to be much bigger.
It's still MIMO, and you can implement multi-user MIMO when you're ready. You don't have to out of the gate. This makes it easier to do basic 11ac bringup before you have to do more useful optional bits. There are some extra IEs to handle in beacons, probe request/resp, etc, which isn't all that scary.
The trouble(!) is it kinda forces one to tidy up their 11n codebase first. The way we represent channels in net80211, for example. We have one channel for each PHY type and frequency - so, say channel 36. There's 36/a, 36/ht20, 36/ht40. For 1, it's 1/b, 1/g, 1/ht20, 1/ht40. For 11ac we're going to have to add say, 36/vht20, 36/vht40, 36/vht80. Now, 80+80 becomes painful because the other 80MHz slice can be anywhere and that's not easily represented without a massive explosion in the number of channels. So, how channels are fetched/accessed/etc needs to be changed.
There's also the situation where we currently support a "global" channel for a device, rather than one channel per vap, separate scanning state per VAP for full offload devices, etc. That has to change for full offload devices (iwn, iwm, ath10k, rsu, etc) which can do scans in firmware without the stack being involved.
Linux mac80211/cfg80211 solved this with the concept of "channel contexts" - they used to do exactly what we did in net80211 (one channel struct entry per PHY type + channel combo) but fixed it when 11ac came along. Every driver needed modification, so that's going to take some time to plan out and implement.
There's also some tidying up to do with notifying the upper layers about frames. Eg - NICs does AMSDU offload now in the 11ac world. AMSDU is multiple MSDUs in one frame - ie, multiple ethernet frames in a single 802.11 frame. So, you have to tag received frames with some information that states it's a de-cap'ed AMSDU frame with the sequence number, crypto info, etc of the single big 802.11 frame you received. This is problematic because the stack right now expects each frame to have its own sequence number, crypto IV, etc and does duplication detection. I just started committing some newer pieces to the net80211 RX path so we can handle cases like this when AMSDU offload happens - which is very soon now.
So yeah, it's "a few bits away", but since the four of us actively doing wifi stuff in FreeBSD are unpaid volunteers, things happen at the rate of spare time. If you're interested in learning about this stuff and aren't afraid of a C compiler than hit me up ([email protected]) and let's hack on this.
You have MCS0->9, and then you have 1->n spatial streams. It's like 11n, but they didn't make the MCS numbers just keep going up above MCS15, MCS23, etc. Negotiation is easier - you have to do MCS0..7, then you can say whether you also do 8 and 9.
Everything is block-acked when you negotatiate it - even individual frames. It still negotiates AMPDU and AMSDU like 11n, but then everything is BA'ed versus 11n where some frames are and some frames aren't. The 11ac AMPDU is almost the same as 11n, but it adjusts the maximum AMPDU sizes to be much bigger.
It's still MIMO, and you can implement multi-user MIMO when you're ready. You don't have to out of the gate. This makes it easier to do basic 11ac bringup before you have to do more useful optional bits. There are some extra IEs to handle in beacons, probe request/resp, etc, which isn't all that scary.
The trouble(!) is it kinda forces one to tidy up their 11n codebase first. The way we represent channels in net80211, for example. We have one channel for each PHY type and frequency - so, say channel 36. There's 36/a, 36/ht20, 36/ht40. For 1, it's 1/b, 1/g, 1/ht20, 1/ht40. For 11ac we're going to have to add say, 36/vht20, 36/vht40, 36/vht80. Now, 80+80 becomes painful because the other 80MHz slice can be anywhere and that's not easily represented without a massive explosion in the number of channels. So, how channels are fetched/accessed/etc needs to be changed.
There's also the situation where we currently support a "global" channel for a device, rather than one channel per vap, separate scanning state per VAP for full offload devices, etc. That has to change for full offload devices (iwn, iwm, ath10k, rsu, etc) which can do scans in firmware without the stack being involved.
Linux mac80211/cfg80211 solved this with the concept of "channel contexts" - they used to do exactly what we did in net80211 (one channel struct entry per PHY type + channel combo) but fixed it when 11ac came along. Every driver needed modification, so that's going to take some time to plan out and implement.
There's also some tidying up to do with notifying the upper layers about frames. Eg - NICs does AMSDU offload now in the 11ac world. AMSDU is multiple MSDUs in one frame - ie, multiple ethernet frames in a single 802.11 frame. So, you have to tag received frames with some information that states it's a de-cap'ed AMSDU frame with the sequence number, crypto info, etc of the single big 802.11 frame you received. This is problematic because the stack right now expects each frame to have its own sequence number, crypto IV, etc and does duplication detection. I just started committing some newer pieces to the net80211 RX path so we can handle cases like this when AMSDU offload happens - which is very soon now.
So yeah, it's "a few bits away", but since the four of us actively doing wifi stuff in FreeBSD are unpaid volunteers, things happen at the rate of spare time. If you're interested in learning about this stuff and aren't afraid of a C compiler than hit me up ([email protected]) and let's hack on this.
It was support for an additional 802.11n card. Not 802.11n in general.
Have they fixed the remnants of the update security hole? I haven't been keeping up, so they might have done that already, but I thought I'd ask.
Yes. They fixed the theoretical stuff and the things where you'd have required to be root anyway.
In 11.0-RELEASE-p1, or just 11-STABLE? Do you have a link to the commits landing in the RELEASE branch?
In 11.0-RELEASE-p1.
I merged them here: https://svnweb.freebsd.org/base?view=revision&revision=30637...
I merged them here: https://svnweb.freebsd.org/base?view=revision&revision=30637...
Great. Thanks, Ed.
Oh, good.
https://svnweb.freebsd.org/base?view=revision&revision=28719...
POLA violated.
Next FreeBSD will adopt ethX for wired networks and sdX for disks, and systemd for init.
POLA violated.
Next FreeBSD will adopt ethX for wired networks and sdX for disks, and systemd for init.
# : > /usr/bin/bspatch
See https://www.freebsd.org/security/advisories/FreeBSD-SA-16:29...
> Because this vulnerability exists in bspatch, a component used by freebsd-update, a special procedure must be followed to safely update. First, truncate bspatch to a zero byte file.
> FreeBSD-update will fall back to replacing bspatch, rather than applying a binary patch. Proceed with FreeBSD-update as usual.