Kubuntu on Sony VAIO PCR-SRX41P

Yesterday, I bought a new laptop. My old one (a Fujitsu-Siemens, PIII-450, 192 mb ram) let me down one time too much. On FOSDEM, it kept the audience waiting a long time, but things got even worse - during my KDE 4 talk at a Mandrivaclub meeting, I had to wait a few minutes between each slide, and at the KOffice ODF, fighting the laptop took almost as much time as writing the articles. Saturday I have a talk at the local NLUUG, so I would prefer to have a workable setup by then.

So I got tired of that, and got myself a very small (10.4" screen) VAIO. PIII-800 MHZ, 256 MB ram. Nope, not like 10 times faster, but I can't afford much more (I paid 200 euro's). It doesn't have a cd drive (well, an external one, firewire based), thus it's very light: only 1.2 kg!

Now how well does it work with linux (Kubuntu Feisty Fawn)? Almost perfect. Yes, really. suspend and hibernate both work (but choosing suspend hibernates the laptop, and hibernate suspends it...); the volume keys, mute, brightness - they all work. Different from the windows ones, where you first have to do Fn-F5 and use the arrows to change brightness, here Fn-F5 decreases, and Fn-F6 increases brightness. Same goes for volume, but who's complaining? I prefer it this way, actually...

Network works fine, I haven't tried wireless much yet, but it's pretty old (802.11b) so that might be a problem here and there. At least at home, it doesn't see my wireless network...

So, let's see how it works saturday.


And here, for the people from linux-on-laptops:

Installing Kubuntu Feisty Fawn (7.04) on Sony VAIO PCR-SRX41P

General Hardware Specifications of this VAIO:

Hardware Components	Status under Linux	Notes
Pentium III-M Processor, 800 MHz	Works	No special procedure required during installation.
10.4 SXGA TFT Display 1024x768	Works	No special procedure required during installation.
Intgrated 82815EM in Intel 815EM chipset(	Works	No special procedure required during installation.
256MB, PC100	Works	No special procedure required during installation
30 GB Ultra ATA Hard Drive	Works	No special procedure required during installation
Bluetooth	might work	I can't turn it on in linux (yet), so it doesn't work.
Integrated Network Card	Works	No special procedure required during installation
Internal 56k Modem	Not tested. It is a winmodem.	Should not be hard to get working but I don't need it.
external Firewire 24X Max Variable CD-ROM/DVD Drive	Works	No special procedure required during installation
Internal Intel Wireless Networking (802.11b)	Works	No special procedure required during installation
Lithium-Ion Battery	Works	Guidance Power Manager DOES show time left properly, but the icons shows up always red
Internal Intel AC'97 soundcard	Works	No special procedure required

This laptop is operating under Kernel version 2.6.20

Unresolved issues:

• Bluetooth


• KDE battery meter doesn't function correctly

Function Keys:

• Fn + F2: Mute
• Fn + F3: Volume down
• Fn + F4: Volume up
• Fn + F5: Brightness down
• Fn + F6: Brightness up

I'm happy with the battery time, btw - works for 3 hours, no problem.

Boost

While we already had a few KDAB developers hanging and hacking around, we got another visitor: Sebastian Pipping. He happend to be close by, and decided to drop in. He is a Kate developer, currently mainly working on multi-line regular expression search. With the current Kate infrastructure that's pretty hard to do, and he is looking for libraries to make his life easier. Qt won't really help him, as it would be far too slow on big files, and had been looking at Boost. He described the relevant Boost library in pretty euforic statements, but then mentioned he tried to forget about it, as he was convinced Boost was simply not an option, not now, not ever, never... Now I did notice there was some discussion on the kde-devel mailinglist, and even if that wasn't the case - if boost can help so well, it's bad not to be able to consider it, right?

don't computers suck?

The KOffice ODF Sprint is progressing well. At least, for the other participants. I'm mostly fighting with my laptop while I try to write... At least he first article is send to sebas, let's hope he can get it online.

My laptop happens to be a little old, and recently something changed in Kubuntu which made it a lot slower. Memory usage went through the roof (I have 192 mb ram). Part of that is due to the Guidance power manager (top told Boudewijn and me it took 56Mb ram, almost nothing shared...). But it seems to me there is something else as well, as I never had these grave problems on earlier releases. Grave problems here means you can easily get it to a state where it takes several minutes for ONE character to appear in a console... You can imagine how that feels when you still have unsaved changes.

Another problem was getting the pictures of the SD card from the camera I used. Wow, that was a fight, even Windows got started to see if it could read it - but no, it couldn't. sigh... Finally, it was Boudewijn and his (french) linux phone he won on Akademy last year, which saved the day - it read the SD card without any trouble, and Boud used an USB cable to get the pictures on his computer. I had to work on them there, as Gwenview triggered a Out Of Memory kill with the pictures on my own laptop (after approx 1 hour, in which it was unusable).

Of course, that where just 2 of te irritations I had today - I kind'a hate computers right now. Still, for some reason I'm typing on my laptop right now... People are weird. And I know.

Well, at least the article is send, and I have some hope I will be able to finish the saturday article in time.

(I'm gonna cry now)

Strigi performance II

Let's check the performance of some other plugins. The strigi png extractor was clearly faster than the KFileMetaInfo based one, but how about the other fileformats?

So, I went looking for a fileformat which was abundantly available on my pc, and supported by both strigi and kfile. Not much choice, but in the end, xpm turned out to be interesting. Again, xmlindexer was a lot faster. It took xmlindexer 13 seconds to extract the meta-data from all xpm files on my disk, while kfile needed almost 2 minutes (average over 3 runs again).

Now I'm really wondering why the difference is so big. So I went to sysprof to figure out what was happening. It can show you what an app is spending it's time on.

Looking at the results, it seems kfile spends only a very small percentage actually reading the metainfo. Most of it's time, around 50%, it's trying to figure out what mimetype the file is, using kmimetype! So that's the slow part... In the xpm case, a bit more than 3% was spend in reading meta-data, while with the png plugin, it was less than 0.2%!

So the speed difference between kfile and strigi's xmlindexer wasn't really in reading meta-data itself, it was mostly in figuring out the mimetype in KDE. Which strigi does much more efficient.

What does this say about strigi performance? Well, we're back to square one. It's not reliably possible to correct for the slowness of kmimetype, so I can't figure out how much faster (or slower, but I think that's not very likely) the strigi meta-data extractors are compared to kfilemetainfo. At least, we know if someone would write a strigi analyzer for it, figuring out mimetype will be a lot faster in KDE 4...

And of course, strigi could use it's database for meta-data - which might give a big speedup after all. And it will allow things like special directory listings based on some property of the data.

strigi in kdebase

So, Jos van den Oever (yes, the guy working on Strigi) blogged about porting the KFilePlugin's to the new strigi-based infrastructure. Those plugins extract meta-data from files, like in case of a picture, resolution, creation date and such.

This allows Nepomuk integration, less code duplication, and more speed.

Now there have been some insights in Strigi's performance, where it proved to be 40 times faster indexing files compared the the second-best... Of course, the competition has improved since. But how does the new strigi meta-data extraction compare to the old KFileMetaInfo in terms of speed?

I tested this on all png files on my system, using the following two commands:

For KDE 3: time locate png|grep \\.png$|xargs kfile --av
For KDE 4: time locate png|grep \\.png$|xargs xmlindexer

The output of those is comparable, though the xml indexer from strigi extracts stuff in xml form. Both put out the meta information to the commandline, showing things like dimensions, color depth or comments.

Now, on my dualcore 2.2ghz 3gb RAM system, kfile takes 40 minutes to complete (average over 3 runs). Xmlindexer takes an average of 24 seconds. Yes, seconds. That's almost 100x as fast...

xmlindexer (strigi):
real 0m27.262s
real 0m27.056s
real 0m19.328s
Average 24 sec

kfile (kde3):
real 45m5.689s
real 37m14.158s
real 37m17.515s
Average 40m12sec

So, how could this be so much faster? Filecache used by strigi? I first ran xmlindexer (27 seconds), then kfile (45 minutes) and then, after a few hours (during the night), I ran both tests twice again, with a 1 hour interval. Yes, I did use my dualcore in the mean time, mostly watching a movie. So the results aren't exactly scientific, but hey - we're talking a 100 times faster here. A movie won't have such a huge impact... And filecache might have an impact, but if it does - it can't explain the differences. Second and third run of kfile where indeed faster, but still magnitudes behind strigi (which got faster as well).

According to Jos, the speed difference could have two reasons: kfile does something wrong, and KFileMetadnfo isn't that slow, or - well, it is... (I'll have a look at this, btw, expect a second blog about it). It could just be that the png indexer in KFileMetaInfo hasn't seen much work, and most of the speedup could have been gained by rewriting it - so I'll have to check other plugins as well to see how they compare. And currently, the new infrastructure isn't as complete as KFileMetaInfo was - many plugins haven't been ported yet, and there is no KIO integration.

Still, seeing new technology being this closely integrated in KDE, and finding out what it can do makes for some interesting statistics, don't you think? I'll try to test more plugins, and figure out if there is something wrong with kfile. And Konsole, btw, as it crashes every time I try the KDE3 test in it... Maybe the unlimited history gets filled up a bit too fast/much?

fab wanted a blog from me... so i digged up this old account, and thank Bram here for getting Een blik in de toekomst online so quick...

blogger

damn blogger... had to try quite a few names to find one that seemingly was not taken (or at least, it did not want to give it to me...)

whatever

at least now i can post here on blogger.com :D

and my first reaction will be here: http://aseigo.blogspot.com/2005/04/why-khtml-is-important.html