I read the Chrome comic on Monday. It goes into technical detail in describing what their justification was for creating Chrome. By and large I think they succeeded: on the whole, Chrome doesn't appear to be a case of not-invented-hereism. They really do have some different ideas of how to do the browser, both technically and in the UI.

So yesterday I knew two things: Chrome was going to be crossplatform and the 30pg+ comic that went into some detail didn't say how they were planning to do that or anything about their UI toolkit.

So after poking at the code for a bit, it comes to no great surprise that crossplatform wasn't a big concern from the start. Currently the Linux version doesn't actually run, according to its website. And their UI toolkit choices might indeed have been based on some NIHism and are certainly not the most Linux or OS X friendly. Given how easy it is to create a crossplatform app if you make the correct early decisions, this is a bit frustrating.

They use Skia, a graphics library for Android for basic image display. And they have "Chromium Views" which mostly seem to be used to abstract between XP and Vista. It could theoretically be extended and used for crossplatform abstraction (just what the world needs - another xplatform api).

And why not Qt? "Existing UI toolkits for Windows are similarly unsatisfying, with limited widget sets, unnatural aesthetics, or awkward programming models. " Doesn't jive with my experience of Qt. But I guess I'm a bit partisan.

I do think that promising cross-platform support might have been a bit disingenuous of them, time will tell for sure. I suspect that if Linux desktop users do see Chrome, it will most likely be in the form of existing browsers incorporating some of their technology or ideas.

Amarok 2 has two scripted services that are really cool. For one SeeqPod, that lets you search for any kind of music on the web and listen to it in Amarok. And the other one is LibriVox, that integrates the LibriVox service. LibriVox offers free audiobooks of public domain books. Both services are great and definitely deserve to be in Amarok 2.0.

The problem is that they were written a few weeks ago in Ruby. Now they need to be ported to QtScript as that is the only scripting language we allow for internal scripts to reduce the headache of script dependencies especially keeping the Windows and Mac releases in mind.

Among all the stuff that needs to be done before the release of Amarok 2.0 those two scripts were kinda forgotten until now and really need some love. If you want to help us get those two scripts back please let me know. Free cookies and hugs included

So I apparently haven't blogged in a month. Sorry about that, it's not that I have nothing to say, just that I'm usually busy doing that I don't really take the time to talk about it. That said, I'll still keep this short as I myself like to read short blurbs from people who aren't well-known.

Akademy. Awesome. Of course I got to meet a good amount of the Amarok people I often talk to, which was the highlight of the trip for me really. It's one thing to discuss over IRC, and quite another to have breakfast together, chat about things non-Amarok as well as Amarok in person, and in general hang out. I also got to meet a lot of other people, like Will Stephenson who donated an MTP device for development (who I met while waiting in the waffles line) [p.s. thank you so much again for it].

Most exciting stuff non-Amarok: Gallium3D... just wow, that's all I can say. Step was pretty awesome too, though my physics is really bad. Marble is exciting stuff, but in Openstreetmap there remains much to be mapped so it may be a while before it becomes truly amazing. There's more, but these are the ones that stuck out most in my mind right now.

So, Media Device Status Report. As you can see, I haven't blogged so obviously nothing has happened. Lies. MTP playing off the device is now supported, a bunch of random bugs have been fixed, and an applet is under way to deal with configuration etc. of devices. Don't worry, this is only for connect/disconnect and options and whatnot, the configuration of devices will still be almost entirely automated. I'm trying to figure out a way to make it more obvious that for media devices you need only plug in your device essentially, for it to just work. I think that I'll try to push for the Media Devices applet to be one of the initial defaults loaded, and it'll show a text like "plug in media device to play from it" or something.

Why have I been so slow at coding? The truth is I've been held in Guantanamo for the last couple of weeks. And.... again, lies. No, between random life, then Akademy in Belgium (which I spent most of my time bugfixing and socializing), and now I'm in Japan where it's hard to stay on the computer too long, I haven't been that able to. But I'll be back in the USA Sept. 2, so starting then things should pick up a bit more hopefully.

