The Linux Bloke

Our Universe is full of ironies. But some ironies are just too hard to take.

As you may have guessed (!!!), I am an avid Linux developer and user. Though once upon a time I did develop under Windows. Yes, believe it. And on one particular case, I got to be on a first-name basis with some of the Microsoft Software Engineers to resolve issues we were having with their OLE crap — what the Holy Gods of Microsoft decided to redub as “Active-X”.

But I digress. For the past 10 years, I have been solid Linux and have defenestrated Windows for the most part. But as you know, you can never really completely eliminate Windows.  Despite your best efforts, it will always be (for now, at least) the 500 pound gorilla in any room you care to be in. The installed software base there is just staggering, and most have no Linux options.

But then that’s why projects like Wine and the many wonderful hypervisors were created. It turns out we can just about have our cookie and eat it too — almost. There are many games written for Windows that won’t do on anything but native Windows with the latest nVidia graphics card and a 7.1 surround sound system!

I’ve been working with financial software as of late, as well as some old favorite games of mine like Diablo II. My main workstation is an Intel Quad core — pretty standard these days. But my particular system is already “obsolete” as it can only handle a max of 4GB or ram — barely enough when you are running virtual machines. I do plan to upgrade my motherboard to the latest and greatest soon, and slap 16GB of ram on there — and maybe AMD’s new 6- and 8-core CPUs coming soon to a geek dealer near you.

Yes, I love Diablo II. And it works almost flawlessly under Wine on my Ubuntu setup. Some quirks that you will only notice if you have multiple monitors like I do, but I can live with that. It runs fast and furious.

But due to my machines RAM limitations, the financial software I run sometimes wants more RAM than I can devote to it via the virtual machine, so I’ve had to install Windows natively in a multi-boot setup.

Well, getting that done is a story in and of itself. For some unknown reason, Windows 7 (and Windows Vista back when I tried it) runs unbearably slow on my particular hardware, and the installation of Windows 7 took over 24 hours!!!! And it still doesn’t work!

But installing Windows 7 on a virtual machine, such as the Sun VirtualBox, running on Linux, went without a hitch, and took less than half an hour!!! Same hardware. And runs fine!!!!

But I did managed to get Windows XP x64 installed on my machine natively. It, at least, can make use of the quad-core chip and use all of the 4GB of RAM on my system. SP2 is essential with XP 64, as my sound card would not work at all with SP1.

And so I can run my financial software under Windows either natively or in a virtual machine. And Diablo II.

But to my great surprise, both performs BETTER under Linux than Windows!!! Let me explain.

The financial software I am using is eSignal. I have written a number of EFS scripts for it — and their EFS language is simply JavaScript, which is nice — and so does a lot of heavy-duty realtime calculations on the incoming market data stream. I need SPEED, and one would expect better performance if it’s running on a native OS than one running on a virtual machine, right?

Nope!!!! It actually runs better on the virtual machine! I have XP 64 with Service Pack 2 — same image — running in both modes, and it’s simply a bit more responsive overall on Linux!!!

I am totally puzzled by this, but wait! There’s more!

Recall Diablo II? I figured it would run a bit better under native Windows than it does on Wine under Linux. It would be in its happy environment, and so the few annoying quirks I see under Wine would disappear, right?

Well, the quirks disappeared, as expected. It dosen’t go nuts when my mouse happens to move over to the other monitor (it locks the mouse cursor to its screen as it should), and some of the hot-keys issues goes away.

But, it drags. Yep. On native XP 64, Diablo II is very sluggish, and can’t even do some of the video options that it has no problems with under Wine! Is that insane or what?

In fact, Windows XP 64 itself running natively seems to steadily reduce in performance if it’s been running for a while, and the audio gets really funky. Rebooting is essential.  This is less of a problem running on a hypervisor. Why is unknown.

I have tried to research some of these issues with Windows’ lack of performance on Google, but all I find are others also having the same problems but no clue as to why.

I even tried calling Microsoft MSDN Support about this, but they were less than helpful. They kept harping that I should disable or disconnect any device attached to my system that Windows isn’t using.

If I have to do that, I may as well build a new PC and only install Windows on it. But since I primarily develop under Linux, that would be less than ideal for me.

And just what’s the deal with having to disconnect devices that Windows isn’t using? Why would leaving them connected kill performance to unbearable levels? Linux doesn’t have a problem with this at all. It just ignores unknown devices! Well, duh. This is primarily a problem with Windows Vista and Windows 7. Windows XP does the right thing — ignores what it doesn’t understand as well.

And I utterly and flatly refuse to open up my chassis and yank the cables on half the hard drives just to be able to boot and use Windows 7.

You know, the differences between Linux and Windows is like the differences between Atheists and Bible Thumpers. The first (including Yours Truly) are basically very open and tolerant of other beliefs, and typically don’t go about slamming others for having a difference of opinion. The latter is rather hostile to other beliefs, really hostile to the former, and typically spew forth the “my way or Hell” attitudes.

And so you have:

Open Source :: Closed Source

Open Minded :: Closed Minded

Atheists :: Bible Thumpers

Linux :: Windows

There are other parallels too, but I’ll leave that as a fun exercise for you! Feel free, of course, to post them here!

