|
|
|
|
|
|
|
|
In the September issue's Best of Technical Support column, I was particularly interested in two of the letters.
John Barnitz wrote that he has problems with up and down-spinning disks. If his disk is a SCSI disk, it can, in many cases (e.g., Adaptec-Controller), be switched off in the controller setup. Another method on modern motherboards is to disable some of the power-saving settings.
Are Tysland wrote of problems with su and security. I tried sudo for a while, but now I am using su1 (also on sunsite). Using sudo, it is only possible to allow or disallow a command for a user or a specified group of users. With su1 you can control the parameters, e.g., user A can only mount CDs while user B or group B can mount disks. You can control nearly every parameter and command with this tool. I don't believe in a separate group for su users because you have to switch the group before using it. If you don't switch back after using su, you will probably have a problem.
--
Martin Fuerstenau, Bilm, Germany
tomcat@hannover.sgh-net.de
The article Grundig TV-Communications by Ted Kenney in issue 42 contains a small mistake in the last sentence of the last paragraph on page 54. DPT didn't begin to distribute a Linux driver developed by a third party. What they did, was start listing Linux as a supported OS and linking their web site to my EATA web pages. (I am the author of the EATA-DMA driver for the DPT controllers.)
--
Michael Neuffer
neuffer@trudi.zdv.Uni-Mainz.DE
I'd just like to say how much I enjoyed the article by R. K. Owen in the July 1997 LJ, Registering in the U.S. Domain (For Free). Using Mr. Owen's carefully spelled out procedures, I tried to register a domain with the berkeley.ca.us ``delegated authority'', Cliff Frost cliff@ack.berkeley.edu. The response was totally underwhelming, and months later I still do not have my requested domain registered.
This whole US domain registration system seems to be operating at the level of the US Postal Service. (Hmm. Wait, that's uncharitable. The USPS is a whiz in comparison to these characters.)
For example, this morning I went to the page: http://www.isi.edu/us-domain/ and tried to use the web-based registration form, since the Berkeley delegated authority is not responding to me. Clicking on the ``Web Based Registration Template'' and arriving at the URL: http://www.isi.edu/cgi-bin/usdomreg/template.pl, I got a ``Not Found'' message.
It appears that the San Jose, CA delegated authority that R. K. Owen used is better organized. I hope your other readers have better luck using the article's procedures than I did.
Keep the good stuff flowing from Linux Journal.
--
Robert Lynch
rmlynch@best.com
The October issue is great, but there is a small error--my e-mail address on page 33 is wrong [Internet Programming with Python book review]. Instead of djohnson@olympus.net, it should be dwj@aaronsrod.com.
--
Dwight Johnson
dwj@aaronsrod.com
Now you guys have really done it--I mean Issue 42, October 1997.
A smart looking cover, articles packed with answers and numerous relevant reviews, all for five bucks. It's going to take me hours to pore over this thing. Linux Journal keeps improving. Keep it up. I may even get around to subscribing one day.
--
John Whipple
johnboy@sonic.net
I would like to correct the assertion of the responder who claims that Xforms is not available for Linux in a.out format. [Letters to the Editor, October 1997, John Brown, ``XForms Article'']
The FTP site ftp://einstein.phys.uwm.edu/pub/xforms/ contains a linux/ directory with two subdirectories, one that contains the ELF distribution and one that contains the a.out distribution. Both the old release 0.81 and the newer 0.86 are represented in both formats.
Furthermore, the test subdirectory contains the latest test release (0.87.2) in both a.out and ELF formats, thus refuting the assertion that the developers will not support a.out any more.
--
Martin John Bartlett
martin@nitram.demon.co.uk
I thoroughly enjoyed the article by Luis A. Fernanades entitled, xmotd: Writing Free Software [October, 1997]. It was a pleasure to read about a programmer contributing to Free Software and supporting other users. This is the very reason that I switched to Linux. Keep articles like that one coming.
--
Steven J. Hill
sjhill71@inav.net
The LJ article on Pgfs is really great--nicely written and very informative. [Pgfs: The PostGres File System, Brian Bartholomew, October 1997.] A very nice example of problem solving with our favorite OS. Thanks for including information on what didn't work; it was just as interesting as what did.
LJ is quickly becoming my favorite magazine.
--
Eric C. Newton
ecn@smart.net
Table 1 on page 30 of the October issue is hardly a ``Summary of Alpha Chip Family''. [Linux and the Alpha, David Mosberger]
David Mosberger surprised me when he stated in the Alpha article that gettimeofday() ``returns the current real time at a resolution of typically one timer tick (about one millisecond on the Alpha)''. The gettimeofday() API allows a resolution of one microsecond, and Linux on the i386 gives you that (courtesy of a hardware counter that is incremented at approximately one megahertz). A quick look at the 2.0.29 kernel sources (arch/*/kernel/time.c) suggests to me that gettimeofday() gives you high resolution on the i386, m68k, mips and ppc, but not on the Alpha or SPARC. Are there plans to fix this inequity?
--
James R. Van Zandt
jrv@vanzandt.mv.com
No, it's not. Correct table is printed below.
I think you raise three different questions:<\n>
1. What does _typical_ resolution mean?
2. Would gettimeofday() with one microsecond be sufficient for the kinds of
measurements I wanted to discuss?
3. Will Linux/Alpha support resolutions finer than 1 clock tick?
The answers:
1.To user X, ``typical'' is what user X happens to own, I suppose. Seriously though, the traditional gettimeofday() implementation provided timer-tick resolution. The API obviously always has allowed for up to microsecond resolution, but that's not relevant for actual implementations. If you're writing a portable program, you cannot rely on gettimeofday() returning better than timer-tick resolution, hence my claim of this being ``typical''.
2. One microsecond resolution is far from sufficient for modern CPUs. Even on a (relatively slow) 200MHz P6 this would correspond to 200 cycles, so it would not be possible to measure low-level events such as primary cache-misses. Even if the resolution were sufficient, keep in mind that getimeofday() typically involves a system call. For example, on a 200MHz P6, it appears to take on the order of four microseconds just to execute a pair of gettimeofday() calls. In summary, there are plenty of scenarios where a CPU cycle counter is advantageous over gettimeofday(). Of course, the converse is also true. What I'm saying is that both techniques have their place for the time being.
3. I don't know. 2.1.xx may already do that, but I haven't had a chance to keep track of recent kernel development.
--
David Mosberger
davidm@azstarnet.com
I have just read Phil Hughes' Stop the Presses in the October issue of LJ. Being a manufacturer of intelligent multiport cards, Cyclades has been following I2O for a while.
I2O has been around for a few years now. It started to gain momentum only this year, due to the persistence of Intel. SCO, Microsoft and Novell seem to be going to support it. At this point, there are no real implementations of I2O, and the standards are only now becoming stable. I have doubts whether this will actually become real or not. The idea of a standard architecture is good, but I2O is a very heavy interface designed to sell Intel processors.
Besides the fact that you have to pay to get the specs (not necessarily bad, PCI does the same thing), there is another catch. The I2O specs were designed so that there is only one possible CPU to be used on a I2O card: the Intel 960RP. More, only Wind River (working with Intel) has a software implementation of I2O messaging. Intel bundles a runtime license of IxWorks (the RTOS that runs the I2O messaging inside the board) with every 960RP.
Thus, I2O is not an ``open'' standard. It is an attempt by Intel to standardize intelligent I/O around the Intel 960RP and Wind River's IxWorks.
With I2O gaining some momentum, other hardware companies (PLX is one of them) are designing PCI chips compliant with I2O messaging. But, still, the choices are limited, and the viability of I2O is still to be verified.
Phil also mentioned the ``Open Hardware'' initiative. Cyclades was the first company to certify products for Open Hardware and is, still, the only one.
--
Marcio Saito, Cyclades Corporation
marcio@cyclades.com
Write us at ljeditor@ssc.com or send snail mail to Linux Journal, P.O. Box 55549, Seattle, WA 98155-0549. All published letters are subject to editing.
