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

- Various fixes for the developer summit report

Browse source 
Submitted by:	pluknet, wblock
This commit is contained in:
Gabor Pali 2013-12-02 09:55:50 +00:00
parent 87cffcc66f
commit cadb3f1c51
Notes: svn2git 2020-12-08 03:00:23 +00:00 
svn path=/head/; revision=43271
1 changed files with 139 additions and 139 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

278
en_US.ISO8859-1/htdocs/news/status/report-2013-09-devsummit.xml
View file

@ -39,24 +39,23 @@ Report//EN" "http://www.FreeBSD.org/XML/share/xml/statusreport.dtd">
</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/share/xml/statusreport.dtd">
<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/share/xml/statusreport.dtd">
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/share/xml/statusreport.dtd">
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/share/xml/statusreport.dtd">
talked with Gavin Atkinson about removing really outdated
documentation from the <tt>doc</tt> tree, like the ones who are
still reflecting &os;&nbsp;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/share/xml/statusreport.dtd">
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/share/xml/statusreport.dtd">
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/share/xml/statusreport.dtd">
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&nbsp;10 was summarized. The PBI
<p>Finally, the plans for PC-BSD&nbsp;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/share/xml/statusreport.dtd">
</links>
<body>
<p>In the virtualization working group, Peter Grehan gave a usual
status report. In &os;&nbsp;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;&nbsp;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/share/xml/statusreport.dtd">
<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/share/xml/statusreport.dtd">
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/share/xml/statusreport.dtd">
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/share/xml/statusreport.dtd">
<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/share/xml/statusreport.dtd">
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/share/xml/statusreport.dtd">
<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/share/xml/statusreport.dtd">
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/share/xml/statusreport.dtd">
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/share/xml/statusreport.dtd">
common error is to have <tt>&gt;</tt> instead of <tt>&gt;=</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/share/xml/statusreport.dtd">
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;&nbsp;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/share/xml/statusreport.dtd">
</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/share/xml/statusreport.dtd">
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/share/xml/statusreport.dtd">
have support for a native toolchain to work in the QEMU-based
package building infrastructure. By &os;&nbsp;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/share/xml/statusreport.dtd">
&os;&nbsp;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
&mdash; currently there is a number technical roadblocks to
&mdash; 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 &mdash; 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/share/xml/statusreport.dtd">
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;&nbsp;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;&nbsp;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/share/xml/statusreport.dtd">
<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 &mdash; 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/share/xml/statusreport.dtd">
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/share/xml/statusreport.dtd">
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/share/xml/statusreport.dtd">
<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/share/xml/statusreport.dtd">
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/share/xml/statusreport.dtd">
<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/share/xml/statusreport.dtd">
<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/share/xml/statusreport.dtd">
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/share/xml/statusreport.dtd">
<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/share/xml/statusreport.dtd">
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>