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.
Practical Task Scheduling Deployment
One of the best things about the UNIX environment (aside from being stable and efficient) is the vast array of software tools available to help you do your job. Traditionally, a UNIX tool does only one thing, but does that one thing very well. For example, grep is very easy to use and can search vast amounts of data quickly. The find tool can find a particular file or files based on all kinds of criteria. It's pretty easy to string these tools together to build even more powerful tools, such as a tool that finds all of the .log files in the /home directory and searches each one for a particular entry. This erector-set mentality allows UNIX system administrators to seem to always have the right tool for the job.
Cron traditionally has been considered another such a tool for job scheduling, but is it enough? This webinar considers that very question. The first part builds on a previous Geek Guide, Beyond Cron, and briefly describes how to know when it might be time to consider upgrading your job scheduling infrastructure. The second part presents an actual planning and implementation framework.
Join Linux Journal's Mike Diehl and Pat Cameron of Help Systems.
Free to Linux Journal readers.View Now!
|The Firebird Project's Firebird Relational Database||Jul 29, 2016|
|Stunnel Security for Oracle||Jul 28, 2016|
|SUSE LLC's SUSE Manager||Jul 21, 2016|
|My +1 Sword of Productivity||Jul 20, 2016|
|Non-Linux FOSS: Caffeine!||Jul 19, 2016|
|Murat Yener and Onur Dundar's Expert Android Studio (Wrox)||Jul 18, 2016|
- The Firebird Project's Firebird Relational Database
- Stunnel Security for Oracle
- My +1 Sword of Productivity
- SUSE LLC's SUSE Manager
- Non-Linux FOSS: Caffeine!
- Managing Linux Using Puppet
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
- Parsing an RSS News Feed with a Bash Script
- Google's SwiftShader Released
- Doing for User Space What We Did for Kernel Space
With all the industry talk about the benefits of Linux on Power and all the performance advantages offered by its open architecture, you may be considering a move in that direction. If you are thinking about analytics, big data and cloud computing, you would be right to evaluate Power. The idea of using commodity x86 hardware and replacing it every three years is an outdated cost model. It doesn’t consider the total cost of ownership, and it doesn’t consider the advantage of real processing power, high-availability and multithreading like a demon.
This ebook takes a look at some of the practical applications of the Linux on Power platform and ways you might bring all the performance power of this open architecture to bear for your organization. There are no smoke and mirrors here—just hard, cold, empirical evidence provided by independent sources. I also consider some innovative ways Linux on Power will be used in the future.Get the Guide