Motivation

I want to connect to my work computer from home, to the primary X session and continue working remotely.

Problem description

My work computer is the vnc server. My home computer (the client) is to use a vnc viewer such as krdc (KDE Remote Desktop Connection) to allow me to control the remote machine. An added layer of complexity arises from the firewall that I need to tunnel through to reach my machine at work.

Solution

Server side, I’ll use x11vnc to accomplish this. This is because x11vnc allows me to connect to the primary X session – I need this since I might already have applications running at work and would like to continue where I left off. If this is not a concern, you can use tightvnc or other vnc servers, but you will need to start a separate X session to connect to.

As an aside, vnc is a better solution than using ssh with X11 forwarding. This has to do with the dreaded dropped connection problem. If the connection is dropped when you’re working on an application forwarded through ssh, it is terminated. It may or may not cleanly exit, leading to potential issues with data loss/corruption. This really depends on the application in question. However, if you use vnc, if the connection is dropped, you just get disconnected. The application is still running remotely. All you need to do is reconnect. Besides, if the application is already running on the remote machine, ssh forwarding doesn’t really help.

Prerequisites

An ssh server running on the server is highly recommended so you can tunnel all communication to and from the vnc server securely. This, however is optional, strictly speaking.

Procedure

1) Install the x11vnc package on the server. The following command will install x11vnc on arch systems.

# pacman -S x11vnc

2) Set up a vnc password for authentication. This step is optional, but recommended as without a password, anyone can connect to the vnc server. The following command will store a vnc password in ~/.vnc/passwd.

# x11vnc -storepasswd

3) Open the first of two tunnels. The first tunnel is for ssh. The following command will open a tunnel from local port 2222 (or any other port of your choice) to remote port 22.

$ ssh -fNL 2222:<remote server>:22 <user>@<gateway>

4) Now, in a terminal, ssh into the remote server and start the x11vnc server. The -create flag will scan for X sessions you’re logged into and connect to it. If you aren’t logged in or if someone else is logged in at the remote machine, it’ll create a new session for you. This new session cannot be viewed by someone at the remote server console. The -usepw flag tells the server to use an authentication password. The first place this looks for the password is in ~/.vnc/passwd. The -noxdamage flag is a performance option that worked well for me. Note the port number x11vnc is listening on. Usually, this will be 5900.

$ ssh -p 2222 localhost

<remote>$ x11vnc -create -usepw -noxdamage

5) Now, open the second tunnel for your vnc client to connect to the x11vnc server at the port it’s listening on. In this case, I’ve assumed it’s 5900. The following command will open a tunnel from local port 5959 (or any other port of your choice) to remote port 5900.

$ ssh -fNL 5959:<remote server>:5900 <user>@<gateway>

6) Now, you’re ready to point your vnc viewer to localhost:5959 and commence your vnc session. Terminate the x11vnc server on the remote machine when done. If you log out, the server will automatically terminate.

Problems

If you connect to an already running X session, it remains visible remotely. Other than leaving your screen turned off, I haven’t come up with a better solution. However, if the remote machine is either at the login screen or if someone else is logged in, the new session is invisible to the remote user.

Performance is wickedly slow when compared to protocols like rdp (remote desktop from Windows). This seems to be the best vnc is capable of. I’ve heard good things about FreeNX and will play with it when I get the time. If you have any suggestions about improving the performance of vnc, do let me know in the comments!

EDIT: Clarifications, reordering of steps to be more logical.

Motivation

I have two computers at home side by side and would like to share a keyboard and a mouse between them. As an added bonus, my solution will also allow me to share the clipboard between the two computers – I can copy some text from some program on one computer and paste it into another program on another computer!

Problem description

The server computer has a physical keyboard and mouse. It is located to the right of the client computer. The server’s keyboard and mouse needs to be used on the client.

Solution

The package I’ll use is called synergy. Since synergy sends unencrypted information back and forth, I’ll need to route it through an ssh tunnel so that no one can snoop on my key strokes and clipboard contents.

Prerequisites

An ssh server running on the host is needed to secure communication between the server and the client. While this is optional, it’s strongly recommended.

Procedure

