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
$

Terminally Yours

Most Unix and Linux distros have what are called "virtual terminals". You reach these by hitting Ctrl-Alt-F key, where F1-F12 bring you to virtual terminal 1 through 12. A couple of them are special ones:

• F1 : Virtual terminal 1 is the 'boot terminal', where you will see all the boot up messages. In FreeBSD, it is also where system console messages are displayed.


• F7 or F8 : In most Linux distros, F7 is the X server terminal, while in FreeBSD it is generally F8


• F10 : In openSUSE anyway, the F10 terminal is where console messages get dumped after boot up, much like F1 is used in FreeBSD. Not sure if this is true in other Linux distros, but I imagine it is.

So if you hit Ctrl-Alt-F2 (all at the same time), you will be brought to a text mode login screen. From here you can login and do what you want. I usually have a root login on my F2 terminal, just to make admin easy.

You can even set up another X server on other virtual terminals. This means you can do cool stuff like run both GNOME and KDE at the same time. This command will fire up a GNOME session and associate it with the Ctrl-Alt-F8 terminal:

# startx gnome -- :3

Now, for me, Ctrl-Alt-F7 brings me to my KDE desktop, while Ctrl-Alt-F8 brings me to my GNOME desktop. Of course, I need lots more RAM to actually do this. 1gb just isn't going to hack it!

Another thing to note is that from a text mode terminal, you only have to use the Alt-Fkey shortcut. Ctrl-Alt-Fkey works too, so I just use that. And most installations don't have terminals on F9-F12, although you can turn them on. In FreeBSD, check the /etc/ttys file, and in Linux check the /etc/inittab file.

Out Damned Spot!

Want a quick way to kill a frozen process? If it has a window, you can use the KDE shortcut of ctrl-alt-esc. This turns the mouse cursor into a skull and crossbones (argh!) and the controlling application of the next window you click on will be sent a 'kill -9'. It's a very abrupt but final death. Another related KDE shortcut is "ctrl-esc", which brings up Ksysguard, its Task Manager.

See this page for some more info:

Dealing with Runaway Processes - Yet Another Linux Blog

More Linux Words

One thing I have really come to appreciate Linux for - the wealth of information sources out there, both printed and on the web. I'm a real glutton for information, especially printed information, even in today's web-based world, as my groaning bookshelves can attest. And this even after throwing away 3 boxes of books during the great office move! And moving to Linux has opened up a whole brave new world of hernia-inducing books and magazines.

As I mentioned before, I've been checking out the plethora of Linux magazines. My most recent purchase was Linux Format, a UK import. Wow, what a great magazine! Jam packed with excellent articles,including short blurbs, solid reviews, in-depth explorations of things like source code control software, and tutorials for both the beginner and expert. The layout is splashy without being annoying, the editing is tight, with no annoying typos or other graphical glitches (hello, Linux+, are you listening?). The included DVD is a triple boot DVD, with openSUSE 10.2, Mandriva One Metisse and GNewSense 1.0, plus a bunch of eBoooks and 500 HTML pages of documentation. I am tempted to subscribe, but US$180 for 13 issues is a little steep, especially as I feel most of the cost is for two things I won't get full use out of - the tran-Atlantic postage and the DVD. I'm just not sure I need a DVD, as any distro I'm interested in I would just download and any packages I want to use I would prefer to get from an "official" openSUSE source. But I am sorely tempted.

They also have a couple of book reviews, including one for a recent purchase that has really wowed me. They give Linux Administration Handbook, 2nd Edition a 9 out 10, but personally I would go to 11 for it. Every page is densely packed with information and new stuff shows up so often I had to run out and pick up a three pack of highlight markers with page Post-its just to save the information for later! Really clever writing and solid information - a winning combination. Glad I scarfed this up at 50% off. Run, don't walk, to pick this book up.

Linux Administration Handbook, Second Edition, reflects the current versions
of these leading distributions:

• Red Hat Enterprise Linux


• Fedora Core


• SUSE Linux Enterprise


• Debian GNU/Linux


• Ubuntu Linux

SMART Installing

I have decided to give SMART a chance on my openSUSE machine. YaST has been working fine, it is just remarkably slow when it first starts up. It has to load all the dependencies, foreign package source info files, etc, and can take three or four minutes to start up. I suppose I should follow my usual maxim and not try to fix something that isn't broken, because beside the slow start up time, I haven't been able to break YaST, and I'm usually pretty good at breaking application installers. So to complain about a 3 minute startup delay seems to be looking a gift horse in the mouth.

So that makes three package managers available with openSUSE - YaST is the standard one, ZMD is the new "corporate" one and SMART is the third party "better faster smaller" one. Zmd is the ZENworks Management Daemon, introduced as the default installer in 10.1, much to the chagrin of many. It remained the default in 10.2 but it seems in the latest news for 10.3, ZMD will be dropped in favor of getting YaST working better.

At its core, openSUSE uses RPMs as its packages, and these other things are just nice front ends to the remarkably complex flexible RPM command:

$ rpm --help
Usage: rpm [OPTION...]

Query options (with -q or --query):
-c, --configfiles                list all configuration files
-d, --docfiles                   list all documentation files
--dump                           dump basic file information
-l, --list                       list files in package
-P, --patches                    list patches or patched files
--queryformat=QUERYFORMAT        use the following query format
-s, --state                      display the states of the listed files
-a, --all                        query/verify all packages
-f, --file                       query/verify package(s) owning file
-g, --group                      query/verify package(s) in group
-p, --package                    query/verify a package file
-W, --ftswalk                    query/verify package(s) from TOP file tree
walk
--pkgid                          query/verify package(s) with package
identifier
--hdrid                          query/verify package(s) with header
identifier
--fileid                         query/verify package(s) with file identifier
--specfile                       query a spec file
--triggeredby                    query the package(s) triggered by the
package
--whatrequires                   query/verify the package(s) which require a
dependency
--whatprovides                   query/verify the package(s) which provide a
dependency
--nomanifest                     do not process non-package files as
manifests

Verify options (with -V or --verify):
--nomd5                          don't verify MD5 digest of files
--nofiles                        don't verify files in package
--nodeps                         don't verify package dependencies
--noscript                       don't execute verify script(s)
-a, --all                        query/verify all packages
-f, --file                       query/verify package(s) owning file
-g, --group                      query/verify package(s) in group
-p, --package                    query/verify a package file
-W, --ftswalk                    query/verify package(s) from TOP file tree
walk
--pkgid                          query/verify package(s) with package
identifier
--hdrid                          query/verify package(s) with header
identifier
--fileid                         query/verify package(s) with file identifier
--specfile                       query a spec file
--triggeredby                    query the package(s) triggered by the
package
--whatrequires                   query/verify the package(s) which require a
dependency
--whatprovides                   query/verify the package(s) which provide a
dependency
--nomanifest                     do not process non-package files as
manifests

File tree walk options (with --ftswalk):
--comfollow                      FTS_COMFOLLOW: follow command line symlinks
--logical                        FTS_LOGICAL: logical walk
--nochdir                        FTS_NOCHDIR: don't change directories
--nostat                         FTS_NOSTAT: don't get stat info
--physical                       FTS_PHYSICAL: physical walk
--seedot                         FTS_SEEDOT: return dot and dot-dot
--xdev                           FTS_XDEV: don't cross devices
--whiteout                       FTS_WHITEOUT: return whiteout information

Signature options:
--addsign                        sign package(s) (identical to --resign)
-K, --checksig                   verify package signature(s)
--delsign                        delete package signatures
--import                         import an armored public key
--resign                         sign package(s) (identical to --addsign)
--nodigest                       don't verify package digest(s)
--nosignature                    don't verify package signature(s)

