Greetings:

   In the past, we have bought a bunch of these Netra X1 and Sun Fire V100
servers when we needed a small machine to run a dedicated application (like
web, calendar, LDAP, etc).  Now it seems that Sun doesn't sell SPARC-based
machines in that price range any more.  What are the consequences of using,
say, a Sun Fire X2100 as a replacement for a V100?  I mean in terms of
binary compatibility and so forth.  A lot of the software we install is
open-source, so will things like BIND, Apache, sendmail, etc compile under
an x64 as easily as they do with a V100?  If we run a purchased application
that advertises Solaris support, do we need to ask the vendor specifically
about an AMD processor?  Thanks for any advice...

Jim McCullars
University of Alabama in Huntsville

Jim McCullars wrote:
> Greetings:
> 
>    In the past, we have bought a bunch of these Netra X1 and Sun Fire V100
> servers when we needed a small machine to run a dedicated application (like
> web, calendar, LDAP, etc).  Now it seems that Sun doesn't sell SPARC-based
> machines in that price range any more.  What are the consequences of using,
> say, a Sun Fire X2100 as a replacement for a V100?  I mean in terms of
> binary compatibility and so forth.  A lot of the software we install is
> open-source, so will things like BIND, Apache, sendmail, etc compile under
> an x64 as easily as they do with a V100?  If we run a purchased application
> that advertises Solaris support, do we need to ask the vendor specifically
> about an AMD processor?  Thanks for any advice...
> 
> Jim McCullars
> University of Alabama in Huntsville

I can't think of any commonly used open source application that you may 
have used for SPARC that doesn't already have a x86 version available.

Compiling should be just as easy.  I'd suggest you download a copy of 
the Sun Studio 11 compiler on your new Sun Opteron system and have at 
it.  Granted, you should be running Solaris 10 for best results, 
therefore, just ask your proprietary vendor of choice about an x86 
version of their software support for Solaris 10 - essentially Solaris 
10 x86 support implies support for the AMD processors.

The only potential problem I can see about moving from SPARC to x86 for 
needs similar to your would be file migration from a big-endian to 
little-endian filesystem, but this assumes you are trying to directly 
mount filesystems -don't do that and you're fine.

	http://en.wikipedia.org/wiki/Endian

The ZFS filesystem, supposed to be available for Solaris 10u2 (due about 
June) is supposed to be endian neutral and will be a very welcome 
addition to Solaris 10.

	http://www.sun.com/2004-0914/feature/

> Jim McCullars wrote:
>> Greetings:
>>
>>    In the past, we have bought a bunch of these Netra X1 and Sun Fire 
>> V100
>> servers when we needed a small machine to run a dedicated application 
>> (like
>> web, calendar, LDAP, etc).  Now it seems that Sun doesn't sell 
>> SPARC-based
>> machines in that price range any more.  What are the consequences of 
>> using,
>> say, a Sun Fire X2100 as a replacement for a V100?  I mean in terms of
>> binary compatibility and so forth.  A lot of the software we install is
>> open-source, so will things like BIND, Apache, sendmail, etc compile 
>> under
>> an x64 as easily as they do with a V100?  If we run a purchased 
>> application
>> that advertises Solaris support, do we need to ask the vendor 
>> specifically
>> about an AMD processor?  Thanks for any advice...
>>
>> Jim McCullars
>> University of Alabama in Huntsville
> 

One more thing, if you weren't aware already, Sun makes a "Companion CD" 
of most of the software you are likely to need and can simply install 
those components you need and not have to compile anything unless you 
simply prefer to do so.

Additionally pre-compiled packages may be found at 
http://www.sunfreeware.com and http://www.blastwave.org

In article <e2lier$b8i$1@info2.uah.edu>,
Jim McCullars <jim@info2.uah.edu> wrote:
>an x64 as easily as they do with a V100?  If we run a purchased application
>that advertises Solaris support, do we need to ask the vendor specifically
>about an AMD processor?  Thanks for any advice...

What commercial application?

John
groenveld@acm.org

Wes Williams (wes@classiarius.com) wrote:

: One more thing, if you weren't aware already, Sun makes a "Companion CD" 
: of most of the software you are likely to need and can simply install 
: those components you need and not have to compile anything unless you 
: simply prefer to do so.

   OK, thanks for the feedback.  I usually do compile from source, but that