1) Install synergy on both computers. Arch linux has synergy in its ‘extra’ repository.

# pacman -S synergy

2) Edit the /etc/synergy.conf file on both machines. This file specifies the physical layout of the screens to synergy. This way, The mouse will smoothly transition from one computer to another when it encounters the correct screen edge.

The contents of synergy.conf should look like this on both machines: (Replace ’server’ and ‘client’ by the correct IP addresses/hostnames)

section: screens
    server:
    client:
end
section: links
    server:
        left = client
    client:
        right = server
end
section: aliases
end

These files can also be saved in one’s home directory as ~/.synergy.conf

2) On the server, start the synergy server.

$ synergys

3) On the client, open an ssh tunnel to the server. Note that this is an optional, but strongly recommended step.

$ ssh -fNL 24800:server:24800 user@server

4) On the client again, start the synergy client. (If there’s no ssh tunnel, replace localhost by the server in the following command)

$ synergyc localhost

5) Now, I have a working setup with two computers sharing the same mouse and keyboard! The keyboard strokes are sent to the computer whose screen the mouse cursor is on.

Problems

If you designated KWin effects to corners of your screen, they will not work on the shared edge/corners. You may need to remap them to other screen edges and corners.

I’ve also seen that the mouse will sometimes appear on the client screen in the middle rather than the right edge when moving from the server. It’s a minor problem and doesn’t affect the experience much.

This is Part II of a series on Arch Linux

First and foremost, if you have any data that you’ll regret losing, back it up. No, seriously!

This is not a step by step installation guide. It’s a bunch of notes regarding things to expect during the installation. Refer to the Beginner’s Guide for a more complete walkthrough of the installation process.

Backup!

This bears repeating. Back up all data on an external hard disk before you consider installing Arch. I’d suggest spending one week just making sure that everything you could possibly need is safely backed up. It’s better to be safe than sorry.

Download

Download the latest ISO from here. Consider using the torrent. It really doesn’t take much longer than a regular download. There is a choice between a ‘core’ ISO and an ‘ftp’ ISO. Choosing the core option gives you a bigger ISO with many of the core system packages already on the CD. This means no waiting time for downloading during the install. However, the packages are likely to be out-of-date. The ftp option gives you a smaller ISO and downloads the latest version of the core packages from an online repository. This is usually the better option. You also have a choice between a 32 bit and a 64 bit ISO. If you don’t know which one you want, go with the 32 bit option.

Read up

The Beginner’s Guide is a wealth of information that concerns the set up. Regardless of your experience with linux hitherto, consider reading it at least a couple of times before you install. It’s also available as a text file on the installer CD.

If you can, also read up on what module/firmware packages you’ll need to install for your wireless card, if you have one. It’ll help to know this when confirming the set of packages to install during the set up.

Network

You’ll need to be online to download packages from the arch repositories. If it’s a wired connection, there’s little you need to do to get the machine online. In fact, getting online is actually one of the first steps in the installer. If you have a wireless connection, consider downgrading the security on the network to WEP temporarily during the install. This vastly simplifies the process.

Regardless, here’s a quick setup to setting up a network:

$ ifconfig -a


If the prompt is shown as $, the command does not need root access. A # prompt indicates that you need to be root to run this command. During the setup, you ARE root; but this notation will come in handy for use later.

This will list all devices onboard the computer that can connect to a network. Note the <interface> for your wired/wireless card. Should you need to tell a wireless interface from a wired one, use the following command

# iwlist scan

This will list out a quick scan of all the wireless networks in the area. It will also list out the interfaces that support scanning (i.e., the wireless interfaces).

Now, bring up the interface with,

# ifconfig <interface> up

The next step only applies to wireless interfaces. Skip this if your connection is wired. This step will associate the interface with a wireless network using WEP. As I suggested before, consider downgrading the security on your network to WEP (if you’re using WPA/WPA2) at least temporarily.

$ iwconfig <interface> essid <essid> key <key>

The <essid> can be within quotes if you have spaces in your network name.

Now, the final step is common to both wired and wireless devices. This uses the dhcp cliend daemon to obtain an IP address for your computer.

