Introduction
This quarter's FreeBSD developments continue to provide excitement and promise for further developments. I myself have a soft spot for manual pages, so it is especially good to see that we have gained some documentation for writing them (and I hope that this will translate to more and improved manual pages in the future!). The core@ entry is also of particular note, with the introduction of the FCP process and the recognition of the first non-committer FreeBSD Project Member (and more). Read on to find out more about these, as well as improved support for the AMD Zen family of processors (e.g., Ryzen), and a whole lot more!
—Benjamin Kaduk
The deadline for submissions covering the period from October to December 2017 is January 14, 2017.
FreeBSD Team Reports
Projects
Kernel
Architectures
Userland Programs
Ports
Documentation
Third-Party Projects
FreeBSD Team Reports
Entries from the various official and semi-official teams, as found in the Administration Page.
FreeBSD Release Engineering Team
Contact: FreeBSD�Release Engineering Team <[email protected]>
The FreeBSD Release Engineering Team is responsible for setting and publishing release schedules for official project releases of FreeBSD, announcing code freezes, and maintaining the respective branches, among other things.
The FreeBSD Release Engineering Team continued finalizing the 11.1-RELEASE cycle, with the final release builds starting on July 21 and the official release announcement email sent on July 26. Thank you to everyone who helped test 11.1-RELEASE, ensuring its quality and stability.�[1]
FreeBSD�11.1-RELEASE is the second release from the stable/11 branch.
Additionally, the FreeBSD Release Engineering Team started the 10.4-RELEASE cycle, with the code slush starting on July 28. With the final release build expected to start on September 29 and the official announcement overlapping the end of the quarter, everything is on schedule as of this writing.�[2]
FreeBSD�10.4-RELEASE will be the fifth release from the stable/10 branch, and is planned to be the final release of the 10.x series.
This project was sponsored by The FreeBSD Foundation�[1].
This project was sponsored in part by The FreeBSD Foundation�[2].
Ports Collection
Contact:
Ren�
Ladan
<[email protected]>
Contact: FreeBSD Ports Management Team <[email protected]>
The Ports Collection now features over 31,600 ports. There are currently 2671 problem reports, of which 718 are unassigned. This quarter saw almost 5,900 commits from 175 committers. The number of open PRs grew compared to last quarter, and outpaced the number of changes.
This quarter, we welcomed Zach Leslie (zleslie@), Luca Pizzamiglio (pizzamig@), Craig Leres (leres@), Adriaan de Groot (adridg@), and Dave Cottlehuber (dch@) as new committers. The commit bits of the following committers were taken in for safekeeping: alonso@ after 19 months of inactivity, rpaulo@ per his request, and ache@ after he passed away. Despite several tries and changing mentors, kami@ lacked interest in completing his mentorship, so his commit bit was also taken in for safekeeping.
On the infrastructure side, two USES values were removed because they outlived their usefulness:
- execinfo: libexecinfo is now available in the base system of all supported FreeBSD versions
- twisted: there is only one Twisted port left
The default version of GCC was bumped from 5 to 6. Firefox was updated to version 56.0 and Chromium to version 61.0.3163.100. The version of pkg itself was updated to 1.10.1.
During this quarter, antoine@ performed 28 exp-runs to test version updates of major ports, improving USE_GITHUB and SHEBANG_FILES, and API changes to the base system. This quarter, the foundation for ports "flavors" was committed, though more development and testing will be performed in the coming quarter before it goes live.
Open tasks:
- The PR load needs more attention, as the number of open PRs has started to increase again.
The FreeBSD Core Team
Contact: FreeBSD Core Team <[email protected]>
The new "FreeBSD Community Process" was drafted during BSDCan earlier this year. The first such document, FCP 0, defines how the whole process works. After some time for discussion and revision, FCP 0 was voted on and accepted by core, following the procedure laid down within that document. Currently the use of FCPs is entirely optional; we shall see how the community begins to adopt their usage and evolve the process based on experience.
A draft update to the Code of Conduct has been prepared by the advisory committee. Core is currently reviewing the text, and will soon vote on accepting it. Core is keen to avoid the trap of "rules lawyering". At the moment, the feeling is that we need to add a preamble to the CoC to articulate the goals of the project and to act as a general guide to the exercise of the code.
This quarter has been quite a busy one concerning changes to the roster of committers and project members. We have elected our first new Project Member: John Hixson, who will be familiar from many conferences where he has given presentations and ably represented iXsystems. A second proposed Project Member was not accepted by core, but only because core felt that Fedor Uporov really deserved a commit bit instead.
In addition to Fedor Uporov, please also welcome (in no particular order) Matt Joras, Marcin Wojtas, Chuck Tuffli, Ilya Bakulin and Alex Richardson as brand-new committers. We have also awarded Steven Hurd and Eugene Grosbein src commit bits to go with their existing ports bits. Welcome back Gordon Tetlow as a src committer, essential for his new role within secteam. Eric Davis and Rui Paulo have both decided to hang up their commit bits: we wish them well in their future endeavours. Finally, we must report the sad death of Andrey Chernov, who will be sorely missed by his colleagues and collaborators.
Andrey's death has highlighted another question which is only going to become more complex over time. Keeping track of copyrights is already hard enough within a mature source tree with many contributors, such as the FreeBSD sources. Now we need to consider trying to keep track of the heirs and beneficiaries of contributors who have sadly passed away. Core will consult with the Foundation legal team to discuss possible approaches to alleviate this.
There have been complaints that the workings of Core are being kept overly confidential, and that consequently the majority of the project has too little idea of what is going on. This is certainly not intentional by Core, and we are keen to open up Core's business to more general community scrutiny as far as seems reasonable.
Core dealt with a number of licensing questions:
- When upstreaming patches and other original works to VirtualBox or other Oracle properties, pragmatically it works best to provide them under the terms of the MIT license (one of two opensource licenses accepted by Oracle). Of course, this only applies to work upstreamed by or with the permission of the original author.
- The Viking software license is sufficiently BSD-like that magic constants from their drivers can be used in FreeBSD code.
- There is no separate register of deviations from the allowed BSD-like licenses in the source tree: any code in the tree under other than BSD-like license terms can be assumed to have been approved by core.
- At the moment the FreeBSD copyright requirement to include the copyright notice in redistributions in binary form is satisfied by making the FreeBSD sources, with all of the detailed copyright information included in the different source code files, available alongside pre-compiled system images. However, this does not necessarily meet the needs of downstream projects based on FreeBSD, and given the new "packaged base", adding per-package licensing metadata in a way similar to how the Ports Collection works is under consideration as an alternative mechanism.
Concerns were raised regarding the pending HardenedBSD entry in the previous quarterly report prior to publication. The FreeBSD project welcomes reports from separate (but derived) projects in quarterly reports and has included similar reports in the past from other projects (such as TrueOS and pfSense). The HardenedBSD report was edited for length and to concentrate on activities during the quarter in question.
Amazon is proposing to set up mirrors of the freebsd-update and pkg servers within AWS in order to provide faster access for EC2 users. These mirrors will be publicly accessible, but the expectation is that use will primarily be from within EC2. FreeBSD AMIs will have a preset configuration that references the Amazon servers.
The old, long-deprecated, and insecure "r-commands" (rsh, rlogin, rcp) are being removed from the base system for 12.0-RELEASE. Notice of this was added to the man pages and release notes in time for 11.1-RELEASE and 10.4-RELEASE. Anyone requiring these commands for backwards compatibility can use the new net/bsdrcmds port.
Work to replace Heimdal Kerberos in base with the more widely compatible MIT Kerberos has begun in a new projects/krb5 branch. This should not fall afoul of any US cryptography export regulations: the project is required to notify the US government that cryptographic software can be downloaded from FreeBSD servers, and this already covers MIT Kerberos, already available within ports.
A number of Bay Area FreeBSD User Group-related domain names are being given up by their original owner. The current BAFUG organisers have been made aware.
Core has voted on a change to the Doceng voting rules to provide for a "did not vote" status during doceng voting similar to how portmgr and core voting operates. The current requirement for all five members of doceng to register a vote on issues was proving to be a significant bottleneck.
The FreeBSD Foundation
Contact: Deb Goodkin <[email protected]>
The FreeBSD Foundation is a 501(c)(3) non-profit organization dedicated to supporting and promoting the FreeBSD Project and community worldwide. Funding comes from individual and corporate donations and is used to fund and manage software development projects, conferences and developer summits, and provide travel grants to FreeBSD contributors. The Foundation purchases and supports hardware to improve and maintain FreeBSD infrastructure and provides full-time Release Engineering support; publishes marketing material to promote, educate, and advocate for the FreeBSD Project; facilitates collaboration between commercial vendors and FreeBSD developers; and finally, represents the FreeBSD Project in executing contracts, license agreements, and other legal arrangements that require a recognized legal entity.
Here are some highlights of what we did to help FreeBSD last quarter:
Fundraising Efforts
Our work is 100% funded by your donations. This year we have raised over $860,000 from over 500 donors. Our 2017 fundraising goal is $1,250,00 and we are continuing to work hard to meet and exceed this goal! Please consider making a donation to help us continue and increase our support for FreeBSD: https://www.FreeBSDfoundation.org/donate/.
We also have a new Partnership Program, to provide more benefits for our larger commercial donors. Find out more information at https://www.FreeBSDfoundation.org/FreeBSD-foundation-partnership-program/ and share with your companies!
OS Improvements
The Foundation improves the FreeBSD operating system by employing our technical staff to maintain and improve critical kernel subsystems, add features and functionality, and fix problems. This also includes funding separate project grants like the arm64 port, blacklistd access control daemon, and the integration of VIMAGE support, to make sure that FreeBSD remains a viable solution for research, education, computing, products and more.
We kicked off or continued the following projects last quarter:
- OpenZFS RAID-Z Expansion project
- Broadcom Wi-Fi infrastructural improvements (bhnd(4) driver)
- Headless mode out-of-the-box for the Beaglebone Black
- Extending bhyve/ARMv7 features
- Porting bhyve/ARM to an ARMv8 platform
Having software developers on staff has allowed us to jump in and work directly on projects to improve FreeBSD like:
- ZFS improvements
- New Intel server support
- kqueue(2) updates
- 64-bit inode support
- Stack guard
- Kernel Undefined Behavior Sanitizer
- Toolchain projects
- i915 driver investigation
- NVDIMM support in acpiconf(8)
- Continuous integration dashboard (web page and physical hardware)
- FAT filesystem support in makefs(8)
Staff and board members continued hosting bi-weekly conference calls to facilitate efforts for individuals to collaborate on different technologies.
Release Engineering
The Foundation provides a full-time staff member to lead the release engineering efforts. This has provided timely and reliable releases over the last few years.
Last quarter, our full-time staff member worked with the FreeBSD Release Engineering and Security Teams to finalize 11.1-RELEASE. He also supported the 10.4 release effort, and has continued producing 10-STABLE, 11-STABLE, and 12-CURRENT development snapshot builds throughout the quarter. At the vBSDCon Developer Summit, he gave a presentation on the state of the release engineering team.
You can find out more about the support we provided to the Release Engineering Team by reading their status update in this report.
Supporting FreeBSD Infrastructure
The Foundation provides hardware and support to improve the FreeBSD infrastructure. Last quarter, we continued supporting FreeBSD hardware located around the world.
FreeBSD Advocacy and Education
A large part of our efforts are dedicated to advocating for the Project. This includes promoting work being done by others with FreeBSD; producing advocacy literature to teach people about FreeBSD and help make the path to starting using FreeBSD or contributing to the Project easier; and attending and getting other FreeBSD contributors to volunteer to run FreeBSD events, staff FreeBSD tables, and give FreeBSD presentations.
The FreeBSD Foundation sponsors many conferences, events, and summits around the globe. These events can be BSD-related, open source, or technology events geared towards underrepresented groups. We support the FreeBSD-focused events to help provide a venue for sharing knowledge, to work together on projects, and to facilitate collaboration between developers and commercial users. This all helps provide a healthy ecosystem. We support the non-FreeBSD events to promote and raise awareness of FreeBSD, to increase the use of FreeBSD in different applications, and to recruit more contributors to the Project.
Here is a list highlighting some of the advocacy and education work we did last quarter:
- Organized and ran the Essen FreeBSD Hackathon in Essen Germany
- Sponsored and participated in the FreeBSD Developer Summit BSDCam, in Cambridge, England
- Represented FreeBSD at the ARM Partner Meeting
- Presented and taught about FreeBSD at SdNOG 4 in Khartoum, Sudan
- Sponsored and gave presentations and tutorials at EuroBSDCon in Paris, France
- Organized and ran the Paris FreeBSD Developer Summit
- Organized and ran the FreeBSD Developer Summit at vBSDCon
- Sponsored and attended vBSDCon
- Proved travel grants to FreeBSD contributors to attend the above events.
- Sponsored the 2017 USENIX Security Symposium in Vancouver BC as an Industry Partner
- Provided FreeBSD advocacy material
- Sponsored the 2017 USENIX Annual Technical Conference in Santa Clara, CA as an Industry Partner
We continued producing FreeBSD advocacy material to help people promote FreeBSD around the world.
We help educate the world about FreeBSD by publishing the professionally produced FreeBSD Journal. Last quarter we published the July/August issue that you can find at https://www.FreeBSDfoundation.org/journal/.
You can find out more about events we attended and upcoming events at https://www.FreeBSDfoundation.org/news-and-events/.
Legal/FreeBSD IP
The Foundation owns the FreeBSD trademarks, and it is our responsibility to protect them. We also provide legal support for the core team to investigate questions that arise.
Go to http://www.FreeBSDfoundation.org to find out how we support FreeBSD and how we can help you!
Projects
Projects that span multiple categories, from the kernel and userspace to the Ports Collection or external projects.
FreeBSD CI
Contact: Jenkins Admins <[email protected]>
The FreeBSD CI team runs various continuous integration solutions for FreeBSD, regularly checking that the current state of the Subversion repository can successfully build, and performing various tests and analysis upon the build results.
We have introduced a DTrace test pipeline, with the results and artifacts available at:
- https://ci.FreeBSD.org/job/FreeBSD-head-amd64-dtrace_test/
- https://artifact.ci.FreeBSD.org/dtrace-test/
We had team meetings at two developer summits during Q3:
Open tasks:
- Fix the failing test cases and builds.
- Create builds for additional architectures.
- Add more tests.
- The additional TODO items listed at https://wiki.FreeBSD.org/Jenkins/TODO.
Kernel
Updates to kernel subsystems/features, driver support, filesystems, and more.
Intel 10G iflib Driver Update
| Links | |
| ixgbe iflib Conversion | URL: https://reviews.FreeBSD.org/D11727 |
Contact:
Chris
Galazka
<[email protected]>
Contact:
Piotr
Pietruszewski
<[email protected]>
The ix and ixv network interface drivers support a variety of Intel network interfaces, with line speeds at 10 Gbit/second.
This quarter, with the help of Matt Macy and Sean Bruno (among others), we have submitted a review in Phabricator for the conversion of the ixgbe driver to use the new (and evolving) iflib framework.
Stay tuned for the conversion of the 40G driver (ixl), as it is currently being ported to use iflib.
Open tasks:
- Additional testing.
Intel iWARP Support
| Links | |
| iWARP for ixl | URL: https://reviews.FreeBSD.org/D11378 |
Contact: Bartosz Sobczak <[email protected]>
iWARP is a protocol suite that enables efficient movement of data across the network, building on Remote Direct Memory Access, Direct Data Placement, and Marker PDU Aligned Framing. It endeavors to avoid unnecessary (local) data copies and to offload work from the main CPU to dedicated hardware.
An initial commit adding iWARP support for the Intel X722 family of network adapters is under review. This is an important step towards introducing full iWARP support on systems equipped with Intel C620 Series Chipsets. Currently, with the iw_ixl driver, only the kVerbs API is supported.
Open tasks:
- Additional testing.
pNFS Server Plan B
| Links | |
| Instructions for Testing | URL: http://people.FreeBSD.org/~rmacklem/pnfs-planb-setup.txt |
Contact: Rick Macklem <[email protected]>
A pNFS server allows an NFS service to be spread over multiple servers, separating the MetaData operations from the Data operations (Read and Write). This project will add the ability to use FreeBSD systems to create a pNFS service consisting of a single MetaData Server plus a set of Data Servers. The Data Servers can be mirrored, so that redundant copies of the file data are maintained.
The support for non-mirrored Data Servers is now believed to be complete. Support for mirrored Data Servers using the Flexible File Layout, which will soon be published as an RFC, is implemented. However, there is still significant work to be done, since the current implementation of mirrored Data Servers does not handle failed Data Servers or their resilvering/recovery. It is hoped that support for failure/recovery of Data Servers will be implemented in the next six months.
The patched FreeBSD sources may now be accessed for testing via either Subversion or downloading a gzipped tarball. They consist of a patched kernel and nfsd and can be used on any FreeBSD 11 or later system. The installation procedure is covered in the linked document.
Open tasks:
- Testing by others will be needed, now that the implementation is available.
- Implementation and testing of mirror failure/recovery.
Architectures
Updating platform-specific features and bringing in support for new hardware platforms.
AMD Zen (family 17h) support
Contact: Conrad Meyer [email protected] <>
This quarter, a bit of work was done to enhance platform support for AMD Zen (Ryzen, Threadripper, Epyc) processors:
- The CPU topology detection code was enhanced to properly detect Zen dies and CPU Complexes. This gives the scheduler more locality information to use when making scheduling decisions.
- The x86 topology analysis was enhanced to report dies and CPU Complexes, in addition to the existing reporting on packages, cores, and threads. An example of the new output is FreeBSD/SMP: 1 package(s) x 2 groups x 2 cache groups x 4 core(s) x 2 hardware threads.
- The amdsmn(4) driver for accessing SMN (System Management Network) registers was added.
- CPU temperature monitoring support for Zen was added to amdtemp(4).
- In cpufreq(4):
- Added support for decoding Zen P-state information from Machine State Registers (which is usually not necessary, since it is largely redundant with ACPI P-state information, but is potentially useful)
- Work around the apparent Ryzen inability to achieve the P1 state by not busying cores waiting to transition to it
- The intpm(4) smbus driver was fixed to attach to the AMD FCH (Fusion Controller Hub).
- All MCA banks are now enabled and monitored on Zen CPUs.
- Feature-bit decoding was added for: CLZERO, SVM features, and RAS capabilities.
- SHA intrinsic support was added to the aesni(4) driver. Ryzen is currently the only desktop processor to feature these intrinsics. Support for these intrinsics is also present in Intel's Goldmont line of low-end SoCs.
Overall, Zen is now a very usable platform for x86 workstations and servers.
This project was sponsored by Dell EMC Isilon.
Open tasks:
- Add HWPMC support for the new performance counters avilable on the Zen architecture.
- Add support for the CCP (Crypto Co-Processor).
Userland Programs
Changes affecting the base system and programs in it.
Updates to GDB
Contact:
John
Baldwin
<[email protected]>
Contact:
Luca
Pizzamiglio
<[email protected]>
The devel/gdb port has been updated to GDB 8.0.1.
Support for FreeBSD/aarch64 userland binaries has been committed upstream. These patches, along with support for debugging FreeBSD/aarch64 kernels, have been committed to the port.
Upstream patches adding improved support for FreeBSD/arm userland binaries are currently in review. FreeBSD 12 has recently grown support for debugging VFP registers via ptrace() and core dumps as part of this work. Support for FreeBSD/arm kernels will be added to the port after the upstream patches are added to the port.
Support for $_siginfo has been committed upstream. This uses the recently added NT_LWPINFO note to extract signal information from process cores.
Hangs that occured when GDB's kill command was used were fixed in FreeBSD in r313992.
Open tasks:
- Figure out why the powerpc kgdb targets are not able to unwind the stack past the initial frame.
- Test support for sparc64 binaries and kernels.
- Add support for debugging powerpc vector registers.
- Implement info proc commands.
- Implement info os commands.
Ports
Changes affecting the Ports Collection, whether sweeping changes that touch most of the tree, or individual ports themselves.
FreeBSDDesktop
| Links | |
| FreeBSDDesktop on GitHub | URL: https://github.com/FreeBSDDesktop/ |
Contact:
Johannes
Dieterich
<[email protected]>
Contact:
Mark
Johnston
<[email protected]>
Contact:
Hans Petter
Selasky
<[email protected]>
Contact:
Matthew
Macy
<[email protected]>
The FreeBSDDesktop team is happy to announce the availability of graphics/drm-next-kmod. This port for FreeBSD-CURRENT (amd64) provides support for the amdgpu, i915, and radeon DRM modules using the linuxkpi compatibility framework. The port currently corresponds to the DRM from Linux 4.9 and is in an experimental state. It works reliably for many testers with modern GPU hardware (AMD HD7000 series/Tahiti to Polaris and Intel HD3000/Sandy Bridge to Skylake). Broader testing and reporting/fixing of bugs is appreciated.
Open tasks:
- Resolve issues that cause radeonkms and amdgpu to fail with EFI boot (though there is a workaround available).
- Upgrade to Linux 4.10 and higher DRM versions.
- Get feedback from broader testing.
OpenJFX 8
Contact: Tobias Kortkamp <[email protected]>
OpenJFX is an open source, next generation, client application platform for desktop and embedded systems, based on JavaSE. This quarter, the OpenJFX port was reworked and has received some significant improvements.
More modules are being built. With the new web module we gain support for applications that have their own builtin web browser such as AsciidocFX. The new media module allows JavaFX applications to play audio and video files.
A port of the JavaFX scenebuilder, a RAD tool for building JavaFX scenes, was added to the ports tree.
The OpenGL Prism backend for GPU acceleration was enabled by default.
From a mainainer's and contributor's perspective, the port was simplified by moving all FreeBSD-local patches to the ports tree and fetching the upstream sources directly, instead of using a separate repository for them.
Open tasks:
- Upstream some of the patches in the Ports Collection.
Puppet
| Links | |
| Puppetlab's FreeBSD Slack Channel | URL: https://puppetcommunity.slack.com/messages/C6CK0UGB1/ |
Contact: Puppet Team <[email protected]>
This summer has seen the creation of a puppet@ team to help maintain the approximately 30 Puppet-related ports in the FreeBSD Ports Collection. These ports were previously maintained by various committers, and from time to time the distributed maintainership introduced some delays when updating a port, due to the need to wait for a maintainer's approval for a related change to a different port.
Puppet 5 is now in the ports tree (as sysutils/puppet5). The C++ version of Facter (sysutils/facter) got a lot of attention and is now a drop-in replacement for the previous Ruby version (sysutils/rubygem-facter); it is the default facts source for the Puppet 5 port.
Work continues on bringing in Puppetserver 5 to the ports tree, and on keeping all the ports up-to-date.
Open tasks:
- The pkg package provider has some minor issues (it breaks things when no repos are configured, and is not working properly from the context of the MCollective package agent).
- The databases/puppetdb[345] and sysutils/puppetserver[45] ports rely on Clojure and Java, and download compiled jar files instead of building them from source.
Documentation
Noteworthy changes in the documentation tree or new external books/documents.
Absolute FreeBSD, 3rd Edition
| Links | |
| Official Announcement | URL: https://blather.michaelwlucas.com/archives/3020 |
Contact: Michael Lucas <[email protected]>
The first draft of the third edition of Absolute FreeBSD is finished. It is 220,200 words, or roughly enough to stun a medium-sized ox. It's on target to be in print before BSDCan 2018.
Open tasks:
- Stare at the wall blankly for a few days.
- Fix all the problems pointed out by dozens of community reviewers.
- Fix all the problems pointed out by John Baldwin, tech reviewer extraordinaire.
- Editing. Copyediting. Page layout. Page editing. Re-editing. Indexing. Edits discovered by indexer.
- Pre-orders should open some time next year.
- Restrain myself from strangling people who ask when the fourth edition is coming.
Manual Pages
| Links | |
| FreeBSD Documentation Project Primer | URL: https://www.freebsd.org/doc/en_US.ISO8859-1/books/fdp-primer/ |
Contact: Warren Block <[email protected]>
Over the last year, interest has increased in manual pages, in large part due to excellent infrastructure work by Baptiste Daroussin and others, and promotion by George Neville-Neil and others. This increased interest has been both gratifying and problematic. Our man pages are underappreciated gems, but we have sadly lacked any substantial documentation on how to write new ones.
In September, I added a new chapter to the FreeBSD Documentation Project Primer describing the basics of creating a man page. It includes descriptions of the markup, section structure, recommended optional material such as examples, and sample templates for the most common types of man pages. The Resources section includes links to several external resources, including the excellent Practical UNIX Manuals: mdoc.
While this chapter is not a full tutorial, it does begin to fill in a large gap in our documentation resources and provide a starting point from which to grow.
Open tasks:
- Add more explanation and examples of markup usage.
- Expand the sample templates with additional desired standard features, like an EXAMPLES section.
- Add more sample templates.
Third-Party Projects
Many projects build upon FreeBSD or incorporate components of FreeBSD into their project. As these projects may be of interest to the broader FreeBSD community, we sometimes include brief updates submitted by these projects in our quarterly report. The FreeBSD project makes no representation as to the accuracy or veracity of any claims in these submissions.
The nosh Project
Contact: Jonathan de Boyne Pollard <[email protected]>
The nosh project is a suite of system-level utilities for initializing, running, and shutting down BSD systems; and for managing daemons, terminals, and logging. It attempts to supersede BSD init, the Mewburn rc.d system, and OpenRC as used on FreeBSD and TrueOS, drawing inspiration from Solaris SMF for named milestones, daemontools-encore for service control/status mechanisms, UCSPI, and IBM AIX for separated service and system management. It includes a range of compatibility mechanisms, including shims for familiar commands from other systems, and an automatic import mechanism that takes existing configuration data from /etc/fstab, /etc/rc.conf{,.local}, /etc/ttys, and elsewhere, applying them to its native service definitions and creating additional native services. It is portable (including to Linux) and composable, it provides a migration path from the world of systemd Linux, and it does not require new kernel APIs. It provides clean service environments, orderings and dependencies between services, parallelized startup and shutdown (including fsck), strictly size-capped and autorotated logging, the service manager as a "subreaper", and uses kevent(2) for event-driven parallelism.
Since the last status report, in December 2015, the project has seen: restructured and finer-grained packaging that has fewer conflicts with other toolsets; the addition of zsh completion files; improvements to the virtual terminal subsystem, keyboard map, mouse support, and ugen and DECSCUSR support; RFC 5424/5426 remote logging support; replacement of libkqueue and the C library's environment handling functions; several new helper commands; support for Java VM autolocation; improved socket-passing code; an extended status API and "one-shot" service support; additional pre-supplied service bundles; support for service aliases; improved handling of per-user D-Bus services; improved importing of MySQL, MariaDB, Percona, and OpenVPN services; improved configuration import support; and extensive additions to the nosh Guide.
On the recently updated roadmap you can see plans for even more documentation, continuing the work to extend the capabilities of the networking subsystem, and the scant handful of rc.d-related items remaining. There are also some ideas still in the speculative or planning phases, including work that may depend on incorporating nosh support into other software.
Open tasks:
- Improve Ansible and SaltStack integration (the maintainer of the Arch Linux nosh integration has some ideas).
- Command-line completions are still needed for bash, csh, and fish.
- Document convert-systemd-units for use by port maintainers in making packaged service bundles from systemd unit files.
- nosh could take advantage of several proposed
features for the base system:
- the boot loader signaling "emergency" and "rescue" modes of operation
- adding machine-readable status output to fsck
- adding runtime support for more clang-compilable languages in the early bootstrap stage
- adding hooks for invoking external configuration import mechanisms
News Home | Status Home