Interaction with system hardware
Daniel Pead
"In the UNIX world, people tend to interpret `non-technical user' as meaning someone who's only ever written one device driver."
Introduction
There are many computer architectures available. Most of them have a cleaner design and stronger characteristics than the
On a side note, as the quote from the "Autodesk file" by John Walker in the 80s, about the PC predecessor would say:
Coming to Terms with the 8086
It's become clear that the plague called the 8086 architecture has sufficiently entrenched itself that it's not going
to go away. For the last month or more, Mike Riddle, John Walker, Keith Marcelius, and Greg Lutz have been
bashing their collective heads against it. The following is collected information on this unfortunate machine.
I think we'd be wise to diffuse our 8086 knowledge among as many people as possible. The main reference for
the 8086 is a book called, imaginatively enough, The 8086 Book published by Osborne. This is the architecture
and instruction set reference, but does not give sufficient information to write assembly code (of which, more
later). However, it is the starting point to understand the machine. AI will reimburse the cost of your buying
this book, which is available at computer and electronic stores.
I have never encountered a machine so hard to understand, one where the most basic decisions in designing
a program are made so unnecessarily difficult, where the memory architecture seems deliberately designed to
obstruct the programmer, where the instruction set seems contrived to induce the maximum confusion, and
where the assembler is so bizarre and baroque that once you've decided what bits you want in memory you
can't figure out how to get the assembler to put them there.
This list of other general-purpose architectures (besides the
Intel-compatible)
would include Motorola 68000 (
So, given different architectures which are not binary-compatible (that is, where programs are not compatible across The key to the problem is namely
Let's see what would you have to do if you had a completely usable but new architecture, for which no high-level kernels and application programs were developed yet.
The first step in getting software run on our hypothetic architecture would come down to porting an existing Operating System
Once we'd get the above done, we'd have to get the build-chain (development tools) supported for a platform, or we wouldn't be able to get any user applications running. (In reality, this step would probably be more to the top of the list.) And once we'd have all that done, there would still be more work waiting for individual software programs. We'd have to try compiling them (converting to a binary, machine-runnable form) on new hardware. Depending on how much portability issues the original authors addressed themselves, this could be an easy, difficult or impossible task. Sometimes doing a complete rewrite (and avoding other design mistakes the original authors made) is easier than insisting on code base that was written by poor programmers, or at time when no standardized portability techniques were widespread.
To sum up, there's much more to programming that just the physical position of sitting in front of a computer and punching letters.
(Even though we all probably know a person or two who seem to be using their existence to prove the contrary).
When you get to understand the basics of computer hardware, Unix will start looking like the only reasonable and natural extension to hardware, and its concepts and design elements will be easy to understand.
Operating system kernels
As we've mentioned in the Introduction, a basic software element of an usable, general purpose computer is the kernel. Among the most widely known free kernels today is Linus' USENET post from October 5, 1991 in the Google Groups' 20 Year Usenet Timeline. Another excellent site, ComputerHope, maintains a record of Linus saying
Hello everybody out there using minix - I'm doing a (free) operating
system (just a hobby, won't be big and professional like gnu) for
386(486) AT clones.
Nowadays, many (or all) Free Software bundles sold by various companies are commonly called
A variety and freedom of choice always existed in the Free Software applications arena. For example, if there were 10 usable (not even popular, just usable) music player or web server programs in existence, chances are you'd find all of them already packaged and waiting for installation in your Debian package archive (and probably in majority of the
Now you can understand why the authoritative people insist on calling distributions GNU/Linux instead of just
I hope
Now, fitting the section title and this introduction together, we can reach the expected conclusion — since Debian is aiming to be an universal Operating System, it offers the choice of kernels!
Yes, that's right! Besides the most widely known Debian GNU/Linux, there are also &LNK10;, &LNK10-1; and &LNK11-1; available. &LNK11-1; (visit &LNK11;) microkernel itself is still in development and not ready for use in production, but NetBSD and FreeBSD are mature kernels, and the usability of their Debian ports should increase rapidly. (Currently the main issue with *BSD kernels and Debian is getting the kernels play along with GNU userland instead of the expected BSD). Just for the record, Linux 2.6 kernel series seems to outperform the rival cavalry on just about every test performed (at least according to Gregory McGarry and Felix von Leitner), but the BSD people are coming up with no-less smarter ideas and valuable features.
In practice, this means that you'll be able to choose any hardware platform (machine type and architecture) and any of the supported kernels that best match your exact needs, while from the user perspective it will always be Debian with no visible and incompatible differences!
Kernel drivers
Free Software kernels come with all supported drivers already included in the kernel source packages. Loading or unloading a driver for any piece of hardware is an instant, one-command action.
Free Software drivers are often better than their proprietary counterparts (paradoxically, since the proprietary drivers were made by the hardware manufacturers themselves). The only notable exceptions to this rule happen when the manufacturers keep their hardware internals
The situation today looks MUCH better than it looked 8 years ago when I first wrote this. Today Linux
works on just about everything, it supports accelerated graphics and DRI (Direct Rendering Infrastructure)
on all major graphics cards (nVidia and AMD/ATI), and the drivers for those cards come from the
manufacturers. Not all of them are completely open about it, though, but shiny examples include companies
Atheros (network cards) and ATI (after takeover by AMD) who directly talk to the Free Software developers
and have opened their specifications and drivers. And good times are yet ahead! (On a side note, for
a completely open graphics card design and drivers, although not usable for 3D yet,
see OpenGraphics.)
So in general, when the hardware is supported, the whole process of integrating it into your system consists of loading appropriate kernel or user-space drivers, performing any necessary configuration tasks, and making sure the hardware configures itself automatically on each system boot.
To save you the trouble, we will present an introduction to the general hardware identification techniques, then provide a series of sections describing different kinds of hardware and giving actual instructions how to properly integrate them in your system.
Note that this chapter will be losing on importance, as new Debian installers perform the autodetection well, and nowadays there are generally
Hardware identification techniques
(As mentioned, this section is losing on practical relevance as almost all hardware is nowadays
auto-detected, auto-configured and everything else auto- that you can imagine. But it's still how
things work, so it's a great source of knowledge that would today be considered "old school").
We are going to provide the general techniques for identifying system hardware here, because you'll use them in all of the following hardware sections.
In general, to identify system hardware, you run less /var/log/dmesg. That will display most general and low-level information, such as system and processor type, available memory, attached hard disks, etc. This is all pretty nice, but does not help you in identifying
Since (as we just said above) the basic components such as mainboards, processors and hard disks are recognized without special setup on your part, you'll be interested in identifying the rest of the hardware — that would mostly be "attachable" devices such as PCI and AGP cards, serial or parallel adapters and USB gadgets. To do so, run
Note that the ID strings returned by above utilities will be your starting point in finding out the name (or names) of the drivers that support your specific devices. Free software drivers usually target
Driver name identification techniques
So when you find some hardware ID strings, you'll want to search for the appropriate driver names. There are few approaches to this; you can run
Just, don't feel lucky if you manage to load the
If you don't get lucky with http://www.google.com/linux. In the results returned, you should learn the name of the driver to support the specific hardware. The ID string I used in this example belongs to a network card, and directly the first result returned by Google would tell you the appropriate NIC (network card) driver name is
Finally, since the drivers are kept on your hard disk as normal files, the third way to learn the correct driver name includes visiting the modules directory and doing some manual file cd /lib/modules/`uname -r`/. Once there, try using
Note on drivers loading automatically on each boot
If you load the driver using /etc/modules file. In effect, this would make the driver load on each machine boot.
If you don't succeed with sudo modprobe . You'll also want to add the driver name to /etc/modules to make it load on every boot; you can do that by running echo .
On systems of today, we have a mechanism called "udev" which is configured by files in
/etc/udev/. For example, once the network cards are
(auto)detected, their names become persistent since udev updates file
/etc/udev/rules.d/70-persistent-net.rules. So that's the place to look for
if you want to force or change your network card name assignments. Find more introductory information
about "udev" in /usr/share/doc/udev/README.Debian.gz.
Ok, those few simple hints are enough that we can move on to practical hardware setup scenarios.
Common hardware setup and performance; guidelines and practical examples
Network Interfaces (LAN)
The machine picked for this example had two PCI network cards. Let's see how we could detect and recognize both. We will use the
$ lspci | grep Ethernet
00:0f.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8139 (rev 10)
00:12.0 Ethernet controller: VIA Technologies, Inc. Ethernet Controller (rev 74)
Or a similar system might show:
$ lspci | grep Ethernet
0000:00:0f.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8139/8139C/8139C+ (rev 10)
0000:00:12.0 Ethernet controller: VIA Technologies, Inc. VT6102 [Rhine-II] (rev 74)
Today, popular low-cost PC network cards probably use one of modprobe for all of those driver module names above and we'd actually get lucky, but let's be some more clever than that; let's show how we could be successful using the identification tips we gave in the previous section.
If we fired up kernel/drivers/net section, we'd find both "
If we opened the Web browser and searched for the identification string "http://www.google.com/linux, the first result would hint
And if we did cd /lib/modules/`uname -r`/ and
It's important to know that, unlike most things in Unix, network interfaces are not represented by files in the /dev/ directory (although there exists a patch for the Linux kernel which enables that); in Linux, the interfaces are simply given "virtual" names such as eth0, eth1 etc. The tool to manage network interfaces is traditionally called
If you ran /etc/network/interfaces, and it defines the usual things, such as network interface IP addresses, netmasks and gateways. The interfaces5 manual page is pretty informative, but we'll provide two most common examples; simple static IP and dynamic IP (DHCP) setups. Our first interface, eth0 will be given a static IP; the other, eth1 will have a dynamic IP.
/etc/network/interfaces
#
# Standard stuff
auto lo eth0 eth1
iface lo inet loopback
#
# Eth0: static
iface eth0 inet static
address 192.168.7.3
netmask 255.255.255.0
broadcast 192.168.7.255
gateway 192.168.7.1
#
# Eth1: DHCP
iface eth1 inet dhcp
Configuring that file and running sudo /etc/init.d/networking restart should set you on stage.
In some cases you might want to change the network card's ethernet ("hardware") address. This is posible with the
ifconfig eth0 down
ifconfig eth0 hw ether BA:BE:BE:EF:D0:0D
ifconfig eth0 up
Hard disks
As we've mentioned already, hard disks are recognized and work without any special setup. (Well, not really, they too are an option in the kernel configuration, but definitely all of the usual setups include the disk and filesystem drivers out of the box).
One thing that you can do, however, is check the performace of your disks (cached and raw read performance). Install hdparm, then run sudo hdparm /dev/sda to get a feeling of what disks are about. (Note: old ATA disks on older Linux systems were called "hda". The distinction between "hda" and "sda" is a leftover from times when "hda" were strictly ATA and "sda" were strictly SCSI devices).
$ sudo hdparm /dev/sda
/dev/sda:
multcount = 16 (on)
IO_support = 1 (32-bit)
unmaskirq = 1 (on)
using_dma = 1 (on)
keepsettings = 0 (off)
readonly = 0 (off)
readahead = 8 (on)
geometry = 1823/255/63, sectors = 29297520, start = 0
To actually measure the throughput, first make sure the system isn't busy with anything that could influence the outcome (top should report only 1 process running — and that being itself), then run sync three times (to sync, or clean memory buffers by synchronizing to the disk now), and finally, run sudo hdparm -tT /dev/.
In /dev/, stands for disk type (which is s for SCSI, and h for IDE devices), and stands for "number" which is actually letters of the alphabet, starting at a. If you had an IDE disk, it would most probably be /dev/sda. Actually, it would probably be nice to explain this "numbering" scheme properly: on typical PC motherboards, there are two IDE disk connectors (primary and secondary), each accepting a 40- or 80-wire cable with two connectors (master and slave) for peripherial devices. Altogether, this makes a total of 4 disks/CD-Roms that you can attach, and according to their position, they're assigned letters /dev/sda won't do you much good; run
Anyway, speaking of hdparm -tT, here's a sample output:
$ sync; sync; sync; sudo hdparm -tT /dev/hda
/dev/hda:
Timing buffer-cache reads: 848 MB in 2.00 seconds = 424.00 MB/sec
Timing buffered disk reads: 90 MB in 3.01 seconds = 29.90 MB/sec
Interesting, though, how the statistics looked back in the day. Here's
a modern system from February 2010:
$ sync; sync; sync; sudo hdparm -tT /dev/sdc
/dev/sdc:
Timing cached reads: 13570 MB in 2.00 seconds = 6794.06 MB/sec
Timing buffered disk reads: 278 MB in 3.02 seconds = 92.08 MB/sec
Now, what can we see here? Cache performance test measures the raw throughput achieveable from system RAM.
Buffered test eliminates the cache and directly measures disk's ability to read the magnetic medium. For a PC (and — Ultra ATA — 80-column cable), 30 MB/s was nice (older disks were in 15 - 25 MB/s range, but now we managed to get in the 100 MB range per disk.
One traditional SCSI/Unix disk manufacturer and popular SATA manufacturer today is &LNK12;, although
the quality of their SATA disks at least has dropped enormously. Altogether, I've had the best
experience (quality-wise) with Western Digital disks.
If your disk throughput is much worse than this, chances are that DMA (Direct Memory Access) is not enabled; check that first with sudo hdparm /dev/sda | grep dma. If it's disabled, run sudo hdparm -d1 /dev/sda and repeat the test.
In any case, if you figure out any hdparm settings that boost your disk performance, you'll want to add -k1K1 to the options (to preserve settings over disk reset — something that can happen during runtime), and you'll want to save the whole line in /etc/bootmisc.sh or somewhere, to have it run on each boot.
If you have two disks, putting them on separate cables (in case they're not SATA which is one disk
per cable) can further improve transfer rates.
Just don't rush and reposition the disk to which you installed &DEB;. If you do so, the device filename will change (from say, /dev/sda to /dev/hdc) and your system will not boot properly any more! Don't do this until you read this Guide and learn how to use rescue CDs.
Actually, today you can even change disk order and partitions since most of the things target partitions
by UUIDs (Unique Identifiers) and not physical position on the bus. Thumbs up for modern developments!
CD/DVD-Roms
Like hard disks, PC CD-Roms typically just work out of the box. There are some commands, however, that could be used to tune their exact behavior.
We could just say that the Linux kernel can drive CD-Roms in either standard IDE/ATAPI mode, or SCSI emulation. SCSI emulation was primarily used to allow
Of the commands you can use with CD-Rom drives, there's
Finally, the standard, low-level CD-burning application is called wodim -vv -eject FILE_NAME.iso! In case you need to create the .iso first, copy all files to one directory (the easiest, not to search for them), and then produce the .iso with genisoimage -T -U -R -l -o mycd.iso DIR_NAME.
Graphics
Graphic cards arena is pretty interesting. If you know something about the evolution of PC graphics cards, you know there were a little myriad of graphic "modes" invented, each with its pros and cons, and each with a different set of graphic cards that supported it. Those "modes" have surely put a certain burden on backward-compatibility; even modern PC graphic cards like &ATI; or &NVIDIA; that probably never see a console (terminal) mode still support dozens or even hundreds of various text modes.
One of those modes is the standard character terminal mode, so you won't have any problems getting to the console (text mode) on PCs.
One other supported standard is the VGA mode which allows a resolution of 640x480 pixels in 256 colors. (Just by the way, it means the screen alone took 640x480x8 bits — or about 307 kilobytes — to fit in memory).
Then there's VESA 2.0 which is supported by SVGATextMode (and which is quite a pain to set up) so we won't discuss it.
And there's VESA 2.0 in framebuffer mode. Instead of using the card's specific instruction set, you can initialize and use the card in framebuffer/VESA mode. This was quite attractive before, when it was easier to fire up the framebuffer mode than wait for months (should I say years?) before &XFREE86; (X Window System implementation) card-specific drivers became available. VESA 2.0 framebuffers allowed for good resolutions, but they too were limited to 256 colors. Another big drawback was a completely unaccelerated display which flickered even when you were moving a 2D window around the screen. Nowadays the Linux kernel does support the hardware framebuffer acceleration for most popular card groups.
Framebuffers are also a comfortable option for graphic cards that do not support native console mode (such as &APPLE;'s) or were using framebuffer by design, such as some from &SUN;.
The X Window implementation used today on Linux systems is X.org.
You install it and it just works; it autodetects everything and doesn't even
need the config file (/etc/X11/xorg.conf).
And if you have an nVidia or ATI card, a program called
Modems
Telephone-line modems (of historical interest?)
First of all, we must say that there are two main types of modems: real hardware modems, and handicapped modems called Winmodems.
"Hardware modems" are the usual, full-featured modems. They are sometimes also called Rockwell or Hayes-compatible modems, they are attached to serial ports, and (being Hayes-compatible) they all support the standard &LNK13;. All external modems that you attach to the computer via serial cable are "hardware modems". Of internal modems that you plug into an ISA or PCI slot on the mainboard, usually only old ones (prior to year 1998 or even older) are "hardware modems".
"Winmodems", on the other hand, are once again a disastrous invention from the PC world; basically they are modems with one $5 (five dollar, at the time of invention!) chip removed, whose tasks then need to be performed by the main system processor. Winmodems are only sold as internal (and that PCI) cards, and have practically flooded the post-millenium modem market; at most "modern" computer shops, they don't even know that Winmodem is not the only type of "modem". Winmodems do not have a single technical quality or a bright idea — it's quite the opposite. Such modems need special drivers to work at all, and even then you are lucky if they support some degenerated "AT" command set. Needless to say, Winmodems are a major annoyance because all the drivers are proprietary and closed-source. The linmodems.org site is trying hard to help Winmodem owners, but it's really not worth it. Winmodems are a disgusting piece of "hardware", they smell bad, and you are better off passing them to the next lucky owner. If you can buy a real modem yourself, you're good; if you can persuade someone into swapping a real modem for your Winmodem, you're really good.
In the meantime, since originally writing the Winmodems section, the manufacturers seem to have standardized on one or two chips, and basically it is possible to get Winmodems working quite comfortably. They are, of course, as crappy as they've always been, but at least the cost of set up is no longer higher than of winmodem itself.
If you will be interested in connecting to ISPs, you will use the PPP protocol. If you'll want to use the modem in "terminal" mode, then the infamous
If you are interested in PPP connections, you simply need to run ISP1, then running /var/log/ppp.log, we redirected messages to that file earlier in the Guide when we configured the syslog daemon.
Finally, it's worth noting that /etc/ppp/peers/ and /etc/chatscripts/ (and, well, /etc/ppp/ if your ISP uses PAP or CHAP authentication method). For completness, we include a sample working configuration for a typical dial-up ISP connection.
/etc/ppp/peers/provider
Notice that the string should be replaced with the username you use to connect to the ISP. File /dev/ttyS represents the first COM port or, in DOS parlance, COM1 (for serial port 2, you would use /dev/ttyS1, and so on). Note that in case of internal modems, the ports would probably be /dev/ttyS2 or /dev/ttyS3; your computer does have 4 serial ports even if only one or two are available on external connectors.
# This optionfile was generated by pppconfig 2.0.10.
#
#
hide-password
noauth
connect "/usr/sbin/chat -v -f /etc/chatscripts/provider"
debug
/dev/ttyS
/etc/chatscripts/provider
Notice that the number should be replaced with your ISP number. Also, the string ATx3m1 is a setting you should use in most european countries — it instructs the modem not to wait for dial-tone (this can be set from the Provider -> Advanced -> Modeminit).
# This chatfile was generated by pppconfig 2.0.10.
# Please do not delete any of the comments. Pppconfig needs them.
#
# ispauth PAP
# abortstring
ABORT BUSY ABORT 'NO CARRIER' ABORT VOICE ABORT 'NO DIALTONE' ABORT 'NO DIAL TONE' ABORT 'NO ANSWER' ABORT DELAYED
# modeminit
'' ATx3m1
# ispnumber
OK-AT-OK ATDT
/etc/ppp/pap-secrets
and need to be replaced with the actual values you use for authentication with the ISP, of course.
(none) * password
Mentioned Debian PPP tools are definitely superior to any "ad-hoc" programs that you would employ, but wvdial is worth mentioning because it can do a lot of auto-detection (basically, all you need to know to use wvdial is your ISP phone number, user name and password). After installation, run sudo wvdialconf /etc/wvdial.conf to create the configuration file. Then, running wvdial should establish the connection. As usual, a working /etc/wvdial.conf is provided for completeness.
/etc/wvdial.conf
, and need to be replaced with the actual values you use for authentication with the ISP, of course.
/dev/modem is a symbolic link to the modem device (wvdial should detect it all). If it does not, and /dev/ttyS0 were the real port (modem attached to the first serial port, or COM1 in DOS parlance), you'd create the symlink manually by running sudo ln -sf /dev/ttyS0 /dev/modem.
Additionally, the l0m0 part of the "init string" makes the modem speaker quiet during both dialling and the duration of the connection.
[Dialer Defaults]
Modem = /dev/modem
Baud = 115200
Init1 = ATZ
Init2 = ATx3l0m0 S0=0
#Init3 = ATI 5
Phone =
If
Cable modems
Cable modems first need to be connected to the computer by an ethernet (LAN) or USB cable.
If you're using the cable modem to connect to your ISP, then the ISP probably provided DHCP server on their side. In other words, you can simply define the interface to pick up the configuration from a DHCP server. Your /etc/network/interfaces file should simply look like this:
auto eth0
iface eth0 inet dhcp
It's useful to know that ISPs match your ethernet card hardware address before giving you the connection details and finally access. But sometimes you're forced to change your hardware ethernet address; for example, your card might get destroyed by a lightning, or your machine breaks down and you need to replace the card or temporarily move the modem to another computer. Calling the ISP to change your hardware address is sometimes not an option — they're suspicious when you call, or it takes a while for their changes to take effect. Fortunately however, in Linux, it is possible to manually change the hardware address of your network card. You can't write the address to the card's memory permanently though (you need to repeat it on each reboot), but that doesn't affect its usefulness. For a real example, please see .
ADSL modems
ADSL modems also arrive in ethernet or USB cable versions.
ADSL modems usually work using the PPPoE (PPP over Ethernet) protocol. To make your life real easy, install pppoe,
pppoeconf and pppstatus packages.
If your modem is connected and turned on, pppoe -A should find at least one PPPoE provider "on air". This is very simple and should be done at the beginning to minimize problems with pppoeconf. If you see no providers listed by pppoe -A, then something's wrong. In newer Debian installations,
In the next step, you should read /usr/share/doc/pppoeconf/ to read a well-written ADSL introduction and practical HOW-TO. Running pppoeconf and following the instructions from the mentioned documentation file should be enough that you configure your ADSL modem. Once you do it, you can connect using
Mice (console)
Besides in the X Window System (which will be covered separately), you can also use mouse in your text consoles. That is, by the way, very convenient, because you can simply select text with the LMB (Left Mouse Button) and paste with the MMB (Middle Mouse Button).
The traditional program handling console mice is called gpm, run sudo gpmconfig to configure it. The device file to use is /dev/psaux for PS/2 port mice, /dev/ttyS for serial, and /dev/usb/mouse for USB (where is a number dependent on the port assigned, starting at 0). Of protocol types, many exist and many are supported; on PCs, the "auto-sensing" autops2 is the best (and default) choice. Repeat protocol is a convenient way to let gpm handle mice, and "repeat" events on file /dev/gpmdata so that other applications (such as X Window System) could use the same events. This, however, is not necessary since nowadays they can both open the mouse file directly.
You can start, stop or restart the gpm daemon by invoking, for example, sudo /etc/init.d/gpm restart.
And again, gpmconfig does no magic, it simply modifies /etc/gpm.conf which I provide for completeness.
/etc/gpm.conf
# /etc/gpm.conf - configuration file for gpm(1)
#
# If mouse response seems to be to slow, try using
# responsiveness=15. append can contain any random arguments to be
# appended to the commandline.
#
# If you edit this file by hand, please be aware it is sourced by
# /etc/init.d/gpm and thus all shell meta characters must be
# protected from evaluation (i.e. by quoting them).
#
# This file is used by /etc/init.d/gpm and can be modified by
# /usr/sbin/gpmconfig.
#
# PS/2 Mouse example
device=/dev/psaux
responsiveness=
repeat_type=
type=autops2
append=""
sample_rate=
Audio cards
The Linux audio drivers story is quite interesting. Traditionally, Linux used the Open Sound System (OSS) architecture. It was written by guys who ran their own company and wanted to make money on audio drivers, and only contributed old or uncommon drivers to the Linux kernel tree.
This was, as you might guess, pretty unfortunate, so the folks got together to rewrite the audio system and get rid of the hog. The result was ALSA - Advanced Linux Sound Architecture. ALSA is the default sound system in the Linux kernel 2.6 series.
Digital cameras
Some of the digital cameras were (or still are) supported directly by the Linux kernel, allowing you to mount their memory cards as the usual disks.
One other, and more common way, is to use user-space drivers for the cameras. The GNU
gphoto2 --port usb: --get-all-files --camera "Kodak DC3400"
Another common trick these days is to plug the memory card in some universal reader device and then mount it as a standard disk. This way it's also possible to upload files to the card even if the camera itself doesn't support uploading (so you can't use
Printers
Traditionally, printing in Unix was done by the BSD lp or lpr stand for
Line Printer, although printing is all but limited
to line/matrix printers, of course). Afterwards, /etc/printcap, describing printers' capabilities.
Probably the three most relevant printing-related commands are
With PostScript printers it's quite easy. With PC printers, as always
— the things are a little different. To overcome printing problems,
(primarily on GNU/Linux PCs, but on other Unices as well), CUPS —
Common Unix Printing System — was developed, and it's what we are
going to use. Let's first install it:
$ sudo apt-get install cupsys cupsys-{bsd,client} foomatic-db foomatic-filters-ppds
By default, CUPS listens on &LNK14;. Visit the page with your web browser, and you'll be able to perform printer administration tasks from quite an usable web GUI.
The username and password you're asked for are "root", and root's password.
For details on supported printers and the drivers you can use, surely visit &LNK15;.
CUPS can also be configured directly, just using config files in
/etc/, but that is out of the scope
of this Guide.
Here's what I wrote years ago in this section: "Printer setup is still unnecessarily too hard to get right, but hopefully things will get better." Well, things have surely changed for the better. Almost all printers are nowadays recognized by Cups (auto-detection finds them and the drivers exist). What's more, if you're using a modern desktop, such as &GNOME;, &XFCE; or &KDE;, or a more "out of the box" oriented flavor of Debian, such as Ubuntu, there's a great chance the printer will be automatically recognized and installed with the appropriate driver