Prettier Firefox

Some kind of theme/style hack to make the buttons and other form controls look nicer under Linux. Not being much of a gourmet when it comes to visual niceties, I don't really see too much difference. And it does require you to register at the Ubuntu forums to download it, so I probably won't bother. But I would guess it would work for any KDE or Gnome based Firefox installation. If you try it, let me know.

Hackszine.com: Beautify Firefox widgets in Ubuntu

Setting up a dual boot

Nice, picture heavy tutorial for setting up a computer to boot both openSUSE and WinXP.

Dual boot: Windows XP & openSuSE 10.2

Tuning your LAMP

Nice set of articles from Big Blue on LAMP (Linux, Apache, MySQL, PHP/Perl), covering how to tune your setup to its most efficient.

developerWorks : Linux : Tuning LAMP systems


(Thanks to nixCraft for the pointer)

Equivalence

A couple of nice pages listing Linux equivalents to popular Windows software. I've blogged about the first one before, but the second one is new to me. It is a little out of date, but seems to be more encompassing.


The Linux Equivalent Project - linuxeq.com

The table of equivalents / replacements / analogs of Windows software in Linux

Get Closer To Windows

Nice, short, to the point posting about how to easily and efficiently integrate your Linux box into a Windows network. It allows for easy navigation to Windows shares. I gotta try this!

Cool Solutions: Integrating Your Linux Host into a Windows Environment

Becoming SMART

I have started to run into a couple of small problems with the YaST software installer, besides the general slowness of everything, so I have decided to embark upon my SMART journey. I'm going to follow the instructions found here (man, there sure are a lot of wiki's out there!).

The first thing I learned was about the existence of /etc/SuSE-release, which is a simple text file describing the installed version of openSUSE:

$ cat /etc/SuSE-release
openSUSE 10.2 (i586)
VERSION = 10.2

Okay, so as predicted, I'm running openSUSE 10.2. And I think I have all the correct files installed:

$ rpm -q python-xml python-elementtree rpm-python
python-xml-2.5-19
package python-elementtree is not installed
rpm-python-4.4.2-76

Oops, I guess I don't. I wonder if python-elementtree is really necessary, as I'm sure if it was that my YaST installation would have taken care of it? Looking into it, it isn't listed as a dependency and YaST says it isn't installed alright. So I'll install it via YaST, rather than use the commandline as found in the web page. Hold on a sec... Okay, let's check again:

$ rpm -q python-xml python-elementtree rpm-python
python-xml-2.5-19
python-elementtree-1.2.6-41
rpm-python-4.4.2-76

There, that's better. Now, it's time to fire up SMART as root.

$ su -c "smart update"
Password:
New channel 'Packman 3rd Party Package Repository (packman)' detected.
Include it? (Y/n):

New channel 'Current KDE applications (suse-kde-backports)' detected.
Include it? (Y/n):

New channel 'Guru smart repository (smart)' detected.
Include it? (Y/n):

New channel 'Latest mozilla.org packages (suse-mozilla)' detected.
Include it? (Y/n):

New channel 'Latest KDE packages (suse-kde)' detected.
Include it? (Y/n): n

New channel 'SUSE 10.2 Repository (suse)' detected.
Include it? (Y/n):

New channel 'SUSE 10.2 Add-On Repository with non-OSS Packages (suse-non-oss)' detected.
Include it? (Y/n):

New channel 'Guru 3rd party package repository (guru)' detected.
Include it? (Y/n):

New channel 'Latest wine packages (suse-wine)' detected.
Include it? (Y/n):

New channel 'SUSE Linux Online Updates (suse-update)' detected.
Include it? (Y/n):

Updating cache...

I didn't enable 'Latest KDE packages (suse-kde)' because of the warning on the web page, although I'm a little confused. I really don't want to be cutting edge. I have no need for the latest in graphical ui technology, so I'm pretty happy to stay with the stable release when it comes to my desktop environment. But I have to wonder if 'suse-kde' is really the "highly experimental" version? After the "Updating cache", it did plenty of fetching. Let this be a warning - don't do it in your Emacs shell window, as it wants to do the kinds of redrawing found only in Konsole. It took about five minutes to do all my channels. Then I installed the gui.

