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
Getting Started with DevOps - Including New Data on IT Performance from Puppet Labs 2015 State of DevOps Report
August 27, 2015
12:00 PM CDT
DevOps represents a profound change from the way most IT departments have traditionally worked: from siloed teams and high-anxiety releases to everyone collaborating on uneventful and more frequent releases of higher-quality code. It doesn't matter how large or small an organization is, or even whether it's historically slow moving or risk averse — there are ways to adopt DevOps sanely, and get measurable results in just weeks.
Free to Linux Journal readers.Register Now!
- August 2015 Issue of Linux Journal: Programming
- Django Models and Migrations
- Hacking a Safe with Bash
- Secure Server Deployments in Hostile Territory, Part II
- The Controversy Behind Canonical's Intellectual Property Policy
- Huge Package Overhaul for Debian and Ubuntu
- Shashlik - a Tasty New Android Simulator
- Embed Linux in Monitoring and Control Systems
- KDE Reveals Plasma Mobile
- diff -u: What's New in Kernel Development