svn commit: r43271 - head/en_US.ISO8859-1/htdocs/news/status
Gabor Pali
pgj at FreeBSD.org
Mon Dec 2 09:55:51 UTC 2013
Author: pgj
Date: Mon Dec 2 09:55:50 2013
New Revision: 43271
URL: http://svnweb.freebsd.org/changeset/doc/43271
Log:
- Various fixes for the developer summit report
Submitted by: pluknet, wblock
Modified:
head/en_US.ISO8859-1/htdocs/news/status/report-2013-09-devsummit.xml
Modified: head/en_US.ISO8859-1/htdocs/news/status/report-2013-09-devsummit.xml
==============================================================================
--- head/en_US.ISO8859-1/htdocs/news/status/report-2013-09-devsummit.xml Sun Dec 1 22:51:34 2013 (r43270)
+++ head/en_US.ISO8859-1/htdocs/news/status/report-2013-09-devsummit.xml Mon Dec 2 09:55:50 2013 (r43271)
@@ -39,24 +39,23 @@ Report//EN" "http://www.FreeBSD.org/XML/
</links>
<body>
- <p>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.</p>
+ <p>The discussions on toolchains and build systems in Malta
+ 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.</p>
<p>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
+ 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.</p>
- <p>In the context of replacing GCC we discussed David Chisnall's
+ <p>In the context of replacing GCC, we discussed David Chisnall's
plan to stop building GCC and <tt>libstdc++</tt> on systems where
Clang is the default compiler (this has happened). Further, we
plan to migrate all existing platforms to Clang or an external
@@ -69,12 +68,12 @@ Report//EN" "http://www.FreeBSD.org/XML/
<tt>freebsd-update(8)</tt> does including upgrades and detecting
changed files in a more operating-friendly way. Using
<tt>pkg(8)</tt> as a replacement for <tt>freebsd-update(8)</tt>
- is not a general solution yet as package signing and delta
+ is not a general solution yet, as package signing and delta
support is required to make it viable.</p>
- <p>In Malta we covered two main topics. The overall status of
+ <p>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
+ 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
@@ -150,7 +149,7 @@ Report//EN" "http://www.FreeBSD.org/XML/
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,
+ from all sides, e.g., administration, functionality, security,
and so on.</p>
<p>Another thing that we have talked about was the on-going print
@@ -158,7 +157,7 @@ Report//EN" "http://www.FreeBSD.org/XML/
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
+ sections, etc.) in order to have 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
@@ -185,7 +184,7 @@ Report//EN" "http://www.FreeBSD.org/XML/
talked with Gavin Atkinson about removing really outdated
documentation from the <tt>doc</tt> 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
+ objective is to have a system that helps by 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
@@ -222,9 +221,9 @@ Report//EN" "http://www.FreeBSD.org/XML/
progress, and future builds based on <tt>10-STABLE</tt> are
coming soon. The plan there is to track the <tt>10-STABLE</tt>
branch until it becomes <tt>11-STABLE</tt>. Kris also described
- the <q>rolling release</q> model they have been switched to.
- This approach leverages <tt>freebsd-update(8)</tt> to provide
- rolling updates for the base system (that is, the kernel and the
+ the <q>rolling release</q> model they have switched to. This
+ approach leverages <tt>freebsd-update(8)</tt> to provide rolling
+ updates for the base system (that is, the kernel and the
userland utilities) and in parallel with that, <tt>pkg(8)</tt>
is employed for the packages, especially for the desktop
applications. It was also reported that the PC-BSD staff has
@@ -232,7 +231,7 @@ Report//EN" "http://www.FreeBSD.org/XML/
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.</p>
+ authentication.</p>
<p>Next, the current in-progress items were reported and
discussed. The <tt>sysutils/pcbsd-utils</tt> and
@@ -240,17 +239,17 @@ Report//EN" "http://www.FreeBSD.org/XML/
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
+ programs. The PC-BSD developers have also been working on a
<q>life-preserver</q> ZFS command-line and GUI utility, which is
- still in heavy development. The purpose of this tools to
+ still in heavy development. The purpose of these tools to
leverage ZFS for snapshot and replication functionality as a
backup solution.</p>
- <p>Finally, the plans for PC-BSD 10 was summarized. The PBI
+ <p>Finally, the plans for PC-BSD 10 were summarized. The PBI
package format that PC-BSD employs in now under revision and
- will be updated to use <tt>pkg(8)</tt> 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
+ will be updated to use <tt>pkg(8)</tt> repository to build PBIs
+ and provide better integration for server PBIs. As part of this
+ effort, it will also be investigated whether it is possible to
run PBIs without actual installation. <tt>pc-sysinstall</tt>
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
@@ -277,22 +276,23 @@ Report//EN" "http://www.FreeBSD.org/XML/
</links>
<body>
- <p>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
- <tt>bhyve(4)</tt> into 10.0-RELEASE. We talked about little bit
- about <tt>bhyve(4)</tt> <q>memory overcommit</q> 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 <tt>bhyve(4)</tt> 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.</p>
+ <p>In the virtualization working group, Peter Grehan gave a 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
+ <tt>bhyve(4)</tt> into 10.0-RELEASE. We talked a little bit
+ about the <tt>bhyve(4)</tt> <q>memory overcommit</q> 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
+ <tt>bhyve(4)</tt> work has also been 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 to adding support
+ for live migration.</p>
</body>
</project>
@@ -321,12 +321,13 @@ Report//EN" "http://www.FreeBSD.org/XML/
<body>
<p>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.</p>
+ which is a new 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 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.</p>
<p>Then a status report of ZFS on other platforms besides &os; and
Illumos was given. On Linux, it basically works, it is being
@@ -341,13 +342,13 @@ Report//EN" "http://www.FreeBSD.org/XML/
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
+ platform-specific VFS layer, but that would reduce the hackiness
+ of the Solaris Porting Layer that is in &os; and 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.</p>
+ rather than doing just Illumos plus &os; and then tacking on the
+ Linux layer.</p>
<p>Next, we talked about test coverage and what tests are
available. Spectra Logic has finished porting the STF test suite
@@ -362,7 +363,7 @@ Report//EN" "http://www.FreeBSD.org/XML/
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
+ subtle physical pathing that was not a hundred percent
generic.</p>
</body>
</project>
@@ -389,7 +390,7 @@ Report//EN" "http://www.FreeBSD.org/XML/
<p>In the security working group, we had four items in the agenda.
First of all, we started with the current state of
<tt>/dev/random</tt>. There were a number of known entropy
- harvesting bugs that have been fixed, for example feeding a lot
+ harvesting bugs that have been fixed, for example feeding a lot of
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
@@ -398,30 +399,30 @@ Report//EN" "http://www.FreeBSD.org/XML/
Padlock backends and feed them into Yarrow instead of delivering
their output directly to <tt>/dev/random</tt>. It will still be
possible to access hardware random number generators, that is,
- RDRAND, Padlock etc, directly by inline assembly or by using
+ 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
<tt>initrandom</tt> script that feeds mostly static data into
<tt>/dev/random</tt> and pretends that is actually entropy,
- while it is not. Pawel Jakub Dawidek has a patch which has been
+ when 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 <tt>/dev/random</tt> 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
+ device. Also, we should have the installer fill up the
<tt>/entropy</tt> 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
+ the clones diverge quickly enough. As an example, we discussed
+ having the installer generate SSH keys. But a 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
+ installation process, which is as almost as bad. The device
attach patch helps with that.</p>
<p>The next item was package signing. We have a short-term
@@ -433,11 +434,11 @@ Report//EN" "http://www.FreeBSD.org/XML/
<tt>/etc/pkg/fingerprints</tt>. 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
- <tt>freebsd-update(8)</tt> to distribute an update that moves
+ <tt>freebsd-update(8)</tt> distribute an update that moves
the key from the <tt>trusted</tt> directory to the
- <tt>revoked</tt> directory, and adds the new key to the
+ <tt>revoked</tt> directory and adds the new key to the
<tt>trusted</tt> directory. When launched, <tt>pkg(8)</tt>
- looks into those directories, loads all the keys it founds, and
+ looks into those directories, loads all the keys it finds, and
will accept a packages if it is signed by at least one good key
and no revoked keys.</p>
@@ -448,7 +449,7 @@ Report//EN" "http://www.FreeBSD.org/XML/
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
+ 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. <tt>mmap()</tt>
@@ -457,7 +458,7 @@ Report//EN" "http://www.FreeBSD.org/XML/
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.
+ this apparently interferences the way some ports build.
<tt>libc</tt> is now a linker script and not just a <tt>.so</tt>
file, therefore the linker will always know how to handle this.
<tt>ldbase</tt> randomization was also discussed, but it has not
@@ -473,10 +474,10 @@ Report//EN" "http://www.FreeBSD.org/XML/
common error is to have <tt>></tt> instead of <tt>>=</tt>.
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
+ unused because of this. One of the reasons for that is that the kernel
patch level does not necessarily reflect the patch level of the
userland, because <tt>freebsd-update(8)</tt> does not update the
- kernel patch level unless the actual update affects the kernel. So,
+ 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
@@ -485,8 +486,8 @@ Report//EN" "http://www.FreeBSD.org/XML/
the same CPE without any trouble. We will store it as
annotations for <tt>pkg(8)</tt> 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
+ to do the matching ourselves any more. The specification of CPE
+ includes a matching algorithm and is shipped with a reference
implementation. &os; 10 is going to install a script under
<tt>/libexec</tt> that prints the userland patch level, and
<tt>freebsd-update(8)</tt> will update that script so it will be
@@ -522,7 +523,7 @@ Report//EN" "http://www.FreeBSD.org/XML/
</links>
<body>
- <p>The discussion on embedded platforms has started in Cambridge a
+ <p>The discussion on embedded platforms was 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
@@ -532,14 +533,14 @@ Report//EN" "http://www.FreeBSD.org/XML/
Tier-1 status. Finally, we discussed power management.</p>
<p>The discussion of Tier-1 status for embedded platforms,
- particularly Raspberry-Pi identified a number of things required
+ 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,
+ and stabilization 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 <tt>freebsd-update(8)</tt> but in the long term this
+ process. We also need to be building packages (Stacey Son 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 <tt>freebsd-update(8)</tt>, 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.</p>
@@ -561,8 +562,7 @@ Report//EN" "http://www.FreeBSD.org/XML/
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.</p>
+ know what is and what is not supported on a given platform.</p>
<p>Next, we had a long discussion about the auto tuning changes
that Alfred Perlstein did recently. They are great for machines
@@ -574,42 +574,42 @@ Report//EN" "http://www.FreeBSD.org/XML/
&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 <tt>armv6</tt> platform
- — currently there is a number technical roadblocks to
+ — currently there are a number technical roadblocks to
that. We want to keep the <tt>armv4</tt> and <tt>armv5</tt>
- 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
+ support in 11 until there is some particular reason not to do
+ that. One of the biggest tasks probably, since we are moving to
+ Clang, would be the external toolchain item. Besides that, the
<tt>armv6</tt> 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
+ such as Raspberry 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 <tt>freebsd-update(8)</tt>. 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.</p>
+ and let the Android blobs to be dropped in. There are a number
+ of challenges in this case.</p>
<p>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
<q>domains</q> 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.</p>
+ treated as such. Also, GPIO and pinmux are inconsistent
+ between the different releases, we need to fix that. We also
+ talked about Arm64, where there are 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. Together with the
+ Semihalf people and the ARM representative at the summit, Andrew
+ Wafaa, we have conluded that Arm64 support 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.</p>
</body>
</project>
@@ -636,17 +636,17 @@ Report//EN" "http://www.FreeBSD.org/XML/
what they did for the PC-BSD CDN (Content Delivery Network).
For example, it uses the <tt>--delay-update</tt> flag for
<tt>rsync(1)</tt> to make it more atomic, uses a lot of ZFS
- functions (e.g. replication, snapshot management) and
+ functions (e.g., replication, snapshot management) and
implements automatic mirror selection. It was a quite
- interesting talk, and featured few interesting ideas that we
+ interesting talk, and featured some 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 <tt>SSP_UNSAFE</tt> knob. On the contrary,
- it is not enabled by default on 9.x, but it can be turned on by
- the other knob, <tt>WITH_SSP_PORT</tt>. This should work on
- amd64, and it has no effect on i386.</p>
+ about stack protection (SSP). It will be enabled by default in
+ &os; 10.x on amd64 and i386 platforms, but can be turned
+ off by the <tt>SSP_UNSAFE</tt> knob. Conversely, it is not
+ enabled by default on 9.x, but can be turned on by the other
+ knob, <tt>WITH_SSP_PORT</tt>. This should work on amd64, and it
+ has no effect on i386.</p>
<p>Baptiste Daroussin talked about staged installs which was
committed recently. Every other package system does that, now we
@@ -656,17 +656,17 @@ Report//EN" "http://www.FreeBSD.org/XML/
<tt>NEED_ROOT</tt> 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 <tt>post-install</tt> 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
+ checks can be automated this way, catching broken plists and
+ helping to get rid of the special <tt>post-install</tt> scripts.
+ It lays the foundation for some new features we want to add in
+ the future, for example implementing sub-packages. Having
+ sub-packages enables building packages once and putting 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
+ Actually, this would help us find out which ports in the tree
are not used any more.</p>
<p>Then there was a discussion about what to do next. We have
@@ -676,15 +676,15 @@ Report//EN" "http://www.FreeBSD.org/XML/
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
+ ongoing plan for three years, because we needed many things to
+ happen before we could proceed, such as moving away from CVS,
+ introducing new-style binary packages, deploying new build
clusters. We have finally got them all, and we can actually do
it now with the <tt>pkg-test</tt> setup. So, we are hoping to
start with the first quarterly release in early November.</p>
<p>We had a long discussion about removing support for old-style binary
- packages, now we have <tt>pkg(8)</tt>. Staying compatible with
+ packages now that we have <tt>pkg(8)</tt>. Staying compatible with
<tt>pkg_install(1)</tt> 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
@@ -692,7 +692,7 @@ Report//EN" "http://www.FreeBSD.org/XML/
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
<tt>pkg(8)</tt> that it can interoperate with various
- third-party applications, e.g. puppet and chef. It is still a POLA
+ 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
@@ -704,16 +704,16 @@ Report//EN" "http://www.FreeBSD.org/XML/
<p>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 <tt>LATEST_LINK</tt> to work this
- behavior around. We should educate people to make better use of
- <tt>PKGNAMESUFFIX</tt> 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.
- <tt>PKGNAME</tt> must be unique across categories, so when one
- uses <tt>pkg-add(8)</tt>, 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.</p>
+ on this, so currently we have <tt>LATEST_LINK</tt> to work
+ around this behavior. We should educate people to make better
+ use of <tt>PKGNAMESUFFIX</tt> 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. <tt>PKGNAME</tt> must be unique across categories,
+ so when one uses <tt>pkg-add(8)</tt>, 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.</p>
</body>
</project>
@@ -757,7 +757,7 @@ Report//EN" "http://www.FreeBSD.org/XML/
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
+ with DNSSEC operations in an informative way. There have been
many proposals for that, like the get-api from Hoffman, or
draft-hayatnagarkar-dns-ext-validator-api for <tt>libval</tt>,
but it is currently being standardized by members of IETF. What
@@ -786,12 +786,12 @@ Report//EN" "http://www.FreeBSD.org/XML/
<body>
<p>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
+ status update. A major change was that previously we had only a
+ single part-time employee, 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
+ improving continuity within different teams like 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
@@ -804,8 +804,8 @@ Report//EN" "http://www.FreeBSD.org/XML/
<p>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
+ not allow him to do that as they could not get commercial
+ support for &os;. So he started his own company solely for this
purpose, which for example, includes hardware certification.</p>
<p>There was a discussion revolving around that current status of
@@ -815,7 +815,7 @@ Report//EN" "http://www.FreeBSD.org/XML/
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
+ backported erratas for the releases. Then we talked about
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
@@ -849,7 +849,7 @@ Report//EN" "http://www.FreeBSD.org/XML/
<body>
<p>In the USB working group, Hans-Petter Selasky summarized what
- happened to &os;'s USB stack during the last one year. He
+ happened to &os;'s USB stack during the last 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
@@ -900,14 +900,14 @@ Report//EN" "http://www.FreeBSD.org/XML/
activities. One can also catch reports from the Google Summer
of Code students at the European instances.</p>
- <p>At EuroBSDcon 2013 we had talks in the following topics:
+ <p>At EuroBSDcon 2013 we had talks on 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
+ support, a &os;-based network simulation environment, and
+ 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.</p>
</body>
More information about the svn-doc-head
mailing list