$ su
Password:
# rpm --import http://linux01.gwdg.de/~pbleser/guru-rpm.asc
# smart install smart-gui
Updating cache...                         ######################################################### [100%]

Computing transaction...

Upgrading packages (4):
smart-0.51-1.guru.suse102@i686                      smart-gui-0.51-1.guru.suse102@i686
smart-addons-0.51-1.guru.suse102@i686               smart-ksmarttray-0.51-1.guru.suse102@i686

2.8MB of package files are needed. 1.2MB will be freed.

Confirm changes? (Y/n):

Fetching packages...
-> http://ftp.gwdg.de/pub/linux/misc/suser-guru/rpm/10.2/RPMS/i686/smart-0.51-1.guru.suse102.i686.rpm
-> http://ftp.gwdg.de/pub/linux/misc/suser-guru/rpm/10.2/.../smart-ksmarttray-0.51-1.guru.suse102.i686.rpm
smart-ksmarttray-0.51-1.guru.suse102.i6.. ######################################################### [ 25%]
-> http://ftp.gwdg.de/pub/linux/misc/suser-guru/rpm/10.2/RPMS/i686/smart-gui-0.51-1.guru.suse102.i686.rpm
smart-gui-0.51-1.guru.suse102.i686.rpm    ######################################################### [ 50%]
-> http://ftp.gwdg.de/pub/linux/misc/suser-guru/rpm/10.2/.../smart-addons-0.51-1.guru.suse102.i686.rpm
smart-0.51-1.guru.suse102.i686.rpm        ######################################################### [100%]


Committing transaction...
Preparing...                              ######################################################### [  0%]
1:Installing smart                     ######################################################### [ 12%]
2:Cleaning smart                       ######################################################### [ 25%]
3:Installing smart-ksmarttray          ######################################################### [ 37%]
4:Cleaning smart-ksmarttray            ######################################################### [ 50%]
5:Installing smart-gui                 ######################################################### [ 62%]
6:Cleaning smart-gui                   ######################################################### [ 75%]
7:Installing smart-addons              ######################################################### [ 87%]
8:Cleaning smart-addons                ######################################################### [100%]

Saving cache...

# smart --gui

I have to admit, I like the YaST window a little more, as there seems to be more options, but it surely is faster. From command to dialog takes about 30 seconds, while YaST takes a good couple of minutes. And it seems to have found lots and lots of packages to update. We'll see how screwed up it makes my system!

Does anyone really know what time it is?

There was an interesting discussion on the opensuse mailing list about finding out which command is going to get used when you type something in. The Original Poster (OP) couldn't figure out why some options found in the time man page weren't working:

$ time -o ls
bash: -o: command not found

real    0m0.008s
user    0m0.000s
sys     0m0.000s
$ time --help
bash: --help: command not found

real    0m0.003s
user    0m0.000s
sys     0m0.008s
$

Of course, any veteran of the commandline could tell you it is not executing the time command as documented in the man page, but some other time command, in this case bash's builtin time command, which doesn't have the -o or the --help options. So you have to tell the shell exactly which command you are looking to execute, or use bash's man page or help command to get info on its version:

