AMD/Linux vs Intel/Microsoft

David Utidjian wrote:

.... snip ...

One can get a very decent card from Nvidia for under US$100 and
one that is decent for under US$50. While it would be nice if we
could get the specs from Nvidia or they would completely
open-source their drivers I have no problem with the current
ones. The stock XFree86 "nv" driver works just fine in 2D.

Conceded that that sort of thing handles 98% of most needs today.
However I miss the ability to build cheap systems from commercial
hardware from the ground up. This enables one to correct faults,
avoid copyrights, etc.

As an example 20 years ago I could buy a complete Kaypro, replace
the EPROM, and be running entirely on my own code. No disk drives
were necessary for some applications. Nothing was hidden - every
component was fully documented and replaceable. I can't do the
equivalent today. This makes such systems unsuitable for critical
applications, such as medicine, aeronautics, voting, even
financial.

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

In article ,
Kevin Lawton wrote:
So, if you are running an 'alternative' Op System like Linux or BeOS, then
you can get decent drivers to rn your Matrox, nVidia or S3 Savage card no
problem.
Ultimately, won't this just leave ATI 'out in the cold' while
non-Mocro$oft users opt for better-supported hardware ?

Leaving aside that many people do use ATI's Linux drivers
successfully:

A BOTE calculation with reasonable assumptions about number of card
sales dependent on some particular alternate OS, revenue to the OEM, and
size and cost of a graphics driver engineering and support team focusing
on that OS, what pops out the back end is that oficially supporting the
major flavors of Linux is in the ballpark of a break-even proposition,
while supporting any other alternate OS is done at a loss. The BeOS,
BSD, etc. markets are too small to be relevant to companies shipping
tens-hundreds of millions of chipsets/year.

Jon

On 13 Jan 2004 06:12:03 -0800, (THX1138) wrote:
Tony Hill wrote in message t.com...
On 12 Jan 2004 06:44:30 -0800, (THX1138) wrote:
They haven't really pulled back so much as delayed. That is hardly
anything new for Microsoft, I can't even remember the last time they
shipped something on time! The 6-9 month delay is fairly standard for
their products, no need for any conspiracy theories there!

Still, Don't you find it interesting that MS was able to come up with
a 64 bit implimentation of Windows that happens to only run on
Itanium?

No, no I don't. Furthermore, I don't see why anyone SHOULD find it at
all abnormal that Windows for IA64 arrived before Windows for AMD64.
The Itanium was released three years ago and the instruction set was
documented long before then. AMD64 hasn't even been here a year.

What's more, Windows for IA64 was late as well! When the Itanium came
out (3 years late), it was still 6-9 months before Microsoft had a
final version of Windows for it. The first systems shipped either
with Linux or with a beta version of WinXP. Sound familiar?

Minor FWIW, but NGSCB/Palladium/La Grande/name-of-day actually DOES
have some very beneficial aspects to it. The DRM stuff is really only
one small portion of the whole deal, but of course it's the ONLY part
that ever gets any coverage in the geek-sream media (I don't think any
of it gets coverage in main-stream media : ). The ability to run a
service in it's own 'sandbox' of a sorts is a very good thing from a
sever security standpoint.

This is very true but you know you are being obtuse if you think that
is what is driving this.

Intel ( AMD ) and especially MS don't give a wet fart about server
security because if they did they would have had at least 10 years to
fix the problem. They only care about money and security wasn't part
of the deal.

Of course all they care about is money, they're a company! But the
fact of the matter is that security problems are costing Microsoft,
Intel and AMD sales, people are choosing IBM AIX and Sun Solaris
instead of Intel/AMD on Windows because of security problems.
Security problems cost money, and money talks.

Of course there is the other issue I mentioned about MS wanting to
bring the media companies onto their side as well and drive sales that
way. It's a two-pronged strategy that MS is bundling together in one.
Microsoft talks all about the security aspects of it publicly and
doesn't say much about the DRM stuff, while the /. hordes yell and
scream about DRM and totally ignore the security aspect of it (all the
while yelling and screaming about MS' poor security track record).

Both AMD and Intel have included the hardware required for Microsoft's
NGSCB in their new or upcoming processors. Nothing in ANY of this
hardware has any connection at all to locking out applications or
operating systems.


http://www.theregister.co.uk/content/4/33729.html
MS to intro hardware-linked security for AMD64, Itanium, future CPUs
By John Lettice

Good god that article is TERRIBLE! Even by The Registers standards
it's bad! They even managed to get a clueless (or possibly just
incorrect) quote to back up their own cluelessness.

