A computer components & hardware forum. HardwareBanter

If this is your first visit, be sure to check out the FAQ by clicking the link above. You may have to register before you can post: click the register link above to proceed. To start viewing messages, select the forum that you want to visit from the selection below.

Go Back   Home » HardwareBanter forum » General Hardware & Peripherals » General
Site Map Home Register Authors List Search Today's Posts Mark Forums Read Web Partners

AMD/Linux vs Intel/Microsoft



 
 
Thread Tools Display Modes
  #41  
Old January 10th 04, 11:46 PM
Mainframe Linux
external usenet poster
 
Posts: n/a
Default


They've never put enough effort towards drivers, even for WINDOWS,
IMHO.


linux doesn't need fancy 3d drivers

it uses the cpu for x rendering

  #42  
Old January 11th 04, 08:06 AM
stacey
external usenet poster
 
Posts: n/a
Default

Kevin Lawton wrote:

chrisv wrote:


If a manufacturer chooses to not supply drivers for your chosen OS then
what is the point in 'spitting into the wind' building a machine to run
that OS using parts lacking in decent driver support ?


Exactly. I needed a new photo printer and have used canon in the past. But
when I started using linux I found the driver support for canon printers
sucks and this is canon's fault IMHO. Epson and HP provide the info for
good drivers to be written or actively support linux themselves so guess
whose printer I bought? A hint, it wasn't Canon. Maybe they don't care that
I bought someone else's $400+ printer just because they don't want to be
involved with linux?
--

Stacey
  #43  
Old January 11th 04, 02:55 PM
Linønut
external usenet poster
 
Posts: n/a
Default

Fearing a spontaneous XP reboot, stacey mumbled this incantation:

Kevin Lawton wrote:

chrisv wrote:


If a manufacturer chooses to not supply drivers for your chosen OS then
what is the point in 'spitting into the wind' building a machine to run
that OS using parts lacking in decent driver support ?


Exactly. I needed a new photo printer and have used canon in the past. But
when I started using linux I found the driver support for canon printers
sucks and this is canon's fault IMHO. Epson and HP provide the info for
good drivers to be written or actively support linux themselves so guess
whose printer I bought? A hint, it wasn't Canon. Maybe they don't care that
I bought someone else's $400+ printer just because they don't want to be
involved with linux?


I have an additional consideration. A company may not see enough of a
market to make Linux support worth the cost. Fine. But a good company
will have developers who are keenly interested in getting their
company's product supported on Linux. They will be motivated to write
the code themselves, and push it through the process to at least have
"officially unsupported" drivers posted at the corporate download site.

An motivated coders are quite often good coders, as shown by the whole
Open/Free software community.

--
No, I won't fix your Windows computer!
  #44  
Old January 11th 04, 07:37 PM
Tom Morris
external usenet poster
 
Posts: n/a
Default


"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!

Tom


  #45  
Old January 12th 04, 01:22 AM
Rupa Schomaker
external usenet poster
 
Posts: n/a
Default

Tony Hill writes:

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


My first WinNT box was a MIPSpower (MIPS cpu) machine running 3.5.1.
We used it to run a cheaper (than unix) version of Pro/Engineer
(parametric CAD software).

They did work and were fairly fast at the time.

--
-rupa
  #46  
Old January 12th 04, 03:44 PM
THX1138
external usenet poster
 
Posts: n/a
Default

E wrote in message ...
Tony Hill wrote:

On Thu, 08 Jan 2004 00:13:13 -0500, E
wrote:


snip


Although Intel currently has there own IA-64 architecture, this is aimed
at the server market,


Intel is still holding out for IA-64 across the board. Their original
plan had IA-64 dominating the server world by 2000 and starting to
take over the workstation market at that time. Then, by 2002 and 2003
IA-64 was supposed to be replacing IA-32 on the desktop and in all
except the low-end and mobile chips.

Obviously things haven't played out quite how Intel had hoped! Still,
they've put too much time and effort into IA-64 to abandoned it just
yet. Announcing a 64-bit extension to x86 for the Xeon would pretty
much kill off the Itanium line.


