August 25, 2017
The following is my account of the August 2017, FreeBSD Developer’s Summit in Cambridge University for receiving a travel grant from the FreeBSD Foundation. First, I’ll add a little background context of who I am, and why I wished to attend the conference. I have been a FreeBSD user for a few years now, learning about it in year 2 of my undergraduate education, and using it on nearly all of my computers since that moment. I recently completed my undergrad studies, but more importantly, was accepted into the Google Summer of Code program to work on ZFS Boot Environment tooling with Allan Jude. These two events let me fully dive into not just using FreeBSD, but working on FreeBSD, and I’m quite hooked now. I’ve had an enjoyable and enlightening time working on FreeBSD, and wanted to find out where I could be of use when my GSoC project completes at the end of August.
When we first arrived on August 2nd, we had a half hour or so to chat with each other over coffee prior to topic selection. During that time, I met Deb from the FreeBSD Foundation, and we had a productive conversation on potential articles aimed at newcomers to FreeBSD in various contexts (student, developer, data nerd, etc.).
Then the process of topic selection began. Each person in the circle went around and introduced ourselves and our areas of interest, with a tally being put for each category. When everyone was done, the top 16 topics (after some combining) were chosen. I regret not photographing that whiteboard, because it was a fascinating look into the diversity of what people care to discuss, which was my first real look into how lucky I am to be participating in this.
The first working group I attended was on virtualization. It broke form in that it had a guest speaker from the Docker on OSX team, who spoke a bit on the ways in which the docker codebase has been refactored in recent years, and how that could influence more powerful FreeBSD support. Most applicably, the *containerd* subsystem allows a target to implement the actual docker containment in whatever way is most appropriate for their ecosystem. On Linux, this might consist of lxc containers, on Solaris, zones, and on other platforms, perhaps a VM. As long as your system can provide an isolated namespace and a virtualized network, then you create a valid container definition on it. On FreeBSD, this obviously suggests jails. After some discussion, it seemed like a nice way to approach this would be the “lib-ification” of jail to encompass some of the utilities that the system call doesn’t simply offer (such as jexec), and ifconfig.
After the docker talk, we reviewed various updates and desired features regarding virtualization on FreeBSD. A particularly interesting point to me was live migration on bhyve. There is some work on snapshotting and restoring that folks believed is a good way to start out. While most of the other points brought up were updates on existing work and how to better get resources allocated to those efforts, a thoughtful triage of some requests such as nested virtualization was constructed.
The Security Mitigation Techniques working group was extremely insightful for me in two ways, logistically and technically. Logistically speaking, this meeting was where it occurred to me just how important these developer summits are. The FreeBSD community, among nearly all open source projects, are extremely capable of effective decision making processes in an online context, however given the nature of the medium, it can be quite lengthy. In one hour and forty-five minutes, about 13 topics were brainstormed, intelligently discussed, and a decision was made about their inclusion in planned work. I had never seen such efficiency and thoughtful conversation in an environment before, whether academic, professional or other open source work. It was truly an effectively efficient moment to witness.
On the technical side of the discussion, various randomization techniques, memory protection schemes and update/install related practices were discussed. The lengthiest discussion was about W^X (enforcing that memory locations be strictly either writable or executable, but not both). The interesting part about W^X is that while its implementation is very simple, dealing with the deployment of it opens up many issues. For example, in both the base system, as well as ports, many applications are likely to violate this property (and crash) when it is rolled out. These are inherently runtime issues, which make their discovery difficult. The proposed solution to this is a period of time in which W^X violations are logged, so that developers can easily discover what would need to be patched. Additionally, other security enhancements, such as (K)ASLR, and stack protection schemes were discussed.
The desktop/usability working group session grew into a really productive conversation on a diverse selection of topics, which was augmented by a tweet that Gavin Atkinson put out, asking the community for their input as well.
The session began focusing on the driver-centric issues: graphics, suspend/resume, and WiFi. Graphics work is very promising with the drm-next work. This code depends on a GPL licensed shim, so cannot readily live in the base system with out a rewrite, but in the mean time there is a base package that exists.
Regarding suspend/resume, the conversation focused on how, while there is a plethora of useful information between the wiki/handbook and forums, it can sometimes be difficult to piece together various techniques that might lead to a solution, or at least a cause. To remedy this, a script was proposed that would attempt many known techniques until it arrives at a working configuration, or at least provide useful information as to why it didn’t function.
The topic of Wifi intersected heavily with a review of the state of certain peripheral protocol drivers, such as i2c and SDIO. There seems to be a recent tendency toward Wifi using these protocols, especially on embedded devices, for example the Raspberry Pi 3 using SDIO for it’s wifi. There is work currently being done on SDIO, but HID over i2c is a configuration that is starting to show up on more and more hardware, and therefore would be nice to incorporate as well.
After these points, a lengthy conversation about the installer took place, specifically in the context of automation and default settings. A reasonable scheme was discussed in which the installer would have two phases: a configure phase, and an install phase. The benefit of this approach is that one could have a configuration file that they have already crafted, and bypass the configuration phase by using it. Additionally the user-experience could be improved at some points. The example that was brought up was feedback: currently there are situations such as DHCP configuration where there is no actual indicator of success or failure. While that is one example, folks were able to list off many of these little points that contribute to an experience that might be less ideal than other installers. Additionally, Dialog and its library could certainly use a rewrite to remove any dependency on GPL code in the installer.
The discussion then focused on how we might better set up users with a usable desktop environment out of the box. This chat very quickly circled back to discussion of the installer, where we could perhaps have support for setting defaults for popular use cases, such as workstation, storage-server, vanilla, etc.
Overall, I was very impressed with the professionalism and humility of the conversation. Often times, it can be easy to become attached to a way that something operates if it is sufficient for one’s self and then become resistant to feedback. That was simply not the case in this conversation. It seemed as though everyone in the room was an advocate for the user.
Packaging base, specifically usability and informational improvements, were a large part of the Packaging Working Group’s discussion. Packaging base obviously has many benefits, but accrues small organizational work here and there, that haven’t needed to be considered in the past. Some of these are related to versioning and making the associated metadata available to the end user, such as including the revision number on base packages. Other improvements that were suggested were a kernel selection menu at boot and creating packages of source that at various revisions that correspond to the packages at that time. Echoing some of the discussion in the desktop working group, sets of packages that accomplish a goal were discussed in more length, but also modifications to port/pkg infrastructure to add some flexibility in dependency satisfiability.
I found the teaching working group discussion to be very engaging. The session was a balance between pedagogy, presentation, and tooling, with many perspectives and demographics considered. In terms of pedagogy, the TeachBSD philosophy of learn-by-tracing, was discussed a bit, which is such a great resource to have publicly available. The blend of academic and community educators in the room provided a unique skill share opportunity to learn from each others techniques, styles, and materials. The most actionable points came from talking about videos and personal embedded computers. The professors in the room were no stranger to filming lectures, but tips were traded on video production quality to assist in giving this information a second life, and this evolved into a reflection on the shift towards online video content in the skill learning realm, and how we can adapt some of resources (blog posts, books, the handbook) to that format.
The hardware in which people might learn FreeBSD on, particularly in a lab setting, was discussed as well. The TeachBSD material is targeted toward the Beaglebone Black for understandable technical reasons, but at a steeper price tag and less ubiquity than the Raspberry Pi models makes it perhaps less accessible to get started with. For this reason, it was decided to put a conscious effort into improving support for the capabilities of cheaper embedded boards (which ties into the SDIO Wifi work discussed in the Desktop/Usability section).
I’ve never been very into those highly hyped-up product unveilings that Apple or video game manufacturers might do…but I get it now. The Storage Working Group was essentially one of those events but for ZFS on FreeBSD fans who are slightly behind on their mailing list readings. Allan Jude, provided an informative survey of upcoming ZFS features and current work being done in both FreeBSD and OpenZFS. Among these topics were the state of native ZFS encryption, the work being done for including the zstd compression library, atomic-transaction-like channel programs, and many performance improvements, both in terms of storing the data (RAID-Z, Compressed ARC) and operating upon a pool or filesystem (scrubbing). The wiki page on this discussion has a full list of features discussed, along with some clarifying points on what may be holding up some discussed components.
Of course, the DevSummit wasn’t limited to the activities listed on the schedule. From nightly impromptu dinners (and one marvelously luxurious dinner in St. John’s College thanks to Google!), the nerdy pilgrimage to The Centre For Computing History where we got to examine and play Tetris on James Newman’s “MegaProcessor” (seen in this Computerphile video: ), and the quintessential Cambridge punting trip on the River Cam, there was so much opportunity for socialization with fellow attendees. I can’t stress enough how important that aspect seems to a project in which the majority of interactions are through text on a screen. The FreeBSD community has been extremely helpful to me in my short time being involved with the project, however, in person, it is even more clear how welcoming of a community it is. Events like these seem to crucial to a flourishing open source project. If you have never been, I highly recommend attending one…but beware, you might end up volunteering for things you never had thought about contributing to before!
In closing, this trip was a very important experience to me. I am very grateful to the FreeBSD Foundation, and every person I met for making this a possibility for me. I look forward to continuing to give back to a project that has provided me with so much, both in terms of software and opportunity, in the past years.