# dhcpcd <interface>

Finally, you can test your connection by pinging a network address

$ ping google.com

You should see ping times being shown. Ctrl+C to stop the pinging.

Other commands that will come in handy are:

# dhcpcd -x <interface>

to stop the DHCP client daemon, and

# ifconfig <interface> down

to bring the interface down.

If you need to troubleshoot, use the beginner’s guide suggestions.

Partitions

This is a very important step during your install. If you have multiple hard disks, make sure you know which hard disk you’re about to wipe clean. Use the cfdisk utility to create the partitions. Don’t sweat about formatting them. The installer will take care of formatting them during the setup.  The following commands will come in handy while working with hard disks and partitions.

$ cat /etc/partitions

will list all the partitions you have.

$ ls -lF /dev/disk/by-uuid

will list the UUID’s of the partitions

# mkfs.ext4 /dev/sda1

will format the sda1 partition using the ext4 file system.

Consider creating at least the following partitions:

1. boot (about 128 MB is more than enough. ext2 is fine for this partition)
2. root (a 10 GB, ext4 partition is a good start)
3. swap (used for hibernating the machine. 10% more than the size of your RAM is good enough)
4. home (leave the rest of the hard disk to this partition. ext4 is a good choice)

Packages

As long as you install the base packages, you can always install any other packages you may need later. Don’t sweat it too much during the setup trying to decide which packages you need. If you have a wireless card, you may need to make sure you get the appropriate package for the module at this point. My Intel Pro Wireless 2915 card on my laptop needed the ipw2200 package, for example.

System Files

You’ll have a chance to go over key configuration files at the end of the install. You’ll likely find that you have very little you want to change at all at this point. You can always load ‘em up later and edit them to your heart’s content.

Reboot!

If all went well, you should be able to boot into your freshly installed Arch linux system. Your journey is far from over. In fact, it’s just beginning!

# reboot

KDE’s powerhouse torrent application, KTorrent comes with a formidable set of plugins including an IP filter. Here’s how to get it working.

Launch KTorrent. Head to Settings > Configure KTorrent. Look for the Plugins options in the side bar. Under Plugins, select the IPFilterPlugin. A new set of options should appear in the side bar called IP Filter.

You should find the option to Use PeerGuardian filter already selected and a url filled in the IP filter file area. Under that, the status will inform you that it’s not loaded. There’s a Download/Convert button, but that won’t work either, giving you a cryptic error message about no IP’s found in level1.txt.

Here’s what the problem is: the splist.zip file hosted at bluetack.co.uk is no longer hotlinkable. Which means, the url doesn’t work. You need to manually get this file from here and use the file browser to load it. Now, the Download/Convert button should work properly and the status message will inform you that the plugin is Loaded and running. Congratulations, you are in P2P heaven.

You can uncheck the automatic update option since you may delete the splist.zip file from your hard disk. Otherwise, KTorrent will periodically check the location to see if there is an updated list available.

A proper workaround is to find an up to date list of blacklisted IP’s that KTorrent users can happily hotlink to and have it updated automatically. But for now, you’ll need to manually update the splist.zip file from the link above and load it into KTorrent. Does anyone know of a viable option to manually updating the file every few days?

This is Part I of a series on Arch Linux.

Before I begin, a disclaimer. Arch Linux is DEFINITELY not for people new to linux. For them, I’d whole-heartedly suggest using a user-friendly distro like Ubuntu just to get a feel for how things work in linux. Arch Linux is also not for people who don’t have the time or inclination to learn how their computer works. Frequently, you will need to dig into configuration files and sometimes, use trial and error to determine which settings work for you during the set up process.

On the plus side, if you are comfortable with editing config files by hand, if you seek a high degree of control over what your machine does or if you are just too curious to be discouraged at this point, walk right in. You don’t need to be a linux god to enjoy Arch Linux – I’ve never compiled a single package from source and I loved setting up Arch Linux on my laptop.

After reading this blog on FSDaily, I was eager to try out Arch linux. The two biggest things that appealed to me were the idea of a rolling release (I was getting tired of the release update breaking my Kubuntu every six months, effectively forcing me to reinstall everything) and the promise of a “pure” linux experience. On a minor note, I was also impressed by the assertion that Arch linux remained very up to date and was usually one of the first to release an updated version of a package.