Thats interesting, so Intel might one day have an IA-64 and an AMD x86-64
aimed at desktop PCs?


and from what I have read, if Intel wants to go 64 bit,
Microsoft wants Intel to get a license to implement AMD x86-64


Rumor has it that Microsoft has told Intel that they've already played
their 64-bit hand with the Itanium. That was their one and only shot.
If they want another 64-bit architecture, it'll have to be one that MS
already supports, ie AMD64.


Yes, I read this same rumor. But I don't understand why if Microsoft already
has a version of XP for the Itanium, they would drop support for it in
favor of a version of Windows for x86-64, and tell Intel to follow suite
with there desktop CPU line. I guess its the built in 32 bit compatiblity
of the AMD x86-64.


architecture. But Intel also has Hyperthreading in there Xeon and Pentium
4 lines, and will have a more improved version in the Prescott
core, which may help in multitasking. But like AMD's 64 bit solution,
don't individual applications need to be written and compiled with the new
optimizations in mind, in order to gain any benefit?


Not exactly. The program needs to be multithreaded. Simply
recompiling a program will not make it multithreaded, a
single-threaded program would need to be partially re-written to take
advantage of it.

However, that being said, any program that is designed to work on a
multiprocessor machine is already going to be multithreaded (or use
multiple processes). Basically any server application worth it's salt
is already written with multiple processors in mind, so SMT (or
hyperthreading in Intel's word book) is supported right out of the box
(though perhaps not in an ideal fashion). Hyperthreading is like a
poor-mans dual-processor setup in one chip.

There are a few pitfalls to this. SMT doesn't give you a full second
processor, just an emulation of one. You still need to share lots of
resources. In particular, if a program is designed to be split among
processors to optimize the use of cache in a dual-processor box it can
easily end up running slower with hyperthreading (each thread keeps
bumping the other's data out of cache). So, in this sense modifying
the code and recompiling can provide additional benefits for SMT.

This is where it gets interesting. Why doesn't Microsoft have an x86-64
version ready of Windows XP?


It's in the works but not ready yet. The main issue is market demand,
or lack there of. Unfortunately AMD64 (aka x86-64) is basically a
negligible feature in the grand scheme of things at the moment. AMD
has sold, at most, a million AMD64 capable chips so far. For
comparison, Intel sells a million chips every three or four days.

What this means is that there isn't much incentive for Microsoft to
invest a lot of time and money into supporting an AMD64 port of WinXP
entirely on it's own. Supporting a separate architecture is
expensive, especially for a company like Microsoft that has LOTS of
different products that need to work together. To minimize costs,
Microsoft has wisely chosen to try and keep their AMD64 and their IA32
ports as close together as possible.

Unfortunately for AMD this means that WinXP for AMD64 won't be
released until Microsoft can synch up the releases of the two. That
isn't going to happen until this summer with the release of WinXP SP2.
If Microsoft were to release WinXP for AMD64 now it would be sort of
halfway in between SP1 and SP2 and would require extra cost to support
independently.

Will Linux companies pick up the slack, and
ban together with AMD to take some of the Windows and Intel market share?


Possibly, but not in huge numbers. In Q3 of 2003 AMD managed to sell
something like 10,000 servers. In that same time frame Intel sold
~500,000 Xeon servers. Even if every single one of those servers sold
went to Linux instead of Windows Microsoft is still not losing much in
the way of sales. However, the numbers will grow and if MS delays the
release of their operating system for AMD64 for too much longer it
might start costing them some real money.

There are already 64-bit Linux distributions ready. Will open source
applications be optimized for AMD x86-64?


Probably yes. Actually they just need to be recompiled to take
advantage of most of the new features of AMD64.

Will proprietary vendors of
multimedia and photo editing software, optimize there applications for AMD
x86-64 and port them to Linux? We can only hope.


Probably not. Porting a Windows application to Linux is a pretty big
undertaking for a commercial software vendor. It's a very different
environment from Windows and requires a lot of software changes as
well as increased support costs. If the application is already ported
to Linux, then porting to AMD64 is an easy option (case-in-point,
IBM's DB2, which apparently took all of 2 days to port from IA-32 to
AMD64 under Linux). However, porting a commercial application JUST
because AMD64 is supported under Linux now and won't be supported
under WinXP for 6 months makes absolutely no sense.

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



My own observation is that it comes down to politics more then
technology.
Microsoft promised support to AMD for x64 when it came out and pulled
back at the last minute for two reasons.

1) Microsoft still needs Intel for sales as Intel still has a
veritable monopoly on consumer systems although they would very much
like this not to be the case very soon. So a bone was kicked in hte
direction on Intel to allow them to claim 64 bit Windows on Itanium.

2) Microsoft is in the process off revamping everything around Rights
Denial
( NGSCB or Palladium if you will ), Microsoft DRM, etc. and really
wants this so that it can pander to the likes of the music and movie
monopoly slobs at the expense of it's customer base who you get the
feeling that they think are stupid enough to believe that it's for
their benefit. You could see the logic in this if you accept that you
are a monopoly leveraging your OS product to sell you productivity and
back room apps and you want to seal up the vast majority of systems
from your competition that you know that you have no other way of
competing against. I think it's interesting to note that both AMD64
based chips and Itanium and all future Intel processors support the NX
( No execute ) register. This is one way to allow NGSCB to lock out
"illegal" applications and for Microsoft and others to control the
list of legal applications that can run in the processor. Do you
suppose this was the price of admission the Microsoft wanted from the
processor people? I think the Intel got the better end of the deal in
that case.

