diff options
author | Karsten Merker <merker@debian.org> | 2012-09-05 18:43:36 +0000 |
---|---|---|
committer | Karsten Merker <merker@debian.org> | 2012-09-05 18:43:36 +0000 |
commit | a6cc6d853ac598900733d41a82f3e6eaada86433 (patch) | |
tree | ae9f293a4efaea163971109be60a93bebb3ad69d /en/hardware/buying-hardware.xml | |
parent | f37b7f4a7c08882439ff6eab0d2682c6b0c9fcc2 (diff) | |
download | installation-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.xml | 74 |
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> |