is mostly out of habit from the days before so many sites offered precompiled
binaries.  Also, perl modules occasionally need to compile something.  I used
to use gcc exclusively until Sun started bundling perl in with Solaris
and then modules started expecting Sun's cc to be installed (unless I 
install a separate perl built with gcc) so we now put cc on new servers in
case we have to build something.

   I guess I was just looking for some reassurance that Solaris x86 wasn't
just a "kludge" that was going to give me problems :-)

Jim McCullars

John D Groenveld (groenvel@cse.psu.edu) wrote:
: >an x64 as easily as they do with a V100?  If we run a purchased application
: >that advertises Solaris support, do we need to ask the vendor specifically
: >about an AMD processor?  Thanks for any advice...

: What commercial application?

   Just as an example, we run Banner from SungardSCT and the front-ends
are Sun servers.  We also run Payment Gateway and webCheck from Touchnet
Information Systems and are about to migrate those applications to small
Sun servers like a V100 and I was wondering about applications like that.
Of course, I guess the smart thing to do would be ask the vendor, right? :)

Jim McCullars

jim@info2.uah.edu (Jim McCullars) writes:

>   OK, thanks for the feedback.  I usually do compile from source, but that
>is mostly out of habit from the days before so many sites offered precompiled
>binaries.  Also, perl modules occasionally need to compile something.  I used
>to use gcc exclusively until Sun started bundling perl in with Solaris
>and then modules started expecting Sun's cc to be installed (unless I 
>install a separate perl built with gcc) so we now put cc on new servers in
>case we have to build something.

You can use gcc compiled modules with perl (somewhat hairy; "expecting
to be compiled with Sun's compiler" comes from the Solaris perl
configuration, no from the tools)

>   I guess I was just looking for some reassurance that Solaris x86 wasn't
>just a "kludge" that was going to give me problems :-)


Note that things like sendmail, bind and apache are bundled as a standard
part of the OS.

Casper
-- 
Expressed in this posting are my opinions.  They are in no way related
to opinions held by my employer, Sun Microsystems.
Statements on Sun products included here are not gospel and may
be fiction rather than truth.

Jim McCullars wrote:
>    I guess I was just looking for some reassurance that Solaris x86 wasn't
> just a "kludge" that was going to give me problems :-)
> 
> Jim McCullars
> 

The BIOS is about the only 'kludge' you'll see on those x86 systems...as 
is any x86 BIOS.  But on a good note, you only have to deal with that 
mess on the rare reboot.

In article <e2loho$cbf$1@info2.uah.edu>,
Jim McCullars <jim@info2.uah.edu> wrote:
>binaries.  Also, perl modules occasionally need to compile something.  I used
>to use gcc exclusively until Sun started bundling perl in with Solaris
>and then modules started expecting Sun's cc to be installed (unless I 
>install a separate perl built with gcc) so we now put cc on new servers in
>case we have to build something.

I wouldn't use Sun's Perl's for anything except Sun's applications.
For your own applications, its best to maintain your own Perl builds
with your favorite compilers, compiler options, and module versions.

John
groenveld@acm.org

In article <e2lp6m$cie$1@info2.uah.edu>,
Jim McCullars <jim@info2.uah.edu> wrote:
>   Just as an example, we run Banner from SungardSCT and the front-ends
>are Sun servers.  We also run Payment Gateway and webCheck from Touchnet
>Information Systems and are about to migrate those applications to small
>Sun servers like a V100 and I was wondering about applications like that.
>Of course, I guess the smart thing to do would be ask the vendor, right? :)

I think you should ask SunGard, but also ask Sun.
Before he was moved to the SunGrid initiative, Stuart Wells was hawking
SunGard's Solaris x86 solutions to Wall Street so Sun might have some
high level relationships which could be leveraged.
<URL:http://www.sun.com/smi/Press/sunflash/2005-06/sunflash.20050621.1.xml>

John
groenveld@acm.org

Jim McCullars wrote:

