On 28-Nov-05 Wayne Stallwood wrote:
[...] The involuntary reboot is inexcusable.
What should happen is that idle applications should get swapped out of memory...I am almost positive OSX does this and (based on the performance of my Linux box) am pretty sure Linux does it.
To the best of my knowledge, what Linux does is keep idle applications in memory where possible, and the code for dead ones too (i.e. they've been closed down), in case they're needed again. This means that resuming, or restarting, avoids disk read/writes. Unless, of course, something else needs the space, in which case idle apps will be elbowed out to disk, and dead ones will be simply over-written.
You could test this (in a clean session, i.e. soon after boot) by doing say 'vim somefile' (where "somefile" already exists, to make it a fair test). Without altering the file, just ":q" to quit. Then do something else, and then come back to 'vim somefile'. You should observe that it starts up again perceptibly faster (unless of course your machine is so fast that the difference is subliminal).
However, having to type code on a command line to open OOo leaves me cold.
Me too, I understand what Brett is saying that sometimes it is quicker,but that's only true if you know the filename of the application you are want. To somebody who is using it for the first time what's intuitive about typing "oowriter" to launch a Word Processor ?, Even after the first time why should I have to remember that my Word Processor is called oowriter and not just writer or OOWriter ?
One of the features of Linux is that you can set up an alias or a symbolic link to an app, or embed it in a shell script, with an intuitive and snappy name.
For instance, since I use 'telnet' a lot, I have the symbolic link "tl -> telnet" in /usr/bin. Likewise, in my /etc/hosts file my MCC mailhost nessie.mcc.ac.uk has "nickname" 'ns'. So to log in to nessie, I just do
tl ns
and off I go. beats "telnet nessie.mcc.ac.uk". Similarly my local machines "tedistan", "brandy", "compo" and "daisy" are "td", "br","co" and "dy", all leading to very snappy command lines ("tl td" etc.).
However, there's a lurking "gotcha" if you use the symbolic link trick, in that some programs depend on this to behave differently depending on how they are evoked. For example, in /usr/bin
ls -l /usr/bin | grep sendmail [stuff] hoststat -> /usr/sbin/sendmail [stuff] mailq -> /usr/sbin/sendmail [stuff] newaliases -> /usr/sbin/sendmail [stuff] purgestat -> /usr/sbin/sendmail
(quite what happens here depends on your distribution). The point is that the commands 'hoststat', 'mailq', 'newaliases' and 'purgestat' all lead to the execution of the program /usr/sbin/sendmail, whose behaviour is different for each of these commands, since any program written in C (or C++) can find out how it was called.
In the case of such programs, you'll get a bummer if you evoke them using some non-canonical symbolic link. For instance, 'sendmail' would react with indignation if you used a symbolic link "sm" to evoke it. But you'd be safe if you had a script called "sm" in which there was an explicit call to 'sendmail'. Aliases are probably OK too, though personally I'm a bit wary of them.
To get back to the point: Your word processor may be called "oowriter" on its birth certificate, but one way or another you could set it up to be evoked by say "wp". I don't think anyone would be puzzled or upset by being able to start up a word processor in that way.
Setting up snappy easy names is useful for experienced and new users alike. For instance, in the distant past I had a dialup script, whose core was a nasty command line
/usr/sbin/dip -v /usr/local/bin/mcc-portmaster.dip
and which also included goodies like a "child-lock" to disable unsupervised access, and the name of the DialuP script was "dp". (You obviously shouldn't call it 'du').
Likewise, the script which shut it down was "dpk" ("k" for "kill"), and included a check on whether there was outgoing mail being sent to keep it running until all was done. The non-geek users got on very well with all this.
If you use your common sense, and a bit of thought, about such things you can make the command line very friendly indeed.
For example, if I put a CD's worth of tracks into a directory, put a CD in the burner, and then
mkaudioCD *
I save a lot of hassle:
cat /usr/local/bin/mkaudioCD
#! /bin/bash /usr/bin/cdrecord -v -eject -speed=2 driveropts=burnfree \ -dev=0,0,0 -audio -pad $*
and it's easy to remember the command (and it's much quicker than, and saves farting about with, xcdroast and all that sticky GUI stuff).
Not that I'm against the GUI in its place. A running program which can switch between several different types of activity is often best driven through a GUI, such as my mailer (XFMail) which is one of the nicest mail clients I've seen. Mind you, 'pine' let's you do a lot of different things too, and it's strictly keyboard-driven; but I find that using the keyboard for this kind of thing is in fact stickier than the GUI!
Best wishes to all, Ted.
-------------------------------------------------------------------- E-Mail: (Ted Harding) Ted.Harding@nessie.mcc.ac.uk Fax-to-email: +44 (0)870 094 0861 Date: 28-Nov-05 Time: 01:52:08 ------------------------------ XFMail ------------------------------