summaryrefslogtreecommitdiff
path: root/en/hardware/buying-hardware.xml
diff options
context:
space:
mode:
authorKarsten Merker <merker@debian.org>2012-09-05 18:43:36 +0000
committerKarsten Merker <merker@debian.org>2012-09-05 18:43:36 +0000
commita6cc6d853ac598900733d41a82f3e6eaada86433 (patch)
treeae9f293a4efaea163971109be60a93bebb3ad69d /en/hardware/buying-hardware.xml
parentf37b7f4a7c08882439ff6eab0d2682c6b0c9fcc2 (diff)
downloadinstallation-guide-a6cc6d853ac598900733d41a82f3e6eaada86433.zip
Installation-guide cleanup
removal/rework of outdated parts (chapters 1 and 2, parts of chapter 3)
Diffstat (limited to 'en/hardware/buying-hardware.xml')
-rw-r--r--en/hardware/buying-hardware.xml74
1 files changed, 32 insertions, 42 deletions
diff --git a/en/hardware/buying-hardware.xml b/en/hardware/buying-hardware.xml
index 4995508a1..48c20e4c7 100644
--- a/en/hardware/buying-hardware.xml
+++ b/en/hardware/buying-hardware.xml
@@ -41,58 +41,48 @@ releasing the &arch-kernel; source code.
</para><para>
Since we haven't been granted access to the documentation on these
-devices, they simply won't work under &arch-kernel;. You can help by asking
-the manufacturers of such hardware to release the documentation. If
-enough people ask, they will realize that the free software community
-is an important market.
+devices, they simply won't work under &arch-kernel;.
-</para>
-</sect2>
+</para><para>
+In many cases there are standards (or at least some de-facto standards)
+describing how an operating system and its device drivers communicate with a
+certain class of devices. All devices which comply to such a
+(de-facto-)standard can be used with a single generic device driver and no
+device-specific drivers are required. With some kinds of hardware (e.g.
+USB "Human Interface Devices", i.e. keyboards, mice, etc., and USB mass
+storage devices like USB flash disks and memory card readers) this works
+very well and practically every device sold in the market is
+standards-compliant.
- <sect2 arch="any-x86"><title>Windows-specific Hardware</title>
-<para>
+</para><para>
-A disturbing trend is the proliferation of Windows-specific modems and
-printers. In some cases these are specially designed to be operated by
-the Microsoft Windows operating system and bear the legend <quote>WinModem</quote>
-or <quote>Made especially for Windows-based computers</quote>. This
-is generally done by removing the embedded processors of the hardware
-and shifting the work they do over to a Windows driver that is run by
-your computer's main CPU. This strategy makes the hardware less
-expensive, but the savings are often <emphasis>not</emphasis> passed on to the
-user and this hardware may even be more expensive than equivalent
-devices that retain their embedded intelligence.
+In other fields, among them e.g. printers, this is unfortunately not the
+case. While there are many printers which can be addressed via a small set
+of (de-facto-)standard control languages and therefore can be made to work
+without problems in any operating system, there are quite a few models which
+only understand proprietary control commands and either cannot be used at
+all on free operating systems or can only be used with a vendor-supplied
+closed-source driver.
</para><para>
-You should avoid Windows-specific hardware for two reasons. The first
-is that the manufacturers do not generally make the resources
-available to write a &arch-kernel; driver. Generally, the hardware and
-software interface to the device is proprietary, and documentation is
-not available without a non-disclosure agreement, if it is available
-at all. This precludes it being used for free software, since free
-software writers disclose the source code of their programs. The
-second reason is that when devices like these have had their embedded
-processors removed, the operating system must perform the work of the
-embedded processors, often at <emphasis>real-time</emphasis> priority,
-and thus the CPU is not available to run your programs while it is
-driving these devices. Since the typical Windows user does not
-multi-process as intensively as a &arch-kernel; user, the manufacturers hope
-that the Windows user simply won't notice the burden this hardware
-places on their CPU. However, any multi-processing operating system,
-even Windows 2000 or XP, suffers from degraded performance when
-peripheral manufacturers skimp on the embedded processing power of
-their hardware.
+Even if there is a vendor-provided closed-source driver for such hardware
+when purchasing the device, the practical lifespan of the device is limited
+by driver availability. Nowadays product cycles have become short and it is
+not uncommon that a short time after a consumer device has ceased
+production, no driver updates get made available any more by the
+manufacturer. If the old closed-source driver does not work anymore after a
+system update, an otherwise perfectly working device becomes unusable due to
+lacking driver support and there is nothing that can be done in this case.
+You should therefore avoid buying closed hardware in the first place,
+regardless of the operating system you want to use it with.
</para><para>
-You can help improve this situation by encouraging these manufacturers
-to release the documentation and other resources necessary for us to
-program their hardware, but the best strategy is simply to avoid this
-sort of hardware<phrase arch="linux-any"> until it is listed as working
-in the <ulink url="&url-hardware-howto;">Linux Hardware Compatibility
-HOWTO</ulink></phrase>.
+You can help improve this situation by encouraging manufacturers of closed
+hardware to release the documentation and other resources necessary for us
+to provide free drivers for their hardware.
</para>
</sect2>