If you are a GUI-oriented person, you need not read this. But if you are like me, you make heavy use of the console. If you are managing many machines as well as your own Linux workstation, it’s VERY important to know where your console session is.

Too many times in the past I had wanted to bring down my workstation, and would type “shutdown” or “reboot” in the console window, only to find out to my horrors that the console was really a remote session to one of my web servers serving up hundreds of web sites.

Whoops!

Well, that prompted me into developing a solution where I can tell at a glance where I happened to be logged in. This way,  I wouldn’t be in danger of issuing dangerous commands on the wrong server. And if you are working for someone else, it also keeps you from being FIRED!

I use KDE to do my development and administration, and I have fallen in love with Konsole. Konsole, despite its quirks, has a lot of nice features that makes it a shoe-in for what I am talking about.

My approach now is to create login bash scripts to begin a session with whatever machine I need to ssh into, and have that script also do something nice to the Konsole background in the process.

I also develop a lot of websites, as well as other things. Sometimes, it’s helpful to change the background when I go into emacs so that I have the proper contrast for syntax coloring, etc. Same approach works there as well.

The secret to my machinations? A little script I wrote called kschemaset. It does all the “magic” in  resetting the Konsole background, and is actually derived from a similar script that didn’t do everything I needed. But in the fine tradition of opensource, I grabbed it and enhanced it over time. It currently does require you to either create images or acquire images for your backgrounds, but eventually I wish  to create a more comprehensive opensource package that will do all that magic for you automatically. But for now, it’s a lot of fun to come up with a cute background that represents the server you are working on! I recommend choosing either very light pastel colors or very dark colors with low contrast, because you want to be able to read the text without killing your eyes.

You don’t have to create any artwork at all, actually, and many may elect to do it that way. It’s all up to how you want to proceed.

The first step is to install the kschemaset script somewhere where it can execute. There are actually other related scripts involved, and they are all available from here. Typically, I create a local bin directory to my login account and alter the .bashrc file to add it to the PATH environment variable. Since you are obviously well adept at such things if you are interested, I won’t bother with holding your hand here.

The next step involved is to create Konsole schemes to reflect the servers you wish to work on. All kschemaset does is invoke a schema for the duration of the session, and restore the old schema when the session is concluded. Eventually, not only do I want to automate the creation of new Konsole schemas, but also the images used for the backgrounds. But for now you can do this by hand — or automate these steps yourself. If you do, let me know so I don’t wind up reinventing your wheel!

Konsole has one annoying problem that seems not to have been fixed in recent times — when you add a new schema, any Konsoles that were open prior to the addition tend to get “confused” and may start displaying the wrong schema. The workaroud for this is to either to manually select the schema for those Konsoles out of sync, or to restart them. Hopefully this problem will be fixed soon.

Now, you simply create scripts based on kschemaset that will launch your new sessions, and change not only the background, but the tab text as well, on the fly, and to reset everything to the pre-existing schema and tab text when you’re done. I’ve even did this with emacs to give me a flat-black background to do my editing on.  The possibilities are endless.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37

#!/bin/bash
# Set the schema of the currently-running Konsole
# Based on konsoledcopschema
 
 
# So running script can know this is where it's running
# (to enable scripts to enable kschemaset via recursion)
export kschemaset=1
 
. kconfuns
getKonsoleInfo
getAppInfo ${*}
shift
 
if [[ ! ${appSchema} ]] ; then
    echo "(schema $appName not found)"
fi
 
export -f ksetSchema getKonsoleInfo getAppInfo
 
if [ "${inKonsole}" == "1" ] && [[ ${appSchema} ]] ; then
    # dcop $konsole konsole reparseConfiguration
    dcop $konsole $session setSchema "${appSchema}"
    dcop $konsole $session setSchema "${appSchema}" # testing -- may not have gone through the first time
    if [ -n "${appName}" ] ; then
        dcop $konsole $session renameSession "${origSession}: ${appName}"
    fi
 
    if [ -n "${*}" ] ; then # run the command and reset to prveious schema.
        ${*}
        dcop $konsole $session setSchema "${origSchema}"
        dcop $konsole $session renameSession "${origSession}"
    fi
else
    kschemaset=2
    ${*}
fi

And now for the next script:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34

#!/bin/bash
# Konsole functions. Include with ". kconfuns"
 
kloc=~/.kde/share/apps/konsole/
 
getKonsoleInfo()
{
    # Make sure we're in Konsole
    if [ -n "${KONSOLE_DCOP}" ] ; then
        export inKonsole='1'
        export konsole=`echo $KONSOLE_DCOP | cut -d\( -f 2 | cut -d, -f1`
        export session=`dcop $konsole konsole currentSession`
        export origSchema=`dcop $konsole $session schema`
        export origSession=`dcop $konsole $session sessionName`
    else
        export inKonsole='0'
    fi
}
 
getAppInfo()
{
    export appName="${1}"
    export appSchema=`ls -1 $kloc | egrep "${appName}\."`
}
 
ksetSchema()
{
    dcop $konsole $session setSchema $1.schema
}
 
ksetSessionName()
{
    dcop $konsole $session renameSession "$*"
}

And here is an example of lauching an ssh session using kschemaset:

1
2
3

#!/bin/bash
# Log on to the Polaris Web Server
kschemaset Polaris  ssh -t youraccount@yourserver.yourdomain.com $*

And it’s that simple!