It's already our two-year anniversary! This time on the show, we'll be chatting with Scott Courtney, vice president of infrastructure engineering at Verisign, about this year's vBSDCon. What's it have to offer in an already-crowded BSD conference space? We'll find out.
This episode was brought to you by
Headlines
OpenBSD hypervisor coming soon
Our buddy Mike Larkin never rests, and he posted some very tight-lipped console output on Twitter recentlyFrom what little he revealed at the time, it appeared to be a new hypervisor (that is, X86 hardware virtualization) running on OpenBSD -current, tentatively titled "vmm"Later on, he provided a much longer explanation on the mailing list, detailing a bit about what the overall plan for the code isOriginally started around the time of the Australia hackathon, the work has since picked up more steam, and has gotten a funding boost from the OpenBSD foundationOne thing to note: this isn't just a port of something like Xen or Bhyve; it's all-new code, and Mike explains why he chose to go that routeHe also answered some basic questions about the requirements, when it'll be available, what OSes it can run, what's left to do, how to get involved and so on***
Why FreeBSD should not adopt launchd
Last week we mentioned a talk Jordan Hubbard gave about integrating various parts of Mac OS X into FreeBSDOne of the changes, perhaps the most controversial item on the list, was the adoption of launchd to replace the init system (replacing init systems seems to cause backlash, we've learned)In this article, the author talks about why he thinks this is a bad ideaHe doesn't oppose the integration into FreeBSD-derived projects, like FreeNAS and PC-BSD, only vanilla FreeBSD itself - this is also explained in more detailThe post includes both high-level descriptions and low-level technical details, and provides an interesting outlook on the situation and possibilitiesReddit had quite a bit to say about this one, some in agreement and some not***
DragonFly graphics improvements
The DragonFlyBSD guys are at it again, merging newer support and fixes into their i915 (Intel) graphics stackThis latest update brings them in sync with Linux 3.17, and includes Haswell fixes, DisplayPort fixes, improvements for Broadwell and even Cherryview GPUsYou should also see some power management improvements, longer battery life and various other bug fixesIf you're running DragonFly, especially on a laptop, you'll want to get this stuff on your machine quick - big improvements all around***
OpenBSD tames the userland
Last week we mentioned OpenBSD's tame framework getting support for file whitelists, and said that the userland integration was next - well, now here we areTheo posted a mega diff of nearly 100 smaller diffs, adding tame support to many areas of the userland toolsIt's still a work-in-progress version; there's still more to be added (including the file path whitelist stuff)Some classic utilities are even being reworked to make taming them easier - the "w" command, for exampleThe diff provides some good insight on exactly how to restrict different types of utilities, as well as how easy it is to actually do so (and en masse)More discussion can be found on HN, as one might expectIf you're a software developer, and especially if your software is in ports already, consider adding some more fine-grained tame support in your next release***
Interview - Scott Courtney -
[email protected] / @verisign
News Roundup
OPNsense, beyond the fork
We first heard about OPNsense back in January, and they've since released nearly 40 versions, spanning over 5,000 commitsThis is their first big status update, covering some of the things that've happened since the project was bornThere's been a lot of community growth and participation, mass bug fixing, new features added, experimental builds with ASLR and much more - the report touches on a little of everything***
LibreSSL nukes SSLv3
With their latest release, LibreSSL began to turn off SSLv3 support, starting with the "openssl" commandAt the time, SSLv3 wasn't disabled entirely because of some things in the OpenBSD ports tree requiring it (apache being one odd example)They've now flipped the switch, and the process of complete removal has startedFrom the Undeadly summary, "This is an important step for the security of the LibreSSL library and, by extension, the ports tree. It does, however, require lots of testing of the resulting packages, as some of the fallout may be at runtime (so not detected during the build). That is part of why this is committed at this point during the release cycle: it gives the community more time to test packages and report issues so that these can be fixed. When these fixes are then pushed upstream, the entire software ecosystem will benefit. In short: you know what to do!"With this change and a few more to follow shortly, Libre*SSL* won't actually support SSL anymore - time to rename it "LibreTLS"***
FreeBSD MPTCP updated
For anyone unaware, Multipath TCP is "an ongoing effort of the Internet Engineering Task Force's (IETF) Multipath TCP working group, that aims at allowing a Transmission Control Protocol (TCP) connection to use multiple paths to maximize resource usage and increase redundancy."There's been work out of an Australian university to add support for it to the FreeBSD kernel, and the patchset was recently updatedIncluding in this latest version is an overview of the protocol, how to get it compiled in, current features and limitations and some info about the routing requirementsSome big performance gains can be had with MPTCP, but only if both the client and server systems support it - getting it into the FreeBSD kernel would be a good start***
UEFI and GPT in OpenBSD
There hasn't been much fanfare about it yet, but some initial UEFI and GPT-related commits have been creeping into OpenBSD recentlySome support for UEFI booting has landed in the kernel, and more bits are being slowly enabled after reviewThis comes along with a number of other commits related to GPT, much of which is being refactored and slowly reintroducedCurrently, you have to do some disklabel wizardry to bypass the MBR limit and access more than 2TB of space on a single drive, but it should "just work" with GPT (once everything's in)The UEFI bootloader support has been committed, so stay tuned for more updates as further progress is made***
Feedback/Questions
John writes inMason writes inEarl writes in***