Letters to the Editor
It's great to see two (count them) of our books reviewed in a single issue. [June, 1997] However, you spelled my name wrong in the “Programming with GNU Software” article by Randyl Britten. I take that as a lapse on my part. I should be in touch with you more often. (I tend to just drop by the booth at occasional conferences.)
—Andy Oram O'Reilly & Associates, Inc .email@example.com
Thanks for being so understanding. Unfortunately—a-hem—I have to take full responsibility for the spelling. It's in my original manuscript and there was no excuse. I offer my apologies.
—Randyl Britten firstname.lastname@example.org
Thanks for your seamless renewal of my subscription, even though I had decided in favour of the new UK Linux World magazine, which has now disappeared after one issue.
LJ continues as well as ever, but I'd like to add my voice to the novice lobby—more stuff for us please. After some easily understood articles on RCS, shell scripting and the like, you've become all technical and clever again. I'd like to see stuff on make and gdb—I've downloaded many applications as source archives only to find the authors assume abilities I don't have. Stuff on the startup and shutdown scripts would also be nice. Anyway, great magazine.
—Bob Smith email@example.com
For every opinion, there's an equal and opposite opinion. Read on —Editor
I would like to see Linux Journal remain a Linux magazine, and not move towards more WWWsmith articles, as you have done in the last few months.
Also, I would like to see LJ become more technical, and move away from the novice corner type stuff, which can easily be found in more current form in places such as Linux Gazette, newsgroups, etc.
When I say technical, I mean articles like Alessandro Rubini's excellent Kernel Korner columns. Or detailed articles on Perl and shell scripting, hardware ports to alpha or networking (the article on ghosting in June is a nice detailed article). [“Ghosting Onto the Net”, Scott Steadman, June 1997]
I understand that Linux is new in some sense, and you may feel justified in having the “simpler” stuff in there, so I offer my feedback as simply another data point for your consideration.
—Les Schaffer firstname.lastname@example.org
We strive to be balanced, offering both a Kernel Korner and a Linux Apprentice column each month —Editor
I very much enjoyed your keyboard article in the June Linux Journal. [“Consistent Keyboard Configuration”, John Bunch] The article as published by LJ had several typos. I was able to get most everything to work as described. Did not have much luck with the arrow keys in Emacs running in an xterm. I have not been able to determine the cause of this. Something to do with the xterm translations?
—W. Paul Mills email@example.com
Note that on page 54, six lines are broken, forcing “Arrow” onto the following line. These lines should be joined so that “Arrow” is inside the comment. Also note that the escape sequences are incorrect. The double backslashes should all be single backslashes, so for example, the line for F117 should read:
string F117 = "\033\033[A" # Alt-Up Arrow
This type of error is present throughout the article. On page 57, the key translation lines have two problems. First, all of the double backslashes should be changed to single backslashes. Second, the lines were broken improperly. The first seven lines are shown in Listing 1.
Copy the rest of the lines from the man page for xterm(1). Every line of the translations, except for the last line, should end with either \n\ or \. Typographical errors here are very serious, because they cause problems without generating any error messages.
Let me know if this helps.
—John F. Bunch firstname.lastname@example.org
I have a little big complaint about LJ Issue 37, in particular the native PowerPC article [“Native Linux on the PowerPC”, Cort Dougan, May 1997]. There was a performance listing which compared MKLinux, native Linux-PPC and OSF and some Sun operating systems, but the table was typeset all wrong. Being so cryptic it is almost, if not completely, useless since one cannot tell which digits belong to which columns. If you have so many problems getting your magazine printed correctly, you should probably hire better people, like me for instance.
—Ville Voutilainen email@example.com
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!
- Google's SwiftShader Released
- Interview with Patrick Volkerding
- Tech Tip: Really Simple HTTP Server with Python
- My +1 Sword of Productivity
- SUSE LLC's SUSE Manager
- Managing Linux Using Puppet
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
- Non-Linux FOSS: Caffeine!
- SuperTuxKart 0.9.2 Released
- Returning Values from Bash Functions
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