Здравствуйте. Мне кажется, что такой документ -- как раз то, что многие около ALT Linux надеялись увидеть с 2001 года.
В любом случае, интересное чтение и явная провокация примерить launchpad и bazaar к нашей камнеломне :-) PS: даю копии в полярные рассылки, просьба отвечать в одну. -- ---- WBR, Michael Shigorin <[EMAIL PROTECTED]> ------ Linux.Kiev http://www.linux.kiev.ua/ ---- visit our conference (Oct 1): -- http://conference.osdn.org.ua
--- Begin Message ---Corey Burger wrote: >http://www.libervis.com/modules/smartsection/item.php?itemid=28 > > Sigh. Attached is a working draft of an "SABDFL FAQ" to address some of this, comments welcome. MarkFrequently Asked Questions about Ubuntu's Direction and Intent
This document is maintained by Mark Shuttleworth. I'm happy for other website editors to modify it, please just drop me an email with your additions or clarifications. It's written from my perspective ("I") since the buck, technically, stops here. So add to it on my behalf with care, please ;-)
Ubuntu is not without its controversies. This is a good thing (at least IMO - MarkShuttleworth) as it suggests we are both challenging the status quo, and taking some risks. Speaking for myself, my motivation for funding and participating in Ubuntu so heavily is in large part derived from a desire to do both of those things, I enjoy shaking up established lines of thinking, and I enjoy taking risks. This document exists to give the community some insight into my thinking, and to a certain extent that of the Community Council, Technical Board and other governance structures - on some of the issues and decisions that have been controversial.
I will try to address rumours, frequently asked questions, common allegations and neuroses, and of course controversies both within the project ("our default desktop should be *purple*") and in the open source community at large ("alert! alert! ubuntu is going to become a commercial project!"). You may have come across variants of both of those in the wild. You can take this document as canonical (;-)) for my perspective on them, and where noted, you'll also get the Ubuntu Community Council or Technical Board position. If you would like to see additional things addressed here, please raise them at a Community Council meeting on IRC, or correspond with me or the CC members, or raise it on ubuntu-devel.
Will Ubuntu ever be have licence fees or royalties?
No. Never. I have no interest in joining the proprietary software industry, it's a horrible business that is boring and difficult, and dying out rapidly anyway. My motivation and goal is to find a way to create a global desktop OS that is *free*, in every sense, as well as sustainable and of a quality comparable to anything you could pay for. That's what I'm trying to do, and if we fail, well then I will go and find some other project to pursue rather than get into the proprietary software business. I don't think any of the core ubuntu developers, or much of the community, would stick around if I went loony and decided to try this, anyhow.
If that isn't enough for you, then you will be happy to know that Canonical has signed public undertakings with government offices to the extent that it will never introduce a "commercial" version of Ubuntu. There will never be a difference between the "commercial" product and the "free" product, as there is with Red Hat (RHEL and Fedora). Ubuntu releases will always be free.
That said if you want to pay for Ubuntu, or something that includes Ubuntu code, you probably can. There is already Ubuntu code in Linspire, which you can pay for (w00t!). Though Linspire is not (yet) an Ubuntu derivative, per se, it's not unlikely to happen in the future. There are likely to be many specialised versions of Ubuntu, under other brand names, that have commercial or proprietary features. They might have proprietary fonts or software or add-ons or integration with services, etc. There is also likely to be quite a lot of proprietary software available for Ubuntu (there is already a fair bit - Opera for Ubuntu was announced recently, for example). But Canonical, and I myself, and the Ubuntu Comunity Council and Technical Board, will not produce an "Ubuntu Professional Edition ($XX.00)". There will certainly be no "Ubuntu Vista".
If you don't make a commercial "Ubuntu Professional Edition", how can Ubuntu be sustainable?
I don't know. Seriously. I don't have all of those answers. That's OK, this is a risky (ad)venture, which is still at an early stage, so I don't expect to know. I can personally justify my investment in Ubuntu on philanthropic grounds (at least, the money we spend on open source development and on tools for open source developers, like Launchpad) because most of my good luck and wealth could only have been created using open source tools, so I'm happy to give back to the community. Inasmuch as we start to spend money on suits, they need to be sustainable quickly. We currently make some money offering certification related services (certifying developers, administrators, applications, and hardware) as well as customisation services (you want your own distro, based on Ubuntu, let's talk). Demand for those services is growing. I'm pretty confident that I can get Canonical to break even on that basis. And breaking even is fine by me, because it means that Ubuntu will continue to rock even if I decide it's time to go back to space and pick the wrong Soyuz.
With the announcement of the Ubuntu Foundation, I was basically saying "OK, this project has legs, I'll commit enough capital to keep the core going for a long time no matter what happens to me or Canonical". So we have plenty of time to grow sustainability around the project. If you want to help on that front, send work to Canonical next time you need something done with Ubuntu. We won't let you down.
What about binary compatibility between distributions?
A lot has been said about the fact that Debian is not binary-compatible with Ubuntu. Sometimes this manifests itself as "I can't install Ubuntu packages on Debian", sometimes its more "Why does Ubuntu use GCC 4 when Debian is using GCC 3.3?". Or "Why is the kernel and glibc on Ubuntu 5.04 different from that in Debian Sarge?". I'll try to address all of those here.
I'll start with our general policy and approach, and then examine some of those examples in detail.
First, "binary compatibility" means different things to different people. If you've followed the trials and tribulations of the LSB standards process, you'll understand how difficult it is even to *define* binary compatibility in a meaningful way across multiple distributions. That, in essence, is why we don't set "binary compatibility" as a goal for Ubuntu. Sometimes it happens, but if so it's accidental or because there was an opportunity to make something work nicely that someone took - not because its a specific goal.
Just to be clear, I'll say it again, for the record. We don't aim for "binary compatibility" with any other distribution. Why?
In short, because we believe in Free Software as a collaborative process focused on SOURCE CODE, and consider it superior to the proprietary process which is focused on specific applications and binary bits. We choose to devote the large majority of our energy to the improvement of the source code that is widely and freely available, rather than trying to work on binary bits that cannot be shared as widely. When we spend hours of time on a feature, we want that work to be usable by as many other distributions as possible, so we publish the source code in "real time" as we publish new versions of the packages. We go to great lengths to make those patches widely available, in an easy to find format, so that they will be useful to upstreams, and other distributions. That benefits Debian, but it also benefits Suse and Redhat, if any of them are willing to take the time to study and apply the patches.
We syncronise our development with upstream, and with Debian, and with other distributions such as Suse and Gentoo and Mandrake and Redhat, on a regular basis. We draw code from the latest upstream projects (which might not even be in Debian, or in RedHat, or addressed in the LSB). We try to merge with Debian Unstable (a.k.a. Sid) every six months. We have no control over the release processes of other distributions, nor of upstream, so it would be impossible for us to define in advance an API or ABI for each release. We are in the hands of hundreds of other developers every time we freeze Ubuntu in preparation for a new version. Even though the Ubuntu community is substantial and growing rapidly, it is still tiny compared to the total number of developers working on all the free software applications that make up the distribution itself. Our job is to package what is there, efficiently and cohesively, not to try to massage it to some pre-defined state of compatibility. We focus on delivering the newest-but-stabilised-and-polished versions of the best open source applications for your server or desktop. If we were to set binary compatibility (at any level) as a top priority, it would massively diminish our ability to deliver either newer software, or better integration and polish. And we think our users care most about the fact that they are getting the best, and most integrated, apps on the CD.
It is worth noting that the Linux kernel itself takes the same approach, shunning "binary compatibility" in favour of a "custom monolithic kernel". Each release of the kernel requires that it be compiled separately from previous releases. Modules (drivers) need to be recompiled with the new release, they cannot just be used in their binary form. Linus has specifically stated that the monolithic kernel - based on source code, not trying to maintain a binary interface for drivers across releases - is better for the kernel. We believe the same is true for the distribution.
So the imperative to work with very current code overrides the idea of maintaining compatibility with a specific ABI, especially if we have little or no say in the ABI we should be trying to remain compatible with.
But, I heard that Ubuntu is LESS compatible than other similar projects?
If you touch or change the kernel, or x server or clients, or libc, or compiler, you have effectively made yourself incompatible. And as far as I am aware every significant distribution has, with good reason, invested work in those components to ensure that they meet the needs of their users. In the process, they make themselves "binary incompatible". What makes open source work despite this, of course, is the fact that source code and patches usually travel across distros, which is why we focus our attention there, not on the binary bits. It is possible to build a new distribution using only package selections from another distribution, and that's useful. It's like the CDD project - and will in future I think be important in the ubuntu world too. But it's not fundamentally very interesting - it's just package selection, which is useful for a specific set of users but does not advance the state of the open source art.
How about some specific examples?
There are some good examples of other distributions doing the same thing. Since Ian Murdock and Progeny have been very vocal about this, let's start there. Progeny 1.x was not "binary compatible" with the current Debian stable release at the time. Yes, really. The current "DCC Alliance" release uses a different kernel, and different LibC, to Debian Sarge. In both cases, however, source code patches will transport quite happily from those projects to Ubuntu, and to Debian, and we are happy to take them. That's what makes open source development more constructive than proprietary development.
Why was Ubuntu 5.04 (Hoary Hedgehog) not "binary compatible" with Debian Sarge?
Many people report no problems moving packages between Ubuntu 5.04 and Sarge. But they are not entirely compatible. Ubuntu 5.04 and Debian Sarge have slightly, but significantly, different libc versions. When Ubuntu 5.04 was released, it WAS compatible with the version in Sarge, which was then in deep freeze. After the Hoary release, a change was proposed in Debian. In order to implement it, the Debian team would have to break compatibility with Hoary, which had already been released. This was discussed openly, and the decision was taken to make the change. We (at Ubuntu) absolutely believe this was the right decision by Debian. This is about open source, and we can collaborate effectively if we focus on the source code. Had Debian felt obliged NOT to implement the change, in order to maintain Ubuntu compatibility, then the open source world would in fact have been impoverished.
So inasmuch as there is a binary incompatibility between those two releases, it was not introduced by the Ubuntu team. Furthermore, we actively support the decision process that led to the incompatibility - that's what makes open source strong.
What about the GCC 4.0 transition? Why did you adopt GCC 4.0?
We always try to include the latest stable development tools, libraries, and applications. GCC 4.0 was released early in the Breezy (Ubuntu 5.10) development cycle, so it was the appropriate choice of compiler for that release. This meant that C++ applications compiled on Breezy would by default have a different Application Binary Interface (ABI) to the same libraries compiled in Sarge, which used GCC 3.
This was discussed with the Debian toolchain maintainers, who were themselves planning to adopt GCC 4 at some time. A plan was agreed with regard to the specific naming of binary packages compiled with GCC 4, so that there could be a graceful migration and upgrade process for users who were updating from a previous release of Ubuntu (or Debian). The Ubuntu team then went ahead and pioneered the work, providing patches for hundreds of packages to bring them into compliance with the agreed naming for GCC 4. These patches are available to all the Debian maintainers, and make their life a lot easier with the GCC 4.0 migration in Debian.
Is Ubuntu a Debian fork? Or spoon? What sort of silverware are you, man?
Yes, Ubuntu is a fork. No, it isn't. Yes it is! Oh, whatever.
In short, we are a project that tries hard to collaborate with many other projects - such as upstream X.org, and GNOME, and of course Debian. In many cases, the code we ship is modified or different to the code shipped by those other projects. When that happens, we work hard to ensure that our changes are published as widely as possible, in a format that is easy for other project maintainers to understand and incorporate into their own working tree.
In practice, we have gone to great lengths to develop tools that make it easy to collaborate with Ubuntu, and help us to collaborate with upstreams and other distributions. For example, we have an automatic patch publisher that shows Debian maintainers what patches for their packages are available for Ubuntu. It couldn't be easier for DD's to decide which patches they want, and which they don't. And frankly, it's a lot easier for us if they DO take them, but we can't force that. Many of the patches only make sense in Ubuntu. As a side benefit, these patches are also available for Gentoo, Red Hat, Linspire (yes, really) and Suse. And we know they check 'em out and use some of them, which is cool.
Collaboration goes beyond patches though. We have developed Malone, a bug tracker that explicitly tries to create collaboration between Ubuntu and other distros, and upstreams, on the fixing of bugs. Each bug can be tracked in lots of places, and in a single place you can see the status of the bug in all places. It's pretty cool.
One of the triggers that got me out of the "cosmonaut playboy international love rat of mystery" game and into Ubuntu was the emergence of tools like TLA, which it seemed to offer the promise of even better collaboration on source code between distros and upstreams. So we did a lot of work on TLA, to the point where it looked different enough to call it Bazaar. Then we did a ground up rewrite in Python, and the result is Bazaar-NG, or Bzr, which will be Bazaar 2.0 by March 2006. Why is this important? Because passing patches around is not nearly as effective as working in a genuinely distributed revision control system. Many of the Ubuntu guys don't work on the distro, they work on tools like Bazaar, and HCT, which we hope will really accelerate the kind of collaboration that is possible in the open source world. Time will tell.
In summary: binary compatibility between Ubuntu and Debian is not a priority for us. We believe we contribute more to the open source world by providing patches to make Ubuntu (and Debian) packages work better, and providing a cutting edge (or bleeding edge, depending on your perspective) distribution for others to collaborate with. We invest a lot of energy in making sure our patches are widely published and easily available to developers of ALL other distributions as well as upstream, because that way we think our work will have the biggest long term benefit. And we develop tools (see Bazaar and Bazaar-NG and Launchpad and Rosetta and Malone) that we hope will make source code collaboration even more efficient.
Why is Ubuntu not part of the DCC Alliance
I don't believe the DCC will succeed, though its aims are lofty and laudable. It would be expensive to participate, and it would slow down our ability to add the features, polish and integration that we want in new releases. I'm not prepared to devote scarce resources to an initiative that I believe will ultimately fail. There's no point here in going into the reasons why I think the DCC will fail - time will tell. I would encourage members of the Ubuntu community to participate in the DCC discussions if they have time and are interested. If the DCC produces good code, we should merge that into Ubuntu releases, and it should be easy to do so.
Why are you funding Ubuntu, instead of giving the money to Debian
I spent a lot of time thinking about how best to make a contribution to the open source world, and how best to explore the ideas I am personally interested in, such as the best ways to deploy open source on the desktop. One option was to stand for the position of DPL (I'm a DD, first maintainer of Apache in 1996 blah blah) and drive those ideas inside Debian. In the end I decided to create a parallel distribution, and invest in the infrastructure to make inter-distro collaboration a lot more efficient.
Here's why.
First, a lot of the things I want to do involve reducing the scope of the distro. That makes it MORE useful for one set of people, but quite clearly LESS useful for others. For example, we currently officially support only 3 architectures in Ubuntu. That's GREAT for people running those architectures, but clearly not so useful for people running something else.
Similarly, we support about 1,000 core apps in Ubuntu. Those are the core pieces that are in the "main" component for Ubuntu, Kubuntu and EduBuntu. Everything else is accessible, as part of universe or multiverse, but not officially supported.
The more I thought about it, the more I realised this was the wrong thing for Debian, which derives much of its strength from its "universality". It makes more sense to take these approaches in a separate project.
Second, the problem of "sharing between distributions" is the really interesting one. At the moment, we tend to see the world, as upstream, a distro, and derivatives. Actually, the world looks more like a bunch of different projects that need to collaborate. We need to collaborate with Debian, but we should also be able to collaborate with upstream, and with Gentoo. And with Red Hat, too. We need to figure out how to collaborate effectively with distributions that use totally different packaging systems to us. Because the reality of the open source world is one in which the nmber of distributions continues to rise - each one fulfilling the needs of a specific group of people, based on their job, or their cultural identify, or the institution for which they work, or their personal interests. Solving the "distro collaboration problem" would really advance the state of open source. So that's what we set out to do in Ubuntu. We work on Launchpad, which is a web service for collaboration on bugs, and translations, and technical support. We work on Bazaar, which is a revision control system that understands branching and distributions, and is integrated with Launchpad. And hopefully those tools allow us to make our work available easily to Debian, and to Gentoo, and to upstream. And also, allow us to take good work from other distros (even if they would rather we didn't ;-)).
And finally, it seems to me that the hard part is not making funds available, its allocating them to people and projects. I could easily write a cheque to SPI, Inc, for the same amount that I've invested in Ubuntu. But who would decide how that money was spent? Have you actually read the financial statements of SPI, Inc, over the past few years? Who would decide who gets hired full time, and who doesn't? Who would decide which projects get funded to be worked on, and which don't? As much as I admire the governance and social structures of Debian, I don't believe that it would be effective to allocate funds to it and expect to see the same level of productivity that we have been able to achieve in the Ubuntu project.
Mixing funding with volunteer work raises all sorts of issues. Ask Mako to tell you about the experiment that showed that this difficulty might be hard-wired into our genes - there are deep social difficulties with projects that blend full time paid work with volunteer efforts. I'm not sure Debian needs that kind of challenge.
OK, but why don't you call it "Debian for Desktops" then?
Because we respect the Debian trademark policy. You may have watched the mindbending contortions around the definition of "DCC Alliance" recently for an example of what happens when people don't. Very simply, the Ubuntu project is not Debian, so it has no right to use the name. And using the name would weaken Debian's own brand name. In addition, we like the "humanity" aspect of the name Ubuntu, so we chose that.
-- sounder mailing list [EMAIL PROTECTED] http://lists.ubuntu.com/mailman/listinfo/sounder
--- End Message ---
pgpWIvnB9a3ab.pgp
Description: PGP signature
_______________________________________________ smoke-room mailing list [email protected] https://lists.altlinux.ru/mailman/listinfo/smoke-room