THX
  #47  
Old January 12th 04, 06:39 PM
Rob Warnock
external usenet poster
 
Posts: n/a
Default

Tim Shoppa wrote:
+---------------
| ... but all that may have to be re-done... AGAIN. Linux doesn't
| suffer nearly so much from this stupidity (but it does, to some extent,
| as many manufacturers distribute binary-only drivers for Linux.
| That's not the fault of Linux, although many regard binary-only
| drivers as pure evil.)
+---------------

In some cases the manufacturer simply has no other choice. A good case
in point is for wireless devices (e.g., 802-11.{b,a,g}) in which some
aspect of the transmission (frequency, power, or encoding, say) is
dynamically controlled directly by the driver software [so-called
"software-defined radios"]. The FCC has ruled that the end-user *must*
not be able to alter those characteristics of the driver, since it
might result in the device no longer meeting its emissions requirements.
See "Section C: Software Modifications" in the following:

URL:http://ftp.fcc.gov/Bureaus/Engineeri...nology/Orders/
2001/fcc01264.pdf

Sam Leffler, in particular, has been working to create a standard for
an API to the FCC-mandated binary parts of wireless drivers (as well as
parts considered vendor-proprietary) for open-source operating systems
(sort of like the old MS-DOS "NDIS" driver API for networking cards),
starting initially with the Atheros chipset and the Linux & FreeBSD
operating systems, to encourage more wireless manufacturers to support
open-source operating systems. See:

URL:http://cvs.sourceforge.net/viewcvs.py/madwifi/madwifi/
README?rev=1.17
URL:http://www.atheros.com/news/linux.html
URL:http://wifinetnews.com/archives/002545.html
URL:https://sourceforge.net/projects/madwifi/
URL:http://ndiswrapper.sourceforge.net/


-Rob

-----
Rob Warnock
627 26th Avenue URL:http://rpw3.org/
San Mateo, CA 94403 (650)572-2607

  #48  
Old January 12th 04, 10:08 PM
chrisv
external usenet poster
 
Posts: n/a
Default

On Sat, 10 Jan 2004 14:39:02 +1300, ~misfit~ wrote:

chrisv wrote:

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


**** 'em. nVidia make some good cards and drivers.


Yeah, I may have to go that way with my next card. I've never liked
nVidia or it's products all that much, but if their card has better Linux
support...

These companies must know that there's a lot people who are going to be
checking-out Linux, and they should be ready. Tux Racer @ 1fps is NO
GOOD! 8)

  #49  
Old January 12th 04, 11:20 PM
Kevin Lawton
external usenet poster
 
Posts: n/a
Default

