Re: Transitioning to 64bit, is it worth it, and how
So I installed a system where / and /boot are not on raid and low and behold grub seemed to successfully install the boot sector and I could boot the disks. Making the /boot partition on a RAID is generally not possible with GRUB (don't know about LILO). It supposedly can be done if the RAID is just an MD mirror but I remember there being some caveats. So I wouldn't be surprised if the installer doesn't get it right. However I now hit the next problem = the installer somehow thought my drives were /dev/sde and /dev/sdf (rather than /dev/sda and /dev/sdb that they originally were) so created /etc/fstab, and the grub menu.lst entries refering to these drives. However when booting the new system it expected /dev/sda and /dev/sdb and so root failed to mount. I had to go back into the installer and manually edit files in the target system to make it work. My /etc/fstab doesn't use the /dev/sd* names: all my partitions are either under LVM (and hence have the names I chose to give them) or are labelled so that I can use /dev/disk/by-label/*. In Grub I always use hd0. Stefan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Transitioning to 64bit, is it worth it, and how
On 8/4/07, Alan Chandler [EMAIL PROTECTED] wrote: I have a Core2 Duo on which I am running a 686 kernel (from Debian unstable). It has 1GB of memory I am wondering two things a) What are the pros and cons in switching to 64 bit mode? - Is it faster? I am only responding to this particular message in the thread because my computer is still not fully operational and this is the only way (at the moment) to comment on this process. The whole process has been a nightmare - and not really anything to do with 64 bit architecture - although I haven't yet got to the point of finding out how to run flash in IceWeasel and Konqueror I had a raid 1 setup with a 32M /boot partition, a 4G / partition and a large LVM on raid 1 partition for the rest (except swap - which takes equal space on my two drives). The drives are SATA - originally on /dev/sda and /dev/sdb I used the debian netinst disk from this weeks lenny. Firstly I wanted to increase /boot from 32M to 100M because I kept getting disk full on upgrades. So in the installer I deleted the /boot and swap partitions and recreated them. For reasons I don't understand - although the old raid devices had both /dev/md[12] and /dev/md/[12] entries the new boot only had a /dev/md3 entry. However the installation seem to go well until it ran grub to install the boot sector. Thie appeared to work. However, as soon as I tried rebooting this new system the BIOS told me it couldn't find a boot disk. Everywhere I searched on the net, there is plenty of people who claim it does work - and with examples of what to do. I tried them all - but none worked. I even tried lilo - but I couldn't get that to work either. After much frustration I decided to just try installing the new system without raid on root and boot partitions. This is where the problem with the /dev/md3 entry wouldn't work because the partitioner failed to allow me to delete this device. Again after much frustration I created a symlink /dev/md/3 to /dev/md3 and was able to make it work. So I installed a system where / and /boot are not on raid and low and behold grub seemed to successfully install the boot sector and I could boot the disks. However I now hit the next problem = the installer somehow thought my drives were /dev/sde and /dev/sdf (rather than /dev/sda and /dev/sdb that they originally were) so created /etc/fstab, and the grub menu.lst entries refering to these drives. However when booting the new system it expected /dev/sda and /dev/sdb and so root failed to mount. I had to go back into the installer and manually edit files in the target system to make it work. I have been able to go back to raid - by using mdadm to create a raid 1 array with a missing entry and /dev/sdb[13] as the component devices. I mounted these as /dev/md1 and /dev/md3 and rsync'ed the contents of / (/dev/sda3) and /boot (dev/sda1) across to them. Editing in fstab and grub's menu.lst to reflect the change of devices and a reboot I had a system running on raid. Finally repartitioned /dev/sda[13] as raid autodetect partitions and added them into the existing arrays as the second device. I did make a big mistake at this point and forgot to a) Update /etc/mdadm/mdadm.conf with the raid array details b) Run update-initramfs So on next reboot I got bounced into a shell inside initramfs and had to manually assemble to raid arrays before I could carry on (and then correct that mistake). Hopefully when I get home from work this evening I can continue (can't get Xorg working - but I have a backup of my xorg.conf so that should solve this). -- Alan Chandler [EMAIL PROTECTED] (via webmail - normally means I am not at my computer) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Transitioning to 64bit, is it worth it, and how
On Mon, Aug 06, 2007 at 12:55:46PM +0100, Alan Chandler wrote: On 8/4/07, Alan Chandler [EMAIL PROTECTED] wrote: I have a Core2 Duo on which I am running a 686 kernel (from Debian unstable). It has 1GB of memory I am wondering two things a) What are the pros and cons in switching to 64 bit mode? - Is it faster? I am only responding to this particular message in the thread because my computer is still not fully operational and this is the only way (at the moment) to comment on this process. [snip many woes] When you ran the installer, did you start from scratch? Did you start by removing your existing partitions? I don't think you can reuse a 32-bit software raid setup on 64-bit (don't know, never tried). The only thing you can probably reuse is your /home, however, if /home is on a raid or LVM partition, you may not be able to reuse it either. If this is the case, at the beginning of the installer, choose a disk to partition and tell it to ignore the partition table and start from scratch. If it doesn't let you do that either, restart the installer, and go to the VC with a shell and #dd if=/dev/zero of=/dev/[drive toclear] bs=512 count=1 to clear the partition table. Doug. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Transitioning to 64bit, is it worth it, and how
On Monday 06 August 2007, Douglas Allan Tutty wrote: On Mon, Aug 06, 2007 at 12:55:46PM +0100, Alan Chandler wrote: On 8/4/07, Alan Chandler [EMAIL PROTECTED] wrote: I have a Core2 Duo on which I am running a 686 kernel (from Debian unstable). It has 1GB of memory I am wondering two things a) What are the pros and cons in switching to 64 bit mode? - Is it faster? I am only responding to this particular message in the thread because my computer is still not fully operational and this is the only way (at the moment) to comment on this process. [snip many woes] When you ran the installer, did you start from scratch? Did you start by removing your existing partitions? I don't think you can reuse a 32-bit software raid setup on 64-bit (don't know, never tried). I needed to keep my LVM on Raid partition, because that was where my home was. That part worked great. It would seem to me a really bad idea to not have compatibility between the two. I only destroyed the /boot and swap partitions whilst I resized them (inside the partitioner inside the installer), and then told the partitioner in the installer to set them up as raid (you go into a raid submenu to create a raid device). The / (root) partition I asked the installer to reformat, but didn't change it -- Alan Chandler http://www.chandlerfamily.org.uk -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Transitioning to 64bit, is it worth it, and how
is because there is a penalty for executing 32-bit code, one which is There is none (if you use the 32bit subset of the AMD64 architecture). But there is a penalty for using the x86 architecture instead of the amd64 architecture. This penalty is not specific to the Athlon64/Opteron/younameit, but to all known x86 implementation: it's just the the x86 architecture has few registers and this limitation was partly lifted in the amd64 architecture. So the penalty you're talking about, is there because the amd64 architecture did more than extend pointers and int to 64bit, it also fixed a few problems in the x86 architecture. It has nothing to do with whether or not the amd64 is a true 64 bit architecture, whatever that may mean. Stefan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Transitioning to 64bit, is it worth it, and how
Andrew J. Barr wrote: Ron Johnson wrote: Andrew J. Barr wrote: Yes. Unlike true 64-bit architectures like PowerPC, there is a penalty for executing 32 bit code on amd64/em64t processors. Most certainly incorrect. In fact natively compiled AMD64 64-bit compiled code *may* run faster due to better optimizations available by having more registers available. But typically amd64 runs both 32-bit and 64-bit at similar performance levels. Penalty? Absolutely fscking not The A64 processes 32 bit code at a similar speed to regular Athlon CPUs. Most emphatically agree! Do you have any sources for this? Search the web. I am too lazy to go looking myself at this moment. I remember quite distinctly seeing on a mailing list, I think it was debian-powerpc in fact, that the only reason that AMD64 operating systems have an all-64-bit user land is because there is a penalty for executing 32-bit code, one which is not present on other true 64-bit architectures. Ahem, that is incorrect. For example Red Hat and SuSE GNU/Linux on amd64 install a biarch model with dual support for both 32-bit and 64-bit. So I would put forward that most amd64 systems support both 32-bit and 64-bit out of the box. The reason Debian is a pure 64-bit system is simply that the biarch model used by Red Hat and SuSE is terrible. It is too ugly for words. There was huge discussion about how to support amd64 for Debian. The obvious way to go is the multiarch model but no one could agree to actually do it. Meanwhile a pure 64-bit port was pretty simple, direct and without serious complication. A pure 64-bit port would be quite useful to a large segment of the population. Even if agreement could not be reached on either biarch or multiarch a pure 64-bit port could be made and would be useful and could transition to multiarch in the future when the issues were resolved with it. But even so there was huge resistance because it was not a perfect solution and did not support 32-bit applications out of the box. Arguments ensued. The amd64 port was prevented from entering Debian Sarge. A sad time all things considered. Debian went with a pure 64-bit model on amd64 out of a pragmatic attitude that it was good enough and that pursuit of a perfect multiarch model should not prevent using 64-bit amd64 now. There was never any issue of performance difference entering into the discussion. A review of the early days of the debian-amd64 mailing list would contain the history of these decisions. Bob -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Transitioning to 64bit, is it worth it, and how
On Sun, Aug 05, 2007 at 12:28:14AM -0600, Bob Proulx wrote: But even so there was huge resistance because it was not a perfect solution and did not support 32-bit applications out of the box. I run Etch amd64 on may Athlon64 3800+ and its great. Then again, this box was an upgrade from my 486 :) The only thing I need ia32 for is iceweasel/flash. For this, I had to setup a chroot which wasn't that bad and takes up 442 MB of disk space. The only thing that would have been convenient would have been an amd64 package that brought in debootstrap and schroot and whatever else and did all the setup ready for installing the chroot. There was a lot of reading of howtos and man pages to bring myself up-to-speed on setting it up. Now I see in Sid there's a wrapper for mozilla plugins to make using a chroot for this unneccessary, however there could still be value in a 'ia32-schroot' meta-package. Doug. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Transitioning to 64bit, is it worth it, and how
I have a Core2 Duo on which I am running a 686 kernel (from Debian unstable). It has 1GB of memory I am wondering two things a) What are the pros and cons in switching to 64 bit mode? - Is it faster? - Are the packages less stable? - Does it need significantly more memory? - Can I use 32 bit apps from the repository if I have problems with an identically named one in the 64 bit repository (with pinning maybe) b) Is there a simple transition path? - Is there any howto? - My current unstable repository seems to have a 64 bit kernel - do I just install that and then change where my sources.list points -- Alan Chandler http://www.chandlerfamily.org.uk -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Transitioning to 64bit, is it worth it, and how
Alan Chandler wrote: I have a Core2 Duo on which I am running a 686 kernel (from Debian unstable). It has 1GB of memory I am wondering two things a) What are the pros and cons in switching to 64 bit mode? - Is it faster? - Are the packages less stable? - Does it need significantly more memory? - Can I use 32 bit apps from the repository if I have problems with an identically named one in the 64 bit repository (with pinning maybe) Yes, it is faster. Packages are not less stable, but some are unavailable. It does need significantly more memory, but your system should work fine, unless you use some very hungry apps like Eclipse. You can install some 32-bit apps using dpkg with --force-architecture option. If you need Acroread, first install ia32-libs-gtk from Ubuntu. b) Is there a simple transition path? - Is there any howto? - My current unstable repository seems to have a 64 bit kernel - do I just install that and then change where my sources.list points I think you have to install from scratch. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Transitioning to 64bit, is it worth it, and how
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 08/04/07 03:25, Alan Chandler wrote: I have a Core2 Duo on which I am running a 686 kernel (from Debian unstable). It has 1GB of memory I am wondering two things a) What are the pros and cons in switching to 64 bit mode? - Is it faster? Yes. There are more CPU registers, which means that programs need do less fetching and storing of temp variables to and from memory. Applications (like modern Python interpreters) which use lots of long long 64 bit integers will also be significantly faster. - Are the packages less stable? Why should they be? - Does it need significantly more memory? Not that you'd notice, unless you are already memory constrained. However, having 2 banks of 512MB will give it better RAM bandwidth. - Can I use 32 bit apps from the repository if I have problems with an identically named one in the 64 bit repository (with pinning maybe) Yes, within chroots. b) Is there a simple transition path? Reinstall from scratch, and pray that your /home is on a seperate partition. - Is there any howto? - My current unstable repository seems to have a 64 bit kernel - do I just install that and then change where my sources.list points - -- Ron Johnson, Jr. Jefferson LA USA Give a man a fish, and he eats for a day. Hit him with a fish, and he goes away for good! -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFGtEhjS9HxQb37XmcRApO4AJ9hytQIdFiWFNQ5PUSRyzV67ebpQQCg07Is Z9swOfa+than2CjyQoimHJY= =aHfx -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Transitioning to 64bit, is it worth it, and how
* a) What are the pros and cons in switching to 64 bit mode? * - Is it faster? I don't know - never ran my Opteron in 32-bit mode. I was wishing 64-bit floating point operations would be faster but they're not because AMD didn't really improve the math unit. In principle it should be faster if only because you're running in Native mode rather than Compatibility mode. * - Are the packages less stable? No. It is possible that some 'unclean' code which is being transitioned to 64-bit will cause problems but I am not familiar with any. OpenOffice was unclean at one stage but the fix-up was completed at least a year ago. (Having said that, I had fixed up 64-bit issues in 2 open source libraries.) * - Does it need significantly more memory? No, memory use doesn't change that much except for addresses now being 64-bit (well, something like 48 really) rather than 32-bit. 32-bit addresses limited you to 4GB of virtual memory. With 64-bit addressing you probably cannot afford to buy enough memory to make use of all 48 address bits. * - Can I use 32 bit apps from the repository if I have problems with an identically named one in the 64 bit repository (with pinning maybe) Yes, but it's tricky. The kernel needs to support the 32-bit system call format (I think the Debian kernels enable this by default) and you need a 32-bit dynamic loader and 32-bit libraries. Your 32-bit program can only make system calls and link to 32-bit libraries. * b) Is there a simple transition path? Yes, install from scratch. * - Is there any howto? Numerous howtos on the Debian AMD64 website.Have a look at the links near the bottom of this: http://www.debian.org/ports/amd64/ * - My current unstable repository seems to have a 64 bit kernel - do I just install that and then change where my sources.list points No. Install from scratch. Install 32-bit libraries as needed. Some software (notably numerous proprietary stuff - people have already mentioned Acrobat Reader) are available as 32-bit only. Other proprietary binaries that come to mind are Flash Player and Skype. I've nagged Skype for a few months but they really don't care. I don't use any of these 32-bit only software because I refuse to waste disk space installing 32-bit libs. If you use Wine or CrossoverOffice or Cedega you will have pretty much a complete 32-bit installation in parallel with your 64-bit. If you really use a lot of 32-bit stuff, stick to 32-bit until things improve (that may be a few more years). The exception to that of course is if you're one of those people who really wants to squeeze something out of every CPU cycle. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Transitioning to 64bit, is it worth it, and how
On Saturday 04 Aug 2007, Ron Johnson wrote: On 08/04/07 03:25, Alan Chandler wrote: b) Is there a simple transition path? Reinstall from scratch, and pray that your /home is on a seperate partition. Well the only home that matters - ie mine is - this is essentially just a personal machine. I am using raid1 with LVM on top, so I can easily create additional partitions and move things about as I wish. My only slight reservation is I am not sure if the installer supports raid, so it might be more complex than just installing. I also want to take the opportunity to enlarge my /boot partition (also raid 1) as 32M is just not enough these days - frequently seem to fill it up as I upgrade kernels. -- Alan Chandler http://www.chandlerfamily.org.uk -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Transitioning to 64bit, is it worth it, and how
On Sat, Aug 04, 2007 at 12:19:09PM +0100, Alan Chandler wrote: On Saturday 04 Aug 2007, Ron Johnson wrote: On 08/04/07 03:25, Alan Chandler wrote: b) Is there a simple transition path? Reinstall from scratch, and pray that your /home is on a seperate partition. Well the only home that matters - ie mine is - this is essentially just a personal machine. I am using raid1 with LVM on top, so I can easily create additional partitions and move things about as I wish. My only slight reservation is I am not sure if the installer supports raid, so it might be more complex than just installing. I also want to take the opportunity to enlarge my /boot partition (also raid 1) as 32M is just not enough these days - frequently seem to fill it up as I upgrade kernels. I don't think that you can keep your 32-bit raid/LVM setup, but I don't know. Your safest option is to backup your /home (you do this anyway, right), and do a clean reinstall. Doug. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Transitioning to 64bit, is it worth it, and how
Marko Randjelovic wrote: option. If you need Acroread, first install ia32-libs-gtk from Ubuntu. Just for the record, I installed today ia32-libs-gtk from officials unstable repos in Debian... Regards, Jose Luis. -- ghostbar on Linux/Debian 'sid' x86_64-SMP - #382503 Weblog: http://ghostbar.ath.cx/ - http://linuxtachira.org http://debian.org.ve - irc.debian.org #debian-ve #debian-devel-es San Cristóbal, Venezuela. http://chaslug.org.ve Fingerprint = 3E7D 4267 AFD5 2407 2A37 20AC 38A0 AD5B CACA B118 signature.asc Description: OpenPGP digital signature
Re: Transitioning to 64bit, is it worth it, and how
On 8/4/07, Alan Chandler [EMAIL PROTECTED] wrote: I have a Core2 Duo on which I am running a 686 kernel (from Debian unstable). It has 1GB of memory I am wondering two things a) What are the pros and cons in switching to 64 bit mode? - Is it faster? Yes. Unlike true 64-bit architectures like PowerPC, there is a penalty for executing 32 bit code on amd64/em64t processors. This is why the amd64 port of Debian has an all 64-bit user land, whereas other 64-bit ports of Linux and other operating systems generally have mostly a 32-bit user land and compile only applications that would benefit for 64-bit. -- Andrew Barr We matter more than pounds and pence, your economic theory makes no sense... -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Transitioning to 64bit, is it worth it, and how
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 08/04/07 12:53, Andrew J. Barr wrote: On 8/4/07, Alan Chandler [EMAIL PROTECTED] wrote: I have a Core2 Duo on which I am running a 686 kernel (from Debian unstable). It has 1GB of memory I am wondering two things a) What are the pros and cons in switching to 64 bit mode? - Is it faster? Yes. Unlike true 64-bit architectures like PowerPC, there is a penalty for executing 32 bit code on amd64/em64t processors. Penalty? Absolutely fscking not The A64 processes 32 bit code at a similar speed to regular Athlon CPUs. This is why the amd64 port of Debian has an all 64-bit user land, whereas other 64-bit ports of Linux and other operating systems generally have mostly a 32-bit user land and compile only applications that would benefit for 64-bit. - -- Ron Johnson, Jr. Jefferson LA USA Give a man a fish, and he eats for a day. Hit him with a fish, and he goes away for good! -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFGtMl5S9HxQb37XmcRAjzoAJ4x8X59ymK8SjExPbBZzPwgDQMYygCgx4Za Nk/L+s4d7bUzlP5kwq2DrdQ= =omH0 -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Transitioning to 64bit, is it worth it, and how
On 8/4/07, Ron Johnson [EMAIL PROTECTED] wrote: On 08/04/07 12:53, Andrew J. Barr wrote: a) What are the pros and cons in switching to 64 bit mode? - Is it faster? Yes. Unlike true 64-bit architectures like PowerPC, there is a penalty for executing 32 bit code on amd64/em64t processors. Penalty? Absolutely fscking not The A64 processes 32 bit code at a similar speed to regular Athlon CPUs. Do you have any sources for this? I remember quite distinctly seeing on a mailing list, I think it was debian-powerpc in fact, that the only reason that AMD64 operating systems have an all-64-bit user land is because there is a penalty for executing 32-bit code, one which is not present on other true 64-bit architectures. 64-bit code /does/ use more memory, so it is advantageous to have a mixed userland if you can afford it--e.g. only compiling applications that will benefit from 64-bit into 64-bit executables. This is what the OSes for other 64-bit architectures do. Perhaps the penalty is only under a 64-bit kernel... -- Andrew Barr We matter more than pounds and pence, your economic theory makes no sense... -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Transitioning to 64bit, is it worth it, and how
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 08/04/07 14:31, Andrew J. Barr wrote: On 8/4/07, Ron Johnson [EMAIL PROTECTED] wrote: On 08/04/07 12:53, Andrew J. Barr wrote: a) What are the pros and cons in switching to 64 bit mode? - Is it faster? Yes. Unlike true 64-bit architectures like PowerPC, there is a penalty for executing 32 bit code on amd64/em64t processors. Penalty? Absolutely fscking not The A64 processes 32 bit code at a similar speed to regular Athlon CPUs. Do you have any sources for this? I remember quite distinctly seeing on a mailing list, I think it was debian-powerpc in fact, that the only reason that AMD64 operating systems have an all-64-bit user land is because there is a penalty for executing 32-bit code, one which is not present on other true 64-bit architectures. 64-bit code /does/ use more memory, so it is advantageous to have a mixed userland if you can afford it--e.g. only compiling applications that will benefit from 64-bit into 64-bit executables. This is what the OSes for other 64-bit architectures do. Perhaps the penalty is only under a 64-bit kernel... I think we might have different definitions of penalty. What I mean is that an AMD64 in 32-bit mode will run apps at the same speed as an equivalently-clocked AthlonXP. - -- Ron Johnson, Jr. Jefferson LA USA Give a man a fish, and he eats for a day. Hit him with a fish, and he goes away for good! -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFGtOHMS9HxQb37XmcRAqLbAJ9ur/EB+r+tgzww7WKBgqEKlz9CAgCfbtzS 64Neda8mpS38KGhTgZn8Rk4= =xQoK -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]