os/doc
3
0
Fork 0
Code Issues Pull requests Projects Releases Wiki Activity

Grammer and spalling foxes.

Browse source
This commit is contained in:
Warren Block 2015-01-13 01:51:36 +00:00
parent 5ed1945636
commit 585ceaf043
Notes: svn2git 2020-12-08 03:00:23 +00:00 
svn path=/head/; revision=46195
1 changed files with 105 additions and 106 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

211
en_US.ISO8859-1/htdocs/news/status/report-2014-10-2014-12.xml
View file

@ -27,7 +27,7 @@
2014.</p>
<p>The fourth quarter of 2014 included a number of significant improvements to the &os;
system, in particular in compatibility with other systems. This included
system. In particular, compatibility with other systems was enhanced. This included
significant improvements to the Linux compatibility layer, used to
run Linux binaries on &os;, and the port of WINE, used to run Windows
applications. Hypervisor support improved, with &os; gaining the ability
@ -139,7 +139,7 @@
</project>
<project cat='kern'>
<title>Process management</title>
<title>Process Management</title>
<contact>
<person>
@ -163,9 +163,9 @@
management last quarter.</p>
<!-- This needs some markup from someone with more docbook-fu than me -->
<p>The Reaper facility, to allow a process to reliably track the
running and exiting state of the whole subtree of the processes,
was added. It is intended to improve tools like timeout(1) or
<p>The Reaper facility was added, allowing a process to reliably track the
running and exiting state of the whole subtree of the processes.
It is intended to improve tools like timeout(1) or
poudriere, by making it impossible for the runaway grandchild to
escape the controlling process. The feature was designed based on
similar facilities in DragonFlyBSD and Linux, with some
@ -191,17 +191,17 @@
data are on stable storage, to minimize damage of failed
resume.</p>
<p>The code stressed some parts of the system and has lead to
discovery of a numbers of bugs in different areas,
including process management, buffer cache and syscall
handlers. The bugs were fixed, fixes and the features commmitted
<p>The code stressed some parts of the system and has led to
discovery of a number of bugs in different areas,
including process management, buffer cache, and syscall
handlers. The bugs were fixed, and the fixes and features commmitted
by a series culminating in r275745.</p>
<p>During the work described above, it
was noted that process spinlock duties are significantly
overloaded (the same is true for the process lock). The spinlock
was split into per-feature locks, in r275121. Also, as result, it
was possible to eliminate recursion on it, in r275372.</p>
was split into per-feature locks in r275121. As result, it
was also possible to eliminate recursion on it in r275372.</p>
</body>
<sponsor>The FreeBSD Foundation</sponsor>
@ -242,7 +242,7 @@
</project>
<project cat='misc'>
<title>Creating Vagrant images with Packer</title>
<title>Creating Vagrant Images with Packer</title>
<contact>
<person>
@ -271,14 +271,14 @@
create and configure lightweight, reproducible, and portable
development environments.</p>
<p>To get started clone the Git repo and follow the directions in
<p>To get started, clone the Git repo and follow the directions in
the README. More information is available from the Packer and
Vagrant websites.</p>
</body>
</project>
<project cat="proj">
<title>pkg(8)</title>
<title><tt>pkg(8)</tt></title>
<contact>
<person>
@ -305,9 +305,9 @@
</p>
<p>An important part of the development direction for the 1.4
release has been done on stabilizing the existing features, and
release was stabilizing the existing features and
improving the <tt>pkg(8)</tt> experience on small/embedded
machines (reduce memory usage, speed up operations).</p>
machines (reducing memory usage and speeding up operations).</p>
<p><tt>pkg(8)</tt> is not only the &os; Package Manager, but also the
Package Manager for DragonflyBSD. Support has been
@ -340,7 +340,7 @@
</project>
<project cat="bin">
<title>mandoc(1) support</title>
<title><tt>mandoc(1)</tt> Support</title>
<contact>
<person>
@ -375,8 +375,8 @@
format manual pages by default, then fall back to
<tt>groff(1)</tt> if it fails.</p>
<p>This change also fixes an issue with FreeBSD <tt>man(1)</tt>
command not able to properly deal with ".so" in gzipped manual
<p>This change also fixes an issue with the &os; <tt>man(1)</tt>
command not being able to properly deal with ".so" in gzipped manual
pages.</p>
<p>The documentation team has spent a lot of time fixing issues
@ -386,12 +386,12 @@
<p>Most manual pages with remaining issues are from contrib/, for
which changes should be reported and fixed upstream.</p>
<p>The "manlint" target has also been switch to use <tt>mandoc
<p>The "manlint" target has also been switched to use <tt>mandoc
-Tlint</tt>, which results in the target being more useful
when working on manual pages.</p>
<p>Some <tt>groff(1)</tt> vs <tt>mandoc(1)</tt> formatting
differencies have been spotted and reported to mandoc's upstream
<p>Some <tt>groff(1)</tt> versus <tt>mandoc(1)</tt> formatting
differences have been spotted and reported to mandoc's upstream
developers.</p>
</body>
@ -401,8 +401,8 @@
<tt>mandoc(1)</tt>.</p>
</task>
<task>
<p>Figure out a way to detect non <tt>mandoc(1)</tt> unfriendly
manpages from ports and create catpages with <tt>groff(1)</tt>
<p>Figure out a way to detect <tt>mandoc(1)</tt>-unfriendly
manpages in ports and create catpages with <tt>groff(1)</tt>
for them.</p>
</task>
<task>
@ -412,7 +412,7 @@
</project>
<project cat='proj'>
<title>External toolchain</title>
<title>External Toolchain</title>
<contact>
<person>
@ -444,12 +444,12 @@
<body>
<p>The main goal of the external toolchain project is to be able
to build world and kernel with non default toolchain. It can be
to build world and kernel with non-default toolchain. It can be
helpful to:
<ul>
<li>Prepare a migration to a newer version of toolchain components.</li>
<li>Port &os; to a new architecture</li>
<li>Upgrade from a &os; that ships with GCC 4.2 to a version that ship with clang 3.5+ (which need a more modern toolchain than GCC 4.2 to bootstrap).</li>
<li>Upgrade from a &os; that ships with GCC 4.2 to a version that ships with clang 3.5+ (which needs a more modern toolchain than GCC 4.2 to bootstrap).</li>
</ul>
</p>
@ -480,7 +480,7 @@
<p>Those packages will depend on special versions of GCC
(minimalistic cross-built ready GCC) and on binutils. To use
them run: <tt>make CROSS_TOOLCHAIN=powerpc64-gcc TARGET=powerpc
them, run: <tt>make CROSS_TOOLCHAIN=powerpc64-gcc TARGET=powerpc
TARGET_ARCH=powerpc64</tt></p>
<p>As a result of this effort, it has been possible to
@ -504,7 +504,7 @@
</project>
<project cat='kern'>
<title>Timer function support for Linuxulator</title>
<title>Timer Function Support for Linuxulator</title>
<contact>
<person>
@ -520,12 +520,12 @@
<p>Since 2006, initial support for Linux timer function
compatibility support was present but untested.
This update corrects the initial implementation and makes it
available to the 32bit linuxolator on amd64, not just on i386.
available to the 32-bit Linuxulator on amd64, not just on i386.
</p>
<p>Starting with &os; 10.1, this enables users to run another
FPGA high-level synthesis toolchain and emulation platform
on a FreeBSD system.
on a &os; system.
</p>
</body>
@ -551,25 +551,25 @@
</links>
<body>
<p>The FreeBSD GNOME Team maintains the GNOME, MATE and CINNAMON desktop
environments and graphical user interfaces for FreeBSD. GNOME 3 is part
<p>The &os; GNOME Team maintains the GNOME, MATE, and CINNAMON desktop
environments and graphical user interfaces for &os;. GNOME 3 is part
of the GNU Project. MATE is a fork of the GNOME 2 desktop. CINNAMON
is a desktop environment using GNOME 3 technologies but with a GNOME 2
look and feel.</p>
<p>This quarter was an exciting time for the GNOME Team. We imported
GNOME 3.14.0 and CINNAMON 2.2.16 into the ports tree. At the same
time we removed the old GNOME 2.32 desktop. And two weeks later
time, we removed the old GNOME 2.32 desktop. And two weeks later
we updated GNOME to 3.14.2 and CINNAMON to 2.4.2, which was collected
while the preparation for the initial GNOME 3.14.0 import was
underway.</p>
under way.</p>
<p>We moved our development repo to GitHub.
The repo is structured as follows: the <tt>master</tt> branch
is vanilla &os; Ports, and we have <tt>theme branches</tt> for topics,
is vanilla &os; Ports, and we have <tt>theme branches</tt> for topics
such as the porting of MATE 1.9 (mate-1.10 branch) and GNOME 3.15
(gnome-3.16 branch). The GNOME 3.14 branch (gnome-3.14) is not
used/updated anymore because the content has been committed to
used or updated any more because the content has been committed to
ports, but is kept around for the history.</p>
</body>
@ -580,12 +580,12 @@
</task>
<task>
<p>MATE 1.10 porting is underway, the latest 1.9 releases are
<p>MATE 1.10 porting is under way, the latest 1.9 releases are
available in the mate-1.10 branch.</p>
</task>
<task>
<p>GNOME 3.16 porting is underway, and is available in the
<p>GNOME 3.16 porting is under way, and is available in the
gnome-3.16 branch.</p>
</task>
</help>
@ -639,7 +639,7 @@
some updates to system sources, and fielded complaints about
code quality of some other work in critical areas.
While such disagreements will occasionally occur, core is
promoting the routine use of the phabricator service in order to
promoting the routine use of the Phabricator service in order to
review work before committal. Catching problems early is in the
project's best interests, and discussion of changes in an open
review context should minimize confrontational demands for
@ -688,8 +688,8 @@
Raphael Kubo da Costa (rakuco@) and Max Brazhnikov (makc@) maintain all
Qt and KDE-related ports.</p>
<p>This quarter, Qt 5.3 was finally committed to the ports tree
after extensive work that included cleaning up and/or changing a lot of
<p>This quarter, Qt 5.3 was finally committed to the ports tree.
Extensive work was required, including cleaning up and/or changing a lot of
the Qt5 ports infrastructure to make it both easier to maintain the Qt
ports as well as finally make it possible to build newer versions when
older ones are already installed on the system.</p>
@ -728,7 +728,7 @@
</project>
<project cat='doc'>
<title>More Michael Lucas books</title>
<title>More Michael Lucas Books</title>
<contact>
<person>
@ -848,7 +848,7 @@
<body>
<p>Since the last status report, many people have contributed
help in various areas to help with Continuous Integration
and Testing in FreeBSD. Some of the highlights include:</p>
and Testing in &os;. Some of the highlights include:</p>
<ul>
<li>The Jenkins project mentioned on their blog how FreeBSD is using
@ -894,13 +894,13 @@
<li>&a.rodrigc; submitted a formula to create a package for
kyua in the Homebrew packaging system on OS X. The Homebrew project
accepted this. Now, kyua can easily be installed on OS X via a
Homebrew package. Hopefully &os; this will make it easier to share
Homebrew package. Hopefully this will make it easier to share
more test infrastructure and scripts with OS X.</li>
<li>&a.rodrigc; submitted to the Debian project a kyua
package. Approval for this is still pending. A package
will make it much easier to install kyua on Linux distributions which
use Debian packages such as Debian, Ubuntu and Linux Mint. Hopefully
use Debian packages such as Debian, Ubuntu, and Linux Mint. Hopefully
&os; this will make it easier to share more test infrastructure and
scripts with Linux.</li>
@ -908,7 +908,7 @@
Harness for OpenJDK (jtreg). The test results are in JUnit XML
format, which can be natively imported into Jenkins.</li>
<li>Ahmed Kamal, an experienced devops expert, and past
<li>Ahmed Kamal, an experienced devops expert and past
contributor to the Ubuntu project, offered to help
&a.rodrigc; with improving the automation and deployment of
Jenkins nodes in the &os; cluster using the Saltstack automation
@ -957,11 +957,10 @@
<body>
<p>Xfce is a free software desktop environment for Unix and
Unix-like platforms, such as FreeBSD. It aims to be fast and
Unix-like platforms, such as &os;. It aims to be fast and
lightweight, while still being visually appealing and easy to use.</p>
<p>During this quarter, the team has kept up-to-date the following
applications:</p>
<p>During this quarter, the team has kept these applications up-to-date:</p>
<ul>
<li>misc/xfce4-weather-plugin 0.8.5</li>
@ -981,8 +980,8 @@
<li>x11/xfce4-dashboard</li>
</ul>
<p>Moreover, we are working on the next stable release, below list
of ports updated:</p>
<p>Moreover, we are working on the next stable release, with these
ports being updated:</p>
<ul>
<li>sysutils/xfce4-power-manager 1.4.2</li>
@ -1003,16 +1002,16 @@
<help>
<task>
<p>Find workaround when acpi_video(4) is not functional
<p>Find workaround <tt>when acpi_video(4)</tt> is not functional
(panel crashes); OpenBSD seems to have same problem.</p>
</task>
<task>
<p>Cleanup patch in order to add new panel plugin in ports
<p>Clean up patch in order to add new panel plugin in ports
tree.</p>
</task>
<task>
<p>Continue to work on documentation, especially the Porter's
handbook.</p>
Handbook.</p>
</task>
</help>
</project>
@ -1058,11 +1057,11 @@
</project>
<project cat='ports'>
<title>The Graphics stack on FreeBSD</title>
<title>The Graphics Stack on &os;</title>
<contact>
<person>
<name>FreeBSD Graphics team</name>
<name>&os; Graphics team</name>
<email>freebsd-x11@FreeBSD.org</email>
</person>
</contact>
@ -1079,7 +1078,7 @@
now usually updated shortly after a new release. Mesa 10.x brings
huge improvements in terms of OpenGL standards support, performance
and stability, especially for Radeon owners. Mesa 9.1 is kept for
FreeBSD 9.x, but we have plans to fix this; see below.</p>
&os; 9.x, but we have plans to fix this; see below.</p>
<p><tt>graphics/gbm</tt> and <tt>devel/libclc</tt> are new ports used
by Mesa to implement OpenCL. The next step is to finish the port for
@ -1090,7 +1089,7 @@
of xserver supporting Mesa 9.1. Changes are described in an article
on the blog. The most noticeable one is the switch from
the input device detection back-end based on HAL to the one based on
devd(8). hald(8) is still required by many desktop environments, but
<tt>devd(8)</tt>. <tt>hald(8)</tt> is still required by many desktop environments, but
the X.Org server itself is free from it.</p>
<p>xserver was the last port supporting the <tt>WITH_NEW_XORG</tt>
@ -1104,7 +1103,7 @@
<ul>
<li><tt>TEXTURE_FLOAT</tt> in graphics/dri, which allows Mesa to
advertise the support for OpenGL 3.0+;</li>
<li><tt>LCD_FILTERING</tt> in print/freetype2, which enables the
<li><tt>LCD_FILTERING</tt> in <tt>print/freetype2</tt>, which enables the
subpixel rendering engine, improving font anti-aliasing.</li>
</ul>
@ -1115,12 +1114,12 @@
<p>On the kernel side, Tijl Coosemans added AGP support back to the
TTM memory manager and therefore to the Radeon driver. His work was
merged back to stable/10 and will be available in FreeBSD
merged back to stable/10 and will be available in &os;
10.2-RELEASE.</p>
<p>We migrated our Ports development tree to Git and GitHub. Tracking
changes in the official Ports tree and preparing patches is way
easier. Furthermore, we can accept pull requests. All reasons behind
easier. Furthermore, we can accept pull requests. All of the reasons behind
this change are detailed on the blog and the workflow is described
on the wiki.</p>
@ -1130,7 +1129,7 @@
<p>Our next items on the roadmap are:</p>
<ol>
<li>Provide FreeBSD 10.1-RELEASE's i915 driver to FreeBSD 9.x users
<li>Provide &os; 10.1-RELEASE's i915 driver to &os; 9.x users
through a new port. This is a work in progress, but it would allow
us to remove Mesa 9.1 and make Mesa 10.4 available everywhere.</li>
<li>Once Mesa 9.1 is gone, we can update xserver to 1.16.</li>
@ -1246,10 +1245,10 @@
<body>
<p>During this quarter almost all pending Xen changes have been
committed, enabling FreeBSD to be used as Dom0 under the new
PVH mode. The set of features supported by FreeBSD is still limited,
but it should allow for basic usage of FreeBSD as Dom0. Support for
booting Xen from the FreeBSD boot loader will be committed very soon
committed, enabling &os; to be used as Dom0 under the new
PVH mode. The set of features supported by &os; is still limited,
but it should allow for basic usage of &os; as Dom0. Support for
booting Xen from the &os; boot loader will be committed very soon
to HEAD.</p>
<p>Apart from testing on a variety of hardware, work has now
@ -1257,8 +1256,8 @@
parity with a traditional PV Dom0 and to declare the PVH ABI as
stable.</p>
<p>Regarding guest improvements (running FreeBSD as a DomU),
there's also ongoing work to add unmapped IO support to Xen blkfront,
<p>Regarding guest improvements (running &os; as a DomU),
there is also ongoing work to add unmapped IO support to Xen blkfront,
which is blocked pending some modifications to the generic bounce
buffer code.</p>
</body>
@ -1287,7 +1286,7 @@
</project>
<project cat='proj'>
<title>Clang, llvm and lldb updated to 3.5.0</title>
<title>Clang, <tt>llvm</tt>, and <tt>lldb</tt> Updated to 3.5.0</title>
<contact>
<person>
@ -1319,13 +1318,13 @@
</links>
<body>
<p>Just before the end of the year, we have updated clang,
llvm and lldb in the base system to 3.5.0 release. These all contain
numerous improvements; please see the linked release notes for
<p>Just before the end of the year, we updated clang,
llvm, and lldb in the base system to 3.5.0 release. These all contain
numerous improvements. Please see the linked release notes for
more detailed information.</p>
<p>This is the first release that requires C++11 support to build.
At this point, FreeBSD 10.0 and later provide that support, at least
At this point, &os; 10.0 and later provide that support, at least
on x86.</p>
<p>In the near future, more components from llvm.org will
@ -1333,7 +1332,7 @@
being the first.</p>
<p>Thanks to Ed Maste, Roman Divacky, Andrew Turner, Justin
Hibbits and Antoine Brodin for their invaluable help with this
Hibbits, and Antoine Brodin for their invaluable help with this
import.</p>
</body>
@ -1350,7 +1349,7 @@
</task>
<task>
<p>There are still some open issues with the ARM, PowerPC
<p>There are still some open issues with the ARM, PowerPC,
and Sparc64 architectures, and any help in this area is very much
appreciated.</p>
</task>
@ -1398,7 +1397,7 @@
</project>
<project cat='proj'>
<title>Git integration</title>
<title>Git Integration</title>
<contact>
<person>
@ -1471,7 +1470,7 @@
</project>
<project cat='proj'>
<title>Migration to ELF Tool Chain tools</title>
<title>Migration to ELF Tool Chain Tools</title>
<contact>
<person>
@ -1557,7 +1556,7 @@
</project>
<project cat='proj'>
<title>bhyve</title>
<title><tt>bhyve</tt></title>
<contact>
<person>
@ -1764,9 +1763,9 @@
<p>As of the end of Q4 the ports tree holds more than 24,000
ports, and the PR count is just over 1,400. As during the
previous quarter the tree saw a sustained activity with
almost 6,000 commits and more than 1,600 ports PR closed!</p>
almost 6,000 commits and more than 1,600 ports PRs closed!</p>
<p>In Q4 five new developers were granted a ports commit bit
<p>In Q4, five new developers were granted a ports commit bit
(gordon@, jmg@, jmmv@, bofh@, truckman@) and six were taken
in for safekeeping (sylvio@, pclin@, flz@, jsa@, anders@,
motoyuki@).</p>
@ -1778,7 +1777,7 @@
<p>This quarter also saw the release of the fourth quarterly
branch, namely 2014Q4.</p>
<p>On QA side 39 exp-runs were performed to validate sensitive
<p>On the QA side, 39 exp-runs were performed to validate sensitive
updates or cleanups.</p>
</body>
@ -1793,14 +1792,14 @@
<task>
<p>2014 is the year that saw the highest number of commits
in all of our ports tree's history! As for the PR front and
to keep our beloved tree in such a good shape we would love
to keep our beloved tree in good shape, we would love
to see the same commitment from our developers next year!</p>
</task>
</help>
</project>
<project cat='kern'>
<title>Linux emulation layer a.k.a. Linuxulator</title>
<title>Linux Emulation Layer, the Linuxulator</title>
<contact>
<person>
@ -1823,10 +1822,10 @@
version 2.20 or later to be available on &os;. Glibc 2.20
requires a Linux kernel (or emulation thereof) of version 2.6.32
or later. The main obstacle preventing this is that the current
Linuxulator uses native FreeBSD processes for emulating Linux
Linuxulator uses native &os; processes for emulating Linux
threads. This leads to several problems, including problems with
process reparenting and dethreading, <tt>wait()</tt> and signal
handling. It would be much better to reuse the FreeBSD kernel
handling. It would be much better to reuse the &os; kernel
code for thread management than to create a completely new
codebase for pseudothread management in the Linuxulator.</p>
@ -1848,8 +1847,8 @@
<li>Many bugs were fixed</li>
</ul>
<p>The project's code is located in the FreeBSD Project's
Subversion repository, at <tt>base/user/dchagin/lemul</tt> (a
<p>The project's code is located in the &os; Project's
Subversion repository at <tt>base/user/dchagin/lemul</tt> (a
little bit old). To facilitate merging the improvements back to
head, several patches have been placed on reviews.FreeBSD.org with
the tag <tt>#lemul</tt>. Nearly half of the patches have already
@ -1883,7 +1882,7 @@
</task>
<task>
<p>Extend xucred suppport, which is required for many Linux
<p>Extend xucred support, required for many Linux
applications.</p>
</task>
</help>
@ -1936,7 +1935,7 @@
<p>The ports have packages built for amd64 (available through the
ports emulators/i386-wine and i386-wine-devel) for &os; 8.4, 9.1+,
10.0+ and CURRENT.</p>
10.0+, and CURRENT.</p>
<p>Accomplishments include:</p>
@ -1957,9 +1956,9 @@
<li>Various smaller changes.</li>
</ul>
<p>We would like to thank all volunteers who contributed feedback
<p>We would like to thank all the volunteers who contributed feedback
or even patches. We would also like to welcome kmoore@ to the Wine
team. He has been extensively involved in bring wine-compholio to the
team. He has been extensively involved in bringing wine-compholio to the
Ports Collection.</p>
<p>Future development on Wine will focus on:</p>
@ -1971,9 +1970,9 @@
</ul>
<p>Maintaining and improving Wine is a major undertaking that
directly impacts end-users on &os; (including many gamers). If you
are interested in helping please contact us. We will happily accept
patches, suggest areas of focus or have a chat.</p>
directly impacts end-users on &os;, including many gamers. If you
are interested in helping, please contact us. We will happily accept
patches, suggest areas of focus, or have a chat.</p>
</body>
<help>
@ -1983,7 +1982,7 @@
</task>
<task>
<p>FreeBSD/amd64 integration (see the <a
<p>&os;/amd64 integration (see the <a
href="http://wiki.FreeBSD.org/i386-Wine">i386-Wine wiki page</a>).</p>
</task>
@ -1994,7 +1993,7 @@
</project>
<project cat='ports'>
<title>Linux emulation ports</title>
<title>Linux Emulation Ports</title>
<contact>
<person>
@ -2155,7 +2154,7 @@
<ul>
<li>creating ports/packages of the gnu-efi toolchain,
Matthew Garrett’s shim loader, and sbsigntools</li>
Matthew Garrett's shim loader, and sbsigntools</li>
<li>extending the shim to provide an API for boot1.efi to
load and verify binaries signed by keys known to the shim</li>
<li>writing uefisign(8), a BSD-licensed utility to sign EFI
@ -2220,8 +2219,8 @@
<body>
<p>There is growing interest in ARM's 64-bit architecture.
Officially named as AArch64, it is also known as ARMv8 and arm64.
Andrew Turner started initial work on the FreeBSD/arm64 port at
Officially named AArch64, it is also known as ARMv8 and arm64.
Andrew Turner started initial work on the &os;/arm64 port at
the end of 2012.</p>
<p>The &os; Foundation is now collaborating with ARM,
@ -2229,9 +2228,9 @@
arm64, and significant progress was made on the port over the last
quarter of 2014.</p>
<p>As of the end of the year &os; boots to single-user mode
<p>As of the end of the year, &os; boots to single-user mode
on arm64, executing both static and dynamic applications. Patches
in review allow &os; to boot to multi-user mode and these are
in review allow &os; to boot to multi-user mode, and these are
expected to be merged soon. This includes implementing many stub
functions in userland and the kernel. With this, &os; has booted to
multi-user mode on both the ARM Foundation Model and the QEMU full
@ -2279,7 +2278,7 @@
</project>
<project cat='bin'>
<title>libxo: generate text, XML, JSON, and HTML output</title>
<title><tt>libxo</tt>: Generate Text, XML, JSON, and HTML Output</title>
<contact>
<person>
@ -2308,9 +2307,9 @@
<p>Juniper Networks has created a library called libxo, which
makes it easy for utilities to emit output in various
formats. By default the text output is emitted, but with the
introduction of the <tt>—libxo</tt> option this can be changed to
XML, JSON and HTML. The &os; project has imported this library
formats. By default, text output is emitted, but with the
introduction of the <tt>--libxo</tt> option this can be changed to
XML, JSON, and HTML. The &os; project has imported this library
into the base system and is in the process of rewriting utilities
to use libxo.</p>