I enjoyed the October 2006 issue of LJ—especially the article “Digital Photography and Linux” by Adrian Klaver, as I was just starting to investigate what it would take to transfer my 1,000 or so 35mm slides onto a CD or DVD.
I have hit a snag right out of the box. When I tried to find scanners with manufacturer-supported drivers, the list was not long and the data was quite old. I did some additional searching and found a lot of messages railing about the support, or lack of, regarding various models. It occurs to me that a good subject for a future article would be how to determine if your “widget” is supported. I know the standard answers, but when the data is old and talks about items that are no longer available, it is not helpful. Regarding Adrian's article, I know that we cannot expect Adrian, or most authors, to test on various hardware, but it certainly would be a big plus if LJ could provide an addendum to an author's article that stated the process has been tried on the different hardware, or include a list of supported hardware that could be used to accomplish the tasks the article describes—not an exhaustive list but some representative items.
I know everything is a resource issue, and I want to congratulate you
on an excellent magazine. The October 2006 issue hit two of my hot buttons
right on time. Thank you, and keep up the good work.
—
Jim
Several recent discussions about the Linux kernel have focused on the problems it has with drivers. The monolithic kernel makes drivers a part of the kernel, and it is becoming bloated. In addition, management of modules, where infrequently used drivers are often placed, is becoming problematic, and the concept of modules may be dropped. A recent article (A. S. Tannenbaum, J. N. Herder, H. Bos, “Can We Make Operating Systems Reliable and Secure”, IEEE Computer, May 2006) pointed out some advantages to placing the drivers in user space rather than in the kernel. Minix 3, which is closely related to Linux, does this with great success. Because the drivers are in user space, only the drivers that are needed by the system have to be loaded. Infrequently used drivers can be loaded on demand. If a driver fails or is co-opted by rogue software, it does not cause the system to fail, and it can be recovered simply by reloading a fresh copy.
This approach would seem to have some real advantages for Linux.
I understand that some experimental work has been done. The kernel
size would be reduced, modules would not be needed and reliability
would be enhanced. In addition, vendors who currently do not supply
drivers for Linux because of problems they perceive with the GPL vs. the
proprietary nature of their products could issue proprietary drivers
that would not in any way be subject to the GPL and would operate
strictly as user applications, interfacing to the primitive interrupt
handlers and dispatches in the kernel. Developers would need to pay
attention to some new security concerns and attack modes, but overall
the approach may be more secure than the current one.
—
Norman Worth
I thought I'd relate something that happened to me recently. A friend of mine called me up, excitedly saying that he just got a new computer and was telling me all the amazing things it could do, running Windows, of course, and he was especially excited about being able to change the way it looked with something called themes.
So I told him to come over to my place, and when he did I said to him, “just watch what I can do”. So, I logged in to my Ubuntu with GNOME, then said, “watch this”, logged out and logged back in with KDE. Then, before he could say another word, I logged out and logged in with WindowMaker (which I personally use most often), saw his look of total confusion, and finally logged out and back in with Fluxbox. At this point, completely confused, he said to me, “Wait. You have all these different OSes on your machine?” I told him it was all just one Linux distro. He was astounded.
So, when we argue over which WM is better, remember, what is important
is not what is better, but the fact that we have the choice to use what
works best for each of us, which is, if you think about it, certainly a
lot better than having a big corporation forcing proprietary software
down our throats without the ability of choice. Just a little comment on
the argument of what's best. By the way, love the way the magazine looks
and reads these days. You have my subscription for a long time to come!
—
Jon Alexander
I was reading the October 2006 LJ, and at a certain moment, during reading the article from Dave Taylor named “Analyzing Log Files”, I noticed some processor consuming order in his examples.
At a certain point he wrote the next command prompt to search for HTML files in the access_log:
awk '{ print }' access_log | sort | uniq -c \
| sort -rn | grep "\.html" | head
This command consumes at my system:
real 0m0.097s user 0m0.084s sys 0m0.020s
If you put the grep command right after the awk command, the filter consumes:
awk '{ print }' access_log | grep "\.html" |sort | uniq -c \
| sort -rn | head
real 0m0.042s
user 0m0.028s
sys 0m0.012s
The reason why this is faster can be explained that in the first filter, you will sort first the whole data set, and after that you remove with grep the non-.html entries. The second one (the one I suggest) removes first all the non-.html entries and will sort it afterwards.
In my daily life, I have to deal with IT forensics and data analysis.
I have a lot of big data sets and prefer the fast-as-possible commands
(order) to do my work. With this data set in the article it doesn't
matter (it is a fraction of second faster), but with data sets of more
than 1GB it does matter.
—
Pieter de Rijik
Dave Taylor replies: a great point. I do spend most of my time working with smaller data sets, but you're right that greps should always be as early as possible to cut down that data stream.
I just had the occasion to re-read Mr Petreley's “Separation of Church and Choice” (March 2006), and it couldn't be more timely, as you'll see. For the record, I began reading LJ long before I started subscribing to it. LJ is a very well-put magazine, but, for me, of very limited value. There's nothing wrong with your choice of having the magazine heavily slanted toward sysadmins, programmers and hackers. Alas! I don't fall, nor intend nor expect to, into any one of those categories. Even though eons ago I had my hands heavily into Cobol, that's water long passed under the bridge. Nowadays, my use of Linux is mainly in spreadsheets, some writing, e-mail and a growing interest in digital photography. In other words, I'm a “domestic” user.
I'm not going to suggest you change LJ's direction; I may be many things, but not stupid. My suggestion would be for you to consider a sister publication on the level of (does it still exist?) Smart Computing. Something for “household” consumption—beginners and intermediates.
I wish I were not, but I am not, in the economic level to shell out $50
without concern for something I come to regret. Hence, I can't help but
dream LJ could be of more help to
“pedestrian” Linux users like me. I
imagine there are a lot more of “us” than
“them”; though, no question,
their monthly income may easily surpass my annual intake.
—
g.r.
We've had such a publication for some time! It's called TUX, and I'm proud to say I was the Editor in Chief of TUX before moving to Linux Journal. You can find it at www.tuxmagazine.com. —Ed.
Your October 2006 LJ commentary was dead-on target. I've been attempting MythTV for more than a year, without success. I've tried two motherboards, many distros (Red Hat, Mandriva, Knoppix 4, KnoppMyth and the Debian/AMICUS project). I also subscribe to the MythTV mail group. But, something, somewhere, always fails during the build. I freely admit that my own ineptitude plays a significant part, but I agree that building Myth is much more difficult than it should be. After all, the ATI AIW cards have been performing similar tasks since the early days of Win98 SE.
I built a box based on an Athlon64 board, with an NVIDIA graphics card,
SB Audigy2 ZS sound, a Hauppauge PVR250 and a pcHDTV card, plus three drives
with 800GB total space. All it needs is a functioning system. Maybe
someday....
—
Joe O. Marcom
I finally got MythTV working fairly well, but the quality is limited by the available tuner and capture cards. There is only one hope that it will ever work as well as the built-in PVR in my HDTV cable box. The as-yet unreleased HDTV cable cards promise to capture HDTV just like a cable box. Let's hope they work, and that there will be Linux drivers for them. —Ed.
I am writing to express my great disappointment in your article on Savage 2 (September 2006). It seems that no one bothered researching S2 Games and its previous business practice before publishing this free advertisement for it.
When Savage 1 came out years ago, I rushed to buy it because S2 Games supported Linux. The game installed and ran on Linux. Life was good...for two or three months. Then when a required patch came out, S2 Games never released a Linux version. Savage, being an on-line-only game, requires the same version. This kept all Linux users out in the cold with a worthless non-playable game. Myself and hundreds of others posted on the support forums, e-mailed tech support—all to no avail. S2 Games dropped Linux support and didn't even bother to respond to users. If you do a quick search, you will see the big stink over this. And, I'm sure someone will reply with “but it can work through a third-party hack” comment. If that's what you want to call supporting Linux, feel free to buy Savage 2. My vote, as always, will be with my money, and it won't go to S2 Games.
I am very disappointed that Linux Journal would publish such good things
about S2 Games without doing research first into the company and its
previous actions.
—
Greg
Sorry to fulfill your prediction, but it can run with a third-party hack. The S2 Games site credits Evolved Clan Community for continuing the support for Savage 1 on Linux and provides the appropriate link. —Ed.