sidux
Many swear seem to swear by sidux, though its claim to turn "unstable
into a stable and reliable operating system for every-day usage" seems at odds with common sense, especially given its own advice to avoid dist-upgrades in the middle of "serious work" because "any package in sid can break at any time, and any person can be the first to discover it, especially if it is not a standard sidux package." I'm obviously never going to get a considered, impartial appraisal from their forum and IRC channel, so has anyone here tried sidux only to find that Testing was better suited to their desktop needs? Regards, Michael -- To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org |
sidux
Michael,
I wanted to put Debian on a new Thinkpad X61s, and to achieve that with minimal pain, I went with sidux. I created a USB-stick to install it, and it went as smooth as can be. I'm using the machine with wifi. All hitches were simply the result of my ignorance. The applications I've installed (not many so far because I started with only a base system), work fine. I don't bother with any desktop manager, but use fluxbox instead. -- Haines Brown, KB1GRM -- To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org |
sidux
Haines Brown wrote:
Michael, I wanted to put Debian on a new Thinkpad X61s, and to achieve that with minimal pain, I went with sidux. I created a USB-stick to install it, and it went as smooth as can be. I'm using the machine with wifi. All hitches were simply the result of my ignorance. The applications I've installed (not many so far because I started with only a base system), work fine. I don't bother with any desktop manager, but use fluxbox instead. Thanks, With Fedora as my current desktop I'm used to ongoing minor breakages, though from the explanation in Martin Krafft's book Sid, and by implication sidux, is probably too chaotic a proposition for my (non-hobbyist) needs. -- To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org |
sidux
On Mon, Apr 14, 2008 at 10:29:19PM +0100, Michael C wrote:
> Haines Brown wrote: >> Michael, >> >> I wanted to put Debian on a new Thinkpad X61s, and to achieve that with >> minimal pain, I went with sidux. I created a USB-stick to install it, >> and it went as smooth as can be. I'm using the machine with wifi. >> >> All hitches were simply the result of my ignorance. The applications >> I've installed (not many so far because I started with only a base >> system), work fine. I don't bother with any desktop manager, but use >> fluxbox instead. > > Thanks, > > With Fedora as my current desktop I'm used to ongoing minor breakages, > though from the explanation in Martin Krafft's book Sid, and by > implication sidux, is probably too chaotic a proposition for my > (non-hobbyist) needs. I have very strong opinions on the use of testing versus unstable for non-hobbyist needs. First the purpose of testing is just that, to test the distribution. A testing user should be willing and able to poke and prod the system looking for and reporting bugs. And that user should be willing to live with those bugs for an extended period of time. And be willing to live _without_ particular packages for a while. We saw a lot of this late in the game when etch was in testing. Users would use it for a while, see that it was in pretty good shape but suffer when a particular bug hung around for a while. The crucial bit that many miss is that new packages don't move into testing unless they've sat in unstable with no new bug reports for 10 days (I think). That means that if something breaks in testing, there's a minimum of 10 days of waiting after the initial bug report before the bug fix could even think of migrating into testing. If you throw a couple of other wrenches in the works, you could be looking at an extended period of breakage. So yeah, testing is more stable than sid, but could also bite you pretty badly. Contrast that with sid, bug fixes happen fast. It seems, in my limited experience, that serious bugs that get caught in sid rapidly disappear, sometimes within hours. Sure there's more churn and potentially more opportunities for breakage, but it seems to be pretty short-lived. I've run sid on my desktops for about 4 years now (wow! when did that happen) and I can count on one hand the number of times I've had a serious enough breakage to cause a real problem for my work. And I can count on one finger the number of breakages that required real work to get out of (unbootable system...). I personally wouldn't run a testing system for regular use. I would run sid or stable (with backports as needed). Of course, YMMV. .02 A |
sidux
Andrew Sackville-West wrote:
> The crucial bit that many miss is that new packages don't move into > testing unless they've sat in unstable with no new bug reports for 10 > days (I think). Or 5 days (urgency=medium in changelog). Or 2 days (urgency=high). Or 1 day if it's a bad enough problem (urgency=emergency). -- see shy jo |
sidux
On Mon, Apr 14, 2008 at 06:25:11PM -0400, Joey Hess wrote:
> Andrew Sackville-West wrote: > > The crucial bit that many miss is that new packages don't move into > > testing unless they've sat in unstable with no new bug reports for 10 > > days (I think). > > Or 5 days (urgency=medium in changelog). > Or 2 days (urgency=high). > Or 1 day if it's a bad enough problem (urgency=emergency). thanks Joey. In your opinion, am I right in my assessment that testing is more likely to be in an unusable state for longer than sid? (at least at the package, not system, level)? I have been making this claim for a while, but it's really only based on my intuition of the situation and not any direct experience. A |
sidux
Michael C <sieverfrisch@yahoo.ie>:
> > I'm obviously never going to get a considered, impartial appraisal from > their forum and IRC channel, so has anyone here tried sidux only to find > that Testing was better suited to their desktop needs? I've never run Sid. I do support a user who wants to play with (among other things) Sidux. He's an enthusiastic noob, and is doing fine with Sidux so far, on a secondary sandbox machine. :-) You can drop in a second, kickass system (sandbox, used hardware) for C$160.00. Why not? -- Any technology distinguishable from magic is insufficiently advanced. (*) http://blinkynet.net/comp/uip5.html Linux Counter #80292 - - http://www.faqs.org/rfcs/rfc1855.html Please, don't Cc: me. -- To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org |
sidux
Andrew Sackville-West wrote:
On Mon, Apr 14, 2008 at 10:29:19PM +0100, Michael C wrote: Haines Brown wrote: Michael, I wanted to put Debian on a new Thinkpad X61s, and to achieve that with minimal pain, I went with sidux. I created a USB-stick to install it, and it went as smooth as can be. I'm using the machine with wifi. All hitches were simply the result of my ignorance. The applications I've installed (not many so far because I started with only a base system), work fine. I don't bother with any desktop manager, but use fluxbox instead. Thanks, With Fedora as my current desktop I'm used to ongoing minor breakages, though from the explanation in Martin Krafft's book Sid, and by implication sidux, is probably too chaotic a proposition for my (non-hobbyist) needs. I have very strong opinions on the use of testing versus unstable for non-hobbyist needs. First the purpose of testing is just that, to test the distribution. A testing user should be willing and able to poke and prod the system looking for and reporting bugs. And that user should be willing to live with those bugs for an extended period of time. And be willing to live _without_ particular packages for a while. We saw a lot of this late in the game when etch was in testing. Users would use it for a while, see that it was in pretty good shape but suffer when a particular bug hung around for a while. That was certainly my experience running Etch for about a month in 2006... I'd just migrated from Windows but the bugs eventually drove me to Ubuntu. The crucial bit that many miss is that new packages don't move into testing unless they've sat in unstable with no new bug reports for 10 days (I think). That means that if something breaks in testing, there's a minimum of 10 days of waiting after the initial bug report before the bug fix could even think of migrating into testing. If you throw a couple of other wrenches in the works, you could be looking at an extended period of breakage. So yeah, testing is more stable than sid, but could also bite you pretty badly. Contrast that with sid, bug fixes happen fast. It seems, in my limited experience, that serious bugs that get caught in sid rapidly disappear, sometimes within hours. Sure there's more churn and potentially more opportunities for breakage, but it seems to be pretty short-lived. I've run sid on my desktops for about 4 years now (wow! when did that happen) and I can count on one hand the number of times I've had a serious enough breakage to cause a real problem for my work. And I can count on one finger the number of breakages that required real work to get out of (unbootable system...). I personally wouldn't run a testing system for regular use. I would run sid or stable (with backports as needed). Of course, YMMV. .02 A I'll bear that in mind, thanks :) -- To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org |
sidux
On Mon, Apr 14, 2008 at 03:09:26PM -0700, Andrew Sackville-West wrote:
> Contrast that with sid, bug fixes happen fast. It seems, in my limited > experience, that serious bugs that get caught in sid rapidly > disappear, sometimes within hours. Sure there's more churn and > potentially more opportunities for breakage, but it seems to be pretty > short-lived. > > I've run sid on my desktops for about 4 years now (wow! when did that > happen) and I can count on one hand the number of times I've had a > serious enough breakage to cause a real problem for my work. And I can > count on one finger the number of breakages that required real work to > get out of (unbootable system...). Just remember that a serious (is there such a thing as a non-serious) security bug doesn't usually show up as breakage. Doug. -- To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org |
sidux
Andrew Sackville-West wrote:
> On Mon, Apr 14, 2008 at 06:25:11PM -0400, Joey Hess wrote: > > Andrew Sackville-West wrote: > > > The crucial bit that many miss is that new packages don't move into > > > testing unless they've sat in unstable with no new bug reports for 10 > > > days (I think). > > > > Or 5 days (urgency=medium in changelog). > > Or 2 days (urgency=high). > > Or 1 day if it's a bad enough problem (urgency=emergency). > > thanks Joey. > > In your opinion, am I right in my assessment that testing is more > likely to be in an unusable state for longer than sid? (at least at > the package, not system, level)? No, I don't think so. If a package has a bug that makes it unusable, then a) Someone will generally notice a bug in the two weeks before that buggy package gets into testing, and file a RC bug to keep it out. b) If a bug that makes a package unusable does get into testing, it can be fixed in 2 days in most cases. c) The graph of release critical bugs[1] currently shows 1750 in unstable, and only 571 of those affect testing. (658 of them affect *stable*). http://bugs.debian.org/release-critical/ -- see shy jo [1] Not all of which actually make the package unusable for users, but many of them do. |
| All times are GMT. The time now is 10:51 PM. |
VBulletin, Copyright ©2000 - 2013, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.