A test install on virtualbox at work showed no glaring difficulties in using it as my main system. The live CD also had no issues. So, I decided to go ahead and wipe out Kubuntu Hardy and replace it with Arch Linux at work. I chose the KDE3 environment as KDE4 (at that time, 4.0.5) still had issues.

I was pleasantly surprised by how light and responsive the system was. There were no unnecessary daemons running and the memory usage at bootup was 109 MB. That was impressive by itself.

A week or more later, KDE 4.1.0 was released and Arch, with its customary speed, rolled it out and replaced my KDE3 install. This was probably not a very nice thing for Arch to do, but I had sufficient warning – the package manager told me exactly what it was going to do if I said yes.

KDE 4.1.0, if you haven’t heard already, is quite stable and mature, so I didn’t really mind losing my KDE3 install at the end of the day. If anything, it convinced me that the time was ripe to roll out the install on my home laptop.

My expectations were not so modest for the ‘home’ install. Everyone faults Kubuntu for providing one of the worst KDE experiences in the linux world. So, firstly, I wanted to see what a “pure” install of KDE was really like. Second, I expected the install to run very light on resources and thus, to be quick and responsive. (To be fair, the Kubuntu install really wasn’t all that heavy.) Third, I expected to see fewer bugs because of Kubuntu specific alteration of the KDE packages. Lastly, I wanted to have more control and knowledge of my system. I wanted to know where to fix things if something broke. Essentially, looking to advance my geek cred, I suppose.

The main reason for this series of posts is to archive my experience so that it may come in handy to someone else later on. The second reason is to be able to refer to it myself if I need to perform another install in the future.

Next up, Part II – The Installation

Consider the following user scenarios. All relate to linux users sorely missing some functionality in dealing with PDF files:

User A: I have two or more PDF files and I would like to merge them and make a single PDF file.

User B: I have a large PDF file, but I only want some pages of it. It would be nice if I could cut some pages out of the large PDF file and carry the smaller, more portable PDF file around.

User C: I want to add my notes to a PDF file I have and save it. This could be forms that I want filled, highlighting some text or even, editing text in the PDF file.

User D: I’d like to rearrange the order of the pages in my PDF file.

Chances are that at some point or the other, all of us relate to the above users. While everyone and his uncle talks about creating PDF files natively in linux (most applications can output to a PDF file; those that come without a “Create PDF” option can still use the virtual PDF printer and print out one in a jiffy), no one mentions anything about editing them.

Well, the other day, I stumbled (no, not that Stumbled) along online looking for a way to do it easily in linux. Until then, if I needed to edit a PDF file, I’d have to head over to Windows land where the highly capable and highly expensive (and *cough* highly cracked *cough*) version of Adobe Professional lived. Indeed, it must be telling to some users that Adobe doesn’t make a version of this software for linux…

I first found an article about a command line utility called PDF Toolkit. While it seems highly capable, PDF files are intimidating enough to deal with in a GUI environment without having to deal with them from the command line. I chickened out. Others like flpsed offered only limited functionality in editing PDF files (just annotating them, in case of flpsed).

And so, I came across PDF Editor. With a devilishly inconspicuous name that cunningly conceals what the program does (I know, so devious!), I’ll bet very few linux users who googled for it and found it…Okay, it was just me then who never thought of googling “pdf editor”

Anyway, all kubuntu boys and girls, head over to a konsole and sudo apt-get install pdfedit.

Right. The good points first; it starts snappily and shows up with a simple interface that has plenty of toolbars and tooltips that explain what each button does nicely. For those that prowl ‘teh intertubes’, there’s a detailed user manual, too.

User A would open the first file and head over to Tools > “Insert Pages from other document” and begin splicing together the new and improved pdf file. You can even reorder the order of the pages here. User A: Satisfied.

User B would look at the tree view on the right and select the pages (by number) that they want to remove and right-click > Remove page. User B: Satisfied.

