Sometimes, buying a diskless linux computer will be cheaper than building!! Checkout the following commercial sites, which are selling diskless linux network-cards and diskless computers. These companies do mass production of Linux Diskless computers selling millions of units and thereby reducing the cost per unit. Each and every fortune 1000 companies in USA will be replacing the MS Windows PCs with diskless computers in near future as diskless linux computers can run both Linux and MS Windows 95 programs (via VMWare BIOS software). VMWare is NOT a emulator but has BIOS which allows you to install Windows 98/NT as guest OS to linux. You can use the 'xhost' command and DISPLAY environment from diskless node to run Windows95/Linux programs. See 'man xhost' on linux. You can also use Virtual Network Computing (VNC) to run Windows95/NT programs on linux diskless nodes. Get VNC from http://www.uk.research.att.com/vnc
Even if you buy diskless linux computer, you may be very much interested in reading this entire document.
Since Microsoft Windows 95/NT DOES NOT support diskless nodes, there is an intelligent work-around to overcome this short coming. Microsoft corporation will be surprised !!
Use the VMWare BIOS software with Linux which can host the Windows 95/98/NT. Linux will be the "host" OS and Windows 95/NT will be the "guest" OS. VMWare is NOT a emulator but has BIOS which allows you to install Windows 95/98/NT as the guest OS to linux. Install the VMWare on Linux server and than install Windows 95/NT on VMWare.
You can use the 'xhost' command and DISPLAY environment from any diskless node. See 'man xhost' on linux. At diskless node give -
export DISPLAY=server_hostname:0.0 where server_hostname is the name of the server machine. And start X-terminal with xterm
You can also use the VNC (Virtual Network Computing) Technology from the telecom giant AT & T. VNC is GPLed and is a free software. Using VNC you can run Windows 95/NT programs on diskless linux computer but actually running on remote Windows95/NT server. VNC is at
Diskless linux computer will become immensely popular and will be the product of this century and in the next century. The diskless linux computers will be very successful because of the availability of very high-speed network cards at very low prices. Today 100 Megabit per second (12.5 MB per sec transfer rate) network cards are common and in about 1 to 2 years 1000 MBit (125 MB per sec transfer rate) network cards will become very cheap and will be the standard.
In near future, Monitor manufacturers will place the CPU, NIC, RAM right inside the monitor to form a diskless computer!! This eliminates the diskless computer box and saves space. The monitor will have outlet for mouse, keyboard, network RJ45 and power supply.
The following are benefits of using diskless computers -
An overview to build diskless nodes is as follows:
LTSP is an open source code project to build diskless linux computers.
At LTSP site you will find RPM packages for Redhat Linux and packages for Debian Linux which will save you lots of time. The subsequent chapters given in this document are for academic purposes only, which you can read them if you have more time.
Visit the LTSP and related sites at :-
This chapter is written by Abhijit Dasgupta and is reproduced here from http://www.nnaf.net/~abhijit/eep. Abhijit's email : abhijit@ans.net
A photo of the burner is at - http://www.nnaf.net/~abhijit/pictures/eeprom-burner.jpg
This is an eeprom burner for the 2816/2864 type of eeproms. There are various designs available, but the main goal was to have something which
This one uses a handful of 74HCTxx logic chips all available at the local Radio Shack store! It uses the PC parallel port interface, and Abhijit wrote the driver code for Linux only, but it should be easy to modify it for other PC operating systems.
This was used to burn netboot PROMs for ethernet cards, which were used to make diskless linux boxes. See the netboot/etherboot packages for details of how to do that. You can also use it for building microcontroller systems with external ROM (e.g. 8031).
WARNING: It is easy to destroy the parallel port of your PC by connecting things to it. It is also possible to damage or destroy the whole PC, its attachments, peripherals, and people near it by improper connections and electrical accidents. USE EXTREME CAUTION.
Disclaimer: Use at your own risk. There is absolutely no warranty of any kind here.
The programmer can be built on a breadboard, but use a protoboard for a more permanent version. Use 0.1uF power-bus bypass capacitors generously. The 5V power source can be obtained from the PC itself, but be careful here.
Download the software from http://www.nnaf.net/~abhijit/eep/eeprom.tar.gz. To build the software, just cd to the src directory and type `make';
readrom ------- readrom will read a specified number of bytes from a 2816/2864 eeprom starting at a given offset, and send it to the standard output in either binary (raw) or ascii-hex listing format. Usage: readrom -b|-t offset size where -b output binary (raw) bytes -t output text (ascii-hex) listing offset start address of eeprom, 0..8191 size number of bytes to output, 0..8192 Examples: # read the contents of a 2864 in binary (raw) form and save it in a file: readrom -b 0 8192 > contents.bin # list 80 bytes starting at offset 32: readrom -t 32 80 writerom -------- writerom will read a given number of bytes from the standard input and write them into a 2816/2864 eeprom starting at a specified offset. writerom verifies the eeprom byte-by-byte as it writes into it. Usage: writerom offset size where offset start address of eeprom, 0..8191 size number of bytes to output, 0..8192 Example: # Write 8192 bytes from the file ne.lzrom into the eeprom: writerom 0 8192 < ne.lzrom
The schematic is in ascii, but a PostScript version which looks better is available from http://www.nnaf.net/~abhijit/eep/eeprom/schematic.ps
+-------+ +5-------|RST | +5---o o o J1 +-----------+ +5--o----|/CLR1 | 10K | | | | | |-----o--/VVV\-- +5 +----------|26 +5(NC) | +------+ | |1/2 123| | +----------->|27 NC(/WE) | 16 o-|/CS2 | | | |--||-+ | +--------->|23 /WE(A11)| | CS1|----o----|B1 | 100pF | | | | | | | /Q1|---------->---------o o o J2 | ZIF28 | | Y1|---------|/A1 | | | socket | | 138 | +-------+ _ 1/2 74HCT132 | | for | | | +5 --| \ __ | | 2816(2864)| | Y2|--------------------------| O--| \ | | | 8 o-|A2 | +-------+ |_/ | O-------------->|/OE | 7 o-|A1 Y4|--------------->|EN Y7|-----o-|_/ | | | 6 o-|A0 Y3|----+ +5-----|RST | | | | | | Y0|-+ | | Y6|--+ | | | | | /CS3| | | | 259 | | | | | | +------+ | | | Y4|--|--|-----------|------->|2 NC(A12) | | | | | Y3|--|--|-----------+ | | 5 o--->---|--|--|--------o--|D Y2|--|--|------------------->|A10 | 4 o--->---|--|--|------o-|--|A2 Y1|--|--|------------------->|A9 | 3 o--->---|--|--|----o-|-|--|A1 Y0|--|--|------------------->|A8 | 2 o--->---|--|--|--o-|-|-|--|A0 | | | | | | | | | | | | +-------+ | | +5------------|28 NC(+5) | | | | | | | | | | +5----/VVV\---|1 NC(RDY) | | | | | | | | +-------+ | | 1K | | | | | | | | | | Y7|--|--|------------o------>|A7 | | | +---------->|EN |--|--|-----------o|------>| | | | | | | | | |--|--|----------o||------>| | | | | | | | | 259 |--|--|---------o|||------>| | | | | | | | | |--|--|--------o||||------>| | | | | | | | | |--|--|-------o|||||------>| | | | | | | +--|D |--|--|------o||||||------>| | | | | | +----|A2 Y0|--|--|-----o|||||||------>|A0 | | | | +------|A1 | | | |||||||| | | | | +--------|A0 RST| | | |||||||| | ZIF28 | | | +-------+ | | +------------+ | for | | | | | | | data in | | 2816/64 | | | +5 | +-->|/OE | | | | | | | 574 | | | | +------------------------------->|CLK | | | | | | data out | | | | V +------------+ | | +----+ +------------+ |||||||| | | | | SEL | |||||||| | | | | B3|<----|||||||o------|D7 | 11 o---<-----------------------|Y3 B2|<----||||||o-------| | 12 o---<-----------------------|Y2 B1|<----|||||o--------| | 13 o---<-----------------------|Y1 157 B0|<----||||o---------| | 15 o---<-----------------------|Y0 A3|<----|||o----------| | | | A2|<----||o--- data---| | | | A1|<----|o---- bus ---| | | GND----|/OE A0|<----o-------------|D0 | +5--o--+ | +------------+ | | | | __ o---------------------------------------------->|/CE | 100K +-| \ | __ +-----------+ sw1 | | O-o-| \ 1/2 74HCT132 o-->o----|__/ | O---390ohm--+ | | +-|__/ | | --- 1uF | LED | --- +5--+ | | | | +---o----------------------------o- GND
Notes:
Below is the information about EPROM and various types of memory chips.
Here is the brief descriptions of memory chips and their types.
For a list of EPROM burner manufacturers visit the Yahoo site and go to economy->company->Hardware->Peripherals->Device programmers.
This chapter is written by Ken Yap ken.yap@acm.org and explains how to bootstrap your computer from a program stored in non-volatile memory without accessing your hard disk. It is an ideal technique for maintaining and configuring a farm of linux boxes.
Network booting is an old idea. The central idea is that the computer has some bootstrap code in non-volatile memory, e.g. a ROM chip, that will allow it to contact a server and obtain system files over a network link.
In order to boot over the network, the computer must get
Consider a diskless computer (DC) that has a network boot ROM. It may be one of several identical DCs. How can we distinguish this computer from others? There is one piece of information that is unique to that computer (actually its network adapter) and that is its Ethernet address. Every Ethernet adapter in the world has an unique 48 bit Ethernet address because every Ethernet hardware manufacturer has been assigned blocks of addresses. By convention these addresses are written as hex digits with colons separating each group of two digits, for example - 00:60:08:C7:A3:D8 .
The protocols used for obtaining an IP address, given an Ethernet address, are called Boot Protocol (BOOTP) and Dynamic Host Configuration Protocol (DHCP). DHCP is an evolution of BOOTP. In our discussion, unless otherwise stated, anything that applies to BOOTP also applies to DHCP. (Actually it's a small lie that BOOTP and DHCP only translate Ethernet addresses. In their foresight, the designers made provision for BOOTP and DHCP to work with any kind of hardware address. But Ethernet is what most people will be using.)
An example of a BOOTP exchange goes like this:
DC: Hello, my hardware address is 00:60:08:C7:A3:D8, please give me my IP address.
BOOTP server: (Looks up address in database.) Your name is aldebaran, your IP address is 192.168.1.100, your server is 192.168.1.1, the file you are supposed to boot from is /tftpboot/vmlinux.nb (and a few other pieces of information).
You may wonder how the DC found the address of the BOOTP server in the first place. The answer is that it didn't. The BOOTP request was broadcast on the local network and any BOOTP server that can answer the request will.
After obtaining an IP address, the DC must download an operating system image and execute it. Another Internet protocol is used here, called Trivial File Transfer Protocol (TFTP). TFTP is like a cut-down version of FTP---there is no authentication, and it runs over User Datagram Protocol (UDP) instead of Transmission Control Protocol (TCP). UDP was chosen instead of TCP for simplicity. The implementation of UDP on the DC can be small so the code is easy to fit on a ROM. Because UDP is a block oriented, as opposed to a stream oriented, protocol, the transfer goes block by block, like this:
DC: Give me block 1 of /tftpboot/vmlinux.nb.
TFTP server: Here it is.
DC: Give me block 2.
and so on, until the whole file is transferred. Handshaking is a simply acknowledge each block scheme, and packet loss is handled by retransmit on timeout. When all blocks have been received, the network boot ROM hands control to the operating system image at the entry point.
Finally, in order to run an operating system, a root filesystem must be provided. The protocol used by Linux and other Unixes is normally Network File System (NFS), although other choices are possible. In this case the code does not have to reside in the ROM but can be part of the operating system we just downloaded. However the operating system must be capable of running with a root filesystem that is a NFS, instead of a real disk. Linux has the required configuration variables to build a version that can do so.
Net Loader is a small program that runs as a BIOS extension, usually on an EPROM on the NIC. It handles the BOOTP query and TFTP loading and then transfers control to the loaded image. It uses TCP/IP protocols but the loaded image doesn't have to be Linux. The loaded image can be anything, even DOS. They can also be loaded from a floppy for testing and for temporary setups.
Besides commercial boot ROMs, there are TWO sources for free packages for network booting. Free implementations of TCP/IP net loaders are -
Etherboot uses built-in drivers while Netboot uses Packet drivers. First you have to ascertain that your network card is supported by Etherboot or Netboot. Eventually you have to find a person who is willing to put the code on an EPROM (Erasable Programmable Read Only Memory) for you but in the beginning you can do network booting from a floppy.
To create a boot floppy, a special boot block is provided in the distribution. This small 512 byte program loads the disk blocks following it on the floppy into memory and starts execution. Thus to make a boot floppy, one has only to concatenate the boot block with the Etherboot binary containing the driver for one's network card like this:
# cat floppyload.bin 3c509.lzrom > /dev/fd0
Get the nfsboot package (the package is available from your favourite linux mirror site in the /pub/Linux/system/Linux-boot directory). It contains a booteprom image for the network cards (like wd8013) which can be directly burned in. See also the LTSP site at http://www.ltsp.org
Before you put in the network boot floppy, you have to set up three services on Linux -
You don't have to set up all three at once, you can do them step by step, making sure each step works before going on to the next.
Install Bootp. See bootp*.rpm on Redhat linux cdrom. See also LTSP site for RPM packages at http://www.ltsp.org. See also unix manual pages 'man 5 bootptab', 'man 8 bootpd', 'man 8 bootpef', 'man 8 bootptest'. You then have to ensure that this server is waiting for bootp requests. The daemon can be run either directly by issuing command
bootpd -s
Or by using inetd edit the file /etc/inetd.conf and put a line like this:
bootps dgram udp wait root /usr/sbin/in.bootpd bootpd
bootps 67/tcp # BOOTP server tftp 69/udp # TFTP server
If you had to modify /etc/inetd.conf, then you need to restart inetd by sending the process a HUP signal.
kill -HUP <process id of inetd>.
Next, you need to give bootp a database to map Ethernet addresses to IP addresses. This database is in /etc/bootptab. You must modify it by inserting the IP addresses of your gateway, dns server, and the ethernet address(es) of your diskless machine(s). It contains lines of the following form:
aldebaran.foo.com:ha=006008C7A3D8:ip=192.168.1.100:bf=/tftpboot/vmlinuz.nb
Other information can be specified but we will start simple.
Another example of /etc/bootptab is :
global.prof:\ :sm=255.255.255.0:\ :ds=192.168.1.5:\ :gw=192.168.1.19:\ :ht=ethernet:\ :bf=linux: machine1:hd=/export/root/machine1:tc=global.prof:ha=0000c0863d7a:ip=192.168.1.140: machine2:hd=/export/root/machine2:tc=global.prof:ha=0800110244e1:ip=192.168.1.141: machine3:hd=/export/root/machine3:tc=global.prof:ha=0800110244de:ip=192.168.1.142:
global.prof is a general template for host entries, where
After this, every machine must have a line:
Now boot the DC with the floppy and it should detect your Ethernet card and broadcast a BOOTP request. If all goes well, the server should respond to the DC with the information required. Since /tftpboot/vmlinux.nb doesn't exist yet, it will fail when it tries to load the file. Now you need to compile a special kernel, one that has the option for mounting the root filesystem from NFS turned on. You also need to enable the option to get the IP address of the kernel from the original BOOTP reply. You also need to compile the Linux driver for your network adapter into the kernel instead of loading it as a module. It is possible to download an initial ramdisk so that module loading works but this is something you can do later.
You cannot install the zImage resulting from the kernel compilation directly. It has to be turned into a tagged image. A tagged image is a normal kernel image with a special header that tells the network bootloader where the bytes go in memory and at what address to start the program. You use a program called mknbi-linux to create this tagged image. This utility can be found in the Etherboot distribution. After you have generated the image, put it in the /tftpboot directory under the name specified in /etc/bootptab. Make sure to make this file world readable because the tftp server does not have special privileges.
For TFTP, see tftp*.rpm on Redhat Linux cdrom. TFTP (Trivial File Transfer Protocol) is a file transfer protocol, such as ftp, but it's much simpler to help coding it in EPROMs. TFTP can be used in two ways:
Tftpd is normally started up from inetd with a line like this in /etc/inetd.conf.
tftp dgram udp wait root /usr/sbin/tcpd in.tftpd -s /tftpboot #tftp dgram udp wait root /usr/sbin/in.tftpd tftpd /export
Again, restart inetd with a HUP signal and you can retry the boot and this time it should download the kernel image and start it. You will find that the boot will continue until the point where it tries to mount a root filesystem. At this point you must configure and export NFS partitions to proceed.
For various reasons, it's not a good idea to use the root filesystem of the server as the root filesystem of the DCs. One is simply that there are various configuration files there and the DC will get the wrong information that way. Another is security. It's dangerous to allow write access (and write access is needed for the root filesystem, for various reasons) to your server's root. However the good news is that a root filesystem for the DC is not very large, only about 30 MB and a lot of this can be shared between multiple DCs.
Ideally, to construct a root filesystem, you have to know what files your operating system distribution is expecting to see there. Critical to booting are device files, files in /sbin and /etc. You can bypass a lot of the hard work by making a copy of an existing root filesystem and modifying some files for the DC. In the Etherboot distribution, there is a tutorial and links to a couple of shell scripts that will create such a DC root filesystem from an existing server root filesystem. There are also troubleshooting tips in the Etherboot documentation as this is often the trickiest part of the setup.
The customised Linux kernel for the DC expects to see the root filesystem at /tftpboot/(IP address of the DC), for example: /tftpboot/192.168.1.100 in the case above. This can be changed when configuring the kernel, if desired.
Now create or edit /etc/exports (see 'man 5 exports' and 'man 8 exportfs') on the server and put in a line of the following form:
/tftpboot/192.168.1.100 aldebaran.foo.com(rw,no_root_squash)
The rw access is needed for various system services. The no_root_squash attribute prevents the NFS system from mapping root's ID to another one. If this is not specified, then various daemons and loggers will be unhappy.
Start or restart the NFS services (rpc.portmap and rpc.mountd) and retry the diskless boot. If you are successful, the kernel should be able to mount a root filesystem and boot all the way to a login prompt. Most likely, you will find several things misconfigured. Most Linux distributions are oriented towards disked operation and require a little modification to suit diskless booting. The most common failing is reliance on files under /usr during the boot process, which is normally imported from a server late in the boot process. Two possible solutions are -
You may wish to mount other directories from the server, such as /usr (which can be exported read-only).
When you are satisfied that you can boot over the network without any problems, you may wish to put the code on an EPROM.
X-terminals are one natural use of network booting. The lack of a disk in the terminal makes it quieter and contributes to a pleasant working environment. The machine should ideally have 16MB of memory or more and the best video card you can find for it. This is an ideal use for a high-end 486 or low-end Pentium that has been obsoleted by hardware advances. Other people have used network booting for clusters of machines where the usage is light on the DC and does not warrant a disk, e.g. a cluster of classroom machines.
Your first stop should be the Etherboot home page: http://www.slug.org.au/etherboot/
There you will find links to other resources, including a mailing list you can subscribe to, where problems and solutions are discussed.
Related documents
The DC requests to mount /tftpboot/< IP address of DC > (in Linux Kernel 2.1 and above it is - /tftpboot/< name of DC in bootptab > ) as its root directory '/' by NFS from server. You must export this from the server (rw, no_root_squash) because the DC wants to write on it (log files, etc).
The root directory / must contain /sbin, /bin, /lib, /etc, /var, /tmp, /root, /dev and /proc.
/sbin, /bin, /lib can be a copy of an existing Redhat Linux system. They can be shared between all DCs. But hard links only. By the way, don't link to server originals.
/etc, /var and /dev should be non-sharable copies. Customise /etc/sysconfig/network, /etc/sysconfig/network-scripts/ifcfg-eth0, /etc/fstab, /etc/conf.modules, and others. Turn off all network services you don't need. Remove all stuff you don't need from /var, e.g. RPM db, lpd files.
/root and /proc should just exist. /tmp should exist and be mode 1777.
You probably want to create /usr and /home mount points. /usr can be mounted ro (read-only).
About 10 MB per DC plus about 15 MB of shared files should be sufficient. By the way, if your DCs are quite similar, the kernel image can also be shared.
Here is an illustrative script to create the first root filesystem.
#!/bin/sh if [ $# != 1 ] then echo Usage: $0 client-IP-addr exit 1 fi cd / umask 022 mkdir -p /tftpboot/$1 # just make these ones for d in home mnt proc tmp usr do mkdir /tftpboot/$1/$d done chmod 1777 /tftpboot/$1/tmp touch /tftpboot/$1/fastboot chattr +i /tftpboot/$1/fastboot # copy these ones cp -a bin lib sbin dev etc root var /tftpboot/$1 cat <<EOF Now, in /tftpboot/$1/etc, edit sysconfig/network sysconfig/network-scripts/ifcfg-eth0 fstab conf.modules and configure rc.d/rc3.d EOF
Here is an illustrative script to duplicate the root filesystem
#!/bin/sh if [ $# != 2 ] then echo Usage: $0 olddir newdir exit 1 fi cd /tftpboot if [ ! -d $1 ] then echo $1 is not a directory exit 1 fi umask 022 mkdir -p $2 # just make these ones for d in home mnt proc tmp usr do mkdir $2/$d done chmod 1777 $2/tmp touch $2/fastboot chattr +i $2/fastboot # link these ones for d in bin lib sbin do (cd $1; find $d -print | cpio -pl ../$2) done # copy these ones for d in dev etc root var do cp -a $1/$d $2 done cat <<EOF Now, in /tftpboot/$2/etc, edit sysconfig/network sysconfig/network-scripts/ifcfg-eth0 fstab (maybe) conf.modules (maybe) and configure rc.d/rc3.d EOF
On the server, make sure the DC is matched by a clause in /etc/X11/xdm/Xaccess and comment out the :0 in /etc/X11/xdm/Xservers. Then make sure that xdm is run from the init scripts.
On the client, run X -query server
You will get the xdm login box and then all your X clients will run on the server.
For other applications use - you could use diskless technique for netboot routers, print servers (but should not be spooling print server), standalone apps, etc.
This information may save you time. In order to make LanWorks BootWare(tm) PROMs to correctly start up a Linux kernel image, the "bootsector" part of the image must be modified so as to enable the boot prom to jump right into the image start address. The net-bootable image format created by netboot/etherboot's `mknbi-linux' tool differs and will not run if used with BootWare PROMs.
A modified bootsector together with a Makefile to create a BootWare-bootable image after kernel compilation can be found at -
Refer to the README file for installation details. Currently, only "zImage"-type kernels are supported. Unfortunately, kernel parameters are ignored.
This section courtesy of Jochen Kmietsch email to - jochen.kmietsch@tu-clausthal.de for any questions.
Etherboot is a package for creating ROM images that can download code over the network to be executed on an x86 computer. Typically the computer is diskless and the code is Linux, but these are not the only possibilities.
This document is at the Etherboot Home Page. This document explains how to install, configure and use the Etherboot package.
Netboot was written by Zurück zu Gero. The main site is at http://www.han.de/~gero/netboot.html.
The following list shows just a few examples of what Netboot can be used for:
For the bootrom to find the kernel image it uses the BOOTP protocol as defined in RFCs and RFCs to get the necessary boot information, and then loads the actual image using the TFTP protocol as defined in RFCs .
The exact specifications for this netboot process can be found http://www.han.de/~gero/netboot/english/spec.html.
There exists a mailing list devoted to network booting. To subscribe simply send a mail with the line
subscribe netboot
in it's body to majordomo@baghira.han.de
The subject in the mail header doesn't matter. After subscribing to it, you can send messages into the list by writing a mail to netboot@baghira.han.de.
Netboot mailing list archive is at http://www.han.de/~gero/netboot/archive/maillist.html
Copyright policy is GNU/GPL as per LDP (Linux Documentation project). LDP is a GNU/GPL project. Additional restrictions are - you must retain the author's name, email address and this copyright notice on all the copies. If you make any changes or additions to this document than you should intimate all the authors of this document.
This document is published in 11 different formats namely - DVI, Postscript, Latex, Adobe Acrobat PDF, LyX, GNU-info, HTML, RTF(Rich Text Format), Plain-text, Unix man pages and SGML.
LaTeX documents may be converted into PDF files simply by producing a Postscript output using sgml2latex ( and dvips) and running the output through the Acrobat distill ( http://www.adobe.com) command as follows:
bash$ man sgml2latex bash$ sgml2latex filename.sgml bash$ man dvips bash$ dvips -o filename.ps filename.dvi bash$ distill filename.ps bash$ man ghostscript bash$ man ps2pdf bash$ ps2pdf input.ps output.pdf bash$ acroread output.pdf &
This howto document is located at -
Also you can find this document at the following mirrors sites -
In order to view the document in dvi format, use the xdvi program. The xdvi program is located in tetex-xdvi*.rpm package in Redhat Linux which can be located through ControlPanel | Applications | Publishing | TeX menu buttons. To read dvi document give the command -
xdvi -geometry 80x90 howto.dvi
man xdvi
And resize the window with mouse.
To navigate use Arrow keys, Page Up, Page Down keys, also
you can use 'f', 'd', 'u', 'c', 'l', 'r', 'p', 'n' letter
keys to move up, down, center, next page, previous page etc.
To turn off expert menu press 'x'.
You can read postscript file using the program 'gv' (ghostview) or 'ghostscript'. The ghostscript program is in ghostscript*.rpm package and gv program is in gv*.rpm package in Redhat Linux which can be located through ControlPanel | Applications | Graphics menu buttons. The gv program is much more user friendly than ghostscript. Also ghostscript and gv are available on other platforms like OS/2, Windows 95 and NT, you view this document even on those platforms.
To read postscript document give the command -
gv howto.ps
ghostscript howto.ps
You can read HTML format document using Netscape Navigator, Microsoft Internet explorer, Redhat Baron Web browser or any of the 10 other web browsers.
You can read the latex, LyX output using LyX a X-Windows front end to latex.
This section is for academic interest only - for universities or research institutes. If you have plenty of time then you can read it. These links are to RFCs and to the history of diskless nodes. Students will find these links interesting to read the history of development of diskless workstations.
Word of Caution: The information and data given by these URLs may be old.