[Desktop_architects] Re: What is your answer to solve the top inhibitor for the Linuxdesktop adoption?

Bryce Harrington bryce at osdl.org
Tue Jan 3 23:13:04 PST 2006


On Tue, Jan 03, 2006 at 09:55:41PM -0700, Aaron J. Seigo wrote:
> On Tuesday 03 January 2006 21:01, Bastian, Waldo wrote:
> > There would be a natural motivation in the sense that everyone will be
> > documenting those parts of the system that they have a natural interest
> > in already anyway. 
> 
> given that we don't have much of this documentation right now (i'm thinking of 
> high-level docu (e.g. "how to print") versus API docu, which we do a good but 
> not stellar job with), i don't know if this is realistic?

I was involved in the very, very early days of Wikipedia, so I do know
that natural motivation for writing documentation exists and can be
harnessed, but I also know it's really, really difficult to get things
up off the ground, and takes dozens of extremely crazy^H^H^H^H^H
visionary people to get it to the snowball point.  Wikipedia's the
exception, not the rule; I've been involved in a dozen wiki efforts for
every one that actually could be called a success.

Incidentally, I'm having some experience right now with this
documentation portal in a microcosm, for the NFSv4 testing effort
(http://wiki.linux-nfs.org).  We've been collecting documentation to
help answer questions that NFSv4 testers and deployers might have.  It's
working, but it's very slow going.  This may be because NFS is a fairly
dry topic compared with something exciting like RUDI or Klik or
Inkscape, but I think that makes this a good analog to what we're
talking about here.  The exciting stuff has no trouble getting
documented; it's this core infrastructure bread and butter stuff where
the documentation effort is really needed.

Anyway, I guess my point is that I think there's some stuff where there
is natural motivation to write documentation, but the stuff that really
*needs* to be documented may not have natural motivation, so the best
strategy would be one that had a built-in motivation for getting the
bread and butter items documented.

> > If OSDL would generate the questions I'm sure that the individual
> > projects will manage to come up with answers, after all, these are the
> > same issues that are being asked and answered on mailinglists already.
> > The only difference is that with this infrastructure such knowledge
> > would be much more accessible.
> 
> how many questions on mailing lists are of the "how do i use this particular 
> set of functions/classes in libfoo?" variety versus broader, topic-wide 
> queries like "how do i print?" or "what are the IPC options available and how 
> do i use them from my application?"

Or for example, a question I happened to have today - what is the best
practices being used for provisioning multiple client machines?  I had a
bunch of (gentoo-based) test systems at work that I have to keep up to
date, and have just got 10 more bare systems that I need to install.
We have typically just been using system imager, but I'm curious what
other companies and organizations use.  Is there a best practice?  If
not, what are the pros and cons of the various options?

I figured this was something that lots and lots of people have already
run into, so searched a bit online (keyworded with gentoo, debian, and
ubuntu) but found very little that I would trust to be unbiased
information.  Wikipedia had an article on provisioning but it only
scratched the surface.

Bryce



More information about the Desktop_architects mailing list