$ /usr/bin/time -o t.out ls
$ /usr/bin/time --help
Usage: /usr/bin/time [-apvV] [-f format] [-o file] [--append] [--verbose]
[--portability] [--format=format] [--output=file] [--version]
[--help] command [arg...]
$ help time
time: time [-p] PIPELINE
Execute PIPELINE and print a summary of the real time, user CPU time,
and system CPU time spent executing PIPELINE when it terminates.
The return status is the return status of PIPELINE.  The `-p' option
prints the timing summary in a slightly different format.  This uses
the value of the TIMEFORMAT variable as the output format.
times: times
Print the accumulated user and system times for processes run from
the shell.

So the discussion evolved into answering the important question - "How can you tell which command is actually getting executed when you don't type in the full path?" One hint is in the question - use the which command:

$ which time
/usr/bin/time
$ which -a time
/usr/bin/time
$

Hmm, now that doesn't work! That's what I had always used, especially the -a flag, which should show all versions of the command, rather than just the first one. It turns out a better option is bash's builtin type command, which does know about aliases and builtins:

$ type time
time is a shell keyword
$ type -a time
time is a shell keyword
time is /usr/bin/time
$

Okay, that's much better, although the suggestion to use the -p option just makes it revert back to the mysteriously incomplete which output:

$ type -ap time
/usr/bin/time
$ help type
type: type [-afptP] name [name ...]
For each NAME, indicate how it would be interpreted if used as a
command name.

If the -t option is used, `type' outputs a single word which is one of
`alias', `keyword', `function', `builtin', `file' or `', if NAME is an
alias, shell reserved word, shell function, shell builtin, disk file,
or unfound, respectively.

If the -p flag is used, `type' either returns the name of the disk
file that would be executed, or nothing if `type -t NAME' would not
return `file'.

If the -a flag is used, `type' displays all of the places that contain
an executable named `file'.  This includes aliases, builtins, and
functions, if and only if the -p flag is not also used.

The -f flag suppresses shell function lookup.

The -P flag forces a PATH search for each NAME, even if it is an alias,
builtin, or function, and returns the name of the disk file that would
be executed.
typeset: typeset [-afFirtx] [-p] name[=value] ...
Obsolete.  See `declare'.

So I learned about the type command, which is really what you want to use. But then I started investigating the which command, which led to a surprise:

$ type -a which
which is aliased to `_which'
which is /usr/bin/which
$ type -a _which
_which is a function
_which ()
{
local file=$(type -p ${1+"$@"} 2>/dev/null);
if test -n "$file" -a -x "$file"; then
echo "$file";
return 0;
fi;
hash -r;
type -P ${1+"$@"}
}

Whoa, where did that come from? A quick perusal of the bash man page tells me bash, on start up:

       When  bash  is  invoked  as an interactive login shell, or as a non-interactive shell
with the --login option, it first reads and executes commands from the file /etc/pro-
file,  if  that  file exists.  After reading that file, it looks for ~/.bash_profile,
~/.bash_login, and ~/.profile, in that order, and reads and  executes  commands  from
the  first  one that exists and is readable.  The --noprofile option may be used when
the shell is started to inhibit this behavior.

So I checked out /etc/profile, which is a very long shell script doing all kinds of interesting things, worth a post all in its own. But one of the last things it does is to execute /etc/bash.bashrc, which again is a fascinating script setting a whole bunch of mostly bash-specific things, again worth a look at in itself. In there, a whole bunch of aliases get set up and there is this section:

if test "$is" = "bash" ; then
#
# Other shells use the which command in path (e.g. ash) or
# their own builtin for the which command (e.g. ksh and zsh).
#
_which () {
local file=$(type -p ${1+"$@"} 2>/dev/null)
if test -n "$file" -a -x "$file"; then
echo "$file"
return 0
fi
hash -r
type -P ${1+"$@"}
}
alias which=_which
fi

Interesting. I wonder why they do this instead of using the /usr/bin/which command in the path? It doesn't seem to improve anything over the system which command except add an unnecessary layer of obfuscation.

But I will look over my .bashrc file, which, much like my .emacs file, has accompanied me for many years, to see what I should remove as redundant, as the openSUSE standard one does a lot of it already. I wonder how standard it is on other Linux distros? Looks like I'll have to check the MACHTYPE environment variable for the Linux type:

jdarnold@opensuse $ echo $MACHTYPE
i686-suse-linux
$ 

jarnold@redhat $ echo $MACHTYPE
i386-redhat-linux-gnu
$