User C would be amazed by the plethora of buttons that allow the user to add text, and highlight or strikethrough existing text. Forms can be filled, the PDF can be saved. Life can be good. User C: Satisfied.

User D would also look at the tree view and select a page (again by number) and right-click > Move Page Up/Down. There’s a dedicated toolbar for this with buttons that move the currently viewed page up or down. User D: Satisfied.

Well, what can I say? My users are an easily satisfied lot.

Now, for the bad stuff; Okay, right off the bat, no undo?! It’s good that no changes are saved until you tell the program explicitly to save the file. It’s also good that there’s a handy menu command to save a copy before you edit the file. But it’s disappointing that there’s no undo command available.

There seems to be no way of editing the metadata of the PDF file. This is the handy bit of info that tags the file with such useful searchable items as Title, Author, Subject, Keywords and any other user-defined items. Desktop searching software is only going to get more popular. Already, Kubuntu tries to force Strigi down our throats (sudo apt-get remove strigi) from Gutsy on. The ability to edit the metadata in PDF files is going to become increasingly important. KDE can be excused for not allowing editing of PDF metadata(for the moment). A PDF Editor cannot.

Since it is possible to combine, sort or trim down the pages in one or more PDF files, a more intuitive user interface would be nice. A story board view (reminiscent of the slide-sorter view in PowerPoint) or just a thumbnail preview of multiple pages would be perfect to add/delete/arrange pages in a PDF.

Finally, while the tree view is a portal into a frightening sense of power and control over the very structure of the PDF file, it’s not very intuitive. It is good that the advanced mode is disabled in the options by default, it would have been nicer still to hide the tree view from the user at first glance.

To conclude, PDF Editor fills a crucial functionality void in Penguin land. It’s learning curve is gradual enough that the average user will not be frustrated. The most current version out in the wild is 0.3.2, while *buntu users will have to be satisfied with 0.3.1. In the coming versions, as PDF Editor becomes more user-friendly and feature rich, it has a real potential to join the ranks of packages like Amarok and K3b to become one of the killer apps in linux.

Also, as further food for thought, it would be nice if this functionality is incorporated into okular in some future release of KDE4. There’s no reason why a good PDF reader cannot have an Editor mode, too.

Update: Okular will NOT have PDF editing capabilities (at least any time soon) as the developers feel it would add unnecessary bloat to the package. Oh well!

The 2004 debut and subsequent rise of Ubuntu’s popularity among the linux users is cause for celebration indeed. Over the last two years, the new distro managed to upstage entrenched (in user base terms) offerings like OpenSuse and Fedora and has provided a rallying point for the cause of adoption of free and open-source software. That over time, there’s been an (alarming?) drift in Ubuntu in terms of complacency towards using closed-source components (such as the Compiz-Fusion powering video card drivers) is a topic for another post.

Still, with all the good news, something is rotten in the state of…Ubuntu. You see, by default, Ubuntu has always shipped with GNOME as the default desktop. Shuttleworth explains that the absence of a regular release schedule on part of KDE made him choose GNOME as the default desktop environment for Ubuntu. Fine. But, the very idea of starting offshoots like Kubuntu and Xubuntu must surely indicate that all these distributions are considered equal? This in short, is the biggest peeve I have with Ubuntu.

The most tangible of this less-than-equal treatment meeted out towards KDE and the “lesser” desktop environments is in the predictable one-release lag before a “cool” new feature made its way down the hierarchy, from the GNOME version to Kubuntu and the even lesser known variant, Xubuntu (and in Edubuntu’s memory, we’ll hold a minute’s silence). That there is a different feature set because of different desktop environments is a given, even welcome state of affairs. But why should there be a noticeable lag in the introduction of features that can clearly be common to all flavors? Like the restricted package manager (debut: GNOME: 7.04, KDE: 7.10?), the windows settings import capability for the ubiquity installer (debut: GNOME: 7.04, KDE: 7.10?) or compiz (debut: GNOME: 7.04, KDE: 7.10?)?

