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

- Many minor fixes from Warren -- thanks!

Browse source 
Submitted by:	wblock
This commit is contained in:
Gabor Pali 2013-07-09 13:22:59 +00:00
parent 8e4ae0d0a8
commit 65d4712fe7
Notes: svn2git 2020-12-08 03:00:23 +00:00 
svn path=/head/; revision=42218
1 changed files with 31 additions and 31 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

62
en_US.ISO8859-1/htdocs/news/status/report-2013-04-2013-06.xml
View file

@ -1238,7 +1238,7 @@
<task>Look into replacements for HAL. HAL is used for
hot-plugging of devices, but it has been long abandoned by
Linux. A replacement, perhaps build on top of <tt>devd(8)</tt>,
Linux. A replacement, perhaps built on top of <tt>devd(8)</tt>,
would be nice to have. This work should be coordinated with the
&os; GNOME and KDE teams.</task>
</help>
@ -1272,26 +1272,26 @@
</links>
<body>
<p>We are proud to announce &os; Haskell Team has updated the
Haskell Platform to 2013.2.0.0, GHC to 7.6.3, as well as updated
existing ports to their latest stable versions. In this update,
we provided experimental support for LLVM-based code generation
(disabled by default) to Haskell ports. We also added number of
new ports, which brings their count in &os; Ports Collection to
402, and now Haskell ports play nicer with
<tt>portmaster(8)</tt>-based upgrades.</p>
<p>We are proud to announce that the &os; Haskell Team has updated
the Haskell Platform to 2013.2.0.0, GHC to 7.6.3, as well as
updated existing ports to their latest stable versions. In this
update, we provided experimental support for LLVM-based code
generation (disabled by default) to Haskell ports. We also
added a number of new ports, which brings their count in the
&os; Ports Collection to 402, and now Haskell ports play nicer
with <tt>portmaster(8)</tt>-based upgrades.</p>
<p>In cooperation with Konstantin Belousov and Dimitry Andric, we
have managed to unbreak build of GHC on 32-bit 10.x systems, so
we have packages for 10.x again. However, it turned out that
have managed to unbreak the build of GHC on 32-bit 10.x systems,
so we have packages for 10.x again. However, it turned out that
this bug (in thread signal delivery) can also affect the
building process for other platforms as well, which explains
some of the strange build breakages our users experienced in the
past.</p>
<p>We have also learned that there is an <a
<p>We have also learned that there is <a
href="http://www.haskell.org/pipermail/ghc-devs/2013-June/001506.html">ongoing work</a>
in GHC upstream which will allow us to provide support for
in the GHC upstream which will allow us to provide support for
building with Clang natively once GHC&nbsp;7.8 becomes part of
the Haskell Platform.</p>
</body>
@ -1350,8 +1350,8 @@
</links>
<body>
<p>There have been new utilities introduced in &os; base system:
<tt>bsdconfig(8)</tt> and <tt>sysrc(8)</tt>. The
<p>New utilities have been introduced in &os; base system:
<tt>bsdconfig(8)</tt> and <tt>sysrc(8)</tt>.
<tt>bsdconfig(8)</tt> is a replacement for the post-install
abilities of deprecated <tt>sysinstall(8)</tt>, while
<tt>sysrc(8)</tt> is a robust utility for managing
@ -1568,7 +1568,7 @@ functionality through <tt>pkg(8)</tt>.</task>
also a plan to implement two new modules for Casper. Casper is
a daemon to provide services for applications using Capsicum's
capability mode. Some experimentation with implementing two new
capability rights is in progress, so as porting one more program
capability rights is in progress, so is porting one more program
to use the existing features of the Capsicum framework.</p>
</body>
@ -1577,7 +1577,7 @@ functionality through <tt>pkg(8)</tt>.</task>
connect and listen on Unix domain socket.</task>
<task><tt>system.udp</tt> &mdash; a Casper module enabling
connect, listen, sending and receive UDP packages.</task>
connect, listen, send, and receive of UDP packets.</task>
<task>Implementing sandboxing for <tt>fetch(1)</tt>.</task>
@ -1622,13 +1622,13 @@ functionality through <tt>pkg(8)</tt>.</task>
</ol>
<p>The common parameters used on TCP sessions have changed quite a
bit since SYN cookies very invented some 17 years ago. Today we
have a lot more bandwidth which makes the use window scaling
bit since SYN cookies were invented some 17 years ago. Today we
have a lot more bandwidth which makes use of window scaling
almost mandatory. Also SACK has become standard as it makes
recovering from packet loss much more efficient.</p>
<p>The original SYN cookies method only stored an indexed MSS
values in the cookie. This obviously is not sufficient anymore
value in the cookie. This obviously is not sufficient any more
and breaks in the presence of WSCALE. WSCALE information is
only exchanged during SYN and SYN-ACK. If we cannot keep track
of it then we severely underestimate the available send or
@ -1636,28 +1636,28 @@ functionality through <tt>pkg(8)</tt>.</task>
scaling the window size information on the TCP segment header
would be even lower numerically.</p>
<p>A number of years back SYN cookies have been extended to store
the additional state in the TCP timestamp fields, if available
on a connection. It has been adopted by Linux as well. While
<p>A number of years back, SYN cookies were extended to store the
additional state in the TCP timestamp fields, if available on a
connection. It has been adopted by Linux as well. While
timestamps are common among the BSD, Linux and other Unix
systems, Windows never enabled them by default, thus they are
not present for the vast majority of clients seen on the
Internet.</p>
<p>The new improvement in this patch moves all necessary
information into the ISN again removing the need for timestamps.
Both the MSS and send WSCALE are stored in 3 bit indexed form
together with a single bit for SACK. While we cannot represent
all possible MSS and WSCALE values, both are 16 bit fields in
the TCP header, in only 3 bits each this, it turns out, is not
actually necessary.</p>
information into the ISN again, removing the need for
timestamps. Both the MSS and send WSCALE are stored in 3 bit
indexed form together with a single bit for SACK. While we
cannot represent all possible MSS and WSCALE values in only 3
bits each (both are 16-bit fields in the TCP header), it turns
out that is not actually necessary.</p>
<p>These improvements allow one to run with SYN cookies only on
Internet-facing servers. However while SYN cookies are
calculated and sent all the time, they are only used when the
syn cache overflows due to attacks or overload. In that cause
syn cache overflows due to attacks or overload. In that case
though, you can rest assured that no significant degradation in
TCP connection setup happens anymore and that even Windows
TCP connection setup happens any more and that even Windows
clients can make use of window scaling and SACK.</p>
</body>