AMD/Linux vs Intel/Microsoft

On Thu, 08 Jan 2004 20:03:13 GMT, "GreyCloud"
wrote:
The real issue is whether the Itanium port has been done competently,
or by simply spawning off another completely unportable code stream.
I have not heard any reliable rumours either way.

OpenVMS has been ported successfully to the Itanium2 processor as well as
TRU-64 UNIX. Whether HP keeps tru-64 unix is another question tho.
When M$ has ported XP to the Itanium2 isn't known here nor have I seen any
ads on M$ website about it.

WinXP was ported to IA-64 long ago. Here's the webpage for WinXP
64-bit edition for IA-64:

http://www.microsoft.com/windowsxp/64bit/default.asp

I guess this wasn't really done for the Itanium2 since it predates
that chip, but it certainly will run with no troubles at all on it.
More recently MS released Win2003 Server for IA-64.

FWIW at least in theory WinNT was designed to be very portable. The
entire system was built with a hardware abstraction layer that was
supposed to minimize the amount of architecture-specific code. Now,
I'm not sure just how successful this attempt was, but the basis is
there. At various times NT was reported to have been running on
PowerPC and MIPS in addition to the Alpha, i386 and IA-64 instruction
sets that it was officially released for. Combined with the upcoming
AMD64 port that makes for a fairly impressive array of architectures,
though several of them were stillborn.

-------------
Tony Hill
hilla underscore 20 at yahoo dot ca

chrisv wrote:

You can't tell me it would take all THAT much manpower for a company
like ATI to compile their drivers for the half-dozen or so leading Linux
distributions.

It does take THAT much manpower and more. ATI hasn't had a stellar
record by any stretch even while compiling for wintel only and one can
only expect even lower quality when compiling for 6-10 different
platforms. nVidia has had an only slightly better record. But there
are other much smaller manufacturers of hardware which will be buried
under a load they cannot handle peoperly, so the users of ALL
platforms do suffer, which will only get worse.

Competition is usually good but the ideal in hardware/OS level would
be a standards based black box approach, where, say, both Intel and
AMD would agree to optimize for performance/price a black box
processor with predefined standards. Same for OS's. Of course nobody
would agree to that.

Kevin Lawton wrote:


I don't think there is much profit made out of drivers, though.