Also, there’s a trend in PC manufacturers to offer Ubuntu preinstalled on their machines. Hailed as the coming of the linux desktop, these trends inevitably looked to Ubuntu for a solid, noob-friendly linux experience. But here’s the catch: Ubuntu here doesn’t refer to Ubuntu, the umbrella under which the GNOME, KDE, XfCE and Edubuntu are covered. It refers to the GNOME version only. Because of this biased marketing, Ubuntu has come to be synonymous with a GNOME desktop. People I meet don’t even know about Kubuntu or Xubuntu (one more minute’s silence in memory of Edubuntu should be in order here, but in the interest of time, we’ll move on) and worse, eye them with a sense of xenophobic dread. As a result, KDE has moved from being the top dog (pre-Ubuntu days, 60% users) to KD-who? (post-Ubuntu, 35% users).

So what can be done to change this? I’m fine with synchroniing the Ubuntu release schedule with GNOME’s. I’m fine with GNOME being the default desktop for Ubuntu. What I’m not fine with is the relegation of KDE to the sidelines. For starters, the websites should be merged. While Ubuntu (meaning the GNOME version) has a spiffying, shiny website, Kubuntu’s website is a front page full of news. That’s what the RSS feed is for! Then, on the unified mainpage, Ubuntu should be mentioned as Ubuntu [ GNOME | KDE | XcFE | Edubuntu ], and each can lead to an appropriately themed ( GNOME being orange/brown etc) website that deals with information about that version. Hell, they can even add a “(default)” next to the GNOME link. But just acknowledging the equal status of the four versions would be nice for starters. They could do a Beatles styled (think, album cover of Let It Be…) entry page. That would totally rock. KDE gets to be Lennon, of course. GNOME can be McCartney. XfCE can be Harrison and Edubuntu is Ringo.

One more (minor) thing, could they (puleeze!) make the grub menu read Kubuntu and not Ubuntu. Or atleast not change the title everytime a new kernel upgrade comes along…or not. I guess it might be a pain to implement since at least the grub menu thinks of all Ubuntu versions as the same thing…

In my earlier post, I provided a quick-n-dirty solution to the problem of devising a superior system of scoring songs played in Amarok. After giving the problem some thought, I have come up with a different approach.

The score of a song represents the computer’s best guess of how much you, the user, likes a certain song. Unlike the rating, the score requires little user input. Of course, if the rating is provided, the computer can predict the score a lot more reliably. In any case, the parameters that the computer can track and use in determining the score of a song are as follows:

• the previous/current score of the song (prevscore: 0-100)
• the rating of the song (rating: 0-10)
• the play count of the song (playcount: 0-inf)
• the percentage of the song listened to now (percentage: 0-100)

How important are each of these parameters in judging the score of the song? The prevscore is our current best guess and needs to be refined. The rating is the absolute indication of how much you like the song. But over time, it is likely to be obsolete – the user may grow to like or dislike the song over time and the rating might not be relevant over time. The playcount indicates how obsolete the user’s rating is likely to be. If the playcount is high, it is possible that despite a low rating, the user does indeed like the song quite a bit. Finally, the percentage of the song that was just played is an important, though limited parameter in our decision – it’s altogether likely that the user had to stop the song because of an important call, for example.

In what follows, the code is provided in the Ruby programming language.

Let’s start with the prevscore. It’s our initial best guess of how much the user likes the song. If the song was never played before, the score would be returned as a default value, 0. Just to make sure it is so, the first if statement sets this:

if ( playcount <= 0 )
prevscore = 0

We need to next consider the rating of the song. Again, it’s possible that the rating is not present for the song. In that case, the computer must make a decision. Conservatively, I start it off at a rating of 5 – that’s two and a half stars.

if ( rating <= 0 )
rating = 5

The choice of the ‘<=’ logical operator is inspired by the default Amarok scoring script. Now, we are ready to make our first guess at the new score.

guess1 = ( 5 * rating ) + ( prevscore / 2 )

In other words, the rating and the prevscore are averaged. Let’s examine the stability of this guess. It’s immediately clear that this algorithm will always approach the condition prevscore = 10*rating. This was the basis of my first solution.

To improve our guess, the playcount must be considered. If the playcount is high, it should reasonably imply a higher score. This guess must be bounded by the user’s rating and the maximum, 100. The best function to execute this gradual move from the user’s rating to 100 is the exponential decay function.

