GStreamer 1.0 released
The 1.x series is a stable series targeted at end users. It is not API or ABI compatible with the 0.10.x series. It can, however, be installed in parallel with the 0.10.x series and will not affect an existing 0.10.x installation." LWN recently previewed this release.
Posted Sep 24, 2012 21:31 UTC (Mon)
by ncm (guest, #165)
[Link] (60 responses)
Posted Sep 24, 2012 22:15 UTC (Mon)
by Jonno (subscriber, #49613)
[Link] (52 responses)
At least KDE even supports parallel installation and execution of multiple versions of the actual desktop and individual applications. Of course integration is not perfect, but that is to be expected. Combining pieces of two different major versions of a DE works about as well as combing pieces of two different DEs, quite possible, but not trivial to configure.
Posted Sep 24, 2012 22:30 UTC (Mon)
by dlang (guest, #313)
[Link] (49 responses)
I don't know about KDE.
Posted Sep 24, 2012 22:34 UTC (Mon)
by khim (subscriber, #9252)
[Link] (38 responses)
Posted Sep 24, 2012 23:22 UTC (Mon)
by sebas (guest, #51660)
[Link] (34 responses)
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. :)
Posted Sep 25, 2012 3:14 UTC (Tue)
by khim (subscriber, #9252)
[Link] (10 responses)
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. 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?
Posted Sep 25, 2012 10:07 UTC (Tue)
by jospoortvliet (guest, #33164)
[Link] (4 responses)
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 :(
Posted Sep 26, 2012 4:37 UTC (Wed)
by khim (subscriber, #9252)
[Link] (3 responses)
Yet another place where distributions are a problem not a solution.
Posted Sep 27, 2012 11:17 UTC (Thu)
by renox (guest, #23785)
[Link] (2 responses)
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.
Posted Sep 27, 2012 13:05 UTC (Thu)
by Jonno (subscriber, #49613)
[Link] (1 responses)
Posted Sep 27, 2012 13:36 UTC (Thu)
by renox (guest, #23785)
[Link]
Posted Sep 25, 2012 10:13 UTC (Tue)
by sebas (guest, #51660)
[Link] (2 responses)
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.
Posted Sep 25, 2012 11:44 UTC (Tue)
by jackb (guest, #41909)
[Link]
Posted Sep 25, 2012 12:08 UTC (Tue)
by nix (subscriber, #2304)
[Link]
Posted Sep 25, 2012 23:34 UTC (Tue)
by Tester (guest, #40675)
[Link] (1 responses)
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")?
Posted Sep 25, 2012 8:34 UTC (Tue)
by obi (guest, #5784)
[Link] (19 responses)
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?
Posted Sep 25, 2012 8:57 UTC (Tue)
by Cyberax (✭ supporter ✭, #52523)
[Link] (7 responses)
Yes, it is. I have 12 year-old games on my computer which I'd very like to be still playable.
Posted Sep 25, 2012 15:37 UTC (Tue)
by hummassa (subscriber, #307)
[Link] (1 responses)
Posted Sep 25, 2012 16:08 UTC (Tue)
by Kit (guest, #55925)
[Link]
Posted Sep 25, 2012 17:04 UTC (Tue)
by ovitters (guest, #27950)
[Link] (4 responses)
Posted Sep 26, 2012 12:17 UTC (Wed)
by sebas (guest, #51660)
[Link] (3 responses)
Posted Sep 26, 2012 21:05 UTC (Wed)
by khim (subscriber, #9252)
[Link] (2 responses)
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?
Posted Sep 26, 2012 21:48 UTC (Wed)
by raven667 (subscriber, #5198)
[Link]
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.
Posted Sep 27, 2012 13:08 UTC (Thu)
by sebas (guest, #51660)
[Link]
Posted Sep 25, 2012 9:02 UTC (Tue)
by rvfh (guest, #31018)
[Link] (2 responses)
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.
Posted Sep 25, 2012 16:23 UTC (Tue)
by tuna (guest, #44480)
[Link]
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.
Posted Sep 25, 2012 17:06 UTC (Tue)
by ovitters (guest, #27950)
[Link]
Posted Sep 25, 2012 10:22 UTC (Tue)
by jospoortvliet (guest, #33164)
[Link] (3 responses)
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).
Posted Sep 25, 2012 17:10 UTC (Tue)
by ovitters (guest, #27950)
[Link]
Posted Sep 26, 2012 4:49 UTC (Wed)
by khim (subscriber, #9252)
[Link] (1 responses)
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.
Posted Sep 26, 2012 12:22 UTC (Wed)
by sebas (guest, #51660)
[Link]
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.
Posted Sep 25, 2012 12:04 UTC (Tue)
by sebas (guest, #51660)
[Link] (2 responses)
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.
Posted Sep 25, 2012 12:45 UTC (Tue)
by mjg59 (subscriber, #23239)
[Link] (1 responses)
So you have an abstraction layer that behaves differently depending on what it's abstracting?
Posted Sep 25, 2012 14:57 UTC (Tue)
by bronson (subscriber, #4806)
[Link]
Posted Sep 25, 2012 12:09 UTC (Tue)
by sebas (guest, #51660)
[Link]
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...
Posted Sep 25, 2012 10:25 UTC (Tue)
by Frej (guest, #4165)
[Link] (2 responses)
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 :(
Posted Sep 25, 2012 12:13 UTC (Tue)
by sebas (guest, #51660)
[Link]
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.)
Posted Sep 25, 2012 14:07 UTC (Tue)
by rvfh (guest, #31018)
[Link]
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?
Posted Sep 24, 2012 23:24 UTC (Mon)
by Jonno (subscriber, #49613)
[Link] (1 responses)
To get "propper behaviour" the distribution just have to pick three data directories (ie. /usr/share/kde3, /usr/share/kde4, and /usr/share) and determine where each program should reside (eg is it KDE3 only, KDE4 only, or a regular application) and set the default XDG_DATA_DIRS values appropriately (eg "/usr/share/kde3:/usr/share" in KDE3 and "/usr/share/kde4:/usr/share" in KDE4).
If using only one data directory, you will get duplicates of every entry in the K-menu that is available in both versions, and if using only two directories you will get the "two separate worlds" you describe, but both those scenarios are due to bad distribution packaging, not due to anything KDE did wrong.
Posted Sep 25, 2012 12:10 UTC (Tue)
by nix (subscriber, #2304)
[Link]
Posted Sep 26, 2012 8:23 UTC (Wed)
by rqosa (subscriber, #24136)
[Link]
> What you can not do (and what you really want to do) is to mix and match KDE3-based and KDe4-based applications. I used to do that, and it worked fine for me.
Posted Sep 24, 2012 22:59 UTC (Mon)
by Jonno (subscriber, #49613)
[Link] (5 responses)
GNOME 2 and GNOME 3 libraries can co-exist (I'm running both a GNOME 2 application and a GNOME 3 application on my KDE desktop right now), though unlike KDE, the GNOME 2 and GNOME 3 desktops can't be co-installed. So GNOME offer the same ability as GStreamer, even if only KDE goes one step further. As for KDE, I was running KDE 3.5 and 4.x in parallel for a few years, switch between them at login time, so that works just fine (though the K-menu was a bit messy for a while, with duplicates of several applications).
Posted Sep 26, 2012 4:03 UTC (Wed)
by jmalcolm (subscriber, #8876)
[Link] (4 responses)
Posted Sep 26, 2012 4:56 UTC (Wed)
by khim (subscriber, #9252)
[Link] (2 responses)
Of course it's possible! It's almost always possible with software! The only case where this can not be achieved is when you don't have a specs for older system and you don't have a source code to dissect it. The problem is with attitude: the fact that you need to run third-party fork of GNOME2, not some kind of Classic Environment or WoW from the creators of this "shiny new thing" spokes volumes about their priorities and about their attitude WRT their users.
Posted Sep 26, 2012 12:25 UTC (Wed)
by sebas (guest, #51660)
[Link] (1 responses)
Posted Sep 26, 2012 13:47 UTC (Wed)
by mjg59 (subscriber, #23239)
[Link]
Posted Sep 26, 2012 9:36 UTC (Wed)
by paulj (subscriber, #341)
[Link]
If MATE were actually GNOME 2, then switching between GNOME 2 and MATE would be completely transparent. It isn't.
Posted Sep 26, 2012 4:05 UTC (Wed)
by jmalcolm (subscriber, #8876)
[Link] (3 responses)
Posted Sep 26, 2012 18:59 UTC (Wed)
by dlang (guest, #313)
[Link] (2 responses)
Posted Sep 27, 2012 12:37 UTC (Thu)
by cortana (subscriber, #24596)
[Link] (1 responses)
Posted Oct 1, 2012 17:30 UTC (Mon)
by ssam (guest, #46587)
[Link]
The GNOME3 classic mode is new, less well tested code, with less features and new bugs. it could be made to be a good replacement for GNOME2, but that might take a few developer years of work.
Ubuntu have put some nice work into GNOME3 classic, bringing back things like the system monitor. and there is the cinnamon project. so maybe in a few years GNOME3 will be able to do what want, but for now MATE just works.
Posted Sep 24, 2012 22:31 UTC (Mon)
by khim (subscriber, #9252)
[Link] (1 responses)
That they do, but this is not what people are talking about. Compatibility means one simple (yeah, right) thing: I have this old program, I install some shiny new thing and still can use this old crufty thing I really like for some reason. Nothing more, nothing less. If you package does not make it possible "because of a few tiny reasons" it still makes it not possible, period. When you see "yes, you can install KDE3 and KDE4 side-by-side, but remember that sharing a .kde directory between KDE 3.4 and KDE 3.5 wasn't completely supported" or if you ask "Is there a strategy regarding co-existing of gnome2 and gnome3 on the same system?" and see "Short answer is no, and we won't be doing it" you know that their developers have read how to wreak your ecosystem book and decided to do exactly that. Just why otherwise sensible people repeatedly do the same mistake again and again and again is open for debate, but sadly this is quite real problem. I would gladly remove all that GNOME3 crap from Precise Pangolin, but some packages which I would really like to keep depend on it so I'm stuck.
Posted Sep 25, 2012 0:03 UTC (Tue)
by Jonno (subscriber, #49613)
[Link]
As for the 3.5 -> 4.x migration, the idea was that kde3 and kde4 applications should use different dot-directories and the kde4 application should migrate the settings from it's 3.5 counterpart on first use. Unfortunately most distributions didn't make use of this feature, either using separate directories without telling KDE4 where to find KDE3 settings to migrate, or pointing both to the same directory forcing KDE4 to do an in-place conversion thus making a downgrade to KDE3 impossible (without removing all your settings).
Posted Sep 24, 2012 22:17 UTC (Mon)
by khim (subscriber, #9252)
[Link] (6 responses)
I agree that this is smart move, but this is how GStreamer guys always did things, so… P.S. I guess if I'll point out that GStreamer is used on many more systems than GNOME or KDE I again see the explanation for how this is good thing to do with GStreamer and bad thing to do with desktop environment because they the problem desktop environments are trying to solve are oh-so-unique.
Posted Sep 25, 2012 9:31 UTC (Tue)
by Company (guest, #57006)
[Link] (5 responses)
You only have one Totem, one Pitivi and one Cheese application on your computer. And most likely your distro will not even let you choose which one.
So in that sense GStreamer is just like the desktops.
PS: GStreamer got a lot of its inspiration for parallel-installability from GNOME back when GNOME 2.0 and GStreamer 0.6 came out.
Posted Sep 26, 2012 11:02 UTC (Wed)
by Otus (subscriber, #67685)
[Link] (3 responses)
Can an application like Totem support both 0.10 and 1.0?
But I'm not sure what you mean, since of course you can have two Totems or
Posted Sep 26, 2012 22:46 UTC (Wed)
by Company (guest, #57006)
[Link] (2 responses)
You can of course install the application twice, once into /usr and once into /opt. But that works for GNOME or KDE, too. In fact, GNOME development is done that way. Everyone has the distro's GNOME installed in /usr and a jhbuild somewhere in the home directory or /opt.
Posted Oct 1, 2012 14:31 UTC (Mon)
by kleptog (subscriber, #1183)
[Link] (1 responses)
Well, it could if the library used symbol versioning
There's lots and lots of features in shared libraries to make backward compatibility work. But it seems that glibc is the only library out there that uses it (thank god, it makes glibc upgrades extremely safe).
Posted Oct 1, 2012 14:48 UTC (Mon)
by TomH (subscriber, #56149)
[Link]
To name a few: libstdc++, zlib, libpng, libjpeg-turbo, libxml2, etc, etc.
Posted Sep 27, 2012 0:10 UTC (Thu)
by khim (subscriber, #9252)
[Link]
Why would I want to do that? Or ever: why would I care about that? hIt's some magic pixie dust programmers are using to show me pretty pictures. I don't want to even think about it. If one program wants to use 0.10 - it can do that, if it wants to use 1.0 - it can do that, too. I don't care what they use actually. I just want to see which version I like better: old one or new one. And if I like 0.10-based Totem, but 1.0-based Pitivi then that's fine with me. Sadly this is not so. I can not decide when to upgrade. I may decide to keep GNOME2 pr GNOME3 - and that's it. I can not combine them. Not without third-party packages like MATE.
That is really smart, releasing a next generation
framework that co-exists peacefully with the previous
one. If only desktop environments could do the same!
A lesson
A lesson
But they do! Both KDE and GNOME support co-existing major (eg ABI incompatible) versions of their respective libraries.
A lesson
KDE is a little better: you can parallel-install KDE3 and KDE4 on the same system and if one user only uses KDE3 applications and another uses KDE4 applications - you are golden. Not a big improvement IMO: you can do the same with GNOME using chroot-install. What you can not do (and what you really want to do) is to mix and match KDE3-based and KDe4-based applications.
A lesson
The cake, it was a lie
The cake, it was a lie
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.
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".
The cake, it was a lie
The cake, it was a lie
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 cake, it was a lie
The cake, it was a lie
> 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
The cake, it was a lie
The cake, it was a lie
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
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
Benefits
The cake, it was a lie
The cake, it was a lie
The cake, it was a lie
The cake, it was a lie
The cake, it was a lie
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
The cake, it was a lie
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
The cake, it was a lie
Phonon for ever
Phonon for ever
Phonon for ever
So you're saying that porting once every 7 (!!) years, is more painful than writing and maintaining the abstraction layer?The cake, it was a lie
The cake, it was a lie
The cake, it was a lie
Well, if all the technologies behind you are changing each every 7 years, yes, you're changing all the time.
The cake, it was a lie
The cake, it was a lie
The cake, it was a lie
The cake, it was a lie
The cake, it was a lie
The cake, it was a lie
The cake, it was a lie
The cake, it was a lie
A lesson
A lesson
A lesson
A lesson
A lesson
A lesson
A lesson
A lesson
MATE is not GNOME 2
MATE can be installed alongside GNOME 3.
A lesson
A lesson
A lesson
A lesson
A lesson
But they do! Both KDE and GNOME support co-existing major (eg ABI incompatible) versions of their respective libraries.
A lesson
A lesson
A lesson
A lesson
>
> You only have one Totem, one Pitivi and one Cheese application on your
> computer. And most likely your distro will not even let you choose which
> one.
>
> So in that sense GStreamer is just like the desktops.
Cheeses. I have several versions of some applications. They just have to be
installed in /opt or ~/whatever.
A lesson
A lesson
A lesson
A lesson
You cannot install the same GStreamer application for both 0.10 and 1.0.
So in that sense GStreamer is just like the desktops.