Database options:
--initdb                         initialize database
--rebuilddb                      rebuild database inverted lists from
installed package headers

Install/Upgrade/Erase options:
--aid                            add suggested packages to transaction
--allfiles                       install all files, even configurations
which might otherwise be skipped
--allmatches                     remove all packages which match <package>
(normally an error is generated if
<package> specified multiple packages)
--badreloc                       relocate files in non-relocatable package
-e, --erase=<package>+           erase (uninstall) package
--excludedocs                    do not install documentation
--excludepath=<path>             skip files with leading component <path>
--fileconflicts                  detect file conflicts between packages
--force                          short hand for --replacepkgs --replacefiles
-F, --freshen=<packagefile>+     upgrade package(s) if already installed
-h, --hash                       print hash marks as package installs (good
with -v)
--ignorearch                     don't verify package architecture
--ignoreos                       don't verify package operating system
--ignoresize                     don't check disk space before installing
-i, --install                    install package(s)
--justdb                         update the database, but do not modify the
filesystem
--nodeps                         do not verify package dependencies
--nomd5                          don't verify MD5 digest of files
--nocontexts                     don't install file security contexts
--noorder                        do not reorder package installation to
satisfy dependencies
--nosuggest                      do not suggest missing dependency
resolution(s)
--noscripts                      do not execute package scriptlet(s)
--notriggers                     do not execute any scriptlet(s) triggered
by this package
--oldpackage                     upgrade to an old version of the package
(--force on upgrades does this
automatically)
--percent                        print percentages as package installs
--prefix=<dir>                   relocate the package to <dir>, if
relocatable
--relocate=<old>=<new>           relocate files from path <old> to <new>
--repackage                      save erased package files by repackaging
--replacefiles                   ignore file conflicts between packages
--replacepkgs                    reinstall if the package is already present
--test                           don't install, but tell if it would work or
not
-U, --upgrade=<packagefile>+     upgrade package(s)

Common options for all rpm modes and executables:
-D, --define='MACRO EXPR'        define MACRO with value EXPR
-E, --eval='EXPR'                print macro expansion of EXPR
--macros=<FILE:...>              read <FILE:...> instead of default file(s)
--nodigest                       don't verify package digest(s)
--nosignature                    don't verify package signature(s)
--rcfile=<FILE:...>              read <FILE:...> instead of default file(s)
-r, --root=ROOT                  use ROOT as top level directory (default:
"/")
--querytags                      display known query tags
--showrc                         display final rpmrc and macro configuration
--quiet                          provide less detailed output
-v, --verbose                    provide more detailed output
--version                        print the version of rpm being used

Options implemented via popt alias/exec:
--scripts                        list install/erase scriptlets from
package(s)
--setperms                       set permissions of files in a package
--setugids                       set user/group ownership of files in a
package
--conflicts                      list capabilities this package conflicts
with
--obsoletes                      list other packages removed by installing
this package
--provides                       list capabilities that this package provides
--requires                       list capabilities required by package(s)
--suggests                       list capabilities this package suggests
--recommends                     list capabilities this package recommends
--enhances                       list capabilities this package enhances
--supplements                    list capabilities this package supplements
--basedon                        list packages this patch-rpm is based on
--info                           list descriptive information from package(s)
--changelog                      list change logs for this package
--xml                            list metadata in xml
--triggers                       list trigger scriptlets from package(s)
--last                           list package(s) by install time, most
recent first
--filesbypkg                     list all files from each package
--fileclass                      list file names with classes
--filecolor                      list file names with colors
--filecontext                    list file names with security context from
header
--fscontext                      list file names with security context from
file system
--recontext                      list file names with security context from
policy RE
--fileprovide                    list file names with provides
--filerequire                    list file names with requires
--fileclass                      list file names with classes
--filecolor                      list file names with colors
--buildpolicy=<policy>           set buildroot <policy> (e.g. compress man
pages)
--with=<option>                  enable configure <option> for build
--without=<option>               disable configure <option> for build

