On Mon, Nov 14, 2005 at 05:50:18PM -0800, Andy Streich wrote: > On Monday 14 November 2005 09:21 am, s. keeling wrote: > > Stability is what Debian was trying to produce when Murdock & friends > > began. That's still a cornerstone value. Considering all the > > downstream distributions based on Debian, that strategy is working well. > > I agree. But as a relative newbie myself I'd like to better understand the > rationale. > Better to try and understand it than to blindly criticize. > A newbie looking at the plethora of distros is one confused and mystified > individual. I chose Debian because of its open development model and > reputation for stability (and lacked the time to investigate the 100+ so > alternatives). The net-install was a quite a pleasure -- living without > sound until I bought new hardware was a small price to pay. My use is > primarily Java and web development and document writing. I don't need the > latest and greatest of everything. What I did find surprising after reading > this list for a while was that stable meant not only really stable but also > really slow release cycle. Okay, that's the price you pay for "really > stable." > In my case, I am willing to live with some out of date applications (I back port the apps that are critical to my work) so that I can be certain that my machine will always be functional, barring a hardware failure. > What seems odd to me is that a stable release is not just the OS and utilities > but also all the applications that run on top of them (15,000+ packages total > -- that certainly explains the release cycle time). Is the rationale that > this is the best way to do testing and configuration management? Is it just > a consequence of the way Debian has grown up? Or something else entirely? > The rationale is that the admin should expect that a package installed from the official Debian repository will *not* change behavior between releases. That is why security fixes are backported and not simply brought an as updated version of the package. There are certain packages, like those of the Mozilla family that violate this since it is not possible. Upstream, Mozilla is developed in such a way so to make backported security fixes nearly impossible and then they actively discourage such practices, which has been the cause of some tension between the Debian and Mozilla projects. The reason it is done this is so that I can depend on a known set of functionality that will not change for the life of the release. I can write a program and be certain that it will work even if security updates are made, since those security updates will not include a version bump of a core library that causes the app to break. Since not all programs in the world are packaged for Debian, simply looking at the applications in the official repository does not tell the whole story. > As a newbie I expected there to be a set of OS/utility packages that were > released together (say, for example, like Sun does with Solaris) and various > sets of application software that had independent release cycles. The Debian > model seems to be that all FLOSS software constitutes a "Debian release" and > once that release happens you can pick and choose what you want. Why is that > a good thing? > Unfortunately, the Debian project does not have enough people or infrastructure to make that happen. Please feel free to fund such an effort :-) > Any clarification on the above will be appreciated. I'm not throwing stones > here, just trying to figure out what the motivation is so I can better > understand the Debian way. > > Andy > HTH, -Roberto -- Roberto C. Sanchez http://familiasanchez.net/~roberto
Attachment:
pgpCLgWexjRzP.pgp
Description: PGP signature