A developer meeting strengthens a Linux desktop alliance that could lead to better leverage with hardware vendors and more cross-distribution efforts such as the newly created Portland Project.
To read all comments associated with this story, please click here.
Member since:2005-07-06
this time you are clearly missing the boat.
I'm afraid not, and here's why. Both you and Martin are looking at something that draws a huge circle, and you both believe that you've ended up in a different place when you're actually back where you started.
I am all for compatibility layers when they make sense. When you're creating desktop environments, for example, there are going to be people who have written software for older environments and that software still needs to work in KDE 15 with all the latest wizz bang features. An example is when people moved from Windows 3.1 to 95, and the applications written for 3.1 when run on 95 inherited new UI features amongst other things. ABI compatiblity in that manner is perfectly sensible and required if desktop Linux is to go anywhere.
Martin hints at this ABI problem between different versions, but he describes totally the wrong solution to tackle it. What you have to do is take responsibility for the interfaces in the previous versions and continue to provide support for them, or you sensibly deprecate interfaces from the main libraries and continue support for them in a thin compatibility layer. You don't run away and hide in a new system, and in RuDI you still have to program a translation in for them. The ABI problem for C++ of GCC has an obvious solution - ABI stability of GCC needs to stabilise. You never, ever create a whole new layer just to get around a problem that shouldn't exist in the first place.
The problem with Martin's RuDI approach is that he does not even really go into the problems above for coming up with what he's done. He goes off on a huge, totally unrelated, tangent talking about not having a monoculture and supporting XFCE in a bank when there are already 400 KDE workstations. Is the security risk that great from a monoculture of KDE that this bank needs to consider putting XFCE in, together with a RuDI layer on top of that which allows the same applications to be run? No it isn't, it's just total lunacy and no one out there thinks like that.
Martin then goes on to describe a whole service type architecture, of some complexity, and because of that complexity it really is a whole desktop enviroment in itself - all to insulate ISVs, and even whole programming environments, from different desktop environments! And what happens if there are differences between the environments (which there definitely will be) such that RuDI or Portland cannot translate for an application? You get very poor integration into the desktop environment, especially for people like IHVs, to the point where it becomes useless. Interestingly, you also have to come up with a common and agreed dialect which can be translated into each desktop environment or you simply get too many differences, which leads us right back to the arguments this architecture is supposed to solve. You want several hundred XML schemas and committees describing translations for different desktop environments? Yay!
Why not just make RuDI or Portland into a desktop environment, can the underlying desktop and get rid of the complexity? Why, you might ask. Because more effort for zero return will go into this than actually improving the desktop environments, Portland will become a roadblock, too restrictive in terms of its functionality and people will continue to port to different desktop environments regardless, as they have always done.
It is by far not "another ill-advised attempt at integration where integration just isn't possible or just creates more work than is actually required".
Since RuDI (or Portland) hasn't got off the ground or been proved in the real world you can't make that statement.
This time you are clearly off target.
I am still not convinced otherwise. I'm sorry, but this whole thing is a touchy, feely, nicy, nicy, cross-platform, cross-desktop integration thing that makes zero sense in the real world. If you look at this whole sorry thing you find it makes more sense to an open source developer than it does to an ISV, and it makes absolutely zero difference to a user. It certainly doesn't make the applications any better or the development tools any better. That's what needed to be discussed at these OSDL meetings - stuff that actually makes a difference to ISVs and users, not stuff to solve the open source world's problems.
Member since:
segedunum,
this time you are clearly missing the boat. AFAICS, Project Portland was wholly inspired by Martin Konold's previous "RUDI" proposal [see http://www.kdedevelopers.org/node/1398 for details].
It is by far not "another ill-advised attempt at integration where integration just isn't possible or just creates more work than is actually required".
This time you are clearly off target.