Help options:
-?, --help                       Show this help message
--usage                          Display brief usage message

SMART promises better package management, always a real trial for every distribution. It gets high marks from many openSUSErs, and I figure I'll give it a go to see what happens.

I actually installed my first non-YaST package the other day. You have to be careful when installing new software, especially using the standard ./configure && make install method, as this circumvents the rpm package stuff and makes the package database obsolete. So you should always use an rpm to install stuff. According to this page, you don't need to necessarily use a "SUSE rpm", that any rpm should work. But you can also use checkinstall to do your work and create an rpm for you. You just replace the make install step with checkinstall, and it creates an rpm for you. From there, you can just do an rpm -i to install it. I did this with Crypto++ library and it worked like a charm.

$ cd cryptopp
$ ./configure
$ su -c checkinstall
checkinstall 1.6.0, Copyright 2002 Felipe Eduardo Sanchez Diaz Duran
This software is released under the GNU GPL.



**************************************
**** RPM package creation selected ***
**************************************

This package will be built according to these values:

1 -  Summary: [ libcryptopp, v5.5 ]
2 -  Name:    [ cryptopp ]
3 -  Version: [ 20070510 ]
4 -  Release: [ 1 ]
5 -  License: [ GPL ]
6 -  Group:   [ Applications/System ]
7 -  Architecture: [ i386 ]
8 -  Source location: [ cryptopp ]
9 -  Alternate source location: [  ]
10 - Requires: [  ]
11 - Provides: [ cryptopp ]

Enter a number to change any of them or press ENTER to continue: 4
Enter new release number:
>> 5.5

This package will be built according to these values:

1 -  Summary: [ libcryptopp, v5.5 ]
2 -  Name:    [ cryptopp ]
3 -  Version: [ 20070510 ]
4 -  Release: [ 5.5 ]
5 -  License: [ GPL ]
6 -  Group:   [ Applications/System ]
7 -  Architecture: [ i386 ]
8 -  Source location: [ cryptopp ]
9 -  Alternate source location: [  ]
10 - Requires: [  ]
11 - Provides: [ cryptopp ]

Enter a number to change any of them or press ENTER to continue:

Installing with make install...

========================= Installation results ===========================
mkdir -p /usr/include/crypto /usr/lib /usr/bin
cp *.h /usr/include/crypto
cp *.a /usr/lib
cp *.exe /usr/bin

======================== Installation successful ==========================

Copying documentation directory...
./
./Readme.txt

Copying files to the temporary directory...OK

Compressing man pages...OK

Building file list...OK

Building RPM package...OK

NOTE: The package will not be installed

Erasing temporary files...OK

Writing backup package...OK

Deleting temp dir...OK


**********************************************************************

Done. The new package has been saved to

/usr/src/packages/RPMS/i386/cryptopp-20070510-5.5.i386.rpm
You can install it in your system anytime using:

rpm -i cryptopp-20070510-5.5.i386.rpm

**********************************************************************

Keeping the Agent Around

I answered an interesting question on the Suse Forums today, and I thought I would log my answer here too. Teresa wanted to know how to have ssh-agent remember her passkey across multiple shell logins and the like. I answered the question here for how to do it when you are using X, but she was doing everything from the console and so didn't have the luxury of an overarching environment.

When you run 'ssh-agent', it starts up a process that listens on a local socket, and prints out some info you can use to set environment variables with, which then tell other programs where to ask it for info:

$ ssh-agent -s
SSH_AUTH_SOCK=/tmp/ssh-CzngL4914/agent.4914; export SSH_AUTH_SOCK;
SSH_AGENT_PID=4915; export SSH_AGENT_PID;
echo Agent pid 4915;

So normally you "eval" the results of this to actually create the environment variables, so you put something like this in your .bashrc:

