My monthly 'oh yeah, the platform' mail

[Daniel Stone]

On Tue, Dec 21, 2004 at 10:24:22PM -0500, Havoc Pennington wrote:
> I concur that getting a bundle of the specs to "1.0" state as a unit
> would be useful, but I don't see the bright line between a specs release
> and a code release. I'll get back to this by the end of the long mail
> here.

Thanks for the reply.

> On technology pimping
> ===
> 
> The "stack" concept is useful but NOT for technology pimping.
> A goal of the stack should be to show which technology is *well-cooked*
> - and part of the definition of "well-cooked" is "widely de facto shown
> to be useful." So it doesn't make sense to use the stack to "push" or
> promote technologies, since "already accepted" should be a gating
> principle.

Agreed -- I suppose this was again badly expressed.  As said before, I'm
not so keen on ramming things like D-BUS and Cairo down people's
throats, hence why they were never proposed.

> Another reason not to go the "push technologies" route is that it can
> come back and bite you in the ass. If I can be controversial for a
> moment, look at XPrint: it's generally agreed by mainstream toolkit
> authors that XPrint is the 100% wrong direction, yet it's being pushed
> into the stack anyhow.

Agreed.

> Many of the things that have been discussed for the stack are in fact
> not ready. Cairo is a good example: most of the desktop world agrees
> this is the right path and that it's going well, but it's *not done*.
> The API is not ready to lock down. Same for D-BUS.

Yep.

> Platform stack is not all-inclusive
> ===
> 
> [...]
> 
> This implies that we have a basic goal with freedesktop.org platform of
> targeting the "mainstream" open source desktop, rather than some of the
> corner cases we could think about. freedesktop.org *the hosting site*
> can and does host alternate platforms or projects that don't have this
> "mainstream" orientation, but I think most of us talking about this
> platform release are thinking about the primary toolkits and
> environments.

Agreed.

> [...]
> 
> So guideline 1 for a platform stack: it should be defined to be
> "mainstream desktop" and not these other cases. There should be a target
> audience.
> 
> Guideline 2: it should require that the specs or libraries have de facto
> success among the target audience (whether toolkit maintainers or app
> developers).

Right.

> Purpose of the stack
> ===
> 
> Some thoughts on why we'd collect widely-accepted technologies into a
> release:
>  - snapshot particular branches/versions of these technologies and  
>    give them an overall version number; this avoids the issue 
>    where environment or app A requires foo 1.0 and bar 1.2 and 
>    environment or app B requires foo 2.0 and bar 1.0, and so 
>    you can't make things work. Of course if foo and bar 
>    support parallel install this doesn't come up... ;-)
>    http://ometer.com/parallel.html
>  - the other reason to snapshot a set of branches/versions is for 
>    testing purposes; we can have everyone testing the same 
>    *combination* of platform elements
>  - naming the whole big bundle lets something like GNOME say 
>    "we require freedesktop.org platform 1.0" rather than 
>    "we require the following long-ass list of stuff: ..."
>  - OS vendors can also refer to including a particular platform release
>  - have a "release train" that people want to catch, which gives some 
>    deadlines and incentive to the development process, and a freeze-and-
>    stabilize phase as well. This should encourage more 1.0 releases.
> 
> These same basic goals apply to a GNOME or X.org or KDE release.

All of these criteria are good -- the other thing there is that it
encourages more of a static baseline between desktops, so we don't end
up with, say, four multimedia frameworks.

> Purpose of the LSB
> ===
> 
> While I see freedesktop.org solving communication, coordination, and
> software development problems - it's largely an intra-community effort -
> the LSB is solving the ISV problem.
> 
> So what the LSB is doing is documenting, testing, and enforcing the
> interfaces that ISVs are supposed to use. They collect not only desktop
> technologies but also other elements of the Linux platform.
> 
> This LSB process *should* be more conservative even than
> freedesktop.org. Though they have been moving somewhat too slow on the
> desktop front, that's largely due to lack of volunteers and assistance
> from what I've seen. Because the LSB goes further than just releasing
> the software, and creates validation tests for ABIs (to be sure they
> didn't change) and for ISV apps (to be sure they don't have extraneous
> dependencies) it simply takes some work. But this stuff is useful.
> 
> Here's another twist, though, for the ISV question: freedesktop.org is
> largely creating a "backend for toolkits," and only a few of the specs
> are really intended to be used directly by applications. So what we'd
> expect the LSB to bless is a bit higher-level - GTK+ and Qt, rather than
> XSETTINGS or fontconfig.
> 
> Another way to look at LSB: they are not releasing software. They're
> releasing a contract-enforcement layer between the ISV and the software.
> This is a fundamentally different thing from a
> freedesktop/X.org/GNOME/KDE release.

