Take Adaptec for instance. Before the 3.7 release we disabled support
for the
-aac(4)
+aac(4)
Adaptec RAID driver because negotiations with the Adaptec had failed.
They refused to give us documentation. Without documentation, support
for their controller had always been poor. The driver had bugs (which
@@ -2727,7 +2727,7 @@
ever) we will get around to writing that support for Adaptec RAID
controllers now. And Adaptec has gone and bought ICP Vortex, which
may mean we can never get documentation for the
-gdt(4)
+gdt(4)
controllers.
The "Open Source Friendly liar" IBM owns Mylex, and Mylex has told us we
would not get documentation, either.
@@ -2866,17 +2866,17 @@
Want to help us? Avoid
-Intel Centrino,
+Intel Centrino,
Broadcom, TI, or Connexant PrismGT chipsets.
Heck, avoid buying even regular
-old pre-G Prism products,
+old pre-G Prism products,
to send a message.
If you can, buy 802.11 products using chips by
-Realtek,
-Ralink,
-Atmel,
-ADMTek,
-Atheros.
+Realtek,
+Ralink,
+Atmel,
+ADMTek,
+Atheros.
Our manual pages attempt to explain which vendors (ie. D-Link) box
which chipsets into which product.
@@ -3164,12 +3164,12 @@
Cisco lawyers and IETF policy.
We've been working a few years now on our packet filtering software -pf(4) +pf(4) and it became time to add failover. We want to be able to set up pf firewalls side by side, and exchange the stateful information between them, so that in case of failure another could take over 'keep state' sessions. Our -pfsync(4) +pfsync(4) protocol solves this problem. However, on both sides of the firewall, it is also necessary to have all the regular hosts not see a network failure. The only reliable way to do this is for both @@ -3242,9 +3242,9 @@ it to use cryptography.
The combination of -pf(4), -pfsync(4), and -carp(4) +pf(4), +pfsync(4), and +carp(4) has permitted us to build highly redundant firewalls. To date, we have built a few networks that include as many as 4 firewalls, all running random reboot cycles. As long as one firewall is alive in a