Strategy for fixing Bug #1

Wed Dec 27 08:37:22 UTC 2006

You're not necessarily wrong (in fact, I agree with you on many of your
points). But, we need to take advantage of this 32-to-64-bit transition
window when and while we can. And the fact of the matter is, many of these
problems are as bad if not worse in the Windows world, and those that remain
are challenges for us, not blocking issues for having a majority market
share (and thus closing bug #1). It's all about priorities. Let's take over
the world first, then fix these other things. When you look at who's in
control now, you realize that we need not be perfect in order to be
dominant.

The 5 points from the essay are not meant to be an exhaustive list of what's
wrong with Linux. They're meant to be a list of what's required to be a
contender in the looming battle for the 64-bit desktop. That's a battle that
Microsoft does _not_ have in the bag already, so it's worth fighting. If you
think some of your issues are blocking that, then let's continue the
discussion in that vein.

I believe that if Ubuntu emerged as a front runner on this stuff, then
Michael Dell wouldn't have to ask "which one?" anymore. Red Hat isn't the
only enterprise server distro in town, but Dell had no trouble standardizing
on them. It's because they provide what is needed for Dell and its
customers, and they did it better, sooner, and cheaper than their
competitors. Ubuntu can do the same on the desktop, and I believe it's
already years ahead of many (most? all?) of its competitors here. With
out-of-the-box Wine and Codex support, it would be well-poised to become the
Red Hat of the desktop space (i.e. as dominant on the desktop as RH is in
the server space, with the added bonus that the desktop market is much, much
larger than the server market). And if we played our cards right and emerged
as the dominant 64-bit desktop platform, wow. That, in my opinion, is worth
shooting for.

Wes Morgan

On 12/27/06, mikecorn <mikecorn at t-online.de> wrote:
>
> The 5 points are OK but there are deeper problems with Linux that need
> to be solved first. Ubuntu is the best Linux, but is not doing anything
> to fix the real issues, IMO.
>
> This is a (short) rant about what is wrong with Linux, so if you are
> sick of reading about this you can just delete it now. I write because
> most such rants miss the point (for example ESR's essay).
>
> Linux Problems
> - too many bugs and rough edges in applications
> - error messages are hidden in log files, incomprehensible, or do not
> exist
> - technical and user docs are often missing, erroneous, or outdated
> - docs are in chaos: man, info, http, text, websites, tar
> (or sometimes findable only with Google)
> - developer goals are not aligned with common user needs
> (FOSS is not customer or market-driven)
> - development is not managed (1000s of independent projects)
> - developers care about creative freedom, not about utility, standards,
> compatibility, fit and polish, quality documentation, etc.
> - app development is 90% overlapping, a huge waste
> - Linux distros are diverging, making app portability and support too
> difficult for software providers. (Software I developed using Ubuntu
> runs unmodified on about half the other Gnome distros I have tried.
> Problems: package naming, file names and locations. KDE distros often
> fail for lack of Gnome libraries - a hurdle most users are not
> willing/able to overcome.)
> - the LSD project is an attempt to create some useful standards and
> cross-platform tools, but Mark Shuttleworth has stated he does not
> believe in this.
> - software providers want standards, so that installation and support
> does not have a different "gotcha" with each distro. MS Windows provides
> a single standard, which is more important than its weaknesses (viruses,
> etc.).
>
> When Michael Dell was asked about providing Linux pre-installed, his
> response was "which one?". From his viewpoint, he has to either pick one
> distro or try to support many distros. He believes neither option is
> viable for his business, and I think he is right.
>
> If you think I am wrong about this, please explain. I will listen.
>
> Wes Morgan wrote:
> > Most of you have probably seen ESR's recently-slashdotted essay about
> > what Linux needs to do to conquer the desktop computing world by the
> > end of 2008 (and why we need to do it by then--hint: because of the
> > 32-to-64-bit transition). If not, you can read it here:
> >
> http://www.catb.org/~esr/writings/world-domination/world-domination-201.html
> >
> > Here are the "what it will take win" points from the essay:
> >
> >     1. Drivers for all major existing hardware.
> >     2. 32-bit legacy platform emulation.
> >     3. Surviving the killer app.
> >     4. Enabling preinstalls.
> >     5. Support for all major multimedia formats.
> >
> > We're in pretty good shape on numbers 1 (we have the source code for
> > lots of legacy hardware drivers, so 64-bit support is a recompile
> > away) and 3 (because of the rise of web apps, an OS-specific killer
> > app is less likely). But we need to do some work on 2, 4, and 5. In
> > fact, solving 2 and 5 are dependencies (but not the only ones) of
> > solving 4.
> >
> > So, we need good multimedia support out-of-the-box (to the point where
> > we have something OEMs can pre-install on new computers) and solid
> > Win32 software support (the bulk of legacy 32-bit software that can't
> > easily be moved to 64-bit Linux will be Win32 apps). We don't have
> > time to wait for the legal situation to improve, nor do we have time
> > to wait for our efforts to persuade content providers to use open and
> > free codecs to come to fruition. The 2008 deadline is pretty hard, as
> > the essay shows. (Because of the 32-to-64-bit transition. I know, I
> > was skeptical too, but read the whole essay.)
> >
> > It seems to me that Ubuntu is easily the front-runner of desktop
> > Linux, for a number of reasons I needn't go into here. I'd really like
> > to see it position itself to tackle bug #1 (Microsoft's majority
> > market share) via this 64-bit transition window, but I think we need a
> > strategy to do so.
> >
> > Specifically, I believe Ubuntu should work closely with Linspire to
> > bundle their "Codex" (basically a CD full of licensed proprietary
> > multimedia codecs) with Ubuntu. (See the last paragraph of the essay.)
> > This could take the form of charging for the "multimedia" version of
> > Ubuntu that comes with this CD, as well as making it extremely easy
> > (put the CD in the drive and click "OK") to install the Codex later on
> > any Ubuntu system. We could even charge a little extra or ask for
> > donations to support giving away this "multimedia" version of Ubuntu
> > to schools or other non-profits. And possibly, in countries with less
> > screwed-up laws than certain other countries (I'm looking at you,
> > U.S.), we could just give this CD away.
> >
> > This would then be the version of Ubuntu that we would encourage OEMs
> > to put on new systems, and the installer would ask people to insert
> > the Codex CD during installation. (And if they didn't have one, the
> > installer could ask if a user wanted to purchase the Codex right then,
> > take the payment info, and then download and install the Codex in one
> > fell swoop.)
> >
> > But the most important thing would be this: As the authors of the
> > above essay stress, Ubuntu would want to go into this situation with a
> > clear plan for getting out of it at some point. Once Linux is the
> > dominant desktop distro, we should stop playing the proprietry codec
> > game and start demanding open codecs. Ubuntu should set a policy that
> > all use of the Codex be phased out by 2015 (or whatever), and then
> > incremental phases leading up to that to transition us away from it.
> > Maybe even set market share triggers (for example, when Linux desktop
> > market share hits 30%, drop codecs X, Y, and Z from being supported in
> > the next release) in order to drive demand for open and free codecs.
> > An easy target to set is to drop MP3 from the Codex in 2010 when its
> > patents expire (and instead bundle it with the OS directly).
> >
> > In theory we could just keep doing the Wine-bundling until users no
> > longer demanded it, so I don't think we need a sunset policy on that
> > like we do for the proprietary codecs. One thing the essay points out
> > that we should keep in mind, however, is that our bundled Wine must
> > NOT emulate Win64. Otherwise, we'll have the OS/2 effect where it's
> > Win16 support was so good, no one bothered writing OS/2-native apps
> > because the one Windows app covered those users too. We don't want
> > Win64 to == Win64 and Lin64 support.
> >
> > What do Ubuntu devs and interested community members think of this? I
> > definitely want to help drive this effort where I can, but I want to
> > see where folks are at first. Should I make this a spec (should
> > probably be two specs)? The Codex doesn't really exist yet, but the
> > basic idea is obvious enough that a first draft could be put together
> > for that, and the Wine stuff is probably already out there in
> > spec-land to some extent.
> >
> > I think if we go into this with our eyes open and a plan for using the
> > leverage we would attain to move things back towards the open and free
> > end of the spectrum, we could have much greater progress towards
> > closing bug #1 than if we continue doing what we're doing now. Like
> > ESR says in the essay, "We can't set the standards until /after/ we
> > take over the world."
> >
> > Wes Morgan
> >
> >
>

-- 
"Small acts of humanity amid the chaos of inhumanity provide hope. But small
acts are insufficient."

- Paul Rusesabagina, Rwandan and former hotel manager whose actions inspired
the movie Hotel Rwanda
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/ubuntu-devel-discuss/attachments/20061227/804f97fa/attachment.html>