The cake, it was a lie [LWN.net]

The cake, it was a lie

Posted Sep 24, 2012 23:22 UTC (Mon) by sebas (guest, #51660)
In reply to: A lesson by khim
Parent article: GStreamer 1.0 released

Mix & Match of KDE3 and KDE4 application is possible without problems. We've been doing that for a long time, especially as it took applications some time to port from Qt3 / KDE3 to Qt4 / KDE4.

Ironically, what we heard especially from the GStreamer team were complaints about the introduction of Phonon, which provides an abstracted multimedia API. It has backends for GStreamer, VLC and a few other things. The GStreamer developer's arguments were that Phonon is entirely unnecessary and that they would provide an API with guaranteed source and binary compatibility. If we'd listened to them, we'd be stuck with GStreamer as of two API/ABI versions ago. I've just talked to the developer who's working on the phonon-gstreamer backend, and he says the necessary changes have already hit master. We'll be able to provide the latest GStreamer to our users without them having to install new versions of their applications. It's a little tempting to now say "told you so". With today's knowledge and experience, I'd still call the collaboration between the phonon developers and the gstreamer team a success story, even if it wasn't up to a perfect start.

I'm happy about the 1.0 release. It's a sign of confidence and maturity, and a stable and mature multimedia framework is most welcome.

Congrats to the GStreamer team, have some cake. :)

to post comments

The cake, it was a lie

