|
|
|
|
|
|
|
|
I am a subscriber to LJ and, in fact, have every issue. I hesitate to say this, because it sounds like so much bullshit, but I have always been impressed by how quickly LJ came up to speed with quality articles. As a Unix applications programmer, I read several periodicals, and I find your nuts-and-bolts approach refreshing, compared to DDJ's articles. However, I am writing (if that is what this form of communication is properly called) to ask for an improvement in LJ. Would your editorial staff please give serious consideration to including articles on FreeBSD? Especially since it poses no threat to the sales of Linux. Furthermore, I think it would increase your sales, at least with some of the programmers that I know.
An informal survey made back in LJ's early days suggested the FreeBSD community wasn't interested in a magazine devoted to FreeBSD, which SSC was contemplating. (Perhaps things have changed?)
As far as giving time to FreeBSD within the pages of Linux Journal, we do have some ideas we're working on. Right now, though, we've got more material about Linux than we can print.
The July '96 issue of LJ presents the new Korn shell (ksh93). What is not mentioned (and is not widely known) is users not interested in commercial support can get Linux, Sun, etc. binaries for free (src is not available). This includes not only the ksh binary but also shared libraries and the Tksh extension for Tcl/Tk. Just check the URL http://www.research.att.com/orgs/ssr/book/reuse. By the way, the book that URL refers to (Practical Reusable Unix Software, Krishnamurthy, Wiley 1995), is a gold mine, describing and providing the source code for gems such as the dot tool. Dot is a directed graph layout tool, and now I can't live without it. Recommended.
--
Alexandre Valente Sousa
avs@daimi.aau.dk
Mike Loukides and Andy Oram point out in their ``Getting to Know gdb'' article (September '96) that gdb is capable of setting hardware watchpoints on ``only a few workstations''. Not only does the i386 (and beyond) have these capabilities, but current versions of Linux (1.2.1+) and gdb (4.14+) are able to use this feature.
The 386 supports up to four simultaneous hardware watchpoints which can trigger when a memory location is ``accessed'' (read or written). In Linux gdb, these are the ``rwatch'' and ``awatch'' commands. Both commands take an expression to be watched. As the authors point out, this feature is great for watching a memory location that is being mysteriously trashed. The advantage with hardware watchpoints is your program runs at full speed instead of being slowly single-stepped.
The one tricky point in dealing with these watchpoints is they are disabled automatically if program control transfers outside the scope of the expression. For example, if ``i'' is an automatic variable (a ``local'' variable), then when a subroutine is called, the meaning of ``i'' is lost. The workaround is to watch a raw memory location:
(gdb) print &i $1 = (int *) 0xbffffd2c (gdb) awatch *((int *) 0xbffffd2c) Hardware access(read/write) / watchpoint 3: *(int *) 3221224748 (gdb) cont Continuing. Hardware access(read/write) / watchpoint 3: *(int *) 3221224748 123 *foo = 0; (gdb)--
I couldn't believe it--not one, not two, but three (!) issues of Linux Journal in my mail box Wednesday.
I don't know how to thank you for the happy hours I have wiled away in the past two days. I spent several hours just reading ads.
Not since the old days of Byte magazine can I remember enjoying a magazine's ads so much.
--
Dwight Johnson
djohnson@olympus.net
Bonjour,
Thanks for your very efficient dtree [article].
As an anonymous subscriber, I encourage [you] to continue this way: staying with the technical features is, for now, the best means to sustain the Linux movement.
Merci beaucoup.
Cordialement,
--
J-F Bardou
I just purchased a copy of the September 1996 issue of Linux Journal. I was extremely disappointed that you are excluding any mention of bugs from your review articles. Rely on word of mouth? Then why the devil did I just pay $4.00 for your silly journal!! I know you don't want to offend any potential advertisers, but this is ridiculous. Until you can be bothered to report on what these packages are REALLY like, your journal does not have any value.
--
Tim Gawne
tgawne@icare.opt.uab.edu
I just finished reading your article on the Texas OODB in July's Linux Journal.
One free system you did not mention was Exodus (from the now famous OO7 benchmark debacle with Object Store). I have been using Exodus for about two years with its E (C++ extension) for persistence. It is exceptional.
I note from its archive (cs.uws.edu) the latest version of E has been removed (based on gcc-2.5.8), maybe because of several bugs in the release (which I tripped over and have since fixed). The stable release is based on gcc-2.3.3.
I have just completed the port of E-2.5.8 to Solaris 2.4 & 5 and should be releasing it, along with the fixes, back to the archive shortly.
By the way, Exodus does run under Linux and does support a very extensive multi-user, multi-server caching system called ``sm''. sm also supports a two phase commit and checkpointing.
I agree about OODB speed differences--they make systems like ``Manacle'' look like the dinosaurs they are.
--
Stephen Dennis
dennis@rover.research.canon.com.au
I want to give you an update on the Israeli Linux Users Group. First, we now have our own domain. The official web site is http://www.linux.org.il, and a full-scale sunsite-mirroring FTP site is on the way. We are also considering becoming an official non-profit organization, which might be interesting for readers. Subscription to our mailing list can be done at http://www.linux.org.il/Linux-il-sub.html or by sending mail to majordomo@linux.org.il with the subject line empty and the body containing ``subscribe linux-il [address]''.
Finally, I just want to ask that any feedback and comments sent to you as a result of the article also be forwarded to me. I'll make sure the entire group receives them.
--
Shay Rojansky
roji@cs.huji.ac.il
Thanks to everyone there for a wonderful source of information and advertisements specific to Linux. I receive many magazines each month, but the copy of LJ I pick up at the newsstand each month (until now) is by far my favorite. Keep up the good work! (And if there are any technical employment opportunities at LJ, I would love to hear about them.)
I would like to know as much as possible about the projected availability of the back issues. I want to get one of each of the issues still available, so it would help to know which to order first. I don't want to miss one by waiting too long.
Thanks in advance.
--
Walter Seefeld
wseefeld@memphisonline.com
I'm writing to congratulate you on yet another fine issue of the Linux Journal. Your journal is the only one I read from cover to cover any more. Here are a few opinions and comments I'd like to pass on:
--
Nick Busigin
nick@xwing.org
I think your treatment of modules both in your article about 2.0 and in Mr. Crow's article about them is totally wrong. You focus only on memory savings. Mr. Crow even goes so far as to explain that for drivers used permanently, it is better to compile them in the kernel due to the 2K loss per module when they are page-aligned--besides, you lose twelve pages due to kerneld.
Let me answer this first. If you have 20 modules loaded (an unrealistically high number) you lose 40K--add the kerneld and you are still under 100K. Well, what's the matter? This is Linux, not stinking DOS. We have no 640K barrier, and 100K will not cause a noticeable difference in speed (unless you have only 4MB of RAM, but today this is rare).
Consider a beginner using 1.2: he must choose from dozens of boot diskettes the one able to support his hardware. Despite this, the kernel has so many unnecessary drivers that it is 1MB too big (and that WILL make an important difference in speed). And despite being so large, this kernel lacks things he wants, like sound support. So our beginner (still barely able to copy a file) is confronted with the task of compiling a new kernel. It is not so difficult, as we know, but this has an undesirable effect: Linux gets the reputation of being a ``hackers only'' OS--you can't put it in the hands of a person without some computing experience.
Now consider a (future) 2.0 distribution: only one boot image (well, perhaps half a dozen, if you want to optimize for Pentiums). All the drivers are modules. At installation time, the user answers some questions about his hardware, and the installation procedure builds the config files for kerneld and /etc/rc.d/conf.modules for ``permanent modules''. The user reboots and he is running.
Your kernel is perhaps slightly suboptimal, but recompiling is no longer a requisite. That means handling drivers in Linux becomes a lot easier than editing CONFIG.SYS or AUTOEXEC.BAT. Add to this the new package managers, some configuration tools, and a good file manager--with a little hand holding, I now have a hope to rescue my 15-year-old niece from the clutches of the Evil Empire.
--
Jean Francois Martinez
jfm@sidney.remcomp.fr