> Greetings:
> 
>    In the past, we have bought a bunch of these Netra X1 and Sun Fire V100
> servers when we needed a small machine to run a dedicated application (like
> web, calendar, LDAP, etc).  Now it seems that Sun doesn't sell SPARC-based
> machines in that price range any more.  What are the consequences of using,
> say, a Sun Fire X2100 as a replacement for a V100?  I mean in terms of
> binary compatibility and so forth.  A lot of the software we install is
> open-source, so will things like BIND, Apache, sendmail, etc compile under
> an x64 as easily as they do with a V100?  If we run a purchased application
> that advertises Solaris support, do we need to ask the vendor specifically
> about an AMD processor?  Thanks for any advice...
> 
> Jim McCullars
> University of Alabama in Huntsville

I'd take a wild ass guess and say most things will simply compile, link, 
and work.  The exceptions will be code with architectural dependencies 
such as endianess, page size, and probably a couple of things I've never 
thought of.  Most experienced programmers and especially those who have 
had to port code from one architecture or O/S to another are aware of 
the pitfalls and will avoid them like the plague!  "Hello world!" will 
work just about anywhere because it is not aware of the O/S or the 
hardware.  Code that is aware of the O/S; e.g. makes calls directly into 
the O/S or that is aware of behavior specific to an architecture is 
usually a nightmare!

In <e2lu0k$5mk$1@neuromancer.cse.psu.edu> groenvel@cse.psu.edu (John D Groenveld) writes:

>In article <e2loho$cbf$1@info2.uah.edu>,
>Jim McCullars <jim@info2.uah.edu> wrote:
>>binaries.  Also, perl modules occasionally need to compile something.  I used
>>to use gcc exclusively until Sun started bundling perl in with Solaris
>>and then modules started expecting Sun's cc to be installed (unless I 
>>install a separate perl built with gcc) so we now put cc on new servers in
>>case we have to build something.

>I wouldn't use Sun's Perl's for anything except Sun's applications.
>For your own applications, its best to maintain your own Perl builds
>with your favorite compilers, compiler options, and module versions.

