Tuesday, December 2. 2008Avast, We Be Getting Slandered, YarPoisonous people. They exist everywhere, sucking the light and good out of things and repurposing them for all sorts of nasty activities. Like the rest of KDE, and the rest of the software world (both free and non-free) in general, the Amarok team has taken its fair share of abuse over the years. Normally I ignore it. However, today I got my KDE 4.0 Release Event talk twisted around in malicious ways and the blame placed right at my own feet. So I'm rising to the bait. The latest perpetrator of bile and venom is one Antal István Miklós. This I'm not going to pick apart all of the technical wrongheadedness he portrays with MySQL/e, Akonadi, and the capabilities therein -- Nikolaj posted a nice response to the blog, and the guy would be very well served to fully read my posting about mysqle (as well as many of the comments). Much of the blog can also easily be decoded as baseless, factless trolling ("amarok1.x is the slowest KDE3 program, if not it's surely in the top 3 slowest KDE3 programs"), and the-developers-don't-agree-with-me-so-they're-wrong syndrome. But I am going to defend my statements at the Release Event. Let me explain, up front, the format of my Release Event talk. I presented a short introduction to Amarok, for those that did not know it. I then stated some drawbacks we found with the KDE3 platform. With these drawbacks, plus a desire to go cross-platform like many other media players (VNC, Banshee, iTunes, etc.), we had considered the possibility of switching to a Qt-only architecture. But then, KDE4 comes along, with elegant solutions to our problems -- Phonon, Solid, Plasma, targeting multiple platforms, and more. Boom -- the thoughts of Qt-only go out of our heads, and we commit ourselves fully to KDE4. Far from a long series of complaints, it's a success story, showing how the benefits the KDE4 platform offer to us solved our problems, and how they could solve yours too. Apparently, however, it simply shows -- from Antal's blog post title, and probably because he hasn't bothered to watch past five minutes in -- how we just don't get KDE4. This may not be apparent to everyone, but Amarok was an early poster child for adoption of many of the Pillars of KDE. We are the only application, to date, that has embedded Plasma inside of our application (with our developers doing a large amount of work to make that possible). (Update: we are technically the first, outside of the plasma workspace, but there are others playing with that now.) Device detection completely relies on Solid (which is one reason Mac and Windows ports have no device support right now). And we have completely standardized on Phonon for our media engine. We've also had Oxygen team members working on our icons and our interface. It's hard to imagine ways for us to more fully integrate with KDE4 than what we are doing. We've gone for KDE4 whole-hog, and it's ludicrous to suggest otherwise. Picking out random Pillars that we don't fully integrate with (yet) does not mean that we are not KDE4-oriented. After all, right now we don't have a use for Marble (who knows? that could change) -- but does that mean we don't get KDE4? it just reminds me of one of the KDE4.0 release event, where a KDE dev complained that how KDE3 sucked, because they couldn't port Amarok to Windows, and KHTML had bad performance It'd be nice for Antal to realize that there is a difference between complaining, and listing drawbacks of a platform. (This doesn't really fit into how trolls work, of course.) Yes, I said that two of KDE3's drawbacks were that it made it impossible to port Amarok to Windows (and Mac) and that KHTML rendering was found to be slow. No, I did not say that KDE3 sucked. But there's nothing new here. It's not like Amarok was alone in wanting to port to other platforms. The Release Event had showcases of KDE4 applications running on both Windows and Mac. But Antal has this fixation that Windows and Mac are suddenly all we care about, taking an out-of-context "consider the majority" statement someone (he doesn't say who) made on IRC about some topic (he doesn't say what, only that it's vaguely somehow about performance): Using mysqle mostly benefits non-KDE4 desktops, because as I said earlier KDE4 will probably have a mysql server anyway, but isn't improving the KDE4 user experiance top release priority anymore? Is amarok on Windows on Mac more important than getting the best out of amarok on KDE4? I think Antal fails to realize that KDE is not just a desktop. Windows and Mac users that might be using Amarok are going to be using lots of KDE technologies in the process. Regardless of his mistake, there is certainly no evidence that Amarok cares more about Windows and Mac users, or thinks them the majority of our users. Speaking as a developer, I can tell you that the exact opposite is true. Antal also clearly doesn't realize that Akonadi is not a requirement of KDE to run (even if it's installed), and therefore the best Amarok could do would be to integrate with Akonadi, but not to depend or rely upon it. Maybe he kind of gets it when he says, my emphasis, "KDE4 will probably have a mysql server anyway" -- we can't rely on probably, or maybe. We need to use what works, always. He even contradicts himself: He begins with complaining, how slow was rendering amarok's context with KHTML, so it looks like performance matters in amarok, not that anyone forced them to use KHTML for rendering context... Make up your mind, Antal. You're right that no one forced us to use KHTML for rendering context, although WebKit wasn't available back then, and hooking into Mozilla was a non-starter. But you want us to be integrating with other KDE technologies...right? One last point: Jeff Mitchell the developer who spoke at the event that I was referring to, referenced KDE as a family, but where is the love now? The lack of communication between Amarok and the rest of KDE4(Akonandi) doens't seem to back up Amarok as being a family member. It is not surprising, given how little he understands of Amarok, KDE, and the integration thereof, that he thinks both that there is a lack of communication between Amarok and the rest of KDE4, and that he implies that Akonadi is the entire rest of KDE4. I've covered a small fraction of the untruths and inaccuracies in his post, but it's enough -- I've made my points. I love KDE, I have not publicly disparaged it, we Amarok developers are fully committed to the platform, and we are not putting the Windows and Mac ports at a higher priority than the *nix base. Any comments will be read, but I may decide not to post them. Trackbacks
Trackback specific URI for this entry
No Trackbacks
Comments
Display comments as
(Linear | Threaded)
Not commenting on the rest of it, but Amarok is not the only app to embed libplasma.
Besides the plasma workspace shell, which it was written for in the first place and so perhaps you don't count for that reason  , there's a nepomuk query builder. So there's at least one more.I know of a couple others that have patches and/or are playing with the same thing. Amarok was certainly the first non-Plasma-workspace shell application though =)
there goes aseigo, constantly trying to push us down.
see, we try for more integration and love but obviously it is not reciprocated...
i thought you got off on that stuff, Leo?
and here i was struggling to come up with inventive new ways to be hard on you ... and all you wanted was a hug. sniffHUGS
You know, since you mention the "we" and the "us" (whoever that might be), it would be nice to reveal your identity.
Leo who?
Its a Leo at London's Global University, sounds like ours. I'm guessing its some sort of plasma humor that we don't get.
I say just keep ignoring them.
Although I would prefer amarok to not have mysql as a dependancy, I mostly agree with the decision. Also, KHTML is pretty bad anyway and as soon as there will be a proper Webkit KPart most people will use that.
The reason the KHTML context based browser was slow wasn't because of anything wrong with KHTML. It was due to all the manual string manipulations required to dynamically generate the HTML and then render it, at a critical time in Amarok performance (between tracks). WebKit doesn't solve any of this. Plasma seems to.
I'm guessing you weren't so negative as Antal seems to imply. But then you go ahead and react to his blog as if he was basically correct about our reasons for switching from KHTML anyways.
I think in the end, requiring Mysql/e will generally be regarded as a Bad Idea (tm) a few years from now.
I've stated many times that apps much larger with queries much more complex make use of SQLite [http://en.wikipedia.org/wiki/SQLite#High-profile_deployment]. Clearly, covering up the root problem with a heavyweight database isn't going to fix unoptimized queries. I've seen you folks many times call for artwork and artists; perhaps finding an experienced DBA for advice should have been equally paramount. We all have unique talents and experience, and a DB expert would be authoritative here. Also, the dependency on MySQL will surely strike a nerve with many DB experts. You know your project is in trouble when the founder takes time to write in length about it [http://monty-says.blogspot.com/2008/11/oops-we-did-it-again-mysql-51-released.html]. The shortcomings of MySQL/e should not be scoffed at. Amarok crashing because of MySQL/e problems will be deja vu of Xine and the 1.x days. Amarok is and has been a great media player. Surely SQLite and/or SQLite+MySQL support could have been maintained until a Nepomuk backed could replace them both. Would the work load have been much different than the redundant effort of porting everything to MySQL/e? I don't understand why this is such a polarizing topic or why the devs are so vehement to call users "blathering idiots" because this is a controversial issue. I wish you guys would see the other side of the coin, but I doubt comments on a blog will help anything in the long run. So cheers to a successful 2.0 release, and thanks for proving many of the current KDE pillars!
Its not like we haven't asked for it. And its not like Amarok hasn't been out for 4-5 years, ready for some savant DBA to come be part of the team. We've had database people look at things, mostly Amarok isn't much like your normal database so they come in with some bad assumptions (why they'd need to be part of the team, not just a passing expert).
I suppose I "ported" to MySQL/e, it was basically no work. The main problem was all the compile-time issues, there was only a handful of SQL queries that to be tweaked. It wasn't the reason why Jeff called him an idiot, btw. I'm guessing it was the misrepresentation of what he was saying that set Jeff off.
Ian is right. We've had database people come and look at our needs many times before, and never given us anything useful before disappearing. We've had lots of people accuse of of bad schemas and unoptimized queries, but no one that has ever followed through and really analyzed what it is we need and what it is we are currently doing, and figured out a better way.
Saying that we found SQLite to be slower than MySQLe because of unoptimized queries begs the burden of proof -- not only that our queries are unoptimized, but that optimizing our queries would actually cause SQLite to meet or surpass MySQLe's speed (since theoretically this should speed up MySQLe too...) Until proof of both of these is supplied, you're just another voice in the chorus we've heard since the mysqle switch telling us that the speed difference is our fault, not SQLite's. I know all about high profile deployments of SQLite, both in the open-source world and in enterprise applications that I make use of at my job. I also know many of those where you sit there and wait for queries to finish (Firefox, for instance). Would a different embedded library prove to be faster in those applications? Hard to say. But certainly it's not lightning fast in all situations, and when you're searching your media library or scanning hundreds of thousands of files, we wanted this to be as fast as possible. It is also worth noting that, as has been explained before several times (but seems to be ignored quite often), speed was one of the reasons for standardizing on mysqle, but not the only one. Finally, an Akonadi collection will likely never replace a SQL collection...it will simply be another collection (just as many other sources of music become collections in 2.0).
I did not agree most of what the "Great Blog" said - most of it was trolling if anything and probably not worth a reply.
However, among all this one valid point is brought up - if in the future applications become a lot more data-intensive (pretty much a given with increased consumption of media like audio, video, photos, e-mails, IMs, etc.) and each user application handling different types of media decides to use its own "non-trivial" data backend, whether embedded or as a separate database server process, the resulting overhead from all of the combined applications' individual database processes may eventually hurt the user experience, especially on lower-end hardware (low to mid-range workstations, netbooks, certain other portable systems/devices, etc.). One solution to this could be a central set of library/APIs for handling all of the above data-related needs. This is definitely out of scope for Amarok and probably even KDE, but maybe something on the freedesktop level (?) that could have the following dual purpose: 1. Provide a single data repository for all application needs that choose to use it; and provide standard APIs and abstraction layer for manipulating data; 2. Remove programmers (such as those of Amarok, digiKam, Akonadi, Miro, etc.) from low-level data-oriented tasks so they can concentrate on their core competencies. Then those libraries themselves can be maintained to work with multiple database backends by the programmers qualified for those specific tasks. And, it would be up to the vendors (and/or advanced enough users) to set/change what data backend is appropriate for what device/platform and purpose. For example, a low-powered netbook or a smart phone could use the sqlite backend for handling relatively smaller amount of data, while a top of the line box could run a separate multi-threaded database server to index terabytes of different media through different applications. But in each of those cases your application (e.g. Amarok, digiKam, etc.) would interact with the data exactly the same way, no matter what the backend storage is used. I'm not sure how much of this is going to be part of the nepomuk implementation or if such a thing exists already and not in wide use for one reason or another; but I just thought I'd give my thoughts.
One of the reasons we decided to use MySQL is because Akonadi is also using MySQL. Sharing the same MySQL process with Akonadi would be fairly trivial.
But overall your idea is pretty awesome in the traditional "really big" sense of the word. C++ lacks an established open source true DB abstraction.
Your idea is pretty much what Akonadi strives to be -- shared backend storage that removes complexity from the end application.
It's a great idea, but it is hard to make one solution that fits all. Amarok requires complex queries on large data sets, and performance has been a problem on some backends. Plus, a solution that all KDE apps can use means that solution must be ubiquitous, whereas right now Akonadi is not. I do hope that we can have better flow between us and Akonadi in the future -- as I and Ian both said, it's one reason that we're using MySQL.
"I did not agree most of what the "Great Blog" said - most of it was trolling if anything and probably not worth a reply."
It's not the "Great Blog", it's the "Great Blog of a Web Developer" it's a name, that's all. I don't do trolling, this is what I have been seeing for a while, and what you have brought up is almost identical to what I have been trying to tell by this post all along, see my reply(the points where I try to explain again, what I meant), the portability explanation(which made a few people upset) was the closest answer, to the question("why mysqle?"), most people say that it's too big deal to create and set up a mysql user, and that's why they choose mysqle instead, with which I can't agree, because creating a mysql user and setting up a mysql connection, if you know that you could have one on localhost, can be fairly trivial, maybe even more trivial than using mysqle.
"because creating a mysql user and setting up a mysql connection, if you know that you could have one on localhost, can be fairly trivial, maybe even more trivial than using mysqle."
No! The entire point is that , for the user, the way we use mysql embedded is completely config free. The average user will not even know it is there. Everything is set up completely automatically by Amarok. Requiring the user to manually do any kind of setup of a database just to get Amarok running, automatically disqualifies 95% (some high percentage I just pulled out of thin air...) of potential users who either wont be able to or just cant be bothered when all they want is to run a music player. Now, for power users who already have an external mysql server running, it would be nice to offer them the ability to use that instead, something which mysql embedded will allow us to do, while still remaining completely transparent for most users.
"Requiring the user to manually do any kind of setup of a database just to get Amarok running, automatically disqualifies 95% (some high percentage I just pulled out of thin air...) ..."
I don't agree with most of what the guy says, but on this point - you can easily start a mysql (or even postgres, etc.) server process with your own configuration parameters programatically without any user intervention whatsoever. I believe this is how Akonadi works too.
"No! The entire point is that , for the user, the way we use mysql embedded is completely config free. The average user will not even know it is there. Everything is set up completely automatically by Amarok."
Ohhh c'mon, creating a mysql database user can be done automatically without config too, you could even create a little helper framework for it, that could check for a mysql database on localhost, then look for an existing "amarok" user, if exist, then generate a randomized name like "amarok353636" than it would tell the user that "Amarok has found a usable database on this system, do you want to use it?" If yes, than aks for the root password("of the system"), and amarok would automatically configure the whole thing, the user would never know what hit'em. Just before anyone would start thinking about writing down what a bad idea this is, think.... simmiliar stuff had been done already by the kubuntu people(or at least used), which goes something like this "Amarok can't play this music, because it has no codec for it, do you want Amarok to get it for you?" Yes/No, and then amarok asks for the root password, so it can "apt-get" the codec. 1 confirmation and 1 prompt for the root password, doens't sound complicated to me.
I think you need to learn the difference between sudo and database scripting.
Anyways, yes, it could be done. No, it's not a good solution. We can't expect users to know a database admin password (they may not even have rights, even if they have limited sudo rights, for instance to install packages). We also can't expect them to understand the difference between the two. And the whole point is not requiring that kind of setup.
I must agree setting up mysql stuff isn't that hard, as I got it done - but for really basic users it's way too much. As an intermediate option (until there is a good database solution in KDE) mysql-embedded is a decent solution, imho. Not perfect, but good enough for now...
End users don't compile their software from source. They don't even realize they're using mysqle unless they look at the output of "yum install amarok" and see mysql-embedded in the list of dependencies (and even that is only on distributions such as Fedora which ship a shared libmysqle - if it's statically-linked, it doesn't even show up in the list of dependencies). Setting up a MySQL server is actual work they have to do, mysqle just works.
Using the server autospawning hack Akonadi is using could work, but isn't really an improvement over mysql-embedded. Moreover, running a server in the background is acceptable for the Akonadi server (which is a server itself), but not so desirable for an application such as Amarok. And you can't really rely on Akonadi already running in KDE 4.1, maybe when more stuff is using it (i.e. in 4.2 or later), but not now. The use of mysqle was an annoyance mainly for us packagers, and in fact I would have much preferred if SQLite continued to be used (which also "just works" for our users and which was already packaged in all the relevant distributions), but now that we (in Fedora, but it's the same in the other major distros) have mysqle packaged (because Amarok 2 needs it) it's essentially a solved problem (and there wouldn't be much benefit in switching back to SQLite now). Most end users won't notice the difference because they install from binary packages and don't care whether they drag in sqlite or mysql-embedded as a dependency.
"Using the server autospawning hack Akonadi is using could work, but isn't really an improvement over mysql-embedded."
"Improvement" is a relative term. One of the advantages is that the separate server process provides you with less likelihood of you losing or corrupting your data. If the database process is "embedded" then the stability of the process embedding it is an additional consideration. On the other hand, a drawback could be that, if implemented properly, it seems as if the embedded method would require less system resources than a separate process. "Moreover, running a server in the background is acceptable for the Akonadi server (which is a server itself), but not so desirable for an application such as Amarok." I wouldn't hold any prejudice like that towards any application. As others have pointed out, there are plenty of users who are using Amarok with a separate database server process; even running on another box.
Hehe, I did appreciate the humor - everybody knows how Aaron always is complaining about Amarok being such a bad player in the KDE community. LOL
But serious, Jeff is totally right, this Antal guy is crazy. Who is he anyway? I remember the KDE Multimedia Meeting in the Netherlands. I feel this was the turning point, where Amarok clearly became part of the KDE community more than ever. Darn, we're sharing booth space everywhere, we work together on marketing, we join in grouphugs at Akademy, how more 'KDE' can you get?
"Aaron always is complaining about Amarok being such a bad player in the KDE community. LOL"
so anyone who is complaining about something about amarok is not right, "But serious, Jeff is totally right, this Antal guy is crazy" Right about what? You don't even know how to spell my name, and you say I'm crazy. But you are right, I am crazy enough to respond to pointless comments like these I guess. If you would took time, you'd realize that it's not about being part of KDE it's about the priority of giving the possibility of using the same 'database' server as Akonandi and maybe the possibility of compiling Amarok without what's not really needed. But I'm happy, that there are comments that list real pros/cons instead of just "defending" Amarok.
"so anyone who is complaining about something about amarok is not right"
Sigh.
I don't see how "this Antal guy" would be any more incorrect than "this Bush guy" or "this Mozart guy".
I loved Amarok, I love Amarok 2 even more and I'm confident that the Amarok team will do their best to make it an awesome product.
Don't listen to those people that want to complain just to look "important". Just remember: people who like amarok will use it and will only complain or point out problems in a constructive manner. Keep up the good work.
Thank you very much. Just that.
Sometimes it feels good to get some open minded feedback from a user ready to embrace the future Let's together make Amarok 2 a great product!
Apart from István's blunt style, he did make a valid point. I believe that this version of amarok is still under heavy development and everyone who compiles from svn knows that it won't necessarily work as expected.
The devs could have easily said that: we're working on it, cut us some slack. I would like to point out that I compiled amarok from svn and I use it every day.I like it (not as much as the kde3 version though, but I know this will change with time). I think that application developers should never be afraid of adding advanced options, specially in kde applications which are notorious for being powerful and configurable. Just ad an advanced button and let people configure Amarok to use their mysql server. I'll admit that I don't know too much about mysql embedded, but I had experience with SQLite (I know it can be slow). I understand the developer's decision of using something more powerful, but I believe that we shouldn't be afraid of confusing the (Windows/Mac ?) user. I know István (Antal as you call him ) personally and he is a dedicated kde user (dedicated amarok user too ).He can be harsh at times but he means good.Knowing him, his blog post fits the constructive criticism category. It wasn't a personal attack on Jeff or any other developer, it was just the typical frustrated user rant fueled by the fear of amarok becoming idiot-oriented. Calling him a "blathering idiot" wasn't too classy.Now was it ? There is no point in taking criticism as a personal attack.
"The devs could have easily said that: we're working on it, cut us some slack."
There would be no way for us to say "we're working on it, cut us some slack", because his criticisms are leveled (poorly and incorrectly) at decisions that have already been made, not that are currently in progress. "Just ad an advanced button and let people configure Amarok to use their mysql server." I don't know how many more times we can say that this has been in our plan all along. Certainly I made it quite clear in my earlier blog post about our decision (referenced in the above post). And it was a large factor in standardizing on mysqle, so that people could do this without us having to support multiple backends with various capabilities. This isn't what Antal (as I call him; not knowing his native tongue or nationality I made an assumption about his first name) was complaining about; he was complaining about us not reusing Akonadi's mysql instance and how this showed that we neither got nor cared about interacting with KDE, and (bizarrely) how it showed that we only care about Windows and Mac users. "I believe that we shouldn't be afraid of confusing the (Windows/Mac ?) user." Again with the Windows/Mac. I made it clear that Windows/Mac was not really a factor in our decision. Why do you (and Antal) insist upon bringing it up over and over? "Knowing him, his blog post fits the constructive criticism category." This wasn't constructive criticism. Constructive criticism implies an informed voice suggesting better ways to do things. Antal's post was uninformed, stupid, harsh, rabid, ranting, twisted, and idiotic. It was the very definition of a trolling post. "It wasn't a personal attack on Jeff or any other developer" Give me a break. The guy calls me out by name, misquoting me and taking my words entirely out of context multiple times while chastising me for not being a good member of KDE and implying that I am a hypocrite. It was absolutely a personal attack, and whether he started out meaning to do that or not doesn't make a difference. The end product is a very personal attack. "Calling him a "blathering idiot" wasn't too classy.Now was it ?" Who said I had to be classy? I could have made a very venomous post if I had wanted to. There, I'm just telling the truth. |
Amarok LinksCalendarQuicksearchCategoriesSyndicate This BlogBlog AdministrationWe Listen To... Powered by
|