"The 32-bit version of Windows currently leverages the NX processor
feature, as defined by the AMD64 Architecture Programmer's Manual." So
actually, it's not being introduced to the mass market with SP2 - it's
here already for AMD64 platforms."

If they had bothered to do a good 10 seconds worth of research they
would have discovered that the NX bit is NOT SUPPORTED IN 32-BIT MODE!
AMD publishes complete documentation for their AMD64 instruction set
and they flat out state:

"No Execute (NX) Bit. Bit 63. This bit is present in the translation
table entries defined for PAE paging, with the exception that the
legacy-mode PDPE does not contain this bit. This bit is not supported
by non-PAE paging."

I like how they complain about how the NX bit doesn't seem to be a
must-have for Linux... Yet again, 10 seconds worth of research
probably would have told them that it's already used in Linux for
AMD64! I believe that it's turned off by default because some poor
written programs break, but it's certainly in there.

If I find it later there is an article on AMD's site that states that
NX IS for DRM...It's a sales pitch for corp types that was link
public.

Please do, I'd be interested in seeing how they managed that, because
there is NO WAY to get any sort or DRM using this feature. At the
very best it might be of a tiny bit of help in making existing DRM a
tiny bit trickier to break, but that would be trivial to get around.

I would highly recommend that you read AMD's documentation on what
this bit does. You can find it at page 175 of Volume 2 of their AMD64
Programming Guides (System Programming). Here's a link to the pdf:

http://www.amd.com/us-en/assets/cont...docs/24593.pdf


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

On Wed, 14 Jan 2004 00:33:33 +0000, Jon Leech wrote:

In article ,
Kevin Lawton wrote:
So, if you are running an 'alternative' Op System like Linux or BeOS, then
you can get decent drivers to rn your Matrox, nVidia or S3 Savage card no
problem.
Ultimately, won't this just leave ATI 'out in the cold' while
non-Mocro$oft users opt for better-supported hardware ?

Leaving aside that many people do use ATI's Linux drivers
successfully:

A BOTE calculation with reasonable assumptions about number of card
sales dependent on some particular alternate OS, revenue to the OEM, and
size and cost of a graphics driver engineering and support team focusing
on that OS, what pops out the back end is that oficially supporting the
major flavors of Linux is in the ballpark of a break-even proposition,
while supporting any other alternate OS is done at a loss. The BeOS,
BSD, etc. markets are too small to be relevant to companies shipping
tens-hundreds of millions of chipsets/year.

I hear that Linux is surpassing (or pretty darn close) Apple in desktop
share. Apple seems to be split about 50-50 between Nvidia and ATI graphics
sets. I don't know how that factors in to BOTE calculations but it MUST be
putting Linux in a better position than it was.

Another factor that I found surprising the first time I heard about it is
that, for Nvidia at least, they are working closely with the movie
industry in providing the drivers they need for their really high end
cards. I heard a talk by a group of people from Dreamworks at Linux World
Expo-NYC (I think it was 2 years ago). There seems to be a big push in
Hollywood SFX houses not just for render farms but for Linux on the
desktop of their artists. They tend to buy the really high end graphics
stuff like Nvidias Fire GL. They buy them every time there is a new one
and they buy them by the hundreds if not thousands. How many gamers buy a
US$500+ Fire GL card? Probably not many. These SFX houses have a certain
amount of suction with the chipset makers since they are buying the high
margin stuff. I think the reason we have seen decent drivers from Nvidia
is largely thanks to the SFX market. I am not sure where ATI fits into
that picture... though I suppose it must try.

-DU-...etc...

In comp.arch Tom Morris wrote:

"Ken Hagan" wrote in message
...

If MS (or anyone else) had really wanted RISC editions of NT to
succeed, they could have done worse than given away zillions of
x86-RISC cross-compilers. Sure, it wouldn't have been properly
tested on the new platform, but most software isn't properly
tested on the developer's platform either. )

That may be true of the vendors that you deal with, but most application
vendors take testing pretty seriously because it has a direct effect on
customer satisfaction (revenue) and support costs (expense).

The commercial vendors that I'm familiar with would (and did) consider
a cross compilation environment with no opportunity for testing a
non-starter.

Heck, the CAD vendors only certify and support specific versions
of the graphics card drivers!

Once you read the changelogs you will fast get to the point where you
say "oh, I see why". GFX drivers seem to be fast moving into complexity
levels that the companies have trouble handling.


Tom



--
Sander

+++ Out of cheese error +++