Re: New stable version after Sarge
On 04-Jan 09:45, Steve Greenland wrote: On 04-Jan-05, 07:40 (CST), Paul van der Vlis [EMAIL PROTECTED] wrote: One of the biggest disadvantages of Debian for me is the long time it takes for a new stable version. If you want Ubuntu or Progeny, you know where[1] to find them. :-) Seriously. There's just no way you're going to change the way Debian makes releases, or rather, doesn't. It's too big, and there are just too damn many people involved, many of whom simply don't care about releases. As long as we maintain our current release criteria (which I don't necessarily think we should change) we will get slower and slower as we get bigger and bigger. Steve [1] Okay, just in case you don't: http://www.ubuntu.com/, http://www.progeny.com How large of a change would it be to switch to a goal based releases? More along the lines of new installer for sarge and once all release goals have been met tag a release and only accept new packages that fix RC bugs. or Use popularity-contest results to find a core set of packages and make a release more time based, but only count RC bugs from those core packages (Maybe those packages that would fit on 2 CDs?) Debian is a great distro, but I can't really use it anywhere other than a static server (and even then woody's SpamAssassin is much too out of date to be usefull.) If an organization _needs_ the security and stability of hopefully^W historic debian release, than there is Progeny or decent admins to keep things running. It would be nice if testing really was Testing a whole set of packages where with every new release it was quickly switched to a new snapshot of Sid, or Sid when some major release goals where met. Thomas
Re: New stable version after Sarge
On 05-Jan 09:30, Jose Carlos Garcia Sogo wrote: El mié, 05-01-2005 a las 04:16 -0800, Stephen Birch escribió: Paul van der Vlis([EMAIL PROTECTED])@2005-01-04 14:40: Hello, One of the biggest disadvantages of Debian for me is the long time it takes for a new stable version. I guess one man's meat is another man's poison. Since I administer a large number of distant computers I view the long time between stable releases as a feature not a bug. What about saying something like: the next stable release comes in the beginning of 2006? Once a year works for me, but any more frequent would be a pain in the neck. Frankly a release every 18 months seems about right. I agree with you on this. People using stable can not cope with upgrades each 6 months or so. Is that really true? I would love to run apt-get dist-upgrade every half a year. Currently it doesn't get me much. :) Now, for production systems, don't you do some testing *before* you upgrade the OS? When debian release on a much fast and predictable schedule, it might be nice to have longer security support. Maybe the security team would only really _track_ security related problems and remind maintainers that they needed to update thier debs in Stable-1, and Stable-2. Thomas
Re: Debian should not modify the kernels!
On Mon, 22 Sep 2003 22:04:15 +0200 martin f krafft [EMAIL PROTECTED] wrote: I'd appreciate if you would not quote me on a mailing list without my consent. Anyhow... also sprach Florian Weimer [EMAIL PROTECTED] [2003.09.22.2114 +0200]: It's a well accepted fact among kernel developers that vanilla kernel.org kernels should not be used by end users. Could you point me to some reference on this, please? Albeit rather advanced, I am an end user that uses the vanilla kernels, so I should know some reasons. The ptrace bug fix took two monthes to be fixed in a stable kernel. The arguement was that end users use a distro kernel that would pick up the fix, and if you used kernel.org, you would read the lists to get the fix (ie, you patch kernel.org, if that's what you run). Releases have been much more frequent since then... Thomas pgpMwEFYNodgL.pgp Description: PGP signature
Re: [PROPOSAL] Debian Release Plan
On Sat, 2 Aug 2003 01:25:51 -0400 Matt Zimmerman [EMAIL PROTECTED] wrote: If something has been in unstable for a year and hasn't managed to have few enough bugs to make it into testing, then I don't care to have it in the release (either the older or newer version). But this is software that users _use_. KDE and GNOME may be bad cases here as they seem to be too large for rc bugs to really give a usefull idea on the relative stability of the software hidden behind the package name. There really isn't a reason for users to _ever_ really not use the lastest stable release of KDE (at least that's been my impression for the last two stable releases of KDE). I would note that _every_ liveCD based on debian ships with non-maintainer releases of KDE and GNOME from testing (or even from unstable, iirc.). Thomas -- - mdz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] pgpqFz1zazaZm.pgp Description: PGP signature
Re: Are we losing users to Gentoo?
On Sat, 23 Nov 2002 19:37:02 + Andrew Suffield [EMAIL PROTECTED] wrote: [snip] Turning on IDE DMA is a performance improvement of around a factor of 6-10 (2-3Mb/sec - 25-40Mb/sec), for disk-bound operations. You can get *more* than a 6-times improvement in performance? Well, no. But then, I've not had to do anything other then use a 2.4 kernel to get IDE DMA. But most desktop work is letency based and using a kernel with the low latency patch and preempt cuts max latency by about 6 times based on some workloads ( 600ms -- 20ms ). Under debian's X/glibc/kde I can't move windows with contents without 'tearing.' Something is seriously wrong, most likely with your display driver. You should be able to achieve this on a 486, albeit at a lower resolution. Yep. I was using the nv driver from then woody's X. I blows chunks. The non-free Nvidia driver works fine but taints the kernel (and causes random crashes sometimes.) I would bet that debian's nv driver has gotten much better over time as newer X versions move into testing. X is CPU bound if you can't move windows smoothly because it has latency that is too high. Moving windows around is a memory-to-framebuffer-throughput-bound operation, not a CPU-bound one (unless your processor is really slow and your resolution is absurdly high). Even with DRI, moving a window about over mozilla peged my 1GhZ duron. Well, I guess 1600x1400 is absurdly high, but I like how the fonts look (even the non-true type ones.) Thomas pgp6uEJiXJetZ.pgp Description: PGP signature
Re: Are we losing users to Gentoo?
On Thu, 21 Nov 2002 13:33:29 + Andrew Suffield [EMAIL PROTECTED] wrote: Let me just say as a desktop user of Gentoo. I can use gentoo's X server and the opensouce nv driver here with kde and have a usable desktop. I couldn't in debian, it was just too slow. Yes, it's anticdotal. Yes, this is the sort of anecdotal 'evidence' that is of no use whatsoever. Most of the time it turns out to be a matter of local system configuration. IDE DMA is one of the bigger culprits here. Is it really? I tweeked debain on this box untill it hurt. I was slowly replaceing everything by hand to compile it with decent optimizations. As a user, forcing build changes is hard even with apt-get source (and apt-src). Beleive me, this is much more then turning on IDE DMA. Under debian's X/glibc/kde I can't move windows with contents without 'tearing.' I can with gentoo. 5% better really makes a difference if you hit that code often. Debian already optimizes the kernel and (IIRC) glibc somewhat. X would really be nice...and kde/gnome would be even better. It's a game of deminishing returns for almost everything else (as they are usaully IO bound, not CPU). X is CPU bound if you can't move windows smoothly because it has latency that is too high. Don't get me wrong, I _like_ debain, but it didn't work for me on the desktop--debian actively fights users who want to compile with local optizations (and yes, pbuilder is a hack). Gentoo works for me, even if I don't really enjoy (other than the geek factor) compiling everything. It is the bleeding edge though. Gentoo does have testing of builds (package masks) and security fixes, sometimes before most other distros (debian included). Security is really one of the more intresing features of debian; the comment of a security team to fix security bugs in stable. Thomas pgpCGX7kYDkl1.pgp Description: PGP signature
