EuroBSDcon 2013 Developer Summit Special Status Report

From owner-svn-doc-head@FreeBSD.ORG Sun Dec 1 08:37:35 2013 Return-Path: Delivered-To: svn-doc-head@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 2864AE1B; Sun, 1 Dec 2013 08:37:35 +0000 (UTC) Received: from svn.freebsd.org (svn.freebsd.org [IPv6:2001:1900:2254:2068::e6a:0]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 123E217E1; Sun, 1 Dec 2013 08:37:35 +0000 (UTC) Received: from svn.freebsd.org ([127.0.1.70]) by svn.freebsd.org (8.14.7/8.14.7) with ESMTP id rB18bZNK048866; Sun, 1 Dec 2013 08:37:35 GMT (envelope-from pgj@svn.freebsd.org) Received: (from pgj@localhost) by svn.freebsd.org (8.14.7/8.14.5/Submit) id rB18bYBD048864; Sun, 1 Dec 2013 08:37:34 GMT (envelope-from pgj@svn.freebsd.org) Message-Id: <201312010837.rB18bYBD048864@svn.freebsd.org> From: Gabor Pali Date: Sun, 1 Dec 2013 08:37:34 +0000 (UTC) To: doc-committers@freebsd.org, svn-doc-all@freebsd.org, svn-doc-head@freebsd.org Subject: svn commit: r43269 - head/en_US.ISO8859-1/htdocs/news/status X-SVN-Group: doc-head MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-BeenThere: svn-doc-head@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: SVN commit messages for the doc tree for head List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Dec 2013 08:37:35 -0000 Author: pgj Date: Sun Dec 1 08:37:34 2013 New Revision: 43269 URL: http://svnweb.freebsd.org/changeset/doc/43269 Log: - Import an initial version for the EuroBSDcon 2013 Developer Summit Special Report Reviewed by: bcr, erwin, grehan, hselasky, Matthew Ahrens Added: head/en_US.ISO8859-1/htdocs/news/status/report-2013-09-devsummit.xml (contents, props changed) Modified: head/en_US.ISO8859-1/htdocs/news/status/Makefile Modified: head/en_US.ISO8859-1/htdocs/news/status/Makefile ============================================================================== --- head/en_US.ISO8859-1/htdocs/news/status/Makefile Sat Nov 30 18:31:04 2013 (r43268) +++ head/en_US.ISO8859-1/htdocs/news/status/Makefile Sun Dec 1 08:37:34 2013 (r43269) @@ -62,6 +62,7 @@ XMLDOCS+= report-2013-01-2013-03 XMLDOCS+= report-2013-04-2013-06 XMLDOCS+= report-2013-05-devsummit XMLDOCS+= report-2013-07-2013-09 +XMLDOCS+= report-2013-09-devsummit XSLT.DEFAULT= report.xsl Added: head/en_US.ISO8859-1/htdocs/news/status/report-2013-09-devsummit.xml ============================================================================== --- /dev/null 00:00:00 1970 (empty, because file is newly added) +++ head/en_US.ISO8859-1/htdocs/news/status/report-2013-09-devsummit.xml Sun Dec 1 08:37:34 2013 (r43269) @@ -0,0 +1,915 @@ + + + + + + September + 2013 + + +

+ EuroBSDcon 2013 Developer Summit Special Status Report + +

This special status report contains a summary of the discussions + from the various working groups at the EuroBSDcon 2013 Developer + Summit. The &os; Project organizes developer summits at various + events, typically at the major BSD conferences, so that developers + can meet and discuss matters in person.

+ + + Toolchain and Build Systems + + + + + Brooks + Davis + + brooks@FreeBSD.org + + + + + Summary + Notes + Cambridge notes + Roadmap + + + +

The discussions on toolchains and build systems happened in + Malta has started a month earlier in Cambridge. There, the main + themes were source code analysis, the status of replacing GCC, + and a discussion of packaging the base system. Notes on these + and other topics can be found on the session page on the + wiki.

+ +

Source code analysis took several directions. We discussed + adding annotations to the source tree to support various advanced + analysis tools. There was general agreement that this has some + downsides if they get out of date, but that it is useful so long + as the annotations are verified. Most proposed annotation + require some sort of LLVM support so we discussed the process of + integrating LLVM analysis into the build framework. We also + discussed the idea of running various analysis tools as part of + the tinderbox framework.

+ +

In the context of replacing GCC we discussed David Chisnall's + plan to stop building GCC and libstdc++ on systems where + Clang is the default compiler (this has happened). Further, we + plan to migrate all existing platforms to Clang or an external + GCC by 11. External toolchain support currently works with + Clang, but not GCC.

+ +

Finally, Baptiste Daroussin discussed his proposal to package + base with packages as a replacement for the current tarballed + distributions. Once this is done, it is possible to do the tasks + freebsd-update(8) does including upgrades and detecting + changed files in a more operating-friendly way. Using + pkg(8) as a replacement for freebsd-update(8) + is not a general solution yet as package signing and delta + support is required to make it viable.

+ +

In Malta we covered two main topics. The overall status of + non-permissively licensed (GPL-licensed) software in the base + system and a detailed discussion of the status of external + toolchain support. We also decided that a future meeting should + discuss making incremental builds practical and that we should + run a working group specifically on the kernel build system at a + future conference.

+ +

About half the meeting was consumed by a detailed walkthrough + of the GPLinBase wiki page (see links). A number of + areas need modest amounts of work and binutils + replacement needs quite a bit. In practice, we believe we have + most of the required pieces in either the ELF Toolchain project + or LLVM, but the work of identifying pieces and testing them + with base and ports will take some time.

+ +

We then discussed the status of Warner Losh's work on adding + support for GCC to the external toolchain infrastructure and on + upstreaming patches to GCC. Fortunately, the majority of our + changes to GCC in base are x86 modernization which is no longer + required in new releases. In practice, we have about 2000 lines + of changes that should be merged and a few hundred more we + should add to cross toolchain ports. In addition to creating a + modern cross GCC, the external toolchain support needs work due + to differences in support for -B and possibly + --sysroot between Clang and GCC. Further discussions + of external toolchain support occurred in the Embedded + session.

+ + + + + Documentation + + + + + Benedict + Reuschling + + bcr@FreeBSD.org + + + + + Summary + + + +

We wanted to try something new this year, so instead of doing a + lot of talk, we focused on doing actual work, and fixing PRs in + collaboration with the attendees who participated the working + group. It turned out that it did not work so well, because we + had a lot of things to discuss, but some issues were fixed + eventually.

+ +

There was a huge demand for a new webpage: it has to be more + modern to catch up with the recent trends. It should provide + dynamic content like blogrolls, twitter feeds, etc. Currently, + the problem is that the web site lacks many basic + functionalities, such as the search option is not working + properly. Isabelle Long has been working on integrating the + DuckDuckGo search engine into the web site, and she will + hopefully commit the necessary changes soon. There are other + problems, for example, there is no link to the &os; Forums, + while they have established themselves as another support option + for users.

+ +

Then the representatives of the &os; Foundation joined our + group and showed us what they have been working on. They showed + a design proposal for their website. Their suggestion is to + make the &os; Foundation website look similar to the &os; + Project website, so these pages could be connected visually. + Judging from the fancy proposal they have shown us, it will + probably take a lot of infrastructural work to make our website + look closely to the Foundation's. As a result, we agreed to + form a team for the new website, assembled from Project members + internally, to ensure that the new design satisfies expectations + from all sides, e.g. administration, functionality, security, + and so on.

+ +

Another thing that we have talked about was the on-going print + edition work of the &os; Handbook. We have promised to complete + the effort by BSDCan this year, but apparently we could not make + it in time. Dru Lavigne went through the whole Handbook and + identified many problems to solve (outdated content, unrelated + sections, etc.) in order to have a really good content ready for + the printed edition. We need more content and reviewers, so if + you are looking through the Handbook and meet an outdated + section, please contact the Documentation Team. You do not have + to send patches right away, it is enough to provide a few + sentences or a paragraph only to improve or add the description + for the given system functionality. The Documentation Team will + then take care of putting them in the Handbook or the relevant + documents.

+ +

We also discussed the idea of having maintainers assigned to + specific sections and chapters of the Handbook, similarly to the + policy implemented in the Ports Collection, so users and related + PRs can be forwarded to them, and the maintainers take care of + keeping those areas in the documentation up-to-date. The goal + is to reduce the overall workload on the Documentation Team.

+ +

Finally, it was mentioned at the vendor group that we want to + revamp our actual workflow for translating documents. We are + currently doing the translation work by using a standard editor + translating sentence by sentence, which is tedious. In addition + to that, most of the translator teams are really small, so it is + hard for them to catch up with the changes in the English + documents and they become outdated quickly. We have briefly + talked with Gavin Atkinson about removing really outdated + documentation from the doc tree, like the ones who are + still reflecting &os; 5.x or so. In summary, the main + objective is to have a system that helps keeping track of + translations, like the PC-BSD developers are doing: we are aware + that Kris Moore has written some scripts to extend the standard + tools like Pootle to improve their efficiency. It would be a + huge win to see how many sentences are already translated, how + many are left to translate, how many of them could be reused + using such a system. Another benefit of these systems is that + they can provide an interface for casual contributors to provide + translations which can be then checked and committed by the + documentation developers.

+ + + + + Desktop + + + + + Kris + Moore + + kmoore@FreeBSD.org + + + + + Summary + + + +

In the Desktop working group, Kris Moore summarized the changes + made over the last few months in the world of PC-BSD. Builds + based on the freshly released 9.2-RELEASE are in + progress, and future builds based on 10-STABLE are + coming soon. The plan there is to track the 10-STABLE + branch until it becomes 11-STABLE. Kris also described + the rolling release model they have been switched to. + This approach leverages freebsd-update(8) to provide + rolling updates for the base system (that is, the kernel and the + userland utilities) and in parallel with that, pkg(8) + is employed for the packages, especially for the desktop + applications. It was also reported that the PC-BSD staff has + improved the ZFS integration of their tools, including the + installer. Another highlight of the upcoming PC-BSD releases is + that they will include Gleb Kurtsou's PEFS that provides user + encryption of user home directories with PAM-based + authention.

+ +

Next, the current in-progress items were reported and + discussed. The sysutils/pcbsd-utils and + sysutils/pcbsd-utils-qt4 ports have been recently added + to the ports tree that contain all PC-BSD developed tools and + utilities, where the former features the command-line and the + latter features the GUI-enabled versions of the corresponding + programs. The PC-BSD developers have been also working on a + life-preserver ZFS command-line and GUI utility, which is + still in heavy development. The purpose of this tools to + leverage ZFS for snapshot and replication functionality as a + backup solution.

+ +

Finally, the plans for PC-BSD 10 was summarized. The PBI + package format that PC-BSD employs in now under revision and + will be updated to use pkg(8) repository to build PBIs, + provide better integration for server PBIs. As part of this + effort, it will be also investigated whether it is possible to + run PBIs without actual installation. pc-sysinstall + will have a text-based front-end. This is going to be basic at + first, but later it will provide a command-line interface to do + installation with the pc-sysinstall backend.

+ + + + + Virtualization + + + + + Peter + Grehan + + grehan@FreeBSD.org + + + + + Summary + Notes + + + +

In the virtualization working group, Peter Grehan gave a usual + status report. In &os; 10, a lot of pieces of work have + been going on for the last two years, so we are slowly getting + the guest support of Xen, PHVM, Hyper-V drivers, and + bhyve(4) into 10.0-RELEASE. We talked about little bit + about bhyve(4) memory overcommit work that Neel + has been doing for a quite long time, but we are hoping that it + will get into 10 as well. It gives much better integration with + management of guest memory, with the &os; Virtual Memory + subsystem, so we can actually page guest memory to swap. Some + of the future directions for the bhyve(4) work has been + also discussed: we want to shift away from the user-space boot + loader, and use the BSD-licensed UEFI code from Intel as a boot + ROM, we want to have more Windows guest support at some point, + and getting the ability to suspend and resume the guests, which + eventually leads adding support for live migration.

+ + + + + ZFS + + + + + Martin + Matuška + + mm@FreeBSD.org + + + + + Matthew + Ahrens + + mahrens@delphix.com + + + + + + +

For starting up, Justin Gibbs gave an overview of shingled media + which is a new hardware technology that is coming from the hardware + vendors. We talked about some performance issues with that, came up + with some simple ideas of how to make sure that everything can get + take advantage of this, or actually not to have bad performance when not + deleting just overwriting the data. We finally came to the conclusion + that it is probably very hard to do better than that.

+ +

Then a status report of ZFS on other platforms besides &os; and + Illumos was given. On Linux, it basically works, it is being + actively developed, it is in the kernel. On Mac OS X, it is + quite immature, but there is a lot of work going on there. On + Oracle Solaris, they are still working on ZFS but probably we + will never see source code from them.

+ +

We talked about creating a common, cross-platform code + repository for ZFS that all the platforms would pull code from. + The idea here is that all the platforms available would get the + platform-independent code from there verbatim, so getting + changes into all platforms is much easier. This would not + include things like the ZPL, which need to interface with each + platform-specific VFS layer, but that would reduce the hackyness + of the Solaris Porting Layer that are in &os; and in Linux while + adding a little bit of porting layer to Illumos. We talked + about how we should stage this work and we decided we definitely + want to try to include the Linux developers from the beginning + rather than doing just an Illumos plus &os; and then tackling on + the Linux layer.

+ +

Next, we talked about test coverage and what tests are + available. Spectra Logic has finished porting the STF test suite + to &os;, so we discussed how we can make them more widely + available, and potentially getting them into the main source + tree. Eventually, it will become part of the independent code + repository but it may take a while to get there.

+ +

And then we also talked about zfsd, which is a + substitute for FMA. This is a Solaris technology which deals + with hot spares and device replacement, etc. So zfsd + is a replacement for this tool on &os;, implemented by Spectra + Logic. With regard to this, we discussed some of the issues + about getting it into the main tree, as they had done some + subtle physical pathing that was not hundred percent + generic.

+ + + + + Security + + + + + Dag-Erling + Smørgrav + + des@FreeBSD.org + + + + + Summary + Notes + + + +

In the security working group, we had four items in the agenda. + First of all, we started with the current state of + /dev/random. There were a number of known entropy + harvesting bugs that have been fixed, for example feeding a lot + zeroes from the network stack. We have a pluggable random + generator framework and we have a number of plugins for it, + Yarrow is one, and the RDRAND, Padlock are two others, we have + one that blocks and one that panics, and few coding examples and + so on. For 10, we are going to backtrack and remove RDRAND and + Padlock backends and feed them into Yarrow instead of delivering + their output directly to /dev/random. It will still be + possible to access hardware random number generators, that is, + RDRAND, Padlock etc, directly by inline assembly or by using + OpenSSL from userland, if required, but we cannot trust them any + more. In addition to this, we want to collect more entropy + early in the boot process, because we want to get rid of the + initrandom script that feeds mostly static data into + /dev/random and pretends that is actually entropy, + while it is not. Pawel Jakub Dawidek has a patch which has been + floating around and doing some analysis on this, we finally got + some numbers for it. This patch feeds the amount of time it + takes to attach a device into /dev/random and it turns + out that one can get about 4 good bits of entropy from each + device. Also, we should have the installer to fill up the + /entropy file on the newly installed system, so we have + something when the system starts up for the first time. And + there is also the matter of (especially with virtualization and + cloning, which is becoming more and more common) ensuring that + the clones diverge quickly enough. As example, we discussed + having the installer generate SSH keys. But problem is that if + you install a VM and it generates the SSH keys, and then it is + cloned, all the instances will have the same keys. So when the + individual VMs are started and they do not have enough entropy + harvesting early in the boot process, then keys are generated + based on the entropy that the installer has dumped during the + installation process, which is as almost as bad.t The device + attach patch helps with that.

+ +

The next item was package signing. We have a short-term + solution for 10 until a more professional one is developed. In + this design, the package builders do not have the keys, instead + they submit hashes to a signing server after they are done, and + the signing server returns the signature. We are simply going + to ship the fingerprints with the base system under + /etc/pkg/fingerprints. If we need to revoke a key, or + distribute a new key, we will just issue a new &os; Security + Advisory (which should be done anyway), and will have + freebsd-update(8) to distribute an update that moves + the key from the trusted directory to the + revoked directory, and adds the new key to the + trusted directory. When launched, pkg(8) + looks into those directories, loads all the keys it founds, and + will accept a packages if it is signed by at least one good key + and no revoked keys.

+ +

Package signing was followed by mitigation by Sofian Brabez. + He has stackgap optimization and mmap() randomization + ready to be included in 10, but turned off by default. Stackgap + randomization adds a random amount of empty space at the top of + the stack, so that an attacker cannot just make assumptions + about the actual stack layout of the applications in case of + buffer overflows. The problem with stackgap randomization is + programs like Varnish that have many threads and therefore very + small stacks in order to avoid running out of stack space, will + run out of stack space. This is because stackgap randomization + will increase the size of the stacks. mmap() + randomization inserts a random gap between consecutive mappings + for the same purpose. Stack protection (SSP) can now be enabled + by default. The problem is if it is turned on by default, a lot + of ports will break. It is because GCC includes an additional + object file during linking for checking the canary words, and + this apparently interferences the way of how some ports build. + libc is now a linker script and not just a .so + file, therefore the linker will always know how to handle this. + ldbase randomization was also discussed, but it has not + been implemented. It randomizes where the libraries are loaded + by the run-time linker.

+ +

The final item on the agenda was VuXML and portaudit. We + have a number of shortcomings with VuXML. One of them is that the + portaudit tool is based on string matching which is + unreliable, especially when we have ports that are renamed and + multiple ports, different versions of the same software. In addition, + there are many errors in the actual data, especially a very + common error is to have > instead of >=. + Also, the auditing tools do not verify the base system version. + We have VuXML entries for Security Advisories but they are + unused because of this. One of the reasons for that, the kernel + patch level does not necessarily reflect the patch level of the + userland, because freebsd-update(8) does not update the + kernel patch level unless the actual update affects the kernel. So, + we are going to start including CPE information in ports. That is the + Common Platform Enumeration, and that is a NIST standard for uniquely + identifying software packages, versions, variances, even port + revisions. The point of using CPEs is that it is unique, not + tied to the name of the port so we can have multiple ports with + the same CPE without any trouble. We will store it as + annotations for pkg(8) packages. CPEs published by + NIST can be simply pushed directly to VuXML and we do not have + to the matching ourselves any more. The specification of CPE + includes a matching algorithm and shipped with a reference + implementation. &os; 10 is going to install a script under + /libexec that prints the userland patch level, and + freebsd-update(8) will update that script so it will be + possible to verify the userland patch level as well.

+ + + + + Embedded Platforms + + + + + Warner + Losh + + imp@FreeBSD.org + + + + + Brooks + Davis + + brooks@FreeBSD.org + + + + + Summary + Notes + Cambridge notes + + + +

The discussion on embedded platforms has started in Cambridge a + month earlier, where it was kicked off with a presentation by + BrilliantService on their Viking operating system for a head + mount augmented reality display. We then had a discussion of + board bringup and the related topic of kernel minimization. + This was followed by a long discussion of system image creation + and what is required to promote some embedded platforms to + Tier-1 status. Finally, we discussed power management.

+ +

The discussion of Tier-1 status for embedded platforms, + particularly Raspberry-Pi identified a number of things required + to make this possible. In addition to some driver improvements + and stabalization efforts, we need to build images as part of, + or derived from the products of the current release build + process. We also need to be building packages (sson is working + on making this happen for ARM and MIPS64). We will also need + some form of binary updates. Initially this will probably be + done via freebsd-update(8) but in the long term this + will likely be too slow to be practical. Further discussion of + this topic was a major thread at the EuroBSDCon developer + summit.

+ +

The power management discussion was wide ranging and concluded + that we do need better power management infrastructure and that we + are not entirely sure what that looks like. We certainly do + need some way to represent the power management bus/device trees + that differ from the conventional models of attachment in our + device infrastructure. We also need smarter scheduling to allow + us to do things like steer all interrupts away from certain + cores so they can be shut all the way down.

+ +

In Malta, the first thing we talked about was trying to get + better goals, use cases for the external toolchain support so that + we have the work done by &os; 11, where any architecture + that supports can be built by using external toolchains. We + talked about different ways for an architecture that does not + have support for a native toolchain to work in the QEMU-based + package building infrastructure. By &os; 11, we also want + to make sure that it was all well-documented so that users will + know what is and what is not supported on the given + platform.

+ +

Next, we had a long discussion about the auto tuning changes + that Alfred Perlstein did recently. They are great for machines + with a gigabyte or more memory, but they are bad for machines + that almost have no memory, so Adrian Chadd has volunteered to + fix this (see the slides for more details).

+ +

We talked a lot about what to do around the ARM port in + &os; 11, and we have set some goals for 11 in this area. + Some of the highlights are as follows. We want to have the + ability to boot one kernel on any armv6 platform + — currently there is a number technical roadblocks to + that. We want to keep the armv4 and armv5 + support in 11 until there is some particular reason not do that. + One of the biggest tasks probably, since we are moving to Clang, + would be the external toolchain item. Besides that, the + armv6 will grow hardware floating-point support, we are + hoping to have Symmetric Multi-Processing (SMP). And we talked + rather extensively about some of the release engineering tasks + we will have to do: we need to have images for popular boards, + such as Raspberri Pi and BeagleBoard. We would like to have + some work done in this area in the 10.1 timeframe. We want to + get packages spun up for ARM and MIPS, as well as setting the + infrastructure up for freebsd-update(8). It was also + briefly mentioned that there is no good GPU support on ARM right + now, and that is on the &os; side. We need a strategy that has + the least disadvantages, which might be adopting the Android ABI + and let the Android blobs to be dropped in — there is a + number of challenges in this case.

+ +

In addition to that, we talked about MIPS and various FDT + issues. The key problems for the latter were that we need + better clock and power support and there are separate + domains from the device tree, and they need to be + threated as such. Also, GPIO and pinmux is inconsistent between + the different releases, we need to fix that. We also talked + about Arm64, where there is lot of things to do. The key though + is find out (with the assistance of the &os; Foundation) who is + interested in Arm64 among the vendors and how to collaborate + with them. Since the Foundation has the contacts and the + related NDAs to the largest consumers, probably they are in the + best position to drive this effort. We have concluded, together + with the Semihalf people and the ARM representative, Andrew + Wafaa, at the summit, after investigating Arm64, that it is not + far away from the things we have now support for in the kernel. + It turned out that it is mostly about how we organize the source + tree and similar minor issues.

+ + + + + Ports and Packages + + + + + Erwin + Lansing + + erwin@FreeBSD.org + + + + + Summary + Notes + + + +

We had one full presentation by Allan Jude, a quick overview of + what they did for the PC-BSD CDN (Content Delivery Network). + For example, it uses the --delay-update flag for + rsync(1) to make it more atomic, uses a lot of ZFS + functions (e.g. replication, snapshot management) and + implements automatic mirror selection. It was a quite + interesting talk, and featured few interesting ideas that we + could pick and use for the &os; package distribution network. + This was then followed by a talk by Jeremy Le Hen, who talked + about stack protection (SSP). It is going to be enabled by + default in &os; 10.x on amd64 and i386 platforms, but can + be turned off by the SSP_UNSAFE knob. On the contrary, + it is not enabled by default on 9.x, but it can be turned on by + the other knob, WITH_SSP_PORT. This should work on + amd64, and it has no effect on i386.

+ +

Baptiste Daroussin talked about staged installs which was + committed recently. Every other package system does that, now we + do it as well. It brings a lot of improvements, such as we can + catch packaging list errors earlier, before the package is + actually installed on the file system. There the + NEED_ROOT knob can be used if a port requires root + privileges for building and packaging. It also simplifies most + of the logic employed at the build farms, because many of the + checks can be automated this way, catches broken plists, helps + to get rid of the special post-install scripts. It + lies the foundation for some new features we want to add in the + future, for example implementing sub-packages. Having + sub-packages enables to build packages once and put files into + separate smaller packages which can be then installed + individually. Compared to all the other options, it is turned + off by default, and ports are slowly converted to this format + one by one — however, at some point, we might say that + ports not converted to support staging will be removed. + Actually, this would help us to find out which ports in the tree + are not used any more.

+ +

Then there was a discussion about what to do next. We have + been talking about package sets for at least three years now, it + seems we are finally able to do it. We are going to try to do a + security branch, together with reviving the ports security team, + in cooperation with the Security Officer, Dag-Erling Smørgrav. + We are aiming for quarterly releases and weekly security updates + for those releases in the security branch. This has been an + ongoing plan for three years, because we needed to have many + things to happen before we could proceed, such as move away from + CVS, introduce new-style binary packages, deploy new build + clusters. We have finally got them all, and we can actually do + it now with the pkg-test setup. So, we are hoping to + start with the first quarterly release in early November.

+ +

We had a long discussion about removing support for old-style binary + packages, now we have pkg(8). Staying compatible with + pkg_install(1) hinders the introduction of new features, e.g. + sub-packages mentioned above. We cannot really add those new features + as the old tools will not support them and we cannot expect ports to + work with two different package formats at the same time. We + do not want to surprise our users too much, but it turns out there is + an easy migration path. Among many others, an advantage of + pkg(8) that it can interoperate with various + third-party applications, e.g. puppet and chef. It is still a POLA + violation, so we should be careful of how the actual transition is + made. We should give a lot of warning to the users, specially in case + of large installations, where there are custom scripts to work with + ports and packages. The date for throwing the switch has been + set for six months, that is, April 2014, which fits nicely with + the End-of-Life date of 8.3-RELEASE, the last release that does + not include pkg(8). So, at BSDCan next year, we can + hopefully celebrate the switch from pkg_install(1).

+ +

Finally, we discussed issues related to package naming. The + problem is that certain ports have the same name and they rely + on this, so currently we have LATEST_LINK to work this + behavior around. We should educate people to make better use of + PKGNAMESUFFIX to make sure that all affected ports have + a unique name. To encourage this, we should set up automated + checking to warn people about having packages of the same name. + PKGNAME must be unique across categories, so when one + uses pkg-add(8), the system has to know which package + to choose for install. This will improve things for better + handling of options, adding package flavors and implementing + sub-packages.

+ + + + + DNS + + + + + Erwin + Lansing + + erwin@FreeBSD.org + + + + + Summary + + + +

&os; 10 is not going to have BIND any more, it is going to + be based on unbound(8) and LDNS, both have been + imported into the base system, along with a small + host(1) replacement. LDNS also comes with + drill(1) that needs a simple wrapper to make it + compatible with the dig(1) command-line interface. + OpenSSH can use LDNS for checking SSH fingerprints which also + implies that DNSSEC validation is enabled by default. Note that + unbound(8) will be hidden, it will be a local resolver + only. For other purposes, one shall have to install its version + in the Ports Collection instead.

+ +

For the next major version, &os; 11, there will be more + time to find an alternative to BIND, so it was also discussed in + the working group what the requirements would be for an ideal + DNS implementation. Based on the results, what we want is a + caching, validating resolver library, which is compartmentalized + by Capsicum, supports per-user policies and integration with the + Casper daemon, BSD-licensed, has a low footprint, fast, and + thread-safe. But the most important factor here is that we want + to standardize the API towards application level, so we can + actually report back to the user on what happens in relation + with DNSSEC operations, in an informative way. There has been + many proposals for that, like the get-api from Hoffman, or + draft-hayatnagarkar-dns-ext-validator-api for libval, + but it is currently being standardized by members of IETF. What + we want to do is to contact those people and make sure that + &os; 11 will become a standard reference + implementation.

+ + + + + Vendor Discussions + + + + + Erwin + Lansing + + erwin@FreeBSD.org + + + + + Summary + + + +

First, Justin Gibbs, on behalf of the &os; Foundation, gave a + status update. A major change that previously we had only a + single part-time employee, who was Deb Goodkin, now we have a + two full-time technical staff members involved in some of the + current projects, such as Kostik Belousov who is still working + on improving our X.org support. They are also helping out with + improving continuity within different teams, e.g. the Release + Engineering Team and the Security Team. We also employed Glen + Barber as a system administrator who is working with the &os; + cluster administrators to supervise the Project's machines, and + he is also helping out with release engineering. Ed Maste has + been employed part-time as a project manager to oversee the + progress of the Foundation-sponsored projects. But we are + hoping to get more people involved, especially on the sides of + administration and marketing.

+ +

We had a presentation by Daichi Goto about his company in + Japan, called BSD Consulting, Inc. He consulted for a company + where he wanted to solve problems using &os; but the company did + not allow him to do that as they could not get a commercial + support for &os;, so he started his own company solely for this + purpose, which for example, includes hardware certification.

+ +

There was a discussion revolving around that current status of + our documentation and web site, especially in Japan, where most + of the people do not speak English very well. In the rest of + the time we had a long but fruitful discussion about smaller + projects, for example incorporating more bug fixes related to + Infiniband into releases. In general, it would be useful to + backport not only security fixes but major fixes and release + backported erratas for the releases. Then we talked about the + nanobsd support, making it more visible and accessible to the + potential users. Next, we talked about promoting ARM and MIPS + platforms to Tier-1, providing more translated documents and + testimonials, documentation to attract news users for &os; and + reach out for them: how to write problem reports, debug the + kernel, etc. In connection to that, PR triage was also + mentioned, where the goal is to provide an answer for every + incoming bug report in a couple of days. As usual, Java was + also on the menu, where it seems they are swinging back to + OpenJDK being the default in 1.8.

+ + + + + USB + + + + + Hans-Petter + Selasky + + hselasky@FreeBSD.org + + + + + Summary + Notes + + + +

In the USB working group, Hans-Petter Selasky summarized what + happened to &os;'s USB stack during the last one year. He + mentioned that there were no serious issues, while the USB + driver support improved on both device and controller fronts. + He also noted that many systems have started to use the USB + stack itself outside the &os; kernel, for example DragonFly BSD. + Hans-Petter briefly walked through the list of ideas on how to + improve USB support further: he wants to import more Linux USB + serial port and Ethernet device drivers into userspace, which + can be then accessed through his webcamd(8) daemon, + move the NDIS (Ethernet and wireless) USB wrapper to userspace, + and implement emulation of the Linux USB file system at + character device level via the Cuse4BSD-based daemon, also in + userspace.

+ +

The summary was followed by the discussion of how to fix the + detach issues experienced in case of USB wireless and Ethernet + devices, initiated by Adrian Chadd. In addition to that, some + DWC OTG were discussed, such as the need for implementing DMA + support and expose it to more testing for all device speeds, not + only for Ethernet and memory sticks.

+ + + + + Developer Summit Track + + + + + Gábor + Páli + + pgj@FreeBSD.org + + + + + Playlist of the talks + + + +

Since 2011, the &os; Developer Summit Track has become an + essential part of BSDCan and EuroBSDcon conferences. It + provides the developers and community members an opportunity to + tell about their latest projects, brainstorm on solutions to a + hard problem, train attendees to use a new tool, make + observations about a &os; development process and how to improve + it, talk about how their company uses &os;, or coordinate + activities. One can also catch reports from the Google Summer + of Code students at the European instances.

+ +

At EuroBSDcon 2013 we had talks in the following topics: + superpages for ARM, an SDIO stack, porting GlusterFS, unattended + encrypted kernel crash dumps, adding Capsicum support for + compression services, an intelligent download management + service, LLDB, improvements in packet forwarding, multipath TCP + support, a &os;-based network simulation environment, finally + porting Mirage, an operating system written in the OCaml + functional language, to &os;. The playlist of the talk + recordings (audio with slides and demonstrations) can be found + above at the entry's URL section.

+ + +