chrisv wrote:
| On Sat, 10 Jan 2004 14:39:02 +1300, ~misfit~ wrote:
|
|| chrisv wrote:
|||
||| I'm the customer, ATI. I'm the guy with the money that YOU want.
||| Make some effort to help me out!
||
|| **** 'em. nVidia make some good cards and drivers.
|
| Yeah, I may have to go that way with my next card. I've never liked
| nVidia or it's products all that much, but if their card has better
| Linux support...
|
| These companies must know that there's a lot people who are going to
| be checking-out Linux, and they should be ready. Tux Racer @ 1fps is
| NO GOOD! 8)

Exactly - so vote with your wallet ! ;-)
This brings me back to using Matrox video cards in systems which run a
non-Micro$oft OS - often Linux, maybe something else (BeOS ?).
The high-spec nVidia and ATI cards show their best performance ratings
used on Windoze systems - and the battle for top position seems to change
monthly. This isn't much of an indication of how the card might perform
under, say, Linux as the system for displaying complex 3D graphics is a bit
different. Those top-ranking cards rely on Windoze drivers which have been
carefully written to exploit their features. In a Linux box they might not
seem quite so clever.
Matrox have the good sense, decency and end-user committment to offer
Linux drivers for most of their cards - that is one of the reason why I use
them and recommend them. The other two reasons are image quality and the
ability to drive two monitors (dual head). I even have a system running BeOS
giving a dual-head display from its Matrox card (G400).
To me, these things are more important than being able to show about 70
fps in the latest games. My eyes posses a feature called 'persistance of
vision' which prevents such speed being necessary - and ceratinly not worth
paying for.
Kevin.



  #50  
Old January 13th 04, 02:45 AM
Tony Hill
external usenet poster
 
Posts: n/a
Default

On 12 Jan 2004 06:44:30 -0800, (THX1138) wrote:
My own observation is that it comes down to politics more then
technology.
Microsoft promised support to AMD for x64 when it came out and pulled
back at the last minute for two reasons.


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!

1) Microsoft still needs Intel for sales as Intel still has a
veritable monopoly on consumer systems although they would very much
like this not to be the case very soon. So a bone was kicked in hte
direction on Intel to allow them to claim 64 bit Windows on Itanium.


Intel needs Microsoft much more than Microsoft needs Intel.

2) Microsoft is in the process off revamping everything around Rights
Denial
( NGSCB or Palladium if you will ), Microsoft DRM, etc. and really
wants this so that it can pander to the likes of the music and movie
monopoly slobs at the expense of it's customer base who you get the
feeling that they think are stupid enough to believe that it's for
their benefit.


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.

Of course, the goal of the DRM stuff is most certainly not to help the
users, but rather to attract the media companies to release their
wares using Microsoft DRM. What better way to keep people using your
product than to REQUIRE the use of your product to view certain
content?

competing against. I think it's interesting to note that both AMD64
based chips and Itanium and all future Intel processors support the NX
( No execute ) register. This is one way to allow NGSCB to lock out
"illegal" applications and for Microsoft and others to control the
list of legal applications that can run in the processor. Do you


What in the hell are you talking about? First off, the NX bit is just
that, a bit in the page table. It has ABSOLUTELY NOTHING to do with
applications! It does exactly ONE thing and one thing alone, it marks
pages in the page table as executable or non-executable. This is a
feature that is implemented in many (most?) other architectures out
there but has been sadly lacking in x86 (err, it's implemented in
IA32, but only in a rather ass-backwards manner that can not be easily
used by most operating systems).

It's quite unclear whether Intel will support this feature in their
upcoming P4 "Prescott" chips or not. One recent third-party report
was quoted as saying that they will, however several other recent
reports have Intel saying that they the Prescott does not support the
NX bit and they have no plans on doing so.

suppose this was the price of admission the Microsoft wanted from the
processor people? I think the Intel got the better end of the deal in
that case.


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.

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




Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

vB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Forum Jump


All times are GMT +1. The time now is 11:26 AM.


Powered by vBulletin® Version 3.6.4
Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
Copyright ©2004-2024 HardwareBanter.
The comments are property of their posters.