Except the hardware sales. I chose an epson printer rather than another
canon (I've owned several) because of the crappy linux support with canon
products. This cost canon the sale of a $400 photo printer not helping with
linux drivers for their products!

--

Stacey

"Del Cecchi" writes:

When I look at the brochure for the x450 and x455, it says "Supports
Microsoft Windows Server 2003, Enterprise Edition "
These are IA64 boxes. Is that XP?

It is XP's successor. Don't you just love vendor version numbering?
I am especially fond of "HP-UX 11i version 2" (aka HP-UX 11.23).

Cheers,
--
In order to understand recursion you must first understand recursion.
Remove /-nsp/ for email.

"Stephen Sprunk" wrote in message
.. .
"GreyCloud" wrote in message
...
The porting was by DEC. DEC had to pay for the whole port. Trouble
was, NT couldn't compete against OpenVMS and TRU64 UNIX on the
Alpha. Not enough features and pretty rough around the edges.
DEC dropped developement for M$. M$ let the other vendors do the
port of NT to their perspective platforms. When the vendors finally
woke
up, they dropped NT.

Were there any platforms besides i386, Alpha, and MIPS?


The RISC line that SGI line was using I think for a while. I do know that
SGI tried to push NT under their namebrand of X86 for a period, but it
brought them nothing but a bad name out of it.

OpenVMS has been ported successfully to the Itanium2 processor as well
as
TRU-64 UNIX. Whether HP keeps tru-64 unix is another question tho.

I don't see why HP would continue supporting Tru64 if they've already got
a
commitment to HP-UX on IA64. Also, HP appears to be putting some level of
support into Linux and GCC -- at least on IA64. How many different unix
flavors can a single vendor realistically ship and support?


Good point and one that is good to take to the bank. I only see it being
supported under the current federal contracts... but after that I suspect
its the axe for tru64.

When M$ has ported XP to the Itanium2 isn't known here nor have I
seen any ads on M$ website about it.

Windows Server 2003 has been ported to IA64. Whether XP was ported or not
is now moot.

Most of the old DEC line uses Apache now anyway. If there is a mass
produced IA64 for public use, XP maybe only able to compete if the price is
real low. Other than that windows can't compete against OpenVMS on the
IA64.

In comp.arch Peter Köhlmann wrote:
David Magda wrote:

(Tim Shoppa) writes:

Set your wayback machine to the early-mid-90's and remember that
Microsoft sold Windows NT for a 64-bit platform (Alpha) before.
Rumors have it that other RISC platforms were targets back then
[...]
Actually it ran on PowerPC and MIPS as well, if I remember
correctly. This was NT 3.5(1) and maybe 4.0. It's one of the reasons
why NT has/had a hardware abstraction layer (HAL).
It did not run under NT4.
And the Alpha-version ran in 32-bit mode

I have a Finnish-language OEM NT4 CD that contains versions for Alpha,
i386, MIPS and PPC. By contrast, the service pack 4 CD enclosed in the
same package supports only the Alpha and i386 versions.

-a

On Fri, 09 Jan 2004 03:47:06 +0000, Bogdan wrote:

chrisv wrote:

You can't tell me it would take all THAT much manpower for a company
like ATI to compile their drivers for the half-dozen or so leading Linux
distributions.

It does take THAT much manpower and more.

Sorry, I don't understand how. They've done the driver in source code
already. They've written insructions on how to compile the kernel
modules. How much of the end-user's time do they expect this whole
process to take? An hour? That seems to be the maximum reasonable time
to expect an end-user to take to get a dang driver installed.

Now, how much time would it take for someone who really knew what they
were doing, because they worked with these drivers for a living? I would
expect a half-hour TOPS. Now, you multiply that by a half-dozen
distributions, maybe double it again for the two most recent versions of
XFree, and you have like ONE DAY of an engineer's time.

What am I missing? And even if my time estimates are unrealistic, it's
sure a hell of a lot easier for them to do it, ONCE for each distro/XFree,
rather than asking thousands of end-users to make the individual effort.

I'm the customer, ATI. I'm the guy with the money that YOU want. Make
some effort to help me out!

On Thu, 08 Jan 2004 17:05:04 +0100, Bernd Paysan wrote:

I don't know what problems you'll have with ATI cards and Linux (up to
now, I've mainly use nVidia cards, and a Matrox card), but if you go to
http:/ www.ati.com/support/faq/linux.html, you'll see that ATI does
support Linux, and does provide proprietary binary drivers on
http://mirror.ati.com support/driver.html.

These did not work. The install failed and the messages told me that I
had to compile kernel modules (using MD9.2). Googling, I found that others
were getting the same error messages that I was.

"Tony Hill" wrote in message
.com...

FWIW at least in theory WinNT was designed to be very portable. The
entire system was built with a hardware abstraction layer that was
supposed to minimize the amount of architecture-specific code. Now,
I'm not sure just how successful this attempt was, but the basis is
there. At various times NT was reported to have been running on
PowerPC and MIPS in addition to the Alpha, i386 and IA-64 instruction
sets that it was officially released for. Combined with the upcoming
AMD64 port that makes for a fairly impressive array of architectures,
though several of them were stillborn.



My first NT box was a MIPS based DEC 5000 (or some such thing) prior to
Alpha being done (I was investigating graphics support for Alpha/NT). A DEC
group in Seattle (DECWest) did the work as far as I remember. At the first
NT developers conference, I recall that they made a lot of noise about how
NT was designed to be portable across architectures. Much later on, in
connection with some console firmware research - I noted that OpenBoot had a
"thin veneer" implementation of the "BIOS" interfaces that allowed NT to
boot on Alpha which apaprently had been used for PowerPC (again IIRC froma
hazy memory).

The basic problem really is that the Windows market is a shrink wrap SW
market. Despite interesting things like FX!32, other architectures just had
no real advantage unless SW vendors (including Microsoft!) would provide
native implementations of their apps.

chrisv wrote:
On Fri, 09 Jan 2004 03:47:06 +0000, Bogdan wrote:
chrisv wrote:

You can't tell me it would take all THAT much manpower for a
company like ATI to compile their drivers for the half-dozen
or so leading Linux distributions.

It does take THAT much manpower and more.

Sorry, I don't understand how. They've done the driver in source
code already. They've written insructions on how to compile the
kernel modules. How much of the end-user's time do they expect
this whole process to take? An hour? That seems to be the
maximum reasonable time to expect an end-user to take to get a
dang driver installed.

Now, how much time would it take for someone who really knew what
they were doing, because they worked with these drivers for a
living? I would expect a half-hour TOPS. Now, you multiply that
by a half-dozen distributions, maybe double it again for the two
most recent versions of XFree, and you have like ONE DAY of an
engineer's time.

What am I missing? And even if my time estimates are unrealistic,
it's sure a hell of a lot easier for them to do it, ONCE for each
distro/XFree, rather than asking thousands of end-users to make
the individual effort.

I'm the customer, ATI. I'm the guy with the money that YOU want.
Make some effort to help me out!

Adapting drivers to the quirks of various systems is non-trivial,
so I don't blame them for not issuing multiple versions. However
all manufacturers of anything should be publishing their complete
interface specification, timing requirements, etc. so that anyone
can build an accurate driver. This doesn't even require that they
publish the source to their own drivers, although doing so would
probably be helpful to both sales and the public, not to mention
driver quality.

For all you know a part of the driver may be required to upload a
program in goombah machine code to the device to launch it. That
may save a ROM, or ease modification, and the reluctance to
publish is because that goombah code exposes trade secrets.

--
Chuck F ) )
Available for consulting/temporary embedded and systems.
http://cbfalconer.home.att.net USE worldnet address!