Letters to the Editor
Regarding Phil Hughes' article in the December issue of LJ, please help push further development of Arena. Netscape is huge, slow, and our only option. I now use Lynx for almost all my browsing because Netscape is so slow on my system. Arena runs well, but cannot handle forms, one of the most functional features of a web browser. Like many people, I am not interested in background patterns and enhanced fonts. I want easy access to information, which I am unable to get with Netscape or the current Arena.
—Peter McArthur email@example.com
Linux Journal has a sister publication called WEBsmith™, and its editor, Jon Gross, was recently involved in a World Wide Web conference. We asked him to respond:
I (and many others) agree with your summation of the status of the browser selection available at this point. In December, I was at the 4th International World Wide Web conference in Boston, and a group of us started talking, and decided it was time to start a Free Browser project, modeled on the Linux community, to address exactly this problem. We are putting a mildly cohesive framework together before “going public” but your input is certainly appreciated. The Linux community has much to offer this project, and I think we can definitely build a better mousetrap. A mailing list has been set up. See www.base.com/gordoni/web/www4-bof.html for more information.
—Websmith Magazine Editor, Jonathan Gross
“The chmod Command” by Eric Goebelbecker (LJ #21) was an excellent introduction to the sometimes counterintuitive file and directory permissions of Unix-like operating systems. Near the end, however, there is a misstatement concerning the “sticky bit”. This bit actually has a very important, though obscure, use on Linux systems.
The sticky bit got its name on early Unix systems in the days before demand-paged virtual memory. If the sticky bit of an executable file was set, after the program exited a copy of its text segment was saved in the system's swap area, i.e., it would “stick around” for the next use. This feature was used to make frequently-run programs load a little bit faster. This meaning of the sticky bit is no longer particularly relevant.
Although it is not a part of the POSIX specification, recent System V and Berkeley Unix systems defined a new meaning for the sticky bit. If a directory's sticky bit is set, a file in the directory may be deleted only by the file's owner, by the directory's owner, or by root. This provides an additional measure of security for directories such as /tmp. Linux, of course, supports this useful feature. For example, on my system:
$ ls -ld /tmp drwxrwxrwt 3 root root 1024 Jan 1 09:49 /tmp $ ls -l /tmp -rw------- 1 roman users 0 Jan 1 09:49 bar -rw------- 1 root root 0 Jan 1 09:47 foo $ rm /tmp/bar $ rm /tmp/foo rm: /tmp/foo: Operation not permitted
Without the sticky bit, I would have been able to remove root's file from /tmp.
—Bill Roman firstname.lastname@example.org
Mea Culpa. Thank you for pointing out that mistake. It should never have passed through editing.
I read your article on LISP-Stat last August with much interest, and have just got around to trying it out. One inconsistency: the article claims that the “dld” library is essential. This is not true; if you build Lisp-Stat from scratch, it will use the now-standard “dlopen” method for dynamic loading (based on the ld.so library) if it is present. In fact, “dld” no longer seems to work with current “a.out” style static libraries, let alone ELF libraries.
I compiled the thing for ELF using gcc 2.7.0 and everything worked just great. The compile time is rather long (about an hour on a 486-33 with 20M memory), especially since a lot of the code is in LISP. All of the book examples worked perfectly. A marvellous way to review long-forgotten stats material.
You are doing an excellent job at presenting intriguing applications for Linux. Please keep up the great work!
—Rod Hallsworth email@example.com
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