Re: Debian sid and risk management
Something I proposed a while back: A workable backtracking mechanism in apt. There already is for single off-site packages--an option to explicitely enable a downgrade back to the original. Simplest would be the backtrack to the previous systems configuration. Snapshots would be a larger and more complex solution. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Debian sid and risk management
On Tue, Dec 28, 2004 at 01:53:21PM +0200, David Baron wrote: Something I proposed a while back: A workable backtracking mechanism in apt. I'll post version 2.0 of my script that does this, with some documentation, here presently. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Debian sid and risk management
Greg Folkert wrote: So what do you think of those of us that *DO* use Sid + Experimental for Production? Careful what you say... I do have experience with Debian. No I am not an idiot, I have very UN-limited needs, I have been known to talk out of /dev/ass, have built very elaborate systems to ensure other's work Greg, whay are you wasting so much of your time to rebuke the opinions of Mr. Kelley ? His opinions are valuable as any other and, sadly, expressed with a tone that surely does not make them sound more authoritative than the tantrums of a freckled face 14 yr old nerd. Bob -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Debian sid and risk management
On Monday 27 December 2004 03:58, Bob Alexander wrote: Kelley ? His opinions are valuable as any other and, sadly, expressed with a tone that surely does not make them sound more authoritative than the tantrums of a freckled face 14 yr old nerd. He has freckles? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Debian sid and risk management
On Sun, 2004-12-26 at 22:39 -0600, Tim Kelley wrote: --snip-- If you think testing or unstable is suitable for production systems you are one of 1. an idiot 2. have very limited needs/no experience 3. talking out of your ass 4. have no concept of what it means to be responsible for others' work Thanks for the kind words. :) My comment regarding the nuclear defense grid was a reference to mission critical systems. If production DEPENDS on a server being up no matter what, then absolutely, you should be running Woody. However, since the majority of the work that I do is IT outsourcing for companies, most of the servers that we put together are for internal or non-mission critical external applications. In these cases, running Sid is perfectly acceptable and preferable, since our customers tend to be more interested in having better features available and they can survive if they go without email for 3 hours in a year. And having 19 Sid servers in our data center and another 68 at customer sites with no major problems in nearly 4 years should go a ways towards illustrating that. But I do absolutely agree that for mission critical systems, stable should be the only real choice. -- Alex Malinovich Support Free Software, delete your Windows partition TODAY! Encrypted mail preferred. You can get my public key from any of the pgp.net keyservers. Key ID: A6D24837 signature.asc Description: This is a digitally signed message part
Re: Debian sid and risk management
On Mon, 2004-12-27 at 09:18 -0600, Alex Malinovich wrote: On Sun, 2004-12-26 at 22:39 -0600, Tim Kelley wrote: --snip-- If you think testing or unstable is suitable for production systems you are one of 1. an idiot 2. have very limited needs/no experience 3. talking out of your ass 4. have no concept of what it means to be responsible for others' work Thanks for the kind words. :) My comment regarding the nuclear defense grid was a reference to mission critical systems. If production DEPENDS on a server being up no matter what, then absolutely, you should be running Woody. However, since the majority of the work that I do is IT outsourcing for companies, most of the servers that we put together are for internal or non-mission critical external applications. In these cases, running Sid is perfectly acceptable and preferable, since our customers tend to be more interested in having better features available and they can survive if they go without email for 3 hours in a year. And having 19 Sid servers in our data center and another 68 at customer sites with no major problems in nearly 4 years should go a ways towards illustrating that. But I do absolutely agree that for mission critical systems, stable should be the only real choice. With or without backports? Or hand compiled packages? or Third Party (read as non-Debian) software that needs non-Debian package (as in not packaged by Debian Developers for Debian)? To what extent do you see, MISSION CRITICAL SYSTEMS being? an example please. context: I also agree that for mission critical systems, stable should be the only real choice. I just want to know what justifications lead others to these conclusions. As I sometimes have wildly different schema for my classifications and just want to see just how wild they really are. Thanks in advance. -- greg, [EMAIL PROTECTED] The technology that is Stronger, better, faster: Linux signature.asc Description: This is a digitally signed message part
Re: Debian sid and risk management
On Mon, 2004-12-27 at 11:40 -0500, Greg Folkert wrote: On Mon, 2004-12-27 at 09:18 -0600, Alex Malinovich wrote: --snip-- But I do absolutely agree that for mission critical systems, stable should be the only real choice. With or without backports? Or hand compiled packages? or Third Party (read as non-Debian) software that needs non-Debian package (as in not packaged by Debian Developers for Debian)? A mission critical system definitely should not use backports and definitely SHOULD use security updates. Hand compiled packages are left to your discretion. Sometimes they are necessary, but are you confident enough in the software and have you tested it thoroughly with an identical test system for a prolonged period to make sure it won't break? Third-party software should observe all of the considerations for hand-compiled packages. Further considerations in the case of commercial software include warranties and certification of the software. If the software does break and brings your business to a grinding halt, what will the vendor to rectify the situation, and how quickly will they do it? Keep in mind that most vendors will only certify to big-name distributions like Red Hat and will not support a Debian installation. This is always up to your discretion, but if my job were riding on a system staying up I certainly wouldn't risk using commercial software on an unsupported platform. To what extent do you see, MISSION CRITICAL SYSTEMS being? an example please. A mission critical system is a production system which handles a major and important portion of the production process. In a previous life I worked in the IT department for a large steel company. Mission critical there meant any of the production line computers. If any of these fails, the entire line needs to be shut down. The cost of this is in the MILLIONS of dollars and that is not even considering lost profits and lost materials. Just to stop the line and start it back up is in the MILLIONS. THAT is mission critical. One of our clients at my current job runs their business almost exclusively through faxes. They have 6 servers, each handling 4 fax lines, and they go through roughly 4000 faxes in a typical day. A downtime of 1 minute could translate to 24 lost or delayed faxes, each to or from a very important customer. That's mission critical. Needless to say these boxes are all running Woody. A web or mail server for a company that does not rely on e-commerce would be non-mission critical in my opinion. A Sid system in normal operation can easily provide 99.999% uptime or better. That's roughly 9 hours of down-time in a year. (One of our file servers running Sid has been up for 480 days, so far in '04 it's at 100% uptime.) A Woody system should be able to do 99.% or even 99.9% uptime. 1 hour or 5 minutes of down-time in a year, respectively. -- Alex Malinovich Support Free Software, delete your Windows partition TODAY! Encrypted mail preferred. You can get my public key from any of the pgp.net keyservers. Key ID: A6D24837 signature.asc Description: This is a digitally signed message part
Re: Debian sid and risk management
Rogério Brito wrote: Just hang on a second! If you are so afraid of breaking your system, you should not be using sid, but using testing instead. Did I really sound that afraid ?! Natural language is such an imprecise tool. Especially when two different mothertongue use a third language to communicate.:) My (quite long) experience with unstable shows me the risk level is manageable. Take care, Bob -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Debian sid and risk management
On Sat, 2004-12-25 at 10:05 -0600, Alex Malinovich wrote: [snip] Sid is probably not the right choice if you need to run a nuclear defense grid, but for day to day work on the desktop and even on servers, it's plenty stable enough in my experience. I agree with this, with the caveat that you should already be experienced with Debian before you try to do it seriously. It will run flawlessly most of the time, but eventually an upgrade, or something you try to do (e.g. installing from another unstable repository) will probably require some maintenance. With that said, what I usually do for my servers is do an update every two weeks, storing the list of packages that WOULD be upgraded in a text file. Then when I do my next update, I compare that list vs the list of two weeks ago and only install the packages that HAVEN'T changed. This gives me a selection of two week old packages that MOST LIKELY work (since critical bugs are usually fixed within two weeks). That's not a bad idea; I would almost consider doing that on my desktops (although atm testing/sarge is pretty up to date on the user visible stuff, e.g. GNOME). FWIW: on my servers, I run a mix of testing/unstable; to minimize unforeseen downtime I only upgrade every 3-6 months (and keep my ear to the ground for security issues in the applications we run, in case I might need to do it sooner). mb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Debian sid and risk management
On Sat, 2004-12-25 at 10:05 -0600, Alex Malinovich wrote: Sid is probably not the right choice if you need to run a nuclear defense grid, but for day to day work on the desktop and even on servers, it's plenty stable enough in my experience. Running unstable on an outward-facing server is probably a bad idea because security holes could be present. The general advice I've heard on this list is run wooody+security updates + backports. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Debian sid and risk management
On Sun, 2004-12-26 at 14:42 -0500, William Ballard wrote: On Sat, 2004-12-25 at 10:05 -0600, Alex Malinovich wrote: Sid is probably not the right choice if you need to run a nuclear defense grid, but for day to day work on the desktop and even on servers, it's plenty stable enough in my experience. Running unstable on an outward-facing server is probably a bad idea because security holes could be present. The general advice I've heard on this list is run wooody+security updates + backports. Well, when a security hole in an application is found the next version of the application usually includes a fix, so by keeping the system regularly updated with the newest versions of a package it SHOULD keep most of the holes plugged. woody + security is definitely the safest bet, but see my previous statements about running a nuclear defense grid or something less critical. -- Alex Malinovich Support Free Software, delete your Windows partition TODAY! Encrypted mail preferred. You can get my public key from any of the pgp.net keyservers. Key ID: A6D24837 signature.asc Description: This is a digitally signed message part
Re: Debian sid and risk management
With that said, what I usually do for my servers is do an update every two weeks, storing the list of packages that WOULD be upgraded in a text file. Then when I do my next update, I compare that list vs the list of two weeks ago and only install the packages that HAVEN'T changed. This gives me a selection of two week old packages that MOST LIKELY work (since critical bugs are usually fixed within two weeks). Seems to be a good way to operate, rather secure... But isn't there a way to manage this automatically ? It doesn't sounds impossible nor stupid, does it ? -- Marc Demlenne GPG : 768FA483 (http://pgp.mit.edu) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Debian sid and risk management
On Sun, Dec 26, 2004 at 11:08:17PM +0100, Marc Demlenne wrote: Seems to be a good way to operate, rather secure... But isn't there a way to manage this automatically ? It doesn't sounds impossible nor stupid, does it ? It's really easy to set up your own dists directory with a tweaked 'Packages.gz' in it. In the FOSS world this is generally done by individual hackers using perl, and occasionally they package it. But if it's not available just write it yourself, hacking something for personal use only. That's what I've done. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Debian sid and risk management
On Saturday 25 December 2004 10:05, Alex Malinovich wrote: Sid is probably not the right choice if you need to run a nuclear defense grid, but for day to day work on the desktop and even on servers, it's plenty stable enough in my experience. You've got to be kidding me. I've run sid for about five years now and no way in hell would I even think of considering using it for a production system. This is the whole point of stable. If you think testing or unstable is suitable for production systems you are one of 1. an idiot 2. have very limited needs/no experience 3. talking out of your ass 4. have no concept of what it means to be responsible for others' work I am getting really sick of people pushing sid for production use. Please stop doing it. I don't really care if it meets your needs. If it does, you are a tiny minority; your experience with it in this capacity is anecdotal, and none of it is likely to have any bearing on anyone else's needs. -- _ _ _ _ _ _ _ _ _ _ _ _ _ / \ / \ / \ / \ / \ / \ / \ / \ / \ / \ / \ / \ / \ ( t | i | m | @ | i | t | . | k | p | t | . | c | c ) \_/ \_/ \_/ \_/ \_/ \_/ \_/ \_/ \_/ \_/ \_/ \_/ \_/ GPG key fingerprint = 1DEE CD9B 4808 F608 FBBF DC21 2807 D7D3 09CA 85BF -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Debian sid and risk management
On Sun, Dec 26, 2004 at 10:39:47PM -0600, Tim Kelley wrote: I am getting really sick of people pushing sid for production use. Please stop doing it. I don't really care if it meets your needs. If it does, you are a tiny minority; your experience with it in this capacity is anecdotal, and none of it is likely to have any bearing on anyone else's needs. At Microsoft the largest domain is NORTHAMERICA. It runs production code but they switch to (for example) Windows 2003 and the latest Exchange at least a year before the products are released. Microsoft.com switched to Windows 2003 at least 9 months before it was released. They also run a domain called NTDEV, aka Dogfood. This is equivalent to Sid. They use it for all sorts of development things. So running sid on development or intranet servers might be useful. But Tim is 100% right for outward facing, it has to work servers. But there are some servers where reliability isn't the highest goal. But the bar is pretty high for doing something stupid like running Sid on a server. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Debian sid and risk management
On Sun, 2004-12-26 at 22:39 -0600, Tim Kelley wrote: On Saturday 25 December 2004 10:05, Alex Malinovich wrote: Sid is probably not the right choice if you need to run a nuclear defense grid, but for day to day work on the desktop and even on servers, it's plenty stable enough in my experience. You've got to be kidding me. I've run sid for about five years now and no way in hell would I even think of considering using it for a production system. This is the whole point of stable. If you think testing or unstable is suitable for production systems you are one of 1. an idiot 2. have very limited needs/no experience 3. talking out of your ass 4. have no concept of what it means to be responsible for others' work I am getting really sick of people pushing sid for production use. Please stop doing it. I don't really care if it meets your needs. If it does, you are a tiny minority; your experience with it in this capacity is anecdotal, and none of it is likely to have any bearing on anyone else's needs. So what do you think of those of us that *DO* use Sid + Experimental for Production? Careful what you say... I do have experience with Debian. No I am not an idiot, I have very UN-limited needs, I have been known to talk out of /dev/ass, have built very elaborate systems to ensure other's work Yes, I use Sid/Experimental for certain things. No not everything. I use Sarge for many other things, have for quite a while. Woody, I have no Woody machines. I understand Debian, how to manage those updates. Use sacrificial testing (as in a lesser powered, but identical in functionality) machines to test out any upgrades/updates. One other thing, if you have run Redhat anything... you were running a system comparable to Sid. I argue this, as seen with many of the same problems wrecking many a machines during a upgrade/update/security update/etc... Sid, from time to time has these same issues, but not to the extreme that those updates caused for the other Distro. -- greg, [EMAIL PROTECTED] The technology that is Stronger, better, faster: Linux signature.asc Description: This is a digitally signed message part
Re: Debian sid and risk management
On Sun, Dec 26, 2004 at 02:42:31PM -0500, William Ballard wrote: On Sat, 2004-12-25 at 10:05 -0600, Alex Malinovich wrote: Sid is probably not the right choice if you need to run a nuclear defense grid, but for day to day work on the desktop and even on servers, it's plenty stable enough in my experience. Running unstable on an outward-facing server is probably a bad idea because security holes could be present. The general advice I've heard on this list is run wooody+security updates + backports. Backports are far more likely to have known but unpatched security holes than packages in unstable. Unstable is really no less insecure from that POV than stable. -- For every sprinkle I find, I shall kill you! -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Debian sid and risk management
On Sat, 2004-12-25 at 16:48 +0100, Bob Alexander wrote: --snip-- While I love using sid because of the very current releases and I am willing to take the risk of having to debug some problems, being the system I WORK with the only I have, getting fundamental things wrong can seriously impact my job. While this doesn't actually answer your question about how to check the age of a package, I do feel that I should inject a comment about the relative stability of Sid here. My primary machine at work is a Debian-only machine running Sid AND Experimental. In the last 6 months or so, I have spent probably about 5 - 6 hours working through problems caused by packages on my system, ALL of them caused by Experimental. All of the servers that I use for my day to day work also run Sid, and I've never had a problem with any of them that wasn't caused by user error. Sid is probably not the right choice if you need to run a nuclear defense grid, but for day to day work on the desktop and even on servers, it's plenty stable enough in my experience. With that said, what I usually do for my servers is do an update every two weeks, storing the list of packages that WOULD be upgraded in a text file. Then when I do my next update, I compare that list vs the list of two weeks ago and only install the packages that HAVEN'T changed. This gives me a selection of two week old packages that MOST LIKELY work (since critical bugs are usually fixed within two weeks). -- Alex Malinovich Support Free Software, delete your Windows partition TODAY! Encrypted mail preferred. You can get my public key from any of the pgp.net keyservers. Key ID: A6D24837 signature.asc Description: This is a digitally signed message part
Re: Debian sid and risk management
Bob Alexander wrote: Background considerations, question follows: When I was studying as a doctor (a lng time ago) my Pharmacology professor told us: A good doctor is never the first to use a new medicine and never the last to abandon an old one and later on my sailplane instructor told me: There are old pilots and bold pilots but NO old bold pilots While I love using sid because of the very current releases and I am willing to take the risk of having to debug some problems, being the system I WORK with the only I have, getting fundamental things wrong can seriously impact my job. Just as an example, in the moment I write, synaptic tells me I could upgrade LVM2, login, and HAL. If these bomb I would be in trouble. If xpdf bombed it would be a little annoying but nothing more. One solution for the fundamental packages (please do not call me coward but only cautious) would be, (like the medicine example on top) to wait a little time (say one week ten days) before installing any new packages and before that checking if/which serious bugs have been reported. Or you could use William Ballard's system of keeping the upgrades separate by differently labeled .deb directories and simply reverting to a set of .debs that worked if you run into problems. He has posted his scripts to this list at least twice that I know of. HTH H -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Debian sid and risk management
On Saturday 25 December 2004 10:48 am, Bob Alexander wrote: snip Is there an automatic way to check even only for the number of severe bugs for a package from any of the package manager frontends ? Install the apt-listbugs package. -- ...Rob Return address is obfuscated. You can reach me via mylaptop (at) twcny dot rr dot com -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Debian sid and risk management
Hugo Vanwoerkom wrote: Or you could use William Ballard's system of keeping the upgrades separate by differently labeled .deb directories and simply reverting to a set of .debs that worked if you run into problems. He has posted his scripts to this list at least twice that I know of. Sounds nice. Could not locate the resource though ... can you help further ? TIA, Bob -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Debian sid and risk management
Rob Bochan wrote: On Saturday 25 December 2004 10:48 am, Bob Alexander wrote: snip Is there an automatic way to check even only for the number of severe bugs for a package from any of the package manager frontends ? Install the apt-listbugs package. Sounds GREAT. Tried reading or finding examples on Google ... Did I understand correctly ? When installed the apt-listbugs will be automatically invoked when synaptic or command line apt-get install or upgrade will be performed. It will warn of critical bugs pending on each of the files to be downloaded. Is that it ? TIA, Bob -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Debian sid and risk management
On Saturday 25 December 2004 12:45 pm, Bob Alexander wrote: snip It will warn of critical bugs pending on each of the files to be downloaded. Is that it ? According to http://packages.debian.org/unstable/admin/apt-listbugs apt-listbugs is a tool which retrieves bug reports from the Debian Bug Tracking System and lists them. Especially, it is intended to be invoked before each upgrade/installation by apt in order to check whether the upgrade/installation is safe. Many developers and users prefer the unstable version of Debian for its new features and packages. apt, the usual upgrade tool, can break your system by installing a buggy package. apt-listbugs lists critical bug reports from the Debian Bug Tracking System. Run it before apt to see if an upgrade or installation is known to be unsafe. I use it myself on my laptop that runs Sid, which I use for my business, to check to see if there's anything major I need to know before I upgrade anything. It runs automatically whenever I run apt-get upgrade. It's saved my butt more than once. -- ...Rob Return address is obfuscated. You can reach me via mylaptop (at) twcny dot rr dot com -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Debian sid and risk management
Rob Bochan wrote: I use it myself on my laptop that runs Sid, which I use for my business, to check to see if there's anything major I need to know before I upgrade anything. It runs automatically whenever I run apt-get upgrade. It's saved my butt more than once. Thank you very much Rob. Of course you should not trust packages which have just appeared since they will most probably never have crit bugs. Correct ? For instance the LVM2 and HAL examples I was making appeared a few hours agon on the mirror I use. Ciao. Bob -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Debian sid and risk management
Bob Alexander escribe: Is that it ? Is that it. However, it's useful to have one's system wholy fu***d down at least once in one's live, just to know what sid's really about. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Debian sid and risk management
Bob Alexander wrote: One solution for the fundamental packages (please do not call me coward but only cautious) would be, (like the medicine example on top) to wait a little time (say one week ten days) before installing any new packages and before that checking if/which serious bugs have been reported. That's close to how the testing distribution works. Of course with testing there's the issue of getting up-to-date security fixes. -- see shy jo signature.asc Description: Digital signature
Re: Debian sid and risk management
On Dec 25 2004, Bob Alexander wrote: Of course you should not trust packages which have just appeared since they will most probably never have crit bugs. Correct ? For instance the LVM2 and HAL examples I was making appeared a few hours agon on the mirror I use. Just hang on a second! If you are so afraid of breaking your system, you should not be using sid, but using testing instead. With testing, you have relatively recent software and you are protected by the barrier of the testing scripts, that only let a package get into testing if things are reasonably consistent. You can even use apt-pinning for grabbing something from unstable in the rare event that you need something from there. But, IMVHO, every user that depends on some stability and, for some reason, needs newer packages than those in stable, should use testing instead, not sid. This way, you are helping the Debian community by seeing if testing is in a releasable state (which is the intention, anyway). Of course, if you don't *need* stability, then go ahead and use sid. And file the bugs that you encounter, perhaps preventing the package from floating to testing. Just my 2 cents, Rogério Brito. -- Learn to quote e-mails decently at: http://pub.tsn.dk/how-to-quote.php http://learn.to/quote http://www.xs4all.nl/~sbpoley/toppost.htm -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Debian sid and risk management
On Dec 25 2004, kurtz wrote: However, it's useful to have one's system wholy fu***d down at least once in one's live, just to know what sid's really about. Yes, that is a good lesson. The hard way to learn, but also a good way to see if you can get your act together when big troubles come haunt you. Conservatively yours, Rogério Brito. -- Learn to quote e-mails decently at: http://pub.tsn.dk/how-to-quote.php http://learn.to/quote http://www.xs4all.nl/~sbpoley/toppost.htm -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
