|
|
|
Our sponsors make financial contributions toward the costs of publishing Linux Gazette. If you would like to become a sponsor of LG, e-mail us at [email protected].
Linux Gazette is a non-commercial, freely available publication and will remain that way. Show your support by using the products of our sponsors and publisher. To subscribe to Linux Journal, click here.
The Whole Damn Thing 1 (text)
The Whole Damn Thing 2 (HTML)
are files containing the entire issue: one in text format, one in HTML.
They are provided
strictly as a way to save the contents as one file for later printing in
the format of your choice;
there is no guarantee of working links in the HTML version.
Got any great ideas for improvements! Send your comments, criticisms, suggestions and ideas.
This page written and maintained by the Editor of Linux Gazette, [email protected]
Write the Gazette at [email protected]
|
Contents: |
Date: Sun, 30 Nov 1997 14:08:24 +0000
From: David Stern [email protected]
Subject: Help Wanted -- Article Ideas
I'm at that point in my Linux development where I'm comfortable with the basics, and am venturing out to learn and discover the myriad of alternatives which exist. While I appreciate the many alternatives, it can be difficult for someone with little experience to decide which MUA, MTA, proxy..is most suitable. When each individual must personally begin anew to evaluate the field, unnecessary repetion of efforts results and often a selection is made based on incomplete information. When the user later discovers a more suitable alternative, and possibly later another, a glutton of inefficiency results.
On that note, I'd like to suggest "head-to-head" comparision articles of similar programs. A chart with columns and rows which represent the programs and the features would be invaluable for Linux users ranging from completely new to advanced, thus I would consider that a necessity. Optionally, different recognitions may be given for exceptional achievement. Notes on individual programs or categories, and a brief summary would probably be required.
If thorough analytical evaluations were performed, this may exceed the resources and other imposed limitations of Linux Gazzette, but I'm not asking for that much depth. I'm just looking for a cursory examination of programs with a comparison of features in a "side-by-side" format.
While I appreciate the reviews of individual programs, and enjoy the deeper attention which can be given, there is an ever-increasing number of alternatives available to the Linux user, and summary comparisons of programs is now a very real need, and the importance will only increase with time.
Please consider adding a side by side summary comparison of programs feature article. I think this would not only make Linux Gazzette better than it already is, but also expand the readership. Thanks and sincerely,
David Stern
Date: Fri, 28 Nov 1997 08:35:04
From: Erwin Penders [email protected]
Subject: passwd shadow convert problem
I am running RedHat 4.2 with normal passwords since a couple of month's. Now i read the shadow-password howto and i wanted this also to work on my system. After reading the manual i went to a 'blank' redhat system with a couple of users and i ran /usr/sbin/pwconv5 and the shadow was up and running fine. BUT on another system (same as the first) but with a lot more users the pwconv5 runs but won't stop. It makes an empty shadow file and i have to kill pwconv5 because it isn't doing anything.
I then copied the passwd file from the second to the first system and tried on the first system... and the same problem.. no shadow.
Can anybody tell me what i do wrong !?
Thanks everybody.
Erwin Penders
Date: Fri, 21 Nov 1997 01:39:51
From: Manish Oberoi [email protected]
Subject: printing problems
Anyone that can help me. I'd love to hear it. I try running the lpr, but everytime I get no name for local machine. How do I set this and/or what is the problem.
Manish Oberoi
Date: Wed, 10 Dec 1997 20:33:38 -0800
From: Nolan Zak [email protected]
Subject: Help Wanted!
I'm running RH 4.2 with kernel 2.0.30 on an Intel P90, I've only been at this for a couple weeks so go easy on me if this is a stupid question. :)
I'm trying to get ppp to working for dialing into my ISP, but no matter what I do it disconnects.
Here's a small description of what is going on: I set up /dev/modem --> /dev/cua1 and enabled full permissions on both. Set the jumpers on my modem for com2, irq3. Ran setserial to setup the proper device settings. Re-compiled the kernel for ppp. checked my modem init strings.
Now, no matter what I use (minicom, shell scripts, netcfg), the chat script goes through the proper procedure and starts up ppp on the server side, passes control to pppd, which connects ppp0 <--> /dev/modem, and after that, the modem hangs up (within about 2 seconds).
I've tried all kinds of command line args to pppd, with no luck. Can anyone help me out here?
Later, Nolan
My webpage--> http://users.uniserve.com/~nzak/welcome.htm
Date: Thu, 11 Dec 1997 22:20:54 -0500
From: "atm" [email protected]
Subject: Linux and routing
I have heard that you can connect a LAN to the internet via just 1 assigned IP address. This is what I am planning on doing, however, I do not know how one would go about doing it, and I would like to ask you if you could do an article about it. (Any takers among our readers? --Editor)
I plan on getting a cable modem soon, so the bandwidth would be pretty high, so that is why I have decided to try to make this connection provide for my whole house via a LAN connection in my home. What I have read is that you could use the private IPs, meaning the 10.x.x.x or so, 192.168.x.x and some others for the IP of the LAN and have these connect to some box (the LINUX box?) that would provide its connection to the internet to the inside LAN connected to the box. Is the problem that you would have to route the assigned address to the private IPs for the LAN use. I have also read that this would slow down the connection a bit or something, but that is a price I am willing to pay. So, the summary of the question is how would I be able to connect many computers to the internet via just 1 assigned IP address? I would like to be able to do it using my LINUX box connected to the internet via cable modem, and to my LAN via an Ethernet link. Any help is much appreciated, thanks.
Date: Fri, 12 Dec 1997 10:41:54 +0000
From: John Fisher [email protected]
Subject: Of Mouse and Men (no Cheese)
A very new boy to all this I am :-)
Problem--
Using a 486 pc & Slackware I'm unable to use my mouse due to this error:
Too many symbolic links encountered /dev/console
Would very much apprecaite some help.
Regards
John Fisher
Date: Fri, 12 Dec 1997 09:23:14 -0500
From: [email protected]
Subject: try to use a 386 computer
I am new in the Linux world. How new? I am so new that I have just ordered a Redhat release 5.0. Though this is a new world I am very glad I am one of you, the Linux lovers.
I used to have a 386 25 MHz computer. Not long time ago I bought a Pentium 200 MHz computer. Since then I have not played with 386. Is there any easy and economical way to connect the 386 to the Pentinum computer where I will install the Release 5.0. If so, what I can do with it or at lease what I can learn from it.
Thank you very much. Waiting for talking to you.
Date: Tue, 16 Dec 1997 08:44:15 -0700
From: Doug Milligan [email protected]
Subject: Help Wanted: RedHat 5.0 sound
Have installed RedHat 5.0 and configured the sound card using sndconfig. All went well and I heard the demo sound bite of Linus. However, I have never heard another sound since. When browsing web sites with sound, no audio is played. Anyone have any ideas?
Doug Milligan
Date: Thu, 25 Dec 1997 12:45:29 -0800 (PST)
From: karl rossing [email protected]
Subject: LINUX AS A PDT
I was wondering if it is possble to get windows 95/NT to authenticate to LINUX (using nis or nis+). I'm really getting tired of adding accounts on the nt boxes for the linux boxes (for smb)...Is there any commercial software availible?
I know of d-sync [http://www.m-tech.ab.ca/psynch/index.html] and NSGINA [http://www.dcs.qmw.ac.uk/~williams/] which seems a bit of work to setup...
I'm not really looking for passwd syncronisation, i'd like to consolidate it to the linux box, because the users use both linux/95/nt.
nuff said
Thanks,
Karl Rossing
Date: Sun, 04 Jan 1998 23:54:37 +0100
From: Gabriele Giansante [email protected]
Subject: Perl and HTML
please pardon me for my bad english. I need help for one exam in my university. I have to do a script CGI in Perl and I have to recall with HTML. I have done all. Perl compile without errors the script but when I run the HTML page and choose the link to the script, I obtain only a list of script. Why is it? I put in the Perl script the line #!/usr/local/bin/perl. I know this is used to indicate the Perl compiler. I work on Linux RedHat 4.1 trying to execute the script with browser ARENA and NETSCAPE. I enjoy if you can help me. I see Linux Gazette now the first time and like it because I find many help on my questions. Pardon my english and Thank you.
Date: Sun, 7 Dec 1997 11:15:36 PST
From: Marty Leisner [email protected]
Subject: some requests
When including more than a few lines of code, include a link to the code (i.e. the original source files).
In issue 22, I had problems with the line breaks cutting and pasting a program from netscape into a window, saving and recompiling.
Marty
Date: Wed, 10 Dec 1997 13:36:05 -0600 (CST)
From: Justin Dossey [email protected]
Subject: Help for trival problems
I notice that a lot of people write the Gazette with fairly trivial problems that are difficult to solve via non-interactive media (email). I'd like to remind some and inform others of the Linux Internet Support Cooperative. An excerpt from the LISC home page (http://www.linpeople.org) says:
"Since 1994, a small and somewhat foolish group of Linux system users and administrators have been giving free technical support for Linux under the name LinPeople, on Internet Relay Chat (IRC). With Linux being a free operating system, it only seemed appropriate to provide a free means of supporting it.Since 1994, a small and somewhat foolish group of Linux system users and administrators have been giving free technical support for Linux under the name LinPeople, on Internet Relay Chat (IRC). With Linux being a free operating system, it only seemed appropriate to provide a free means of supporting it."
It sometimes seems to linux users with problems that no one is interested in helping them. They post to news and don't get a reply, they send email to the Gazette and feel ignored. When you have a problem, especially if you suspect that others might have the same, try LISC. With most internet-connected Linux boxen, it's just a matter of typing:
ircii irc.linpeople.org /join #linpeople
and then asking the question.
The people at LISC will do what they can to solve your problem, teaching you about Linux at the same time.
Justin Dossey
Date: Thu, 11 Dec 1997 06:35:00 -0500 (EST)
From: Benjmin Lee Adamson [email protected]
Subject: Ah... Goodstuff...
I just found the Linux Gazette... I haven't read all of them yet, but I really dig what I've found so far... :)
Really really really really goodstuff. :)
Date: Fri, 12 Dec 1997 01:03:04 +0100
From: Diego Cortassa [email protected]
Subject: Netscape Hidden tips:w
I saw Ivan Griffin's 'Netscape Hidden "Easter Eggs"' tip on Linux Gazette Issue 23 and I've got one more cool special URL:
about:mozilla
Read the message and take a look to the N animation while downloading a web page ! :-)
P.S. Linux Gazette is GREAT !!!!!!!!!
Diego Cortassa
Date: Sat, 20 Dec 1997 06:13:59 -0700
From: Sengan Baring-Gould [email protected]
Subject: Loading times
Hi,
Thanks for the great work at linuxgazette.com. I'd like to suggest an improvement: that the loading does not get paused while the massive Linux Gazette banner at the top of the page gets loaded... it's a pain on a slow link.
Thanks
Sengan
(You might try turning off the display of graphical images using your browser. Alternatively, you can wait a short while and then stop the loading. Although the graphics may be incomplete, the text should be there. --Editor)
Date: Sun, 21 Dec 1997 20:03:32 +0100
From: Ingo Oeser [email protected]
Subject: Kewl new cover image
The subject just says what I would like to tell you: The cover image (the one with "Linux Gazette" inside) really looks great!
cu
Ingo
Date: Tue, 30 Dec 1997 09:52:10 -0500 (EST)
From: Kragen Sittler [email protected]
Subject: http://www.operasoftware.com/alt_os.html
Using WinNT at work, I discovered this fabulous browser called Opera. It's the fastest web browser I've ever used, including Lynx, but has most of the features I want from Netscape. Also, it's fairly small -- right now, my Opera process is under 5000K, even though it has six fairly heavy web-pages open, and the download size just grew over one megabyte.
They're doing this funky pledge-drive thing where they ask people to promise to buy copies of Opera for $35 for other platforms -- Mac, Be, OS/2, and Linux -- before they've started developing Opera for those platforms. They say they haven't gotten much support from the Linux community -- perhaps it's because not many people have heard of them?
(I learned about Opera from Borland's web pages, btw.)
Kragen
Date: Tue, 30 Dec 1997 20:37:26 +0530
From: Sudhir Krishnan [email protected]
Subject: Can I help you?
I have been using Linux for more than a year now. There's no other OS that fascinates me more than Linux! I have been programming in Linux using gcc. I have made my own text editor for Linux, with various modes for emulating emacs, vi and turbo c editor keystrokes. Also there are modes for C, C++ and Pascal programs so that the keywords are highlighted. My home page's location is:
http://www.geocities.com/SiliconValley/Pines/9147/
Here I have an entire page dedicated to Linux tips and help, meant for the Linux newbie. There are sections regarding PPP configuration, kernel compilation, installation and partitioning etc. Please let me know if any of these could be of help in any way.
regards,
- sud -
Date: Wed, 31 Dec 1997 14:23:26 PST
From: Marty Leisner [email protected]
Subject: Troff/Tex debate
I read Andrew Young's ([email protected]) letter in December, then read Larry Ayers Issue 22 column...
I take issue with two of Larry's statements: "Groff is the epitome of the non-user-friendly and cryptic unix command-line tool." Larry also says: "Learning to use Groff on a Linux system might be an uphill battle, though Linux software developers must have learned enough of it at one time or other, as most programs come with Groff-tagged man-page files. Groff's apparent opacity and difficulty make LaTeX look easy in contrast!"
I'm not sure LaTeX is an improvement in these areas. I've used troff for over 10 years and recently started to use LaTeX (in fact, many times LaTeX is far more obscure then troff). And there are a few features in LaTeX I miss (like:
.sy stat \n(.F | fgrep Change >change.time .so change.time .sy rm change.time
to get the document time into the document (as opposed to the "TeX" time, or having to manually change the date, which is invariably wrong. I have a makefile which puts this in a file, then includes the file)
The biggest problem is the lack of reference materials for troff. I've used Unix Text Processing (Dougherty/O'Reilly) which Andrew mentions...I've never seen or heard of the other book...
There are some references for troff/pic/indexing tools on: http://cm.bell-labs.com/cm/cs/cstr.html (including the one mentioned later) There are also good papers on troff in: 4.4BSD User's Supplementary Documents (I'm not sure which ones can be redistributed and which ones are only in the book).
FYI, from Eric Raymond's online jargon file: :troff:: /T'rof/ or /trof/ /n./ [Unix] The gray eminence of Unix text processing; a formatting and phototypesetting program, written originally in PDP-11 assembler and then in barely-structured early C by the late Joseph Ossanna, modeled after the earlier ROFF which was in turn modeled after Multics' RUNOFF by Jerome Saltzer (*that* name came from the expression "to run off a copy"). A companion program, {nroff}, formats output for terminals and line printers.
In 1979, Brian Kernighan modified troff so that it could drive phototypesetters other than the Graphic Systems CAT. His paper describing that work ("A Typesetter-independent troff," AT&T CSTR #97) explains troff's durability. After discussing the program's "obvious deficiencies -- a rebarbative input syntax, mysterious and undocumented properties in some areas, and a voracious appetite for computer resources" and noting the ugliness and extreme hairiness of the code and internals, Kernighan concludes:
None of these remarks should be taken as denigrating Ossanna's accomplishment with TROFF. It has proven a remarkably robust tool, taking unbelievable abuse from a variety of preprocessors and being forced into uses that were never conceived of in the original design, all with considerable grace under fire.The success of {{TeX}} and desktop publishing systems have reduced `troff''s relative importance, but this tribute perfectly captures the strengths that secured `troff' a place in hacker folklore; indeed, it could be taken more generally as an indication of those qualities of good programs that, in the long run, hackers most admire.
marty
Date: Fri, 02 Jan 1998 15:33:15 +0100
From: Wolfgang Laun Wolfgang
[email protected]
Subject: Linux Gazette/GNU/Linux Benchmarking
A recent LG article by André Balsa on benchmarking provided interesting material to me.
Having a little experience with benchmarks myself (some of it while checking optimizing efforts myself on a compiler) I have found that caching on Intel CPUs can significantly distort results. In the first part you mention that caching can be disabled via the BIOS setup. If you write your own benchmarks (or have the source), you could also consider using the pertaining CPU instructions, easily inserted using gcc's _asm_. This could be used to keep caching up while running the code you want to measure and to flush between cycles, in order not to "carry over" a cache bonus from the previous iteration.
Wolfgang
![[ TABLE OF
CONTENTS ]](../gx/indexnew.gif)
![[ FRONT
PAGE ]](../gx/homenew.gif)
More 2¢ Tips!
Followup to PostScript and VC Key Sequences (LG#23)
Date: Thu, 4 Dec 1997 16:43:47 +0000 (GMT)
From: Ivan Griffin [email protected]
I just wanted to point out that some of my 2cent tips in Issue 23 of the Linux Gazettte (December, 1997) were a little funky in their appearance.
While it doesn't really matter at all with the VC key sequences, it may affect someone's understanding of the bad (imho) PostScript generated by the Microsoft PS driver.
In this, the PostScript should have been pre-formatted using the appropriate HTML tags. Basically, the line
The Mailbag!
30000 VM?
Is on its own, and not part of any other line.
All that you have to do to remove this artificial restriction on
viewing/converting the PostScript with ghostscript is to delete this line.
On another note, someone asked me where those key sequences come from. If you check either keyboard.c or keyb_m68k.c, you will find an array of function pointers called spec_fn_table[].
This array contains a list of functions to execute when certain key combinations are received... The key combinations listed in the 2cent tips execute the functions show_state(), show_mem() and show_regs()
You will find the source for function show_state() in /usr/src/linux/kernel/sched.c
show_mem() is in /usr/src/linux/arch/i386/mm/init.c
and show_regs() is in /usr/src/linux/arch/i386/kernel/process.c
Best Regards,
Ivan.
PostScript $0.02 follow-up
Date: Wed, 3 Dec 1997 13:51:48 -0500 (EST)
From: Kyle Ferrio [email protected]
In the December issue of LG, Ivan Griffin suggests using pstops from the psutils package to accomplish two-up printing, gives a helpful example for A4 paper, and points out that the command line needs to be tweaked for US letter. If you're using US letter paper, then psnup (also part of psutils) already does the job nicely with no uncomfortable thinking. It might even work for A4, but I haven't checked. The psutils are generally very handy, so folks might want to have a look. An RPM is available in /contrib at ftp.redhat.com, for instance. Be advised that there seem to be at least two very distinct packages called psutils floating around Net-space.
Yet another cheap tip.
Date: Sun, 30 Nov 1997 03:48:40 -0800 (PST)
From: Gary Johnson [email protected]
Sorry if it has been mentioned before, I thought I would throw it in the Gazette pile just in case it hasn't . . .
Cat proof keyboard.
Switching to an unused virtual console is a quick way to blank the screen and disable the keyboard. To make one available try
setterm -clear > /dev/tty12
on startup. ALT F12 flips to it, or ALT CTRL F12 from X.
Because there (probably) isn't a login running on that VC it
doesn't do much, which can be a feature. A smart cat may still
luck into a troublesome key sequence.
2 cent tip - dosemu
Date: Fri, 5 Dec 1997 00:55:55 -0500
From: Joey Hess [email protected]
I occasionally use dosemu, mainly to run some games I can't live without, but I hate seeing the C:\> prompt. So I thought it'd be nice if there were a way to tell dosemu what dos command to run, and it would run that command on bootup. Here's a perl script that does just that. Read the comments at the top, they explain some changes you need to make on the dos side of this. The basic idea is, make a ~/dos_do.bat file, that contains the command you want to run, and use lredir to let dosemu see your home directory. Then run the batch file.
#!/usr/bin/perl
#
# This runs dosemu.
#
# Any parameters psecified after "--" will be passed in to dosemu to be
# run as dos commands.
#
# Setup: add to autoexec.emu:
# lredir.com h: linux\fs\${home}
# if exist h:\dos_do.bat call h:\dos_do.bat
#
# GPL Copyright 1996, 1997 Joey Hess
# Split params into dosemu parameters and dos commands.
while ($a=shift @ARGV) {
if ($a=~m/--/ ne undef) { last }
$dosemu_command_line.="$a ";
}
$dos_command_line=join(' ',@ARGV);
$dos_command_line=~s/;/\r\n/g;
open (OUT,">$ENV{HOME}/dos_do.bat") || exit print "$ENV{HOME}/dos_do.bat:
$!";
if ($dos_command_line) {
print OUT "$dos_command_line\r\n"; # note dos CR LF
print OUT "exitemu\r\n";
}
close OUT;
system "/usr/bin/dos $dosemu_command_line";
unlink "$ENV{HOME}/dos_do.bat";
Re: 2c Tip "Finding What You Want with find"
Date: Wed, 03 Dec 1997 16:03:30 +0100
From: Mike Neuhauser [email protected]
Jon Rabone, [email protected], wrote in the December 97 issue of LG:
> In the October 97 issue, Dave Nelson suggests using
> find . -type f -exec grep "string" /dev/null {} \;
> to persuade grep to print the filenames that it finds the search
> expression in. This starts up a grep for each file, however. A
> shorter
and more efficient way of doing it uses backticks:
>
> grep "string" `find . -type f`
>
> Note however, that if the find matches a large number of files you
> may
exceed a command line buffer in the shell and cause it to complain.
To avoid an overflow of the command line buffer use:
find . -type f | xargs grep "string"
This may give problems if filenames contain white space (e.g. touch
"test file") -- to avoid use:
find . -type f -print0 | xargs -0 grep "string"
Note also that find doesn't follow symbolic links to directories per
default. Using find with the option -follow does the trick (find .
-follow ...).
Re: Finding What You Want with find
Date: 5 Dec 1997 17:47:50 -0000
From: Dale K. Hawkins [email protected]
find . -type f -exec grep "string" /dev/null {} \;
That is how I used to run things too, but a friend showed me the xargs program. Very nice. So one could turn the above statement to something like:
find . -type f | xargs fgrep "string" /dev/nullAgain, the /dev/null will force the name of the file to be printed (in the unlikely case that find only found one file name). This has the benefit of not invoking a new grep process each time.
But for a really slick (and much faster search) try this:
locate $PWD | grep "^$PWD" |xargs fgrep "string" /dev/nullThis assumes that your locate database is current for the directory to be searched. It does have a problem though: it tries to grep everything, including directories!
locate $PWD | grep "^$PWD" |xargs -ifilename sh -c \ "if [ -f filename ]; then echo filename; fi " | \ xargs fgrep "string" /dev/nullAnd as an exercise for the reader: Take a look at lesspipe.sh (if it is installed; download it otherwise!) See if you can create a shell script called supercat (or something) which preprocesses the input to prevent grep'ing binary files, etc.
You gotta love UNIX and especially Linux!
-Dale K. Hawkins
Finding What You Want with find Part III
Date: Thu, 11 Dec 1997 17:12:46 +0100 (MET)
From: Axel Dietrich [email protected]
>In the October 97 issue, Dave Nelson suggests using
>
> find . -type f -exec grep "string" /dev/null {} \;
>
>to persuade grep to print the filenames that it finds the search
>expression in.
Besides Jon Rabone's "shorter and more efficient" version in the December 97 issue using backticks:
grep "string" `find . -type f`the following variant can be used without the danger of exceeding a command line buffer limit:
find . -type f -exec grep -l "string" {} \;
The "-l" switch tells grep to show the name of the file in which
"string" was found.
To limit such a search on selected files I use a combination of the -type and -name switches.
find . \( -type f -name "*\.html" \) -exec grep -l "string" {} \;
This searches in all files with the suffix "html" for the string
"string" and outputs the name(s) of the file(s) in which "string"
was found.
Axel
More on finding
Date: Tue, 16 Dec 1997 14:12:57 +0100 (MET)
From: Alexander Larsson [email protected]
In the December 97 issue Jon Rabone wrote:
------------------------------------
This starts up a grep for each file, however. A shorter and
more efficient way of doing it uses backticks:
grep "string" `find . -type f`Note however, that if the find matches a large number of files you may exceed a command line buffer in the shell and cause it to complain.
A better way would be to use:
find . -type f | xargs grep "string"which starts up a new grep everytime the command line buffer is full.
/ Alex
Another way to find
Date: Sat, 27 Dec 1997 12:06:47 -0500
From: [email protected]
In an article in the LG, it was suggested that, in order to cut down on having to fork(2)/exec(2) for each grep when you're searching through a tree of files, you use the shell's capability of command substitution (for the file names paramaters to the grep command) with "backquotes," "grave accents," "backticks," etc. as they are commonly called ("`"). In that little tidbit, it is noted that it has the limitation of the system-wide imposed limit on number of arguments, and I possibly think there might be a length issue as well (too many total bytes). Enter xargs(1).
The job of the xargs command is to read its stdin and use the resultant strings as arguments to some command prefix (such as "grep -n somestring"), much like backquotes work. However, the xargs program is "aware of" the limitations imposed by the system, and will run the command prefix as many times as necessary to exhaust the list provided on stdin, while on each run giving the command only the maximum number of arguments and the maximum byte count (?) that an exec(2) call can handle. Thus, provided that the program named in the command prefix follows the UNIX program protocol of iterating over its non-option arguments, one can search one, hundreds, thousands, even millions of files with a line like:
find / -type f -print | xargs grep -n 'where is that string?'As usual, consult your favorite source of documentation, such as your local man pages, for ways to get even craftier with xargs.
Yet another way to find
Date: Mon, 29 Dec 1997 10:49:52 +0100
From: Guido Socher [email protected]
In recent Linux Gazette issues there were a couple of ideas on how to recursively grep around files and directories. Very useful, but it can cause problems when you have binaries (e.g some executable) in the directories that contain somewhere the string that you are looking for. The result is most of the time an unusable terminal because some control character from the binary file has set it to graphics mode. There are, of course, ways to make the terminal readable again but the best is to avoid it in the first place.
Let's just remove the unprintable characters. They are unreadable anyway! The command
sed -e 's/[^ -~][^ -~]*/ /g'removes multiple occurrences of non printable/control characters and replaces them by a single space. The [^ -~] matches all characters not in the ASCII range from SPACE to Tilde. This command can be easily combined (using a pipe) with the find and grep. Here is a little script, I called it grepfind, that does it all:
#!/bin/sh
#save this in a file called grepfind and do a "chmod 755 grepfind"
#
if test $# = 0 -o "$1" = "-h" -o "$1" = "--help" ; then
echo ' grepfind -- recursively descends directories and egrep all files '
echo ''
echo ' Usage: grepfind [--help][-h][start_directory] egrep_search_pattern'
echo ''
echo ' The current directory is used as start_directory if parameter'
echo ' start_directory is omitted. The search is case insensitive.'
echo ' Multiple occurrences of control characters are replaced by a single'
echo ' space. This makes it possible to grep around in files that contain'
echo ' binary data and strings without setting the terminal accidently '
echo ' to graphics mode.'
echo ''
echo ' Example: grepfind /home "hello world" '
else
if [ "$2" = "" ]; then
find . -type f -exec egrep -i "$1" /dev/null {} \; | sed -e 's/[^ -~][^
-~]*/ /g'
else
if [ -d "$1" ];then
find $1 -type f -exec egrep -i "$2" /dev/null {} \; | sed -e 's/[^
-~][^ -~]*/ /g'
else
echo "ERROR: $1 is not a directory"
fi
fi
fi
#__END__OF_grepfind
A final(?) way to find
Date: Wed, 31 Dec 1997 14:31:57 PST
From: Marty Leisner [email protected]
In the last few months, there's been a few letters (by Dave Nelson, Jon Rabone, some more) on how to grep with file names.
Instead of using the trick:
find . type f -exec grep "string" /dev/null {} \;
and other variatiants, or doing
grep "string" $(find . -type f)
1) use the -H option of grep 2.1 (to print file names, not in 2.0)
find . -type f | xargs grep <pattern> -H
Marty
Re: I need some help
Date: Sun, 7 Dec 1997 14:25:25 +0100 (MET)
From: Roland Smith [email protected]
Javier,
In response to your article in the mailbag of the dec. 97 Linux Gazette:
You need to set the environment variable MOZILLA to the directory containing Netscape's files.
There are two ways of doing this: You can type `export MOZILLA_HOME=/usr/local/netscape' every time you start your computer, or you can edit /etc/profile. This is a file read by the bash shell. Add the following to this file (assuming the Netscape stuff is in /usr/local/netscape):
MOZILLA_HOME="/usr/local/netscape" export MOZILLA_HOMEYou also need to add an entry for Netscape to your window-manager's initialization file, so it shows on the toolbar and/or menu. How to do this depends on the window manager you use.
If you're using fvwm2-95, add the following to the .fvwm2rc95 file in your home directory:
# add to this menu: AddToMenu "Utilities" "Utilities" Title + "Netscape%mini-nscape.xpm%" Exec netscape -geometry 931x683+54+9 &Regards, Roland
Spinning Down Unused HDs
Date: Mon, 08 Dec 1997 14:21:31 -0500
From: Peter S Galbraith [email protected]
In the December issue of LG tips, you discuss the hdparm command to spin down disks. I tried this on my old SCSI disk:
bash-2.01# hdparm -S6 /dev/sdb /dev/sdb: operation not supported on SCSI disksToo bad! I use the `scsi-idle' kernel patch to do this very same thing on SCSI, and I was eager to try your trick to finally stop having to patch the kernel at evey upgrade.
Too bad it don't seem to work on SCSI disks (it's also strange that the man page doesn't say this...)
LG Tips and Tricks (Netscape)
Date: Fri, 12 Dec 1997 02:56:16 -0600
From: Christian J Carlson [email protected]
* Date: Sun, 9 Nov 1997 22:00:31 +0000 (GMT)
* From: Ivan Griffin [email protected]
*
* These special URLs do interesting things in Netscape Navigator and
Communicator.
*
* about:cache gives details on your cache
* about:global gives details about global history
* about:memory-cache
* about:image-cache
* about:document
* about:hype
* about:plugins
* about:editfilenew
*
* view-source:URL opens source window of the URL
*
* Ctrl-Alt-F take you to an interesting site :-)
This appeared in Linux Gazette, December 1997. There is one more way cool easter egg that's in Netscape.
First, type "about:mozilla" to get the Mozilla easter egg. Then, watch your "N" in the upper right hand corner of Netscape. Whenever you access a website, Mozilla himself will appear instead of the boring flying stars, etc. As far as I know, this has been in every version of Netscape since at least version 2.0. Of course, this only works in the Linux version (I don't know about other *nix versions) of Netscape, NOT Windows95 :).
Christian J. Carlson
Easter Eggs in Netscape
Date: Tue, 30 Dec 1997 0:47:12 +1100 (EADT)
From: Michael Lake [email protected]
I have just been reading the Linux gazette Issue 23 about the easter eggs in Netscape and thought that I would try some URL's of my own. I am using Netscape 3.01 for Linux. A little experimentation found the following--
about:foo
The message that is returned is: Whatchew talkin' 'bout, Willis? Instead of foo you can use anything that is not understandable to Netscape.
A more interesting one that I tried is--
about:mozilla
This gives a very interesting quotation which I will leave to the reader to discover.
Enjoying the Linux Gazette immensely,
Best Regards,
Michael Lake
Sydney, Australia
Calculator Tip
Date: Sun, 14 Dec 1997 19:23:55 -0500
From: Michael McLay [email protected]
The Issue #21 and #23 tips column gave tips for doing calculations without having to fire up a heavyweight GUI calculator. It is very handy to be able to do all the number entry through the command line, but I was surprised to see perl and awk used in the two examples. The bc has been around forever in Unix and would be the logical first choice to many oldtimers. And bc can do the calculations to any precision desired if that is important.
Another good option is Python. Python can be run in an interactive mode like bc, so previous calculations can saved as variables and reused. Python also can be built so that past lines can be edited using the standard GNU readline library editing operations. For instance, in the following interactive sequence the previous-line key will restore the last executed line to the prompt and the line edit keys, such as backward-char and delete can then be used to edit the line.
~: python
Python 1.5b2 (#2, Dec 12 1997, 16:13:12) [GCC 2.7.2] on linux2
Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam
>>> a = (10+3)/7
>>> a
1
>>> a = (10.+3)/7
>>> a
1.85714285714
>>> a/32
0.0580357142857
>>> "it takes %7.2f percent" % a
'it takes 1.86 percent'
>>> "it takes %-7.2f percent" % a
'it takes 1.86 percent'
>>> from Numeric import *
>>> b = array(arange(12))
>>> b.shape = 3,4
>>> b
array([[ 0, 1, 2, 3],
[ 4, 5, 6, 7],
[ 8, 9, 10, 11]])
>>> b/a
array([[ 0. , 0.53846154, 1.07692308, 1.61538462],
[ 2.15384615, 2.69230769, 3.23076923, 3.76923077],
[ 4.30769231, 4.84615385, 5.38461538, 5.92307692]])
>>>
This example also shows the Python Numeric[1] module being used at the
command line. Any Python module that is installed with the
interpreter can be imported and used in the interactive mode.
Of course if you want to make Python do a one-liner from the command line that is possible also:
~: python -c "print 34./33" 1.0303030303or to format the output:
~: python -c "print 'eat %3.4f %s' % (1.444e5/32,'more fish')" eat 4512.5000 more fish[1] The Numeric module in this example is not built into the standard distribution. See the matrix-sig page for details on how to add it to the module library if you can't find it on your system.
Security script
Date: Mon, 15 Dec 1997 20:49:53 -0600 (CST)
From: Corey G [email protected]
Often when I leave my machine connected to the Internet for prolonged periods I worry about hackers. I wanted a program that would know if a process was started by anyone, including root, that was not originally on the machine.
This caused me to program this script. I dont know if something similar exists but I have tested this very throughly and it works rather well. It can be frustrating at times when you are active on the machine but works very well for idle times.
HOW IT WORKS:
This scripts grabs all the processes when first invoked and saves them to a temporary file. After a default of 10 seconds the process table is checked against any new processes that were started. If these processes were not listed in the "TRUSTED_ITEMS" variable they will be killed immediately.
USAGE:
Once you have all the necessary processes running on your machine start the script as root. It will make the necessary directories on the machine in a safer place than just /tmp. I have created two variables named "TRUSTED_ITEMS" and "TRUSTED_USERS". These can be used to ignore some users or programs that you never want killed. Be careful since sometimes you will need to include more than one item for some programs. For example, if you dont want xterms killed you must add "xterm" and "bash" if you are running bash as your default shell.
Note: When testing this script make certain that nothing important is running. I take no blame for any wrong doing from this script.
To start the script: nohup ./secmach &
I am always looking for ways to improve this script so feel free to e-mail your comments or suggestions to me.
Good Luck !!!
#!/bin/sh
# Secmach - security program
# v1.0 12-14-97
# By: Corey Gaffney
export PATH=/usr/bin:/bin:/sbin
COUNTER=0
LOCATION=/usr/secmach
CHECK_TIME=10
TRUSTED=/usr/secmach/trusted
UNTRUSTED=/usr/secmach/untrusted
DIFFKILL=/usr/secmach/diffkill
TRUSTED_USERS="johndoe"
TRUSTED_ITEMS="$TRUSTED_USERS|pppd|chat|netscape|xterm|egrep|ps|sed|secmach|awk"
if [ ! -s $LOCATION ]
then
mkdir $LOCATION
chmod 700 $LOCATION
fi
while :
do
COUNTER=`expr $COUNTER + 1`
if [ $COUNTER -eq 1 ]
then
ps -aux | sed -e '1d' | awk '{print $2}' > $TRUSTED
fi
sleep $CHECK_TIME
ps -aux | sed -e '1d' | egrep -v $TRUSTED_ITEMS | awk '{print $2}' >
$UNTRUSTED
diff $TRUSTED $UNTRUSTED > $DIFFKILL
KILL=`grep ">" $DIFFKILL | awk '{print $2}'`
kill -9 $KILL
done
Controlling cron.hourly
Date: Sun, 21 Dec 1997 10:36:16 -0500 (EST)
From: Jeff Johnson [email protected]
According to Gary Turkington:
> I know this one of those *really* simple ones, but it's beating me. How
> do I stop the cron.hourly setup mailing a 'fortune' to root? This used
> to happen daily, no biggie, but when I upgraded to 5.0, its hourly.. spam
> :)
This is a variant of the "not a typewriter" error that causes loss of hair when using rlogin :-)
The analysis goes like this:
1) Cron runs a job an hourly job as root.
2) To run the job, a non-interactive (i.e. stdin/stdout are *not* connected
to a tty but to cron) shell is started.
3) The shell reads its init files: /etc/profile, ~/.bashrc, whatever.
4) The init files execute fortune.
5) The job is performed.
6) Cron detects output, so it mails it to root.
Fix by identifying which shell init file is executing fortune and avoiding fortune when not interactive. There are a couple of techniques for doing this, often by checking whether PS1 is set.
73 de Jeff
Syslog and ping
Date: Tue, 30 Dec 1997 17:58:59 -0500 (EST)
From: Andrew Tucker [email protected]
Hi, this is a small hack I did to allow logging of users's use of ping through syslog. With more and more larger systems running Linux, and more and more situations of ICMP abuse, any shortcut a system administrator can use to prevent such abuse is helpful. Click here to dowload the scripts.
-- Andrew
|
Contents: |
February Linux Journal
The February issue of Linux Journal will be hitting the newstands this week. The focus of this issue is Databases. Also, included is an article on the making of the movie Titanic -- Digital Domain used Linux extensively in generating the graphics for this movie. Check out the Table of Contents.
Apache Webserver Serves Over Half the Internet
Date: January 5, 1998
The Apache Web Server, from the Apache Group (http://www.apache.org/), now serves over half the domains on the Internet, according to the latest Netcraft Web Server Survey (http://www.netcraft.com/). According to the January 1998 survey, the Apache server and its derivatives serve 50.24% of the 1,834,710 sites found by Netcraft.
For complete press release, click here.
Linux on Celsius Workstations
Date: November 28, 1997
Siemens Nixdorf (SNI) is selling there new "Celsius" Workstations with WinNT AND Linux. SNI is the first major Producer that offers Workstations with Linux on board. The Linux-Support is done by the well known Linux Distributor SuSE GmbH. The machine is targeted for the universitys and already in use there with linux. The "Celsius" is based on a Pentium-II with 266/300 Mhz, 512KB Cache, 32MMB ECC-SDRAM, 2GB drive, a PCI/AGP based matrox millennium II with 4MB, FastEthernet, Diskdrive and Keyboard. The price shall be between 7300-8200DM but its exspected to fall. According to SNI the "Celsius 1000" (300Mhz Version) gets 11,9 SPECint95 and 8,6 SPECfp with WinNT. (no Linux values yet.)
Freeware OCR Project
A mailing list has been started for discussion of the design and implementation of a freeware Optical Character Recognition program for Unix.
Scanner support for Unix is under rapid development thanks to projects such as SANE, and applications such as GIMP are beginning to benefit from this support. OCR is one major application missing from the freeware Unix world, and has long been on the FSF's project list, as well. The project is going to have to create both a user interface and a character recognition engine.
The project Web page is at http://starship.skyport.net/crew/amk/ocr/; look there for announcements about the project's status.
For more information:
Andrew Kuchling, [email protected]
5th International Linux Kongress 1998
The 5th International Linux Kongress 1998 will be held from June 3 to June 5 at the University of Cologne (Köln). It follows the tradition of the Linux conference series (Heidelberg 94, Berlin 95/96 and Würzburg 97) which has evolved into the most important meeting for Linux experts and developers.
The conference will offer up to 25 talks during two days (June 4 and 5) in two parallel tracks. The first track will be dedicated to Linux development, the second track will be intended to accomodate talks about Linux applications and usage. Each talk will be 40 minutes (possibly including discussion). The language of the talks will be English or exceptionally German.
For more information:
GUUG office, Ms. Bester,
[email protected]
http://www.linux-kongress.de/
Linux in the News
Articles by Charles J. Fisher worth checking out in Unixworld On-line:
Creation and Maintenance of Virtual Hosts
Linux, PPP and Windows 95
More Linux articles:
"Linux Grows Up" -- Red Hat's commercial Linux beats NT at its own
game.
Computer Currents
"Intel-Based Unix: A Great Solution for Intranets"
Federal Computer Week
Better late than never:
On November 15 Linus announced that the F00F bug
had been fixed in the 2.0.x kernel. Click here to
read what he had to say.
Linux Bibliography
After a three month hiatus, the Linux Bibliography is back on line. The bibliography has grown a lot in size since it was last "live": there are now almost 50 Linux specific titles listed.
While the site is back up, it is still in beta mode. You'll need a Javascript compatible browser to see it, and some of the JavaScript appears to be a bit buggy with older browsers. Most of the forms are working, but not all of them just yet.
For more information: Mark Stone, [email protected]
Linux Business Solutions
Announcing: A project to generate and improve documentation of Linux Businesss Solutions. This project is a few days old, so far. http://linas.org/linux/web-project.html.
There is a separate mailing list for this project. Web page owners, writers, marketing types & document mangement hackers are encouraged to join.
For more information:
[email protected]
The Linux Project Server
The Linux Project Server has a new home page providing counters, guestbooks and many many other such scripts.
For more information:
Gerhard Poul, [email protected]
Freely Redistributed Software Track - USENIX'98
Come hear the latest about the full range of freely redistributable software--with pointers to the code--including Linux, FreeBSD, GNU, netBSD, OpenBSD Samba, and more.
FREENIX, The Freely Redistributed Software Track, at the USENIX 1997 Conference held June 15-19, 1998 in New Orleans, Louisiana.
For more information: http://www.usenix.org/events/no98/
Linux Software Database
The Linux Software Database is now up and running at http://www.txcc.net/~cl/.
Unlike software sites that list only what software the author has found the LSDB allows Linux users connecting to the database to add software thay have found or use. This way both authors of software and users of the site can add there titles on-line.
For more information:
[email protected]
S.u.S.E. Discussion Groups
S.u.S.E. has set up two lists for discussions and announcenments concerning the S.u.S.E. Linux Distribution:
suse-announce-e -- Announcements of S.u.S.E. LLC (english) suse-linux-e -- Discussions about S.u.S.E. Linux (english)
To subscribe, send an email to [email protected] with 'subscribe listname' in the body.
For more information:
Bodo Bauer, [email protected]
http://www.suse.de
The Linux Resource Kit
The Linux Resource Kit has been expanded to included current news and information on:
IACT & Linux users
A message from the Land of Beyond web site!
We have devoted a new section for IACT, the "International Alliance for Compatible Technology." Users of major platforms such as OS/2, Linux, FreeBSD, BeOS, MacOS, Unix, DOS etc., are invited to sign-on to IACT's Declaration! IACT is working for greater freedom of choice in software, for better access to computer-based services & technology, and for open standards, including higher standards of compatibility. To achieve such important goals for all people, IACT will join in anti-monopoly efforts against Micro$oft, while we find positive ways to help consumers & users regardless of their chosen platforms. Join us at... http://pages.cthome.net/iact/
For more information:
Diane Gartner, [email protected]
IACT Co-ordinator
Dotfile Generator 2.2
Date: December 24, 1997
Jesper Pedersen has announced the release of The Dotfile Generator version 2.2. New in this release is:
For more information:
Jesper Pedersen, [email protected]
TeamWave Workplace 2.1
Date: November 27, 1997
TeamWave Software Ltd. today announced the release of version 2.1 of TeamWave Workplace, its popular software that lets teams work together in shared electronic rooms across the Internet. For teams within an organization who are sometimes physically separated yet still need to work closely together, TeamWave Workplace provides an Internet forum where teams collaborate, communicate and share information.
For more information:
[email protected]
http://www.teamwave.com/
Red Hat Linux 5.0, HURRICANE
Date: December 1, 1997
Red Hat Software, Inc. has announced the
availability of Red Hat Linux release 5.0 for Intel and Alpha
computers. This release is a major update to the Red Hat Linux 4.X
series.
Red Hat Linux is available on their FTP site:
ftp://ftp.redhat.com/pub/redhat/redhat-5.0/
For more information:
http://www.redhat.com/
[email protected]
Nighthawk
Date: December 19, 1997
Nighthawk is An X-Windows game for Linux (Freeware GPL), based on Andrew Braybrooks C-64 classic- "Paradroid", written by Jason Nunn (JsNO)
Nighthawk 1.0 uploaded onto the following sites:
For more information:
Jason Nunn, [email protected]
C++ GUI IDE
Date: November 28, 1997
Simple IDE for: Qt C++. GUI dialog editor, all developed on Linux X11R6 available at: http://qtez.commkey.net/ All distributes of QtEZ include: documentation, a set of tutorials, and many demonstration programs to illustrate features in the environment. I hope QtEZ is well received.
For more information:
Sam Magnuson, [email protected]
r2d2 - easy but powerful boot-concept
Date: December 3, 1997
r2d2 is a newly developed boot-concept for Unix. In some way r2d2 combines the easeness of the BSD-style scripts (e.g. in Slackware Linux) with the power and flexibility of the traditional SysV scripts (e.g. in RedHat, Debian or S.u.S.E. Linux). r2d2 is available at ftp://sunsite.unc.edu/pub/Linux/system/daemons/init/
For more information:
Winfried Truemper, [email protected]
TkSTEP 8.0p2
Date: December 5, 1997
This is Tk 8.0p2 with some modifications to make it look like N*XTSTEP's interface, plus some new widgets inspirated on N*XTSTEP and the ability to utilize the full power (and more) of the OffiX Drag'n'Drop protocol.
The programming aspects of Tk have not been changed much, so you can run your old Tk apps normally with it, although some options will not do anything (like -relief for scrollbars).
To get TkStep go to http://www.fga.de/~ograf/TkStep.shtml
For more information:
Oliver Graf, [email protected]
Steve Murray, [email protected]
t1lib-0.4-beta: A rasterizer for Adobe Type 1 Fonts
Date: December 5, 1997
t1lib is a library for generating character- and string-glyphs from Adobe Type 1 fonts under UNIX. t1lib uses most of the code of the X11 rasterizer donated by IBM to the X11-project. But some disadvantages of the rasterizer being included in X11 have been eliminated.
You can get t1lib by anonymous ftp at: ftp://ftp.neuroinformatik.ruhr-uni-bochum.de/pub/software/t1lib/t1lib-0.4-beta.tar.gz
For more information:
Rainer Menzner,
[email protected]
SGML-Tools 1.0.1
Date: December 5, 1997
After a year of mostly code restructuring and bugfixing, the time finally arrived to let SGML-Tools 1.0 see the light. This means the final demise of Linuxdoc-SGML. Loads and loads of features were added. Most of the code was redone in Perl 5, which adds a lot of flexibility for people who want to override certain parts of the functionality (but at the same time be able to install newer versions); uncountable bugs were fixed (more were introduced, of course :-)), lots of small enhancements, etc.
Visit the SGML-Tools homepage, at http://pobox.com/~cg/sgmltools/, for latest news, pointers to locations, etcetera. Note that I haven't been able to get this stuff on SunSite yet, so you'd better go via the homepage.
For more information:
Cees de Groot, [email protected]
http://pobox.com/~cg/sgmltools/
LinuxThreads 0.7 -- POSIX thread library
Date: December 5, 1997
LinuxThreads is a thread library for Linux implementing the POSIX 1003.1c API and based on the "one thread = one process" model. The sources are available through the LinuxThreads home page: http://pauillac.inria.fr/~xleroy/linuxthreads/ or directly on our FTP server: ftp://ftp.inria.fr/INRIA/Projects/cristal/Xavier.Leroy/linuxthreads.tar.gz
For more information:
Xavier Leroy, [email protected]
TkDesk 1.0b5 released
Date: December 9, 1997
TkDesk 1.0b5, a Desktop and File Manager for UNIX's running X11, has been released. TkDesk is a graphical desktop and file manager for several brands of UNIX (such as Linux) and the X Window System. It offers a very rich set of file operations and services, and gives the user the ability to configure most aspects of TkDesk in a powerful way. The reason for this is the use of Tcl/Tk as the configuration and (for the biggest part of TkDesk) implementation language.
You can get TkDesk from its homepage at: http://people.mainz.netsurf.de/~bolik/tkdesk/
For more information:
Christian Bolik,
[email protected]
MP3Blaster V2.01 -- Mpeg audio player for Linux
Date: December 9, 1997
A new release of MP3Blaster, an Mpeg-layer 1/2 audio player for Linux is available. This player has a smart and intuitive user-interface that allows a user to split up a playlist into sections. An interesting use of this feature is that you can put about 10 of your audio CD's in MP3-format on one CD-ROM and have each section in the playlist represent an album. Then, you can have the player play the songs in every imaginable order you want.
Available at:
ftp://sunsite.unc.edu/pub/Linux/apps/sound/players/mp3blaster-2.0b1.tar.gz
http://www.stack.nl/~brama/src/mp3blaster-2.0b1.tar.gz
For more information:
Bram Avontuur, [email protected]
X-CD-Roast 0.96c
Date: December 9, 1997
X-CD-Roast 0.96c, a CD writer package for X, has been released. Really new stuff:
For more information:
Thomas Niederreiter,
[email protected]
ADABAS D Workgroup Edition
Date: December 11, 1997
ADABAS D Workgroup Edition 10.0 for Linux is now available. Visit http://www.IoS-online.de
For more information:
Bjoern Bayard,
[email protected]
Linbot 0.1 web site management tool
Date: December 12, 1997
Linbot 0.1 is a tool that can examine a web site for broken links, outdated pages, and other useful information. It is based on the commercial LinkBot from TetraNet Software (http://tetranetsoftware.com/) though Linbot will be free. You can get Linbot at http://home1.gte.net/marduk/linbot/index.html
For more information:
Marduk, [email protected]
The Answer Guy
Netscape Mail Crashing
From: Jim Kelley, [email protected]
I've been running Netscape Communicator 4.04 on my RedHat Linux system since the day it came out and yesterday it started crashing whenever I check for new messeges or try to go to a newsgroup. I've deleted NC4.04 and re-installed it but to no avail. Any suggestions?
When you removed NC4.04 (which I didn't know had been released
yet -- I'm still using 4.03) did you also remove your ~/.netscape
directory tree?
What happens if you try it from another account on the same system? What happens if you use different e-mail and newsreaders? (elm, pine, emacs' mh-e and/or tin, nn, trn, or emacs' Gnus for respective examples).
I would suspect a data or configuration file corruption. Many programming practices that I most loathe and detest have to do with a lack of robustness and simple error messages with regard to corrupted input. Is it really that hard to have a switch that logs each input source like: "Reading configuration from ~/.netscape/foorc....." and "Bounds error at ~/.netscape/bar.conf offset 0x2AFF9A77"? I haven't looked at the innards of NS Comm's data files -- I wouldn't use their mail and newsreaders since I'm very particular about my mail and netnews -- and I need extensible, configurable, text mode capable systems (so I use emacs' mh-e and Gnus).
--Jim
Slackware Help
From: Ralph, [email protected]
HELP!!!!!!!!!!!!!
Recently I installed Linux Slackware version 3.2, everything loaded fine, but
I really run into problems when I set up the password for the root, for some
reason the one i register doesn't allow me to log in. I have problems on how
to mount the /root and remove the existing password from the /etc/shadow. I
install linux with partitions for a SCSI hardrive sda1 sda2.
I would really appreciate some few hints to solve this problem.. Thank YOU
VERY MUCH.
--Ralph
I haven't used any of the newer Slackware systems -- so I don't know
if there's anything specific to their system that would contribute
to or cause this problem.
The general way to fix this sort of problem (lost root password) is to boot from a rescue diskette (or from an "alternate root partition") mount your normal root partition (let's you put it under /mnt/oldroot) and then simply edit the mnt/oldroot/etc/passwd file -- and maybe the corresponding shadow file).
Another trick is to use the chroot command instead of editing the passwd files directly. Basically you can follow the mount with a command sequence like:
cd /mnt/oldroot/ && usr/sbin/chroot . bin/sh... and then:
passwd(allows you to use the normal passwd command -- and forces it to update the passwd files *under* the (chroot)/etc directory rather than the one of the root diskette or the alternative root part).
A properly maintained alternative root partition should have extra copies (mirrors) of the whole /etc directory from your production root partition. This makes recovery from errors *much* easier. On some systems you may be able to use a removable drive (LS120, Zip, Jaz, magneto-optical, Bernouli, Syquest, DynaMO, whatever) as your alternative root system.
-- Jim
Netscape /var/spool/USER
From: John Liebenrood, [email protected]
I'm running Redhat 4.2 with Netscape 3.01. I can send mail fine but I can't receive mail. I don't understand how to configure my /var/spool/USER. I've used chown mail.mail and chmod 01777 on USER file. But still can't get mail to come in... all talk no listen
--john
Do you have a POP account? Are you trying to
read you mail from the localhost? Where is your
localhost supposed to get it's mail from?
Normally 'sendmail' (or smail, deliver, or procmail) appends messages to your spool file. 'sendmail' gets your mail via SMTP or from your UUCP system (depending on your configuration and your ISP/account type).
There are a bunch of factors that anyone would need to know before answering your question.
Netscape is normally configured to fetch mail via the POP protocol and to send it directly via SMTP. If your system is already configured to send and recieve mail (i.e. you can use other mail user agents (MUA's) like elm, pine, mh, etc) then you should be able to configure Netscape to use "localhost" (the loopback interface -- internal to your own system).
Personally I won't use NS Nav. (or Comm.) as a mail or news client. I absolutely require a text mode interface
-- Jim
Getting Rid of Virtual Screen
From: [email protected]
Hi, how do i get rid of the virtual screen under x windows, it's bloody annoying!! I've tried disabling it under install and I've even tried resetting my resolution size, please help!!!
Assuming you're using XFree86 you'd edit your XF86Config file
(which might be /etc/X11/XF86Config or might be something more
like /usr/X11R6/lib/.... or something).
Find the Screen section for the device driver and mode you're using, look for the display subsection that applies you your monitor and modify the "Virtual" line thereunder.
If you've tried that (if that's what you mean by "resetting my resolution" or "disabling it under install") than it's possible that you're using a different X Server than I think you are (Xig, or Metro-X or something) or that your installation or distribution is using a config file in a different location than you think it is.
The man pages for 'X', 'startx' and 'xinit' may help -- in particular the XFree86 servers allow you to specify an option of -xf86config file -- which allows you to explicitly over-ride the system wide configuration (and is a great reason for security concscious sysadmins to limit the execution of X to some trusted local users -- and maybe use xdm).
I found this option in XFree86(1) (that's the XFree86 man page in chapter one on my man pages). Don't confuse it with the -config option referred to in the XServer(1) man page. That option just says that more *command-line options* are stored in a file. The XServer man page refers to options and configuration information that should apply to any Unix X Windows display server. The XFree86(1) page refers to the extensions which apply to the servers written as part of the XFree86 project. The various XF86_* man pages refer to the features that are specific to specific servers (that is the ones which are compiled for a given video card or chipset).
You're only running one binary -- yet three man pages apply to whichever one you're using. This is unnecessarily confusing -- and one of the books I've perused (on Unix, X, or Linux) cover this sort of thing. So you have to wander through lots of different man pages and /usr/doc/* files without a clear roadmap.
I'm hoping that some future distribution (maybe the Red Hat 5.0 that's supposed to be shipping in the next couple of weeks, or the next Debian) will have a really good set of HTML (lynx clean!) documents, served by default off of the initial localhost webserver which takes a top down, organized approach to educating and informing us about all the power and choices we have in Linux.
-- Jim
diald's Niche
From: Pollywog, [email protected]
Put it anywhere you'd like. The .rpm version installs into defined sub-directories, but keep the .rpm file anywhere you like. I have /usr/local/packages for tarballs and .rpms....
I recommend that SA's use a /usr/local/from directory
tree. You can then have a set of directories named
after your favorite FTP and web sites and after the
volume names of your favorite CD's.
When you download/fetch a file -- put it into a directory that reminds you where you got it from such as:
/usr/local/from/sunsite/ /usr/local/from/redhat/ /usr/local/from/ftp.replay.com/
... etc.
Now when you want to upgrade a package you can see where you got the previous version from -- and consequently you have a headstart on where to look for upgrades.
This technique is also handy if you read an alert about a compromised (trojan) package -- you can easily see where *you* got your copy from.
For files you install off of the CD -- create a directory name that reminds of you which CD it is like:
/usr/local/from/cd/MOP/ (Mother of Perl) /usr/local/from/cd/rharchive.fall97/
... etc.
Now you just put symlinks from that directory to your usual CD-ROM mount point (ln -s /mnt/cdrom/dir/foo foo).
This creates a tree of "broken" links -- but it tells you where to find the source file if/when you need to rebuild.
As you can probably see this technique is really a "poor man's HSM" (hierarchial storage management system). You can also extend this idea to migrated data files from your home directories to removable media (such as Zip, Syquest, MO, and CDR devices).
It's also a very handy form of self-documentation in businesses where you may have many sysadmins or you may have various consultants "stomping" around on your systems.
-- Jim
Upgrade to Red Hat 5.0?
From: Jason Welsh, [email protected]
hey, im running an older 4.something version of Red Hat and was wondering if I just wanted to upgrade it to 5.0, do I need to download certain RPMS or do I need to get the whole thing? or get it on CD.. just curious if there was a shortcut I could take..
--Jason.
I would get the CD (in fact I did -- but I haven't
run the upgrade yet -- want to finish some work and
do an extra backup first).
CD's save lots of bandwidth and save lots of time.
If you don't need the commercial packages that come with Red Hat (the BRU and Metro-X) you can wait a month or so for the "Archives" set to come out -- which is about $20 (less than half the full version).
-- Jim
Red Hat Linux and WABI and other things
From: [email protected]
I have RedHat Linux v5.0 (kernal 2.x) ($49) and (silly me) found out that Caldera OpenLinux Standard ($399) supports WABI for Windows 3.1 apps, FreeDOS (or is it DOSEMU??) for DOS apps, and NetWare 3.x/4.x client supporting NDS (Network Directory Services).
WABI/Linux (a.k.a the Windows 3.1 Applications Binary
Interface) is available separately from Caldera. It
is a commercial package -- and it should install on
most Linux systems without much trouble.
There's also WINE ("WINdows Emulation" or "WINE is not Emulation" -- take your pick of acronym expansion). This is a freeware project to implement enough support for the lower level Windows API's to allow Linux (and other Unix) users to install MS-Windows and run Windows programs.
I've heard that it is also possible to run Windows 3.1 in "standard mode" under DOSEMU/MS-DOS. I'm not sure if that works under other DOS variants running under DOSEMU.
OpenDOS is Caldera's release of "Novell DOS" (which was formerly "DR DOS" -- from Digital Research). Caldera aquired the licenses and rights to Novell DOS when Novell decided to "refocus on its 'core' markets" (and practically gutted itself in the process). In fact Caldera's "Network Desktop" (their distribution that preceded the OpenLinux/Base and OpenLinux/Standard) was originally a research project at Novell.
OpenDOS is partially commercial -- it is free for personal use (or for students, or something like that -- read their web pages for details). It has little to do with DOSEMU. OpenDOS is available on CD for about $30(US).
DOSEMU is really a bit of a misnomer. Technically it's a BIOS emulator which can be used to run any x86 "real mode" operating system (such as CP/M-86 or some versions of Forth). When you install DOSEMU you also have to install some copy of DOS (MS-DOS, PC-DOS, OpenDOS, whatever) to get any practical use out of it. DOSEMU includes several DOS programs which connect to the underlying Linux system. This allows one to access Linux directories and NFS mounts as DOS "network" drive letters, and do other things like that.
FreeDOS is a different project -- you can learn more about it at http://www.freedos.org. They are quite Linux friendly -- but I haven't played with their release (and I've barely touched DOSEMU or Caldera's OpenDOS) so I can't say much about it.
Regarding Netware access from Linux:
Caldera's Netware client access (with bindery and NDS support) is only available as part of their OpenLinux Standard (as far as I know). I've heard that some people have successfully installed the clients on other Linux distributions. However it appears that you are legally required to purchase the commercial COL/Standard (Caldera OpenLinux is often called COL by participants of it's mailing lists).
There are also a couple of free packages that implement some Netware protocols for Linux. 'ncpfs' is one that allows you to 'mount' Netware partitions in a way that similar to NFS. This is a system-wide mount (unlike the Caldera netware clients where each user has unique "virtual" mountings that are not visible from other concurrent processes on the system.
There's also the mars_nwe (Netware emulator) that implements a subset of the Netware fileserver protocols -- allowing DOS and other systems to access portions of your Linux filesystem(s) using the Netware clients (similar to 'samba' for Windows for Workgroups/LANMan/NT functionality).
I would like to know if this support can be added to RedHat
Linux by downloading this stuff from somewhere, and recompiling
the kernel? Can you help? I'm new to RedHat and have not
yet gotten an answer from them.... If not, can you direct me
to where I can inquire? This is a quest to make use of our
486 computers at work (and just need to know) by running
Linux, and still support some things like Windows 3.1x Lotus Lotsuite,
etc., which Caldera claims to do, but I would like
to find out how much trouble it would be to add support to
Redhat.....
In general, anything you can run under Caldera you
can get to run under Red Hat or any other reasonably
recent Linux distribution.
Since Caldera, Red Hat, Craftworks, and a couple of other Linux distributions use the same package management system (the RPM -- or "Red Hat Package Manager") sharing packages among them is somewhat simpler than installing a Debian package or Slackware "tarball" would be.
I'd look at any FTP mirror of Red Hat's "contrib" directory for the lastest dosemu "rpm" and install that. You'll probably find one of these on your set of Red Hat CD's in addition to the ones online. You can check the online directory for updates and recent additions.
-- Jim
Linux as a PDT
From: Karl Rossing, [email protected]
Linux as a PDC (Primary Domain Controller), NIS/NIS+ Master -- etc.
I was wondering if it is possble to get windows 95/NT to authenticate to LINUX (using nis or nis+). I'm really getting tired of adding accounts on the nt boxes for the linux boxes(for smb)...Is there any commercial software availible?
It sounds like you're asking fundamentally different
questions here.
In your subject you refer to using Linux as a PDT by which I presume you meant a PDC (Primary Domain Controller). Here you refer to using NIS/NIS+ -- which would involve adding client support (third party software) to all of the NT/'95 boxes.
A broader questions is:
What network authentication and directory services system/model/architecture should you use?
This is a sticky question with no easy answer.
A simpler question is:
How can I configure my MS client machines (NT and '95) to use my Linux system's account information for access control and authentication?
I'll provide some thoughts on each of these questions after commenting on the rest of your message:
I know of p-sync [http://www.m-tech.ab.ca/psynch/index.html]
I glanced at their web pages and was not impressed.
They have almost no text and are almost completely
unreadable for Lynx users. They also don't offer
any functionality in their demo -- which is just a
mockup of the GUI (crippleware).
and NSGINA
[http://www.dcs.qmw.ac.uk/~williams/]
which seems a bit of work to setup...
That would "NISGINA" This is by Nigel Williams -- apparently
derived from work by Doug Scoular(*). It is apparently released
under a BSD'ish license. So this is much more promising than
the p-sync package right off the bat.
* (http://www.arch.usyd.edu.au/~doug/gina.html)
GINA (graphical identification and authentication) is the NT DLL that manage logins at the NT console -- there are several different GINA's -- one from Novell for NDS, one from MIT for Kerberos, another similar one for NT-AFS (Transarc's distributed filesystem -- which uses a Kerberos 4 authentication model) etc. Here are some related URLS:
NT GINA related information: http://web.mit.edu/cartel/ntgina.html -- very informative -- leads to all the rest that I found.
ND_GINA - An alternative authentication method for Windows NTr, http://www.nd.edu/~dobbins/ntarch/nd_gina_doc.html
NT/UNIX Integration with Doug's GINA replacement, http://www.arch.usyd.edu.au/~doug/gina.html
The problem with GINA is that it doesn't appear to be available for '95 (or earlier versions of Windows or DOS). That may be a show stopper for for this approach
I can't recommend in good faith that you upgrade you Win '95 systems to NT (since that just buys you in further to this proprietary OS model -- and just worsens your dilemma when '98 and NT 5.x ship).
I'm not really looking for passwd syncronisation, i'd like to
consolidate it to the linux box, because the users use both linux/95/nt.
nuff said, thanks.
I don't think nearly 'nuff's been said about this topic.
There are a large number of directory service and
authentication methods that are vying for control of your
network. Each as its own security implications -- making
them co-exist is difficult from the start, and a
constant drain on administrative time and resources -- and
having them running concurrently usually means that the
weakest link prevails in your security model.
There's an excellent white paper about this at Cygnus Solutions:
http://www.cygnus.com/product/unifying-security.html
That aside, some of your choices are:
Overall I think I'll like CODA best when we have a reasonably Linux server and client for it.
More more info on the CODA project at CMU browse through their mailling list archives at:
http://www.coda.cs.cmu.edu/maillists/linux-coda/0175.html
I could rant for sometime about the security models of the various network/shared filesystems -- but it's late so let it suffice to say I like that even less than the choices for DS and authentication. So far I think I like TCFS (transparent cryptographic filesystem) the best for security -- though I'm quite concerned about its performance costs.
I presume you're using Samba on your Linux server(s) to provide file services to your Windows clients. From a glance at the Samba Meta-FAQ and some of its other pages it looks like you could just let Linux/Samba manage the accounts for your whole network.
Here's some links that relate to that:
Samba: User accounts http://samba.anu.edu.au/samba/docs/smb_serv/html/smb_se-4.html#ss4.1
Samba Server HOWTO http://samba.anu.edu.au/samba/docs/smb_serv/html/smb_se.html
(*Note: if I read this correctly -- Samba can't currently be a "password server." This seems to mean that it can't act as a PDC/BDC (backup domain controller) for NT systems to refer client authentication requests through).
It looks like the future will hold some sort of LDAP and Kerberos -- for NT and many other OS' and packages. This would be fine -- if it weren't for the inevitable politicking and kneebiting that the various commercial vendors are going to do.
The problem is that everyone's version of LDAP (directory services) and Kerberos (authentication) will be just different enough that each vendor's OS will just *need* to be *the* server for *their* domain. They'll all make press releases about their "interoperability" -- and most will refuse to release enough details about their "extensions" for any other vendor (or freeware programmers) to implement them elsewhere.
I guess it will take a few years after the initial deployment for enough of this proprietary info to leak out (and/or be reverse engineered) to allow system administrators to actually have any semblance of a unified directory service and authentication system. The bugs and security problems will probably keep popping up for a long time after that (they've been popping up in Unix for 27 years -- and many of them are reappearing in NT now).
Meanwhile we're going to see a continuing explosion of servers and network applications (client server systems) that each require different user account (with associated group, token, and other information) and authentication information.
Worse yet, the various layers of management above us are already hearing the marketeers lies -- that the solutions are "already shipping" or "just around the corner." This is just what management wants to hear -- so many of them are believing it -- and planning their budgets and project schedules accordingly. A system administration disaster in the making.
Sorry I can't offer a brighter hope for the new year -- but I'm no marketeer.
-- Jim
What is autofs? Autofs uses automount to mount cdrom and floppy drives (and other things) to your computer as you need them and umount as they are not being used. What is mount and unmount? Mount and umount are programs to mount a device ontop of a directory. For example, this command would mount the first floppy drive (drive a: in DOS terms) to the directory "/mnt/floppy" so that everytime you access "/mnt/floppy" to access your floppy drive.
mount /dev/fd0 /mnt/floppy
And this command unmounts or frees up the floppy drive from being used.
umount /dev/fd0
Now, in DOS terms, your floppy disk is accessed as you need it. For normal users, that is what they would expect. They wouldn't want to use mount and umount because it is time consuming and because they might not get it right.
I assume "/dev/cdrom" is your cdrom drive and "dev/fd0" is your floppy drive. I am also assuming you will backup your "/etc/auto.master" file. Use this script to create the following threes files and restart autofs. Login as "root", goto your home directory, copy whatever between the next two lines to a file called "CreateAutofs.script" and execute the script with the command
source CreateAutofs.script
cd
echo "Please ignore any errors when making directories"
### Let us make sure the two directories exist, ignore errors
mkdir /mnt/floppy
mkdir /mnt/cdrom
### Let us backup the auto files in case they haven't
mv /etc/auto.master /etc/auto.master_old
mv /etc/auto.floppy /etc/auto.floppy_old
mv /etc/auto.cdrom /etc/auto.cdrom_old
### Create the files for autofs
echo "/mnt/cdrom /etc/auto.cdrom --timeout 10" > /etc/auto.master
echo "/mnt/floppy /etc/auto.floppy --timeout 1" >> /etc/auto.master
echo "floppy -user,suid,fstype=msdos :/dev/fd0" > /etc/auto.floppy
echo "cdrom -fstype=iso9660,ro :/dev/cdrom" > /etc/auto.cdrom
### Create the links to the floppy drive and cdrom drive
ln -s /mnt/floppy/floppy a:
ln -s /mnt/cdrom/cdrom d:
ln -s /mnt/floppy/floppy floppy
ln -s /mnt/cdrom/cdrom cdrom
### Lets retstart autofs, you might have to reboot
cd /etc/rc.d/init.d
./autofs restart
### If it didn't work, you might have to reboot
### Try "./autofs start" if the restart claims autofs has not been
#### started
cd
The end of your results should look something like the following if it was sucessfull
Start /usr/sbin/automount --timeout 10 /mnt/cdrom file /etc/auto.cdrom Start /usr/sbin/automount --timeout 1 /mnt/floppy file /etc/auto.floppyNow put a floppy disk formatted for MSDOS and a cdrom in and execute the commands
ls a: ls d:to see if there is anything on them. Hopefully you don't get any error messages.
Personally, my /etc/auto.floppy file looks like
floppy -fstype=auto,defaults,user,suid :/dev/fd0and my /etc/auto.cdrom file look like this
cdrom -fstype=iso9660,user,suid :/dev/cdromThe reason why I gave conservative values in the script was the fact the my values might be security hazards. But since I am the only person using my computer, I wanted to make sure my personal account had full access to the floppy and cdrom drives. Also, -fstype=auto doesn't seem to work quite right when your disk is formated for MSDOS, but works fine with ext2. "-fstype=auto" tries to autodetect the file format.
If you noticed the timeout value for the floppy drive is 1 second. This makes it so that by the time the floppy drive light has gone out, your floppy disk is unmounted and a normal user can take the floppy disk out and "nothing bad happens". I made the timeout value for the cdrom 10 seconds because it wasn't working really well at 1 second, and I figured it was because the drive didn't have enough time to "warm up" before it was being shut down. You might want to test what the timeout value for your cdrom drive should be.
To get more information about autofs, do the commands
man 5 autofs man autofsand look the the directory "usr/doc" for the directory "autofs-0.3.14" or something similar to it.
Your "/etc/rc.d/init.d/autofs" script first looks at "/etc/auto.master". That file usually has three things on each line. It has the directory which all mounts will be located at. Then next to that value is the filename which contains the configuration(s) for what devices you want mounted. We will call these filenames the "supplemental" files. Next to that value is the timeout which you want to occur after so many seconds of inactivity. The timeout will free or umount all devices specificed in the supplemental files after so many seconds of inactivity.
Now, the supplemental files can have more than on entry, but for my purposes I don't do that. Read below for the explanation. The supplemental files can be named anything you want them to be named. They also have three values for each entry. The first value is the "psuedo" directory. I will explain this later. The second value contains the mount options. The third value is the device (like "/dev/fd0" which is the floppy drive) which the "psuedo" directory is connected to.
The "pseudo" directory is contained in the directory which is defined in "/etc/auto.master". When people try to access this "psuedo" directory, they will be rerouted to the device you specified. For example, the above script will generate a link called "a:" which if you list with the command "ls a:" will give you a list of files in the floppy drive. Or, a similar command would be "ls /mnt/floppy/floppy". But if you do the command "ls /mnt/floppy", you don't see anything even though the directory "/mnt/floppy/floppy" should exist. That is because "/mnt/floppy/floppy" doesn't exist as a file or directory, but somehow the system knows that if you specifically ask for "/mnt/floppy/floppy", it will reroute you to the floppy drive.
Now as to the reason why I didn't combine the floppy drive and cdrom drive into the same supplementary file. Each definition in the "/etc/auto.master" file will have its own "automount" program running for it. If you have several devices running on the same automount program and one of them fails, it could force the others not to work. That is why I want every device running on its own automount program which means there is one device per supplementary file per entry in the "/etc/auto.master" file.
Having just read Micheal Shappe's review of the Fujitsu Lifebook 420d in the Nov issue of LJ I thought I would relate a similar experience I had in purchasing a new laptop for my organization. Academic User Services at the University of Oregon provides support for end users on timeshare systems running Digital Unix, VMS, Solaris, and Linux. We have a wide variety of desktop hardware including PC's running Linux, FreeBSD, NT, 95 as well as DEC Alphas, Sparcs, SGIs and Macs. We needed a portable computer to send with people to do workshops, attend conferences and demo software for people. Because our members use a number of varieties of Unix but only a little better than half of them use Windows in the course of their work, solid UNIX support of some variety was imperative.
Our requirements were that it should have sufficient space to dual boot Windows95 and Linux, more over all the subsystems should work equally well under either Windows or Linux. The Laptop needed to provide support for an external display at 24-bit color depth as well as have support for an external keyboard and mouse. It should above all meet those goals and be relatively inexpensive as well as reasonably compact and durable.
We eventually settled on a Toshiba Satellite Pro 220cds. The Toshiba has a complete compliment of ports on the back, PS/2, serial, parallel, IRDA, VGA, docking station and interestingly enough, a USB port. It comes with a Pentium 133 processor, 16mb of ram and 2mb of dram to drive the 12.1" passive matrix display at 8, 16 and 24 bit color. It has a small but sufficient 1.4gb disk. The audio jacks and the volume control are located on the front of the case. The satellite pro 220cds is over all similar to it's more expensive cousins the 440cds and the 460cds which will undoubtedly replace it eventually. They are distinguished by having active matrix displays, larger hard disks and in the case of the 460 an internal modem.
The keyboard is quite large, the feel is closer if anything to a desktop keyboard than anything that you would expect to find on a laptop except for the travel of the keys which is fairly short. The Toshiba laptops have a ThinkPad style trackpoint-pointing device rather than the ubiquitous trackpads that seem to be on almost all portables these days. It does not regrettably have a third mouse button like the new and very expensive ThinkPad 770; but the buttons are located on top of each other rather than adjacent to each other as on most trackpads. This makes them easier to press and hold down with your thumb while moving the trackpoint with you index finger, so you can drag a scrollbar in X for example without using two hands.
Once I got over the fact that windows95 osr2 uses a fat/32 filesystem which cannot be modified by fips, I used partition magic, a utility by Powerquest to resize the windows95 partition I was able to install Redhat 4.2 without trouble. The alternative would have been to repartition the disk by hand using fdisk and then reinstall Windows off of the supplied CD-ROM. I choose to partition the disk 800MB for Windows and 600MB for Linux since I needed to install some large Windows applications such as Adobe Frame and Microsoft Office. Rather than have separate var / and home filesystems I opted for a single large Linux partition. A 64MB slice reserved for swap, this made sense since I didn't expect var to grow too much. The computer wouldn't be serving to much and that everyone using the portable under Linux would be logging in as the same user.
The Toshiba 220cds uses a Chips and Technologies 65555 chipset for the video display. While AcceleratedX and MetroX support this chipset it is also well supported by XFree86's SVGA X server. If you choose to run the free server you can expect to get 640x480 or 800x600 on the internal display at 8 16 or 24 bits per pixels. Because it has 2MB of video memory you can drive an external monitor at up to 1280x1024 in 8-bit color.
Networking was actually easier to configure under Linux than it was in windows. The 3com Elink 3 ethernet card and megahertz 33.6 PC-card modem that we purchased were detected by Redhat's install disks which was fortunate because I installed Redhat 4.2 via NFS using the network card. Because It is a portable I haven't configured it with a static-ip, rather I DHCP the portable under both Windows and Redhat which facilitates dragging it back and forth between subnets on our campus a great deal. The python based Redhat network control panel is particularly well suited to adjusting your network configuration on the fly.
Configuring sound support turned out to be a pretty interesting exercise. I chose to use the commercial OSS-Linux sound driver to support the Yamaha olp3-sa chipset that the portable has. OSS-Linux could not auto detect the settings of the sound chipset as it had done with my desktop Linux machine. It worked fairly well once I figured out which irq's and memory addresses were in use by the sound chipset, which was pretty easy using the windows95 system control panel.
The Toshiba 220cds is not by the standards of the current high-flyer in the laptop world an exceptionally fast machine, It is however full featured and even given all the accessories that we added extremely cheap. The laptop itself can be had for as little as $1600. The cost of a 3com network card and a Megahertz modem were $120 and $220 dollars respectively. A spare lithium-ion battery an additional $199 and an additional 16MB of ram was $90. In all the fully configured laptop cost less than $2300.
I have been very happy with how well the new laptop has worked out. It is a compact and elegant package, which is similar in function and design if not performance to the cream of the Toshiba notebook crop such as the Tecra 740. The moderate sacrifice in performance results in a great machine at a fraction of the cost. I would recommend such a device to anyone looking in to run Linux on a laptop.
Do you have a laptop ? And want frequently to copy files to another system ? Use mirror !
I frequently have to exchange files between my laptop and other
systems, eg. my home desktop. This can be conveniently done
using rdist(1).
I wrote a small script called mirror, which
basically contains a call of rdist setting up a small
Distfile using the shell's here syntax:
rdist -d PWD=`pwd` -f - << EOF
${PWD} -> mirror
install -oyounger ${PWD};
except_pat ( ~\\$ );
EOF
This is not the place to deal with rdist-syntax
in greater detail, so see rdist's-manpage, if you
like. Files will be copied to host mirror. Of
course you have to set up /etc/hosts
appropiately.
So working on a project with files in ~/wsp/pbd/os-tools,
I can simply say
nana:/home/bav/wsp/pbd/os-tools> mirror mirror: updating host mirror mirror: /home/bav/wsp/pbd/os-tools/main-window.tcl: updating mirror: /home/bav/wsp/pbd/os-tools/os-tools.tcl: updating mirror: /home/bav/wsp/pbd/os-tools/popups.tcl: updating mirror: updating of mirror finishedand
mirror will copy new or changed files to the very same directory on
the other node. This will be done recursively. Files on the
other node, which are younger than the files on the node I
started mirror on, will be mentioned, but remain
untouched. Emacs-backup-files will not be copied.
Using the Option -verify, you can check what will be done
without really doing anything:
nana:/home/bav/wsp/pbd/os-tools> mirror -verify mirror: updating host mirror mirror: /home/bav/wsp/pbd/os-tools/os-tools.tcl: need to update mirror: /home/bav/wsp/pbd/os-tools/popups.tcl: need to update mirror: updating of mirror finished
The option -f will remove extraneous files on node
mirror. This is useful to get a real mirror:
nana:/home/bav/wsp/pbd/os-tools> mirror -f mirror: updating host mirror mirror: lulu: /home/bav/wsp/pbd/os-tools/qqq: removed mirror: lulu: /home/bav/wsp/pbd/os-tools/otto: removed mirror: /home/bav/wsp/pbd/os-tools/main-window.tcl: updating mirror: /home/bav/wsp/pbd/os-tools/popups.tcl: updating mirror: updating of mirror finished
Besides mirroring to another system's disk mirror
can be used to mirror the current directory to a floppy. This
comes in handy for a quick kind of backup. There is no real
advantage of using rdist when operating locally.
If there is enough space available, I use cp with the options
-ruvp. To do so, call mirror with the option
-floppy:
nana:/home/bav/wsp/pbd/os-tools> mirror -floppy ./main-window.tcl -> /floppy/./main-window.tcl ./os-tools.tcl -> /floppy/./os-tools.tcl ./popups.tcl -> /floppy/./popups.tclAs with rdist, only new or changed files are copied. Mounting and unmounting the floppy is done by the script. Right now there is no way of handling extraneous files implemented.
In case you like this ideas, you can find my mirror-utility here.
Without the help of the following gentlemen, this article would not have been completed in time, would certainly be much shorter and would probably be filled with errors. In no particular order:
There are two basic approaches to benchmarking in the field of computing: the "scientific" or quantitative approach and the "benchmarketing" approach. Both approaches use exactly the same tools, however with a slightly different methodology and of course with widely diverging objectives and results.
The first approach is to think of benchmarking as a tool for experimentation. Benchmarking is a specific branch of Computer Science, since it produces numbers which can then be mathematically processed and analyzed; this analysis will be later used to draw relevant conclusions about CPU architectures, compiler design, etc.
As with any scientific activity, experiments (benchmark runs and reporting) must follow some basic guidelines or rules:
Of course, this is an idealized view of the scientific community, but these are some of the basic rules for the experimental methods in all branches of Science.
I should stress that benchmarking results in documented quantitative data.
The correct procedure for GNU/Linux benchmarking under this approach is:
This second approach is more popular than the first one, as it serves commercial purposes and gets more subsidies (i.e. grants, sponsorship, money, cash, dinero, l'argent, $) than the first approach. Benchmarketing has one basic objective, and that is to prove that equipment/software A is better (faster, more powerful, better performing or with a better price/performance ratio) than equipment/software B. The basic inspiration for this approach is the Greek philosophical current known as Sophism. Sophistry has had its adepts at all times and ages, but the Greeks made it into a veritable art. Benchmarketers have continued this tradition with varying success (also note that the first Sophists were lawyers (1) see my comment on Intel below). Of course with this approach there is no hope of spiritual redemption... Quoting Larry Wall (of Perl fame) as often quoted by David Niemi:
"Down that path lies madness. On the other hand the road to Hell is paved with melting snowballs."
Benchmarketing results cover the entire range from outright lies to subtle fallacies. Sometimes an excessive amount of data is involved, and in other cases no quantitative data at all is provided; in both cases the task of proving benchmarketing wrong is made more arduous.
We already saw that the first widely used benchmark, Whetstone, originated as the result of research into computer architecture and compiler design. So the original Whetstone benchmark can be traced to the "scientific approach".
At the time Whestone was written, computers were indeed rare and very expensive, and the fact that they executed tasks impossible for human beings was enough to justify their purchase by large organizations.
Very soon competition changed this. Foremost among the early benchmarketers was the need to justify the purchase of very expensive mainframes (at the time called supercomputers; these early machines would not even match my < $900 AMD K6 box). This gave rise to a good number of now obsolete benchmarks, as of course each different architecture needed a new algorithm to justify its existence in commercial terms.
This supercomputer market issue is still not over, but two factors contributed to its relative decline:
Next in line was the workstation market issue. A nice side-effect of the various marketing initiatives on the part of some competitors (HP, Sun, IBM, SGI among others) is that it spawned the development of various Unix benchmarks that we can now use to benchmark our GNU/Linux boxes!
In parallel to the workstation market development, we saw fierce competition develop in the microprocessor market, with each manufacturer touting its architecture as the "superior" design. In terms of microprocessor architecture an interesting development was the performance issue of CISC against RISC designs. In market terms the dominating architecture is Intel's x86 CISC design (c.f. Computer Architecture, a Quantitative Approach, Hennessy and Patterson, 2nd. edition; there is an excellent 25-page appendix on the x86 architecture).
Recently the demonstrably better-performing Alpha RISC architecture was almost wiped out by Intel lawyers: as a settlement of a complex legal battle over patent infringements, Intel bought Digital's microelectronics operation (which also produced the StrongARM (2) and Digital's highly successful line of Ethernet chips). Note however that Digital kept its Alpha design team and the settlement includes the possibility by Digital to have present and future Alpha chips manufactured by Intel.
The x86 market attracted Intel competitors AMD and more recently Cyrix which created original x86 designs. AMD also bought a small startup called NexGen which designed the precursor to the K6, and Cyrix had to grow under the umbrella of IBM and now National Semiconductor but that's another story altogether. Intel is still the market leader since it has 90% of the microprocessor market, even though both the AMD K6 and Cyrix 6x86MX architectures provide better Linux performance/MHz than Intel's best effort to date, the Pentium II (except for floating-point operations).
Lastly, we have the OS market issue. The Microsoft Windows (R) line of OS's is the overwhelming market leader as far as desktop applications are concerned, but in terms of performance/security/stability/flexibility it sometimes does not compare well with other OSes. Of course, inter-OS benchmarking is a risky business and OS designers are aware of that.
Besides, comparing GNU/Linux to other OSes using benchmarks is almost always an exercise in futility: GNU/Linux is GPLed, whereas no other OS can be said to be free (in the GNU/GPL sense). Can you compare something that is free to something that is proprietary (3) Does benchmarketing apply to something that is free?
Comparing GNU/Linux to other OSes is also a good way to start a nice flame war on comp.os.linux.advocacy, specially when GNU/Linux is compared to BSD Unices or Windows NT. Most debaters don't seem to realize that each OS had different design objectives!
These debates usually reach a steady state when both sides are convinced that they are "right" and that their opponents are "wrong". Sometimes benchmarking data is called in to prove or disprove an argument. But even then we see that this has more to do with benchmarketing than with benchmarking. My $0.02 of advice: avoid such debates like the plague.
The SPEC95 CPU benchmark suite (the CPU Integer and FP tests, which SPEC calls CINT95/CFP95) is an example of a promising Jedi that succumbed to the Dark side of the Force ;-).
SPEC (Standard Performance Evaluation Corporation) originated as a non-profit corporation with the explicit objective of creating a vendor-independent, objective, non-biased, industry-wide CPU benchmark suite. Founding members were some universities and various CPU and systems manufacturers, such as Intel, HP, Digital, IBM and Motorola.
However, some technical and philosophical issues have developed for historical reasons that make SPEC95 inadequate for Linux benchmarking:
Summarizing, if you must absolutely compare CPU performance for different configurations running GNU/Linux, SPEC95 is definitely not the recommended benchmark. On the other hand it's a handy tool for benchmarketers.
SMP (Symmetric MultiProcessing) has been implemented in the Linux kernel for Intel Pentium, Pentium MMX, Pentium Pro and Pentium II processors (4) and more recently for SPARC architectures. SMP systems are usually more expensive than their uniprocessor counterparts because they are frequently used to implement heavy-duty (possibly fault-tolerant) servers. For this reason potential buyers of such systems often want to make sure that applications, OS and hardware platform will be able to satisfy their needs in terms of overall performance before deciding on an expensive purchase. This is precisely where a Linux SMP benchmark would be useful. As this series of articles focuses on using current and stable 2.0.x kernels, we will only deal with what could be done for benchmarking Linux SMP systems with current Linux distributions.
Taking advantage of the additional computing power brought to the end-user by an SMP hardware platform puts constraints on almost all layers of the software involved: application, runtime libraries and operating system.
Basically two approaches are possible depending on how the application being considered is designed:
The table below summarizes the impact of these two designs on the software layers involved, on the programming complexity and on the expected performance improvement (relatively to a comparable uniprocessor system):
| Application | Multiple single-threaded processes | Multi-threaded application |
| Runtime libraries special requirements | None. | Libraries must be thread safe and should preferably offer some POSIX control over the threads. |
| Operating system special requirements: load balancing | Smart assignment of processes to processors must be implemented (static or dynamic). | An assignment mechanism of kernel-threads to processors must be supported |
| Example | make -j 4 vmlinux | None available AFAIK. |
| Additional programming complexity | None. | Greater than for single-hreaded applications, but it can be done by us mere mortals. |
| Expected performance improvement | Average to poor. | High (close to linear speedup) for CPU bound applications but can also degrade to become as low as single processor performance for system call intensive applications. |
How do those issues relate to current stable Linux kernels?
Good results obtained from a Linux multi-threaded benchmark would be very interesting for power users.
Threads can be implemented at the user-level as coroutines (e.g. the LinuxThreads package), or can be kernel threads (i.e. threads running in user mode but scheduled by the kernel). Until the very recent release of Glibc 2.0 which RedHat 5.0 includes as its standard C library, finding a thread safe runtime library could be a tough job.
The issue here is the way scheduling is implemented on SMP platforms by the current stable kernels. Quoting its implementor Alan Cox (in a paper he wrote in 1995):
"A single lock is maintained across all processors. This lock is required to access the kernel space. Any processor may hold it and once it is held may also re-enter the kernel for interrupts and other services whenever it likes until the lock is relinquished. This lock ensures that a kernel mode process will not be pre-empted and ensures that blocking interrupts in kernel mode behaves correctly. This is guaranteed because only the processor holding the lock can be in kernel mode, only kernel mode processes can disable interrupts and only the processor holding the lock may handle an interrupt."
So a correct interpretation of this is: right now, no more than a single process may be executing in kernel mode (i.e. executing a system call) at any given time.
But efforts are underway to improve the granularity of locking in future 2.2.x kernels. We should also soon be able to take interrupts without having to take a lock. This should result in much better performance of system call intensive applications on SMP systems running GNU/Linux.
If we stick to our guideline for simple, quick running, readily available benchmarks (or more simply, K.I.S.S. benchmarks), we can use a modified version of the Linux kernel 2.0.0 compilation benchmark (described in article II), now for SMP systems. Andy Kahn provided us with this test and some very interesting results. Quoting directly from some email we exchanged on this subject:
"...actually, it's pretty simple. GNU "make" has an option you can specify to use multiple processes (either a default number or a user specified number).I don't have the man page handy right now, but i'm pretty sure it's either the -j option or the -p option (actually, i think both options have some importance to multiple processes). Once you specify multiple make processes, each process will have gcc compiling something (so in effect, it's just multiple gcc processes).
(later)
"Andre Derrick Balsa" wrote:
-> Great news :-)
->
-> Thanks to Andy who actually tried this on a dual PPro SMP system and
-> explained the whole thing to me, I am pleased to announce a version of
-> the Linux 2.0.0 kernel compilation application benchmark for SMP
-> systems:
->
-> Just replace the "make vmlinux" (was "make zImage") by "make -j n
-> vmlinux". Replace n by 2, 3 ... and make will launch 2, 3 ... processes
-> in parallel. Since Linux SMP will transparently distribute processes
-> between the SMP processors, there is no need to program anything special
-> in terms of message-passing, clone(), etc...
->
-> Andy doesn't have any exact figures available, but it seems this would
-> provide a 30% decrease in compilation time (over a single serialized
-> process). Thanks, Andy. :-)
->
and because I don't have any exact figures, I decided that I would go and get some exact figures. :)
The system tested was:
Dual Pentium Pro 180MHz overclocked to 200MHz 64MB EDO RAM
Linux 2.0.27 gcc v2.7.2.1 libc v5.3.12
hda: QUANTUM TRB850A, 810MB w/96kB Cache, LBA, CHS=823/32/63
This is more or less your "standard" PC from about 13-14 months ago. I'm not at liberty to upgrade the software on this system, so this is as good as it gets from me with this setup.
Also, instead of doing a "sync" before issuing the final "make" command, I propose that if the circumstances allow it (you have root access), then umount the file system, remount it, then go back to that directory and build the kernel.
--- THE RESULTS! ---
"time make vmlinux" 107.32user 149.01system 4:27.91elapsed 95%CPU (0avgtext+0avgdata 0maxresident)k 0inputs+0outputs (143472major+167951minor)pagefaults 0swaps
"time make -j 2 vmlinux" 131.13user 177.77system 3:28.34elapsed 148%CPU (0avgtext+0avgdata 0maxresident)k 0inputs+0outputs (169498major+168582minor)pagefaults 8903swaps
Ugh, the results are terrible (only a 22% improvement)!! Note that in the SMP case, CPU usage was only 148%. From this, we can see that the 2nd CPU wasn't really used all that much (efficiently)."
I really appreciated Andy's attitude: not only he improved on my previous test procedure, but he went right ahead and produced some nice experimental data to go with it! Plus one can feel how enthusiastic he was at doing some hands-on experimentation!
Another nice feature of this simple SMP benchmark is that it provides a basis for performance comparisons between uniprocessor and SMP GNU/Linux systems.
Two more benchmarks would deserve a thorough description, but I will just mention them here:
One should be aware of some specific details when benchmarking GNU/Linux systems, as compared to benchmarking on other OS's.
GNU/Linux is a multitasking, multiuser system. So, obviously system load will skew results. On the other hand, this may be exactly the behavior that we want to test: how will a GNU/Linux system perform under heavy use? There is no simple answer to this question. Again, careful data gathering and analysis may reveal interesting opportunities for GNU/Linux improvement.
Note that system load particularly affects latencies, so one should be very careful about the conceptual differences between latency and throughput.
Just a short example, provided by Jeremy Chatfield ( Xi Graphics : some X servers will freeze for various seconds under heavy load, resulting in mouse movements that can become quite jerky. This behavior is totally undesirable, and yet it is not measured by any X server benchmarking tool available.
Also, in a multiuser, multitasking system, the time function reports various items that must be analyzed separately: CPU time vs system time vs elapsed time (mentionned in article II). So, for a CPU benchmark, we should use CPU time, since the time spent during I/O or system functions is irrelevant. In the case of a system benchmark, it is probable that we will try to write a benchmark that spends most of its time in the kernel, so we will use system time. On the other hand, for our Linux kernel 2.0.0 compilation benchmark, we used elapsed time. There is no general rule to be followed here, one must use one's good sense.
Some caveats also apply to NFS benchmarks. The present Linux NFS implementation runs in user space, not in kernel space as in BSD Unices. Similarly, comparing the performance of Linux as a router against dedicated hardware would be an example of comparing Apples and Oranges. Even though Linux networking performance is very good, particularly with some DMA bus mastering Ethernet controllers/drivers, it cannot possibly be compared to dedicated routing hardware.
We finally get to the practical part of this article. As usual, I propose a different benchmark as a practical example, only this time we will be seeing a more complex benchmark, in fact a CPU benchmark suite: we'll use the latest version of nbench-byte (version 2.1) as our example. You can download it from Uwe Mayer's new Web site or from the Linux Benchmarking Project
What we are going to measure this time can be described as "general CPU performance". So: this is not processor performance for matrix operations, this is not MMX performance, this is not the ability of a processor to decode an MPEG stream. Also, this is not a measure of a processor interrupt response time, peak MIPS, etc.
Now let's take a look at a correct procedure, following all the steps recommended in section 1.1
For this short example we just want to compare the performance of two different CPUs: the AMD K6 and the Cyrix 6x86MX. This is comparative benchmarking, so we should keep all conditions fixed and vary just this single variable: the CPU.
This is not too ambitious and I have no bias for/against any of these two chips. Also, since both CPUs are widely available at reasonable prices, such comparative benchmarking may be of interest to GNU/Linux users wanting to upgrade and/or put together their next CPU.
Nbench-byte is an improved, updated version of the BYTEmark benchmark suite developed at BYTE magazine by Rick Grehan. Uwe F. Mayer did the port to Linux and is its present maintainer/developer. The latest version is 2.1, dated December 97.
Similarly to SPEC95, this modern CPU benchmark suite uses 10 different algorithms that are representative of common CPU-intensive tasks (the file bdoc.txt included with the source has a description of each algorithm). Note that Rick has stopped development of BYTEmark (neither Uwe nor myself managed to contact him), but you can see that this is not a committee-designed benchmark; in this respect its lineage fits quite well the GNU/Linux style of development.
Nbench-byte 2.1 also goes one step beyond SPEC95 in that it generates three index figures: an Integer Index, a Floating-Point Index and a Memory Index. The Memory Index reflects the fact that on most modern CPUs, the memory subsystem represents a major performance bottleneck. You can check the Web site for STREAM a new benchmark specifically created to address this issue, for more information on this topic.
One of nbench-byte nicest features is that it calibrates itself. For each of the tests it determines a minimum amount of work that needs to be done to be able to accurately measure the time needed. Then it runs that test five times and does a statistical analysis (using the student-t distribution) to see if the results are consistent (meaning that the probability is at least 95% that the true mean of the results is within 5% of the calculated mean of the results). If not, then nbench runs the test up to twenty-five times more and does the statistical analysis after each additional test run. If consistency cannot be achieved within a total of thirty runs, a warning will be issued when the score gets reported.
In terms of raw data statistical processing, nbench-byte 2.1 goes beyond all the other benchmarks I have ever come across.
Another very interesting feature of this benchmark suite is its portability across a wide range of OS's and platforms. However, because of fundamental differences in compiler/libraries/memory management in different OSes, this benchmark should not be carelessly used to compare results across platforms. This is not an OS benchmark, it's a CPU benchmark (see the pitfalls subsection below). You have been warned.
We are doing comparative benchmarking, so we will be using exactly the same hardware for our benchmark runs. All that will change between runs is:
Also note that we are using the precompiled nbench executable, as shipped in the tar.gz package.
To describe our hardware setup, we resort to the Linux Benchmarking Toolkit Report Form:
LINUX BENCHMARKING TOOLKIT REPORT FORM
CPU
===
Vendor: AMD/Cyrix
Model: K6-166/6x86MX-PR200
Core clock:166 MHz (2.5 x 66MHz)
Motherboard vendor: ASUS
Mbd. model: P55T2P4
Mbd. chipset: Intel HX
Bus type: PCI
Bus clock: 33 MHz
Cache total: 512 Kb
Cache type/speed: Pipeline burst 6 ns
SMP (number of processors): 1
RAM
===
Total: 32 MB
Type: EDO SIMMs
Speed: 60 ns
Disk
====
Vendor: IBM
Model: IBM-DCAA-34430
Size: 4.3 GB
Interface: EIDE
Driver/Settings: Bus Master DMA mode 2
Video board
===========
Vendor: Generic S3
Model: Trio64-V2
Bus: PCI
Video RAM type: 60 ns EDO DRAM
Video RAM total: 2 MB
X server vendor: XFree86
X server version: 3.3
X server chipset choice: S3 accelerated
Resolution/vert. refresh rate: 1152x864 @ 70 Hz
Color depth: 16 bits
Kernel
======
Version: 2.0.29
Swap size: 64 MB
gcc
===
Version: 2.7.2.3
Options: (default nbench)
libc version: 5.4.38
Test notes
==========
Two processors tested. The 6x86MX was configured with a special rc.cyrix file.
RESULTS
========
Linux kernel 2.0.0 Compilation Time: N/A
Whetstone Double Precision (FPU) INDEX: N/A
UnixBench 4.10 system INDEX: N/A
Xengine: N/A
nbench-byte integer INDEX: 6x86MX - 0.686; K6 - 0.713
nbench-byte memory INDEX: 6x86MX - 0.753; K6 - 0.793
nbench-byte floating-point INDEX: 6x86MX - 0.655; K6 - 0.802
Comments
=========
With the CPU case open, it took me 30 minutes to run nbench-byte on the two processors!
One can get very detailed benchmark results with nbench-byte 2.1 by specifying the -v option. However, here we are only showing the normal output from a standard run, first on the 6x86MX, then on the K6:
6x86MX results:
BYTEmark* Native Mode Benchmark ver. 2 (10/95)
Index-split by Andrew D. Balsa (11/97)
Linux/Unix* port by Uwe F. Mayer (12/96,11/97)
TEST : Iterations/sec. : Old Index : New Index
: : Pentium 90* : AMD K6/233*
--------------------:------------------:-------------:------------
NUMERIC SORT : 80.681 : 2.07 : 0.68
STRING SORT : 11.107 : 4.96 : 0.77
BITFIELD : 2.1997e+07 : 3.77 : 0.79
FP EMULATION : 8.5349 : 4.10 : 0.95
FOURIER : 881.21 : 1.00 : 0.56
ASSIGNMENT : 0.71582 : 2.72 : 0.71
IDEA : 147.28 : 2.25 : 0.67
HUFFMAN : 58.095 : 1.61 : 0.51
NEURAL NET : 0.70897 : 1.14 : 0.48
LU DECOMPOSITION : 27.869 : 1.44 : 1.04
==========================ORIGINAL BYTEMARK RESULTS==========================
INTEGER INDEX : 2.861
FLOATING-POINT INDEX: 1.181
Baseline (MSDOS*) : Pentium* 90, 256 KB L2-cache, Watcom* compiler 10.0
==============================LINUX DATA BELOW===============================
C compiler : gcc version 2.7.2.3
libc : libc.so.5.4.38
MEMORY INDEX : 0.753
INTEGER INDEX : 0.686
FLOATING-POINT INDEX: 0.655
Baseline (LINUX) : AMD K6/233*, 512 KB L2-cache, gcc 2.7.2.3, libc-5.4.38
* Trademarks are property of their respective holder.
K6 results:
BYTEmark* Native Mode Benchmark ver. 2 (10/95)
Index-split by Andrew D. Balsa (11/97)
Linux/Unix* port by Uwe F. Mayer (12/96,11/97)
TEST : Iterations/sec. : Old Index : New Index
: : Pentium 90* : AMD K6/233*
--------------------:------------------:-------------:------------
NUMERIC SORT : 82.229 : 2.11 : 0.69
STRING SORT : 10.57 : 4.72 : 0.73
BITFIELD : 2.0672e+07 : 3.55 : 0.74
FP EMULATION : 6.4842 : 3.11 : 0.72
FOURIER : 1117.1 : 1.27 : 0.71
ASSIGNMENT : 0.93388 : 3.55 : 0.92
IDEA : 158.42 : 2.42 : 0.72
HUFFMAN : 81.407 : 2.26 : 0.72
NEURAL NET : 1.0764 : 1.73 : 0.73
LU DECOMPOSITION : 26.521 : 1.37 : 0.99
==========================ORIGINAL BYTEMARK RESULTS==========================
INTEGER INDEX : 2.990
FLOATING-POINT INDEX: 1.445
Baseline (MSDOS*) : Pentium* 90, 256 KB L2-cache, Watcom* compiler 10.0
==============================LINUX DATA BELOW===============================
C compiler : gcc version 2.7.2.3
libc : libc.so.5.4.38
MEMORY INDEX : 0.793
INTEGER INDEX : 0.713
FLOATING-POINT INDEX: 0.802
Baseline (LINUX) : AMD K6/233*, 512 KB L2-cache, gcc 2.7.2.3, libc-5.4.38
* Trademarks are property of their respective holder.
We will concentrate on the Linux data, for obvious reasons. As we can see, whereas the 6x86MX outperforms the K6 on some tests by a narrow margin (approx. 6%), the K6 vastly outperforms the 6x86MX on other tests.
On our synthetic test nbench-byte version 2.1, the K6 has shown slightly better performance than the 6x86MX, running at the same 166MHz (2.5 x 66MHz) clock rate on exactly the same hardware.
The basic pitfall that one should be warned against concerning nbench-byte applies similarly to all benchmarks: one should not to try to use this tool for something it was not designed for. Since this is a CPU benchmark, do not use it to test OS performance, video bandwidth, or any other feature that implies I/O activity. Also, it is not an adequate tool for comparing compilers and/or C and math libraries.
This is less obvious than it seems at first. For an accurate, thorough, documented discussion of this particular pitfall, you are referred to one of Uwe's excellent pages on benchmarking
Another pitfall would have been to compare the two processors running on widely different machines. Motherboard, cache and RAM timing setup can skew results by as much as 10%. Compilation options and libraries can also skew results by 25% or more.
I had initially estimated that four articles would be enough for an overview of GNU/Linux benchmarking, but recently more issues have been raised and more questions have been asked than I could address in just four articles. The next article will deal with exactly this problem: Available Linux Benchmarking Data and Open Issues.
(1) Basic objective of Sophists: win all arguments by any means available. Truth, logical coherence and argument transparency did not matter to Sophists. They were fought (on intellectual grounds, of course) by Socrates and Plato and later by Aristotle. A quick search on Yahoo/Altavista with keywords Sophism or Gorgias will turn up some information on the subject.
(2) StrongARM: this is an architecture developed at Digital, based on the Advanced Risc Machines design. It provides roughly the same CPU processing performance as a 133 MHz Pentium at a fraction of the cost and with a ridiculously low power consumption (< 0.5W). Intel's purchase of Digital's microelectronics operation includes the design rights to the StrongARM, so the future of this architecture is unknown (as of December 97). Note that Linux has been ported to some implementations of the ARM architecture. The Corel Java NC is based on Linux/ARM and uses the latest version of the StrongARM SA-110 CPU.
The following is strictly rumour: Digital didn't quite know what to do with the StrongARM design, since as a product it didn't fit Digital's corporate culture of high-margin minis and workstations. On the other hand, it was just a nice bargain for Intel, who was looking for exactly that sort of CPU to address the future "appliance PC" market, ideally complementing the Pentium family. Since the details of the Digital/Intel deal have been kept secret, one can only guess how much Intel paid for the StrongARM design, but rumour has it that Digital's negociators were not even aware of how strategically important this CPU was to Intel.
(3) To get a clearer idea of what free means in the GNU/Linux world, you are referred to the various Richard Stallman (founder of the Free Software Foundation interviews and articles, to the GNU manifest, and also of course to the text of the General Public License (GPL). In a speech in 1986, RMS said:
"I want to establish that the practice of owning software is both materially wasteful, spiritually harmful and evil. All these three things being interrelated."
(4) Intel did not license its APIC SMP specifications/technology to either Cyrix or AMD. Even though Cyrix and AMD agreed on a different, open specification called OpenPIC for multiprocessing, no motherboard was ever released to that standard (and no OS has ever implemented it, obviously). An excellent description of OpenPIC and x86 multiprocessing issues can be found in IBM's Application Note 40208, available in pdf format from IBM's Microelectronics Web site
The meeting notice on Usenet (including comp.os.linux.announce) set the tone for the event: Richard M. Stallman's original announcement of the GNU project (Subject: Free Unix!) was the centerpiece. The event: the traditional LXNY meeting at UNIX EXPO (this year a part of Miller Freeman's IT Forum '97) in New York City. The speaker: Bryan Sparks, Founder and CEO of Caldera, Inc. The setting: a corner room at the Javits Center seating 75, with a crowd of approximately 100 enthusiasts overflowing into the corridor.
Jay Sulzberger of LXNY delivered a rousing introduction to the speaker, establishing a martial-revolutionary theme. After regaling the assembled troops with stories of RMS at MIT, he echoed Linus Torvalds' call for more applications and strongly cautioned Linuxers on the need to avoid internecine conflict -- the war is to be waged on many fronts in many ways, even including alliances with commercial vendors. (Caldera offers both free and commercial versions of Linux (and (DR) OpenDOS).) Sparks spoke about the Caldera international operation, non-desktop environments (especially kiosks), their partnerships, their lawsuit against Microsoft, the continuing phenomenal growth of Linux and the need for perseverance. He mentioned that Caldera has sold 2,000,000 copies of OpenDOS.
Caldera brought some of their partners to the meeting including Corel (WordPerfect for Linux), Enhanced Software Technologies (bru), AppGen Business Software, FacetCorp, TwinCom and ICentral. Also represented were VAResearch and Non-Profit Computing. Caldera provided food, T-shirts, flashlights and OpenLinux Lite CDs to all present.
LXNY's booth at the show, which contained a display of Linux publications, was as big a success as the meeting.
If you haven't networked your small office/home office computers, ethernet prices are now so cheap you can't afford not to! I recently installed a three-computer LAN, including my dual- boot Linux/Win95 box (named Dave), my wife's WfW 3.11 box (named Kathy), and my Linux/Win95 portable. We share files among the three computers and print to the laser printer on Dave from within Windows.
The SMB protocol (server message blocks) does all this over IP. SMB/IP is built into Win95 and WfW; Linux uses the Samba program to talk SMB. A special challenge was to get Dave to look the same to Kathy whether Dave is booted in Linux or Win95. This technique could also be helpful if you are changing from a Windows server to a Linux server, and you don't want to redo the settings on each client. All the software is free, once you own the operating systems. My total hardware costs were under $100, including a five port 10 base T hub, network interface cards, and twisted-pair cables.
John Fisk's article on Samba in LG issue 20 was a great introduction to Samba. I used it to get started. Then I added printing from Windows to Linux, solved some file permission problems, and figured out how to make Dave look the same to Kathy under Linux or Win95. I'm sure what I did could be improved on -- I am new to Samba and only a journeyman at Linux, but this way works. If you worry about security, you may want to add passwords. Between my wife and me security isn't a problem ;-)
An example of Samba's power: my wife runs Quicken on Kathy under Windows. She transparently uses the Quicken data file stored in a DOS partition on Dave running Linux. She transparently prints from Quicken to the laser printer on Dave. She doesn't have to change any settings on Kathy when I switch Dave between Linux and Win95. And my settings on Dave are handled automatically on bootup. Way cool!
Here's how I did it:
I used System Commander to dual boot My box (Dave)to Win95 or Linux. I installed networking on both operating systems, using the same IP addresses. I named my SMB group "home." Fisk's article shows how to do most of this. My Linux release (Caldera) comes with Samba installed. Probably your release does too. Samba runs as two daemons: smbd and nmbd. Find them by typing
which smbd; which nmbdIf they are installed, they are probably in /usr/sbin. If not, install them. Caldera Linux starts them on bootup by running the script /etc/rc.d/init.d/smb. Note that if you change the Samba configuration file, it isn't necessary to reboot (at least using Caldera or Red Hat.) Just issue the commands
/etc/rc.d/init.d/smb stop /etc/rc.d/init.d/smb startand Samba will be reconfigured. Fisk's article points out that Samba may also be started by init.d. You don't want to start Samba twice, so check your settings after reading Fisk.
I created the following /etc/smb.conf file on Dave:
[global] workgroup = home printing = bsd printcap name = /etc/printcap load printers = yes guest account = dos [printers] comment = All Printers ; print command = cp %s /tmp/tmp.print print command = lpr -Pepson -b %s browseable = yes printable = yes public = yes writable = no create mode = 0700 [d] comment = DOS Disk d: path = /mnt/diskd/ public = yes writable = yes printable = no guest ok = yesThe [global] section of smb.conf tells Samba that my workgroup is called "home," the printer description file is /etc/printcap, and the user (or guest account) for dos services is "dos." To set up the user "dos" run the program "adduser dos" or just edit the /etc/passswd file. I had to edit /etc/passwd after running adduser to get things right. My /etc/passwd file has the following line for the user dos:
dos::501:500:DOS files:/home/dos:/bin/falseIn order of fields this line says the user is dos; dos needs no passwd; its user number is 501; its group number is 500; it is called DOS files (this field is just a comment); its home directory is /home/dos; and it has no shell privileges. The user and group number were assigned by adduser; they don't have to be 501,500. To test that the user dos is set up right, change /bin/false to /bin/bash and log on as dos. You shouldn't need a password and should get a bash shell prompt. Then change back to /bin/false to close the security hole. When I ran adduser, I told it that dos belongs to group DOS, and it added the group DOS to the /etc/group file with the line
DOS::500:The [printers] section sets up printing for DOS. The commented- out line "print command = cp %s /tmp/tmp.print" is a great way to debug Samba printing. I found this in the help file "Printing.txt" that comes in the Samba package. If this line is uncommented and the next one commented out, the print file from Kathy appears on Dave as /tmp/tmp.print rather than being sent to the printer. You can check whether it arrived OK and try printing it by running lpr. The line "print command = lpr -Pepson -b %s" does the actual printing. The option "-Pepson" says to use the "epson" printer description in /etc/printcap. My laser printer on Dave is called "epson" under Win95, and Kathy expects to see the same name under Linux. The option "-b" tells lpr to accept the binary print files that Windows produces. Otherwise lpr chokes because its default is to expect ASCII files, and the printer does nothing. (Maybe this fix is the same as what is called raw mode printing?) The "%s" parameter represents the file name being sent to Samba.
I created a section in /etc/printcap for the epson printer:
epson:\
:sd=/var/spool/lpd/lp:\
:mx#0:\
:lp=/dev/lp1:\
:sh:
Notice there is no "if=" line, i.e. no input filter that
processes the binary print file. My printer is an Epson 7000,
basically a HPIIp clone, so it expects the DOS convention of CRLF
at line's end. If I tried to use this printer description when
printing under Linux, which only sends the Unix standard LF, I
would see the dreaded staircase effect.
The [d] section of smb.conf describes the shared disk that Kathy expects to be called "d," the same as drive D: under DOS. I mount it as /mnt/diskd in Linux.
I ran into a puzzling problem with user permissions (probably either my ignorance of standard Unix practice, or something weird about msdos filetype.) The user dos needs to have write privileges to the directory /mnt/diskd and all its files. But I couldn't make that happen using chmod, chown, or chgrp. As soon as I would reboot and mount the file system, /mnt/diskd would revert to the following privileges:
drwxr-xr-x 44 root root 18432 Dec 31 1969 diskd/The missing "w" for group and others did me in as long as root owned the directory.
I fixed this by editing the line in /etc/fstab for /mnt/diskd to be the following:
/dev/hda5 /mnt/diskd msdos user,noauto 0 0The important field is user,noauto, which means mountable by a user and don't automatically mount on bootup. The I added a line to /etc/rc.d/rc.local to mount diskd as user dos:
mount -ouid=501,gid=500 /mnt/diskdThis says mount /mnt/diskd with option (-o) of user id 501 and group id 500, which correspond to the user dos. If your adduser gives dos a different uid and gid, just change this line appropriately. If you have trouble mounting diskd on bootup, try logging in as dos (after changing the /etc/passwd line for dos to /bin/bash) and mounting diskd manually. When that works, go back and get the rc.local line to work right.
As John Fisk wrote: one thing about Linux, it hones your problem solving skills. If you have problems, look in Samba's logs and message files. On my system the logs are in /var/log/smbd and /var/log/nmbd. Messages are in the directory var/samba.
That's all it took for me to set up Samba. The Samba documentation shows a wealth of different configurations. At first I found them all daunting, but by chipping away, one problem at a time, things came more easily. I hope this article helps you get started. Who needs NT servers anyway?
For a long time, I lived in my cave, doing my thing. One day, I got out of my nice, very functional cave and saw that my fellow man had built a house just outside. It had all the same functions that my cave had but was much comfortable and livable (for one, you didn't have to push a boulder to close the door every night).
Many years later, I got Linux installed on my personal computer, doing my thing. One day, surfing the net, I saw my fellow man programming a new version of Linux, which had a great user interface, was easy to install and possessed much more new added features. For a long time user of Linux on an i386 like me all Linux was good for was routing packets. This was a shock.
Of course, the new user interface I am talking about is called the KDE project, which along with the new Red Hat distribution version 5.0, the very active www.linux.org site and the many applications available form an incredible package. To my great astonishment, Linux development is in full acceleration and is starting to be viewed as a real contender to Microsoft Windows NT. Not too long ago, people installing Linux on a computer where viewed as computer gurus, or mystic "roots". With the arrival of user friendliness, the question I ask myself is: Is Linux going to become an operating system for the general public?
Some people will feel bad of loosing the respect of being the only ones able to install Linux in their social group. As opposed to them, I welcome this new age. I can't wait to install Linux at my grandma's place. The operating system of the people will finally come back to the people.
This will, however change many things. If less technically inclined people jump on the Linux wagon, new demands will be generated for easier-to-use software and better support and help files. My grandma will ask for drag-and-drop support and very large fonts. The new people on the wagon will not be of much help in moving it forward (have you ever seen your grandma code lately?). Still, they will bring new respect to the OS, and, well, why not, perhaps new ideas.
Some time ago, word from "Santa Cruz" was that we had to upgrade out of Linux. This of course was funny and it highlighted the maturity of Linux. Not only that Linux is free but it compares better (on my scorecard) to almost any other operating system. And unlike some "other" operating system, Linux is soon to become a general public operating system (hello grandma!).
So, I finally decided I was going to move out of my cave and into I much more respectable house. But the most important thing of it all, I must start keeping track of the developments and start pushing the wagon myself. By the way, Linux makes a great Christmas gift!
Watching the Linux operating system begin to mature is interesting these days. A couple of years ago much attention was devoted to incompatibilities with various hardware components, networking, and the development of the kernel itself. Though these activities continue, it's no longer necessary to follow these development efforts as closely in order to run a dependable Linux system. Distributions have improved immensely, and now more free-software developers are turning their attention towards refinement and integration of the user interface. Two separate projects have arisen in the past year, KDE (the K Desktop Environment) and GNOME (the Gnu Network Object Model Environment). Both of these projects include among their stated goals the desire to make the administration and usage of a Linux system easier for beginners, in part by employing a uniform look-and-feel for the most commonly used applications and utilities, as well as interoperability of the system components. It's difficult to make much of a comparison between the two, as KDE is much farther along than GNOME, but I'll make an attempt.
There is one common structural aspect to these two projects. They each rely on a group of shared libraries, which provides the interface to basic OS operations, such as file-reading and saving, as well as basic display and appearance functions. The end result of this is that an installation will populate adirectory with a variety of shared libraries, which in turn supports another directory of fairly small executables. The Gimp works this way as well; the individual plug-ins tand to be small, but rely on the services provided by both the GTK and the Gimp shared libs. This approach facilitates contributions by programmers not directly involved with a project, as many of the low-level and window-display functions are already written, allowing a contributed application or extension to "hook" into them.
The first of the two to gain momentum was KDE. About a year ago a group of developers, mainly European, began coding the components of this ambitious project. They chose the Qt toolkit (from TrollTech in Norway) as the GUI framework, a decision which has since led to some controversy. Qt has a few licensing restrictions which, though not onerous for end-users, can cause problems for the creators of CDROM-based distributions. Advocates of GNU-style free software tend not to favor Qt, a circumstance which led to the creation of the GNOME project.
Setting aside the thorny licensing issues, the KDE developers have managed to pull together quite a remarkable system in the past year, though numerous bugs still remain evident. The second public beta was released in November of 1997, and I compiled and installed it soon after. (I had briefly tried the initial beta, but found it too unstable to evaluate).
This second release still has flaky aspects, but enough of it works to give the user an idea of what the developers are planning to accomplish. In effect KDE is a sort of GUI wrapper around an existing Linux system, which attempts to simplify system-administration tasks and offer interacting and compatible utilities and applications. Kfm is at the core of the system, as it is intended to be left running in the background and serves as the help-viewer for all of the KDE components. Kfm is also a file-manager (icon-based, with some resemblance to xfm and moxfm) and serves creditably as a web-browser.
Kfm is an impressive application, and in itself justifies trying out KDE. Many of the other applications are replacements for programs which most Linux users probably already have and would only be desirable if a complete KDE system is the goal.
KDE has its own window-manager, kwm, which had some display faults on my system. Due to these video artifacts I didn't use it much, but it did appear stylish and well-designed. It seems that these display bugs don't show up on most systems; I suspect that it depends upon the video-card and X-server in use.
A new Linux user (especially someone accustomed to Windows or Macintosh systems) might appreciate the relative ease of configuration and use which KDE offers. In a sense, KDE extends the scope of the tasks traditional distributions perform. One drawback might be the very comfort of the KDE environment itself; the various system-administration tasks outside of KDE's abilities might seem too daunting or unapproachable without a KDE interface. This won't be seen as a drawback to prospective users who lack the fascination with internals and configuration which in the past has typified Linux users.
Some KDE users have reported that they find the system usable and useful, but with my particular setup this wasn't the case. But I have to say that my extensively customized Linux installation seems perfectly satisfactory as is, and I probably lack the motivation to spend the time learning to adapt KDE to my needs. If KDE had existed back when I first booted up a Slackware system some years ago, who knows...
Miguel Icaza (head of the Midnight Commander development group) also seems to be at the helm of the new GNOME development project, which has goals similar to those of KDE, with one difference: the project is composed completely of GNU-style free software. This project is based upon the GTK toolkit, the free successor to Motif in the Gimp development efforts. The project arose as a direct response to the KDE project, and the GNOME developers have borrowed some code from KDE for a few of the applets.
As of late December (version 0.10) GNOME as a whole isn't really suitable for actual use, but several of the applets function well and the future looks bright for the project. Miguel Icaza is in the process of porting the Midnight Commander file-manager to GTK, which will let it fit in with the remainder of the GNOME applications.
The Panel applet, written primarily by Federico Mena Quintero, is an icon-bar and program-launcher which locates itself at the bottom edge of the screen. It features cascading menus which could be a substitute for the usual window-manager root menus. Most of the GNOME applets have been included in the default menu of Panel, allowing this applet to serve as an entry-point to the GNOME installation. It takes a little fiddling around to get the hang of using Panel, so don't give up if at first glance it seems like nothing is working
The provided applets include a desktop-manager (which in part serves as an interface to the Xlockmore screensaver), CroMagnon (an interface to the crontab utility), an audio mixer, an interface to the elaborate LinuxConf configuration manager, several nicely-done games (some of which were adapted from KDE), and several others.
One major difference between GNOME and KDE is that KDE includes a window-manager, whereas GNOME doesn't, and is designed to cooperate with a user's current window-manager. This may make GNOME more appealing to seasoned users who have extensively customized their window-manager resource files.
As I write this only the source code is available for GNOME 0.10, and it's tricky to compile. An intel-Linux binary archive of the 0.9 release is available from this site, but I would recommend waiting a while for either an updated binary release or an easier-to-build source release. The developers are hard at work these days (judging by their mailing-list postings) and I think that, given time, something both interesting and usable will appear.
Though KDE is closer to being "finished" (if such a state even exists in the realm of software), it still has a ways to go. Development is proceeding rapidly, and I imagine that sometime this year a more polished release will become available.
The fate of a free-software project is interesting because of the inherent unpredictability. Anyone can start one, but whether it comes to fruition or withers on the vine is up to the inscrutable software gods. The timing may be just right (i.e., it addresses many users (and developers!) needs) but convincing enough programmers with time and inclination to become involved just can't be forced or foretold. These two projects seem to have attained that essential momentum, and hopefully we shall see them evolve further. Last modified: Sun 4 Jan 1998
Here in north-east Missouri we are currently afflicted with a heavy, wet snowfall, so the time is ripe to write a page updating some of my past Gazette articles, along with some e-mail which has come my way.
I've received quite a few messages concerning my article in LG
#22, Word-Processing vs. Text-Processing. Eric
Marsden sent this message concerning the Lout
text-formatting system:
From: Marsden Eric <[email protected]>
To: [email protected]
Subject: [LG] Lout-mode for Emacs
Hello Mr Ayers,
In the October Linux Gazette you wrote an article comparing different document formatters, and mentioned Lout in passing. I noticed that you regretted the lack of an Emacs mode for Lout code.
I agreed with you, and set out to write one. Indeed, there are now two Emacs modes, since another Lout user had also set about writing one, independently of my effort. Both are available on my site, where you'll also find the Lout FAQ/HOWTO.
You were right to mention that "The Lout system is still maintained and developed"; Jeff Kingston is quite receptive to suggestions and requests for new features in the formatter, which is far from being the case for TeX (now frozen) and LaTeX (whose development group seems very closed).
I agree that Lout is very much less widely used than LaTeX, which is a definite disadvantage. I believe that things will change over time, in particular given Lout's very strong capabilities for mixing graphics and text. I might even write an article for the Linux Gazette myself to spread the word. Eric Marsden
emarsden @ mail.dotcom.fr
It's elephants all the way down. [LA: sounds like a Terry
Pratchett quote!]
I tried out the XEMacs mode found at the above link, and though it's still under development, it works well here and is well worth investigating.
Here's another interesting message:
From: [email protected] (Christopher Oliver)
Subject: TeX/GROFF
To: [email protected]
I noticed in your defense of mark-up systems, you didn't touch on issues regarding quality of output. If you write on this in the future, you might find What has WYSIWYG done to us? by typographer Conrad Taylor quite interesting. I think he makes quite a case that the word processors aren't suitable if the user cares about the quality of the typesetting. I think there is a lot of good thinking there for folk involved with document production at any level. This link will take you to the article.
Regards,
Christopher Oliver Traverse Communications
Systems Coordinator 223 Grandview Pkwy, Suite 108
[email protected] Traverse City, Michigan, 49684
Another message concerning Emacs and LaTeX:
To: [email protected]
Subject: Word Processing and Text Processing
From: Peter S Galbraith <[email protected]>
Nice summary!
> Emacs provides excellent syntax highlighting for LaTeX files,
> which greatly improves their readability.
I also wrote a better syntax highlighting Emacs package for LaTeX files, called font-latex.el. I think I should make it part of Emacs. I doubt you knew about it even though it's distributed as a contributed package with AUC-TeX.
> Xtem has one feature which is useful for LaTeX beginners:
> on-line syntax help-files for the various LaTeX commands.
There are a few add-on packages to AUC-TeX that do this by interfacing with latex info files:
- http://www.ifi.uio.no/~jensthi/word-help.el
- ftp://ftp.phys.ocean.dal.ca/users/rhogee/elisp/func-doc.el
Peter Galbraith, research scientist
Maurice-Lamontagne Institute,
Department of Fisheries and Oceans Canada
I confess I'd seen Mr. Galbraith's font-latex.el in the AucTeX distribution files, but didn't realize that it is an extra package which must be explicitly loaded. The version included with AucTeX is an older one; I recommend downloading the latest revision from this FTP site. Along with font-latex.el, a file called font-latex.tex is available at the site. This file is a sort of demo for font-latex.el, illustrating its capabilities. Some people won't like the very colorful approach to highlighting this LISP file provides, but with judicious selection of colors (now so much easier using the Customize facility!) the readability of TeX files is much enhanced.
I recently happened across a message posted to the
comp.editors newsgroup which eloquently expresses a plea
which I'm sure will resonate with many Linux users:
From: Des Small <[email protected]> Newsgroups: comp.editors
Subject: Re: writing an editor
Date: 17 Dec 1997 22:09:22 +0000
Organization: Southampton University
X-Newsreader: Gnus v5.5/Emacs 20.2
(discussion of editor internals snipped)
Given that the Unix world has already more editors than could possibly be required, and a dearth of even modest word-processing type apps, I would urge you at least to consider allowing multiple fonts in one document. You don't have to rewrite Word; we don't even have a competitor for Notepad (simple wysiwyg-ish thing with RTF output). And no, XEmacs does not count.
(more discussion snipped)
<rant>
But I really, really think that this particular wheel has been reinvented often enough. What I want is a toy word processor/editor, like wordpad on steroids, say, which could be used for writing simple letters to Auntie (for the Windoze crowd), and to make programming more pleasant (different faces for different bits of syntax), and a nice HTML mode. XML (a sort of SGML-lite) is coming, and its facilities for structured documents could make it a snap to develop literate programming envronments, without locking you in to one set of tools, or using (eek!) embedded TeX. You could have DTD's for almost every application, and finally supercede the (admittedly powerful) Unix "everything is a stream of bytes" philosophy with a universally understood set of conventions for structured documents. Word processors could use XML for storage! You could share files across platforms! You could even still use Emacs or vi or joe, if you wanted to!I know XEmacs can (probably) do all this, but I want a small, fast, cute version, that doesn't eat all my RAM. I want to use proportional fonts to edit text (which Sam and Wily allow) without changing my entire world-view (which they tend to insist on), and I don't care if it won't run on a vt100. It's 1997 for heaven's sake! I have a windowing system! (Admittedly, it's only X, but it's still a window system!) At the moment, my desktop has a bunch of terminal emulators, and a couple of GNU emacs frames open. These are powerful tools, but they hardly constitute a rich GUI environment that would make me the envy of all my friends (they lust after the stability of my system, but they run away screaming when confronted with the tools. And they are neither stupid nor technophobic).
I don't want a ultra-heavy power tool, and I don't care about slow serial lines: I already have tools for those jobs. I just want a sprinkling of nice fonts, and an interface which doesn't scare off Windows or Mac users. Context sensitive pop-up menus might be nice, and a reasonable (in terms of looks and functionality) menu bar, too. Real-time spell-checking along the lines of Word is quite a nice idea, too -- spellchecking email and Usenet posts is overkill if it takes any effort at all. (Even M-x ispell-buffer is effort: I have to remember to bother.) Notepad on steroids, is all I want, really. And it has to be free (as in freedom-not-price, that is).
Does anyone have one, or do I really have to roll my own? And does anyone have any info on (or pointers to) suitable data structures for such a thing?
Standard Unix tools are very powerful, and for some things I find them indispensible. But, for me at least, vt100 compatibility is a legacy issue. Sometimes I use remote systems, and then I telnet in and use vi, and I'm happy to do so. But most of the time I'm on my own Linux box, with 16Mb and clock cycles to burn. I can afford some luxuries, but I don't want a whole XEmacs. Is this really so weird, this late in computing history? Or did I swear a vow of allegience to xterms and non-proportional fonts when I signed on as a Unix user? Am I the only person who finds the current situation imperfect? Do I have to wait for GnuStep to combine the robustness and programmability of Unix (which I love) with a halfway-sane GUI-fied environment for those "I want to use a tool but I haven't got a month spare to master the interface" moments?
</rant>Sorry to rant on like that, but I feel strongly that the many things Unix does well should not (and in the eyes of the Heathen do not) excuse its barely-half-hearted embracing of the possibilities of the new-fangled (ahem...) bit-mapped screen.
Des,
who sometimes feels trapped in a 1980's timewarp.
After reading the above posting, I began to think about editors which can display proportional fonts. Off-hand I can think of three which offer this option: XEmacs, the semi-commercial Edith editor, and NEdit. All three display Postscript fonts well only if bitmapped versions are available, which limits you to the fonts (such as Times Roman and New Century Schoolbook) supplied with X. XEmacs will attempt to scale other Type 1 fonts but they are unaliased and unsightly. Edith and NEdit don't even try to scale the fonts, and only the 12 point size is offered in the font dialogs. This isn't the fault of the editors I've mentioned; they just do what X will allow them to do. There are several Type 1 font rasterizers under development for Linux, and perhaps this deficiency in the X environment will eventually be addressed. This could be helpful in attracting Windows users to Linux, as Win95 and NT, for all their faults and annoyances, do display scalable fonts well.
If anyone knows of a technique for generating bitmapped fonts in various sizes from standard type-1 Postscript fonts, I'd love to hear about it!
Both the Gimp and SDCorp's WordPerfect 7 port will scale Postscript fonts flawlessly; I assume they have their own internal font-display engines. I imagine that StarOffice and Applix can do the same.
A floridly-worded letter from Harry Baecker was printed in issue 23 of LG, to which I felt compelled to respond: he seems to think my opinions on text-processing are "a ritual obeisance to received wisdom" and a "requisite Unixworld denigration of word-processors and their users". On the contrary, I have little interaction with Unix users and my expressed opinions are a direct result of my experiences using both word-processors and text-formatting systems. So there!
The folks at SDCorp in Utah have made a welcome change to the licensing scheme used in their Linux port of WordPerfect 7. When the port was first released a licensing daemon had to be running in order to run the word-processor, which would only work on the original machine on which WP was installed. Now the daemon isn't necessary, and the application isn't limited to one machine. Rumor has it that WordPerfect 8 will be ported to Linux sometime next year if sufficient interest is shown in the Linux community.
There have been new releases of several editors lately. Those of you who are of the VI persuasion will be glad to hear of new versions of all three of the actively-maintained VI-clones.
Vim is probably the most featureful of the VI-style editors. Judging by newsgroup postings, it may be the most popular as well. With the release of vim-5.0s, vim 5 has finally reached a beta rather than alpha state. This revision has a really well-implemented syntax-highlighting system for many programming and shell-script languages, and it's not too difficult to adapt to new file-types and languages. The down-side is that vim is growing larger, and is beginning to lose the quickness and low memory-usage that has been a hallmark of VI-style editors. Of course, memory is cheap and machines are more powerful these days, so this isn't as much of a factor as it used to be.
I tend to use XEmacs as my primary editor, due to its excellent programming modes, with vile/xvile as an adjunct for quick editing tasks, such as config files and e-mail messages. Vile 7.3 was released recently, and it is in my opinion the ideal vi-style editor for an Emacs user. It incorporates several of the most common Emacs keystrokes, such as control-x-1 and control-x-0, which softens the transition between the two.
Recently Paul Fox, who several years ago modified the
Microemacs code until it became the first version of the vile
vi-like editor (sounds improbable, but it's true!), posted an
interesting response in the comp.editors newsgroup. He
was responding to a query concerning the differences between vile
and vim:
From: [email protected] (Paul G. Fox)
Newsgroups: comp.editors
Subject: Re: Vile 7.3 Announcement
Date: 29 Dec 1997 00:21:07 GMT
brian moore ([email protected]) wrote:
: > How about portability? I use Vim under NT at work, Linux at home.
: : vile runs on both, and OS/2 and a bunch of other stuff. Hell, it even
: works on Solaris! :)
:and VMS and Win95. i'm not sure which i've used less. :-)
as the original vile author, i'll chime in here, but a) i'm biased :-), and b) i've never used vim much, except when looking at a specific feature implementation.
vile's design goal has always been a little different than that of the other clones (and i mean elvis, vim, and nvi here -- i don't know enough about any of the others). vile has never really attempted to be a "clone" at all, though most people find it close enough. i started it because in 1990 i wanted to to be able to edit multiple files in multiple windows, i had been using vi for 10 years already, and the sources to Micro-EMACS came floating past my newsreader at a job where i had too much time on my hands.
i started by changing the uemacs keymaps in the obvious way, and ran full-tilt into the "hey! where's 'insert' mode gonna come from?!" problem. so i hacked a little more, and hacked a little more, and eventually released in '91 or '92. (starting soon thereafter, major version numbers tracked the year of release: 7.3 was the third release in '97. i don't know what tom is going to do about the Y2K problem. ;-)
but my goal has always been to preserve finger-feel, as opposed to display visuals , and, selfishly, to preserve finger-feel most for the commands i use. :-) i've never used ex mode much, so vile doesn't have much of an ex mode. actually, it has quite an amazing ex mode, that works very well -- it just looks really odd, and a couple of commands ("t", and "m", which are beyond the scope of the current parser) are missing. for the same reasons, it also won't fully parse existing .exrc files, since i don't really think that's very important -- it does simple ones, but more sophisticated one's need some tweaking. when you toss vile's built-in command/macro language, you quickly forget you ever cared about .exrc.
just for bragging rights, i think vile had X11 support earlier than the others, thanks to work by Dave Lemke from NCD, and Keving Buettner who made it really functional. i take no credit -- i never use xvile. on the other hand, vile wasn't real useful under DOS, since it doesn't use a swap file, and the memory limits got in the way pretty quickly. (of course, this isn't a practical problem under real OSes.)
unfortunately, since none of the "vi rewrite" authors were collaborating much in the early years (if we knew about one another at all :-), i think we all made different choices for the extension commands. vile tends to follow an emacs-like model, and uses ^X and ^A as built-in (but rebindable, of course) command prefixes, and indeed uses emacs bindings directly for some commands: like ^X-2 to split a window in half.
another typical difference: i insist that ":q" should quit the editor, and not just close the current window. both nvi and vim got this wrong, imho.
another one: vile does infinite undo the way nvi does, and not the way vim does. small differences, but ones that can make a user prefer one over another.
as someone else said in this thread -- if you're choosing a new version of vi, you owe it to yourself to try them all, for half an hour of real work with each, and make your choice based on that. vim has lots and lots of support, and having this nice "comp.editors.vim" newsgroup helps :-), but the others have things to offer too, and you might like one of the others better. i do. ;-)
btw, i'm only peripherally involved in vile maintenance anymore -- Tom Dickey does most of it (thanks tom) these days -- i just run the mailing lists.
current versions can be had from: ftp://ftp.clark.net/pub/dickey/vile
paul
paul fox, [email protected]
(arlington, ma, where it's 23.5 degrees)
Steve Kirkendall's Elvis editor has also been updated recently. The X version, like vim's, has good syntax-highlighting support, and also like vim, the windows (95/nt) version is well-supported, for those users who need to work in that environment. I confess I haven't spent as much time with elvis as I have with vile and vim; perhaps another user might care to contribute?
XEmacs development continues apace. Versions 19.16 and 20.3 are available (from the home site and its mirrors) but one of the most interesting developments is taking place in the 20.5 series of betas.
A common complaint about XEmacs is its bulk and lengthy
loading time. A full distribution is huge, with many bundled
packages for which most users have little use. Trying out a new
version was not to be undertaken lightly, as the download time
was long and a large block of disk space needed to be available
for compilation. The XEmacs team is in the process of unbundling
packages, which are now available individually. The base source
archive is now around eight megabytes, while the compiled LISP
(*.elc) archive is only one and one-third megabytes. The
packages are independent, and when this beta of XEmacs is
compiled it finds whichever packages you have installed and loads
their documentation, menu-items, and keybindings. The package
subdirectory is independent of the version-specific binary and
LISP directories, so unchanged package files need not be
downloaded when upgrading to a new XEmacs version. The easiest
way to try this out is to compile the base source archive without
any packages installed and see what doesn't work. Then packages
can be incrementally installed until the desired functions are
once again available. After a new package has been unpacked, the
/lib-src/DOC file should be deleted. Run make again and
the new package should be found and incorporated into the editor.
In other words, it's a good idea to keep the built source-tree on
your disk until you've generated an XEmacs which meets your
particular needs. Of the subset of the available packages which
I installed, only the Ediff package initially failed to work, but
after some experimentation I found that the line
(require 'ediff-hook)
in the XEmacs init file caused it to be loaded.
The release version of 20.5 should be available in the late spring of 1998.
A new version of NEdit has been released recently. NEdit has become popular with programmers and general users due to its nicely-designed interface, equally-useful mouse and keyboard control, and relatively small size. Version 5.0 adds very configurable (via dialog-boxes) syntax-highlighting and a new macro language. It's one of the easiest editors to learn, and it's nearly as powerful as Emacs without being as large and memory-hungry. If you like mouse-based editing, the ability to highlight a selection and drag it to another location in the file will be appealing. This function isn't found, as far as I know, in any other editor available for Linux.
NEdit is strictly X-based; if you like to edit in a console session (admittedly a minority view these days) this editor may not be to your taste.
There are now two versions available: the main version is maintained by Mark Edel at Fermi National Laboratories, and both source and binaries are available from ftp.fnal.gov, the home site. Max Vohlken has made a number of patches to NEdit 5 which for various reasons haven't been accepted into the main distribution. He has been packaging his patched version into an alternate release, and it can be also obtained from the above site, in the /KITS/pub/nedit/v5_0/contrib/max/5.0 directory. Both versions have adherents, it seems.
Christian Bolik recently released the first new version of the desktop- and file-manager TkDesk in nearly a year. Version 1.0b5 has some nice new features (check out the Be-style icon-bar!), and is well worth looking into. This beta is supposed to be the last; as soon as [incr tcl] (an object-oriented extension of Tcl) is updated to work with Tcl8.0, TkDesk will also be able to make use of the latest Tcl/Tk releases. The TkDesk web-page has recently become inaccessible, but the new version is still in Sunsite's /pub/Linux/Incoming directory.
Henrik Harmsen's FileRunner is now (with version 2.4.1) a GNU General Public License application, which means that it will be more easily included in distributions such as RedHat and Debian. FileRunner is small, quick, and efficient, and if you have installed Tcl/Tk 8.0 you should give it a try. It can be obtained from this site.
The Midnight Commander, the versatile text-mode file-and-archive-manager, is still under continual development. Beta 4.1.19 is the latest beta, and although none of the X-windows versions are yet ready for prime-time, these recent betas are well worth installing, as useful new features are continually added. Source (which generally will compile without a hitch) is available from this site.
I must confess that the numerous icon-based file-managers, many of which have been released or updated lately, don't really suit my needs. Several are based on the venerable xfm manager, or its (apparently abandoned) successor moxfm. Surely one of you readers out there prefers this type of file-manager? Why not write an article or review for the Gazette? There's room here for all sorts of views, after all!
Jamie Zawinski is a programmer and hacker currently working
for Netscape. He has written several useful free software
programs, including xkeycaps and several of the screensaver modes
included with both Xlockmore and XScreensaver. He also was
involved in the early development of Lucid Emacs (an ancestor of
XEmacs), and has contributed to the development of many Emacs
packages including the Fontlock highlighting mode. I recently
received this message from him:
Date: Sat, 29 Nov 1997 20:20:12 -0800
From: Jamie Zawinski <[email protected]>
Organization: Netscape Communications Corporation, Mozilla Division
X-Mailer: Mozilla 3.02 (X11; U; IRIX 6.2 IP22)
To: [email protected]
CC: [email protected]
Subject: xlockmore and xscreensaver
Dear Linux Gazette folks,
I saw the article on Xlockmore by Larry Ayers in issue 18 of the Linux Gazette, and I was surprised that it didn't mention, even in passing, my XScreenSaver program!
Allow me to engage in a bit of advocacy.
Back in 1991, before Xlockmore existed, there was only Xlock. Xlock was not a screensaver: it was only a locker. There was no way to make it activate itself automatically when the console became idle, nor was there any way to avoid having it lock the screen: that is, there was no way to have it turn off when the mouse moved.
So, I wrote XScreenSaver.
XScreenSaver is superior to Xlockmore in a number of ways. The most important way, of course, is that it is actually a *screen saver*. Although Xlockmore can be configured to not require a password, it still doesn't have the ability to turn on when the machine is idle; for that you have to use an external program that launches and kills it.
The second way in which XScreenSaver is better is that it takes a server/client approach: the "xscreensaver" program itself knows how to detect idleness, and to lock the screen. The graphics hacks are not built in: the beauty of XScreenSaver is that any program which can draw on the root window can be launched by XScreenSaver for use as a graphics hack! This has several benefits:
XScreenSaver also includes a nice Demo Mode that lets the user interactively experiment with the currently-configured graphics hacks. (Until recently, most Linux users wouldn't have been able to take advantage of this, since the code had required Motif; but that is now configurable, and demo mode works with Athena widgets too -- since release 1.27 back in January 1997.)
If you have a system with more than one monitor, XScreenSaver can save them both at once: a different graphics hack will run on each, and if the two monitors have different depths (for example, if one is monochrome and the other color) they can be configured to choose their screenhacks from different lists, so that each monitor is running the hacks that look best on it.
Most of the xlockmore hacks (the ones that I liked, anyway, including the GL modes) are included with the XScreenSaver distribution; the only change made being to extract the various display modes from the monolithic XLock executable, and turn them into standalone root-window-oriented programs.
However, it's possible to have XScreenSaver run xlock itself, as just another one of its many modes -- the best of both worlds!
Do check it out: the canonical web page is <http://people.netscape.com/jwz/xscreensaver/>, which includes screen shots and descriptions of most of the included graphics hacks.
The latest version, as of this writing, is 2.12. At last count, it came with 64 different graphics hacks. Roughly a third of these were written by me; the others were graciously contributed by others.
And, of course, it's all free, under the usual X-Consortium-style copyright.
You also might enjoy my philosophical rambli ngs on the nature of screensavers, at <http://people.netscape.com/jwz/gruntle/savers.html>.
Jamie Zawinski http://people.netscape.com/jwz/ about:jwz
Since I last wrote about the Gnu Image Manipulation Program (in LG #18) both the GTK toolkit (the underlying programming framework of the Gimp) and the Gimp itself have undergone several revisions. The long-awaited version 1.0 still hasn't been released, but may have been by the time you read this. There has been talk of a release by Christmas.
There's really no reason to wait for a non-beta release, though, as the version available as of mid-December is very useful and impressive. Some incredible new plug-ins are bundled with version 19.16, and general stability has been much improved. A useful feature for new users has been added: at start-up a small window appears which contains a different usage tip at each invocation. This can be disabled at any time. One caveat: be sure to obtain the corresponding version of GTK (in this case gtk+-0.99.0), as unlike some earlier versions it is no longer bundled with the Gimp.
Here are brief descriptions of some of the new plug-ins:
I admit I've never used Adobe's Photoshop and the many commercial plug-ins available for it. Therefore my initial reaction (composed of equal parts of awe and wonder) to this plug-in may seem a bit naive, as there are several commercial extenders for Photoshop with similar capabilities. Be that as it may, clicking the mouse pointer on an image thumbnail and actually stirring and shifting pixels interactively is quite amazing.
A screenshot will give you an idea of the nature of the
interface and the options available:
The plug-in offers a choice of six different methods of changing an area of pixels in an image: clock-wise rotation, counter-clockwise rotation, growing, moving, shrinking, or removing. Playing around with this plug-in will give you a good idea of its capabilities. Try setting it to one of the rotation options, then hold the first mouse button down as you slowly move it across an image. It's as if a miniature hurricane is travelling across the image, leaving spirals of distortion in its wake. I imagine that a drawing tablet would be handy to use with this plug-in, allowing more precise control than that provided by a mouse.
Like icing on a cake, Iwarp has animation capabilities built-in. Once you have warped an image to your satisfaction, select the animation tab in the plug-in's window; this lets you choose how many frames to create, and whether to make them cycle repeatedly (the ping-pong effect) or just play from start to finish. Each frame is saved in a separate layer, and there is a convenient plug-in called Animation Playback which will let you view it.
So what's the use of this? You can use it to create animated GIF files for web-pages, or perhaps tweak a small area of an image, but mostly it is just a lot of fun!
Gimp 0.99.16 must be something of a milestone for Scott Draves, creator of the Flame and Fuse plug-ins (as well as the Bomb interactive screen hack). Though successive versions of the Flame plug-in have been available for some months now, the maintainers of the Gimp have been reluctant to include it in the Gimp distribution due to certain licensing restrictions which Scott had placed on the program and its output. Recently Scott relaxed those restrictions and Flame is now a part of the Gimp.
Flame is similar in some ways to the IFS-Explorer plug-in, in
that is based on Iterated Function Systems fractal algorithms,
but the approach and interface are different. Rather than
manipulating three triangles, which is the traditional IFS
interface used by IFS Explorer, Flame does much of its work
"behind the scenes", though there are still several options
available to the user. One nice feature is the built-in support
for the Gimp's color gradients. Several of Scott Draves' own
gradients are included in the plug-in, but any others can be
entered into an entry-field in the plug-in window. Here's a
screenshot of a typical window:
Flame can generate some really intriguing images; some of Scott Draves' examples can be seen on this web page. If you are using an earlier Gimp version, a binary of the plug-in has been thoughtfully included in the Flame archive file available from the page. Just drop the binary into your Gimp plug-in directory; the next time you start the Gimp Flame should be accessible from the "Render" sub-menu.
It's interesting to compare the results obtainable from Flame and the IFS-Explorer plug-ins, as they both are based on the same mathematical principles but have such different methods of implementing them.
Another plug-in from Scott Draves is called Fuse. This one is used to disassemble a pair of images and merge them into one, using what seems to be some sort of AI trial-and-error process. A preview window shows the various attempts in real-time, which can be interesting to watch. The process is time-consuming, as the plug-in seems to be repeatedly dissatisfied with its results, and will back up to a previous branch in the process and start anew. Scott Draves has achieved some interesting results with Fuse, which can be viewed on this web-page. It would take some practice to gain proficiency with this plug-in; this is one of those applications which may require reading the source code to get a feel for just what is going on behind the scenes. In other words, no on-line help!
The Illusion plug-in is another interesting one to experiment
with. It was written by Hirotsuna Mizuno, a Japanese
programmer. What this one does is difficult to describe; it
seems to duplicate an image and tile a new one with "faded-out"
copies of the original. This results in a surrealistic sort of
pattern, and could be useful in creating watermark-like
backgrounds. A before-and-after pair of screenshots should
convey an idea of its capabilities:
The Map-Object plug-in, though included with 19.15, unfortunately wasn't supplied with the 0.99.16 release. It is being developed by Tom Bech, of the University of Bergen in Norway. This plug-in will map or project an image onto the surface of either a sphere or a skewed plane, with full control of many parameters such as the light source's orientation and color. The background can easily be set to be transparent, which makes the output useful in HTML files. If you are still using version 19.15 of the Gimp the current version is functional. Perhaps by the time Gimp 1.0 is released Mr. Bech will find time to adapt this ingenious plug-in to the rapidly-changing Gimp/GTK environment.
Just as I was finishing this article Gimp 0.99.17 was released, and Map-Object has been reinstated into the distribution. A new version of GTK was released concurrently; visit ftp.gimp.org if you'd like to obtain the source. Debian and Redhat packages of these releases are also available there.
This is just a sampling of the more than sixty plug-ins bundled with the 19.16 release; more are appearing regularly, and when the 1.0 release is completed (and development of the Gimp moves on to a new beta version) the resulting "fixed target" should make developing new plug-ins easier for programmers. Last modified: Sun 4 Jan 1998
[A reader requested this article by Gary Moore from the April '97 issue of Linux Journal. --Editor]
Applixware is is an excellent "office suite" that may open doors to wider use of Linux.
Applixware features a word processor, a spreadsheet, a presentation graphics tool, a drawing tool, an e-mail client, database connectivity and an object-oriented application builder. For some time, this professional set of programs has been available for other Unix platforms, including HP-UX, Solaris, AIX and Digital Unix, and now Applixware is available for Intel-compatible Linux machines and Microsoft Windows; at the time of this writing, the NT version is out and the 95 version is in beta testing.
If you install Applixware on your system, you'll notice an impact on system resources. A complete installation with the included Red Hat RPM files requires 210MB--if that's more than you have available, you can make a partial installation from a live, "unpacked" directory on the CD-ROM. In fact, Applixware can be launched and used directly from the CD-ROM, though this makes program operation a little leisurely. I was using Red Hat Linux 4.0 when I reviewed Applixware, but the software should work fine on other distributions, and installation instructions are included.
The CD speed may not seem bad if you're using a 486DX25, on which Applixware is fast enough to be usable, but probably too slow for a production environment; I found my meager CPU power to be a real problem only when I started using the graphics tools.
This is not an application for low-memory systems. As cheap as RAM is today, this shouldn't be too painful a state to rectify. With 16MB of RAM, the word processor was snappy enough with X and the Afterstep window manager running, but having much else loaded caused so much paging of virtual memory I needed something to read while waiting.
Not much reading material comes with Applix--at least, not on paper. Back when it was known as Asterix and also in version 3.x of Applix, there was a manual for each module, but either with the Linux version or with the later releases, virtually all documentation is in the "On-Line Books". Use the on-line tutorials if you're new to the system, or the on-line help if you just need a reference.
Applix Words is a full-featured word processor with everything you'd expect to find in a modern product. That is, unless you're looking to do something which really should be done using desktop publishing software. By the way, one thing you never want to do with it is embed, oh, 80 or so large, 256-color GIFs in a single document--at somewhere around 8MB, application behavior gets a bit wacky. Linking is much, much better.
Words gives you tables, borders, shading, embedded equations and calculations, conditional text and cross-referencing, international dictionaries, thesauri and a multi-font, multi-size WYSIWYG display. You can rely on multiple undo and redo, and when you're done, you can save PostScript and PCL printer files or send them directly to a networked printer.
HTML is easy with the Applix HTML authoring tool. Documents can be imported from Applix or another popular word processor using one of the format filters or created from scratch with the same ease as a word processing document. Clip art, GIFs and linked or embedded Applix Graphics images are converted seamlessly. Applix Spreadsheets documents and queries from the database interface application, Data, can be included, too. Tables, colors, and more than 25 standard HTML styles are all under your control.
Applix Graphics is a terrific drawing and presentation graphics tool. At your disposal are user-definable fill patterns, various brush styles, shearing, drop shadows, incremental zoom, rotating, scaling, color pixel editing and text wrapping, to name a few. Grid snap, guide lines, rulers, and coordinates help create precise and complex drawings quickly. I found graphics as easy to produce with Graphics as with Powerpoint.
The good news continues with Applix Spreadsheets with calculation-based attributes, 3D charts, named views and dynamic links to objects in other Applixware applications. When your linked data from elsewhere changes, it is automatically updated in your spreadsheet. There are live links to a relational database through Applix Data, goal seeking, drag-and-drop, projection tables and background recalculation. You can import those old Lotus 1-2-3 and Excel spreadsheets, too.
You might not think you need another mail client, but check out Applix Mail. When you receive mail, a dialog box pops up with the sender name and subject, giving you the options "Read Now", "Read Later", and "Help". You can attach Applix files to your mail messages and upon receipt, launch the appropriate Applix tool for viewing. Mail can be marked "Urgent", marked with a "Reply by" date, and also sent by "certified" mail, giving you a receipt when the recipient has read the mail. Of course you can "Cc" and "Bcc" people. You also get shared mail folders, automatic conversion of messages and documents to your preferences, encryption, and mail filtering based on rules you specify.
Applix Data connects Applixware applications to SQL databases like Informix, Oracle, Ingres, and Sybase, seamlessly querying data from one or more tables, selecting information with query conditions, and performing advanced queries and joins. Rows can be edited, inserted, and deleted. A live link in your document to the database means up-to-date data. Data provides a lot of capability when teamed with ELF and Builder.
The Extension Language Facility (ELF) is an interpreted language with which users can build and deploy applications, front-ends to applications, automate tasks and connect to databases and other external sources of data. The Applix user interfaces are built with ELF and ELF macros can be used to automate tasks in any of the Applixware applications. Some capabilities include: TCP/IP socket interfacing, remote procedure calls, interactive debugging, many built-in macros, string manipulation, and arithmetic and Boolean operators.
Builder is object oriented and gives you access to external data sources as well as the capabilities of the Applixware application suite for use in your custom applications. Also, full access to ELF macros and functions, external objects, shared classes, RPC and shared library support. Plus, the applications you develop in Builder on one platform are portable to Applixware on other platforms without modification.
Applixware is a terrific package. When I heard it was available for Linux, I knew I could let go of Microsoft Office (and MS Windows) forever.
If you are a potential website/permanent connection, the first thing you should know about is security...
I, from personal experience know what happens when people 'hack' into my machine, it nearly become an international court case. I won't go into details, but it was from my ignorance, and is why I lost my job.
When setting up a machine you should have a guess who might be able to access you machine, and when you setup a new user, eg. to get pirated programs, they'll know how to get in. Sure, you might be able to get free programs and people might look at you in a different way, but if someone with more experience than you (and there is always alot of them, no matter how good you are) sees an obvious security hole they will exploit it as much as they can, so they don't get in trouble and you do.
Linux/Unix is a very flexible/Configureable OS and thats where security holes apear, and disapear. Just ask a system administrator, most Linux distributions need some work before they are close to internet useable, or hack proof. I personally couldn't list every file you would need to edit, but startup files (or links with redhat & debian) you will need to remove, if you don't use them, and /etc/inetd.conf is another place to start, if you don't understand these files, imidiately remove network connection, and read man pages!!!
A basic checklist might be: time, echo, nfs*, telnet*, smb (netbios), ftp, login, pop3, nntp, tftp*, netstat, finger, http, etc... (* these are popular protocols, but are can be very insecure), if you are on a network and are unsure, ask your sysadmin, they will most certainly know more from experience what you should and shouln't use, and most (experienced with Linux) could probably give you some good advice...
At this stage you've gone through and remove unecessary services, now restart your config files ('shutdown now' and login then as root then 'init 3' or restart (better ideas - send them in)), now you learn how the protocols work, what files they access, and what security holes they leave, eg. if you have people that are only using windows to share drives you might set them up in a group that has no telnet and ftp access (for example).
Adding new users should never be as easy as it seems, unless you can trust the person, eg. I have an 'smb' group on my machine for samba users, and they are denied access through telnet and ftp, since they are they only other services I offer on my machine. When working out what people have access to what, plan what you are going to do, eg. restrict certain 'groups' access to paticular services.
At this stage you are probably thinking, "What alot of stuffing around", but as an 'NT ISP' recently proved to me, even they are succeptable to incorrect user access attacks, so don't say that it is only resricted to the Unicies, all OS's suffer, it's just that Unicies can be a little harder to configure than NT, and can be attacked easier by very experienced Unix hackers, as NT with NT hackers...
But probably the biggest advantage to Linux is that 99% of the time you can get the source code and, I ask one question, if you gave away the source code for a program, are you going to leave obvious security holes for personal access, I think not...
It all mainly comes down to asking the computer, people on the internet and sysadmins what you should and shouldn't do, and a little common sense does help alot too, and have fun in the meanwhile.
C is a very small language. This is a good thing. C programmers will use nearly the entire C language every time they write a fair sized program. The standard C library extends the functionality of C in a way that is predictable on multiple systems. The library gives us tools like scanf() and printf() that make reading and writing formatted output much easier than working with blocks of characters using read() and write(). Also when you move from one C programming environment to another, the functionality of printf() will be the same. You don't have to relearn how to print formatted output every time you change machines.
In this series of articles I will discuss the tools that are available for the programmers in the standard C library. At the end is a bibliography of the books and articles that I used to get this information. I refer to these books and magazines on a daily basis when I program. If you want to work as a C programmer I strongly recommend that you buy and read these books and magazines.
Many times the standard functions are overlooked and reinvented by programmers (including myself!) to do things like seeing if a character is a letter by:
(c=>'a' || c<='z' && c=>'A' || c<='Z')
instead of using
isalpha(c);
The second form is much easier to read and figure out. There is another reason to use the second form. The first example only works for ASCII character sets, the second will work on _any_ machine. If you want to write portable code (code that can be compiled and ran on any machine with very minor changes) then use the standard C library.
Several times in the past I have written code that took time to write and debug and interface to the rest of my program only to discover that there was already a function that did what I wanted to do. A few months ago I was writing my own Multi User Dimension (MUD), based on a client/server article in Linux Journal, and I needed to process what the user had entered, one word at a time. So I wrote my own string tokenizer. Turns out I could have used the strtok() function to do almost the exact same thing. And other people will know what the strtok() function does without having to decipher my code.
Make your life easier, use the standard C library. It will also help all of us who try to update and maintain your code later.
The GNU compiler, gcc, comes with the GNU standard C library. This compiler is one of the best in the world and the GNU standard C library conforms almost exactly to the standard. In the places where the standard is imprecise, you can expect very reasonable behavior from both the compiler and the library. I am going to discuss the GNU standard C library in these articles.
The <stdio.h> library handles the standard input and output functions for C programmers. It is also by far the largest library. Because the library is so large I am going to group the commands in these sections: file operations, input and output.
Now before we talk about files we need to agree on the words that we are going to use. In Linux a file or device is considered to be a stream of data. This stream of data that is associated with a file or hardware device is accessed by your program opening the file or device. Once the stream is opened then you can read and/or write to it.
Three streams are opened automatically when you execute a program. Standard input (stdin), standard output (stdout), and standard error (stderr). These can all be redirected by your shell when you run the program but normally stdin is your keyboard and stdout and stderr both go to your monitor.
After you are done with your streams you need to tell the operating system to clean up buffers and finish saving data to the devices. You do this by closing the stream. If you don't close your stream then it is possible to lose data. stdin, stdout and stderr are all closed automatically the same way they are opened automatically.
One of the most important things to remember when dealing with devices and files is that you are dealing with the real world. Don't assume that the function is going to work. Evan something like printf can fail. Disks fill up or occasionally fail, users input the wrong data, processors get too busy, other programs have your files locked. Murphy's Law is in full effect when it comes to computer systems. Every function that deals with the real world returns an error condition if the function failed. Always check every return value and take the appropriate action when there is an error condition. Exceptions are not errors unless they are handled badly. Exceptions are opportunities for extra computation (William Kahan, on exception handling.)
The first example is to basically show how to open a file for reading. It just dumps a file called test in the current directory to the standard out. All exceptions are reported to standard error and then program halted is with an error return. It should produce an error if a file called test doesn't exist.
--------------------------------------------------------
#include <stdio.h> /* this is a compiler directive
that tells the
the compiler that you are going to be using
functions that are in the standard input /
output library
*/
main (){
/* declare variables */
FILE *stream;
/* need a pointer to FILE for the stream */
int buffer_character; /* need
an int to hold a single character */
/* open the file called test for reading in the current directory
*/
stream = fopen("test", "r");
/* if the file wasn't opened correctly than the stream will be
equal to NULL. It is now customary to
represent NULL by casting
the value of 0 to the correct type yourself
rather than having the
compiler guess at the type of NULL to use.
*/
if (stream == (FILE *)0) {
fprintf(stderr, "Error
opening file (printed to standard error)\n");
exit (1);
} /* end if */
/* read and write the file one character at a time until you reach
end-of-file on either our file or output.
If the EOF is on file_descriptor
then drop out of the while loop. if the end-of-file
is on report write
errors to standard out and exit the program
with an error condition
*/
while ((buffer_character=getc(stream))!=EOF)
{
/* write the character
to standard out and check for errors */
if((putc(buffer_character,
stdout)) == EOF) {
fprintf(stderr,"Error writing to standard out. (printed to standard
error)\n");
fclose(stream);
exit(1);
} /* end if */
} /* end while
*/
/* close the file after you are done with it, if file doesn't close
then report and exit */
if ((fclose(stream)) == EOF) {
fprintf(stderr,"Error
closing stream. (printed to standard error)\n");
exit(1);
} /* end if */
/* report success back to environment */
return 0;
} /* end main*/
-------------------------------------------------------------
The above simple program is an example of opening a file, reading
the file, and then closing the file while also using stdout, and stderr.
I cut and pasted the code to a vi session and then saved, compiled, and
ran the program.
What follows is a quick summary of the file operations in the <stdio.h> library. These are the operations that work directly with streams.
Let me discribe the format of the descriptions that you will see here and in the man pages. The first entry is the type that is returned by the function call. The second part is the function name itself and the third part is the list of variable types that the function takes for arguments.
Looking at the first line below we see that the fopen function takes two pointers to strings, one is a path to a file and the other is the open mode of the program. The function will return a pointer to FILE type which is a complex object that is defined in the <stdio.h> library. So in order to accept the return type you must have declared a variable of type pointer to FILE, like the stream variable in the example above on line 9. On line 13 of the example you can see where I call the function fopen with the static filename of "test" and a mode of "r" and then accept the return value into the stream object.
A stream can be opened by any of these three functions:
FILE *fopen( char *path,
char *mode)
FILE *fdopen( int fildes,
char *mode)
FILE *freopen( char *path, char
*mode, FILE *stream)
char *path is a pointer to a string with
the filename in it.
char *mode is the mode of opening the
file (table follows.)
int fildes is a file descriptor which
has already been opened and whose mode matches.
These functions return a pointer to FILE type that represents the data stream or a NULL of type (FILE *)0 on any error condition.
fopen is used to open the given filename with the respective mode. This is the function that is used the most to open files.
fdopen is used to assign a stream to a currently opened file descriptor. The file descriptor mode and the fdopen mode must match.
freopen is normally used redirect stdin, stdout and stderr to file. The stream that is given will be closed and a new stream opened to the given path with the given mode.
This table shows the modes and their results:
open stream for
truncate create starting
mode read write
file file position
---- ---- -----
---- ---- --------
"r" y
n n
n beginning
"r+" y
y n
n beginning
"w" n
y y
y beginning
"w+" y
y y
y beginning
"a" n
y n
y end-of-file
"a+" y
y n
y end-of-file
To read the first line, "r" will open a stream for read, the stream will not be opened for write, will not truncate the file to zero length, will not create the file if it doesn't already exist and will be positioned at the beginning of the stream.
int fflush(FILE *stream)
int fpurge(FILE *stream)
FILE *stream is an already existing stream.
These functions return a 0 on success. On a failure they return an EOF.
fflush is used to write out the buffers of the stream to a device or file.
fpurge is used to clear the buffers of unwritten or unread data that is in a buffer waiting. I think of this as a destructive purge because it clears the read and write buffers by dumping the contents.
int fclose(FILE *stream)
FILE *stream is an already existing stream.
Returns a 0 on success, or an EOF otherwise.
fclose flushes the given streams buffers and then disassociates the stream from the pointer to FILE.
int remove(char
*path)
int rename(char
*oldpath, const char *newpath)
char *path, oldpath and newpath are all pointers to existing files.
Returns a 0 on success and a non-zero otherwise.
remove works just like rm to remove the file in the string pointed to by path.
rename works just like move to rename a file from oldpath to newpath, changing directories if need be.
FILE *tmpfile(void)
This command returns a pointer to a FILE of stream which is a temp file that magically goes away when your program is done running. You never even know the files name. If the function fails it returns a NULL pointer of type (FILE *)0.
char *tmpnam(char *string)
This function returns a filename in the tmp directory that is unique, or a NULL if there is an error. Each additional call overrides the previous name so you must move the name somewhere else if you need to know the name after you open the file.
int setbuf(
FILE *stream, char *buf);
int setbuffer( FILE *stream,
char *buf, size_t size);
int setlinebuf( FILE *stream);
int setvbuf(
FILE *stream, char *buf, int mode , size_t size);
Where mode is one of the following:
_IONBF unbuffered,
output sent as soon as received.
_IOLBF line buffered,
output sent as soon as a newline is received.
_IOFBF fully buffered,
output isn't sent until size characters are received.
setbuf is an alias for setvbuf(stream,
buf, buf ? _IOFBF : _IONBF, BUFSIZ);
setbuffer is an alias for setvbuf(stream,
buf, buf ? _IOFBF : _IONBF, size);
setlinebuf is an alias for setvbuf(stream,
(char *)NULL, _IOLBF, 0);
setvbuf sets a buffer for the given stream of size_t size and of buffer mode.
Note that terminals cannot have their stream repositioned, only block devices (like hard drives) will allow this.
Also note that if you open a file for writing and use fseek to go out 10,000 bytes, write one character and then close the file that you will not have a file of 10,001 bytes. The file will be much smaller. This is called a sparse file. If you move a sparse file using the mv command it will not change size because a mv is only a change to the directory structure, not the file. If you cp or tar a sparse file then it will expand out to its true size.
int fseek( FILE *stream,
long offset, int whence);
long ftell( FILE *stream);
void rewind( FILE *stream);
int fgetpos( FILE *stream, fpos_t
*pos);
int fsetpos( FILE *stream, fpos_t
*pos);
FILE *stream is a pointer to an already
existing stream.
long offset is added to the position
indicated by the whence.
int whence is SEEK_SET,
SEEK_CUR, or SEEK_END depending on where you want the offset
to be applied to: the beginning, the current position or the end.
fpos_t *pos is a complex file position
indicator. On some systems you must use this to get and set stream
positions.
If these functions are successful fgetpos, fseek, fsetpos return
0, and ftell returns the current offset. Otherwise,
EOF is returned. There is no return value from rewind.
fseek sets the file position in the stream to the value of offset plus the position indicated by the whence, either the begginning, the current or the end of file to get the new position in the stream. This is useful for reading along, adding something to the end of the stream and then going back to reading the stream where you left off.
ftell returns the current position of the stream.
rewind sets the current position to the beginning of the stream. Notice that no error code is returned. This function is assumed to always suceed.
fgetpos is used like ftell to return the position of the stream. The position is returned in the pos variable which is of type fpos_t.
fsetpos is used like fseek in that it will set the current postion of the stream to the value in pos.
On some systems you have to use fgetpos and fsetpos in order to reliably position your stream.
However, if you write a nice GUI word processor you don't want the program to stop everytime it can't open a file. You want it to display the error message to the user and continue. In a future article I will deal this error code functions, or someone else can summarize them for us and send in an article and some commented source code to show us how it's done.
If anyone is interested the functions are: clearerr, feof, ferror, and fileno.
Next month I want to talk about input and output. I will take the simple program above and add some functionallity to it to add a column of numbers and output the results to standard out. Hopefully this example program can grow into something useful.
The Standard C Library, P. J. Plauger, Printice Hall P T R, 1992
The Standard C Library, Parts 1, 2, and 3, Chuck Allison, C/C++ Users Journal, January, February, March 1995
STDIO(3), BSD MANPAGE, Linux Programmer's Manual, 29 November 1993
Unidentified File Objects, Lisa Lees, Sys Admin, July/August 1995
A Conversation With William Kahan, Jack Woehr, Dr Dobb's Journal, November 1997
Java and Client-Server, Joe Novosel, Linux Journal, January 1997
I saw the article on Xlockmore by Larry Ayers in issue 18 of the Linux Gazette, and I was surprised that it didn't mention, even in passing, my XScreenSaver program!
Allow me to engage in a bit of advocacy.
Back in 1991, before Xlockmore existed, there was only Xlock. Xlock was not a screensaver: it was only a locker. There was no way to make it activate itself automatically when the console became idle, nor was there any way to avoid having it lock the screen: that is, there was no way to have it turn off when the mouse moved.
So, I wrote XScreenSaver.
XScreenSaver is superior to Xlockmore in a number of ways. The most important way, of course, is that it is actually a *screen saver*. Although Xlockmore can be configured to not require a password, it still doesn't have the ability to turn on when the machine is idle; for that you have to use an external program that launches and kills it.
The second way in which XScreenSaver is better is that it takes a server/client approach: the "xscreensaver" program itself knows how to detect idleness, and to lock the screen. The graphics hacks are not built in: the beauty of XScreenSaver is that any program which can draw on the root window can be launched by XScreenSaver for use as a graphics hack! This has several benefits:
* You don't have to recompile and reinstall xscreensaver to install a new graphics hack: all you have to do is change your X resources, and issue one command.
* Since programs don't have to be written *specifically* to run inside the xscreensaver framework, there are many more potential graphics hacks available. They don't even need to be written in the same language: they just have to draw on the root. Thus, it's easier to write programs to work with XScreenSaver than with Xlock or Xlockmore, because they don't have to follow a complex set of idiosynchratic rules on how to structure the code: the only rule is, "draw on the root."
* By separating the task out into two processes, the whole system becomes more robust: the memory protection provided by the OS serves us well, in that, if one particular graphics hack has a bug (leaks memory, corrupts memory, gets a floating-point exception, etc) the integrity of the screen saver itself is not compromised. The offending hack may exit, but the screen saver itself is still running, and the screen is still blackened (or locked.) Also, since a screen saver is, by its nature, a very- long-running background task, even a small leak would build up over time. By arranging for the graphics hacks themselves to be relatively short-running tasks, this problem goes away.
* On some systems, only programs which are running as root can check passwords. Therefore, on such systems, a screen locker would need to be a setuid-root program. Obviously one needs to be very careful about what programs one allows out of the security sandbox; a conscientious sysadmin would want to examine such a program very carefully before installing it. The XScreenSaver model allows this, by having the priveleged part of the program (the saver itself) be small, while letting the larger part (the graphics hacks) remain unpriveleged.
XScreenSaver also includes a nice Demo Mode that lets the user interactively experiment with the currently-configured graphics hacks. (Until recently, most Linux users wouldn't have been able to take advantage of this, since the code had required Motif; but that is now configurable, and demo mode works with Athena widgets too -- since release 1.27 back in January 1997.)
If you have a system with more than one monitor, XScreenSaver can save them both at once: a different graphics hack will run on each, and if the two monitors have different depths (for example, if one is monochrome and the other color) they can be configured to choose their screenhacks from different lists, so that each monitor is running the hacks that look best on it.
Most of the xlockmore hacks (the ones that I liked, anyway, including the GL modes) are included with the XScreenSaver distribution; the only change made being to extract the various display modes from the monolithic XLock executable, and turn them into standalone root-window-oriented programs.
However, it's possible to have XScreenSaver run xlock itself, as just another one of its many modes -- the best of both worlds!
Do check it out: the canonical web page is http://people.netscape.com/jwz/xscreensaver, which includes screen shots and descriptions of most of the included graphics hacks.
The latest version, as of this writing, is 2.12. At last count, it came with 64 different graphics hacks. Roughly a third of these were written by me; the others were graciously contributed by others.
And, of course, it's all free, under the usual X-Consortium-style copyright.
You also might enjoy my philosphical ramblings on the nature of screensavers, at http://people.netscape.com/jwz/gruntle/savers.html.
Larry Ayers
André D. Balsa
Gerd Bavendiek
Erik Campo
Jim Dennis
Joel Jaeggli
Dave Nelson
Mark Nielsen
James M. Rogers
Ylian Saint-Hilaire
Michael E. Smith
Jamie Zawinski
Thanks to all our authors, not just the ones above, but also those who wrote giving us their tips and tricks and making suggestions. Thanks also to our new mirror sites.
Margie and I had a great Christmas break in Houston, Texas, where much of her family lives. Besides visiting with family and numerous friends we got to tour the Cockrell butterfly habitat, which was very pretty. Mostly sunny days and highs in the 60s made it tough to return to the middle of a Seattle winter, but we managed.
Have fun!
Riley P. Richardson
Editor, Linux Gazette [email protected]
Linux Gazette Issue 24, January 1998, http://www.linuxgazette.com/
This page written and maintained by the Editor of Linux Gazette,
[email protected]