KDE 4.1 Alpha 1 Is Out

The KDE Community is happy to announce the first preview for the upcoming KDE 4.1, due in late July. KDE 4.1 is based on Qt 4.4's goodness, bringing performance improvements, WebKit, widgets-on-canvas and other goodies. Also new is Dragon Player, a KDE 4 port of the codeine video player which is famous for its simplicity and ease of use. KDE 4.1 Alpha 1 ships with Akonadi, the new data storage framework for our beloved PIM applications. KDE-PIM will also see its first KDE 4 release with 4.1, but is not yet based on Akonadi. More planned and already implemented features can be found in the KDE 4.1 Feature Plan. The Plasma desktop shell has just undergone major surgery, so expect some additional breakage there.

Dot Categories: 

Comments

by Stefan Majewsky (not verified)

I guess that distributors will in 2009 stop to ship KDE 3.5 in 2009 (with the appearance of KDE 4.2 and KDE 4.3). KDE 3.5 will of course continue its life in long-life areas (LTS and enterprise distributions), four years are realistic here.

If you do not believe this, take the following into account: If the KDE 3 -> KDE 4 transition takes as long as the KDE 2 -> KDE 3 transition, it would have needed about three to five years for KDE 2 to disappear from distributions. In this case, KDE 2 would have been shipped until 2007.

The big news on Slashdot would then have been: "Kubuntu 7.04 to abandon KDE 2.2.205" (sounds like a legacy kernel version number).

by Ian Monroe (not verified)

Amarok and K3B have never followed the KDE release schedule.

KDE3 apps run on KDE4 fine, OpenSUSE made sure of this, so I doubt that's an issue.

by Mark Kretschmann (not verified)

Amarok 2 depends on KDE 4.1, and it's progressing nicely.

by Stefan Majewsky (not verified)

By the way, does a release schedule exist for Amarok 2 (I could not locate one in the Amarok wiki), or is there at least an estimated release date? How far have you already come (not only on the optical, but also on the technical side)? There is not much to see about Amarok 2 in the blogs, except for nice screenshots.

by apokryphos (not verified)

Please don't mention this out of context, because in fact there were several reasons given -- the others being that we don't want a 10/11 month release cycle, but an ~8 month one, that 4.1 will not fix all known problems, and that other projects depend upon us adhering to our general release cycle (like SUSE Linux Enterprise). And yes, the chance of KDE 4.1 being delayed cannot be ruled out as an impossibility yet, even if we hope it will not happen.

by mac asylum (not verified)

from the announce:
"KDE 4.1 will also be available on Windows, Mac OS X and OpenSolaris. The ports are not yet completely finished yet, but good for a first preview nevertheless"

just yesterday I installed the mac version from mac.kde.org which is from january actually and not even good for a first preview.
I think the mac/win editions shouldn't be promoted in such a way because I can distinguish between a preview and a released version but I'm not sure if the average mac/win user can

by anon (not verified)

perhaps it is just a case of wording. To me a preview just means a glimpse at what is coming. To me I would never use anything that is advertised as a preview, because that is not a stable product, but a glimpse

by Chaoswind (not verified)

I think, the average mac/win-user won't find his way to news about an alpha-version of an unix-environment.

by Morty (not verified)

If you installed a version from january, it's obviously not KDE 4.1(alpha 1 or anything close to it). You are basing your comment about preview on ancient version not related to the anouncemet at all.

And it sould have been rater obvious since the release anoncement is dated April 29, that it does not describe a version thats over 4 months old.

If you are going to argue if it's a good first previev or not, the minimal requirement should be to base it on the version described as such.

by illogic-al (not verified)

Well in that case, it doesn't work any better now than it did in january.
Happy now?

by fred (not verified)

