svn commit: r50254 - head/en_US.ISO8859-1/htdocs/news/status
Benjamin Kaduk
bjk at FreeBSD.org
Sat May 13 04:00:26 UTC 2017
Author: bjk
Date: Sat May 13 04:00:25 2017
New Revision: 50254
URL: https://svnweb.freebsd.org/changeset/doc/50254
Log:
Make a second editing pass over the 2017Q1 status report
Modified:
head/en_US.ISO8859-1/htdocs/news/status/report-2017-01-2017-03.xml
Modified: head/en_US.ISO8859-1/htdocs/news/status/report-2017-01-2017-03.xml
==============================================================================
--- head/en_US.ISO8859-1/htdocs/news/status/report-2017-01-2017-03.xml Fri May 12 20:33:27 2017 (r50253)
+++ head/en_US.ISO8859-1/htdocs/news/status/report-2017-01-2017-03.xml Sat May 13 04:00:25 2017 (r50254)
@@ -110,7 +110,7 @@
we can start coordinating work.</p>
<p>In addition, since we have a translation set already from the
- XML files, it would be interesting to see and know whether we
+ XML files, it would be interesting to see whether we
can merge them easily into the po structure. If you have ideas
on that, contact us a.s.a.p.</p>
</body>
@@ -201,13 +201,13 @@
where page mappings are repeated. This may change in the
future.</p>
- <p>As with the AIM powerpc64 port, this supports running powerpc
+ <p>As with the AIM powerpc64 port, Book-E supports running powerpc
(32-bit) binaries as well, and has even been tested with a
32-bit <tt>init</tt> and 64-bit shell.</p>
<p>Several of the SoC drivers are supported, however, the dTSEC
ethernet controller is not yet supported. Work is ongoing to
- support this.</p>
+ support it.</p>
<p>A QORIQ64 config is included, targeting the P5 and T* series
SoCs from Freescale.</p>
@@ -248,7 +248,7 @@
allows for file accesses within a single logical mount to be
performed against multiple file servers, with the potential
for data access to occur in parallel. The pNFS
- "layout" specifies how the division occurs, with
+ "layout" in use specifies how the division occurs, with
metadata operations occurring against the main server, and
bulk data operations (read/write/setattr/etc.) occurring via
a layout-specific scheme between the client and data
@@ -381,8 +381,8 @@
</links>
<body>
- <p>The TrustedBSD Project is an open source community developing
- advanced security features for the open source &os; operating
+ <p>The TrustedBSD Project is an open-source community developing
+ advanced security features for the open-source &os; operating
system. Started in April 2000, the project developed support
for extended attributes, access control lists (ACLs), UFS2,
OpenPAM, security event auditing, OpenBSM, a flexible kernel
@@ -675,13 +675,13 @@
libraries are readily available, we are at the point where we can
shift our focus towards porting full applications.</p>
- <p>Late February one of the lead developers of
+ <p>In late February one of the lead developers of
<a href="https://github.com/bitcoin/bitcoin">the Bitcoin reference
implementation</a> got in touch, as he is very interested in
creating a copy of Bitcoin that is better protected against
security bugs. You do not want a security bug in the
networking/consensus code to allow an attacker to steal coins from
- your local wallet.</p>
+ your local wallet!</p>
<p>As I think that this is a use case that demonstrates the strength
of CloudABI well, I've made addressing any issues reported by the
@@ -703,7 +703,7 @@
Memcached? If so, feel free to give the sandboxed version of
Memcached for CloudABI a try!</task>
- <task>So far CloudABI can be used to run software written in C, C++
+ <task>So far, CloudABI can be used to run software written in C, C++
and Python. Would you like to see any other programming language
work on CloudABI as well? Be sure to help out!</task>
</help>
@@ -800,7 +800,7 @@
<links>
<url href="https://wiki.FreeBSD.org/Rust">Wiki Portal</url>
- <url href="https://gist.github.com/dumbbell/b587da50ef014078da9e732a4331ebad">Guide to Bootstrap Rust on &os;</url>
+ <url href="https://gist.github.com/dumbbell/b587da50ef014078da9e732a4331ebad">Guide to Bootstraping Rust on &os;</url>
<url href="https://bugs.FreeBSD.org/bugzilla/show_bug.cgi?id=216143">Bug Report to Track Progress on Bootstrapping</url>
</links>
@@ -836,7 +836,7 @@
<task>Investigate compiler crashes.</task>
<task>Create a <tt>USES=rust</tt> Makefile helper and simplify
- Rust and Cargo ports.</task>
+ the Rust and Cargo ports.</task>
<task>Investigate how to speed up <tt>lang/rust*</tt>
compilation time.</task>
@@ -906,14 +906,14 @@
<p>Specific tasks completed include:</p>
<ul>
- <li>Platform benchmarking and low-level optimisations
- (internal bus, cache L1/L2 prefetch) — already
+ <li>Platform benchmarking and low-level optimizations
+ (internal bus, L1/L2 cache prefetch) — already
submitted)</li>
- <li>Enable PL310 L2 cache controller — currently under
+ <li>Enable the PL310 L2 cache controller — currently under
review</li>
- <li>NETA tests, optimisations and PHY-handling rework</li>
+ <li>NETA tests, optimizations and PHY-handling rework</li>
<li><tt>e6000sw</tt> PHY handling rework and fixes</li>
@@ -967,7 +967,7 @@
<li>1 RPMB (Replay Protected Memory Block) partition</li>
- <li>4 general purpose partitions (optionally with a enhanced
+ <li>4 general purpose partitions (optionally with an enhanced
or extended attribute)</li>
</ul>
@@ -1004,10 +1004,10 @@
silicon bug (which is independent of running in DDR52 mode).
The only viable workaround for that problem appears to be the
implementation of support for ADMA2 mode in <tt>sdhci(4)</tt>
- (currently, <tt>sdhci(4)</tt> supports the encumbered SDMA
- mode only, or no DMA at all).</p>
+ (currently, <tt>sdhci(4)</tt> supports only the encumbered SDMA
+ mode or no DMA at all).</p>
- <p>However, r315598 also already brought in infrastructure and
+ <p>However, r315598 also brought in infrastructure and
a fair amount of code for using even faster transfer modes with eMMC
devices and SD cards respectively, i.e., up to HS400ES with eMMC
and the UHS-I modes up to SDR104 with SD cards.</p>
@@ -1082,7 +1082,8 @@
that are running ZFS. User stations would be running
<tt>bhyve</tt> on RBD disks that are stored in Ceph.</p>
- <p>The &os; build will build most of the tools in Ceph.</p>
+ <p>Compiling for &os; will now build most of the tools
+ available in Ceph.</p>
<p>Notable progress since the last report:</p>
@@ -1188,7 +1189,7 @@
that the project appears welcoming to newcomers.</p>
<p>Normally, most of Core's activities around this are done in
- private -- a quiet word in the right ear, some discrete
+ private — a quiet word in the right ear, some discrete
peacemaking, occasional reading of the riot act. Most of the time,
this is all that is necessary.</p>
@@ -1232,7 +1233,7 @@
This is not in the current plan, but a number of developers and
important &os; users would be keen to see it happen, given some of
the work that has gone into the stable/10 branch since
- 10.3-RELEASE. On the other hand, this would require an additional
+ 10.3-RELEASE. On the other hand, this would represent an additional
support burden for the Security Team, including maintaining versions of
software that have been declared obsolete upstream, in particular
OpenSSL. As an even-numbered release, 10.4-RELEASE would have a
@@ -1248,7 +1249,7 @@
the <tt>finger</tt> server on freefall.freebsd.org. Many
developers have included details such as phone numbers into
the GECOS field of their &os; password database entries, and
- these would be revealed by the <tt>finger</tt> server --
+ these would be revealed by the <tt>finger</tt> server —
details which are nowadays generally felt inadvisable to
expose publicly. <tt>finger</tt> is still available
internally within freefall.freebsd.org. Core recommends that
@@ -1261,7 +1262,7 @@
particular, Postmaster and the Security Team are in need of new blood.
Recruiting for a new member of the Security Team is well under way, but anyone
interested in joining any of the teams is encouraged to make
- themselves known either to Core, or directly to the teams
+ themselves known either to Core or directly to the teams
concerned.</p>
</body>
</project>
@@ -1292,7 +1293,7 @@
generated by the inserted card, which is a prerequisite for
implementing the SDIO interface. SDIO support is necessary
for communicating with the WiFi/BT modules found on many
- development boards, like the Raspberry Pi 3.</p>
+ development boards, such as the Raspberry Pi 3.</p>
<p>Another feature that the new stack will have is support for
sending SD commands from userland applications using
More information about the svn-doc-all
mailing list