1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
|
<!-- retain these comments for translator revision tracking -->
<!-- $Id$ -->
<sect1 arch="not-s390"><title>Purchasing Hardware Specifically for GNU/&arch-kernel;</title>
<para arch="linux-any">
There are several vendors, who ship systems with &debian; or other
distributions of GNU/Linux
<ulink url="&url-pre-installed;">pre-installed</ulink>. You might pay more
for the privilege, but it does buy a level of peace of mind, since you can
be sure that the hardware is well-supported by GNU/Linux.
</para><para arch="any-x86">
If you do have to buy a machine with Windows bundled, carefully read
the software license that comes with Windows; you may be able to
reject the license and obtain a rebate from your vendor. Searching
the Internet for <quote>windows refund</quote> may get you some useful
information to help with that.
</para><para>
Whether or not you are purchasing a system with &arch-kernel; bundled, or even
a used system, it is still important to check that your hardware is
supported by the &arch-kernel; kernel. Check if your hardware is listed in
the references found above. Let your salesperson (if any) know that
you're shopping for a &arch-kernel; system. Support &arch-kernel;-friendly hardware
vendors.
</para>
<sect2><title>Avoid Proprietary or Closed Hardware</title>
<para>
Some hardware manufacturers simply won't tell us how to write drivers
for their hardware. Others won't allow us access to the documentation
without a non-disclosure agreement that would prevent us from
releasing the driver's source code, which is one of the central
elements of free software.
Since we haven't been granted access to usable documentation on these
devices, they simply won't work under &arch-kernel;.
</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 <quote>Human Interface Devices</quote>, 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.
</para><para>
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 for which no usable
documentation is available and therefore either cannot be used at
all on free operating systems or can only be used with a vendor-supplied
closed-source driver.
</para><para>
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 manufacturers of closed
hardware to release the documentation and other resources necessary for us
to provide free drivers for their hardware.
</para>
</sect2>
</sect1>
|
