ICCCM vs. technology pimping (was: Re: No more module proposals - decisions need to be made)

Mike Hearn mike at navi.cx
Fri Nov 5 20:30:58 EET 2004


On Fri, 2004-11-05 at 17:50, Daniel Stone wrote:
> So, Havoc has noted this -- the LSB exists to define incredibly stable
> ABIs, and thus it tends to move rather slowly.
> 
> Looking at the shape of the platform, there are two alternatives I see
> thus far:
> 	* a very small set of specifications (think: ICCCM)
> 	* the above, plus pushing cool technologies that, while largely
> 	  standard, are not in the Oracle realm of LSBism; stuff like
> 	  D-BUS in April next year or such.

Well, I've been saying this for a while now in various forums. I'm not
convinced the LSB moves fast enough for a competitive desktop platform
given how far we've got to catch up [to Windows]. Happy to be proven
wrong mind you.

The flip side is that the LSB has distro buy-in (... unless the LSB says
something the distro doesn't want to do like the LSB C++ ABI) whereas
the mythical freedesktop.org platform doesn't. 

Also, Havoc and Owen Taylor are/were keen on desktop LSB. As desktop
lead for Red Hat and GTK+ maintainer respectively their opinion has a
ton of weight in this discussion: a platform that Fedora doesn't follow
or that doesn't include an ABI stable widget toolkit [1] doesn't seem to
have statistics on its side.

Any alternative would also need some set of rules and standards to stop
people just proposing random cool libraries, ie any proposed library
would probably have to give strong public commitment to backwards
compatibility and stability otherwise the platform would become bloated
really fast. That rules out quite a lot of de-facto standard libraries
already (like OpenSSL) but it's something that has to be done no matter
what the final desktop platform looks like. You also have to be really
specific about what's in and what's out (dependencies of libraries in
shouldn't be considered in themselves), and have some sane way of
versioning the platform as a whole. 

There'd also need to be policy about what happens if a library that's in
the platform reneges on its backwards compatibility commitment or
there's disagreement as to what backwards compatibility means.

LSB as far as I'm aware has no such policy, which means things like NPTL
and readdir()-breaking patches have slipped through. LSB is also
powerless to do anything about upstream projects which aren't concerned
about compatibility hence the fact that most libraries currently in the
LSB are either unchanging (like ncurses/core Xlib) or use unusual
versioning schemes to break compatibility but also sorta not break it
(like glibc).

So for these reasons I think it makes sense to have a separate desktop
platform project, but I'm in no way convinced I'm right and could
definitely be swayed in favour of desktop LSB again.

thanks -mike


[1] until g++ stops changing the C++ ABI Qt isn't ABI stable in the
    absolute sense, sorry




More information about the platform mailing list