The article on page 14 of Linux Journal #2 [The “What's GNU” article on using the Unix “tools philosophy”] was interesting to me. The final pipeline on page 17 has given me a better idea of what Unix really is!!

I even got it working, too, in my Slackware 1.1.1 from morse.net-jon kitchin, VK6TU, jon@dialix.oz.au

LJ replies:

We're glad you liked it. You will probably enjoy the article this month on the history of Unix. Like the “What's GNU” article, it does not directly relate to Linux, but it tells a story that explains why we can have Linux in the first place.

Your Linux Journal is great. I just read the second issue, which was outstanding, and would like to ftp the GNU C Library Reference Manual. I could not find it at sunsite. What is the file name I should be looking for?-Clinton Carr, clint@netcom.com

LJ replies:

All GNU software (that is, software maintained by the Free Software Foundation) and its documentation, including the GNU C library and the GNU C library reference manual, can be found at prep.ai.mit.edu in the directory /pub/gnu, and on mirror sites around the world. Read gnu.announce, where each post announcing a new product is followed by a list of mirror sites all over the world.

The filename you want is glibc-1.07.tar.gz, which contains both the source code and the documentation.

I am looking for some technical details like process management, memory management, process coordination, file system, etc. of Linux OS for my term project. If you could direct me to get those information I would greatly appreciate it.-Raghib Muhammad, raghib@pegasus.montclair.edu

LJ replies:

First, read the source. It's pretty readable, at least to me.

I have written the beginnings of a book about Linux internals called the Linux Kernel Hackers' Guide. It is not complete, but you can ftp it from tsx-11.mit.edu in /pub/linux/docs/LDP/khg* Also, read Bach's The Design of the Unix Operating System which is about AT&T's internals, but they are somewhat similar. Linus read that book while designing Linux. The KHG contains an annotated bibliography that might help you, as well.

I enjoyed reading the April issue of Linux Journal and have two questions on Linux that might be of interest to other readers. I would certainly appreciate any help or solutions.

Does Linux currently support or plan to support QIC-80 tape back-up via a NON-SCSI interface? What I specifically have in mind is an external tape unit that interfaces with the PC via the parallel (printer) port.

I have a date/time system problem with all Linux kernels that I have compiled beginning with patch level 14 and including the latest Linux 1.0, when I compile on my home computer, a 386DX with 8 MB and a math coprocessor. When I compile patch levels 12 and 13, I do not have this problem. When I boot with a floppy containing the newly compiled kernel, Linux starts up without the correct date/time. Instead it thinks it is Jan 1, 1970. If I use the same floppy kernel to boot on my PC at work (a 486DX with 8MB) the current date/time of the system is found. So it appears to be something related to compiling and then booting the kernel on my PC at home. However, this is not a problem with patch levels 13 or 12. Something in the kernel code changed beginning with patch level 14 that now causes difficulties in finding the system time on my home computer.-Donald Mugnai, Silver Spring, MD

LJ replies:

As documented in the Ftape-HOWTO, there is currently no support at all for any tape drives that work off the parallel port. All of these drives use proprietary protocols. No one that we are aware of in the Linux community is currently working on reverse engineering those protocols so as to be able to use those drives. As far as your system time problem, have you tried booting an old patchlevel 12 or 13 kernel on your home PC lately? It might simply be a worn-out battery on your CMOS. If any readers have any better solutions, please send them in. This question might be a little too specific, or be in a FAQ. I was running Slackware Linux 0.99pl14 with a SCSI CD-ROM. The CD-ROM was mounted with:

mount -t iso9960 /dev/sr0 /cd-rom

I later wanted to access a different CD, so I did:

umount /cd-rom

Popped in the new disk, mounted it, and the system thinks the original disk is in the drive. This doesn't happen with floppies, so there must be a switch to mount that says it's removable media. Is there a special way to mount a CD-ROM so the fs will recognize that it's changed?-Joe Wronski, jwronski@mystery.bbn.com

Eric Youngdale, ericy@cais.com, replied:

Sounds like broken firmware on the drive. Any removable SCSI device should report a media change anytime you change discs, and for some reason this is not happening for you. If the drive were reporting the change, then all of the old buffers would be flushed.

One way to force the issue is to simply attempt to use the drive while the drive is empty. The scsi code notices that there is nothing there and does the right thing.

Joe replied:

Thanks for looking into this. Actually, I had been running a version of Linux earlier than 1.0 (.99pl14, I think). After finally building and installing 1.0, the CD-ROM media changes are detected and reported at mount time. All's as it should be now.

Is there a means with Linux to format and use 3.5" disks above 1.44Mb (1.7MB for instance) as easily as with MS-DOS ?-Xavier Cazin, p6ip051@cicrp.jussieu.fr

LJ replies:

Yes. There are a set of patches on tsx-11.mit.edu that accomplish this. There is something in the directory /pub/linux/patches/ called fdpatch2for15.* which does what you want; it supports 3.5" 1.77 MB disks and 5.25" 1.44 MB disks. With that patch applied to use extra-high-formats, the standard fdformat should allow you to format any supported format.

The patches come with a patched version of mtools which will allow you to access DOS-formatted floppies at these formats. The Linux DOS filesystem should access them correctly without any changes, once the fd driver is patched to recognize the high-capacity formats.

All letters to the editor and submissions for Linux Q&A are subject to editing for clarity, length, grammar, and spelling. Send letters and questions to ljeditor@linuxjournal.com, and use a subject like LTE or Q&A. Alternately, send paper mail to Linux Journal, P.O. Box 85867, Seattle, WA 98145-1867. E-mail is preferred, because we can print the results of a discussion, which can be more useful than just your letter and our response.