FreeBSD 11.0 Now Available
lists.freebsd.org
lists.freebsd.org
# : > /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.
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.
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.)
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.
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).
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.
You mean I can run multiple postgresql jails on a machine? YASSS
Unfortunately, VNET is still off by default, no?
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.
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.
* 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.
Graphics support for bhyve is also pretty spiffy.
[1]: https://svnweb.freebsd.org/base?view=revision&revision=30090...
Is this a unique feature or how is this handled on illumos or Solaris?
Just pointing it out cause it was only mentioned in brackets.
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'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. :(
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.
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 >_<
if bash is installed; if not, at least it's a fairly clear indication that you should install bash
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.
We'll, there's always Debian/kFreeBSD for that...
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).
Other than all that, it works well.[0]: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=189811
[1]: https://github.com/FreeBSDDesktop/freebsd-base-graphics/wiki
I sure miss being able to understand and control my machine...
FreeBSD can be pretty spartan, but I do feel like I'm more in control.
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).
$ 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 romThat'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
And then you can create a swap file or volume on sda2, so long as it isn't on btrfs.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.
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.
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.
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.
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.
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.
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.
% gcloud compute instances create INSTANCE --image freebsd-11-0-release-p1-amd64 --image-project=freebsd-org-cloud-dev
% gcloud compute ssh INSTANCEvagrant init freebsd/FreeBSD-11.0-RELEASE-p1
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.
This is discussed on BSD Now 162 https://www.youtube.com/watch?v=fJ-mgwxhNvo
So, have you donated yet? We need FreeBSD and FreeBSD needs your support!
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?
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.
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.
You should not be, because this is what BSD license is for; otherwise the developers would've chosen GPL.
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.
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.
Source: I started & mostly work on the the FreeBSD arm64 port.
Wait, What?
The iwn(4) driver was added, providing support for the
Intel® Centrino™ Wireless-N 105 and 135 chipsets. [r266770]
from: https://www.freebsd.org/releases/11.0R/relnotes.html#drivers...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://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.
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.
> 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
Looking forward to that sweet, sweet IPSEC by default.
Brought to you from a custom compiled FreeBSD 11-p1 host :(
Does that answer your question? (Sorry, I'm not familiar with PHP.)
Using Poudriere so everything uses the latest packages there.
Poudriere is a charm to use so you really wanna do that.
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!
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.
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.
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
* 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!
adrian@freebsd.org
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 (adrian@freebsd.org) and let's hack on this.
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.
No.
It would be great if Intel stepped up to the plate and helped.
There was an effort for Uniform Driver Interface (UDI)[0], looks like it is dormant.
Any plans to support these in the future?
thanks for the shout-out in the release notes. And thanks for all you do for FreeBSD.
I merged them here: https://svnweb.freebsd.org/base?view=revision&revision=30637...
POLA violated.
Next FreeBSD will adopt ethX for wired networks and sdX for disks, and systemd for init.