From: David Combs on
In article <hf41jv$8ee$1(a)news.eternal-september.org>,
Andrew Gabriel <andrew(a)cucumber.demon.co.uk> wrote:
>In article <Toqdne9RdMmsbo7WnZ2dnUVZ8kqdnZ2d(a)pipex.net>,
> solx <nospam(a)example.net> writes:
>> Hi,
>>
>> Having worked for a software house, Sun has done themselves no favours
>> by dropping SPARC workstations. The Sun workstations are all AMD or
>> Intel based, while servers are SPARC, AMD or Intel.
>> I worked with developers who wanted SPARC workstations but were given
>
>What did they want them for?
>If you want to develop for sparc servers, you need to do that on
>a sparc server. They are now so different from workstations, that
>if you developed on a workstation, your app would probably run
>very badly on a modern server.
>
>> AMD64/x86 based workstations running Windows. Hopefully with Solaris 11
>
>Stick Solaris x86 on it and use it to front-up your sparc server
>for same look and feel, or even just as an X terminal (or use a
>SunRay). There's no shortage of ways to achieve the same thing,
>but developing on a sparc workstation won't any longer give you
>any feel for how a modern server works - they've moved on too
>far from simply being big versions of a workstation.

Wow, is that statement a surprise!



(1) A Blade-2500(red): workstation or server?




(2) Please, elaborate a bit (maybe a lot!) on
the difference between a "sparc workstation" (were Sun to
resume making them) and a "server", as far as developing
software via the workstation to eventually run on
the server.



(3) I always thought solaris was solaris was solaris, be it
workstation or server. Where was I wrong?


THANKS!

David (and many others equally surprised!)



From: Tim Bradshaw on
On 2009-12-11 00:27:03 +0000, dkcombs(a)panix.com (David Combs) said:

> 2) Please, elaborate a bit (maybe a lot!) on
> the difference between a "sparc workstation" (were Sun to
> resume making them) and a "server", as far as developing
> software via the workstation to eventually run on
> the server.

A T-series box, for instance, has oodles of rather slow "cpus", whereas
a workstation has only two or 4 or something, and they are probably
individually faster.

From: David Combs on
In article <2009121120425016807-tfb(a)tfeborg>,
Tim Bradshaw <tfb(a)tfeb.org> wrote:
>On 2009-12-11 00:27:03 +0000, dkcombs(a)panix.com (David Combs) said:
>
>> 2) Please, elaborate a bit (maybe a lot!) on
>> the difference between a "sparc workstation" (were Sun to
>> resume making them) and a "server", as far as developing
>> software via the workstation to eventually run on
>> the server.
>
>A T-series box, for instance, has oodles of rather slow "cpus", whereas
>a workstation has only two or 4 or something, and they are probably
>individually faster.
>

But how would that make them (sparc workstations) useless
for writing server programs?


David


From: Ian Collins on
David Combs wrote:
> In article <2009121120425016807-tfb(a)tfeborg>,
> Tim Bradshaw <tfb(a)tfeb.org> wrote:
>> On 2009-12-11 00:27:03 +0000, dkcombs(a)panix.com (David Combs) said:
>>
>>> 2) Please, elaborate a bit (maybe a lot!) on
>>> the difference between a "sparc workstation" (were Sun to
>>> resume making them) and a "server", as far as developing
>>> software via the workstation to eventually run on
>>> the server.
>> A T-series box, for instance, has oodles of rather slow "cpus", whereas
>> a workstation has only two or 4 or something, and they are probably
>> individually faster.
>>
>
> But how would that make them (sparc workstations) useless
> for writing server programs?

Why?

--
Ian Collins
From: Tim Bradshaw on
On 2009-12-21 05:25:47 +0000, dkcombs(a)panix.com (David Combs) said:

> But how would that make them (sparc workstations) useless
> for writing server programs?

It makes it very hard to do any kind of performance tests. The likely
result of that is that when the application gets deployed on a T-series
machine, the performance is terrible because there's not enough
parallelism, or equivalently there are single-threaded bottlenecks all
over it. Very smart people might be able to deal with this at the
design stage (ie "I know the performance of this application will be
terrible on the machine I write it on, but I'm clever enough to be able
to predict that it will be OK on the target platform"), but I'm not
sure I've ever met anyone that clever.