guess2 = guess1 + ( 100 - guess1 ) * ( 1 - Math.exp( -playcount / 100 ) )

The playcount is divided by 100 to make the typically fast exponential decay a hundred times slower. Over hundreds of plays, the song’s score will now drift away from the user’s rating towards 100.

Finally, the percentage variable is brought in. This variable has the potential to wreck havoc on any algorithm – indeed it was the primary reason why I embarked on this endeavor in the first place. On the other hand, we must recognize the potential to introduce a little ambiguity in the scoring process. It does become boring to stare at a score forever pinned at 99. A little disturbance in the Force might be a good thing from time to time. In order to contain the damage this variable can do, I let it have control of 10% of the current best guess – guess2. If the song is immediately skipped, the score will drop to 90% of its current value.

guess3 = guess2 * ( 0.9 + 0.1 * percentage / 100 )

A final look at the stability of this algorithm is warranted. Initially, the prevscore will tend towards the rating, barring the effect of sub-100 percentage values. As the playcount increases into the hundreds, the exponential function will invariably take over and take the score towards 100. The percentage can disrupt this from time to time, but the score will always return back towards 100.

This, then is the thought process that went into the design of KarperScore 2.0. It’s currently in testing. I’ll release it as soon as I’m sure it’s working as I expect it to. The future improvements to this code should let the user decide parameters like the default rating, or the relative importance of the percentage variable to the score, etc.

Update: What a difference the class of the variable makes! Many of the variables above, such as playcount were initialized as integers and the exponential function likes floats! So, the score was jumping all over the place. Now, all variables have been initialized as floats and that solved all the bugs I noticed with the script during testing. The script is ready for general release as far as I can tell, but a couple of days more of testing the code is always a good idea.

