No more MySQL on my machine
I've said it before: I think MySQL is a toy, and I want as little to do with it as possible.
Unfortunately, since the KDE PIM suite depends on akonadi, which depends on a database, which was initially implemented against MySQL, not having MySQL installed on a Debian machine if you want to use the KDE PIM suite, for the longest time, wasn't even possible. Today it is, but it requires some manual steps:
sudo apt-get --purge install akonadi-backend-postgresql akonadi-backend-mysql- akonadictl stop rm -rf .config/akonadi rm -rf .local/share/akonadi cat > .config/akonadi/akonadiserverrc <<EOF [%General] Driver=QPSQL [QPSQL] Name=akonadi-wouter Host= Options= StartServer=false EOF createdb akonadi-wouter
Change "akonadi-wouter" for a suitable database name.
And now it should work. Note that this requires you run PostgreSQL system-wide and create a system-wide database in that server. It should, in theory, be possible to have akonadi run its own private PostgreSQL instance, much like how the MySQL backend does things, but a) I couldn't get that to work, and b) I don't think having each user run their own database server instance is a good idea to start with, so honestly I didn't try very hard.
And there, pronto! I now no longer have toy databases on my laptop. Word.
"b) I don't think having each user run their own database server instance is a good idea to start with"
Here are some downsides of making Akonadi use a system-wide database (be it MySQL or PostgreSQL):
The only upside I can think of: - may save a few bytes compared to the per-user database scheme
You are so wrong.
Upsides you missed: - Database tablespace is shared among all users with the system-wide databases, so data usage will be more economic. Of course this does not happen with MySQL, since MySQL is a toy and (unless you use InnoDB, which is not the default) does not do tablespaces. - Sysadmin can more easily tune runaway databases, which is much harder to do if you have 100 server instances each with their own configuration - Depending on implementation, a database server may detect that two databases have a similar layout and share cached optimizer plans among them. - Running a single database server instance means the database server has information on all reads and writes among all databases, so it can optimize better. This will improve performance.
Note also that I didn't say manually configuring akonadi is the right choice for everyone. Most of the above is moot if you're running a single-user system, anyway. But hey, I prefer doing things this way.
"It does not "mess" with the scheduler, it allows you to make the scheduler do what it's supposed to do." Really? Users A and B are pushing the same system to its limits. A and B are watching a video each, while B is also searching through his 500k emails. Consequence: A gets 33% of cpu and io time, B gets 67%.
"Sysadmin can more easily tune runaway databases, which is much harder to do if you have 100 server instances each with their own configuration" Tune for whom? For user A with his 100 emails a year, or for user B with his 100k emails a year?
"Depending on implementation, a database server may detect that two databases have a similar layout and share cached optimizer plans among them." I doubt there's any db server that does that.