Letters

Regarding the Golden Age of Linux Journal

After having seen in the past few issues of LJ readers who are
disenchanted with the magazine's content, I feel I must give counterpoint.

Much like Mr Silverton's setup in the January 2007 issue, I began using
Linux in 1995, failing first to install Red Hat and settling in on the
astounding Slackware distribution from untold numbers of hit-or-miss
floppies. Likewise, I used Linux in a rather amateur fashion for a
number of years. At that time, I subscribed to Linux
Journal but found
only one or two articles that rapt my attention. Later, I started a
Linux-based company, designing Linux-based solutions for a number of
types of businesses. Even after becoming a Linux
“professional”, I was
no more drawn to the overall quality of Linux
Journal.

For many months now, however, I have been simply astonished by the quality
of most every article. I now read the magazine cover to cover. Even the
articles that are “beneath” me often have a gem of
information that
I may find intriguing.

Even more appealing is the uncanny timeliness of recent issue
themes. LJ has never really been bleeding-edge. After all, it is a
monthly publication. Recently, though, I have had several issues in a
row that have matched very closely my personal contemporary interests,
and I have been delighted by the breadth of your coverage. You cover
amply the needs of both the amateur (which I am, with respect to more
desktop-type issues) and the professional (which I am, with respect to
the development and server issues).

In summary, I have never, in ten years of subscribership, been so happy
with the diversity, scope, depth and accuracy of Linux
Journal. Keep
up the excellent work.

—
Sean C. McCord

What's a Few Zeros between Friends?

Quote from Linux for Suits, February 2007: “The 15mbps they reserve
for their Internet service is less than 1% of that capacity.”

15 millibits per second really is pathetic.

—
Ian Stirling

Obviously, that should have been Mbps.—Ed.

What's a Few Letters between Friends?

In “White Box Phone” [February 2007], you said that the OpenMoko phone came from
Funambol. I think you meant to say FIC.

Funambol is the company behind SyncML and push mobile e-mail.

—
Bill Weinberg

Someone Else May Have to Decipher Your Code Someday

I've already made comments about Dave Taylor's column, and you know I'm
behind his doing this column and what it teaches. My comment is not a
criticism of that column but what I hope is viewed as an addendum to it.

The urge to put an entire sequence of operations on “one
line” (chained
together via pipes) is noble and quite understandable when one is “in
a hurry” or doing something “quick and dirty”. It isn't the wisest of
choices for beginners or “semi-production” work.

Yes, this is arguable, but I'd like to reference something else in your
magazine, page 14, “They Said It” [February 2007], the third quotation,
“Coding up the simplest thing....”

Over time, I've learned that as “The next guy”, trying to read and
understand code written by “the guy before me”, that breaking a sequence
of steps like this down into the constituent parts makes maintainability
and supportability significantly easier.

While the original state is “easy enough” to work with, especially for
a demonstration, in the work place, we should encourage everyone to
remember “the next guy” (and there will
always be a next guy) when
we write scripts.

I would, in an environment where this might be used by someone else and
not run every five minutes, rewrite this script with these additions:

Yes, this seems wasteful. (I mention the five minutes above to point out that if run
more than, say every half hour on a moderately busy box, the methods
may need to be adjusted.) Many people will point out a number of issues
with this method of operation, and one of them is going to be “writing to
disk so much wastes a lot of time”. Yes, it does. I've never been a member
of the “save the PID” crowd or the “make it hard to troubleshoot for job
security” group either. Writing to disk a lot is much cheaper than the
rate I get paid. If it takes an extra 20% to run, who cares as long as
it gives the right answer reliably?

Using the sequence of steps I show above, the people who have to figure out what the he** I did can
quickly get to the root of the problem. Now, all they have to do is
comment out the trap line and look at the temp files' output to see
what is happening and how to fix it. The trap line executes the rm
of the temp files when the script exits (that is, it cleans up after
itself).
They also can see the flow of the process better and gain quicker
understanding.

Thank you for the great articles and helpful insights!

—
Michael C. Tiernan

Now You See Them, Now You Don't

In /var/opinion [February 2007], Nick Petreley suggests tactics to
move further into the mass desktop market. Among other things, he says,
“don't remove features”.

I heartily agree. KDE has seen a steady stream of added features, but
unfortunately some old ones were removed. It is no longer possible to move a
maximised window partly out of the viewport. You have to de-maximise it
first, just like Microsoft. Nor can you double-click on the bar at the
top and reduce it to just the bar, as used to be possible. Konqueror no
longer allows you to right-click on a file and see an option to delete
it, merely one to move it to trash. (Fortunately, there is a way to do
this: select
the file and press Shift-Delete.)

Presumably, the strategy is to converge on Microsoft—up to a point. If
desktop-level Linux becomes identical, why should people buy it rather
than the ready-installed Microsoft product?

When Microsoft moved from command-line (MS-DOS) to Windows, Linux
expanded in the same direction, retaining the old facilities. This is
part of its strength. The same logic applies to desktop Linux: if we
remove features, we play to lose.

—
Chris Trayner

As far as I can tell, you're right about moving files to the trash.
But, I just moved a maximized window partially out of the virtual desktop,
and I also shaded (reduced a window to its title) by double-clicking on
the title bar. I obtained KDE 3.5.6 from a KDE mirror and run it on
Kubuntu 6.10 AMD64.—Ed.

Trending Topics

Upcoming Webinar

Getting Started with DevOps - Including New Data on IT Performance from Puppet Labs 2015 State of DevOps Report

August 27, 2015
12:00 PM CDT

DevOps represents a profound change from the way most IT departments have traditionally worked: from siloed teams and high-anxiety releases to everyone collaborating on uneventful and more frequent releases of higher-quality code. It doesn't matter how large or small an organization is, or even whether it's historically slow moving or risk averse — there are ways to adopt DevOps sanely, and get measurable results in just weeks.