On that note, cheers from Japan!

The Amarok team is proud to announce the first beta of Amarok 2.0, codenamed Nerrivik.
Please digg it and enjoy the release notes.

If you want to meet some KDE folks, want to see KDE 4.1 in action or if you have questions about KDE FrOSCon in St. Augustin is the place to be this weekend.

Come and say hello at the KDE/Amarok booth and in our dev-room.
We have interesting talks for everyone in our dev room:

Saturday:
11:15 KDE Edu (Frederik Gladhorn)
16:30 KDE Community - How to get involved (Alexandra Leisse and Lydia Pintscher)

Sunday:
11:15 Amarok 2 (Sven Krohlas and Lydia Pintscher)
15:15 Kubuntu - A KDE desktop (Marcus Czeslinski)
16:30 KDE Grill - Ask questions about KDE you always wanted us to answer (KDE dream team ;-))

And on Saturday 15:15 Sebastian Kügler will talk about KDE 4.1 in his talk “Don’t look back” in the main track.
Hope to see you there.

Oh btw: Last year’s social event = best social event of 2007. Let’s see if they can beat Akademy this year

I should have blogged much more from Akademy, but having hardware which insisted on frequently overheating made life a little difficult. I’m still in Belgium - in Bruges actually, blogging from my N810 courtesy of Nokia. More on that later.

I’ll start by saying that l think we had very productive week, getting lots of design and development done towards our goals for Amarok 2.0. We focused heavily on critiqueing the user interfaces of the major components in our GUI: the playlist, context view and each of our sidebar browsers. In between hacking hours, Mark, Leo and myself hosted design and release-breaking-issue sessions. These have provided valuable direction and motivation to all of our developers, so you can look forward to some exciting progress as we gear up to an imminent beta (and eventually final) release!

We also brainstormed a number of post 2.0 ideas such as interface adjustments to enhance your application experience, including, but not withstanding, mobile and embedded devices. Yes, that’s right folks, before too long (hopefully) you’ll be able to run Amarok on your favourite (maybe) small form factor device. The main use case would be for remote collections and streaming, but we’re not going to shut out users who like carrying 8GB of music on memory cards.

All this talk of small form factor devices is making me drool over my N810 as I write this. Some observations: all this very slow and awkward typing makes me much more coherent; leeching off random wireless to blog has never been easier; and, the inbuilt GPS has already proven invaluable to the Amarok crew as we used it to find our restaurant when we got lost cycling through the mid-west of Belgium. Note: never cycle 15km immediately after eating a huge meal, and never let Casey on a bicycle.

Finally, a big thanks to all that made Akademy so great: the organisers, the participants, the speakers, the boffers, the paparazzi, and all the people that were responsible for either brewing, frying or coating things in sugar.

Finally back at home. Less tired after sleeping in my own bed again. Missing everyone. Caught up on stuff. Laundry still piling up

Akademy was great. Very big THANK YOU to Wendy, Bart and their team. You did an amazing job.

Akademy was quite productive. Talked to lots of people about lots of stuff. Wait for some interesting things to happen in the next weeks and months.

I took the time to talk to some of our Google Summer of Code students about their experience. I wanted to find out where we as a community are doing very well and what we can improve in their opinion. Of course it wouldn’t be of much use if only I knew this so let me share it with you:

• Everyone seemed to agree that KDE is a great community and that they felt welcome in our community. Akademy was seen as a great opportunity for the students to get to know people and it seriously helps in turning some of the students into contributors outside of GSoC. (Note to self: Find out how many of them are still committing code in 6 months.)
• Documentation!!! The Amarok team seems to be doing a bad job here :(  (Not really sure about the rest of KDE.) I need to find ways to improve this. Suggestions welcome.
• The Big Picture: This seems to be missing. Mentors should try to give an overview of the code and community and how it fits together at the beginning. Some of the students felt lost at the beginning and it took them a lot of time to get used to everything. For Amarok I created a wiki page with all the important links to websites and mailing lists for the students. Unfortunately the code overview part of it did not get finished.
• Blogs: The Amarok students were encouraged to blog about their work every week and post it on Planet Amarok and Planet KDE. Same goes for some of the students that worked on other parts of KDE. Everyone seemed to agree that this was a good thing. The feedback they got was encouraging and helpful. They felt pushed to produce something worth blogging about at the end of the week which was seen as positive and motivating. It also showed that people are interested in the work they do and that their progress is monitored.
• Branches: Working in a SVN or Git branch outside of trunk was seen as a problem. Code did not get reviewed and tested enough before it hit trunk. Those students worked too much in their own little world. Immediate testing and code review by other developers would have been preferred and a lot of problems would have been avoided. (I know there are reasons for branches but something needs to be done about this.)
• Timezones: Timezone mismatches between mentor and student made students switch their sleep/wake times by several hours. I got a few complains about this but it was always seen as a minor problem. I don’t think it is too healthy though. So maybe this should be considered next year when matching students and mentors.
• Gurus: Every single student was very thankful for having very knowlageable people in our community they could ask when reading manuals didn’t help. Even if their questions from time to time weren’t the most clever ones they got help. You rock!
• Mentor being away: Some mentors left for a week or more on very short notice. This should be avoided or a backup mentor in place.
• Students liked that they were mostly free to do what they want, i.e. solve problems the way they want and work on their own schedule.
• Mentors in general seemed to have done a good job. You rock!

Thanks everyone who had a chat with me about their GSoC. If I didn’t find the time to talk to you at Akademy or if you were not there feel free to ping me on IRC. I will make sure your feedback gets heard.

I hope a lot of our students stay with KDE after GSoC. You have done an amazing job. Rock on!

PS: Thanks to everyone who signed my Moleskine at the social event. I considered doing nasty stuff to Sebr when he took it away from me but I have to reconsider this now since it is the BEST THING EVAR and will be reminding me of Akademy for years to come.

*hug*

Yesterday we released Amarok 1.4.10, an unanticipated security release. From the Release Anouncement you may notice that we gave thanks to Google Alerts for notifying us of this vulnerability. This was perfectly accurate. Read on for why.

I want to say up front that the security value of this vulnerability rates so low that it's amazing Secunia even bothered with it. It requires local access (or at least, a shell prompt), and it requires our code parsing a file whose name was hardcoded to execute the code (doesn't)/overflow a buffer (doesn't)/do things incorrectly (doesn't). At worst, you could maybe make Amarok crash, and since this would be a race condition, you'd have to be extremely lucky, and this could only happen between when the user was downloading the Magnatune database and when it was being parsed. Not exactly mission-critical. So, the actual threat of the vulnerability was approximately nil. That wasn't the driving factor behind the sudden release -- the driving factor was the fact that since Secunia did issue an advisory, we wanted to respond to it as soon as possible. Which should have been 36 hours before. Here's where the bungling comes in.

At midnight Tuesday morning, Dwayne Litzenberger posts a bug report on the public Debian bug tracker with snippets of code from Amarok, and the following:

I'm not familiar enough with Qt to be sure, but it looks to me like the code creating a temporary file insecurely. At minimum, I think this code will break if another user has already created /tmp/album_info.xml (thus preventing the current user from deleting it).

Now, I'm more familiar with the KDE and Gentoo bug trackers, which explicitly ask you to not post security related information there, but to contact the projects directly (this would be in following responsible disclosure guidelines). Debian's bug tracker doesn't seem to say this, but it's hard to say -- in a couple minutes of looking around, I didn't see a link that would let me file a new bug directly. It seems you have to either email it in in a certain format or run their reportbug tool.

But as I was saying -- it gets posted to the public bugtracker, and Dwayne doesn't actually contact us directly. Neither does Debian. Perhaps they don't have bug triagers like I'm used to in Gentoo, and perhaps the maintainer of the package wasn't around for those 36 hours. Perhaps they simply didn't bother -- after all, we recently found out that Debian has created several patches for 1.4 over the years that their maintainer(s) never forwarded upstream.

