Matt Macy added support for current Intel and amdgpu graphics out of tree for now https://github.com/FreeBSDDesktop/freebsd-base-graphics/tree.... It is up to Linux 4.7. The graphics stuff is MIT licensed and the linuxkpi is re-implemented so it will eventually trickle into 11.x or 12 and/or a loadable module packaged with FreeBSD Ports.
Still lots of rough edges but it's pretty fun to watch and participate.
That they do, and that's quite admirable (and important, since nVidia won't port their binary blob drivers; and nouveau doesn't run on OpenBSD either.)
Out of the box ZFS boot is still more important to me than getting rid of my Radeon card, though.
Async sendfile, TCP/IP improvements, RSS are things that stand out for my workload. bhyve with UEFI and graphics is probably pretty neat to many folks. VNET (jails closer to Solaris zones with their own network stack) is also closer to correct.
There's a lot of groundwork that will make 11.1 exciting as a followup too (for new TCP stacks, memory management scalability)
"The Release Engineering build tools have been updated to include support for producing virtual machine disk images for various cloud hosting providers. [r277458] (Sponsored by The FreeBSD Foundation)"
We're running FreeBSD in AWS rather successfully. 11 seems to add a few things that are aimed directly at first-class support for building and running VMs and AMIs. Good to know continued support is being focused in this direction.
Mostly ease of use. It's a rock. I have a special place in my heart for BSD, but that aside, when the SystemD battles started and I was on Ubuntu, I was interested in using ZFS for a few things. So the choices were ZFS on Linux, or go back to BSD. After about an hour of playing around, I ended up back on FreeBSD.
So, it's partly personal, as all things are. But it's mostly how easy it is to use, especially for someone that wouldn't describe themselves as a server admin of any special level of skill. There are a few core tenets of design in BSD/FreeBSD that are both beautiful and very easy to understand. So I can ignore the OS a lot of the time and just get to work on the app side.
It's good to see the DRM (graphics) stuff more up-to-date in 11.0. FreeBSD is frustratingly close to natively-just-works on my 2014 Asus Haswell ultrabook (support for scrolling with the touchpad, of all things, is the main thing missing; also volume/screen hotkeys). I hope the laptop hardware support keeps improving!
Anyway, I really appreciate the simplicity of rc.conf and the well-curated config/boot infrastructure in general; pkg(ng) just works; ZFS is insanely cool; LLVM-as-system-compiler is nice... I sometimes wonder where we'd be if the BSD lawsuit hadn't held things back 20-ish years ago.
> BSD lawsuit hadn't held things back 20-ish years ago
Linus said he wouldn't have written Linux if he had 386bsd at that time, which took longer. What that means is up for speculation, but Linux became wildly popular as a host for Apache and Samba before anything else. Similarly, if Oracle hadn't closed off Solaris, maybe FreeBSD wouldn't be the best compromise between hardware support and ZFS+DTrace availability.
PS: XFS is about to gain COW and data checksum support, probably generally available next year.
> PS: XFS is about to gain COW and data checksum support, probably generally available next year.
Do you have link for that? XFS supports metadata checksumming already and cp --reflink IIRC but I've never heard about data checksums and "real" COW e.g. snapshots?
Nicely said! *BSDs are amazing systems and I try to recommend them to a lot of people, colleagues and friends. Many of them were Linux fans, but after they tried FreeBSD, they were asking themselves why is that system so underrated.
> I sometimes wonder where we'd be if the BSD lawsuit hadn't held things back 20-ish years ago.
BSD would be at the same place as today! People love to bring up the AT&T UNIX lawsuit like it did damage to BSDs popularity but never bring up the SCO Linux lawsuit which saw Linux grow and become more popular in spite of having a multi year lawsuit against it.
BSD is where it is in part because of the BSD license, and Linux is where its at because of the GPL.
They port code from one codebase to the other, and often it's the same dev doing the work for more than one OS, but there isn't any principled coordination of effort to keep a unitary codebase for anything.
The three of them already use basically the same package system. The package management suite (pkg_add, pkg_info, etc.) and the ports collections all originated from work Jordan Hubbard did for FreeBSD in 1994. OpenBSD re-wrote all the tools, but they are functionally the same. NetBSD (pkgsrc, really) added a frontend (pkgin) to offer a more "modern", apt-like experience. FreeBSD added a similar frontend (pkg) in version 10.
As far as I know, there is no binary compatibility between the three of them, so sharing package repositories would be a no-go, but if you know the tools on one system, that knowledge is transferable to the others, for the most part.
If you want to use the same exact ports collection on each of them, NetBSD's pkgsrc is quite portable, and will work not only on the other BSDs, but on Linux, Mac OS X, Minix, Solaris, and a few others as well. I use pkgsrc to manage packages on my Mac Mini -- Joyent provides binaries for most things, and the other stuff is usually just a `bmake` away.
It is rather more rocky than that. (pkgng arrived in FreeBSD 9.1, by the way. Not 10.)
* pkgng has some stark differences to OpenBSD pkg, most notably the notion of Debian-like "post-install", "pre-remove", et al. scripts.
* The systems compress packages with different tools. OpenBSD pkg uses gzip. FreeBSD pkg uses xz.
* OpenBSD has a notion of "package flavours" that does not really have an analogue in pkgng.
* The introduction of pkgng was distinctly problematic. A lot radically changed in early versions, most critically the configuration file format. It used to be YAML. It's now UCL.
* The documentation is misleading to the point of being downright wrong. The FreeBSD wiki still insists (https://wiki.freebsd.org/pkgng#Metadata) that the configuraton file is YAML. The manual page for pkg-create gives examples such as "name pkg-name" and "file sha256-hashpath", which is syntactically incorrect for either language and the wrong keyword to boot. Following the manual does not produce a working configuration file. Ironically, the wiki provides better information on this, even though it provides that information in the wrong configuration language.
* The documentation is misleading to the point of being downright wrong. The FreeBSD manual page for pkg-repository claims that repositories contain files named packagesite.txz, repo.txz, and filesite.txz. In fact, the pkg repo tool generates files named packagesite.txz, meta.txz, and digests.txz .
* OpenBSD pkg and FreeBSD pkg don't really have a common notion of "package repositories". The ways to organize pulling packages from remote storage locations are quite different, even down to the fundamental file fetching tools. FreeBSD has fetch. OpenBSD has ftp.
All that having been said: the idea that a unified packaging system necessitates a unified codebase is disproven by Ubuntu and Debian. (An example is OpenRC: present on Debian 8 at https://packages.debian.org/source/jessie/openrc, up to version 0.21 in what is to be Debian 9, and gone from Ubuntu 16 at http://packages.ubuntu.com/xenial/openrc) Conversely, one can have a unified codebase even with multiple packaging systems.
This is all true, but I was mostly comparing the pkg_* tools (pkg_add, pkg_info, etc.) that were used before the arrival of (NetBSD's) pkgin or (FreeBSD's) pkgng (does OpenBSD have something similar? If so, I haven't used it at this point).
Some, but things that would be package-compatible are likely to be source-compatible anyway and shared among Linux, BSD, and Illumos pretty well with existing mechanisms. It's the base operating system that is hit-and-miss with code sharing.
In case anyone cares, I have chased this up with very helpful people in #freebsd-bugs on Freenode. I am unable to reproduce this bug myself either on 10.2 or 10.3. Any more info would be appreciated.
Still lots of rough edges but it's pretty fun to watch and participate.