So, writing the announcement of Beta 1 was fun, and it's cool to be quoted all over the web ;-)
Yet, every time I write about nice stuff done in KDE, I'm left with the nagging feeling I MUST have missed a lot. And I'm sure I did miss some great things. It's mostly due to the unstructured, ad-hoc way of writing the announcements. OK, I tried to go through a lot of blogs and all KDE commit digests since the second alpha (boy, is that a lot of work) but even then, stuff is missed.
Now it's not just that the release announcement is thus incomplete. It's also that people don't get the credit they deserve, and those reading the announcements miss out on some great stuff which has been done.
So I came up with the idea to create a space on techbase where everyone can help collect stuff for the next announcement. And with everyone, I mean EVERYONE. If you just saw a cool thing being checked in to KDE-EDU, or you read a blog about a new fun feature in Kwrite - or you do a test of KWin and discover new stuff - go ahead. It's worthy. When the release announcement has to be written we (the promo team) will go through it, filter the good stuff, write the text all the while thanking each and every contributor silently ;-)
You don't have to write anything, just say what it's about ('Cool KWin stuff' is enough) and provide a link...
Where? here you go: http://techbase.kde.org/Schedules/KDE4/4.0_Announcements
I already threw in some things, and I'm sure I forgot stuff already. So, developers: if you did something amazing, put a link there. To a blog, commit message, mailinglist email, anything. And to all those reading all the blogs and stuff in the community: please, help a little. It's not much work at all, and it'll not only help us - but also ensure the completeness of the release announcements!!!
Love,
Jos
10 August, 2007
01 July, 2007
Akademy 2007 - day 1
Akademy 2007 started of a bit weird for me. Jos (van den Oever) and me went to bed around midnight. After a few hours sleep, I was woken up by a face next to mine. Aaron decided the floor of our room was unused, and it was the perfect spot to put Laur, who didn't have a place to sleep. He was nice enough to warn us so we'd not be too surprised, but it was hard to get through to our sleepy heads...
Saturday, managing the whole press thing was very hard. We didn't make hard arrangements in advance, so I had to ensure both tracks where covered. Luckily, some ppl quickly offered to help (thanks Giovanni, Laur, Claire!) and when Danny arrived, our press team got up and running. We even have a pressroom now, though it's shared with the food corner ;-)
We still missed Troy, though, who was held up by the incident at the airport.
The second day, the pressroom got so crowded, we (Danny and me) didn't even have a proper seat, so we just moved to the 'real' pressroom in the other building (we each have our own desk now) so we can put up the first article. Yes, you can expect it any time now, as the network is finally up... And Troy did arrive, which means more hands writing for the articles ;-)
Saturday, managing the whole press thing was very hard. We didn't make hard arrangements in advance, so I had to ensure both tracks where covered. Luckily, some ppl quickly offered to help (thanks Giovanni, Laur, Claire!) and when Danny arrived, our press team got up and running. We even have a pressroom now, though it's shared with the food corner ;-)
We still missed Troy, though, who was held up by the incident at the airport.
The second day, the pressroom got so crowded, we (Danny and me) didn't even have a proper seat, so we just moved to the 'real' pressroom in the other building (we each have our own desk now) so we can put up the first article. Yes, you can expect it any time now, as the network is finally up... And Troy did arrive, which means more hands writing for the articles ;-)
31 May, 2007
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
This laptop is operating under Kernel version 2.6.20
Unresolved issues:
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
- Fn + F2: Mute
- Fn + F3: Volume down
- Fn + F4: Volume up
- Fn + F5: Brightness down
- Fn + F6: Brightness up
13 May, 2007
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?
12 May, 2007
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)
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)
26 March, 2007
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.
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.
21 March, 2007
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?
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?
Subscribe to:
Posts (Atom)