Pretty sad :(, but only limited developers have Macs, 99% of them still loyal to Linux. I guess even KDE-windows team has slightly more people.

P.S: 99% is only a rough number :D

by hmmm (not verified)

Good thing, too. Free Software platform should always remain the focus.

That, and more windows and mac users is good only if it brings in more devs.

by Morty (not verified)

Are you basing that on having tried KDE 4.1 Alpha 1 on Mac OS X, or are you trying to be funny.

In any case the parents statement makes just as much sense as claiming how unstable XP was when it was released, based on testing windows 98.

As discussed here:

http://techbase.kde.org/index.php?title=Projects/PIM/Akonadi

akonadi will run its own mysql-server instance in every workstation host,
which sounds quite overkill if you ask me.

Is this really going to remain so?

Amarok2 when launched may run mysql embedded too.

Well, it makes sense, mysql is a reliable and fast storage method for data...

> Well, it makes sense, mysql is a reliable and fast
> storage method for data...

...with that you also get constant breakage in their
binary format - which actually is okay as you never
should not upgrade RDBMS without dump+reload
cycle and that will cause that you can't do regular
backups from your /home anymore.

Not to mention that you can't have NFS homes anymore,
even I have that at home office, not to mention companies.

This is yet-another-piece of bloat to the desktop,
when kde4 with new qt was supposed to run faster than kde3.

Don't get me wrong. I've been looking forward to get
Akonadi and think it's the killer feature of kde4, but full
mysql-server instance in workstation sounds too heavy and
comes with all kind of headache.

Don't worry, KDE4 is being optimized. Of course this is based on what profiler reports as CPU hog, not just on 'sounding too heavy'.

> Of course this is based on what profiler reports as CPU hog,

I wish it would be just buying-more-cpu-solution.

But this is going to introduce complete new set of problems
and force to create in-house solutions to overcome those.

What about shared NFS homes (if those would somehow magically
work), and multiple KDE versions in big enterprises? Not everybody
can upgrade in one night and I thought KDE was trying to be
more appealing for http://enterprise.kde.org/ right?

Those sometimes incompatible dotfiles cause already trouble,
I can imagine what the mysql binary blob does.

Later optimizations are not always effective if the base design is to heavy-weight. So general considerations are not completely out of place. Akonadis multi-process client-server architecture indeed sounds to heavy for my Eee PC.

Hmm, I don't think that makes much sense at all actually, given that Soprano and Nepomuk will be used in Amarok2, and that these essentially provide a triple store for data.

Not just yet as far as I've been reading on the IRC for amarok. A2 will be launched with its own collection scanner and database, I believe they will be integrating step by step with those technologies.

From the same link:

"No. There has to be one Akonadi server instance per user. *However, it is possible to use a shared database server*." [emphasis mine]

So I suspect that the FAQ item (to which I'm guessing you are referring) :

" Do I need a running MySQL server?

No. Akonadi starts it's own local MySQL server. All you need is having the 'mysqld' binary installed at runtime (usually found in the mysql-server package of your distribution)."

is wrongly phrased and should be:

"No. *If* Akonadi detects no shared server, *then* Akonadi starts it's own local MySQL server. All you need is having the 'mysqld' binary installed at runtime (usually found in the mysql-server package of your distribution)."

This is speculation on my part, though: it would be nice to have one of the PIM fellows weigh in :)

by Kevin Krammer (not verified)

The FAQ is probably not fully up to date.

I think someone already contributed code which allows postgresql to be used instead of mysql and code which allows to use a system wide DB daemon instead of a user-local one.

Assuming my memory is correct on these items, it should be possible to use another database engine in case the other two cannot be used, as long as it has the necessary features, e.g. transaction support.

> I think someone already contributed code which allows postgresql
> to be used instead of mysql and code which allows to use a
> system wide DB daemon instead of a user-local one.

I don't see how postgresql would solve those listed problems.

I would understand sqlite somehow as it's known to be quite
simple and even its binaries are named with version (at least
in fedora), thus less likely to cause version related problems.

Anyway, why that STORAGE is needed anyway? I thought Akonadi was
supposed to provide API to actual storage (IMAP,LDAP,Exchange):

http://pim.kde.org/akonadi/

...well, I guess I thought wrong.

by Kevin Krammer (not verified)

> I don't see how postgresql would solve those listed problems.

It means that the database access is not mysql specific, thus other database backend options could be added as well, assuming the respective technology supports all the required features.

> Anyway, why that STORAGE is needed anyway?

Akonadi needs to store the mapping of its IDs to the ones used by remote storage systems and some place to store metadata like MIME types, cached data, etc.

> I thought Akonadi was supposed to provide API to actual storage (IMAP,LDAP,Exchange)

Yes, this parts are called resources.
Akonadi clients, e.g. a mail client, gets the PIM data from Akonadi server, which in turn requests it from the resources unless it already has it (cached data).

One advantage of this approach is that resource developers do not have to re-implement caching functionality multiple times, e.g. the user can tell Akonadi to cache only headers of a local IMAP server but to cache full emails from a remote one. Both cases can be handled by the same resource code, without its developer having to think about caching at all, e.g. where to store data, in which format to store it, etc.

> ...well, I guess I thought wrong.

No, you're correct, but it takes a while to understand how all the pieces work together.

Shock! OK now that I'm calmed down, how about sqlite? I hope the MySQL server is not happening. If it is, I think we should see some figures to back up how much lighter it is than other methods.

http://techbase.kde.org/Projects/PIM/Akonadi#Akonadi_FAQ

Having said that I hear that latest versions of sqlite have much better concurrency behaviour. Unless need for transactions blocks it, it should be possible to use that for a smaller footprint.

It's also worth pointing out that the Akonadi team are talking to MySQL via their community manager to optimise MySQL for this usage.

by T. J. Brumfield (not verified)

I'm worried that an internal packaging of MySQL will be really wasted, especially if Amarok is doing the same. Will KDE 4.2 users be running two seperate engines of MySQL on their desktop?

I'm curious why they didn't go with sqlite, and whether it is possible to tie together various internal uses into one engine. For instance, Firefox uses sqlite. I'd rather have the database server running once.

by Sebastian Sauer (not verified)

> Will KDE 4.2 users be running two seperate engines of MySQL on their desktop?

I don't know if they like too. They can but don't need to :)

