Letters to the Editor
I really appreciated your recent review of SCO OpenServer. Where I work, we recently had reason to take a computer that had Linux on it and make it into a dual Linux/SCO system. I would like to point out, however, an error in the review. Ken says:
While you're going through this process, OpenServer is merrily overwriting your master boot record and wiping it free of LILO.
While it is true that SCO overwrites LILO if you have it installed on the Master Boot Record (MBR), it is not true that LILO cannot boot SCO. In fact LILO is more than happy to boot SCO. The problem is that SCO expects its own partition to be active or bootable. From the README file for LILO:
Some PC UNIX systems (SCO and Unixware have been reported to exhibit this problem) depend on their partition being active. Such a setup can currently only be obtained by installing LILO as the MBR and making the respective partition active.
If, after you install SCO, you reinstall LILO to the MBR and make the SCO partition bootable, LILO will very easily allow you to choose one or the other at boot time. On our setup, we have Linux installed to /dev/hda2 and SCO on /dev/hda4. Our lilo.conf file, therefore, looks like this:
boot=/dev/hda map=/boot/map install=/boot/boot.b message=/boot/boot.msg prompt timeout=100 # # Linux partition image=/boot/vmlinuz label=linux root=/dev/hda2 read-only # # SCO Unix partition other=/dev/hda4 label=sco table=/dev/hda
Upon bootup, LILO runs and displays our boot.msg file which tells the user how to load either Linux or SCO. This has worked out quite nicely for us. In the past, we had installed SCO on a machine that also used MS-DOS and the only way to switch between the operating systems was by using FDISK to toggle between the partitions. It's nice to see that Linux and its tools are still better than anything else out there. —Tanner Lovelacelovelace@acm.org
Thanks for publishing my message in the “Letters to the Editor” in the December 1997, Issue 44. But you introduced a huge mistake in it, which can have security implications for readers who blindly trust LJ.
The message, published under the title “Big Brother”, mentions the -T option of the Perl interpreter, saying that “-T tests that the file type is text, not binary.” This is ridiculous and I never wrote that. I wrote that every Perl CGI programmer should use the -T option and explained that it refers to tainted mode (man perlsec for details). The -T option (a command-line flag) has nothing to do with the -T function (which indeed tests if a file is text). Any Perl programmer could have caught that mistake.
It seems to me that the treatment of my alert message (remember that anyone on the Internet could execute any command on a machine which uses the scripts you originally published) exhibited two serious flaws:
It was treated too slowly. Most people trust paper more than Usenet News or WWW. Many people probably assumed that the articles in LJ were carefully scrutinized and that the scripts were dependable. LJ had, in my opinion, a responsibility to warn users as soon as possible (at least in the next issue) of the mistake and not through a letter to the editor two issues later.
It is perfectly understandable that you edited my message; I know that my English is quite poor. But you could have sent it back to me for a last check. I do not think it is ethical to modify a message, not on a grammatical point but on a technical one, and to publish it without showing to the readers the edited parts and without sending it to the author for proofreading. —Stephane Bortzmeyer firstname.lastname@example.org
First, let me apologize for your letter getting changed in a way that changed technical content. We try hard not to let this happen. One of our copy editors thought the -T needed more explanation and obviously grabbed the information from the wrong place. I agree he should not have added to the text without consulting you. If you had put as much detail in the first letter as you did above, I don't think he would have felt he needed to add anything. Ultimately, though, I did let his addition pass, and I take full responsibility for the error.
LTE is just about the last column I put together. Consequently, there is not a lot of time to pass it back and forth. It is also the first time I even see the letters, so they can be old. By the time a magazine comes out, the next issue is already at the printer, so errors never get corrected until two issues later. It's too bad, but such is the way of magazine deadlines.
Actually, I think you do quite well with your English —Editor
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
- SUSE LLC's SUSE Manager
- My +1 Sword of Productivity
- Interview with Patrick Volkerding
- Managing Linux Using Puppet
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
- Non-Linux FOSS: Caffeine!
- SuperTuxKart 0.9.2 Released
- Tech Tip: Really Simple HTTP Server with Python
- Parsing an RSS News Feed with a Bash Script
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