Posted Sep 25, 2012 3:14 UTC (Tue) by khim (subscriber, #9252) [Link] (10 responses)

Mix ∧ Match of KDE3 and KDE4 application is possible without problems. We've been doing that for a long time, especially as it took applications some time to port from Qt3 / KDE3 to Qt4 / KDE4.

Unported applications are less of a problem. It's when you run "latest and greatest KDE4 app, find out that it's removed half of the features you need and then try to fund KDE3 version of it only to find out that all configuration is destroyed you understand that everything is not as it seems.

We'll be able to provide the latest GStreamer to our users without them having to install new versions of their applications. It's a little tempting to now say "told you so".

Yup. Just one tiny question: how many of these applications actually benefit from a new versions of GStreamer?

It's not as if old versions of GStreamer suddenly go bad if new version is released. If you don't use new features then what's the point of upgrading?

The cake, it was a lie

Posted Sep 25, 2012 10:07 UTC (Tue) by jospoortvliet (guest, #33164) [Link] (4 responses)

Distro's don't want to have to ship the older versions as it is a lot of work to keep that all packaged.

The only KDE 3 app I still run is krecord, there's no port of that - works fine. Other stuff I've tried but the KDE3 apps are so much behind in functionality these days it isn't funny :(

The cake, it was a lie

Posted Sep 26, 2012 4:37 UTC (Wed) by khim (subscriber, #9252) [Link] (3 responses)

Distro's don't want to have to ship the older versions as it is a lot of work to keep that all packaged.

Yet another place where distributions are a problem not a solution.

The cake, it was a lie

Posted Sep 27, 2012 11:17 UTC (Thu) by renox (guest, #23785) [Link] (2 responses)

>Yet another place where distributions are a problem not a solution.

Given that this is in a discussion about KDE and that the KDE projects shipped quite a few immature technology at the start of KDE4.x enabling them by default which meant that if a user wanted a stable KDE desktop he had to find a distribution which disabled those things (or do the work himself) I cannot help but finding this sentence funny.

The cake, it was a lie

Posted Sep 27, 2012 13:05 UTC (Thu) by Jonno (guest, #49613) [Link] (1 responses)

>> Yet another place where distributions are a problem not a solution.
> Given that this is in a discussion about KDE and that the KDE projects shipped quite a few immature technology at the start of KDE4.x enabling them by default which meant that if a user wanted a stable KDE desktop he had to find a distribution which disabled those things (or do the work himself) I cannot help but finding this sentence funny.
Well, given that the KDE project explicitly told distributions to stay with KDE 3.5 for their stable releases and only offer KDE 4.[01] as an option for the unwary, and the problem you described resulted from distributions choosing to ignore the upstream advice, I cannot help but find your statement ignorant ;-)

The cake, it was a lie

Posted Sep 27, 2012 13:36 UTC (Thu) by renox (guest, #23785) [Link]

You assume that KDE4.[01] is the only one to have troubles, but PCLinuxOS still disabled Nepomuk much later than this..

The cake, it was a lie

Posted Sep 25, 2012 10:13 UTC (Tue) by sebas (guest, #51660) [Link] (2 responses)

It means that we don't have to support all versions of GStreamer since 4.0 (or stick with the very old ones, which had their fair share of problems), we can transparantly upgrade. That's something very important for distributions, and in turn for users. If apps would not benefit from a new version of GStreamer, the GStreamer team likely would've stopped working on it a long time ago. Old version don't suddenly go bad, they just get left behind by everything else moving on.

Your assumptions that KDE4 applications generally (paraphrasing) have less features than their KDE3 counter parts is a fallacy. We've made the UI smarter in many places, so they *look* less crowded. Most applications are *much* more powerful then their KDE3 counterparts. You'll surely find the odd app that has removed a feature, and often that happened for very good reasons. Overall, however, newer apps are easier to use, in the vast majority of cases more powerful and on top of that more integrated with the rest of the system (DBus, other standards we adopted with KDE4) and better looking.

The cake, it was a lie

Posted Sep 25, 2012 11:44 UTC (Tue) by jackb (guest, #41909) [Link]

Your assumptions that KDE4 applications generally (paraphrasing) have less features than their KDE3 counter parts is a fallacy. We've made the UI smarter in many places, so they *look* less crowded. Most applications are *much* more powerful then their KDE3 counterparts. You'll surely find the odd app that has removed a feature, and often that happened for very good reasons.

Perhaps you aren't including these two in your definition of "KDE4 applications", but the KDE4 versions of Kaffeine and Amarok lost a lot of features in the transition and only recently have begun to approach feature parity.

The cake, it was a lie

Posted Sep 25, 2012 12:08 UTC (Tue) by nix (subscriber, #2304) [Link]

You'll surely find the odd app that has removed a feature, and often that happened for very good reasons

... and sometimes it didn't, e.g. binding actions to sequences of more than one keystroke (something I used *heavily* in KDE3).

Benefits

Posted Sep 25, 2012 23:34 UTC (Tue) by Tester (guest, #40675) [Link] (1 responses)

GStreamer 1.0 offers lots of benefits for embedded systems and it was one of the key goals as older versions were very desktop centric in their design. But it also offers some nice improvements for desktops users, first and foremost, it has much better performance (see http://luisbg.blogalia.com/historias/71646). If you look at the graph, GStreamer 1.0 uses the least CPU, VLC uses the most. It is also easier to write dynamic pipelines, which should make applications like PiTiVi more stable and make it easier to develop new features.

Benefits

Posted Sep 26, 2012 4:36 UTC (Wed) by khim (subscriber, #9252) [Link]

I've asked very specific question: how many application which don't use GStreamer directly and get new version automatically when KDE upgrades benefit from said upgrade.

GStreamer 1.0 may be nicer than GStreamer 0.10, but then you have this abstraction layer on top of it which negates most of benefits. Smaller CPU usage is nicer, but are we really sure it's not then eaten up by Phonon? IOW: will GStreamer1.0+Phonon will still be less resource-hungry when you compare it with GStreamer0.10 without Phonon? Dynamic pipelines are great, but is it something old application can use without recompilation? And so on. What exactly is the point of upgrade (besides the ability to say that "yes, we now use shiny new toy under the hood")?

The cake, it was a lie

Posted Sep 25, 2012 8:34 UTC (Tue) by obi (guest, #5784) [Link] (19 responses)

So you're saying that porting once every 7 (!!) years, is more painful than writing and maintaining the abstraction layer?

GStreamer 0.10.0 came out in 2005. It's parallel installable with older and newer versions. During that time, KDE has been through many 3.x and 4.x releases, and had their own share of porting work. I find it difficult to understand how exactly you'd be "stuck with GStreamer as of two API/ABI versions ago", and what you gained by using Phonon. And while I admit I'm not very up-to-date with happenings in the KDE/QT world, isn't Phonon going to be replaced with QtMultimedia and QtMobility?

The cake, it was a lie

Posted Sep 25, 2012 8:57 UTC (Tue) by Cyberax (✭ supporter ✭, #52523) [Link] (7 responses)

>So you're saying that porting once every 7 (!!) years, is more painful than writing and maintaining the abstraction layer?

Yes, it is. I have 12 year-old games on my computer which I'd very like to be still playable.

The cake, it was a lie

Posted Sep 25, 2012 15:37 UTC (Tue) by hummassa (guest, #307) [Link] (1 responses)

Funny thing is, almost 20yo DOS games that do not play on W7 or even XP are probably playable in DOSbox on Linux :-D

The cake, it was a lie

Posted Sep 25, 2012 16:08 UTC (Tue) by Kit (guest, #55925) [Link]

DOSBox runs on Windows as well.

The cake, it was a lie

Posted Sep 25, 2012 17:04 UTC (Tue) by ovitters (guest, #27950) [Link] (4 responses)

Yes, it is. I have 12 year-old games on my computer which I'd very like to be still playable.

That is why they are parallel installable. Meaning: that is not a benefit.

The cake, it was a lie

Posted Sep 26, 2012 12:17 UTC (Wed) by sebas (guest, #51660) [Link] (3 responses)

Still, it means you have to ship an unsupported version of the library and framework, inclulding possible stability and security issues. I think /real/ backwards compatibility is a lot better than "you can keep the old version somewhere else on disk".

The cake, it was a lie

Posted Sep 26, 2012 21:05 UTC (Wed) by khim (subscriber, #9252) [Link] (2 responses)

I think /real/ backwards compatibility is a lot better than "you can keep the old version somewhere else on disk".

Actually this exactly how you achieve compatibility in most cases. When Microsoft completely redesigned DirectX in it's 10th incarnation they left DirectX dlls in place. When they shipped shiny new Windows 7 they offred MSVCRT.dll compatible with MSVC 6.0 (with some security fixes, of course). And so on.

This is the most practical way to achive compatibility - and the one which Linux Desktop developers explicitly rejected.

Note that this also diciplines developers, too. Hey, I want to bump revision of libfoo from 28 to 29 because I think function names are not clear enough — Sure! Go ahead. Just don't forget that now you'll need to backport all the security patches to all these 28 previous versions. Still want to go forward with that rename?

The cake, it was a lie

Posted Sep 26, 2012 21:48 UTC (Wed) by raven667 (guest, #5198) [Link]

> This is the most practical way to achive compatibility - and the one which Linux Desktop developers explicitly rejected.

This is sadly true, they do this because it does work if you limit the scope to just what ships from the distro you _can_ rebuild the world on a regular basis. Just because you can doesn't mean you should.

The cake, it was a lie

Posted Sep 27, 2012 13:08 UTC (Thu) by sebas (guest, #51660) [Link]

In most cases, maybe. KDE offers both ways, keep using old stuff, but new versions will also work.

Phonon for ever

Posted Sep 25, 2012 9:02 UTC (Tue) by rvfh (guest, #31018) [Link] (2 responses)

> So you're saying that porting once every 7 (!!) years, is more painful than writing and maintaining the abstraction layer?

Remember that without Phonon, you would need to port _all_ applications (including those that might have become unsupported), and that some people may also prefer using another back-end such as VLC or Xine. Not to mention other OS's.

Phonon was and remains the way to go IMNSHO.

Phonon for ever

Posted Sep 25, 2012 16:23 UTC (Tue) by tuna (guest, #44480) [Link]

Or you could just use gst.010.

I can accept that Phonon can be useful if you want to support different OSs, but in most cases it is nothing but a very leaky inderection layer.

Phonon for ever

Posted Sep 25, 2012 17:06 UTC (Tue) by ovitters (guest, #27950) [Link]

Those applications also had to be ported to Phonon and Phonon had to be developed. Some of the GStreamer 0.10 -> 1.0 porting was just updating something in configure.ac (meaning: no source code change!).

The cake, it was a lie

Posted Sep 25, 2012 10:22 UTC (Tue) by jospoortvliet (guest, #33164) [Link] (3 responses)

So you're saying that porting once every 7 (!!) years, is more painful than writing and maintaining the abstraction layer?

Well, if all the technologies behind you are changing each every 7 years, yes, you're changing all the time. And that's the case with applications build on gtk etc - they get left behind quickly once active development stops. That is where a proper abstraction provides benefit: take away work from application developers, increase lifetime of applications and group changes to them.

For example in the Qt ecosystem you go through a minor change every 4-5 (Qt 2-3, Qt 4-5) and a big one (Qt 1-2, Qt 3-4) every ~8-10 years. At that point you do one port and you're good to go for that long (plus that the 'old' framework stays around for another 5 or so).

The cake, it was a lie

Posted Sep 25, 2012 17:10 UTC (Tue) by ovitters (guest, #27950) [Link]

Qt is at version 5, Gtk+ is at version 3. I'm not really seeing the comparison. Seems to be pretty ok for something that maybe has 1% of the developers. Glib is at version 2 btw.

The cake, it was a lie

Posted Sep 26, 2012 4:49 UTC (Wed) by khim (subscriber, #9252) [Link] (1 responses)

Well, if all the technologies behind you are changing each every 7 years, yes, you're changing all the time.

Only if you use CADT model. The fact of the matter: MacOS, Windows, other platforms regularly redo all the levels of stack - yet somehow people can use all these creations without additional layers of indirections. Why? Oh, it's easy: yes, they change "state of the art" once per about five-to-seven years, but they continue to keep supporting older methods, too. Exactly like GStreamer is doing.

I can see the pluses of an indirection layer for something which changes regularly and forces you to port everything right away, but for something like GStreamer where upstream is sane and seriously thinks about maintainability... this is just an additional complication.

The cake, it was a lie

Posted Sep 26, 2012 12:22 UTC (Wed) by sebas (guest, #51660) [Link]

Upstream simply does not satisfy KDE's requirements for binary and source compatibility, namely BC and SC across a major release lifecycle.

GStreamer's BC and SC have been broken more than once since KDE 4.0, which means we (and every developer using the KDE platform) would be stuck with old and unsupported versions.

That's the exact opposite of maintainability.

The cake, it was a lie

Posted Sep 25, 2012 12:04 UTC (Tue) by sebas (guest, #51660) [Link] (2 responses)

As far as I can count, since the inception of Phonon, we had 2 ABI/API incompatible versions. of GStreamer. That's painfully often, but luckily we found a way to shield developers using KDE APIs from that.

Also note, that GStreamer is not the only backend we have for Phonon. VLC is enjoying a lot of work, and tends to give less headaches than GStreamer's backend. (It's not an option for everybody, since shipping VLC with its support for everything scares some distributors away for legal reasons, but it surely works very well.

Basically, the multimedia world is moving too fast (which in principle is good, since we need progress there) for providing stable APIs. That has to be done on top of that.

For KDE, Phonon prove to be very benefitial, since we didn't have to put all our eggs into one basket.

The cake, it was a lie

Posted Sep 25, 2012 12:45 UTC (Tue) by mjg59 (subscriber, #23239) [Link] (1 responses)

> VLC is enjoying a lot of work, and tends to give less headaches than GStreamer's backend.

So you have an abstraction layer that behaves differently depending on what it's abstracting?

The cake, it was a lie

Posted Sep 25, 2012 14:57 UTC (Tue) by bronson (subscriber, #4806) [Link]

Yup. When gstreamer can't play a particular .mkv, there's very little phonon can do to prevent the abstraction from leaking.

The cake, it was a lie

Posted Sep 25, 2012 12:09 UTC (Tue) by sebas (guest, #51660) [Link]

We guarantee binary compatibility across major versions. So adding GStreamer as of a few years ago to our API/ABI would mean we're stuck with it.

Phonon allows us to "upgrade" and change multimedia systems in the background without the developers even having to rebuild their apps, let alone port. We basically port it one, or add support for a new backend, and it's transparantly available for apps that have been compiled even before that mutimedia system or backend became available. That's the benefit of having pluggable backends to stable interfaces.

There are no plans to move to QtMobility and/or QtMultiMediaKit, that I'm aware of. And looking at QtMobility's source, that's a good thing. Hack, the 1.2 release didn't even build out of the box for me...

The cake, it was a lie

Posted Sep 25, 2012 10:25 UTC (Tue) by Frej (guest, #4165) [Link] (2 responses)

The cost of changing from 0.10->1.0 is likely less than having a wrapper?

Everytime a phonon backend does something 'new' that solves an existing problem - What happens then? You add API, and then all media players have backends that are subpar, or must media players verify if current backend supports the new feature? Either way the pain is just pushed to API users.

Or must every backend support a new feature before it's added? So everything slows down?

And how do media players handle support? Now they get to support problems from X backends instead of just one. Oh the mkv parser is broken in Z, but works in Y. Pain :(

The cake, it was a lie

Posted Sep 25, 2012 12:13 UTC (Tue) by sebas (guest, #51660) [Link]

What you say is true for one isolated application.

In KDE, this is quite different:

The costs of porting a backend in one place is way lower than changing every application.

Moreover, GStreamer developer could not guarantee source and binary compatibility for KDE's lifetime. (Which is OK, just means we had to find a solution, which we did.)

The cake, it was a lie

Posted Sep 25, 2012 14:07 UTC (Tue) by rvfh (guest, #31018) [Link]

> Everytime a phonon backend does something 'new' that solves an existing problem - What happens then? You add API, and then all media players have backends that are subpar, or must media players verify if current backend supports the new feature?

The Phonon API is only about the basic stuff you find in 99% of apps: play a sound. So you don't need to change the Phonon API. The fact that the backend does something better (as is the case in GST 1.0, for example buffer sharing) does not mean you need to change the Phonon API to play/pause/stop a stream.

Why would it?