eval `ssh-agent -s`

But if instead you dump that to a file, you can now use this in any other virtual terminal, say, or another screen session, rather than killing the old one, starting up a new ssh-agent, and adding the key again.

$ ssh-agent -s > sshx
$ cat sshx
SSH_AUTH_SOCK=/tmp/ssh-CzngL4914/agent.4914; export SSH_AUTH_SOCK;
SSH_AGENT_PID=4915; export SSH_AGENT_PID;
echo Agent pid 4915;
$ eval `cat sshx`
Agent pid 4915
$ printenv |grep SSH_
SSH_AUTH_SOCK=/tmp/ssh-CzngL4914/agent.4914
SSH_AGENT_PID=4915

Now any keys you ssh-add to this ssh-agent will be effective in any other shell. It doesn't look like you need to use the nohup command with ssh-agent, as it automagically works as a daemon already, so as long as you use the correct environment variables, you should be communicated with that one no matter what.

Java Is Evil

Yeah, this is more or less how I feel about Java:

Classics Week: The Call of Codethulhu - Worse Than Failure

Tab-way to Heaven

Yay! I finally solved the biggest small annoyance I currently had on my new openSUSE box. I'm using KDE, with dual monitors and two desktops, and Alt-Tab wasn't showing apps currently running on the "other" monitor. It was very weird. I did enable the setting to go through all the desktops, which is hard enough to find. KDE Control Center -> Desktop -> Window Behavior, and select the "Traverse windows on all desktops" option, which is the only right solution, as that is the easiest way to go from desktop to desktop. I'm not a huge fan of multiple desktops, but they work much better on KDE than they do using any of the various hacks to enable them on Windows.

But, oddly enough, ever since I began running openSUSE, Alt-Tab would only show me windows that were displayed on the current *monitor*. It would correctly show me ones on both desktops, but not both monitors, which drove me crazy. I asked a few different places for a solution, to no avail. But my latest plea on the opensuse-kde mailing list got me an answer!

It seems the latest version of KDE added a few Xinerama "improvements", as listed here. One of these "improvements" is that the Alt-tab list of windows can be restricted to a single screen (monitor), as someone even claimed that having alt-tab show all the windows was a bug, which is insane. And just about as crazy is that this new option was made the default! I could see that some deranged individuals might actually desire having alt-tab only show windows on the current monitor, but to make that the new default option is a mistake.

And, even better, another response showed me a quickie way to set this new, undocumented, no-UI option:

$ kwriteconfig --file kwinrc --group Windows --key SeparateScreenFocus --type bool true
$ dcop kwin default reconfigure

kwriteconfig is one of those well-nigh undocumented KDE helper apps, which abound, and include the vitally important dcop, which is a way of sending commands from the commandline to windows. So this makes the SeparateScreenFocus option true and tells KDE to re-read its configuration data. You can also edit ~/.kde/share/config/kwinrc by hand, setting the value to what you want:

• true: show windows on all screens in alt+tab


• false: only show windows on current screen in alt+tab

1

Loopy on CDs

Have an .iso file and want to see what it looks like before you burn it to a DVD or CD? Simple - use mount's "-o loop" option:

$ mkdir myiso
$ sudo mount -o loop gparted-livecd-0.3.4-6.iso myiso
$ cd myiso
$ ls -F
boot/  gparted.dat*  syslinux/
$ cd ..
$ umount myiso

Now that is pretty cool! Most Linux distributions are delivered on .iso files, which are snapshots of complete CDs (or, increasingly these days, DVDs). Using software like cdrecord or k3b, you can burn the ISO to a CD. Remember - don't copy it to the CD, but rather use the option to burn the ISO as a CD. In k3b, you use the Tools->Burn CD Image... or Burn DVD ISO Image... menu selections. You can't modify anything, as it is mounted read-only, but there are ways to modify an ISO file. See this Ultimate Boot CD page for some ways to do it.