That's one of several options.  Perl is a nightmare either way, when
you have perl scripts all over the place, written by many different
people, that may or may not depend on specific versions of perl. It
gets even worse when you have multiple versions of perl all over the
place.  I notice now that many software vendors include their own
version of perl with their product.  Sounds like `perl hell' to me.


-- 
-Gary Mills-    -Unix Support-    -U of M Academic Computing and Networking-

Jim McCullars <jim@info2.uah.edu> wrote:
> Greetings:
> 
>   In the past, we have bought a bunch of these Netra X1 and Sun Fire V100
> servers when we needed a small machine to run a dedicated application (like
> web, calendar, LDAP, etc).  Now it seems that Sun doesn't sell SPARC-based
> machines in that price range any more.  What are the consequences of using,
> say, a Sun Fire X2100 as a replacement for a V100?  I mean in terms of
> binary compatibility and so forth.  A lot of the software we install is
> open-source, so will things like BIND, Apache, sendmail, etc compile under
> an x64 as easily as they do with a V100?  If we run a purchased application
> that advertises Solaris support, do we need to ask the vendor specifically
> about an AMD processor?  Thanks for any advice...

Well, there's no binary compatability between architectures. You'll have to
rebuild every unbundled application from source, which is time consuming. 
On the other hand, the actual compile process should be identical on either
platform.

If you want to stick with the SPARC line, the V210 is pretty cheap and quite
a nice box, although not really up to the X2100 in terms of raw speed.

The one annoying feature I've found is the horrible PC bios, and the quirks
of the serial console. Actually, that's two closely related 'features.' At
any rate, given that sunfreeware.com and blastwave.org have most packages
precompiled these days, they're nice little boxes once they're up and running.

Colin

groenvel@cse.psu.edu (John D Groenveld) writes:

>I wouldn't use Sun's Perl's for anything except Sun's applications.
>For your own applications, its best to maintain your own Perl builds
>with your favorite compilers, compiler options, and module versions.

Why?  (Unless you aspire to be in the software business?)

Casper
-- 
Expressed in this posting are my opinions.  They are in no way related
to opinions held by my employer, Sun Microsystems.
Statements on Sun products included here are not gospel and may
be fiction rather than truth.

In article <444ea32b$0$31651$e4fe514c@news.xs4all.nl>,
Casper H.S. Dik  <Casper.Dik@Sun.COM> wrote:
>Why?  (Unless you aspire to be in the software business?)

Too much risk that application A's module version dependencies
conflict with application B's module version dependencies.

I guess this can be mitigated with lots of testing and by careful
use of @INC, but the success of Solaris containers show that
disk and memory is cheaper.

John
groenveld@acm.org

Casper H.S. Dik <Casper.Dik@sun.com> wrote:
> groenvel@cse.psu.edu (John D Groenveld) writes:
> 
>>I wouldn't use Sun's Perl's for anything except Sun's applications.
>>For your own applications, its best to maintain your own Perl builds
>>with your favorite compilers, compiler options, and module versions.
> 
> Why?  (Unless you aspire to be in the software business?)

One reason is to keep scared apps people happy.  If they decide that their
app only works with perl x.y.z and you want to patch the system perl to
x.y.z+1 you don't have to ask them to approve the patch.

Believe me it's less effort to build a perl for them than to spend days in
meetings trying to get apps people to test the new release :-)

In article <444f2607$0$649$5a6aecb4@news.aaisp.net.uk>,
News  <news@buffy.sighup.org.uk> wrote:
>Believe me it's less effort to build a perl for them than to spend days in
>meetings trying to get apps people to test the new release :-)

And then there are the real compatibility problems between
64 bit Perl, 32 bit Perl with largefiles, 32 bit Perl with threading,
etc.

John
groenveld@acm.org

In article <e2loho$cbf$1@info2.uah.edu>,
Jim McCullars <jim@info2.uah.edu> wrote:
>   I guess I was just looking for some reassurance that Solaris x86 wasn't
>just a "kludge" that was going to give me problems :-)

	Not anymore, thank goodness.
-- 
"When in doubt, use brute force."
- Ken Thompson

"Jim McCullars" <jim@info2.uah.edu> wrote in message
news:e2lp6m$cie$1@info2.uah.edu...
> John D Groenveld (groenvel@cse.psu.edu) wrote:
> : What commercial application?
>
>    Just as an example, we run Banner from SungardSCT and the front-ends
> are Sun servers.  We also run Payment Gateway and webCheck from Touchnet
> Information Systems and are about to migrate those applications to small
> Sun servers like a V100 and I was wondering about applications like that.
> Of course, I guess the smart thing to do would be ask the vendor, right?
:)

I don't want to cry "Bandwagon" or anything, but have you considered running
the applications on a larger, shared machine within dedicated zones? You'll
lose potential redundancy (i.e. one hardware failure can take out several
applications), but you may well get better bang/buck and keep your SPARC
binaries as well (plus all of the other shouted from the rooftop potential
benefits of virtualization). You may even have a machine hanging around
that's "too big" for this task already that just might be suitable.

Regards,

Will Hartung

Will Hartung (redrocks@sbcglobal.net) wrote:

: I don't want to cry "Bandwagon" or anything, but have you considered running
: the applications on a larger, shared machine within dedicated zones? You'll

   Actually, yes I have.  I attended the Solaris 10 Advanced System Admin
class in Atlanta last month and heard about Solaris zones for the first time.
I remember thinking at the time that that might be an alternative to 
our practice of purchasing small dedicated servers for specific applications.
The only concern I had was that processor time and memory use could not
be partitioned, but our instructor seemed to think that that might be
available in the not-too-distant future.

Jim McCullars

jim@info2.uah.edu (Jim McCullars) writes:

>Will Hartung (redrocks@sbcglobal.net) wrote:

>: I don't want to cry "Bandwagon" or anything, but have you considered running
>: the applications on a larger, shared machine within dedicated zones? You'll

>   Actually, yes I have.  I attended the Solaris 10 Advanced System Admin
>class in Atlanta last month and heard about Solaris zones for the first time.
>I remember thinking at the time that that might be an alternative to 
>our practice of purchasing small dedicated servers for specific applications.
>The only concern I had was that processor time and memory use could not
>be partitioned, but our instructor seemed to think that that might be
>available in the not-too-distant future.

Processor time is already partitionable; but physical memory use is
not.

Casper
-- 
Expressed in this posting are my opinions.  They are in no way related
to opinions held by my employer, Sun Microsystems.
Statements on Sun products included here are not gospel and may
be fiction rather than truth.