Re: Another testing vs unstable question
On Wed, Jun 23, 2004 at 05:12:06PM -0600, Jules Dubois wrote: On Wed, 23 Jun 2004 09:35:48 -0600, Monique Y. Mudama wrote: No, but [Red Hat] were always a company looking to make money off of their product (not that there's anything wrong with that). Debian has no such plans, and that's one of the reasons why I trust them to do what's right rather than what's profitable. As do we all(!), I'm sure Debian developers must sometimes do the wrong thing for the right reason or the right thing for the wrong reason. The key word here, and I quote, is trust. Debian's developers have earned the trust they're receiving. Well said! David -- Hi! I'm a .signature virus. Copy me into your ~/.signature to help me spread! -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Another testing vs unstable question
On Thu, Jun 24, 2004 at 02:05:32PM +0800, John Summerfield wrote: atm it seems impossible to get bugs fixed in Woody unless they're security-related. I know, someone's going to ask for an eg, and right now I can't think of one. Of course there are bugs discovered which a lot of people would like to see fixed. Mostly, these would not be release-critical bugs and most people would not run into them. So, `a lot of people' would mean a large absolute number, not a large part of the woody users. Anyway, that's what the point releases are for. Woody release schedule: - Debian 3.0, July 19, 2002 - Debian 3.0r1, December 16, 2002 - Debian 3.0r2, November 21, 2003 And I _think_ the third point release has been put off because of sarge. David -- Hi! I'm a .signature virus. Copy me into your ~/.signature to help me spread! -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Another testing vs unstable question
On Fri, 25 Jun 2004 04:04 am, David Fokkema wrote: that's what the point releases are for. Woody release schedule: - Debian 3.0, July 19, 2002 - Debian 3.0r1, December 16, 2002 - Debian 3.0r2, November 21, 2003 Oh well, that at least tells me what 3.0rn means. That's something, little though it is. And I _think_ the third point release has been put off because of sarge. So ... ?? Look, the issue WAS testing vs unstable. Some people think that not only the decision but its implementation is a simple matter. It isn't. My ISP does what many do - set up a multiple mirror site for the use of its members. Debian is included. I'd like to start up a Debian testing system from an install CD - I gather you can't do this for the unstable branch. In order to do this I really need jigdo - to just download a complete CD (or CDs) as I can with every other Linux distro or BSD, is de rigeur. BTW what is wrong with a clear major/minor dot numeric system, rather than woody/sarge/sid/potato/whatever=stable/testing/unstable(which is really quite stable anyway)/something ? MY ISP's relevant debian directories look like this: /debian-cd/hurd directory (four off) GNU-K4-CD1.iso (four off) hurd-J2-CD1.iso /debian-cd/images/current/i386/ directory (seven off) debian-30r2-i386-binary-1.iso /debian-cd/images/woody/i386/ directory (seven off) debian-30r2-i386-binary-1.iso debian-cd/jigdo/current/i386/ directory does NOT contain jigdo, but files like this: (seven off) woody-i386-1.jigdo (seven off) woody-i386-1.template Whither testing (sarge?) What does all this mean? And Monique and others think this is simple??? -- Regards, Brian -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Another testing vs unstable question
Brian Astill wrote: On Fri, 25 Jun 2004 04:04 am, David Fokkema wrote: that's what the point releases are for. Woody release schedule: - Debian 3.0, July 19, 2002 - Debian 3.0r1, December 16, 2002 - Debian 3.0r2, November 21, 2003 Oh well, that at least tells me what 3.0rn means. That's something, little though it is. And I _think_ the third point release has been put off because of sarge. So ... ?? Look, the issue WAS testing vs unstable. Some people think that not only the decision but its implementation is a simple matter. It isn't. My ISP does what many do - set up a multiple mirror site for the use of its members. Debian is included. I'd like to start up a Debian testing system from an install CD - I gather you can't do this for the unstable branch. In order to do this I really need jigdo - to just download a complete CD (or CDs) as I can with every other Linux distro or BSD, is de rigeur. BTW what is wrong with a clear major/minor dot numeric system, rather than woody/sarge/sid/potato/whatever=stable/testing/unstable(which is really quite stable anyway)/something ? MY ISP's relevant debian directories look like this: /debian-cd/hurd directory You don't want anything under hurd. It's incomplete, and probably less stable than unstable. (four off) GNU-K4-CD1.iso (four off) hurd-J2-CD1.iso /debian-cd/images/current/i386/ directory (seven off) debian-30r2-i386-binary-1.iso That's Woody, aka Stable /debian-cd/images/woody/i386/ directory (seven off) debian-30r2-i386-binary-1.iso So's that debian-cd/jigdo/current/i386/ directory does NOT contain jigdo, but files like this: (seven off) woody-i386-1.jigdo (seven off) woody-i386-1.template Yeah, you download those then fill in the template with jigdo, not necessarily from the same source. If you had an older Woody it would be a good way to get your CDs updated. Whither testing (sarge?) Check the Debian Weekly News and look for announcements about Debian Installer betas. Get the latest and use that: it's one CD and not especially large. Install the rest off the net if you can. What does all this mean? And Monique and others think this is simple??? Everything is simple when you understand it:-) -- Cheers John -- spambait [EMAIL PROTECTED] [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Another testing vs unstable question
On 2004-06-25, Brian Astill penned: And Monique and others think this is simple??? When did I say that? If you're referring purely to the naming conventions, I agree that they're confusing, but no one's been able to come up with a better way to handle it. Usually, the people proposing new names are, well, new to the system, and the names they suggest are based on a faulty understanding of the characteristics of the various options. Also, the devs have made it clear that changing the names would be a major pain in the butt; I guess I believe that there are more valuable issues on which they can spend their time. There are no one-word descriptions of the characteristics of the three options, so any name is going to be slightly flawed. It seems to be human nature to assume that stable-testing-unstable is a spectrum from rock-solid to flakey, and that may be the case at any given time, but that's not what defines them. I guess you just have to read enough debates that finally the lightbulb goes on and you get it. That's what finally happened to me last year some time. -- monique -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Another testing vs unstable question
Monique Y. Mudama wrote: On 2004-06-24, John Summerfield penned: Its only since its IPO that RH has become money-hungry. I am comfortable with the notion of paid-for support in the way of security advisories and bug-fixes: the only matter for debate is cost. Well, if I understood you earlier, you have paying clients. I guess having a paid support contract is a nice CYA maneuver in that kind of situation. After depressingly too many years of unemployment and tinkering, I found a part-time job that comes with toys to tinker with and payment for doing it. (I like debian better, but then, I've never tried the paid version of linux support; maybe it's just fantabulous.) Being unemployed, I never actually paid for support either. However, the level of support I want is bug-fixes for a realistic interval of time. The prices RH charges may be justified to enterprise users who want to oursource their maintenance, and even for the local real estate agent with a dozen or so sales staff and whatevery else they need to support those salesfolk. But not to a geek, even a greying geek. Indeed. While I disagree with much of the Debian project (before you jump in, I'd point ot that many of the Debian Developers disagree with each other too), I do admire their endevour and commitment to the project. Gd, do they ever disagree! I don't disagree with much of the project, but I'm right there with you. I think it's a lot like a quote I heard about the ACLU -- If you agree with half of what we do, you should contribute. If you agree with 75% of what we do, you should be on our Board of Directors! Something like that. No, what's missing is the testing infrastructure. *System* testing, not just the individual package. Better, I think to seek ways towards that ideal. Some cliches come to mind - the person who makes no mistakes does nothing, a journey of a thousand leagues begins with a single step... Right. The question is whether the product can realistically be improved/sped up or not. I'm reminded of that whole nine women can't make a baby in one month business. Not being a woman, I can't be sure, but I do recall my wife produced two in 4.5 months each:-) Full size too:-)) I haven't yet seen a Debian beta process, so I don't know what happens, but if (as I've read) the DDs are mostly running testing or unstable, then there has to be something wrong in _their_ estimation with Woody. Er. They *have* to run testing or unstable in order to test their packages! Not all of them have multiple boxes (or even permanent network connections); many of them may not be running mission-critical systems at home; and they're all experienced enough not to have to run stable to avoid the fear of accidentally doing a Bad Thing. Certainly they have to test on testing/unstable, but that doesn't necessarily require them to _run_ them:-) Heck, I was hacking on Debian running under RHL, and now one of my RHL systems (what I use of it) runs under Woody. I recently bought some Pentium IIs at auction. The docket recorded the winning bid as $2.50! They're certainly not ideal for _building_ kernels or xfree86, but there are lots of jobs they can do. I'm pretty sure all the debian servers run stable, although it would be interesting to hear if they don't. The recent move to subversion has had the effect of officially cutting Woody users off from the latest source - there is no offical Woody build of subversion. Eh? Whose recent move to subversion? I've been distracted by non-computer things recently; have I missed something? I think I felt the urge to hack on d-i: I eventually decided it was too much trouble. See http://www.nl.debian.org/devel/debian-installer/News/2004/8 I got the impression from other reading that sv is the new standard. And now a lot of people who aren't motivated enough to do a google search or ask on d-u are installing packages that haven't been fully tested with the system. The status quo at least ensures that the people who are using backports have at a minimum the ability to research questions. Do you think the current situration is perfect? If not, how do _you_ think it may be improved. There's a difference between imperfect and needs to be fixed. I stand by my belief that adding packages after the official release introduces risk. Now, would releasing a new version of stable more often be a good thing? I guess it depends on if it's deemed truly stable. atm it seems impossible to get bugs fixed in Woody unless they're security-related. I know, someone's going to ask for an eg, and right now I can't think of one. Okay, I'm way too tired for rational thought right now. Must go beddy bye ... Gah, it's early afternoon:-) A wet one too. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Another testing vs unstable question
Monique Y. Mudama wrote: On 2004-06-23, John Summerfield penned: I have been to www.apt-get.org and I got Mozilla from here, pine from there, KDE from somewhere else, Xfree from another... Do you get the picture? Well, just to be pedantic, you wouldn't find pine anywhere in debian because of its licensing terms. Not sure how pedantic you are being, but you do know that pine is available in non-free which while not part of Debian proper is hosted on the debian mirrors? apt-get source pine ... signature.asc Description: OpenPGP digital signature
Re: Another testing vs unstable question
Monique Y. Mudama wrote: On 2004-06-23, John Summerfield penned: I have been to www.apt-get.org and I got Mozilla from here, pine from there, KDE from somewhere else, Xfree from another... Do you get the picture? Well, just to be pedantic, you wouldn't find pine anywhere in debian because of its licensing terms. Quite irrelevant to the point. A coordinated, official system of official backports would be a fine thing, and the workforce to do it is already there - they're the people making these unofficial backports. Yes, but there's no way to test those backports thoroughly enough to match the amount of testing that went into stable in the first place. Do you believe that? Until Red Hat Linux 8.0, Red Hat had two cycles of releases: Major numbers, 5.x, 6.x, 7.x maintained binary compatibility. Those came out with about the same frequencies as Debian releases. And the dot-oh releases were well known to be buggy piles of crap. There was always some nasty gotcha lurking in the system. I don't know why that was the case, but it definitely held true from at least 4 to 6, maybe 7. Somewhere in there I stopped having to care because I switched to Debian. I switched over from OS/2 to 5.0. I was surprised later to discover people regarded it as buggy. I don't recall how much I used 6.0, but where I work we still have a 7.0 box in place: I chose 7.0 over 7.1 so as to have a 2.2 kernel as standard (required for a sat card). The most troublesome system I have is one running Woody, the video regularly gets stuffed up and it's prone to losing its keyboard. Changing the graphics card made no difference. Then there were the minor releases, x.[0-3] coming out at about six-monthly intervals. One could take a package from x.2 and install it with minimal bother on x.0 or x.1, with every expectation of not breaking anything. It's a model Debian would do well to look at and see how it can adapt it, adopt it. Using this model, Sarge would be 4.0, not 3.1 because it breaks binary compatibility (new gcc, new glibc). It sounds like a lot more work for the developers. RedHat had commercial customers to support their developers. How would you suggest Debian manage this? I thnk Red Hat didn't have commercial customers when it started on this model. As I already said, there are enough developers doing enough work - the packages are out there. What is missing official adoption by Debian, and the coordination that would follow its adoption. If there was an official line of built for Stable packages comprising packages people felt were needed, linked to from the dowload page, be sure a lot of people would try them out. If there are regular betas to test, new releases to run with then there is more news to get published on sites such as theregister.co.uk -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Another testing vs unstable question
On Wed, Jun 23, 2004 at 01:10:11AM +, John Summerfield wrote: David Fokkema wrote: On Tue, Jun 22, 2004 at 04:01:20PM +0800, John Summerfield wrote: Monique Y. Mudama wrote: Indeed. I actually meant my statement to be in support of the stable distribution. I guess I should have made that clearer. Still, no one benefits from having blinders over their eyes. Stable is the most stable, and it's also the least current. I don't see how it could be any other way. They're on opposite ends of the same spectrum. For me its lack of currency is becoming a serious problem. I'm deploying new systems: do I really want to deploy software that's not going to be supported much beyond a year? Do I really want to go through migration to new releases just after I've got it bedded down? That's the beauty of stable. It _is_ supported for well over a year. Actually, make that two years. The only problem _right now_ is that if you go with stable _now_, there is sarge coming. But apart from that, stable is supported for years. It's an on-going problem because new stables come out so infrequently. Someone deploying Sarge as soon as it becomes stable can look forward to four years (going on past performance) of support for it. I have no problem with that. Ok. The problem is someone deploying stable _now_ has a little over a year, someone deploying stable in two years can expect two years of life... The cycles are too long. If the cycles were shorter, people would install systems which would be outdated in less than six months time, to take a RedHat point release for an example. Right after 7.1, you would have 6 months. After _only three months_, you would have to start looking for 7.2. The cycles are too short. RedHat's and some other's, that is. Just my opinion, of course. I'm a refugee from Red Hat because its free support model became too short, and there was no paid-for support I found attractive (far too dear). If you found RedHat's cycle too short, why is Debian's too long? No I don't. My choices are going with testing: what then about security patches? or unstable? From my reading it's not unknown for unstable to be seriously borked for a time: I think new glibc did it a while ago, and gcc was forecast to do it shortly after. If I want to support a USB Laserjet 1200, then I really need the latest hpoj stuff: Woody is far too old. Woody is old, but have you looked at www.backports.org? A list of I have. well-supported backports is available there. Security updates will be a tad slower than unstable, which is behind stable. But then, you're not backporting glibc, but imap servers or whatever. I need my security updates _before_ they become a problem. Don't you? Of course. That's why I won't even think of installing testing on a server and won't install unstable either. In my opinion, servers should be running stable. So they do. But then, I like mutt on my server to be the same version as on my desktop running unstable. So I run that as a backport. Also, a newer spamassassin is nicer than the one from stable. These are both applications which run for local users and don't allow incoming connections or things like that. If there is a security problem with them, I can live with the slight delay. In my experience, security updates are thoroughly and quickly done by the DD and the people at backports.org read debian-security-announcements as well. Again, I'm not backporting glibc, some unsafe kernel, apache or a mail server. Probably that won't even be problem... What I find myself doing increasingly is building the occasional package from Sid for Woody: sometimes it's easy, sometimes it's too much trouble (think xfree where I think I found circular dependancies). Also, see www.apt-get.org for various backports, including xfree. But then, www.backports.org also has an xfree backport. Check it out. I have been to www.apt-get.org and I got Mozilla from here, pine from there, KDE from somewhere else, Xfree from another... Do you get the picture? Yes, I get it. Your sources.list grows. But if you have been careful constructing it (newlines, comments, etc.) you know what comes from where. What if the pine person also provided Mozilla? Or worse, glibc 2.3? It got completely out of control. Then don't go to apt-get.org and stick with backports.org. You have to specify new sources for _each_ package. You _only_ get what you want. My desktop system, while it still worked, was becoming a real mess until I upgraded to Sarge (not without some difficulty, the upgrade wanted to remove lots of kit I didn't want removed). Don't tell me I could pin things, until you point to the obvious documentation I missed. I won't. And what about security updates? I'm not going down that path with any system I'm paid to support. I agree with you. No testing
Re: Another testing vs unstable question
On Wed, Jun 23, 2004 at 06:32:08AM +, John Summerfield wrote: Monique Y. Mudama wrote: On 2004-06-23, John Summerfield penned: I have been to www.apt-get.org and I got Mozilla from here, pine from there, KDE from somewhere else, Xfree from another... Do you get the picture? Well, just to be pedantic, you wouldn't find pine anywhere in debian because of its licensing terms. Quite irrelevant to the point. A coordinated, official system of official backports would be a fine thing, and the workforce to do it is already there - they're the people making these unofficial backports. Yes, but there's no way to test those backports thoroughly enough to match the amount of testing that went into stable in the first place. Do you believe that? Yes, she does, and I do as well. And I _think_ (don't want to use some shadow force of people supposed to back me up) a lot of people on this list agree since they _are_ running Debian. Until Red Hat Linux 8.0, Red Hat had two cycles of releases: Major numbers, 5.x, 6.x, 7.x maintained binary compatibility. Those came out with about the same frequencies as Debian releases. And the dot-oh releases were well known to be buggy piles of crap. There was always some nasty gotcha lurking in the system. I don't know why that was the case, but it definitely held true from at least 4 to 6, maybe 7. Somewhere in there I stopped having to care because I switched to Debian. I switched over from OS/2 to 5.0. I was surprised later to discover people regarded it as buggy. I don't recall how much I used 6.0, but where I work we still have a 7.0 box in place: I chose 7.0 over 7.1 so as to have a 2.2 kernel as standard (required for a sat card). The most troublesome system I have is one running Woody, the video regularly gets stuffed up and it's prone to losing its keyboard. Changing the graphics card made no difference. Have you made extensive use of this list to try to do something about it? What is your problem? What is the system? Is the motherboard broke? I only ask that last one because woody is not supposed to be _that_ buggy. Was the new card another brand/model? Which drivers are you running? Did the box work fine before you installed woody? If you have any intention of seriously asking help for this, please start a new thread. Then there were the minor releases, x.[0-3] coming out at about six-monthly intervals. One could take a package from x.2 and install it with minimal bother on x.0 or x.1, with every expectation of not breaking anything. It's a model Debian would do well to look at and see how it can adapt it, adopt it. Using this model, Sarge would be 4.0, not 3.1 because it breaks binary compatibility (new gcc, new glibc). It sounds like a lot more work for the developers. RedHat had commercial customers to support their developers. How would you suggest Debian manage this? I thnk Red Hat didn't have commercial customers when it started on this model. As I already said, there are enough developers doing enough work - the packages are out there. What is missing official adoption by Debian, and the coordination that would follow its adoption. What would that be? Official adoption? If there was an official line of built for Stable packages comprising packages people felt were needed, linked to from the dowload page, be sure a lot of people would try them out. And lose some of that rock solid stability Debian is renowned for. If there are regular betas to test, new releases to run with then there is more news to get published on sites such as theregister.co.uk Maybe. A shorter release cycle would be great if that same stability could be retained. But I like Debian's release cycle philosophy: never hurry. If you do, you run into problems. If you don't agree with that philosophy, run unstable or another distro. That's the nice thing about Debian: it will do nothing to let you keep using it. Not that Debian is that arrogant, but because Debian has its uses for _some_ people. If you're not one of them, that's ok. David -- Hi! I'm a .signature virus. Copy me into your ~/.signature to help me spread! -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Another testing vs unstable question
David Fokkema wrote: The problem is someone deploying stable _now_ has a little over a year, someone deploying stable in two years can expect two years of life... The cycles are too long. If the cycles were shorter, people would install systems which would be outdated in less than six months time, to take a RedHat point release for an example. Right after 7.1, you would have 6 months. After _only three months_, you would have to start looking for 7.2. While RH was releasing about every six months, releases were supported by security (and other) fixes for some years. I think RHL 6.2 and 7.3 became unsupported last December. The cycles are too short. RedHat's and some other's, that is. Just my opinion, of course. I'm a refugee from Red Hat because its free support model became too short, and there was no paid-for support I found attractive (far too dear). If you found RedHat's cycle too short, why is Debian's too long? The support cycle was quite a deal longer than the release cycle. RH didn't drop support a year after the next release. I have been to www.apt-get.org and I got Mozilla from here, pine from there, KDE from somewhere else, Xfree from another... Do you get the picture? Yes, I get it. Your sources.list grows. But if you have been careful constructing it (newlines, comments, etc.) you know what comes from where. What if the pine person also provided Mozilla? Or worse, glibc 2.3? It got completely out of control. Then don't go to apt-get.org and stick with backports.org. You have to specify new sources for _each_ package. You _only_ get what you want. My desktop system, while it still worked, was becoming a real mess until I upgraded to Sarge (not without some difficulty, the upgrade wanted to remove lots of kit I didn't want removed). Don't tell me I could pin things, until you point to the obvious documentation I missed. I won't. And what about security updates? I'm not going down that path with any system I'm paid to support. I agree with you. No testing on servers. A coordinated, official system of official backports would be a fine thing, and the workforce to do it is already there - they're the people making these unofficial backports. Official? Debian has made its decisions: a great amount of freezing, testing, installing, testing, trying to break things, etc. goes into a stable release. The _whole_ system is tested, not individual packages. You can't do that for individual packages between stable releases, because updates come too fast. Run unstable for a while, you'll know what I mean. And hey! What's the difference between official and unofficial anyway? What kind of extra support do you expect if Debian would just label www.backports.org as official? For starters, links from the official website. Perhaps the hostname backports.debian.org, or the location www.debian.org/backports/ The ability to tick backports when doing a package search. Please, no. Debian stable is rock solid, something RedHat, in my opinion, has never been able to achieve. I would love to hear from people who are still running a RedHat system older than two years. I know of a lot of people who are running such Debian systems and are satisfied with it, apart from the usual thoughts: oh, would that I had _both_ that stability _and_ the newer software. But still, they choose stability. I've got three of these to care for: [EMAIL PROTECTED] summer]$ rpm -q redhat-release redhat-release-7.3-1 [EMAIL PROTECTED] summer]$ and one running RHL 7.0 that I've already mentioned. None of them has given any particular problems. We even had up2date working on one of them, but for various reasons I didn't usually bother with up2date. fwiw I was much amused when I first tried Knoppix (it was, I think, a 3.2 beta but it might have been 3.1). The hardware detection is done with Red Hat's tools. The RHL 7.0 system is due to retire. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Another testing vs unstable question
The cycles are too short. RedHat's and some other's, that is. This has been an interesting thread for us newbies. There seems to be no clear right answers. Rather, Debian provides several good choices so that you can choose what flavor best suits your needs. I was hot on Red Hat and then Fedora Core 1 as my first experiences with Linux. While I was very happy with FC1, moving to FC2 wasn't much fun. They advised a fresh install rather than using yum or up2date. I took the middle ground, letting anaconda on a full FC2 DVD handle my upgrade. I only had a few glitches, but the mail list was full of complaints. I decided to try Debian due to what I perceive as a more straightforward upgrade path that shouldn't require a fresh install each time. I started with Knoppix and have stayed with Sid upgrades. No problems so far, and I'm glad I made the switch! I've read here that starting with Knoppix isn't exactly advised, but the install was trivial with fantastic hardware detection etc, and the upgrades since have been fine. I'm not worried about the latest camera etc - just basic server functions. Thanks for the bandwidth and discussion! - John -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Another testing vs unstable question
On 2004-06-23, Travis Crump penned: Monique Y. Mudama wrote: On 2004-06-23, John Summerfield penned: I have been to www.apt-get.org and I got Mozilla from here, pine from there, KDE from somewhere else, Xfree from another... Do you get the picture? Well, just to be pedantic, you wouldn't find pine anywhere in debian because of its licensing terms. Not sure how pedantic you are being, but you do know that pine is available in non-free which while not part of Debian proper is hosted on the debian mirrors? apt-get source pine ... Now I'm confused. A search through packages.debian.org turns up gpg4pine and pine-docs, not to mention something called pine-tracker that appears to be a way to check your installed version of pine against the official version ... but no pine. gpg4pine is in contrib; pine-docs and pine-tracker are in non-free. I see no pine here; can you help me find it? -- monique -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Another testing vs unstable question
On (23/06/04 08:40), Monique Y. Mudama wrote: On 2004-06-23, Travis Crump penned: Monique Y. Mudama wrote: On 2004-06-23, John Summerfield penned: I have been to www.apt-get.org and I got Mozilla from here, pine from there, KDE from somewhere else, Xfree from another... Do you get the picture? Well, just to be pedantic, you wouldn't find pine anywhere in debian because of its licensing terms. Not sure how pedantic you are being, but you do know that pine is available in non-free which while not part of Debian proper is hosted on the debian mirrors? apt-get source pine ... Now I'm confused. A search through packages.debian.org turns up gpg4pine and pine-docs, not to mention something called pine-tracker that appears to be a way to check your installed version of pine against the official version ... but no pine. gpg4pine is in contrib; pine-docs and pine-tracker are in non-free. I see no pine here; can you help me find it? Hi Monique $ dpkg -l pine Desired=Unknown/Install/Remove/Purge/Hold | Status=Not/Installed/Config-files/Unpacked/Failed-config/Half-installed |/ Err?=(none)/Hold/Reinst-required/X=both-problems (Status,Err: uppercase=bad) ||/ Name Version Description +++-=-=-== un pine none(no description available) However, looking on aptitude I can only see associated packages too Regards Clive -- http://www.clivemenzies.co.uk strategies for business -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Another testing vs unstable question
On 2004-06-23, John Summerfield penned: Yes, but there's no way to test those backports thoroughly enough to match the amount of testing that went into stable in the first place. Do you believe that? The point of stable is not just that each package has been tested to the nth degree, it's also that the system as a whole has been tested -- the complex web of interactions among packages. In order to accept these backports into stable, we either have to perform the same amount of testing *on the whole system* as we did to release stable in the first place, or the system can't be certified to be truly stable. When we change one line on the flight software where I work, we can't just test the unit that was changed and move on. We have to perform the complete system test all over again to make sure nothing unexpected happens. The same concept applies to servers. I've worked in environments where we didn't test the system after making small changes. It's not pretty. I switched over from OS/2 to 5.0. I was surprised later to discover people regarded it as buggy. I don't recall how much I used 6.0, but where I work we still have a 7.0 box in place: I chose 7.0 over 7.1 so as to have a 2.2 kernel as standard (required for a sat card). It seems odd to me to choose a release based on the kernel, but okay. It seems *very* odd that you're telling us that RedHat switched major kernel numbers for a minor release. The most troublesome system I have is one running Woody, the video regularly gets stuffed up and it's prone to losing its keyboard. Changing the graphics card made no difference. Is it possible it's the motherboard? Those are some weird problems. It sounds like a lot more work for the developers. RedHat had commercial customers to support their developers. How would you suggest Debian manage this? I thnk Red Hat didn't have commercial customers when it started on this model. No, but they were always a company looking to make money off of their product (not that there's anything wrong with that). Debian has no such plans, and that's one of the reasons why I trust them to do what's right rather than what's profitable. It's also one of the reasons it's been suggested as a reference implementation a number of times. Debian developers are hard-working folk, but it's hard to work full-time for free. As I already said, there are enough developers doing enough work - the packages are out there. What is missing official adoption by Debian, and the coordination that would follow its adoption. No, what's missing is the testing infrastructure. *System* testing, not just the individual package. If there was an official line of built for Stable packages comprising packages people felt were needed, linked to from the dowload page, be sure a lot of people would try them out. And now a lot of people who aren't motivated enough to do a google search or ask on d-u are installing packages that haven't been fully tested with the system. The status quo at least ensures that the people who are using backports have at a minimum the ability to research questions. -- monique -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Another testing vs unstable question
On 2004-06-23, John Summerfield penned: David Fokkema wrote: Please, no. Debian stable is rock solid, something RedHat, in my opinion, has never been able to achieve. I would love to hear from people who are still running a RedHat system older than two years. I know of a lot of people who are running such Debian systems and are satisfied with it, apart from the usual thoughts: oh, would that I had _both_ that stability _and_ the newer software. But still, they choose stability. I've got three of these to care for: [EMAIL PROTECTED] summer]$ rpm -q redhat-release redhat-release-7.3-1 [EMAIL PROTECTED] summer]$ and one running RHL 7.0 that I've already mentioned. When you upgrade from 6.x to 7.x, or from 7.x to 8.x, can you do that? Just upgrade, as opposed to reinstall? This was something that seemed extraordinarily difficult when last I used RedHat, back in the dark ages. None of them has given any particular problems. We even had up2date working on one of them, but for various reasons I didn't usually bother with up2date. Why not? I'm not trying to poke holes or anything -- but a lot of RH enthusiasts point to up2date as a great tool. Why don't you like it? fwiw I was much amused when I first tried Knoppix (it was, I think, a 3.2 beta but it might have been 3.1). The hardware detection is done with Red Hat's tools. Why be amused? If RedHat licenses their stuff such that other systems can use it, and it works, it would be foolish to reinvent the wheel. That's one of the reasons people like open source so much. While I don't have any specific examples, I would be quite surprised if RedHat doesn't incorporate some of Debian's work, too. Again, it would be foolish not to. -- monique -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Another testing vs unstable question
On Wednesday 23 June 2004 02:32, John Summerfield wrote: Monique Y. Mudama wrote: [...] And the dot-oh releases were well known to be buggy piles of crap. There was always some nasty gotcha lurking in the system. I don't know why that was the case, but it definitely held true from at least 4 to 6, maybe 7. Somewhere in there I stopped having to care because I switched to Debian. I switched over from OS/2 to 5.0. I was surprised later to discover people regarded it as buggy. I don't recall how much I used 6.0, but where I work we still have a 7.0 box in place: I chose 7.0 over 7.1 so as to have a 2.2 kernel as standard (required for a sat card). I remember trying to switch to RH4.2. I never could sort out my hardware with it, so back to OS2... Coincidentally, I threw out the box from the 4.2 distro only yesterday. I`ve fished it out of the wastepaper basket. Here`s an extract from what it says on the box: UPGRADE FROM PREVIOUS RELEASES Because Red Hat Linux Release 4.2 is built with advanced RPM technology, your system will never become obsolete. As new releases become available you can upgrade any or all of your components to the newest versions using a simple upgrade program that does all the work for you... That was Red Hat, not Debian. hmm... I must look out the disks for 4.1, I probably still have them somewhere... must be valuable antiques by now... totters off, stroking beard -- richard -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Another testing vs unstable question
On Wed, 23 Jun 2004 09:35:48 -0600, Monique Y. Mudama [EMAIL PROTECTED] wrote: where I work we still have a 7.0 box in place: I chose 7.0 over 7.1 so as to have a 2.2 kernel as standard (required for a sat card). It seems odd to me to choose a release based on the kernel, but okay. It seems *very* odd that you're telling us that RedHat switched major kernel numbers for a minor release. Odd though it may be, it is true. RedHat 7.1 was the first RH release to use the 2.4 kernel. :-) 7.0: http://www.redhat.com/about/presscenter/2000/press_rhl7.html 7.1: http://www.redhat.com/about/presscenter/2001/press_sevenone.html -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Another testing vs unstable question
UPGRADE FROM PREVIOUS RELEASES Because Red Hat Linux Release 4.2 is built with advanced RPM technology, your system will never become obsolete. As new releases become available you can upgrade any or all of your components to the newest versions using a simple upgrade program that does all the work for you... That was Red Hat, not Debian. Sure sounds like Debian rather than the latest Fedora Core recommendations (clean install). I realize that FC is technically not Red Hat anymore, but. Many of the problems with the upgrade from FC1 to FC2 were probably related to the kernel change to 2.6. Yum and up2date seem like they are great within a major release, but getting from one release to another using them isn't even advised. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Another testing vs unstable question
On 2004-06-23, Ernie McCracken penned: On Wed, 23 Jun 2004 09:35:48 -0600, Monique Y. Mudama [EMAIL PROTECTED] wrote: where I work we still have a 7.0 box in place: I chose 7.0 over 7.1 so as to have a 2.2 kernel as standard (required for a sat card). It seems odd to me to choose a release based on the kernel, but okay. It seems *very* odd that you're telling us that RedHat switched major kernel numbers for a minor release. Odd though it may be, it is true. RedHat 7.1 was the first RH release to use the 2.4 kernel. :-) 7.0: http://www.redhat.com/about/presscenter/2000/press_rhl7.html 7.1: http://www.redhat.com/about/presscenter/2001/press_sevenone.html Oh, I believe it. It just serves to emphasize, in my mind, the idea that redhat and debian work from two completely different theories. Minor revision numbers shouldn't contain those kinds of changes! -- monique -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Another testing vs unstable question
On Wed, 23 Jun 2004 08:40:54 -0600, Monique Y. Mudama Now I'm confused. A search through packages.debian.org turns up gpg4pine and pine-docs, not to mention something called pine-tracker that appears to be a way to check your installed version of pine against the official version ... but no pine. You can only find pine in source form because it's licencing terms disallow distribution of binaries obtained from modified source IIRC. You must apt-get source pine and build the packages yourself. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Another testing vs unstable question
Monique Y. Mudama wrote: On 2004-06-23, Travis Crump penned: Monique Y. Mudama wrote: On 2004-06-23, John Summerfield penned: I have been to www.apt-get.org and I got Mozilla from here, pine from there, KDE from somewhere else, Xfree from another... Do you get the picture? Well, just to be pedantic, you wouldn't find pine anywhere in debian because of its licensing terms. Not sure how pedantic you are being, but you do know that pine is available in non-free which while not part of Debian proper is hosted on the debian mirrors? apt-get source pine ... Now I'm confused. A search through packages.debian.org turns up gpg4pine and pine-docs, not to mention something called pine-tracker that appears to be a way to check your installed version of pine against the official version ... but no pine. gpg4pine is in contrib; pine-docs and pine-tracker are in non-free. I see no pine here; can you help me find it? apt-get source pine Binaries aren't available due to the license but the source is from non-free from which you can easily build your own deb to install. signature.asc Description: OpenPGP digital signature
Re: Another testing vs unstable question
On 2004-06-23, Goedson Paixao penned: On Wed, 23 Jun 2004 08:40:54 -0600, Monique Y. Mudama Now I'm confused. A search through packages.debian.org turns up gpg4pine and pine-docs, not to mention something called pine-tracker that appears to be a way to check your installed version of pine against the official version ... but no pine. You can only find pine in source form because it's licencing terms disallow distribution of binaries obtained from modified source IIRC. You must apt-get source pine and build the packages yourself. See, I knew there was a license issue! Hrm. So either the prepackaged pine to which the OP referred is a licensing violation, or debian feels strongly enough about some mods to distribute as source rather than distribute the canonical form? Well, whatever. I use mutt, so it's academic to me. -- monique -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Another testing vs unstable question
On Wed, 23 Jun 2004 09:35:48 -0600, Monique Y. Mudama wrote: No, but [Red Hat] were always a company looking to make money off of their product (not that there's anything wrong with that). Debian has no such plans, and that's one of the reasons why I trust them to do what's right rather than what's profitable. As do we all(!), I'm sure Debian developers must sometimes do the wrong thing for the right reason or the right thing for the wrong reason. The key word here, and I quote, is trust. Debian's developers have earned the trust they're receiving. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Another testing vs unstable question
Monique Y. Mudama wrote: On 2004-06-23, Ernie McCracken penned: On Wed, 23 Jun 2004 09:35:48 -0600, Monique Y. Mudama [EMAIL PROTECTED] wrote: where I work we still have a 7.0 box in place: I chose 7.0 over 7.1 so as to have a 2.2 kernel as standard (required for a sat card). It seems odd to me to choose a release based on the kernel, but okay. It seems *very* odd that you're telling us that RedHat switched major kernel numbers for a minor release. The vendor's driver required a 2.2 kernel. The primary alternative that occurred to me at the time was 7.1 with the older kernel, but that wasn't a standard configuration. Odd though it may be, it is true. RedHat 7.1 was the first RH release to use the 2.4 kernel. :-) 7.0: http://www.redhat.com/about/presscenter/2000/press_rhl7.html 7.1: http://www.redhat.com/about/presscenter/2001/press_sevenone.html Oh, I believe it. It just serves to emphasize, in my mind, the idea that redhat and debian work from two completely different theories. Minor revision numbers shouldn't contain those kinds of changes! Oh? Isn't Sarge to be released as 3.1? I'm pretty sire that the standard kernel with woody is 2.2 though 2.4 is tolerated. I say tolerated because 2.2 is recommended. According to the Monique theory, if Sarge is released as 3.1 then it should still have a 2.2 kernel. I'm sure I've seen discussion that it may contain 2.6. The kernel doesn't provide programmers' APIs, the kernel's ABI is wrapped by (g)libc, and that's what is important. thinks. I wonder what's involved in dropping a BSD kernel in? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Another testing vs unstable question
Monique Y. Mudama wrote: On 2004-06-23, John Summerfield penned: David Fokkema wrote: Please, no. Debian stable is rock solid, something RedHat, in my opinion, has never been able to achieve. I would love to hear from people who are still running a RedHat system older than two years. I know of a lot of people who are running such Debian systems and are satisfied with it, apart from the usual thoughts: oh, would that I had _both_ that stability _and_ the newer software. But still, they choose stability. I've got three of these to care for: [EMAIL PROTECTED] summer]$ rpm -q redhat-release redhat-release-7.3-1 [EMAIL PROTECTED] summer]$ and one running RHL 7.0 that I've already mentioned. When you upgrade from 6.x to 7.x, or from 7.x to 8.x, can you do that? Just upgrade, as opposed to reinstall? This was something that seemed extraordinarily difficult when last I used RedHat, back in the dark ages. Sure. You have to take it out of service, but upgrading that box from 7.0 to 7.3 is/was supported which is as far as _I_ would go (didn't like 8.0 or 9). Indeed, as I said, one can install RHL 7.3 packages on 7.0. I don't recall upgrading major releases, but the docs said that it works, even from very old (4.x) to very new. Come to think of it, I think I did upgrade 6.2 to 7.something. None of them has given any particular problems. We even had up2date working on one of them, but for various reasons I didn't usually bother with up2date. Why not? I'm not trying to poke holes or anything -- but a lot of RH enthusiasts point to up2date as a great tool. Why don't you like it? 1. I had my updates appearing on-site automatically before RH invented up2date. 2. It gets all the updates from RH servers. There are network and potential financial benefits to using local mirrors. 3. I don't like registering. I used up2date on taroon (beta of RHL ES 3.0) and it's very nice except for point 2. fwiw I was much amused when I first tried Knoppix (it was, I think, a 3.2 beta but it might have been 3.1). The hardware detection is done with Red Hat's tools. Why be amused? If RedHat licenses their stuff such that other systems can use it, and it works, it would be foolish to reinvent the wheel. That's one of the reasons people like open source so much. I know. It was the thought of using RH tools to configure what is essentially a Debian system. Given how well RH detects hardware, I think it a great shame that the Debian project didn't use some of the RH tools to help installing Woody. I can (and used to) install RHL 7.3 on arbitrary local-computershop hardware in fifteen minutes, fully automated. I gather the name Ian Murdock has some significance here, and that he's connected to Progeny. Here's what Progeny says, Red Hat's® Anaconda is the standard installer among Linux distributions. Our port of Anaconda to Debian brings the familiar installation experience of Anaconda to the rest of the Linux world. See http://platform.progeny.com/anaconda/ While I don't have any specific examples, I would be quite surprised if RedHat doesn't incorporate some of Debian's work, too. Again, it would be foolish not to. Sure, I've seen bits in RHL attributed to Debian. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Another testing vs unstable question
On Thu, 2004-06-24 at 12:58, John Summerfield wrote: fwiw I was much amused when I first tried Knoppix (it was, I think, a 3.2 beta but it might have been 3.1). The hardware detection is done with Red Hat's tools. Why be amused? If RedHat licenses their stuff such that other systems can use it, and it works, it would be foolish to reinvent the wheel. That's one of the reasons people like open source so much. I know. It was the thought of using RH tools to configure what is essentially a Debian system. Given how well RH detects hardware, I think it a great shame that the Debian project didn't use some of the RH tools to help installing Woody. I can (and used to) install RHL 7.3 on arbitrary local-computershop hardware in fifteen minutes, fully automated. I gather the name Ian Murdock has some significance here, and that he's connected to Progeny. Here's what Progeny says, Red Hat's® Anaconda is the standard installer among Linux distributions. Our port of Anaconda to Debian brings the familiar installation experience of Anaconda to the rest of the Linux world. See http://platform.progeny.com/anaconda/ And those comments also point out that Progeny's Anaconda port is x86-specific. Debian supports a much wider range of hardware than Red Hat does. So Anaconda for debian (+RH hardware discovery) is nice for people with x86 hardware, but *everyone* can use the new debian-installer and its hardware-discovery framework (which also happens to be largely developed by Progeny: see http://platform.progeny.com/discover/index.html). Personally, I think support for alternative hardware is really important; x86 chips aren't bad, but opening the door for other chip makers and designers to compete using alternative architectures is good for everyone. Imagine how much slower our CPUs would be if Intel didn't have AMD and Transmeta pushing them...and imagine how much harder they will have to work when PowerPC and others can compete fairly (ie when the dominant computer OS is not one that is limited to x86 architecture only). The debian-installed FAQ has more info (esp. item 4): http://wiki.debian.net/?DebianInstallerFAQ Cheers, Simon -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Another testing vs unstable question
Monique Y. Mudama wrote: On 2004-06-23, John Summerfield penned: Yes, but there's no way to test those backports thoroughly enough to match the amount of testing that went into stable in the first place. Do you believe that? The point of stable is not just that each package has been tested to the nth degree, it's also that the system as a whole has been tested -- the complex web of interactions among packages. In order to accept these backports into stable, we either have to perform the same amount of testing *on the whole system* as we did to release stable in the first place, or the system can't be certified to be truly stable. When we change one line on the flight software where I work, we can't just test the unit that was changed and move on. We have to perform the complete system test all over again to make sure nothing unexpected happens. The same concept applies to servers. I've worked in environments where we didn't test the system after making small changes. It's not pretty. I switched over from OS/2 to 5.0. I was surprised later to discover people regarded it as buggy. I don't recall how much I used 6.0, but where I work we still have a 7.0 box in place: I chose 7.0 over 7.1 so as to have a 2.2 kernel as standard (required for a sat card). It seems odd to me to choose a release based on the kernel, but okay. It seems *very* odd that you're telling us that RedHat switched major kernel numbers for a minor release. The most troublesome system I have is one running Woody, the video regularly gets stuffed up and it's prone to losing its keyboard. Changing the graphics card made no difference. Is it possible it's the motherboard? Those are some weird problems. I'm not looking for help, and I'm especially not asking for help in this thread. It's probably the mobo. It's Gigabyte, Via chipset. I know there were problems with some (early) Via chipsets, and I know at least some problems are fixed with BIOS updates. I forget what the original video card was but the current one is a Radeon 9200 SE. Of course, XFree doesn't understand it, one of the joys of Woody. I can't get better than 1280x1024 out of it despite my Sun monitor supporting better than 1600x1200. KDE locks up every time, so when I use it at the keyboad I login using GNOME and start a VNC session running KDE. Currently I mostly use the box at the other end of a modem and that works fine. Shortly I hope to be using it at the other end of a 1500/ ADSL connexion and that will be better. Oh, the box locks up whenever I try to use the 120 Gbyte WD drive in it. Its main use is to backport packages to woody. It does that. It sounds like a lot more work for the developers. RedHat had commercial customers to support their developers. How would you suggest Debian manage this? I thnk Red Hat didn't have commercial customers when it started on this model. No, but they were always a company looking to make money off of their product (not that there's anything wrong with that). Debian has no such plans, and that's one of the reasons why I trust them to do what's right rather than what's profitable. It's also one of the reasons it's been suggested as a reference implementation a number of times. Its only since its IPO that RH has become money-hungry. I am comfortable with the notion of paid-for support in the way of security advisories and bug-fixes: the only matter for debate is cost. I think these people may have something I'd accept: http://www.lineox.com/ Debian developers are hard-working folk, but it's hard to work full-time for free. Indeed. While I disagree with much of the Debian project (before you jump in, I'd point ot that many of the Debian Developers disagree with each other too), I do admire their endevour and commitment to the project. As I already said, there are enough developers doing enough work - the packages are out there. What is missing official adoption by Debian, and the coordination that would follow its adoption. No, what's missing is the testing infrastructure. *System* testing, not just the individual package. Better, I think to seek ways towards that ideal. Some cliches come to mind - the person who makes no mistakes does nothing, a journey of a thousand leagues begins with a single step... I haven't yet seen a Debian beta process, so I don't know what happens, but if (as I've read) the DDs are mostly running testing or unstable, then there has to be something wrong in _their_ estimation with Woody. The recent move to subversion has had the effect of officially cutting Woody users off from the latest source - there is no offical Woody build of subversion. If there was an official line of built for Stable packages comprising packages people felt were needed, linked to from the dowload page, be sure a lot of people would try them out. And now a lot of people who aren't motivated enough to do a google search or ask on d-u
Re: Another testing vs unstable question
Simon Kitching wrote: I can (and used to) install RHL 7.3 on arbitrary local-computershop hardware in fifteen minutes, fully automated. I gather the name Ian Murdock has some significance here, and that he's connected to Progeny. Here's what Progeny says, Red Hat's® Anaconda is the standard installer among Linux distributions. Our port of Anaconda to Debian brings the familiar installation experience of Anaconda to the rest of the Linux world. See http://platform.progeny.com/anaconda/ And those comments also point out that Progeny's Anaconda port is x86-specific. Debian supports a much wider range of hardware than Red Hat does. So Anaconda for debian (+RH hardware discovery) is nice for people with x86 hardware, but *everyone* can use the new debian-installer and its hardware-discovery framework (which also happens to be largely developed by Progeny: see http://platform.progeny.com/discover/index.html). Anaconda isn't X86-specific.. As I recall it runs on all current IBM hardware (it didn't originally run on S/390 zSeries). Red Hat currently supports IA32, IA64, AMD-64, PPC/Power and S/390 zSeries. I don't recall when Anaconda was introduced, if it was _before_ RHL 7.0 then it also supports Sparc (I have a Sparc with RHL 6.2 installed, Woody didn't want to install on the box). Yellowdog Linux is essentially RHL ported to the Mac so Anaconda would be working on the Mac too. The only serious problem with Anaconda is it requires significant RAM. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Another testing vs unstable question
On 2004-06-24, John Summerfield penned: Oh? Isn't Sarge to be released as 3.1? I'm pretty sire that the standard kernel with woody is 2.2 though 2.4 is tolerated. I say tolerated because 2.2 is recommended. According to the Monique theory, if Sarge is released as 3.1 then it should still have a 2.2 kernel. I'm sure I've seen discussion that it may contain 2.6. Okay, you're right; my bad. TBH, I haven't paid much (any?) attention to the numbering scheme because the names are easier to remember for me. If sarge is to be 3.1, then I agree that the numbering scheme is non-obvious. I hope there's a document out there somewhere that explains why, but I'm too lazy to look it up. The kernel doesn't provide programmers' APIs, the kernel's ABI is wrapped by (g)libc, and that's what is important. thinks. I wonder what's involved in dropping a BSD kernel in? I'm pretty sure there's a project underway somewhere for exactly that; or maybe it was more like a BSD system using the dpkg/apt packaging tools. I don't konw what it's called, though. I've never used BSD, mostly because I am so happy and familiar with the debian way of upgrading; bsd + debian would be a powerful lure. -- monique -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Another testing vs unstable question
On 2004-06-24, John Summerfield penned: Its only since its IPO that RH has become money-hungry. I am comfortable with the notion of paid-for support in the way of security advisories and bug-fixes: the only matter for debate is cost. Well, if I understood you earlier, you have paying clients. I guess having a paid support contract is a nice CYA maneuver in that kind of situation. (I like debian better, but then, I've never tried the paid version of linux support; maybe it's just fantabulous.) Indeed. While I disagree with much of the Debian project (before you jump in, I'd point ot that many of the Debian Developers disagree with each other too), I do admire their endevour and commitment to the project. Gd, do they ever disagree! I don't disagree with much of the project, but I'm right there with you. I think it's a lot like a quote I heard about the ACLU -- If you agree with half of what we do, you should contribute. If you agree with 75% of what we do, you should be on our Board of Directors! Something like that. No, what's missing is the testing infrastructure. *System* testing, not just the individual package. Better, I think to seek ways towards that ideal. Some cliches come to mind - the person who makes no mistakes does nothing, a journey of a thousand leagues begins with a single step... Right. The question is whether the product can realistically be improved/sped up or not. I'm reminded of that whole nine women can't make a baby in one month business. I haven't yet seen a Debian beta process, so I don't know what happens, but if (as I've read) the DDs are mostly running testing or unstable, then there has to be something wrong in _their_ estimation with Woody. Er. They *have* to run testing or unstable in order to test their packages! Not all of them have multiple boxes (or even permanent network connections); many of them may not be running mission-critical systems at home; and they're all experienced enough not to have to run stable to avoid the fear of accidentally doing a Bad Thing. I'm pretty sure all the debian servers run stable, although it would be interesting to hear if they don't. The recent move to subversion has had the effect of officially cutting Woody users off from the latest source - there is no offical Woody build of subversion. Eh? Whose recent move to subversion? I've been distracted by non-computer things recently; have I missed something? And now a lot of people who aren't motivated enough to do a google search or ask on d-u are installing packages that haven't been fully tested with the system. The status quo at least ensures that the people who are using backports have at a minimum the ability to research questions. Do you think the current situration is perfect? If not, how do _you_ think it may be improved. There's a difference between imperfect and needs to be fixed. I stand by my belief that adding packages after the official release introduces risk. Now, would releasing a new version of stable more often be a good thing? I guess it depends on if it's deemed truly stable. Okay, I'm way too tired for rational thought right now. Must go beddy bye ... -- monique -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Another testing vs unstable question
On 2004-06-21, Michael Satterwhite penned: On Monday 21 June 2004 12:03, Monique Y. Mudama wrote: If you're trying to avoid any downtime or difficulty whatsoever, run stable and live with the age of the packages. Not exactly promoting Debian, are we? Especially in a Linux world where there are so MANY choices. I'm not here to promote Debian. I'm trying to help someone understand the ramifications of their actions so that they don't waste time setting up a system that doesn't meet their needs. Whether or not I'm trying to promote Debian, my statement is true. The stable distro is released as a complete entity, with all of the packages and their interactions having been tested by thousands of people over the course of many months. It gets old, but it's rock-solid. As you introduce new packages to the mix in the form of backports, source installs, etc, you introduce risk, because these interactions haven't been tested as thoroughly as the stable distribution itself. These risks go up exponentially when you move into testing or unstable. Pick novelty or stability. It's a spectrum; you can't have both. I choose to run unstable, but I also recognize the risks inherent in doing so. Others here, however, are doing a much better job. You're entitled to your opinion. -- monique -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Another testing vs unstable question
On 2004-06-22, Jules Dubois penned: On Mon, 21 Jun 2004 14:38:51 -0500, Michael Satterwhite wrote: On Monday 21 June 2004 12:03, Monique Y. Mudama wrote: If you're trying to avoid any downtime or difficulty whatsoever, run stable and live with the age of the packages. Not exactly promoting Debian, are we? She is. Debian stable is an excellent argument in favor of running a Debian release. There's no other distribution or flavor providing its reliability or availability. Indeed. I actually meant my statement to be in support of the stable distribution. I guess I should have made that clearer. Still, no one benefits from having blinders over their eyes. Stable is the most stable, and it's also the least current. I don't see how it could be any other way. They're on opposite ends of the same spectrum. Others here, however, are doing a much better job. You've missed the point and owe an apology. I appreciate the vote of confidence, but it's okay. Everyone's entitled to a cranky day once in a while. -- monique -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Another testing vs unstable question
On 2004-06-21, Kent West penned: Michael Satterwhite wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Monday 21 June 2004 12:03, Monique Y. Mudama wrote: If you're trying to avoid any downtime or difficulty whatsoever, run stable and live with the age of the packages. Not exactly promoting Debian, are we? Especially in a Linux world where there are so MANY choices. Others here, however, are doing a much better job. I'm not sure where Monique went wrong. I'd have to agree with her assessment. Others in the thread have already praised the usability of unstable; Monique is just reiterating that if he really wants stable, he'll need to stick with stable and the older packages there. It might have sounded a bit short, but from my past experience with her, I don't think that was intended; it's just the nature of email. Sounds about right to me. I didn't mean to be short; in fact, while Michael snipped the largest portion of my post, if you look at the whole paragraph in its entirety, I don't think that sentence sounds nearly as harsh. Wow, that was a lot of commas. The more I read that bit about choices, the less I get it. Shouldn't we celebrate choice? If someone prefers Gentoo or SUSE or even, for some reason I couldn't comprehend, RedHat, why is that a bad thing? I adore debian, but I don't take offense when people choose other distributions. It's all open-source; it all comes together to make every distribution stronger. Personally, I think that debian is the system people choose after they've been burned by the rest. What seems like cruftiness to the novice is found to be sublime by the more experienced admin. -- monique -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Another testing vs unstable question
On Monday 21 June 2004 22:00, Chris Metcalf wrote: If I remember correctly, unstable is called unstable because the packages go through a large amount of turnover and you'll usually have to upgrade a few times per week to keep your system in sync. Now that's interesting. The name unstable put me off using it. In my experience, unstable is actually very stable for my desktop uses. I'll consider switching from testing to unstable now. And its a whole lot easier to keep up-to-date than RPM based distros. I wholeheartedly agree, although I have seen comments from fans of RPM-distros that we Debian users say that because we don't know how to use urpmi properly. -- Adam -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Another testing vs unstable question
On Mon, 21 Jun 2004 23:17:49 -0400, John Cichy wrote: Jules Dubois wrote: I think perhaps stable, testing, and unstable were not the absolutely, positively best choices for the flavors but I can't say I could have done any better. These comments are however immaterial. Oops. I meant to say perhaps not the best choices for NAMES. Considering the fact that most distributions ship what debian would consider testing, and another OS sells unstable as a finished product [...] I think we're agreed. I just failed to proofread properly. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Another testing vs unstable question
Monique Y. Mudama wrote: Indeed. I actually meant my statement to be in support of the stable distribution. I guess I should have made that clearer. Still, no one benefits from having blinders over their eyes. Stable is the most stable, and it's also the least current. I don't see how it could be any other way. They're on opposite ends of the same spectrum. For me its lack of currency is becoming a serious problem. I'm deploying new systems: do I really want to deploy software that's not going to be supported much beyond a year? Do I really want to go through migration to new releases just after I've got it bedded down? No I don't. My choices are going with testing: what then about security patches? or unstable? From my reading it's not unknown for unstable to be seriously borked for a time: I think new glibc did it a while ago, and gcc was forecast to do it shortly after. If I want to support a USB Laserjet 1200, then I really need the latest hpoj stuff: Woody is far too old. What I find myself doing increasingly is building the occasional package from Sid for Woody: sometimes it's easy, sometimes it's too much trouble (think xfree where I think I found circular dependancies). -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Another testing vs unstable question
On Tue, Jun 22, 2004 at 04:01:20PM +0800, John Summerfield wrote: Monique Y. Mudama wrote: Indeed. I actually meant my statement to be in support of the stable distribution. I guess I should have made that clearer. Still, no one benefits from having blinders over their eyes. Stable is the most stable, and it's also the least current. I don't see how it could be any other way. They're on opposite ends of the same spectrum. For me its lack of currency is becoming a serious problem. I'm deploying new systems: do I really want to deploy software that's not going to be supported much beyond a year? Do I really want to go through migration to new releases just after I've got it bedded down? That's the beauty of stable. It _is_ supported for well over a year. Actually, make that two years. The only problem _right now_ is that if you go with stable _now_, there is sarge coming. But apart from that, stable is supported for years. No I don't. My choices are going with testing: what then about security patches? or unstable? From my reading it's not unknown for unstable to be seriously borked for a time: I think new glibc did it a while ago, and gcc was forecast to do it shortly after. If I want to support a USB Laserjet 1200, then I really need the latest hpoj stuff: Woody is far too old. Woody is old, but have you looked at www.backports.org? A list of well-supported backports is available there. Security updates will be a tad slower than unstable, which is behind stable. But then, you're not backporting glibc, but imap servers or whatever. What I find myself doing increasingly is building the occasional package from Sid for Woody: sometimes it's easy, sometimes it's too much trouble (think xfree where I think I found circular dependancies). Also, see www.apt-get.org for various backports, including xfree. But then, www.backports.org also has an xfree backport. Check it out. David -- Hi! I'm a .signature virus. Copy me into your ~/.signature to help me spread! -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Another testing vs unstable question
On Tue, 22 Jun 2004, David Fokkema wrote: On Tue, Jun 22, 2004 at 04:01:20PM +0800, John Summerfield wrote: Monique Y. Mudama wrote: Indeed. I actually meant my statement to be in support of the stable distribution. I guess I should have made that clearer. Still, no one benefits from having blinders over their eyes. Stable is the most stable, and it's also the least current. I don't see how it could be any other way. They're on opposite ends of the same spectrum. For me its lack of currency is becoming a serious problem. I'm deploying new systems: do I really want to deploy software that's not going to be supported much beyond a year? Do I really want to go through migration to new releases just after I've got it bedded down? That's the beauty of stable. It _is_ supported for well over a year. Actually, make that two years. The only problem _right now_ is that if you go with stable _now_, there is sarge coming. But apart from that, stable is supported for years. No I don't. My choices are going with testing: what then about security patches? or unstable? From my reading it's not unknown for unstable to be seriously borked for a time: I think new glibc did it a while ago, and gcc was forecast to do it shortly after. If I want to support a USB Laserjet 1200, then I really need the latest hpoj stuff: Woody is far too old. Woody is old, but have you looked at www.backports.org? A list of well-supported backports is available there. Security updates will be a tad slower than unstable, which is behind stable. But then, you're not backporting glibc, but imap servers or whatever. What I find myself doing increasingly is building the occasional package from Sid for Woody: sometimes it's easy, sometimes it's too much trouble (think xfree where I think I found circular dependancies). Also, see www.apt-get.org for various backports, including xfree. But then, www.backports.org also has an xfree backport. Check it out. David How hard will it be to switch or upgrade to sarge from woody when sarge becomes stable? I'm hoping that CUPS and other stuff in sarge will let me use my parallel port HP 697C printer and my HP psc1210 printer/scanner/copier on an USB port. I also hope to have support for my Ethernet card which is a Linksys listed in lspci since I have a local home network. Sincerely, (Mr.) Gayle Lee Fairless Linux Gcomm 2.4.18-bf2.4 #1 Son Apr 14 09:53:28 CEST 2002 i686 unknown -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Another testing vs unstable question
On Tue, Jun 22, 2004 at 08:35:09AM -0500, Gayle Lee Fairless wrote: How hard will it be to switch or upgrade to sarge from woody when sarge becomes stable? I'm hoping that CUPS and other stuff in sarge will let me use my parallel port HP 697C printer and my HP psc1210 printer/scanner/copier on an USB port. I also hope to have support for my Ethernet card which is a Linksys listed in lspci since I have a local home network. Well, upgrading from woody to sarge should be no problem. Maybe you'll be informed that some new software uses other-style config files which you have to reconfigure. Maybe. You can safely assume that any hardware that is supported in woody is also supported in sarge, and probably better. Maybe some very exotic hardware excluded, but it would be very unlikely if that happened to sit around your desktop. And it certainly won't be an HP printer or some ethernet card. David -- Hi! I'm a .signature virus. Copy me into your ~/.signature to help me spread! -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Another testing vs unstable question
On Sun, Jun 20, 2004 at 11:13:37AM -0500, Michael Satterwhite wrote: | I've been watching the various discussions on this, and note that most | experienced types think that the unstable distribution is better than the | testing distribution. This leads me to one more question / observation Unstable is better in the sense that it has the latest-and-greatest software. Fixes and features arrive just as fast as the package maintainer can upload them. Testing has to wait at least two weeks, sometimes longer, to receive those same fixes and features. Sometimes a problem in a package doesn't get noticed until it arrives in testing. If the maintainer uploads a corrected package five minutes after the first user reported the bug, testing will still have the broken package for at least two weeks until the fixed package is migrated from unstable. It is a set of tradeoffs with no clear absolute better. | A few weeks ago (I don't know about now), the KDE distribution in unstable | simply would not run. I've noted several of the messages recommending the | unstable branch say that there were some updates that caused the receiving | machines to crash / lock / not start. Fun. ;-) | How does one recover from something like this short of doing a reload? That depends on the exact nature of the problem. In short it comes down to understanding the system, tracking down the problem and arranging some sort of solution or workaround. For example, sometimes an install fails due to the postinst script having a bug or just not handling some situation optimally. Editing the postinst script to avoid that error is a way around the problem in that situation. Other situations (like the bad PAM package upload a couple summers ago) are resolved by booting without init (append init=/bin/sh to the kernel command line) and manually starting enough of the system to install the previous version of the package so authentication will work when you reboot the machine. Sometimes the issue is simply one of dependency resolution or incorrect/missing/insufficient dependencies in the package. That problem is resolved by determing which package(s) need to be installed, upgraded, or downgraded. | For that matter, a reload should crash the same way as it's getting | the same software. That depends on the source of the problem. Sometimes installation on a clean system works but upgrading an existing system fails to handle certain situations. Sometimes it is the other way around. Again, it all depends. | I may be missing something - quite likely, BTW, I'll admit total | ignorance here - but it would appear that it wouldn't take many of these | incidents to make the testing branch seem A LOT better than unstable. | | Other than this, the arguments for the unstable over testing seem valid. Personally I run a mixture. Testing has somewhat of a safety net to protect against certain sorts of problems. However, sometimes a certain package or version is only available in unstable. With my level of experience I feel comfortable trying unstable packages and dealing with any hurdles I may run into. However, if you don't have that level of experience and don't have a mentor close by to help you through those issues then I would recommend using testing. At the same time, follow various mailling list discussions, and read stuff on the web, read various files (docs, source and scripts) in packages and build up the experience and knowledge to be comfortable in the face of potential failures. It also helps if you have more than one machine so you can try something on one machine and if it doesn't work then don't do the same thing to the other. -D -- He is no fool who gives up what he cannot keep to gain what he cannot lose. --Jim Elliot www: http://dman13.dyndns.org/~dman/jabber: [EMAIL PROTECTED] signature.asc Description: Digital signature
Re: Another testing vs unstable question
On 2004-06-22, Adam Funk penned: On Monday 21 June 2004 22:00, Chris Metcalf wrote: If I remember correctly, unstable is called unstable because the packages go through a large amount of turnover and you'll usually have to upgrade a few times per week to keep your system in sync. Now that's interesting. The name unstable put me off using it. In my experience, unstable is actually very stable for my desktop uses. I'll consider switching from testing to unstable now. Unstable: parts are frequently broken but quickly fixed Testing: parts are broken less often, but when they are, it can take months to fix them Stable: nothing is broken, but you won't be able to play with the latest gizmos unless you install from backports or source Choose your poison. Note that the use of the term frequently in my description of unstable is relative; I've run unstable for years and had far fewer problems with it than I used to have with RedHat. -- monique -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Another testing vs unstable question
On Tuesday 22 June 2004 17:00, Monique Y. Mudama wrote: Unstable: parts are frequently broken but quickly fixed Testing: parts are broken less often, but when they are, it can take months to fix them Stable: nothing is broken, but you won't be able to play with the latest gizmos unless you install from backports or source Choose your poison. Note that the use of the term frequently in my description of unstable is relative; I've run unstable for years and had far fewer problems with it than I used to have with RedHat. Interesting -- thanks! -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Another testing vs unstable question
David Fokkema wrote: On Tue, Jun 22, 2004 at 04:01:20PM +0800, John Summerfield wrote: Monique Y. Mudama wrote: Indeed. I actually meant my statement to be in support of the stable distribution. I guess I should have made that clearer. Still, no one benefits from having blinders over their eyes. Stable is the most stable, and it's also the least current. I don't see how it could be any other way. They're on opposite ends of the same spectrum. For me its lack of currency is becoming a serious problem. I'm deploying new systems: do I really want to deploy software that's not going to be supported much beyond a year? Do I really want to go through migration to new releases just after I've got it bedded down? That's the beauty of stable. It _is_ supported for well over a year. Actually, make that two years. The only problem _right now_ is that if you go with stable _now_, there is sarge coming. But apart from that, stable is supported for years. It's an on-going problem because new stables come out so infrequently. Someone deploying Sarge as soon as it becomes stable can look forward to four years (going on past performance) of support for it. I have no problem with that. The problem is someone deploying stable _now_ has a little over a year, someone deploying stable in two years can expect two years of life... The cycles are too long. I'm a refugee from Red Hat because its free support model became too short, and there was no paid-for support I found attractive (far too dear). No I don't. My choices are going with testing: what then about security patches? or unstable? From my reading it's not unknown for unstable to be seriously borked for a time: I think new glibc did it a while ago, and gcc was forecast to do it shortly after. If I want to support a USB Laserjet 1200, then I really need the latest hpoj stuff: Woody is far too old. Woody is old, but have you looked at www.backports.org? A list of I have. well-supported backports is available there. Security updates will be a tad slower than unstable, which is behind stable. But then, you're not backporting glibc, but imap servers or whatever. I need my security updates _before_ they become a problem. Don't you? What I find myself doing increasingly is building the occasional package from Sid for Woody: sometimes it's easy, sometimes it's too much trouble (think xfree where I think I found circular dependancies). Also, see www.apt-get.org for various backports, including xfree. But then, www.backports.org also has an xfree backport. Check it out. I have been to www.apt-get.org and I got Mozilla from here, pine from there, KDE from somewhere else, Xfree from another... Do you get the picture? What if the pine person also provided Mozilla? Or worse, glibc 2.3? It got completely out of control. My desktop system, while it still worked, was becoming a real mess until I upgraded to Sarge (not without some difficulty, the upgrade wanted to remove lots of kit I didn't want removed). Don't tell me I could pin things, until you point to the obvious documentation I missed. And what about security updates? I'm not going down that path with any system I'm paid to support. A coordinated, official system of official backports would be a fine thing, and the workforce to do it is already there - they're the people making these unofficial backports. Until Red Hat Linux 8.0, Red Hat had two cycles of releases: Major numbers, 5.x, 6.x, 7.x maintained binary compatibility. Those came out with about the same frequencies as Debian releases. Then there were the minor releases, x.[0-3] coming out at about six-monthly intervals. One could take a package from x.2 and install it with minimal bother on x.0 or x.1, with every expectation of not breaking anything. It's a model Debian would do well to look at and see how it can adapt it, adopt it. Using this model, Sarge would be 4.0, not 3.1 because it breaks binary compatibility (new gcc, new glibc). -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Another testing vs unstable question
On 2004-06-23, John Summerfield penned: I have been to www.apt-get.org and I got Mozilla from here, pine from there, KDE from somewhere else, Xfree from another... Do you get the picture? Well, just to be pedantic, you wouldn't find pine anywhere in debian because of its licensing terms. A coordinated, official system of official backports would be a fine thing, and the workforce to do it is already there - they're the people making these unofficial backports. Yes, but there's no way to test those backports thoroughly enough to match the amount of testing that went into stable in the first place. Until Red Hat Linux 8.0, Red Hat had two cycles of releases: Major numbers, 5.x, 6.x, 7.x maintained binary compatibility. Those came out with about the same frequencies as Debian releases. And the dot-oh releases were well known to be buggy piles of crap. There was always some nasty gotcha lurking in the system. I don't know why that was the case, but it definitely held true from at least 4 to 6, maybe 7. Somewhere in there I stopped having to care because I switched to Debian. Then there were the minor releases, x.[0-3] coming out at about six-monthly intervals. One could take a package from x.2 and install it with minimal bother on x.0 or x.1, with every expectation of not breaking anything. It's a model Debian would do well to look at and see how it can adapt it, adopt it. Using this model, Sarge would be 4.0, not 3.1 because it breaks binary compatibility (new gcc, new glibc). It sounds like a lot more work for the developers. RedHat had commercial customers to support their developers. How would you suggest Debian manage this? -- monique -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Another testing vs unstable question
Michael Satterwhite wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Sunday 20 June 2004 18:44, richard lyons wrote: On Sunday 20 June 2004 16:10, Michael Satterwhite wrote: [...] Although I've had to use Windows at some client sites, my personal machines have been essentially MS free for over a year. Some exceptions, there - I can't live without Quicken / Quickbooks [...] Look at sql-ledger. You might like it. Really effective bookkeeping which runs in a browser, so you can set up remote access should you wish to. It's the electronic banking that I use. For obvious reasons, I don't really want to play games with that. Hence cxoffice. I haven't sql-ledger and will look into it but gnucash will read Quicken files from your bank and you may like using accounts completely instead of using Quicken categories which are just weakened accounts. This reference may help with Quickbooks to GnuCash conversion: http://www.aerospacesoftware.com/GNU_Cash_for_Business_users_Howto_Guide.html Paul Scott -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Another testing vs unstable question
On 2004-06-20, Michael Satterwhite penned: I'll take this for one vote that testing is actually a better choice than unstable. No. You said that you read the arguments for and against testing and unstable. If so, you know that if a bug gets through to testing, it can be there for months -- much longer than it would be in unstable. Testing's current stability is an anomolous situation caused by the fact that it's so close to becoming the next stable. If you're trying to avoid any downtime or difficulty whatsoever, run stable and live with the age of the packages. -- monique -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Another testing vs unstable question
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Monday 21 June 2004 12:03, Monique Y. Mudama wrote: If you're trying to avoid any downtime or difficulty whatsoever, run stable and live with the age of the packages. Not exactly promoting Debian, are we? Especially in a Linux world where there are so MANY choices. Others here, however, are doing a much better job. -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQFA1zlejeziQOokQnARAsBfAJwNt5EOBHG3rb7yzEENEk7NiXukTACePR85 fvIRNCR6Z52mTqPFyYt/zxs= =fKRB -END PGP SIGNATURE-
Re: Another testing vs unstable question
If I remember correctly, unstable is called unstable because the packages go through a large amount of turnover and you'll usually have to upgrade a few times per week to keep your system in sync. In my experience, unstable is actually very stable for my desktop uses. And its a whole lot easier to keep up-to-date than RPM based distros. Debian's idea of a stable system is a lot more strict than many other distros. I run testing on my servers, and generally only have to run an upgrade once a week to update a few packages. When I ran stable, I only had to upgrade extremely rarely when a security patch came out. Chris M. On Mon, 21 Jun 2004 14:38:51 -0500, Michael Satterwhite [EMAIL PROTECTED] wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Monday 21 June 2004 12:03, Monique Y. Mudama wrote: If you're trying to avoid any downtime or difficulty whatsoever, run stable and live with the age of the packages. Not exactly promoting Debian, are we? Especially in a Linux world where there are so MANY choices. Others here, however, are doing a much better job. -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQFA1zlejeziQOokQnARAsBfAJwNt5EOBHG3rb7yzEENEk7NiXukTACePR85 fvIRNCR6Z52mTqPFyYt/zxs= =fKRB -END PGP SIGNATURE- -- Chris Metcalf [EMAIL PROTECTED] http://chrismetcalf.net -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Another testing vs unstable question
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Monday 21 June 2004 15:44, Chris Metcalf wrote: If I remember correctly, unstable is called unstable because the packages go through a large amount of turnover and you'll usually have to upgrade a few times per week to keep your system in sync. In my experience, unstable is actually very stable for my desktop uses. And its a whole lot easier to keep up-to-date than RPM based distros. Debian's idea of a stable system is a lot more strict than many other distros. I *THINK* I'm convinced on this one. Actually, Debian's tools make updates (almost) painless; by far the easiest update tools I've seen on any distro. I *DO* think that SuSE's Yast is a great configuration tool, but apt is in a league of it's own. While there have been a couple of people who (unintended, I'm sure) actually gave logical reasons *NOT* to use Debian, most of the replies have been very good; I learned quite a bit about updates. Thanks to all! I run testing on my servers, and generally only have to run an upgrade once a week to update a few packages. When I ran stable, I only had to upgrade extremely rarely when a security patch came out. Very good example. Some machines absolutely *HAVE* to be up 24/7. For the most part, I can live with those machines having older software. Other machines can have a little instability without causing major problems. Thanks again to everyone who responded -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQFA11nBjeziQOokQnARAqmNAJ4jR/S6vEGsEd/YeyezPyA1wtq4ugCgoC2g 9t0y7TIG+4b5dvsctXhEsi8= =ynKC -END PGP SIGNATURE-
Re: Another testing vs unstable question
Michael Satterwhite wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Monday 21 June 2004 12:03, Monique Y. Mudama wrote: If you're trying to avoid any downtime or difficulty whatsoever, run stable and live with the age of the packages. Not exactly promoting Debian, are we? Especially in a Linux world where there are so MANY choices. Others here, however, are doing a much better job. I'm not sure where Monique went wrong. I'd have to agree with her assessment. Others in the thread have already praised the usability of unstable; Monique is just reiterating that if he really wants stable, he'll need to stick with stable and the older packages there. It might have sounded a bit short, but from my past experience with her, I don't think that was intended; it's just the nature of email. -- Kent -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Another testing vs unstable question
On Mon, 21 Jun 2004 14:38:51 -0500, Michael Satterwhite wrote: On Monday 21 June 2004 12:03, Monique Y. Mudama wrote: If you're trying to avoid any downtime or difficulty whatsoever, run stable and live with the age of the packages. Not exactly promoting Debian, are we? She is. Debian stable is an excellent argument in favor of running a Debian release. There's no other distribution or flavor providing its reliability or availability. I think perhaps stable, testing, and unstable were not the absolutely, positively best choices for the flavors but I can't say I could have done any better. These comments are however immaterial. Others here, however, are doing a much better job. You've missed the point and owe an apology. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Another testing vs unstable question
Jules Dubois wrote: On Mon, 21 Jun 2004 14:38:51 -0500, Michael Satterwhite wrote: On Monday 21 June 2004 12:03, Monique Y. Mudama wrote: If you're trying to avoid any downtime or difficulty whatsoever, run stable and live with the age of the packages. Not exactly promoting Debian, are we? She is. Debian stable is an excellent argument in favor of running a Debian release. There's no other distribution or flavor providing its reliability or availability. I think perhaps stable, testing, and unstable were not the absolutely, positively best choices for the flavors but I can't say I could have done any better. These comments are however immaterial. Considering the fact that most distributions ship what debian would consider testing, and another OS sells unstable as a finished product, I think debian's flavor choices give users a good idea of what they are getting. If you need a machine that just runs, then stable is what you want. If your coming from another dist. and are used to applying patches regularly, testing is a good choice. If your coming from the other OS and are used to applying patches, recovering from crashes and having to go in and fix things manually, use unstable, although you might be disappointed, or board, because it's likely that you will have more time on your hands to actually use the machine then you did with the other OS (even though the other OS was released as 'stable' in 2002). Personally, my mission critical corp. servers run stable, all other servers run testing because I have work to do, and I can't take the chance of having to tell an executive that a machine, running 'unstable' has crashed, and I need to spend his/her time getting it to run again. Others here, however, are doing a much better job. You've missed the point and owe an apology. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Another testing vs unstable question
On Sun, Jun 20, 2004 at 11:13:37AM -0500, Michael Satterwhite wrote: A few weeks ago (I don't know about now), the KDE distribution in unstable simply would not run ... How does one recover from something like this short of doing a reload? Don't run KDE for a week or so until it's fixed? Downgrade to the version in Testing, which will still work? I mean, you DO know how to do both of those things from the command line, right? And how to get to the command line when X won't work? Otherwise, really, you shouldn't use Unstable. -- Carl Fink [EMAIL PROTECTED] Jabootu's Minister of Proofreading http://www.jabootu.com -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Another testing vs unstable question
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Sunday 20 June 2004 11:16, Carl Fink wrote: On Sun, Jun 20, 2004 at 11:13:37AM -0500, Michael Satterwhite wrote: A few weeks ago (I don't know about now), the KDE distribution in unstable simply would not run ... How does one recover from something like this short of doing a reload? Don't run KDE for a week or so until it's fixed? Downgrade to the version in Testing, which will still work? I mean, you DO know how to do both of those things from the command line, right? And how to get to the command line when X won't work? Otherwise, really, you shouldn't use Unstable. Certainly I can turn off KDE; cripples KDevelop which is needed, but can be done easily. As to downgrading, I've read answers to several questions saying that can't be done with apt. Unless those answers were wrong, no, I don't know how to - short of a reload. I'll take this for one vote that testing is actually a better choice than unstable. -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQFA1bnhjeziQOokQnARAq9UAJ9YYymDxyNU5mlTCpNy5yLtfD/92ACfd1Jw 4RZjkGNJypftRLfhhm85b28= =QeFr -END PGP SIGNATURE-
Re: Another testing vs unstable question
On Sun, Jun 20, 2004 at 11:13:37AM -0500, Michael Satterwhite wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I've been watching the various discussions on this, and note that most experienced types think that the unstable distribution is better than the testing distribution. This leads me to one more question / observation A few weeks ago (I don't know about now), the KDE distribution in unstable simply would not run. I've noted several of the messages recommending the unstable branch say that there were some updates that caused the receiving machines to crash / lock / not start. How does one recover from something like this short of doing a reload? For that matter, a reload should crash the same way as it's getting the same software. I may be missing something - quite likely, BTW, I'll admit total ignorance here - but it would appear that it wouldn't take many of these incidents to make the testing branch seem A LOT better than unstable. Your concerns are valid. Another example: ghostscript 8 is worthless. It renders very badly (documents look ugly) and won't render a lot of pdf files that ghostscript 7 rendered without problems. Now to answer your question: you first have to isolate the problem. If you have, you can downgrade to the version of testing or the last package in your /var/cache/apt/archives or add snapshot.debian.net to your sources. For example, I have downgraded my ghostscript packages and put them on hold. I will check the status of ghostcript 8 in some time. Most really ugly problems are fixed within a day. If not, you can always wait it out as it will generally sort itself out in a few days. Other than this, the arguments for the unstable over testing seem valid. And that's why a lot of people tend to take the uncommon problems for granted. HTH, David -- Hi! I'm a .signature virus. Copy me into your ~/.signature to help me spread! -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Another testing vs unstable question
Michael Satterwhite wrote: A few weeks ago (I don't know about now), the KDE distribution in unstable simply would not run. I've noted several of the messages recommending the unstable branch say that there were some updates that caused the receiving machines to crash / lock / not start. How does one recover from something like this short of doing a reload? Fix the problem yourself -- a lot of times an error message will point you to the exact line in the exact file that's causing the problem, and a quick look will reveal a missing quote mark in the preceding line or a misspelled word in the line, etc. or Wait for the problem to be fixed and for the fixed packages to become available; then install the fixed packages. In the meantime, use something other than KDE, such as Gnome, icewm, wmaker, fluxbox, ion, twm, sawfish, saffire, xfce, qvwm etc etc etc. -- Kent -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Another testing vs unstable question
On Sun, Jun 20, 2004 at 11:22:57AM -0500, Michael Satterwhite wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Sunday 20 June 2004 11:16, Carl Fink wrote: On Sun, Jun 20, 2004 at 11:13:37AM -0500, Michael Satterwhite wrote: A few weeks ago (I don't know about now), the KDE distribution in unstable simply would not run ... How does one recover from something like this short of doing a reload? Don't run KDE for a week or so until it's fixed? Downgrade to the version in Testing, which will still work? I mean, you DO know how to do both of those things from the command line, right? And how to get to the command line when X won't work? Otherwise, really, you shouldn't use Unstable. Certainly I can turn off KDE; cripples KDevelop which is needed, but can be done easily. As to downgrading, I've read answers to several questions saying that can't be done with apt. Unless those answers were wrong, no, I don't know how to - short of a reload. You can downgrade with apt, that's no problem at all! What you _can't_ do, is downgrading _all_ packages to the version numbers available in testing. If you downgrade, you have to specify things like apt-get install gs=7.07-1 Doing that for hundreds of packages is no fun. I'll take this for one vote that testing is actually a better choice than unstable. Not one vote. Maybe one argument in favour. David -- Hi! I'm a .signature virus. Copy me into your ~/.signature to help me spread! -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Another testing vs unstable question
On Sun, 20 Jun 2004 11:13:37 -0500 Michael Satterwhite [EMAIL PROTECTED] wrote: I've been watching the various discussions on this, and note that most experienced types think that the unstable distribution is better than the testing distribution. This leads me to one more question / observation A few weeks ago (I don't know about now), the KDE distribution in unstable simply would not run. I've noted several of the messages recommending the unstable branch say that there were some updates that caused the receiving machines to crash / lock / not start. How does one recover from something like this short of doing a reload? For that matter, a reload should crash the same way as it's getting the same software. I may be missing something - quite likely, BTW, I'll admit total ignorance here - but it would appear that it wouldn't take many of these incidents to make the testing branch seem A LOT better than unstable. You're right that this happened recently with KDE in unstable. What you're not aware of is that something similar happened last year with KDE in testing. More specifically, last year, KDE was uninstallable in testing for *several months*. -c -- Chris Metzler [EMAIL PROTECTED] (remove snip-me. to email) As a child I understood how to give; I have forgotten this grace since I have become civilized. - Chief Luther Standing Bear pgpY0XsEf2e8C.pgp Description: PGP signature
Re: Another testing vs unstable question
On Sun, Jun 20, 2004 at 11:22:57AM -0500, Michael Satterwhite wrote: Certainly I can turn off KDE; cripples KDevelop which is needed, but can be done easily. Cripples how? I run Konqueror without any other KDE component. Granted it still loads a lot of KDE and QT libraries, but it isn't crippled because I hate the K environment. -- Carl Fink [EMAIL PROTECTED] Jabootu's Minister of Proofreading http://www.jabootu.com -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Another testing vs unstable question
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Sunday 20 June 2004 11:25, Kent West wrote: In the meantime, use something other than KDE, such as Gnome, icewm, wmaker, fluxbox, ion, twm, sawfish, saffire, xfce, qvwm etc etc etc. That works for KDE, but what about the reported problems where the machine locks / won't boot / crashes / etc.? Fixing it without a computer is problematic at best g. Even waiting for a fix (go without a computer for a few days?) doesn't seem feasible as loading the fix requires a running computer. I'm not trying to be difficult, just learn. Obviously, you more experienced types have been through this; how do you handle it. -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQFA1cUXjeziQOokQnARAlkAAJsGZTk1mWoOVTEL8ypyTU0hZ4RBxQCfet71 qJKpvkVwEean7ViZ+H50qyE= =lm1A -END PGP SIGNATURE-
Re: Another testing vs unstable question
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Sunday 20 June 2004 11:40, David Fokkema wrote: On Sun, Jun 20, 2004 at 11:22:57AM -0500, Michael Satterwhite wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Sunday 20 June 2004 11:16, Carl Fink wrote: On Sun, Jun 20, 2004 at 11:13:37AM -0500, Michael Satterwhite wrote: A few weeks ago (I don't know about now), the KDE distribution in unstable simply would not run ... How does one recover from something like this short of doing a reload? Don't run KDE for a week or so until it's fixed? Downgrade to the version in Testing, which will still work? I mean, you DO know how to do both of those things from the command line, right? And how to get to the command line when X won't work? Otherwise, really, you shouldn't use Unstable. Certainly I can turn off KDE; cripples KDevelop which is needed, but can be done easily. As to downgrading, I've read answers to several questions saying that can't be done with apt. Unless those answers were wrong, no, I don't know how to - short of a reload. You can downgrade with apt, that's no problem at all! What you _can't_ do, is downgrading _all_ packages to the version numbers available in testing. If you downgrade, you have to specify things like Ah ... important information here! Thanks much -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQFA1cVHjeziQOokQnARAisgAJ4yaBHo4wDKW6WOH4iWuuLlazkF+wCeIofN IaQb/4bhz2WCqrGCIICB8Vs= =FaSe -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Another testing vs unstable question
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Sunday 20 June 2004 11:47, Chris Metzler wrote: You're right that this happened recently with KDE in unstable. What you're not aware of is that something similar happened last year with KDE in testing. More specifically, last year, KDE was uninstallable in testing for *several months*. Whoa!! You're right, I *DIDN'T* know that. I may need to rethink things. Debian Stable isn't a good choice for me; packages running nearly 2 years old aren't a good thing. Now I'm hearing that the current testing branch may not work either - and it's a given that the unstable won't from time to time. How did you handle this? -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQFA1cZPjeziQOokQnARAuqYAKCYT3EuAsh6anwlgiSfTOcSnLzshACglyrc Nw/V3Sx7lUDSZxPd/jhV/Ws= =eEnO -END PGP SIGNATURE-
Re: Another testing vs unstable question
Michael Satterwhite [EMAIL PROTECTED] wrote: A few weeks ago (I don't know about now), the KDE distribution in unstable simply would not run ... I was effected by this as well, yet not effected at all. This is where doing things by hand comes in very handy. When I ran dselect, it reported a huge number of KDE packages which were effected by broken dependency. At that point, I ctrl-C out of dselect, which leaves my system just as it was before. I checked the bug tracking and user mailing lists, noticed other people having the same problem, and relaxed. It wasn't an isolated problem. Every couple of days I would run dselect, update the list of packages, and if the same dependency problem happened I would simply break out and try later. One day, someone reported that the problem had been corrected, and sure enough dselect did not give me the list of dependency problems. The only people who's systems were twisted by this error were ones who do updates automatically. Automatic can work on Stable, where bug fixes are the rule. I would no more run automatic updates on Unstable or Testing than I would set the cruise control and go to sleep in my car at 75mph on a twisty road. How does one recover from something like this short of doing a reload? That shouldn't be a question by someone running Unstable. Unstable is exactly that, and should be considered to be an interactive learning experience. One of the reasons that I like dselect, other than that's what I used first, is it is a command line application. No matter how crippled the system gets, if it will boot it will run dselect. Curt- -- September 11th, 2001 The proudest day for gun control and central planning advocates in American history -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Another testing vs unstable question
On Sun, 20 Jun 2004 12:15:59 -0500 Michael Satterwhite [EMAIL PROTECTED] wrote: On Sunday 20 June 2004 11:47, Chris Metzler wrote: You're right that this happened recently with KDE in unstable. What you're not aware of is that something similar happened last year with KDE in testing. More specifically, last year, KDE was uninstallable in testing for *several months*. Whoa!! You're right, I *DIDN'T* know that. I may need to rethink things. Debian Stable isn't a good choice for me; packages running nearly 2 years old aren't a good thing. Now I'm hearing that the current testing branch may not work either - and it's a given that the unstable won't from time to time. How did you handle this? First of all, I handled it without any difficulty whatsoever because I don't use KDE. Most of the people tracking testing at that time who were bitten simply changed their sources.list to as if they tracked unstable, but only for the moment. They upgraded KDE, and KDE only, to the versions in unstable. Then, they backed their sources.list down to testing, and continued to track testing. Eventually, things sorted out. But this kind of thing happens often to testing when it's not near release. Right now, tracking testing is pretty safe, because the sarge release is (comparatively) not that far away. I don't know what the RC-bug status right now; but the main holdup on sarge has been the new installer, and everything I've read suggests that's close to finish. So sarge is not too far away from release, and so most of the stuff in sarge is in pretty good shape (one possible exception is GNOME 2.6, which is filtering down to testing from unstable right now, but isn't all there yet; I dunno how robust its partially-complete status it is in testing currently). But when sarge is farther from release, things can get very broken, and stay that way for quite some time. The problems that afflict unstable from time to time are almost always problems that can be recovered from fairly straightforwardly, if you know what you're doing. The issue is not the system, but the user/admin -- whether the user/admin can do those things to downgrade a broken package etc. -c -- Chris Metzler [EMAIL PROTECTED] (remove snip-me. to email) As a child I understood how to give; I have forgotten this grace since I have become civilized. - Chief Luther Standing Bear pgpbZyw0EFy6k.pgp Description: PGP signature
Re: Another testing vs unstable question
On Sun, 20 Jun 2004 12:10:30 -0500 Michael Satterwhite [EMAIL PROTECTED] wrote: On Sunday 20 June 2004 11:25, Kent West wrote: In the meantime, use something other than KDE, such as Gnome, icewm, wmaker, fluxbox, ion, twm, sawfish, saffire, xfce, qvwm etc etc etc. That works for KDE, but what about the reported problems where the machine locks / won't boot / crashes / etc.? Fixing it without a computer is problematic at best g. Even waiting for a fix (go without a computer for a few days?) doesn't seem feasible as loading the fix requires a running computer. This is where things like boot/rescue floppies, or distro CDs that you can boot off of and install modules (e.g. NIC module) from, come in very handy. -c -- Chris Metzler [EMAIL PROTECTED] (remove snip-me. to email) As a child I understood how to give; I have forgotten this grace since I have become civilized. - Chief Luther Standing Bear pgpnn7BhzOgkv.pgp Description: PGP signature
Re: Another testing vs unstable question
David Fokkema wrote: On Sun, Jun 20, 2004 at 11:22:57AM -0500, Michael Satterwhite wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Sunday 20 June 2004 11:16, Carl Fink wrote: On Sun, Jun 20, 2004 at 11:13:37AM -0500, Michael Satterwhite wrote: A few weeks ago (I don't know about now), the KDE distribution in unstable simply would not run ... How does one recover from something like this short of doing a reload? Don't run KDE for a week or so until it's fixed? Downgrade to the version in Testing, which will still work? I mean, you DO know how to do both of those things from the command line, right? And how to get to the command line when X won't work? Otherwise, really, you shouldn't use Unstable. Certainly I can turn off KDE; cripples KDevelop which is needed, but can be done easily. As to downgrading, I've read answers to several questions saying that can't be done with apt. Unless those answers were wrong, no, I don't know how to - short of a reload. You can downgrade with apt, that's no problem at all! What you _can't_ do, is downgrading _all_ packages to the version numbers available in testing. If you downgrade, you have to specify things like apt-get install gs=7.07-1 Doing that for hundreds of packages is no fun. Not exactly, if you put: Package: * Pin: release a=testing Pin-Priority: 1001 in /etc/apt/preferences, and do an apt-get dist-upgrade, apt will happily /try/ to downgrade every package to its testing version[alternatively adding that to /etc/apt/preferences will let you do apt-get install testing-package without needing the version number]. It just isn't guaranteed to work, and isn't considered a bug if it doesn't. signature.asc Description: OpenPGP digital signature
Re: Another testing vs unstable question
On Sun, Jun 20, 2004 at 02:24:45PM -0400, Travis Crump wrote: David Fokkema wrote: On Sun, Jun 20, 2004 at 11:22:57AM -0500, Michael Satterwhite wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Sunday 20 June 2004 11:16, Carl Fink wrote: On Sun, Jun 20, 2004 at 11:13:37AM -0500, Michael Satterwhite wrote: A few weeks ago (I don't know about now), the KDE distribution in unstable simply would not run ... How does one recover from something like this short of doing a reload? Don't run KDE for a week or so until it's fixed? Downgrade to the version in Testing, which will still work? I mean, you DO know how to do both of those things from the command line, right? And how to get to the command line when X won't work? Otherwise, really, you shouldn't use Unstable. Certainly I can turn off KDE; cripples KDevelop which is needed, but can be done easily. As to downgrading, I've read answers to several questions saying that can't be done with apt. Unless those answers were wrong, no, I don't know how to - short of a reload. You can downgrade with apt, that's no problem at all! What you _can't_ do, is downgrading _all_ packages to the version numbers available in testing. If you downgrade, you have to specify things like apt-get install gs=7.07-1 Doing that for hundreds of packages is no fun. Not exactly, if you put: Package: * Pin: release a=testing Pin-Priority: 1001 in /etc/apt/preferences, and do an apt-get dist-upgrade, apt will happily /try/ to downgrade every package to its testing version[alternatively adding that to /etc/apt/preferences will let you do apt-get install testing-package without needing the version number]. It just isn't guaranteed to work, and isn't considered a bug if it doesn't. Wow! I didn't know that, thanks! So debian is even better than I thought, :-) But then, I don't want to downgrade, and indeed, it might still not work. David -- Hi! I'm a .signature virus. Copy me into your ~/.signature to help me spread! -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Another testing vs unstable question
Michael Satterwhite wrote: On Sunday 20 June 2004 11:47, Chris Metzler wrote: You're right that this happened recently with KDE in unstable. What you're not aware of is that something similar happened last year with KDE in testing. More specifically, last year, KDE was uninstallable in testing for *several months*. Whoa!! You're right, I *DIDN'T* know that. I may need to rethink things. Debian Stable isn't a good choice for me; packages running nearly 2 years old aren't a good thing. Now I'm hearing that the current testing branch may not work either - and it's a given that the unstable won't from time to time. How did you handle this? I run stable on my important boxes, like servers, that need to be up 24x7, and I run unstable on my workstations. I have less pain on unstable workstations with their occasional breakages than I do on stable workstations with their ancient package versions. And I have _far_ less pain on unstable workstations than on any version of Windows-based workstation, even those with 1 GB of RAM on a 2.0 GHz P4 running Windows XP Professional and very little application software. Yes, unstable does indeed break sometimes, sometimes seriously so. But in the five or so years I've been running Debian, I've seen far less breakage on Debian unstable boxes than on Windows boxes (and much, much, much more recoverability). So if you've been able to live with Windows for the past few years, you can probably handle Debian unstable. -- Kent -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Another testing vs unstable question
Michael Satterwhite wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Sunday 20 June 2004 11:25, Kent West wrote: In the meantime, use something other than KDE, such as Gnome, icewm, wmaker, fluxbox, ion, twm, sawfish, saffire, xfce, qvwm etc etc etc. That works for KDE, but what about the reported problems where the machine locks / won't boot / crashes / etc.? Fixing it without a computer is problematic at best g. Even waiting for a fix (go without a computer for a few days?) doesn't seem feasible as loading the fix requires a running computer. In that case, you boot off some other bootable medium (boot floppies, Knoppix CD, etc), fix the problem, and then go on with life. Unless you have some really esoteric combination of hardware/software so that no one else is seeing the problem, by the time your problem hits you, somebody else has already hit the problem, figured it out, and posted a work-around on the net, most times. In the worst case scenario, run off a Knoppix CD for a couple of days until the problem gets fixed (although if the problem is that severe, other people are probably aware of it and a fix will be forthcoming in hours instead of days). -- Kent -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Another testing vs unstable question
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Sunday 20 June 2004 14:35, Kent West wrote: I run stable on my important boxes, like servers, that need to be up 24x7, and I run unstable on my workstations. I have less pain on unstable workstations with their occasional breakages than I do on stable workstations with their ancient package versions. That's an interesting observation. Thanks And I have _far_ less pain on unstable workstations than on any version of Windows-based workstation, even those with 1 GB of RAM on a 2.0 GHz P4 running Windows XP Professional and very little application software. I consider Windows XP an abomination by any standard. No question there. Yes, unstable does indeed break sometimes, sometimes seriously so. But in the five or so years I've been running Debian, I've seen far less breakage on Debian unstable boxes than on Windows boxes (and much, much, much more recoverability). So if you've been able to live with Windows for the past few years, you can probably handle Debian unstable. Although I've had to use Windows at some client sites, my personal machines have been essentially MS free for over a year. Some exceptions, there - I can't live without Quicken / Quickbooks / Final Draft. -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQFA1e9RjeziQOokQnARAvp9AKCmYieQN0eilOUnN+mWGNXShOI8kwCeMSmX DgfcjwHWqgw77cNaiwH/abs= =IqN0 -END PGP SIGNATURE-
Re: Another testing vs unstable question
On Sun, Jun 20, 2004 at 02:35:32PM -0500, Kent West wrote: Yes, unstable does indeed break sometimes, sometimes seriously so. But in the five or so years I've been running Debian, I've seen far less breakage on Debian unstable boxes than on Windows boxes (and much, much, much more recoverability). So if you've been able to live with Windows for the past few years, you can probably handle Debian unstable. Sure, but the apropos comparison is against SuSE or Mandrake or something, not Windows. At least IMO. Mind you, tracking Testing for the past two years I've had one significant problem (the KDE thing) which was only a difficulty at all in that I couldn't use Konqueror for a few weeks. -- Carl Fink [EMAIL PROTECTED] Jabootu's Minister of Proofreading http://www.jabootu.com -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Another testing vs unstable question
On Sunday 20 June 2004 12:48, Carl Fink wrote: On Sun, Jun 20, 2004 at 11:22:57AM -0500, Michael Satterwhite wrote: Certainly I can turn off KDE; cripples KDevelop which is needed, but can be done easily. Cripples how? I run Konqueror without any other KDE component. Granted it still loads a lot of KDE and QT libraries, but it isn't crippled because I hate the K environment. And I run Kmail (still, for a while...), Kile, Konqueror, and occasional other k-ish things from icewm with no problems. BTW, I have both sarge and sid running reasonable smoothly with precious little expertise here. -- richard -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Another testing vs unstable question
On Sunday 20 June 2004 16:10, Michael Satterwhite wrote: [...] Although I've had to use Windows at some client sites, my personal machines have been essentially MS free for over a year. Some exceptions, there - I can't live without Quicken / Quickbooks [...] Look at sql-ledger. You might like it. Really effective bookkeeping which runs in a browser, so you can set up remote access should you wish to. -- richard -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Another testing vs unstable question
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Sunday 20 June 2004 18:44, richard lyons wrote: On Sunday 20 June 2004 16:10, Michael Satterwhite wrote: [...] Although I've had to use Windows at some client sites, my personal machines have been essentially MS free for over a year. Some exceptions, there - I can't live without Quicken / Quickbooks [...] Look at sql-ledger. You might like it. Really effective bookkeeping which runs in a browser, so you can set up remote access should you wish to. It's the electronic banking that I use. For obvious reasons, I don't really want to play games with that. Hence cxoffice. -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQFA1ibMjeziQOokQnARApBaAJoDZ1LRun8HUMkbWInQCU9GLAlFkACgimkS R8dURZQ60+dyYjXrpxQ9P80= =KosS -END PGP SIGNATURE-
Re: Another testing vs unstable question
On Sun, Jun 20, 2004 at 11:22:57AM -0500, Michael Satterwhite wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Sunday 20 June 2004 11:16, Carl Fink wrote: On Sun, Jun 20, 2004 at 11:13:37AM -0500, Michael Satterwhite wrote: A few weeks ago (I don't know about now), the KDE distribution in unstable simply would not run ... How does one recover from something like this short of doing a reload? Don't run KDE for a week or so until it's fixed? Downgrade to the version in Testing, which will still work? I mean, you DO know how to do both of those things from the command line, right? And how to get to the command line when X won't work? Otherwise, really, you shouldn't use Unstable. Certainly I can turn off KDE; cripples KDevelop which is needed, but can be That would depend on why kde wouldn't start. If its just kde window manager or kdm then you wouldn't have a problem running it in any other window manager. done easily. As to downgrading, I've read answers to several questions saying that can't be done with apt. Unless those answers were wrong, no, I don't know how to - short of a reload. I'll take this for one vote that testing is actually a better choice than unstable. -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQFA1bnhjeziQOokQnARAq9UAJ9YYymDxyNU5mlTCpNy5yLtfD/92ACfd1Jw 4RZjkGNJypftRLfhhm85b28= =QeFr -END PGP SIGNATURE- +++ This Mail Was Scanned By Mail-seCure System at the Tel-Aviv University CC. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Another testing vs unstable question
On Sun, Jun 20, 2004 at 12:11:35PM -0500, Michael Satterwhite wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Sunday 20 June 2004 11:40, David Fokkema wrote: On Sun, Jun 20, 2004 at 11:22:57AM -0500, Michael Satterwhite wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Sunday 20 June 2004 11:16, Carl Fink wrote: On Sun, Jun 20, 2004 at 11:13:37AM -0500, Michael Satterwhite wrote: A few weeks ago (I don't know about now), the KDE distribution in unstable simply would not run ... How does one recover from something like this short of doing a reload? Don't run KDE for a week or so until it's fixed? Downgrade to the version in Testing, which will still work? I mean, you DO know how to do both of those things from the command line, right? And how to get to the command line when X won't work? Otherwise, really, you shouldn't use Unstable. Certainly I can turn off KDE; cripples KDevelop which is needed, but can be done easily. As to downgrading, I've read answers to several questions saying that can't be done with apt. Unless those answers were wrong, no, I don't know how to - short of a reload. You can downgrade with apt, that's no problem at all! What you _can't_ do, is downgrading _all_ packages to the version numbers available in testing. If you downgrade, you have to specify things like Ah ... important information here! Thanks much BTW if all else fails and you need to go farther back then you can always load the packages with whatever version you want manually from http://snapshot.debian.net/ and install it using dpkg -i package -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQFA1cVHjeziQOokQnARAisgAJ4yaBHo4wDKW6WOH4iWuuLlazkF+wCeIofN IaQb/4bhz2WCqrGCIICB8Vs= =FaSe -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] +++ This Mail Was Scanned By Mail-seCure System at the Tel-Aviv University CC. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Another testing vs unstable question
On Sun, Jun 20, 2004 at 11:25:30AM -0500, Kent West wrote: Michael Satterwhite wrote: A few weeks ago (I don't know about now), the KDE distribution in unstable simply would not run. I've noted several of the messages recommending the unstable branch say that there were some updates that caused the receiving machines to crash / lock / not start. How does one recover from something like this short of doing a reload? Fix the problem yourself -- a lot of times an error message will point you to the exact line in the exact file that's causing the problem, and a quick look will reveal a missing quote mark in the preceding line or a misspelled word in the line, etc. And if you don't know how to fix it but know which file is the problem you can find which package it came from using dpkg -S file name I think that there is also apt-file which will let you search for specific files, or in the debian package search page you also have an option to search bu file. or Wait for the problem to be fixed and for the fixed packages to become available; then install the fixed packages. In the meantime, use something other than KDE, such as Gnome, icewm, wmaker, fluxbox, ion, twm, sawfish, saffire, xfce, qvwm etc etc etc. -- Kent -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] +++ This Mail Was Scanned By Mail-seCure System at the Tel-Aviv University CC. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Another testing vs unstable question
On Sun, Jun 20, 2004 at 12:10:30PM -0500, Michael Satterwhite wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Sunday 20 June 2004 11:25, Kent West wrote: In the meantime, use something other than KDE, such as Gnome, icewm, wmaker, fluxbox, ion, twm, sawfish, saffire, xfce, qvwm etc etc etc. That works for KDE, but what about the reported problems where the machine locks / won't boot / crashes / etc.? Fixing it without a computer is problematic at best g. Even waiting for a fix (go without a computer for a few days?) doesn't seem feasible as loading the fix requires a running computer. Never had a computer that won't boot due to something that wasn't my fault (and even that was hard to achieve file system corruption), and I believe except for one time (my fault) I could still log in using single user mode or worst case scenario using init=/bin/bash (never had to use that one either). I'm not trying to be difficult, just learn. Obviously, you more experienced types have been through this; how do you handle it. -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQFA1cUXjeziQOokQnARAlkAAJsGZTk1mWoOVTEL8ypyTU0hZ4RBxQCfet71 qJKpvkVwEean7ViZ+H50qyE= =lm1A -END PGP SIGNATURE- +++ This Mail Was Scanned By Mail-seCure System at the Tel-Aviv University CC. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Another testing vs unstable question
On Sun, Jun 20, 2004 at 04:37:12PM -0400, Carl Fink wrote: On Sun, Jun 20, 2004 at 02:35:32PM -0500, Kent West wrote: Yes, unstable does indeed break sometimes, sometimes seriously so. But in the five or so years I've been running Debian, I've seen far less breakage on Debian unstable boxes than on Windows boxes (and much, much, much more recoverability). So if you've been able to live with Windows for the past few years, you can probably handle Debian unstable. Sure, but the apropos comparison is against SuSE or Mandrake or something, not Windows. At least IMO. Don't know whats their state now after they all adopted the apt methodology, but it used to be near to impossible to upgrade those systems. I used to run mandrake at work about two years ago and it took me less then a month to break it in a way that needed resinstalling. My previous computer running debian unstable ran fine for over six years with constant upgrades (until I stopped using it and it moved to my girlfriend who can't get used to linux). Actually it was an installation that migrated between two computers and three different hard-drives (went from 486 to PIII with no problem), not to mention the exotic hardware it ran along the years. Mind you, tracking Testing for the past two years I've had one significant problem (the KDE thing) which was only a difficulty at all in that I couldn't use Konqueror for a few weeks. -- Carl Fink [EMAIL PROTECTED] Jabootu's Minister of Proofreading http://www.jabootu.com -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] +++ This Mail Was Scanned By Mail-seCure System at the Tel-Aviv University CC. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Another testing vs unstable question
On Sun, Jun 20, 2004 at 01:01:01PM -0400, Curt Howland wrote: Michael Satterwhite [EMAIL PROTECTED] wrote: A few weeks ago (I don't know about now), the KDE distribution in unstable simply would not run ... I was effected by this as well, yet not effected at all. This is where doing things by hand comes in very handy. When I ran dselect, it reported a huge number of KDE packages which were effected by broken dependency. At that point, I ctrl-C out of dselect, which leaves my system just as it was before. I checked the bug tracking and user mailing lists, noticed other people having the same problem, and relaxed. It wasn't an isolated problem. Every couple of days I would run dselect, update the list of packages, and if the same dependency problem happened I would simply break out and try later. One day, someone reported that the problem had been corrected, and sure enough dselect did not give me the list of dependency problems. The only people who's systems were twisted by this error were ones who do updates automatically. Automatic can work on Stable, where bug fixes are the rule. I would no more run automatic updates on Unstable or Testing than I would set the cruise control and go to sleep in my car at 75mph on a twisty road. How does one recover from something like this short of doing a reload? That shouldn't be a question by someone running Unstable. Unstable is exactly that, and should be considered to be an interactive learning experience. One of the reasons that I like dselect, other than that's what I used first, is it is a command line application. No matter how crippled the system gets, if it will boot it will run dselect. also apt and aptitude ;-) Curt- -- September 11th, 2001 The proudest day for gun control and central planning advocates in American history -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] +++ This Mail Was Scanned By Mail-seCure System at the Tel-Aviv University CC. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Another testing vs unstable question
On Sun, 20 Jun 2004 11:13:37 -0500, Michael Satterwhite wrote: I've been watching the various discussions on this, and note that most experienced types think that the unstable distribution is better than the testing distribution. This leads me to one more question / observation It happened in Sarge/testing when KDE 3.1 was entering. I haven't had any problems with unstable (current) that I didn't have with testing (both Woody and Sarge)... ... with one exception: I tried installing GNOME 2.0 from Ximian onto a new Woody/testing system and I could neither get it to work nor downgrade to GNOME 1.4. How does one recover from something like this short of doing a reload? * Buddha enlightenment * Expert assistance * Educated guesses * Trial and error Other than this, the arguments for the unstable over testing seem valid. I'm convinced; also, my combination of expert assistance, educated guesses and trial and error have corrected the few things that have gone wrong. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Another testing vs unstable question
On Sun, 20 Jun 2004 12:15:59 -0500, Michael Satterwhite wrote: On Sunday 20 June 2004 11:47, Chris Metzler wrote: What you're not aware of is that something similar happened last year with KDE in testing. More specifically, last year, KDE was uninstallable in testing for *several months*. How did you handle this? Patience, Grasshopper. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
