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. |
|
|
Thread Tools | Display Modes |
#41
|
|||
|
|||
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
|
|||
|
|||
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
|
|||
|
|||
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
|
|||
|
|||
"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
|
|||
|
|||
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
|
|||
|
|||
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
|
|||
|
|||
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
|
|||
|
|||
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
|
|||
|
|||
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
|
|||
|
|||
|
Thread Tools | |
Display Modes | |
|
|