I am not writing to complain about the technical content of your magazine; it is excellent quality. I am not writing to complain about the new graphic layout of your magazine—layouts, “look and feel” all come and go. It neither adds nor detracts from the quality of the writing. I am not writing to complain about /etc/rant, or the views and opinions of Nicholas Petreley. Everyone is entitled to his or her opinion, and I have always respected Nicholas, even way back when he wrote for InfoWorld.
I am, however, writing to complain about the new size of the magazine. I somewhat agree with the opinion of Greg Bullough, who believed that his toilet tank was badly designed. However, toilet tanks have been around longer than Linux Journal, and even longer than Linux itself.
As an engineer, I am aware of the need to design products to operate in
the environment they reside. Therefore, I plead with you to reduce the
width of your magazine by about 1.25 inches (32 mm, or 0.0051 furlongs).
I was reading this month's magazine, when I came across this new column: /var/opinion.
I just wanted to say that based on the editor's recent opinions in his
column under the old name /etc/rant, there is a much better name for
his column: /home/petreley/opinion. As the current name, this name is
also LSB-compliant, but like his opinions should be, his home directory
should be kept to himself (not public).
I don't understand why Maddog has to talk in parables. All the other authors don't attempt to give their life story and speak in stories to make their point. This is a publication aimed towards a professional community. Get facts and write an article and not some senile story.
Also the /var/rant article is an okay thing. Editors are allowed to
have opinions. Just as long as when it comes to editing the magazine
they stay objective, which I feel that you have. But the Beachhead
column has to go.
Michael S. Dunsavage
I and many others love Jon's style and look forward to the columns every month. See the next reader's advice. —Ed.
I've been reading this magazine for years and maintain a current subscription to it. Do I always agree with the content selections? No, of course not. Some issues center on something of no value to me, but the next always comes back centered on something that is more to my liking.
The secret to my success is if I don't like an article, I stop reading and turn to the next one. That's a pretty complex task; maybe I should force myself to read the article and write a flame mail to you guys like lots of the letters to editor.
As far as /etc/rant, sure the name might be off a bit, but it's the first article I read in every issue. Once again, I might not agree (hasn't happened yet), but it is your opinion after all. It must be hard for some people just to skip an article, even on the very last page, because it sure draws attention in the letters to editor section every month.
This is still the best Linux mag I see on the market, and I have no
intention of canceling my subscription any time soon. Keep up the good
You are right, [Fedora] disk labels suck. Why Red Hat insists on them beats me.
I've installed [many versions of Red Hat] on many different hardware
platforms, some of them many times. I've never had a Sendmail hang on
boot issue. Could it be your bad karma?
Saw your column in Linux Journal and wanted to respond. I also
have had problems over the years with Sendmail locking up about half the time
when starting Fedora/Red Hat distros.
You'd think [PC] hardware would be easy to understand and use. It isn't. No one wants to play well with others. It's like the PC world is living in never-neverland, and economics has nothing to do with [it].
No other consumer product makes these demands. I don't need to know how an engine in a car works and how to build one. I simply seat myself in the vehicle, fasten the seat belt, check the mirrors, put the key in the steering wheel lock and turn it to start the car.
I'd say the PC is a complicated dinosaur whose days are numbered. The
economics of things, if nothing else, will force the PC to become a much
simpler device to use, operate and own. There is a line being drawn
in what one needs and what one can afford. As long as the brutes are
determining the course of events, this will be the hard rule.
I have been predicting the success of computing appliances for years for these very reasons. Maybe someday my prediction will come true. There is hope. More on that in a future issue. —Ed.
As a contributing editor to LJ with an acknowledged fondness for Perl, I
opened the July 2006 issue on Ruby and, Perl die-hard that I am, groaned.
Despite whatever initial reservations I may have had, I did what I always
do and read the magazine cover to cover. “Ruby as Enterprise
Maik Schmidt on page 58 clearly demonstrated just why Ruby is to be taken
seriously, and I was so intrigued that I'm now working my way through
the Pick-Axe book (Programming Ruby by the Pragmatic Programmers).
Thank you, Linux Journal, for reminding me that the
word “open” not only
refers to my preferred technology, but to my mind, too.
I must say this was a nice article [August 2006]. However, there is one
thing I'm missing in all Linux-related media so far: a test of
server mainboards. Many server-bound extension cards (like the 3ware
RAID controllers or those nice multiport Gigabit cards) are PCI-X,
not PCIe. But, if you start looking for a mainboard suitable for a
Linux system, you are completely on your own. Could you please give an
overview of server-type mainboards that are suitable for Linux at some
time? Something like “these boards work for most Linux distributions,
a few boards are fully supported including built-in hardware
Excellent idea, Sven. —Ed.
I was disappointed to see that there was no Ultimate Linux Laptop [August 2006 Ultimate Linux Box issue]. We work hard to get most of the hardware working perfectly, including the Hot Keys, acpi events and hibernation, and provide a very simple way to get most multimedia to play easily, thanks to programs like MPlayer, Xine and XMMS. Our goal is for customers to open their laptops and get to work. To me that is the Ultimate Linux Laptop.
I would like to make a few comments about your /var/opinion column [August 2006]. We have evaluated many configurations and keep coming back to the Intel Centrino platform. Support for Intel Centrino is very good and is relatively easy to get the necessary components working. We have looked at AMD processors, and 64-bit capability might be nice, but what are the real honest reasons for running a 64-bit version on a laptop where maximum memory capacity is 2GB or 4GB? I can think of only a couple of good situations to run 64-bit Linux on a notebook.
To me, the the real promise of 64-bit computing lies in the ability to
linearly access more than 4GB of RAM, and if notebook hardware isn't
there yet, 64-bit notebooks really are not necessary at this time.
R Cubed Technologies, Inc., Chief Technology Officer
I think software is a bigger problem for 64-bit systems than memory, but I still agree. I run dual-core AMD64 machines for everything but my notebook, which is based on—you guessed it—Intel Centrino. —Ed.
I just read your response to a letter about your Fedora rant. I fully agree that calling Fedora's approach to partition labels boneheaded is not the same as calling the developers boneheaded. However, I made the mistake of telling several police officers that chasing the crowd at a Fourth of July celebration back toward an active lightning storm rather than let them walk “near” the fireworks drop zone that was obviously not going to be used unless and until the storm passed was “idiotic”. I was nearly arrested for maligning a peace officer. The fact that I actually criticized a poor decision, not a person, one that was likely not made by these officers, was totally lost. As I did not want to spend the night of the fourth of July in jail standing up for my right to not actually malign police officers, I beat a hasty retreat.
The distinction between constructive and destructive criticism seems to
depend on whose ox gets gored. Most people read what they wish to hear or
not hear with no connection to what is actually said or written, making
it particularly dangerous to communicate with people with clubs and guns.
I own an ISP, and my primary SMTP server was tagged by one of those services that list exploitable spammers. Not that my SMTP server has been used for SPAM or that I have an open relay capable of being exploited. In fact, a huge block of my IP addresses have been listed by this person, effecting hundreds of my customers.
Many administrators use these RBL resources to filter mail. But is this really a good idea? My customers are suffering an odd sort of “DoS” attack. There are assumptions made in the construction of these lists. An open relay could be hijacked by a spammer, but that doesn't mean it will be. So is it appropriate to conclude that mail coming from that server is SPAM?
This inaccurate policing hurts innocent people. There's little recourse for me and my customers. The operator of the list isn't going to help, and there is no action I can take against him, so now it looks like I'll have to reassign static IP addresses—a time-consuming and expensive process.
ISPs are the primary operator of the Internet. They manage the application services like e-mail and, for the most part, have done so independent of government regulation and oversight. It's important that we self regulate. But inaccurate self regulation will create turmoil in the user community. Unchecked and magnified, it could cause our freedom and independence to be questioned and possibly chipped away by well intentioned, but misguided politicians.
This terror has caused me to rethink some of my policies. I'm at least
thinking more about the impact that my administrative decisions have
Practical Task Scheduling Deployment
July 20, 2016 12:00 pm CDT
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.Register Now!
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
- Tech Tip: Really Simple HTTP Server with Python
- SUSE LLC's SUSE Manager
- My +1 Sword of Productivity
- Non-Linux FOSS: Caffeine!
- Managing Linux Using Puppet
- Returning Values from Bash Functions
- Doing for User Space What We Did for Kernel Space
- Rogue Wave Software's Zend Server
- Google's SwiftShader Released
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