It's an interesting distinction that I honestly hadn't thought about --
but as long as the LSB aren't abdicating their duties, I'm happy to walk
this line.

> ISV Credibility
> ===
> 
> A danger for the open source desktop is that ISVs look at the huge
> collection of libraries available in your average distribution, use a
> few of the ones that "everyone" knows are crap, and are turned off when
> they get shafted by the decision. There's really no good guidance on
> which of the zillion things in /usr/lib are considered OK. And for all
> of them you can find some nitwit on the Internet who will say it's the
> best thing ever.
> 
> This is why having a line where we say "these are the libs to use" is
> useful. But that line has to be oriented toward *keeping ISVs from
> getting shafted* not toward *getting ISVs to use half-baked gee-whiz
> stuff*
> 
> If we consider this, plus the goal of using a platform release for
> stabilization and integration, I hope it's clear that trying to push
> technologies before their time is highly counterproductive.

Yes, agreed.  But wouldn't the LSB fill this role, if they're playing
the ISV liason?

> X.org
> ===
> 
> An additional question people have brought up is the relationship
> between freedesktop.org and X.org. I think potentially X.org could
> define the entire platform and eliminate the need for freedesktop.org. 

I don't think they can, to be honest.

> This hasn't happened because there was resistance to defining the scope
> of X.org to be "entire open source desktop" as opposed to "X Window
> System." Because the X.org scope doesn't cover freedesktop.org goals we
> have a need to do a freedesktop.org platform that is complementary to
> the X11 releases.

I'm personally happy with this resistance ...

> My expectation is that the freedesktop.org platform would include by
> reference the X11 release, or at least those parts that are relevant to
> the modern desktop. For example, I don't think twm needs to be defined
> as part of the platform that GTK+/Qt/GNOME/KDE rely upon. But
> freedesktop.org would say "the modern desktop requires the core X Window
> System" and then define additional components such as D-BUS that X.org
> feels fall outside the X.org scope.

I would take 'the core X Window System' to be the standard X client
libraries (libX11, libXext, libXau), plus the extensions (libXrender,
libXrandr, libXfixes, libXdamage, libXcomposite, et al), plus libXft,
libXt, and anything else I've forgotten.  That sort of thing.

> Perhaps more controversially, I think the same cautions I've suggested
> for freedesktop.org platform would apply to X.org releases. So if X.org
> is blessing de jure technologies that have flopped de facto, then X.org
> has a problem. So far I think X.org is doing mostly fine in this
> respect. And since freedesktop.org hasn't done a platform release it's
> unknown whether freedesktop.org will do fine.

I think this will become less of a problem as X.Org migrates to a
modular structure.  Instead of dragging Xprint through and dealing with
it as a part of a single, massive, release process, modules no-one cares
about get to rot away in obscurity; people can essentially vote with
their feet.

> Anyhow, the point I'm trying to make is that to the extent X.org and
> freedesktop.org exist as usefully distinct entities, it's a matter of
> technology scope (X11 vs. all of desktop). I don't think there's a
> fundamental difference in the kinds of release the two entities are
> making, just a difference in what categories of stuff are in the
> releases.

Right.  I still think this is a useful distinction, however.  X is a
rather large scope, and I think many considerations we have with X are
totally different; for example, I don't really see the value in a stack
that stretches down from D-BUS up to the Radeon DRI driver.  While I
think the modularity within X is much-needed, so we can finally shed
some things that no-one cares about (for instance, we're still dragging
xedit along -- why?), I'm not entirely sure that the scopes of the two
platforms should merge.

> There's no real difference between X.org, freedesktop.org, and GNOME or
> KDE either.

No, but they're still separate ...

> >From my point of view freedesktop.org just covers the block of
> technology in between X.org and GNOME/KDE. If X.org wants to expand up
> to meet GNOME/KDE and leave nothing in the middle then that would be
> fine.

I personally prefer the current situation as it is.

> In summary
> ===
> 
> Getting back to my first paragraph: I don't really see a reason for a
> "specs only" release, I think there are some things such as fontconfig
> that are ready to be in a platform release that also includes code.

Fair point.

> The relevant line to draw is between things that are fully baked and
> things that are works in progress. There's *nothing* wrong with works in
> progress, in fact as an open source community we're usually too afraid
> to try something out and consider dropping it if it fails. However,
> there *is* something wrong with considering something ready to bless
> before it has some de facto success.

Agreed.

> So I like the idea of a platform release. But the idea that it's a way
> to "push" technologies is simply broken. It's a way to communicate which
> technologies have been successfully pushed *already*.

Agreed.

> Hopefully all this makes sense, if I had more time I'd edit and cut the
> mail in half, but better verbose than silent ;-)

Something that would make even more sense: if you were doing the
release, what would you put in the platform?