Prev: Logs and dumps for kernel panics to collect and analyze?
Next: resize a lvm volume on a raid1
From: Artist on 9 Mar 2010 12:23
Nico Kadel-Garcia wrote:
> On Mar 7, 12:09 pm, Artist <Art...(a)sj.speakeasy.net> wrote:
>> Darren Salt wrote:
>>> I demand that Artist may or may not have written...
>>>> Darren Salt wrote:
>>>>> I demand that Artist may or may not have written...
>>> [snip]
>>>>>> I was mistaken about x86_64. The uname -m command gives i686.
>>>>> Kernel. Not particularly relevant, except that that tells me that it only
>>>>> supports native 32-bit userland.
>>>>> /proc/cpuinfo is more interesting; particularly the first model name line
>>>>> and flags line.
>>> [snip]
>>>> model name : Intel(R) Xeon(R) CPU E5405 @ 2.00GHz
>>> [snip]
>>>> flags : fpu de tsc msr pae cx8 sep cmov pat clflush mmx fxsr sse
>>>> sse2 ss ht nx constant_tsc pni ssse3 sse4_1
>>> [snip]
>>> 32-bit. However, according to Intel, that CPU is EM64T; so Debian's -amd64
>>> kernels should be fine, as should an amd64 install.
>>>> I have executed the command:
>>>> apt-get remove --purge libevent
>>>> From the documentation I understand this was supposed to remove all
>>>> files for libevent. But the command:
>>> All files listed as being installed from the .deb.
>>>> locate libevent
>>>> finds many files for libevent in the directories:
>>>> /usr/local/src/libevent-1.4.13-stable/
>>>> /usr/local/lib/
>>>> Were these supposed to be removed be apt-get? Or should I remove these
>>>> manually?
>>> They weren't installed from a .deb, so you'll have to remove them manually.
>> Is it safe to simply delete every file found using the locate command?
>> Or is there anything like a Windows XP registry that would cause trouble
>> if I did it that way?
>>
>> --
>> If you desire to respond directly remove the "sj." from the domain name
>> part of my email address. It is a spam jammer.
>
> For cripes sake, no. A lot of components in different pieces of
> software provide both i386 and x86_64 libraries and include files, to
> allow compilation of i386 software and the use of i386 based binaries.
> Picking and choosing bits among them is much better done with a
> package management system that has some built-in knowledge of
> dependencies, rather than just doing a "find / -name \*i386\* -exec rm
> -rf {} \;" sort of operation on it.

What then is the procedure for removing libevent manually so I can
reinstall it using apt or aptitude?