Mid-Wednesday, Ian gets a Google Alert for Amarok -- Secunia has issued a security advisory against us. This is how we first find out about it, which was apparently considered enough of a vulnerability for Secunia to bother with it. Dwayne didn't notify us. Debian didn't notify us. Secunia didn't notify us. No one bothered.

This doesn't exactly correspond to normally followed responsible disclosure guidelines. A fellow developer thinks "Joe User" -- in this case Dwayne -- shouldn't be expected to know those guidelines. I don't buy it. If you know enough about security to recognize a vulnerability, you should know enough to properly disclose it.

My fellow developer also thinks that Dwayne acted responsibly, letting the world know about the vulnerability as soon as possible so that users could arm themselves against the problem until it was fixed. This is wrong, and easily seen to be wrong.

Let's forget for a moment that the vulnerability was miniscule in terms of threat level, and just think about it in terms of being a vulnerability, to prevent yourself from thinking "well yes, I see your point, but it was really miniscule" -- because that's not the problem with what happened here, and next time the vulnerability could turn out to be major.

Had Dwayne notified us first, instead of posting on the Debian bug tracker and letting it lie:

• Our users would have been protected from the threat 34 hours earlier (it took us five minutes to patch it, and another hour or two to get the tarball out).
  
• The information would have been made available to a wide audience via the Amarok users' mailing list and the packagers' mailing list 36 hours earlier, so that anyone worried about the threat would have been notified and could take action 36 hours earlier.
  
• The Secunia Advisory could have come out already supplied with the information necessary for people to fix the problem (upgrade to 1.4.10).
  

By not following responsible disclosure guidelines, any users concerned about Amarok's security were unaware of, and running, unpatched software for at least a day and a half longer than if responsible disclosure guidelines had been followed. Far from letting the users know so that they could act to protect themselves, the users actually ended up being the ones getting screwed here.

Now, I will say something in Dwayne's defense, on the off chance that he could spot a security bug but really didn't know responsible disclosure guidelines -- on their bug tracker, Debian has the following piece of information:

Don't file bugs upstream: If you file a bug in Debian, don't send a copy to the upstream software maintainers yourself, as it is possible that the bug exists only in Debian. If necessary, the maintainer of the package will forward the bug upstream.

In this case, the first "if" in that sentence should have failed -- it shouldn't have been filed in Debian's bug tracker. But even if the user decided they want to put it there, security bugs shouldn't be included in this -- they should not initially be public, in following responsible disclosure guidelines; or, if Debian wants security bugs to go through its public bug tracker as well, they should be on the ball and not sit around on these reports for more than 36 hours.

So, to wrap up: disclose security bugs you find in a project properly. Contact the project, and if you must post it publicly somewhere before giving the project a reasonable chance to respond, don't sit on it, but contact the project as well and make sure they know about it so they can start fixing it. Do it right, and the one getting the credit for notifying the project won't be Google Alerts; it'll be you.

Continue reading "Responsible Disclosure, and Amarok 1.4.10"

so the very kind folks who won the Akademy awards last year ( sebastian trueg, matthias kretz, danny allen ) decided to go ahead and award Amarok with the Best Application award! we are obviously very excited and very pleased to win this award, and want to (tearfully) thank all those users who have been with us through the long dark (teatime of the soul) times of Amarok 1.x.... wait, we never had those. nevermind.

Anyway, I would like to thank everyone on the behalf of the Amarok team for supporting us, and most of all for believing in us throughout the long Amarok 2 process. It's coming. Soon. But Not Yet (tm).

The other winners of Akademy awards this year include Nuno Pinheiro (Oxygen) for Best Non-Application Contribution, and we're exceedingly glad to be able to say that we have been collaborating with Nuno to get some kick-ass new looks for Amarok. Our continued cooperation will definitely result in some pretty sweet new designs for Amarok, and we are really happy to be working with him.

The other winner of the Best Contributor to KDE is none other than Aaron Seigo, KDE dancer extraordinaire and resident party animal. After a late night saturday, Aaron was able to provide enough lap dances to the judges to sway their opinion in his favor, and he took home the goods.

