Posts Tagged ‘kde’

KDE 4.2 brings the MySQL server to the desktop

If you’re using Fedora 10, and are a KDE desktop user, you’ll notice that your latest KDE 4.2 update, requires having a local MySQL server installed. This is due to Akonadi, part of the KDE PIM packages, that now rely on MySQL as a default server, for storing PIM data. Just a few months ago, I mentioned the news that Amarok 2 will also use MySQL as a default database.

Akonadi uses MySQL mainly as a cache, not as a data store. This is something that Debian users will also see. Eventually, anyone with KDE 4.2 will see the requirement to have a MySQL server installed. If you already have a native installation of MySQL provided for by your distribution (maintained by RPM/DPKG), it naturally won’t be installing another copy – it just uses the system-wide version.

Not everyone is happy. Especially those that use netbooks, with limited disk space. Reading Reducing the MySQL 5.1.30 disk footprint by Ronald Bradford might help in that respect – there are ways to reduce up to 25% of the space.

However, from a MySQL perspective, and as a member of the Sun Database Group, I am happy to see the ubiquity of MySQL, on the Linux desktop.

For the technical folk amongst you, its worth looking at the akonadi spec file:

BuildRequires: mysql-devel
BuildRequires: mysql-server
# when/if akonadi grows support for other backends, consider splitting
# these similar to how phonon is done currently.
Requires: qt4-mysql
# not *strictly* required, but we need a functional default configuration
Requires(hint): mysql-server
Requires an available instance of mysql server at runtime.  
Akonadi can spawn a per-user one automatically if the mysql-server 
package is installed on the machine.
See also: %{_sysconfdir}/akonadi/mysql-global.conf

Amarok 2.0 uses MySQL

I’ve always been more of a GNOME guy, and when running Linux, I use Rhythmbox to play my music. However, Amarok 2.0 might just change that.

They’ve chosen their database – it is none other than MySQL. The release notes state:

Some features, such as the player window or support for databases other than MySQL, have been removed because either they posed insurmountable programming problems, or they didn’t fit our design decisions about how to distinguish Amarok in a saturated market of music players.

If you want to know why the decision was made, read MySQL in Amarok 2 – The Reality. It has a lot to do with the fact that MySQL can be embedded, and performs well. Its a generally useful read to see why SQLite and PostgreSQL was not chosen.

MySQL… powering the music of today!
(wonder as I may, if we will ever get any Enterprise customers, who make heavy use of Amarok over many computers, etc… – I’m thinking modern night clubs, lounges, et al)