--
If you desire to respond directly remove the "sj." from the domain name
part of my email address. It is a spam jammer.
From: Artist on 9 Mar 2010 14:45
The Natural Philosopher wrote:
> Artist wrote:
>> The Natural Philosopher wrote:
>>> Artist wrote:
>>>> The Natural Philosopher wrote:
>>>>> Artist wrote:
>>>>>> Darren Salt wrote:
>>>>>>> I demand that Artist may or may not have written...
>>>>>>>
>>>>>>>> On my x86_64 server with a newly installed Debian 5 I did this
>>>>>>>> sequence of installation commands:
>>>>>>>
>>>>>>>> apt-get install gcc
>>>>>>> [snip; local install of libevent-1.4.13-stable]
>>>>>>>
>>>>>>> That's in backports. You should get it from there instead of
>>>>>>> building it
>>>>>>> yourself; see
>>>>>>> http://packages.debian.org/source/lenny-backports/libevent (and
>>>>>>> follow the "backports" link) for details.
>>>>>>>
>>>>>>> (And were it not in backports, you should install
>>>>>>> build-essential, use dget
>>>>>>> to fetch the .dsc of the version in testing (it'll fetch the rest
>>>>>>> of the
>>>>>>> source automatically), "dpkg-source -x" the .dsc to unpack the
>>>>>>> source, then
>>>>>>> "debuild binary" to build it. Then dpkg (as root) to install it.
>>>>>>> Best to stay
>>>>>>> within the package management system wherever you reasonably can.)
>>>>>>>
>>>>>>>> I thought I would automatically get an installation that took full
>>>>>>>> advantage of the 64 bit architecture.
>>>>>>>
>>>>>>> That's not determined by adding packages.
>>>>>>>
>>>>>>>> But looking in the directory /var/cache/apt/archives I see most
>>>>>>>> of the
>>>>>>>> files end in i386.deb. So now I am not sure. Is this what I
>>>>>>>> should see if
>>>>>>>> the full benefit if the x86_64 architecture is to be had?
>>>>>>>
>>>>>>> Not really. You can cross-compile for amd64 and even run the
>>>>>>> resulting
>>>>>>> binaries, but your installation is i386. (However, you can at
>>>>>>> least run an
>>>>>>> amd64 kernel.)
>>>>>>>
>>>>>>> You might want to throw that away and do a full re-install,
>>>>>>> targetting amd64.
>>>>>>>
>>>>>>> It's possible, but somewhat involved, to "migrate" it to amd64.
>>>>>>> This requires
>>>>>>> use of dpkg --get-selections, preserving /etc, /var/cache/debconf
>>>>>>> and
>>>>>>> probably a few other bits and pieces, doing a base install,
>>>>>>> chrooting into
>>>>>>> it, using dpkg --set-selections, restoring all of what you
>>>>>>> preserved except
>>>>>>> /etc, installing the packages according to the selections
>>>>>>> (aptitude in UI
>>>>>>> mode is ideal), then (selectively?) restoring /etc. You do need
>>>>>>> to know your
>>>>>>> way around a Debian system to some extent to be able to get away
>>>>>>> with this
>>>>>>> kind of installation hack, though, and I've probably omitted
>>>>>>> something
>>>>>>> extremely important. Let's just say that it may, potentially,
>>>>>>> become Very
>>>>>>> Interesting.
>>>>>>>
>>>>>>> (That said, a full install followed by copying what you've
>>>>>>> customised most
>>>>>>> into the new /etc will probably do. It's up to you...)
>>>>>>>
>>>>>>
>>>>>> Thankyou for your reply. This is a big help. I will remove and
>>>>>> reinstall libevent using the link that you have given.
>>>>>>
>>>>>> Does a similar thing need to be done for my installations of gcc,
>>>>>> gawk, make, and locate?
>>>>>>
>>>>>> I was mistaken about x86_64. The uname -m command gives i686. But
>>>>>> the gcc -v command shows the default architecture is i486:
>>>>>>
>>>>>> debian:/usr/share# uname -v
>>>>>> #1 SMP Wed Feb 10 09:24:17 UTC 2010
>>>>>> debian:/usr/share# gcc -v
>>>>>> Using built-in specs.
>>>>>> Target: i486-linux-gnu
>>>>>> Configured with: ../src/configure -v --with-pkgversion='Debian
>>>>>> 4.3.2-1.1' --with
>>>>>> -bugurl=file:///usr/share/doc/gcc-4.3/README.Bugs
>>>>>> --enable-languages=c,c++,fortr
>>>>>> an,objc,obj-c++ --prefix=/usr --enable-shared --with-system-zlib
>>>>>> --libexecdir=/u
>>>>>> sr/lib --without-included-gettext --enable-threads=posix
>>>>>> --enable-nls --with-gxx
>>>>>> -include-dir=/usr/include/c++/4.3 --program-suffix=-4.3
>>>>>> --enable-clocale=gnu --e
>>>>>> nable-libstdcxx-debug --enable-objc-gc --enable-mpfr
>>>>>> --enable-targets=all --enab
>>>>>> le-cld --enable-checking=release --build=i486-linux-gnu
>>>>>> --host=i486-linux-gnu --
>>>>>> target=i486-linux-gnu
>>>>>> Thread model: posix
>>>>>> gcc version 4.3.2 (Debian 4.3.2-1.1)
>>>>>>
>>>>>> Should the target have been i686-linux-gnu if I had the right
>>>>>> configuration for it or the right gcc installed?
>>>>>>
>>>>> reinstall with AM64 architecture.
>>>>>
>>>>>
>>>>>
>>>> Reinstall only gcc and other packages or the entire Debian OS?
>>>>
>>> Whole shooting match mate.
>>>
>>> Otherwise you will be fixing dependencies forever..
>>>
>>
>> This Debian OS is running in a Virtual Private Server. I got this
>> message from the ISP's tech support:
>>
>> "Currently -- Debian 64-bit is not supported by Citrix XenServer so we
>> installed the 32-bit edition to make sure you get maximum stability."
>>
> Find another hosting center.

The problem is not at the data center or at Citrix. The problem is at
Debian:
http://forums.citrix.com/message.jspa?messageID=1406218
So if I want an am64 Debian installation I must regress to Debian 4
Etch. But security updates have been discontinued for Etch. I can
continue with Lenny i386 and wait for Lenny-plus-a-Half to come out.
am64 Lenny for XenServer may or may not be supported then. But if it is
supported there will be a lot of labor to make the change because all
the data on the server would have to be erased and restored.

Is this a pattern with Debian that XenServer is not supported until
"plus-a-Half" versions come out? I do not want to be in the position of
having converted to am64 Lenny-plus-a-Half only to find XenServer is not
supported in Debian 6 when it is released. Then while being dependent on
am64 Lenny and waiting for Debian 6-plus-a-Half to become available find
that security updates for Lenny have been discontinued.

If I want a 64 bit VPS service I think I am going to have to find
another OS. The 64 bit choices are CentOS, Windows 2008 x64, SUSE 11 x64.

I resist the Windows 2008 x64 option. "We are Microsoft. Resistance is
futile. You will be assimilated."

I tried CentOS before but lost confidence in it when I got conflicting
advice on the use of yum priorities. Using it can break the OS. Not
using it can break the OS. It appears there are applications out there
that want to install tampered versions of base files. CPanel is one of
them. It installs a tampered versions of base files and one of them is
courier-imap. This blocked the installation of ispCP:
http://www.isp-control.net/forum/thread-9707-post-74868.html#pid74868.
With ispCP I do not need CPanel. But the concern was about applications
other than CPanel doing the same causing me to have to decide between
applications that can be installed. Would I have similar trouble under Suse?

For a web server what performance difference can a 64 bit system have
over a 32 bit system?

--
If you desire to respond directly remove the "sj." from the domain name
part of my email address. It is a spam jammer.
From: The Natural Philosopher on 9 Mar 2010 15:46
Artist wrote:
> The Natural Philosopher wrote:
>> Artist wrote:
>>> The Natural Philosopher wrote:
>>>> Artist wrote:
>>>>> The Natural Philosopher wrote:
>>>>>> Artist wrote:
>>>>>>> Darren Salt wrote:
>>>>>>>> I demand that Artist may or may not have written...
>>>>>>>>
>>>>>>>>> On my x86_64 server with a newly installed Debian 5 I did this
>>>>>>>>> sequence of installation commands:
>>>>>>>>
>>>>>>>>> apt-get install gcc
>>>>>>>> [snip; local install of libevent-1.4.13-stable]
>>>>>>>>
>>>>>>>> That's in backports. You should get it from there instead of
>>>>>>>> building it
>>>>>>>> yourself; see
>>>>>>>> http://packages.debian.org/source/lenny-backports/libevent (and
>>>>>>>> follow the "backports" link) for details.
>>>>>>>>
>>>>>>>> (And were it not in backports, you should install
>>>>>>>> build-essential, use dget
>>>>>>>> to fetch the .dsc of the version in testing (it'll fetch the
>>>>>>>> rest of the
>>>>>>>> source automatically), "dpkg-source -x" the .dsc to unpack the
>>>>>>>> source, then
>>>>>>>> "debuild binary" to build it. Then dpkg (as root) to install it.
>>>>>>>> Best to stay
>>>>>>>> within the package management system wherever you reasonably can.)
>>>>>>>>
>>>>>>>>> I thought I would automatically get an installation that took full
>>>>>>>>> advantage of the 64 bit architecture.
>>>>>>>>
>>>>>>>> That's not determined by adding packages.
>>>>>>>>
>>>>>>>>> But looking in the directory /var/cache/apt/archives I see most
>>>>>>>>> of the
>>>>>>>>> files end in i386.deb. So now I am not sure. Is this what I
>>>>>>>>> should see if
>>>>>>>>> the full benefit if the x86_64 architecture is to be had?
>>>>>>>>
>>>>>>>> Not really. You can cross-compile for amd64 and even run the
>>>>>>>> resulting
>>>>>>>> binaries, but your installation is i386. (However, you can at
>>>>>>>> least run an
>>>>>>>> amd64 kernel.)
>>>>>>>>
>>>>>>>> You might want to throw that away and do a full re-install,
>>>>>>>> targetting amd64.
>>>>>>>>
>>>>>>>> It's possible, but somewhat involved, to "migrate" it to amd64.
>>>>>>>> This requires
>>>>>>>> use of dpkg --get-selections, preserving /etc,
>>>>>>>> /var/cache/debconf and
>>>>>>>> probably a few other bits and pieces, doing a base install,
>>>>>>>> chrooting into
>>>>>>>> it, using dpkg --set-selections, restoring all of what you
>>>>>>>> preserved except
>>>>>>>> /etc, installing the packages according to the selections
>>>>>>>> (aptitude in UI
>>>>>>>> mode is ideal), then (selectively?) restoring /etc. You do need
>>>>>>>> to know your
>>>>>>>> way around a Debian system to some extent to be able to get away
>>>>>>>> with this
>>>>>>>> kind of installation hack, though, and I've probably omitted
>>>>>>>> something
>>>>>>>> extremely important. Let's just say that it may, potentially,
>>>>>>>> become Very
>>>>>>>> Interesting.
>>>>>>>>
>>>>>>>> (That said, a full install followed by copying what you've
>>>>>>>> customised most
>>>>>>>> into the new /etc will probably do. It's up to you...)
>>>>>>>>
>>>>>>>
>>>>>>> Thankyou for your reply. This is a big help. I will remove and
>>>>>>> reinstall libevent using the link that you have given.
>>>>>>>
>>>>>>> Does a similar thing need to be done for my installations of gcc,
>>>>>>> gawk, make, and locate?
>>>>>>>
>>>>>>> I was mistaken about x86_64. The uname -m command gives i686. But
>>>>>>> the gcc -v command shows the default architecture is i486:
>>>>>>>
>>>>>>> debian:/usr/share# uname -v
>>>>>>> #1 SMP Wed Feb 10 09:24:17 UTC 2010
>>>>>>> debian:/usr/share# gcc -v
>>>>>>> Using built-in specs.
>>>>>>> Target: i486-linux-gnu
>>>>>>> Configured with: ../src/configure -v --with-pkgversion='Debian
>>>>>>> 4.3.2-1.1' --with
>>>>>>> -bugurl=file:///usr/share/doc/gcc-4.3/README.Bugs
>>>>>>> --enable-languages=c,c++,fortr
>>>>>>> an,objc,obj-c++ --prefix=/usr --enable-shared --with-system-zlib
>>>>>>> --libexecdir=/u
>>>>>>> sr/lib --without-included-gettext --enable-threads=posix
>>>>>>> --enable-nls --with-gxx
>>>>>>> -include-dir=/usr/include/c++/4.3 --program-suffix=-4.3
>>>>>>> --enable-clocale=gnu --e
>>>>>>> nable-libstdcxx-debug --enable-objc-gc --enable-mpfr
>>>>>>> --enable-targets=all --enab
>>>>>>> le-cld --enable-checking=release --build=i486-linux-gnu
>>>>>>> --host=i486-linux-gnu --
>>>>>>> target=i486-linux-gnu
>>>>>>> Thread model: posix
>>>>>>> gcc version 4.3.2 (Debian 4.3.2-1.1)
>>>>>>>
>>>>>>> Should the target have been i686-linux-gnu if I had the right
>>>>>>> configuration for it or the right gcc installed?
>>>>>>>
>>>>>> reinstall with AM64 architecture.
>>>>>>
>>>>>>
>>>>>>
>>>>> Reinstall only gcc and other packages or the entire Debian OS?
>>>>>
>>>> Whole shooting match mate.
>>>>
>>>> Otherwise you will be fixing dependencies forever..
>>>>
>>>
>>> This Debian OS is running in a Virtual Private Server. I got this
>>> message from the ISP's tech support:
>>>
>>> "Currently -- Debian 64-bit is not supported by Citrix XenServer so
>>> we installed the 32-bit edition to make sure you get maximum stability."
>>>
>> Find another hosting center.
>
> The problem is not at the data center or at Citrix. The problem is at
> Debian:
> http://forums.citrix.com/message.jspa?messageID=1406218

Er. that says to me that the problem is a Citrix.

If debian loads fine on raw hardware, but not on citrix, how is that
debian's problem?



> So if I want an am64 Debian installation I must regress to Debian 4
> Etch. But security updates have been discontinued for Etch. I can
> continue with Lenny i386 and wait for Lenny-plus-a-Half to come out.
> am64 Lenny for XenServer may or may not be supported then. But if it is
> supported there will be a lot of labor to make the change because all
> the data on the server would have to be erased and restored.
>

Tell Cutrix to fix their sodding code.

Or use another VNM.

> Is this a pattern with Debian that XenServer is not supported until
> "plus-a-Half" versions come out? I do not want to be in the position of
> having converted to am64 Lenny-plus-a-Half only to find XenServer is not
> supported in Debian 6 when it is released. Then while being dependent on
> am64 Lenny and waiting for Debian 6-plus-a-Half to become available find
> that security updates for Lenny have been discontinued.
>
> If I want a 64 bit VPS service I think I am going to have to find
> another OS. The 64 bit choices are CentOS, Windows 2008 x64, SUSE 11 x64.
>

No, find another VM.

> I resist the Windows 2008 x64 option. "We are Microsoft. Resistance is
> futile. You will be assimilated."
>
> I tried CentOS before but lost confidence in it when I got conflicting
> advice on the use of yum priorities. Using it can break the OS. Not
> using it can break the OS. It appears there are applications out there
> that want to install tampered versions of base files. CPanel is one of
> them. It installs a tampered versions of base files and one of them is
> courier-imap. This blocked the installation of ispCP:
> http://www.isp-control.net/forum/thread-9707-post-74868.html#pid74868.
> With ispCP I do not need CPanel. But the concern was about applications
> other than CPanel doing the same causing me to have to decide between
> applications that can be installed. Would I have similar trouble under
> Suse?
>
> For a web server what performance difference can a 64 bit system have
> over a 32 bit system?

Depends what you are doing.

On my web apps, CPU crunch is actually quite important, because I am
making various sized thumbnails 'on the fly' rather than off line and
stored..

I would say that the areas where I have seen real speed improvements
have all been heavily maths/graphics intensive.

If your apps are not 32 bit wont be a deal slower at all.

>
From: Artist on 9 Mar 2010 21:36
The Natural Philosopher wrote:
> Artist wrote:
>> The Natural Philosopher wrote:
>>> Artist wrote:
>>>> The Natural Philosopher wrote:
>>>>> Artist wrote:
>>>>>> The Natural Philosopher wrote:
>>>>>>> Artist wrote:
>>>>>>>> Darren Salt wrote:
>>>>>>>>> I demand that Artist may or may not have written...
>>>>>>>>>
>>>>>>>>>> On my x86_64 server with a newly installed Debian 5 I did this
>>>>>>>>>> sequence of installation commands:
>>>>>>>>>
>>>>>>>>>> apt-get install gcc
>>>>>>>>> [snip; local install of libevent-1.4.13-stable]
>>>>>>>>>
>>>>>>>>> That's in backports. You should get it from there instead of
>>>>>>>>> building it
>>>>>>>>> yourself; see
>>>>>>>>> http://packages.debian.org/source/lenny-backports/libevent (and
>>>>>>>>> follow the "backports" link) for details.
>>>>>>>>>
>>>>>>>>> (And were it not in backports, you should install
>>>>>>>>> build-essential, use dget
>>>>>>>>> to fetch the .dsc of the version in testing (it'll fetch the
>>>>>>>>> rest of the
>>>>>>>>> source automatically), "dpkg-source -x" the .dsc to unpack the
>>>>>>>>> source, then
>>>>>>>>> "debuild binary" to build it. Then dpkg (as root) to install
>>>>>>>>> it. Best to stay
>>>>>>>>> within the package management system wherever you reasonably can.)
>>>>>>>>>
>>>>>>>>>> I thought I would automatically get an installation that took
>>>>>>>>>> full
>>>>>>>>>> advantage of the 64 bit architecture.
>>>>>>>>>
>>>>>>>>> That's not determined by adding packages.
>>>>>>>>>
>>>>>>>>>> But looking in the directory /var/cache/apt/archives I see
>>>>>>>>>> most of the
>>>>>>>>>> files end in i386.deb. So now I am not sure. Is this what I
>>>>>>>>>> should see if
>>>>>>>>>> the full benefit if the x86_64 architecture is to be had?
>>>>>>>>>
>>>>>>>>> Not really. You can cross-compile for amd64 and even run the
>>>>>>>>> resulting
>>>>>>>>> binaries, but your installation is i386. (However, you can at
>>>>>>>>> least run an
>>>>>>>>> amd64 kernel.)
>>>>>>>>>
>>>>>>>>> You might want to throw that away and do a full re-install,
>>>>>>>>> targetting amd64.
>>>>>>>>>
>>>>>>>>> It's possible, but somewhat involved, to "migrate" it to amd64.
>>>>>>>>> This requires
>>>>>>>>> use of dpkg --get-selections, preserving /etc,
>>>>>>>>> /var/cache/debconf and
>>>>>>>>> probably a few other bits and pieces, doing a base install,
>>>>>>>>> chrooting into
>>>>>>>>> it, using dpkg --set-selections, restoring all of what you
>>>>>>>>> preserved except
>>>>>>>>> /etc, installing the packages according to the selections
>>>>>>>>> (aptitude in UI
>>>>>>>>> mode is ideal), then (selectively?) restoring /etc. You do need
>>>>>>>>> to know your
>>>>>>>>> way around a Debian system to some extent to be able to get
>>>>>>>>> away with this
>>>>>>>>> kind of installation hack, though, and I've probably omitted
>>>>>>>>> something
>>>>>>>>> extremely important. Let's just say that it may, potentially,
>>>>>>>>> become Very
>>>>>>>>> Interesting.
>>>>>>>>>
>>>>>>>>> (That said, a full install followed by copying what you've
>>>>>>>>> customised most
>>>>>>>>> into the new /etc will probably do. It's up to you...)
>>>>>>>>>
>>>>>>>>
>>>>>>>> Thankyou for your reply. This is a big help. I will remove and
>>>>>>>> reinstall libevent using the link that you have given.
>>>>>>>>
>>>>>>>> Does a similar thing need to be done for my installations of
>>>>>>>> gcc, gawk, make, and locate?
>>>>>>>>
>>>>>>>> I was mistaken about x86_64. The uname -m command gives i686.
>>>>>>>> But the gcc -v command shows the default architecture is i486:
>>>>>>>>
>>>>>>>> debian:/usr/share# uname -v
>>>>>>>> #1 SMP Wed Feb 10 09:24:17 UTC 2010
>>>>>>>> debian:/usr/share# gcc -v
>>>>>>>> Using built-in specs.
>>>>>>>> Target: i486-linux-gnu
>>>>>>>> Configured with: ../src/configure -v --with-pkgversion='Debian
>>>>>>>> 4.3.2-1.1' --with
>>>>>>>> -bugurl=file:///usr/share/doc/gcc-4.3/README.Bugs
>>>>>>>> --enable-languages=c,c++,fortr
>>>>>>>> an,objc,obj-c++ --prefix=/usr --enable-shared --with-system-zlib
>>>>>>>> --libexecdir=/u
>>>>>>>> sr/lib --without-included-gettext --enable-threads=posix
>>>>>>>> --enable-nls --with-gxx
>>>>>>>> -include-dir=/usr/include/c++/4.3 --program-suffix=-4.3
>>>>>>>> --enable-clocale=gnu --e
>>>>>>>> nable-libstdcxx-debug --enable-objc-gc --enable-mpfr
>>>>>>>> --enable-targets=all --enab
>>>>>>>> le-cld --enable-checking=release --build=i486-linux-gnu
>>>>>>>> --host=i486-linux-gnu --
>>>>>>>> target=i486-linux-gnu
>>>>>>>> Thread model: posix
>>>>>>>> gcc version 4.3.2 (Debian 4.3.2-1.1)
>>>>>>>>
>>>>>>>> Should the target have been i686-linux-gnu if I had the right
>>>>>>>> configuration for it or the right gcc installed?
>>>>>>>>
>>>>>>> reinstall with AM64 architecture.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>> Reinstall only gcc and other packages or the entire Debian OS?
>>>>>>
>>>>> Whole shooting match mate.
>>>>>
>>>>> Otherwise you will be fixing dependencies forever..
>>>>>
>>>>
>>>> This Debian OS is running in a Virtual Private Server. I got this
>>>> message from the ISP's tech support:
>>>>
>>>> "Currently -- Debian 64-bit is not supported by Citrix XenServer so
>>>> we installed the 32-bit edition to make sure you get maximum
>>>> stability."
>>>>
>>> Find another hosting center.
>>
>> The problem is not at the data center or at Citrix. The problem is at
>> Debian:
>> http://forums.citrix.com/message.jspa?messageID=1406218
>
> Er. that says to me that the problem is a Citrix.
>
> If debian loads fine on raw hardware, but not on citrix, how is that
> debian's problem?
>
>
>
>> So if I want an am64 Debian installation I must regress to Debian 4
>> Etch. But security updates have been discontinued for Etch. I can
>> continue with Lenny i386 and wait for Lenny-plus-a-Half to come out.
>> am64 Lenny for XenServer may or may not be supported then. But if it
>> is supported there will be a lot of labor to make the change because
>> all the data on the server would have to be erased and restored.
>>
>
> Tell Cutrix to fix their sodding code.
>
> Or use another VNM.
>
>> Is this a pattern with Debian that XenServer is not supported until
>> "plus-a-Half" versions come out? I do not want to be in the position
>> of having converted to am64 Lenny-plus-a-Half only to find XenServer
>> is not supported in Debian 6 when it is released. Then while being
>> dependent on am64 Lenny and waiting for Debian 6-plus-a-Half to become
>> available find that security updates for Lenny have been discontinued.
>>
>> If I want a 64 bit VPS service I think I am going to have to find
>> another OS. The 64 bit choices are CentOS, Windows 2008 x64, SUSE 11 x64.
>>
>
> No, find another VM.
>
>> I resist the Windows 2008 x64 option. "We are Microsoft. Resistance is
>> futile. You will be assimilated."
>>
>> I tried CentOS before but lost confidence in it when I got conflicting
>> advice on the use of yum priorities. Using it can break the OS. Not
>> using it can break the OS. It appears there are applications out there
>> that want to install tampered versions of base files. CPanel is one of
>> them. It installs a tampered versions of base files and one of them is
>> courier-imap. This blocked the installation of ispCP:
>> http://www.isp-control.net/forum/thread-9707-post-74868.html#pid74868.
>> With ispCP I do not need CPanel. But the concern was about
>> applications other than CPanel doing the same causing me to have to
>> decide between applications that can be installed. Would I have
>> similar trouble under Suse?
>>
>> For a web server what performance difference can a 64 bit system have
>> over a 32 bit system?
>
> Depends what you are doing.
>
> On my web apps, CPU crunch is actually quite important, because I am
> making various sized thumbnails 'on the fly' rather than off line and
> stored..
>
> I would say that the areas where I have seen real speed improvements
> have all been heavily maths/graphics intensive.
>
> If your apps are not 32 bit wont be a deal slower at all.
>
>

It will be a Drupal site. This means the execution of a lot of PHP code
and many database queries.

--
To reply directly remove the sj. from my email address. This is a spam
jammer.
First  |  Prev  | 
Pages: 1 2 3 4
Prev: Logs and dumps for kernel panics to collect and analyze?
Next: resize a lvm volume on a raid1