I'm excited to be done with the talk portion of Akademy, and to get to the hackathon sessions. I'll have to find a way to get through the e.V. meeting tomorrow, but other than that, expect a productive week of amarok hacking coming up!

Last night I managed to have nearly 100 people sign Lydia’s little black notebook at the Akademy beer-event. It was fun and a perfect example of how beer can give you a reason to do practically anything.

Coming up: Amarok talk. Must write notes.

The wolf has once again descended on Akademy. Last year there were 6 of us, this year that has more than doubled. Come the hacking marathon on monday, this will hopefully lead to a great amount of code, technical discussions, bugfixes and general coolness.


( there are a few people missing from this picture )

Tonight was the social event, with great food and great ( and strong... ) Belgian beer. As should be evident from the above picture, the Amarok'ers were making the most of this and having a great time ( I am sure some of them are still going strong as I am typing this... )

An event like this is, as Aaron illustrated, also the perfect place to ponder the needed steps for KDE to achieve ultimate and inevitable goal of total world domination.

I don't blog often, but when I do it tends to be meaty.  I won't disappoint.  I'll be covering Amarok, Amarok history, and a possible future part of kdelibs.

"We can rebuild him. We have the technology. Better than before. Better, stronger, faster."

A little-known feature in Amarok 1, starting at about 1.4.3, was what was known as Amarok File Tracking, or AFT.  For every single file in your collection, on scan, a unique identifier (UID) was generated from some of the file's attributes.  If you moved your tracks around your folders, as the incremental scan kicked in, the UID would allow for the file to be identified, and integration throughout Amarok would mean that your statistics, your cached lyrics, and the current playlist would all be updated with the new path.  No longer did you have to worry that moving around your files would mean losing years of statistics.  Or losing your files.

But I'm getting ahead of myself.

See, AFT wasn't born AFT.  AFT could not track both a file metadata change and a file location change at once, because the UID was being based on file properties such as file length, plus a portion of the file itself hashed together. So you could still lose track of your files.  This was a limitation that was known in advance.

