Starting with your first /etc/rant column, I have loved them. You are
saying aloud what
many in the community think, with a very loud voice. I wanted to ask you,
why is this available only to subscribers? I'd love to make some comments on
my blog and then link to your columns, or translate them to Spanish and let
my friends read them in my blog. Tell me if this is feasible, please. I
already commented on the /etc/rant of February 2006 issue and plan to do it
on the April one I've just received, because I have lots of friends using
GNOME just because they think it embodies the spirit of Free Software.
Keep up the rant...er, the work.
We do not publish in print and on the Web simultaneously, but we do publish our print content on the Web after a period of time expires. You can find archives of the magazine at the URL www.linuxjournal.com/xstatic/magazine/archives. —Ed.
Teams work very hard to release and offer their programming works of art.
I doubt any of them wishes to bash each other's software. How about
some constructive rants? The developers just might be inclined to offer
a feature/fix that your “opinion” had a problem with. Or,
you might even spawn a reader to contribute constructively instead
Thanks for listening to my rant.
The position of editor in chief traditionally allows ultimate control
of all aspects of a publication—from which letters will be included,
to whether GNOME or KDE screenshots are used, to what articles are
published and who is allowed to contribute. Perhaps
LJ has a system of
checks and balances in place that the casual reader doesn't know about,
but from the cheap seats, I'm concerned. Not to sound alarmist, but
a strong bias from the editor in chief is a contamination that can't
possibly be quarantined only to the last page of a publication!
It is the job of an editor in chief to serve the magazine's readers, period. That means keeping the content separate from the influence of advertising and unaffected by the editor's own personal opinions. If at any point you believe the content reflects otherwise, I will take your complaints very seriously. —Ed.
Great rant [April 2006]. But, as I see it, the real problem is not about advocacy,
it's about (never-ending) fragmentation. Big players (such as Oracle and Dell) are
complaining about it, and no one seems to listen.
The real problem is that a genius like Miguel is wasting his time with
GTK or Mono (the C# equivalent of the GNU Java compiler), when he could
do really useful stuff. It's a pity.
I just got the latest LJ in the mail today. I wonder about the genesis of the “practically useless GCJ” remark in the etc/rant column [April 2006].
The version of Eclipse on my Debian Sid installation was built with GCJ, and it seems to run fine with no Sun JRE in sight. I thought Eclipse was a fairly large and complex project (although I have never tried to build it from scratch myself), so what does GCJ need to be able to do to get out of the “practically useless” category?
I also thought the limits of GCJ were due to limits of the GNU classpath,
and that work on that was progressing nicely. Maybe I'm not following
developments closely enough, though.
I'm the one not following the developments closely enough. Granted, it's not supported for Swing, but if you can compile the SWT-based Eclipse with GCJ, I owe it an apology. —Ed.
So far, I just want say that I like the rants closing the new Linux Journal issues, although a blog of some kind might be a more appropriate place.
Still, you are echoing sentiments that I have expressed many times in the past. From the moment Miguel said, “UNIX sucks”, and started making Linux look like Windows, I've felt like I've been lost in some kind of terrible nightmare, unable to awaken. I love UNIX, and although it certainly needs help on the desktop from a development API standpoint, I'm not about to throw away everything about UNIX that makes it great. Please reference the late Mr Einstein's genius (I use the following quotation in my e-mail signature) for why UNIX is great, IMHO:
“Any intelligent fool can make things bigger and more complex....It takes
a touch of genius—and a lot of courage—to move in the opposite
Michael P. Soulier
Please cancel my subscription, because the Linux Journal disappoints me
thoroughly. It's too practical for this budding theoretical computer
William J. McEnaney Jr.
You now have a very inconvenient size and it ruins the display I have
of Linux Journal.
It doesn't fit on my lap in the men's reading room; it doesn't fit
in most places while reading, except in your hands, and it is
awkward there as well.
I love Linux Journal; I hate the new size of the pages.
In “Demons Seeking Dæmons—A Practical Approach to Hardening Your OpenSSH Configuration” [March 2006], Phil Moses mentions the UsersAllow directive, but it is really the AllowUsers directive (as Listing 2 shows). And UsersDeny is really DenyUsers.
The meaning of an entry such as email@example.com is misleading.
He seems to indicate that it allows access to user from hostname.domain,
but it really means that people from hostname.domain can access user's
account (according to O'Reilly's SSH book).
In your recent article on temperature monitoring [see “Remote Temperature Monitoring with Linux” by Steven M. Lapinskas, LJ, April 2006], you didn't mention Paul Alfille's OWFS Project (owfs.sourceforge.net).
OWFS already has been ported to the Linksys WRT54G wireless
router, providing a cheap and readily available hardware
platform for monitoring projects like the one described in the
Juan Marcelo Rodriguez's XOOPS article [April 2006] tells us to set three directories so that any local user, including the Web server, can create and execute programs in them:
chmod 777 uploads cache templates_c
That's poor security practice. If XOOPS needs it, XOOPS needs a redesign. These wide open directories are just the place to install a 'bot for spamming or DoS attacks. It's begging for an Internet worm, if one doesn't exist already.
Mambo has similar issues. It seems the easier they make these complex Web
apps to install, the less care they pay to securing those installations.