This has bugging me for ages. Whenever I want to disconnect my iPod with Linux, I always ended up having to unplug it with the “Do not disconnect.” message flashing. The solution is so:
chmod +s /usr/bin/eject
Ejecting the iPod, will now correctly disconnect the device.
So I wanted to move my computer into another room. The problem is tha I will need to install a wireless card to keep myself on the network. Does Linux even support wireless yet? And I want WPA encrpytion on top of that too.
Well the answer seems to be yes, sorta, sometimes, if your lucky. So I hunted around and pulled out a DWL-G510 (HW Ver: C2), stuck it in the computer and lspci gives me:
00:09.0 Network controller: RaLink RT2561/RT61 rev B 802.11g
The card contains an RaLink chipset. There are 3 drivers available:
The first driver from the Rt2×00 project (available in portage, net-wireless/rt2×00) didn’t work at all. I could load the driver, but scanning produced no result.
The second driver (available in portage, net-wireless/rt61) loaded fine, and I could gain a connection with no encryption and WEP encryption, but no matter what combination I used, I couldn’t get WPA to work.
The third driver I downloaded from Ralink’s website and with a little bit of fiddling, I am able to load it and connect using WPA encryption.
I used the following commands to successfully connect to my Netgear DG834G wireless hub:
#!/bin/sh modprobe rt61 sleep 3 ifconfig ra0 up iwlist ra0 scan iwpriv ra0 set NetworkType=Infra iwpriv ra0 set AuthMode=WPAPSK iwpriv ra0 set EncrypType=TKIP iwpriv ra0 set SSID="network name" iwpriv ra0 set WPAPSK="my passphrase" iwpriv ra0 set SSID="network name"
After probing the device, I had to sleep otherwise the device didn’t come up correctly. Substitute “network name” with your own, and “my passphrase” with the WPA-PSK passphrase.
I haven’t quite figured out how to get all this to work using the Gentoo standard network init script. The main problem seems to be that the network interface needs to be activated before it had be configured. For now I’m just happy I don’t have to run a 50 meter extension cable through my house.
Amarok recently released the ability to synchonise music to your iPod, so I was finally able to stop using iTunes to transfer my songs. However I was still stuck using the Mac to sync my addressbook.
Well not anymore, after some quick poking around, and a simple script, I am now able to transfer my complete KDE addressbook (including photo), with a simple command line.
Just mount the ipod, and execute the script, passing the ipod’s root directory as a parameter. That’s it! The script loads your KDE addressbook, makes a few simple modifications the iPod requires, and copies it across.
Download kde_ipod_sync.rb
Grab the thread.cpp and thread.h source files.
Today I decided to write a cross platform thread class. After a quick look around, the contenders for the job of hiding operating system dependent code seemed to be:
As I’m after simplicity, SDL seems the appropriate choice as the API is basic and quite low level, yet I’m not exposed to any platform specific code. One thing it’s missing that I thought might become useful in the future is thread priorities, but for now that’s something I can live without.
The three SDL functions I need to use for this class are:
| Function | Description |
|---|---|
| SDL_CreateThread | Create the initial thread |
| SDL_WaitThread | Wait for the thread to finish executing |
| SDL_KillThread | Force the thread to die |
The first thing we need to do is to be able to start the thread. We do this with the following code:
void
Thread::start()
{
if (!m_running)
{
m_running = true;
m_thread = SDL_CreateThread(runThread, this);
}
}
First we do a simple check to see if the thread has already been created, then we create the thread passing the entry function to the thread as the first function, and a pointer to this class as the second. The reason behind this combination of parameters, is because the first parameter must be a simple function pointer, and cannot point to a member function of a class. runThread() is a static function of on the class which fulfills this requirement. We therefore pass the the object pointer in as well so we can reference back to ourselves.
This becomes more obvious in the entry point function:
int
Thread::runThread(void *data)
{
Illuminate::Thread *thread = static_cast(data);
thread->run();
return true;
}
In this function, we first cast the data parameter back to the original Thread object which originally created the thread. We can then call the run() method which is the virtual method implemented in the subclass. We also keep track of the running state of the thread which can be accessed from the isRunning() method, and reset m_thread back to 0 so the thread can be started again.
Derive from the Thread abstract base class. Implement the void run() method. Construct your new class as an object and call start(). That’s it!
#include "thread.h"
using namespace Illuminate;
class MyThread : public Thread
{
private:
virtual void run() {}
};
int main()
{
MyThread thread;
thread.start(); // start the thread
thread.join(); // wait for the thread to complete
return 0;
}
The main current weakness of this class is the lack of thread safety, although there is unlikely to be problems in most suitations. A possible scenario which may cause problems is if the join() is called at the same time that the thread is completing as they both access the m_thread variable. The easiest way to get around this is through the use of locking, with which SDL supplies a simple interface for.
Well that’s it. A very simple class which allows a programmer to access some very advanced features. However it’s not all smooth sailing. Once you move down the path of threaded applications, you enter the realm of mutexes, which brings in a range of problems from deadlocking or worse!