> I'm curious why they didn't go with sqlite

As the akonadi FAQ says, SQLite doesn't handle concurrent access very well yet. But I am sure that once it's done, we will also see a SQLite-backend since SQLite rocks :)

by Kevin Krammer (not verified)

> I'm worried that an internal packaging of MySQL will be really wasted

I am not sure what you mean with "internal packaging", but just in case you mean shipping MySQL as part of the Akonadi package, we won't do that.

> Will KDE 4.2 users be running two seperate engines of MySQL on their desktop?

As far as I know Amarok is more likely to use the embedded variant of MySQL, however in the case that they are also going to use a separately running MySQL daemon, it can be shared.
I.e. Akonadi's server config can be adjusted to point to a different database daemon and won't start its own.

by T. J. Brumfield (not verified)

Thanks for clearing that up!

1. How backups should be taken care as full RDBMS
should not be backed up from filesystem binary files?

2. What will happen to KDE users who use NFS /home?

3. Will this make cross-version + networked /home
use more complex and incompatible? Big sites
with large installations will need time to upgrade.

Kevin Krammer on Wednesday 30/Apr/2008, @12:51
> It means that the database access is not mysql specific,
> thus other database backend options could be added as
> well, assuming the respective technology supports all
> the required features.

and when the Akonadi currently requires more than sqlite
can provide, it means a) full-featured RDBMS b) above
problems.

> Thanks for clearing that up!

I think nothing is cleared in this matter yet. Preventing
NFS home users from upgrading to KDE4 is not a small issue.

by Kevin Krammer (not verified)

> How backups should be taken care as full RDBMS should not be backed up from filesystem binary files?

Backing up the actual database files can be an option, some database systems even have a special mode of operation for that.
Anyway, we are working on that.

> What will happen to KDE users who use NFS /home?

One possibility I could think of is using a local database location, e.g. /tmp/akonadi-$USER

Since the PIM data is always loaded and stored through resource agents, the database basically just contains Akonadi internal state data and cached data.
At startup this would behave similar to the current situation, where data is loaded from its actual location right into the applications, but the users still get all the Akonadi features during runtime.

> Will this make cross-version + networked /home use more complex and incompatible?

