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

The cake, it was a lie

Posted Sep 25, 2012 8:34 UTC (Tue) by obi (guest, #5784)
In reply to: The cake, it was a lie by sebas
Parent article: GStreamer 1.0 released

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?

to post comments

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...