It was also a limitation that didn't originally exist.  As I said, AFT wasn't born AFT.  It was born as Advanced Tag Features, or ATF.  ATF was the same idea, but a little different -- it would store the generated UID directly in the file's metadata.  This allowed for superb file tracking capabilities, because unlike generating a UID from a part of a file, if that part of the file changed, you'd still have your UID.  In fact, the only way you couldn't track your file was if you either removed the file's tag entirely (or some other program removed the UID when it shouldn't), or if you removed the corresponding information from Amarok's database. (There are some downsides to this scheme: only certain file types are supported, for instance, determined by the kind of tag they use and the tag's ability to store this kind of information.)

So why the change?  Well, ATF had a problem, which was related to the structure of Amarok itself, and Amarok's historical penchant for crashing (which got much better as the 1.4 series progressed).  The outcome is possibly worthy of an entry in The Daily WTF.  In gory detail, here's the problem.

   1. Amarok would start a collection scan.  The collection scanner was the entity responsible for adding the UIDs to the file metadata.  Important note: the collection scan was a separate process.
   2. Amarok would crash, leaving the collection scan running, although not communicating with anything.  This scanner could be very slow if it was adding the UIDs, depending on whether padding had to be added to the file's tag.  If this was the case, the entire file would have to be rewritten.
   3. Amarok would be restarted by the user.  Another collection scan process would start.  Becuase UIDs would already exist for the early files, it would very quickly catch up to the first collection scan process.
   4. You now had two collection scan processes generating and writing UIDs at the same time to the same file.  If you were lucky, this would mess up your tag.  If you were unlucky, this toasted your entire file.
   5. Repeat step 4 for the rest of the scan.

ATF was never released in this state, but it did get turned on in SVN.  And a few unlucky users had far too many files end up corrupted, depending on how crashy things became for them.  After we finally realized what the issue was, a user came forward on the mailing list (still trying to find the exact mail or user) proposing a solution that I believe they'd seen in a class.  Essentially, the solution relies on modifications to temporary, uniquely named files instead of the original file, using MD5 checksums to find out of the original file has changed while writing the new file, then using filesystem atomicity guarantees to move the new file back over the old one.  This became the MetaBundleSaver, and it worked quite well, but it was also extremely slow compared to a normal scan.  And most importantly, no one was quite trusting of the whole ATF scheme any more.

So, ATF was renamed to AFT and with it came a new algorithm that wouldn't touch anyone's files, but couldn't track as well.

A couple weeks ago, I added AFT to Amarok 2's SqlCollection.  Enjoy, everyone -- statistics, lyrics, and the playlist are already supported, with support for stored playlists coming eventually.  But there's more.

Fast forward to today (okay, two days ago).  I'm taking a shower -- Wade does insist that there's something about showers and KDE coders -- and I had a thought, which was essentially: there's absolutely no reason why Amarok 2 can't use a UID inside a file, if one exists, for superior tracking, and if not, generate a read-only type for normal tracking.

So I created a utility that is built and installed with Amarok 2.  It's called amarok_afttagger, and it will write UIDs into your files, using a class ported from MetaBundleSaver and called SafeFileSaver to ensure that files are not overwritten/interleaved, even if you run the process twice or three times at once.  It optionally supports recursion if you want to pass in directories, and it can also remove UIDs from your files if you like.  Right now it supports MP3s only, but Vorbis and FLAC support will be coming soon.

I've tested it extensively.  I've added UIDs to files, removed them from files, regenerated the ones in files, over and over, and still everything is cherry.  And Amarok 2, when it finds these files, can do some awesomely robust file tracking.

I encourage people to give it a run on their MP3s and check it out -- if you're worried by all the Dark Ages info up above and don't have faith in the implemented solution, back up your files first, or operate on a copy of them, until you're satisfied it won't harm your files.  And if you still don't want to do it, you can enjoy the less awesome but still awesome power of the non-embedded UID file tracking.

Now, I promised this would talk about a possible KDE library.  I'll eventually be submitting the SafeFileSaver class for hopeful inclusion into kdelibs, so that any application that is worried about data integrity and needs to write to a user's files can take advantage of it.  It's very simple to use -- you simply give it a file path, and then operate on the file path that's returned to you when you call prepareToSave(), instead of the original one.  When you're all done, you call doSave() and it will perform the necessary functions.  That's it.

Hope this has been enjoyable, and enjoy AFT in Amarok 2.  Play with it and be amazed.  Use amarok_afttagger on your files and be even more amazed.  More information is available here: http://amarok.kde.org/wiki/AFT



Continue reading "Amarok File Tracking"

QtScript Bindings

If you've been following Peter Zhou's blogs, you know that he has been implementing QtScript support for Amarok. Probably the neatest thing we did is give access to almost the entire Qt API via the QtScript Binding Generator from Trolltech Labs. It uses technology from QtJambi; if you have Qt 4.4.1 and were wondering why Amarok gives a bunch of MetaJavaBuilder errors, this is why. (The bindings are disabled for Qt 4.4.0; we'll bump the Amarok dependency once 4.4.1 is more widespread).

I do think that the QtScript API is probably the most difficult Qt API to get the details right on. Your mind swirls with QScriptValue, QObjects and QVariants. But it is also quite powerful.

Since I had been sending the generators creator Kent Hanson emails regularly, I thought a mailing list would be a good idea to make it more public and useful. Join qtscript-bindings for discussion on the QtScript bindings in general. Kent also created a bug tracker and a Git repo. I created a mirror of it on repo.or.cz and posted the changes we've made to our SVN copy.

The beginnings of documentation for Amarok scripting are available and Richard Moore started a general Techbase article.

Console and Unnamed HTTP Server

The first script I created was an "irb" for Amarok's QtScript environment. This is available with Amarok SVN now, the "Amarok Script Console." It's quite handy to test out QtScript or to even test out the Qt API.

I've been working on a web control application for Amarok 2 using the new API. Using QTcpServer and QHttp, I have created a web server that should work well enough for what I'm doing. Now all that's left is the "little detail" of the HTML interface; I've been tinkering with qooxdoo, a very fancy JavaScript API.

One of my first sizable Amarok-related developments was to create the first kde-apps Amarok script in 2004 using Korundrum. So now its full circle.

Some Blog

The google news catcher sent me an indirect link to this Time-Warner blog: 3 Linux Apps That Make Me Hate Windows. He cites Synaptic, Compiz and Amarok. As much as you hear people gripe about package management on Linux, I really do think its one of its best features. Certainly from a security standpoint: going to a random web site and installing software just isn't something You Do on Linux, and I think thats for the best. And of course, it goes without saying that I agree Amarok is the best media player.

Everyone have fun at aKademy!

Suppose you're really into music created around the "summer of love" in 1967. Its easy enough it create a filter so you only get music from 1967. We could do that in Amarok 1, but that excludes a lot of music around that period that's just as significant.

Maybe you could do something like asking for everything that's recorded after 1960 but before 1973. That's better, but it's still not really what you mean when you say around 1967. You would prefer tracks closer to 1967 than farther away.

This is where "fuzzy biases" come in. The goal with fuzzy biases, is create a playlists that approximately match a value. Generating biased playlists, is always a question of probability distributions. What we are really trying to do here is generate a playlist that fits normal distribution bell-curve.

Like this:

The horizontal axis is the year, the vertical axis is the probability of getting track of that particular. So the nearer to 1967 the track is, the better chance of it ending up in our playlist it has.

Ok, another example.

I really just want to listen to some good straight up pop right now. No eleven minute epic folk ballads, no classical, no post-rock, just tight catchy songs. So I make a fuzzy bias to find songs that are about three minutes long.

Great. That's a pretty good mix, and I can refine it later with other biases.

The fairly vague "Strictness" slider indirectly controls the standard deviation of of the distribution.

It looks a little like this:

How is this different than the old fashion method, just specifying a pair of strict biases?

To get all mathematical on you, that creates a playlist that matches a uniform distribution.

If you've never taken a statistics class and didn't follow any of this, let me summarize:

1. pretty curves > boring rectangles.
2. Apparently a math degree is actually good for something.
3. Mom, you owe me an apology.
   

whatever happened to the rock and roll?
Originally uploaded by johnnyalive.

Paul always does sweet little graphs to show interesting stuff. Since everyone in the Amarok team felt that development really sped up in the last weeks/months I wanted some proof of that mainly to show it off and to find out where it came from. So I asked Paul to help me with that by doing what he does best. And only a few hours later he presented the results. If you haven’t read it yet you should do it now before reading the rest of my post.

Impressive, right?

So now that Paul did his part I should probably do my job and explain why this is happening

There are several “sources of developers”:

• Google Summer of Code: With 6 of our 7 students (Alejandro, Casey, Daniel, Daniel, William, Peter) doing an excellent job they really help getting things done. You rock!
• Season of KDE: Teo is working on his SoC project (mass tagging) without sponsorship from Google. He is doing a great job. Two others are starting to work on another project right now. You rock!
• KDE BugSquad: Edward started triaging bugs for us during the Amarok bugday and is now starting to help with development. He already made a very impressive start. You rock!
• Oldtimers: Our core developers are doing a lot more lately. On the one hand they help new developers getting used to Amarok development and give them a hand when they have trouble with stuff like the buildsystem. On the other hand they seem to be a lot more motivated to get Amarok 2 ready for release now that we have the alpha releases out of the door and things are starting to fall into place. You rock! (But you know that right? ;-))
• Other contributors: A few new people showed up in the last few days and already presented promising results. I hope you all stick around. You rock!

So the next question is: Why are more people interested in Amarok 2 now than they were say 2 months ago. The reasons I can see are:

• With the release of KDE 4.1 it became easier to start developing on Amarok because the hurdle of compiling KDE from trunk was gone.
• With Neon a lot more people could give Amarok 2 a try without compiling it from SVN. (Which also helped non-dev team members _a lot_.)
• The release of alpha 1 and 2 made it a lot easier to try Amarok 2 with distro packages and gave the signal “We have something we think is worth testing now”.
• A lot of very positive reviews in the press.
• People actually start to understand our vision for Amarok 2 and want to help making it reality.

Last but not least: Developers are motivated by:

• Very positive reception of the alphas in the press and among users.
• A lot of bug reports that show that users are caring about what we do and want to help us improve as much as possible until the release of the final 2.0 version. Among those bug reports are a lot of junior jobs which makes it easy to get started with a small task and get used to everything.
• Actually switching to Amarok 2 as their main player without big problems.
• Development being in a very exciting phase, i.e. we left the really hard start behind us where we literally had no new blood at all for a very long time (for reasons see above) and are not yet in boring maintenance mode.
• The frameworks actually start to pay off.

It is pretty interesting to see how most of this, if not all, can also be applied to KDE 4.1. Let’s see if we can get some nice stuff put together at Akademy to prove this

Exciting times and more of them ahead of us! Now is the right time to join KDE development (and any other non-dev part of KDE of course).

The ball has been dropped by me - dropped hard - during the past several weeks. First, I was stumped for a week and a half by the glib+qt fiasco, then my development machine’s hard drive shuffled off the mortal coil. Replacing it took a solid week, and when it finally arrived I installed Gentoo. Two days later, the finally install completes as I’m frantically throwing my life’s possessions into a car:

• clothes
• 2 laptops
• 1 Target desk (retail $50)
• assorted books
• 1 blow-up air mattress

Fast forward through seven hours of me hurtling down the interstate at not-so-safe velocities, and here I am, pardoning my recent idleness as my flight to Paris boards at gate D32. Not accomplishing much over the past several weeks suddenly doesn’t seem so bad: I’m going to Europe! There is a week long hack-a-thon at Akademy; I’ll catch up then.

A bientôt!

So MTP file management (copying/deleting) has gotten implemented, and works well on all 3 devices I tested on. Still a lot of polishing left to do as far as interface goes, and some threading to not stall Amarok at key points, and it should be good to go. One thing I'm having issues with is copying files directly from an MTP to an iPod and vice versa, but will investigate this later as this is a bit more advanced.



So, I had a bit of an epic struggle with a few things over the last day or so. See, libgpod can only retrieve covers in the form of GdkPixbuf structs, but so as to not force the GdkPixbuf dependency on people, they return it as a gpointer which you can then choose to cast if you want to use GdkPixbuf. Sounds great, right? No problem...

... except for having CMake pull in the dependency. So as it turns out, there's no built-in module for gdk-pixbuf library. So, I decided to create my own as I did with libgpod, except when I pulled it in, a certain function wasn't present. Odd... hm. Well as it turns out, this function is only present in the gdk-pixbuf library that resides in gtk. Great! There's a CMake module for GTK, all should be fine this time, yes? No. The GTK module in CMake pulls in GTK1, and gdk-pixbuf is in GTK2. So I end up modifying the gdk-pixbuf module I made before, learning lots about CMake along the way, and finally get it compiling.

Long story short for the next part, the README in libgpod didn't really work for me for setting up SysInfo for my iPod, and I accidentally tripped on a feature from the old Amarok which set it up right, after I modified some permissions. Wonderful, yeah?

Wrong! Turns out that iTunes and libgpod handle covers in two different ways, and so I have to cater to both of them. This turned out to be a bit of a pain, but at last, I finally got a size-distorted but correct solution:


The m-flo cover was set by me using libgpod via Amarok, and the Maná cover was set by iTunes. I'm going to fine-tune the sizes later, and all should be peaches and cream.

That's all for now. One note though about the interface, which right now is either non-existent or bad: likely going to be making an applet which does all the fun stuff that A1 did for media devices, including: connect/disconnect, % free space, possibly a queue, and if supported, even % battery level! That however, is a ways away from coming true, but do stay tuned.