Update 2: KarperScore has been working so well for me over the past couple of weeks that I’ve been using it that I wish I could reset all my playcounts and scores, to start all scores fresh. I need to ask someone on the Amarok IRC channel (#amarok on irc.freenode.net) if that’s possible at all…

I did a simulation of how the score of a song varies over one hundred plays, assuming that the user sets a (constant) rating when the song is listened to for the first time. That’s why the scores always start at 25 for each of the three cases – no rating (blue), full rating (red) and minimum rating (green). I also assumed that the user listened to the song in its entirety everytime it’s played (percentage = 100).

Clearly, for an unrated song, the score approaches 100 leisurely, making it to about 88 after the user listened to the song for the hundredth time. It’s a good guess of how much the user might like the song after so many plays. If the rating is specified, the score tends faster or slower than this. The fastest rise is for the five-star rated songs – the score passes 90 if the song is played just four times. The lowest minimum rating possible is a half-star. Note how the score approaches the rating over the first few plays and then slowly climbs as the song collects more playcounts. When played for the hundredth time, the score reaches about 80.

Problem statement:
Amarok is the music player of choice for the millions (?) of music loving people who use Linux. As one of the flagship KDE apps, it has a legion of followers who believe that there could be no better music player, except of course, for the next release.

Using Amarok, it is possible to let the computer automatically rate your music and assign a “score” in addition to the rating you provide. You, the user, rate a particular song by assigning it 0 to 5 stars, in steps of 1/2 stars. Using parameters like playcount, current score, percentage of song played etc, the computer calculates what the score the song should get.

The default scoring script does this (from Amarok Wiki FAQ):

if( playcount <= 0 ) # not supposed to be less, but what the hell.
  newscore=(prevscore+percentage)/2
else
  newscore=((prevscore*playcount)+percentage)/(playcount+1)
end

Now, this is a perfectly nice script and works fine. However, I feel that the point of running a score script is to allow the computer to judge how much you like the song. The percentage variable is a pain in the ass. For one, I’m scared to browse through a bunch of songs by listening to a bit of each. Because the score depends on how much of the song I listen to, if I skip too early, it drastically reduces the score of even my favorite songs, just because I didn’t listen to it completely. Also, I don’t want to shoo people away from my comp if they want to listen to just a bit of some song. The only workable solution to this is to use the seek bar and click near the end of the current song. That would make the player think I’ve listened to the entire song.

Solution:
So, I decided to write up a new script that addresses my issue. I feel that the score should tend towards my rating if I provide one. If I didn’t it merely goes by how many times I’ve listened to the song. The only way the score would decrease is if I rated the song lower than the current score. Even then, over subsequent plays, it should tend to my (new) rating.

I needed to set up an infinite series that tends towards the “rating” variable. Simple. Keep taking the average of the rating and the score. Here’s my algorithm:

if( rating < 1 )
  rating = 10
end
if( playcount <= 0 )
  prevscore = 0
end
newscore = ( 5 * rating ) + ( prevscore / 2 )

First, the code checks if you have a rating (using dcop). If you haven’t rated the song, the rating is 0 and it targets 10. If you did rate the song, it’ll target your rating. The rating stored by Amarok is twice the number of stars. Thus, a song rated, say 3 1/2 stars will result in a rating of 7. To scale it to 100, I need to multiply it by 10 and take an average with the prevscore. That’s why it’s multiplied by 5. The prevscore is the current score of the song. If it’s being played for the first time, I’ve explicitly made it equal 0. I wasn’t sure if the default score was 0 or 50. Half of this counts towards the new score.

Some friendly, if cryptic instructions from the Amarok website got me started. Since this was my first script (and in Ruby, too!), I used the default scoring script itself as a template in order to make sure I got the syntax right. The default script is stored at /usr/share/apps/amarok/scripts, just like my installed scripts will land up in ~/.kde/share/apps/amarok/scripts. Anyway, I prepped the tar ball just like the Amarok website said and launched it on kde-apps.org.

Hope some of you will try it out. Let me know what you think!

Update: Because of where I was issuing a dcop, the script was using the NEXT song’s rating instead of the current song’s. How painful! The code has been fixed and updated to v1.1. Now it works as nicely as it should

Back when I was a kid, we had this Nintendo system, you know the one – with cartridges. The games were simple, reflex-based and good for hours and hours of fun. I recently rediscovered the pleasures of playing all those old games again.

For linux, you’re pretty much stuck with using GFCE Ultra as the emulator front-end. So, on Kubuntu, you’d just go,

sudo apt-get install gfceu

Next you need the games themselves. They come in tiny files called ROMs. You’re not supposed to get them unless you have the original and since pretty much every kid used to have the originals (yeah, the cartridges you used to love so much…gathering dust in some box at home), that shouldn’t be a problem. Some good folks with the know-how post up the ROMs for downloading. Go and get thee thy cherished old games.

Fire it up (it shows up in the Games menu). Now, to set up your controller. You may have one of these, which helps recreate ye olde game console feeling significantly more believably. Or you can just use the keyboard. Whatever works. To configure the controls, plug in your gamepad, if you have one, and go to the input tab and click Gamepad 1. Press the button you want to stand for each control. When you’re done, go back to the first “Main” tab and browse for the NES file you just downloaded and fire it up. Alt-enter is full screen. Enjoy!

Now for peeves. Gfceu is one sweet app and compared to using the text based fceu, it makes me one grateful gamer to have it. Still, it’s Gfceu! Whatever happened to Kfceu? Because it’s not KDE, it messes with the shadows feature. Specifically, if I alternate between full-screen and window three times, the fourth time when I come out of the full-screen mode, the shadow of the window sticks. There’s no way to get rid of it. Subsequent full-screen-to-window alternations will “add more shadow”. So, now you have this black square where things fall dark at the top-left hand side of the screen. But fear not. Just go to system settings, turn off shadows and turn them back on and your desktop is good as new.

Second pet peeve is far too specific to be a big deal at all – it doesn’t work with Super Mario Bros. as nicely as it should. I know for a fact that I have a proper ROM – works in Windows – but in gfceu, it starts in this World 0-0 and there’s just no way out! You swim to the end of the level and there’s no way out. Basically you can’t play that one game. Methinks it must be some sort of early attempt at copy-protection…

So, it’s really just one peeve and even that is fixable. So, go on and fire up GFCE Ultra and enjoy the NES days again! My current fav is this one game called B-Wings…