cross-version setups usually already use different directories, e.g. different .kde directories to avoid version conflicts, they can do the same for Akonadi directories.

> and when the Akonadi currently requires more than sqlite can provide, it means a) full-featured RDBMS b) above problems.

I am afraid I don't understand the intention of this statement. If sqlite does not yet provide the required features it is obviously not a candidate, but this doesn't imply needing a full-features RDBMS, any database available through a QSql plugin with the required feature set can be used, independent of how it is implemented.

> Preventing NFS home users from upgrading to KDE4 is not a small issue.

We are not going to do that and we quite some time available to work on solutions since KDE 4.2, the version when KDE PIM apps will have been ported to Akonadi, will be release around January 2009.

>> and when the Akonadi currently requires more than sqlite can provide,
>> it means a) full-featured RDBMS b) above problems.
>
> I am afraid I don't understand the intention of this statement. If sqlite
> does not yet provide the required features it is obviously not a candidate,
> but this doesn't imply needing a full-features RDBMS [..]

He obviously questions your definition of "required". Are the "required" features excluding sqlite really mandatory for Akonadi's purpose or are they only convenient? (No question, "concurrency" in some way is mandatory).

by Kevin Krammer (not verified)

> He obviously questions your definition of "required".

Ah, ok.
Since I have not been working on that part of Akonadi myself, my guess is that most these features are required in the sense that it would not work without and some in the sense that it would be a lot of work, e.g. basically creating workarounds around limitations in the software stack below.

I have just browsed the sources via websvn and found this interesting comment to the Akonadi::DataStore class

" Use @c General/Driver to select the QSql driver to use for databse
access. The following drivers are currently supported, other might work
but are untested:

- QMYSQL
- QMYSQL_EMBEDDED
- QSQLITE
"
After all, you seem to use throughout the QtSql module and SQLite is clearly supported by this framework.

by Kevin Krammer (not verified)

While it is true that the intention is to be able to use any database backend supported by QSql, the API docs comment is a bit outdated.

Currently only QMYSQL is well tested and I think there is working but less tested support for QPSQL.

Of course anyone testing new versions of sqlite and the associated QSql plugin is welcome to let us know when we can add it as well.

Btw, FAQ will be updated to address the questions which came up here on the dot

Kevin Krammer on Monday 05/May/2008, @00:21 wrote:
> Currently only QMYSQL is well tested and I think
> there is working but less tested support for QPSQL.
>
> Of course anyone testing new versions of sqlite
> and the associated QSql plugin is welcome to
> let us know when we can add it as well.

Okay, thank you for the clarification in this matter.

Considering that:
- rdbms will be mandatory requirement
- there will be more than one supported backend
- it cannot be run over NFS /home
- /var/cache/akonadi should be used

few questions pops into mind:
- how will this be handled in distro packaging and deps?
Requires: some-heavy-rdbms (actually a distro problem)

- how the configuration will done, assuming that user has
already selected one backend and that selection has been
configured into kde dotfiles which might be shared with NFS between
hosts? akonadi will depend on mysql-server,postgresql-server,etc?

- will akonadi be able to switch the configuration by itself and
start over the cache if it finds a new backend?

- will there be any *real* data or just cached stuff?
assuming that in one host user had mysql and next host a postgresql,
akonadi would then start caching over with postgresql. Would data
be lost?

- if a networked, central backed is used, how the configuration will
be done to find it, manually?

by Kevin Krammer (not verified)

> rdbms will be mandatory requirement

At the moment it looks like none of the alternatives (or at least not the versions that have been tested with) can provide what is needed. Since the alternatives are continuously enhanced as well, any newer version might

> /var/cache/akonadi should be used

For user specific data?
No, that is what $XDG_CACHE_HOME would be for.
We actually use $XDG_DATA_HOME, since the database can include additional metadata, e.g. application specific annotations.

> how will this be handled in distro packaging and deps?

I guess for now they will add a dependency on their mysql package.

> how the configuration will done

$XDG_CONFIG_HOME/akonadi/akonadiserverrc INI-style config file

> will akonadi be able to switch the configuration by itself and start over the cache if it finds a new backend?

