If you are going to continue this thread, could you please do so on sounder instead devel-discuss? This sort of discussion really isn't appropriate or relevant for devel-discuss.
Thank you, Constantine Evans 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 > -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