I am not sure what you mean by "by itself". If you change the configuration to a different backend or different location and restart Akonadi, it will initialize the backend/location like on every first startup and retrieve PIM data from the resources whenever told to do so by either a applications or cache policies.

> will there be any *real* data or just cached stuff?

There can be additional metadata, like threading information discovered by some analysis tool, application specific annotations, etc.
For PIM data (contacts, calendars, emails, etc) there is always a "host" resource

> if a networked, central backed is used, how the configuration will be done to find it, manually?

See above, akonadiserverrc in $xdg_config_dirs/akonadi, see also http://standards.freedesktop.org/basedir-spec/latest/

You seem to be arguing for sqlite, but you know it can't be stored on a NFS partition right (like any database really; I consider this to be a NFS problem)?

> You seem to be arguing for sqlite,

Other projects have managed do with that and it's
not that bloat, as the name says. It doesn't
have net interface, user management nor other
complex features which are not needed in akonadi
either. It's not that sexy project that would break
KDE in every release like mysql does.

If devs tell that there is no other way than mysql
to acehive this, I'm personally fine with that.

But if there is, I think we're asking for trouble
for wrong reasons.

> but you know
> it can't be stored on a NFS partition right (like
> any database really; I consider this to be a NFS problem)?

$ sqlite3 test.db
SQLite version 3.4.2
Enter ".help" for instructions
sqlite> CREATE TABLE fish (i INT, a VARCHAR(8), b VARCHAR(8) ) ;
sqlite> INSERT INTO fish (i,a,b) VALUES (1,'pike','tasty');
sqlite> SELECT * FROM fish;
1|pike|tasty
sqlite> .quit

$ sqlite3 test.db
SQLite version 3.4.2
Enter ".help" for instructions
sqlite> SELECT * FROM fish;
1|pike|tasty
sqlite> .quit

$ pwd
/home/tuju
$ mount |grep home
server:/srv/home on /home type nfs (rw,soft,intr,addr=172.16.1.1)

It can. The locking is the one that *may* cause trouble.

http://www.sqlite.org/faq.html#q5
> But use caution: this locking mechanism might not work
> correctly if the database file is kept on an NFS filesystem.
> This is because fcntl() file locking is broken on many
> NFS implementations.

Client's probably will have recent Linux NFS anyway as they will
be running fresh distro with KDE4. The question is what the server
provides, some enterprise filer might not have all the bells and
whistles.

Anyway, as long this *really* is about caching, it should be put
under /var me thinks.

by Abu.Assar (not verified)

... is available here : http://home.kde.org/~binner/kde-four-live/
based on openSuse.

by anon (not verified)

does it work and what version Opensuse is it 10.3 or 11? OpenSUSE's 11 beta 1 live cd's don't install due to bugs.

by binner (not verified)

It's based on openSUSE 10.3.

by anon (not verified)

thanks, I'll wait then. KDE 4 in 11 looks so much better than the raw KDE packages. The Opensuse tweaks are so much better looking.

by Gerry (not verified)

Alas, following 10.3 update, I get kicked straight out of KDE4.1 Alpha back to log-in. Suppose I'll just have to wait.

Not complaining, just instant-gratification deficient :(

by From Brasil (not verified)

Hy, thanks for this information.

I downloaded this LiveCD and I can say: "it's really a great upgrade over the last LiveCD I got with KDE 4.0

Now it's possible to use the system without hanging or freezes, this is impressive. I got some issues, but all related with the LiveCD system and the small amount of software packaged there. But the new KDE is great.

by Martin Fitzpatrick (not verified)

The alpha is pretty sweet and has me looking forward to seeing the finished 4.1. I've been using KDE4 as my main desktop since 4.0.3. I went on a bug-hunt for the first few weeks, but everything I reported was already fixed already. Now it's settled in, a few quirks and annoyances but it's not like I'd have to use 4.x if I didn't want to, is it?

Keep up the good work and thanks for all you've done so far! Much appreciated.

by Flavio (not verified)

Yeah, thank you so much, hackers! I'm still using 3.5.9 but will surely check 4.1 out. Keep up your incredibly good work! We love you.