Re:Been running it for a week now, great release.
on
KDE 2.2 Released
·
· Score: 2
Apparently, GCC 3.0 is quite a dissapointment for most people. It really doesn't compile faster, it really doesn't produce faster code. It is *very* standard complient, but standards complience cannot be a compiler's only feature. Luckily, Intel C++ is being ported to Linux. Hopefully Intel does something smart and releases 'icl' in a form that's usable to the community. Since many users compile their software themselves, god knows a $400 compiler won't fly very well in the Linux market.
Re:some notes - Fix the Fonts please
on
KDE 2.2 Released
·
· Score: 2
Okay, I'll buy the bait. Win2K never crashes. It has yet to crash on me, even though I brutalize it with crappy programs (for example, InteractiveC). Of course, this is just my personal experience, so it doesn't matter much. On the other hand your little point is also personal experience, and similarly doesn't matter much. What counts is the fact that the majority consensus on the net is that Win2K is very stable (read through some non-Slashdot newsgroups). Maybe not as stable as Linux, but quite usably so. If it is unstable for you, than by all means use something better. However, don't pretend that just because it doesn't work for you that it doesn't work for everyone else.
Of course not! It was a tech demo to show the geometry capabilities of the GF3. Of course it can't do all of the rendering techniques that they did in the film. If they could, the damn thing wouldn't have taken nearly as long to release! Honestly, what kind of question is this? Do you EXPECT them to provide that level of quality?
1.5 million verticies/2.5 fps, gives about 600,000 verticies per frame. Since the average human has less than 100K hairs, it works out. So what exactly is wrong with their math? Of course the Geforce3 doesn't render at 2000x1600 at full quality (it can't since it doesn't do a lot of the rendering techniques) but that level of geometry is still pretty damn impressive for a sub-500 dollar vid card.
Yes, XFree86 will happily detect modes that it supports. Unfortunately, these seem to be the standard VESA modes, so it will not detect modes like 1152x864 @ 85 Hz (which is what I run my monitor at). It defaults to the same res at 75Hz instead (which gives me a headache). In fact, I usually end up stealing the modelines of a BeOS machine, since BeOS does indeed detect the more strenuous modes correctly.
Well, I look at you're message and see that you obviously lack the ability to follow an arguement. The guy who posted before me asked asked why an OEM should care what the hell software is on the CD. I said because sometimes the software is not compatible with mainstream OSs, which makes it harder to sell to stores. Obviously you missed the concept that an arguement can have subsections that are broader than the core issue.
As for the.sig issue, I don't make fun of you for using an OS that lacks basic plug and play features (XFree can't detect non VESA monitor modes such as 1152x864 @ 85 Hz without resorting to modelines) so you don't make fun of me for using an OS that lacks a decent POSIX API.
You still haven't said what prevents NVIDIA and ATI and the ARB from sitting at the table and coming up with an uniform API for such an extension.
>>>>>>>>
When they do, I'll be impressed. But they show no signs of it thus far. And I'll tell you what prevents them from working together: human arrogance, plain and simple.
Last time your cried, just like know, that the "hardware" is too different.
>>>
Care to cite that?
Bullshit. Direct3D is no better. You just have to decide on a freaking API and let the vendors implement that. Read elsewhere in this discussion about programmers not supporting DirectX N yet. How's that better than OpenGL's extension mechanism?
>>>>>>>
Because there are only two versions of DirectX ever in use. The current version, which is used by games already on the shelf (that would be 7.0) and the new version that is being used in games that are in development (that would be 8.0). Plus, DirectX is fully backwards compatible, which can't be said for all OpenGL extensions.
It's not better. You still have to rewrite stuff.
>>>>>>>>
No you don't. If you go from DirectX 7.0 to DirectX 8.0, you have to rewrite 0 lines of code, since they are 100% backwards compatible. To go from NVIDIA's extension to ATI's extension, you might have to rewrite a good bit of code, depending on the exact semantics of the extension.
The only difference is that some companies that will remain unnamed have placed stupid patents arround interfaces, not features, interfaces and other companies have to come up and implement their own.
>>>>>>>>>>>
You hit the nail on the head! "Interfaces, not features!" That's what OpenGL's extension mechanism misses. Two features with different interfaces might as well be two different features. With DirectX, every feature has exactly (1) interface, DirectX's. Not the same is true for OpenGL.
If you want to bitch at someone, bitch at the companies that patent interfaces and stop trolling about OpenGL not supporting current technology.
>>>>>>>>
OpenGL does support coherent technology, just not in a sane way. Extensions are bad design. Game developers don't like them, and users don't like them. They only people who like extensions are hardware manufacturers, because it allows them to lock people into using their products.
And this is a good thing? First, you can't just assume that everyone will copy NVIDIA's extensions and just use them blindly. Second, NVIDIA deciding OpenGL's extensions is a *good* thing? What if they decide to pull intellectual property? (Not that I'm accusing them, but they have the power to). At least with DirectX, its the game developers who decide what the API looks like.
I've programmed both, and I find DirectX to be *much* more powerful. For example, in DirectX you can render to a texture. Unless you dig up some SGI extension, you can't do the same in OpenGL. The problem is that while the core DirectX feature set will work on any card, specific extensions won't. The reason that DirectX doesn't have the same problem is that MS actively integrates new features into the core set. Meanwhile, OpenGL hasn't changed that much since 1.1. Let me give you a concrete example. Take this pixel shader thing. NVIDIA has a pixel shader implementation, and ATI has one. On OpenGL, they are exposed through different extensions. Thus, a developer must code for both extensions. In DirectX, they just have to write to the Pixel shader API. If Matrox comes along, they support the DirectX pixel shader API, but release a matrox-specific OpenGL extension. OpenGL developers now have 3 APIs to contend with, DirectX developers still have one. Eventually, the ARB gets around to making pixel shaders a standard extension, but in the meantime, the next big feature has come. Lather, rinse, and repeat.
Most of the DirectX -> OpenGL ports aren't that great. UT, for example, runs beter on Windows than on Linux. (Given that the lead programmer for the project has publicly dissed OpenGL, I'm not surprised). Plus, the ones that are there are ported are from pretty substantial companies. Besides, are you saying that more DirectX games is a *good* thing?
Obviously someone who has now clue how DirectX is designed! The DirectX team doesn't get led around by NVIDIA. The vast majority of the new features in DirectX get there because game developers want them. MS doesn't go into a room with NVIDIA and then send a DirectX release out. Instead, hardware vendors talk about what features they are thinking of putting in, software developers then ask for features that should be put in, and it goes back and forth until another DirectX comes out. Microsoft has some incredibly arrogant and stupid practices, but for a long time, I've had a hunch that the DirectX team wasn't part of the core MS culture. For example, they don't go to absurd lengths to make every single piece of a code a full-blown COMponent that can be remotely marshalled. DirectX's implementation of COM is so simplistic, I'm sure they got heat for it from the abstraction-obsessed Win32 guys.
This story actually gives me a chance to bitch about OpenGL! None of these new features are a part of the standard OpenGL. "Extensions! Extensions!" you shout. However, due to the differences between hardware, you'll end up with ATI and NVIDIA versions of the same extensions, since the ARB won't touch such new/untested features. This makes sense in the pro segment, where hardware is slow to evolve, but in the consumer segment, it will make the API seem antiquated. Plus, the extension mechanism isn't even suited to such uses anyway, since it was meant to expose features, not radically different methods of rendering. And yes, these are radically different. Part of the reason that the GeForce3 has 57 million transistors is that it has to have a standard geometry engine for DirectX 7 and a new vertex shader-based geometry engine.
In the long run, this will make OpenGL unpopular with game developers. Sure guys like Carmack and afford to suck it in and develop to all the extensions, but for a small development house that wants to make an impressive game, they'll go with DirectX to save themselves the development costs. And when they do, there goes the possibility of a native Linux port.
Now there are two solutions to this. First, the ARB could get off their asses and start integrating extensions. This could be problemetic for the pro segment, which wants a stable API. On the other hand, the ARB could fork OpenGL into a pro and a consumer version, but that results in two incompatible APIs. I think Microsoft is doing the right thing by supporting the latest featuers (in essense, baiting all the hardware manufactuers to integrate these features) but it *does* make DirectX unsuitable for pro use.
In general when comparing archtectures, then yes, some architectures are better than others at some things... but the x86 is CRAP AT EVERYTHING. IT SUCKS. IT HAS ALWAYS SUCKED.
>>>>>>>>>
I wouldn't go that far. It sound like trolling to me.
It is register starved, has a crappy "grown" CISC instruction set that's a bitch to optimise,
>>>>>
I don't know about GCC, but Intel does a damn good job at it. (Check out Intel C++ 5.0)
has a wierd memory map that, again, is a bitch to optimise, tends to have crappy I/O throughput, cache coherency issues (related to aforementioned instrcution set and memory map),
>>>>>>
What "weird" memory map? I've actually read the whole x86 system designer docs, and the only wierdness is that I/O devices are mapped in at 640K instead of high up where they should be. That and the 4GB virtual address space (think big mmaps) but you can hardly fault it for being 32 bit.
highish latency on task switching
>>>>>>
Only if you use the standard TSS system (which nobody does). Plus, it has lots of optimizations (like global PTEs and delayed saving of the FP/SSE registers) that make task-switching quite speedy. Plus, from the (admittedly old) lmbench benchmarks, Linux 1.3 on x86 context switches faster than any other OS on any other platform. (www.bitmover.com/lmbench, I think). Plus, QNX manages to get. 4.5 microsecond task switches on Pentium-class processors, so I doubt x86 task switching is THAT slow.
(well... that depends on how enamoured you are of memory protection, of course - see AmigaOS/AROS on x86 for near-minimal latenncy, with no mem-protection...) and is JUST CRAP.
>>>>>>>>>
QNX does memory protection (as does Linux;)
Basically, for a given MHz rating, the x86 will always come out slowest, no matter what test you do. Except running x86 binaries, of course...
>>>>>>
Actually, the P4 runs SSE ops *really* fast.
Thanks to Open Source, I can now happily use Linux on PPC and ARM boxes, and there's finally some nice, cheap PPC MoBos that aren't apple coming onto the market.
>>>>>>>
So you want to pay more to get less functionality?
Seriously, x86 doesn't suck as much as you think it does. Intel and AMD have invested a huge amount of money in improving the architecture, and even if it is often slower in instructions per clock, the sheer clockspeed of x86 chips often make them outperform their competitors. Plus, they have great price/performance ratio.
Check this 4 CPU Intel vs the 1 CPU Sun considering plain speed...
>>>>>>>>>
I believe it says Pentium 4 as in the "Pentium 4," not 4 Pentium CPUs;) The P4 doesn't do SMP yet, so the comparison is even.
CINT2000: Intel Corporation Intel D850GB motherboard(1.5 GHz, Pentium 4 processor) - 536 524
CFP2000: Intel Corporation Intel D850GB motherboard(1.5 GHz, Pentium 4 processor) - 558 549
CINT2000: Sun Microsystems Sun Blade 1000 Model 1900 - 467 438
CFP2000: Sun Microsystems Sun Blade 1000 Model 1900 - 482 427
CINT2000: Advanced Micro Devices Tyan Thunder K7 Motherboard, 1.2GHz Athlon MP Processor - 522 495
CFP2000: Advanced Micro Devices Tyan Thunder K7 Motherboard, 1.2GHz Athlon MP Processor - 481 433
>>>>>>>>>>
So you just proved that the P4 chop-shops the UltraSparc in SPEC...
Throughput on the Sun with 2 CPU, but strangely enough, none for any Intel hardware. Throw a 2 CPU AMD in there, though...
>>>>>>>>>
Again, P4 doesn't do SMP, but Athlon does.
CINT2000 rate: Sun Microsystems Sun Blade 1000 Model 2900 - 10.7 9.97
CFP2000 rate: Sun Microsystems Sun Blade 1000 Model 2900 - 10.2 9.09
CINT2000 rate: Advanced Micro Devic Tyan Thunder K7 Motherboard, 1.2GHz 2CPU - 10.8 11.1
CFP2000 rate: Advanced Micro Devic Tyan Thunder K7 Motherboard, 1.2GHz 2CPU - 8.30 9.14
>>>>>>>>
So, the dual CPU athlon beats the UltraSparc in SPEC as well.
Really? Empirically, NVIDIA's graphics drivers are the best out there, quality-wise. They've never frozen on my machine (the GF2/3s might be different) and they have by far the best OpenGL support of any consumer cards.
Actually, NVIDIA has been consistantly making quality hardware for years now. Just as you don't expect a reliable company like Intel to produce buggy chipsets, you don't expect NVIDIA to produce buggy products either. It sometimes does happen (Pentium FDIV and i820) but not often enough to get cynical about.
Actually, you won't see many procs still selling that are slower than a 1.1 GHz PIII. The minimum specs for a $1000 machine are 1GHz Athlon (significantly faster than the 1.1GHz PIII for most things). And this is at CompUSA, which overcharges like hell. If you compare Gateway's comps to Apple's comps, you'll find that you get a much faster CPU (1.4 GHz Athlon vs 733 Mhz G4, for example), about double the RAM, a significantly better graphics card (Radeon 64MB vs GeForce MX, for example) and similar support and warrenties. At the high end, the $3500 (does't appear to include monitor) that you have to shell out for a basic dual G4 800 is easily enough to build a dual Athlon 1.2 GHz machine with tons of RAM, IDE RAID, GeForce3 graphics, and Klipsch 4.1 speakers. Face it, Apple's computers may be good in many ways, but they are underperforms that are overpriced.
True, but these things will fall into place. I have a serious doubt that they won't for BeOS. I would like nothing more than to slap BeOS back on my drive and then see if the Windows CD melts quickly, or slowly. But I don't see that happening too soon.
1. It really isnt a UNIX like OS. Not that there's anything wrong with that, but I like UNIX.
>>>>>>>
Neither is Linux. Of course, they're both POSIX complient.
2. No text console.
>>>>>>>>>>
Didn't you see the terminal in the screenshot?
3. Everything in the kernel, particularly video drivers and GUI. That's a bad design. PC video hardware is too crappy to stake your OSes reliability on them or the video drivers.
>>>>>>>>>>
Did you bother to read the documentation?!! The thing is a hybrid-type kernel, and has an app_server that does the GUI bit. If the low level architecture is anything like BeOS's (it doesn't say exactly) then it should run the bulk of the video driver in the context of the app_server, and then use a kernel driver to bang interrupts and registers and whatnot.
AtheOS seems to have a lot of potential. The code looks nice and clean, but drivers are iffy. Even basic things like the IDE driver is fairly immature, and vid card support is almost non-existant. So if you have some development time, instead of coding another abstraction on top of X, please contribute to this worthy project.
PS> Why do windowing system designers never use the X11 driver API as their standard, so drivers can be ported easily? It's not *that* bad!
Slashdot Mirror
Apparently, GCC 3.0 is quite a dissapointment for most people. It really doesn't compile faster, it really doesn't produce faster code. It is *very* standard complient, but standards complience cannot be a compiler's only feature. Luckily, Intel C++ is being ported to Linux. Hopefully Intel does something smart and releases 'icl' in a form that's usable to the community. Since many users compile their software themselves, god knows a $400 compiler won't fly very well in the Linux market.
Okay, I'll buy the bait. Win2K never crashes. It has yet to crash on me, even though I brutalize it with crappy programs (for example, InteractiveC). Of course, this is just my personal experience, so it doesn't matter much. On the other hand your little point is also personal experience, and similarly doesn't matter much. What counts is the fact that the majority consensus on the net is that Win2K is very stable (read through some non-Slashdot newsgroups). Maybe not as stable as Linux, but quite usably so. If it is unstable for you, than by all means use something better. However, don't pretend that just because it doesn't work for you that it doesn't work for everyone else.
Of course not! It was a tech demo to show the geometry capabilities of the GF3. Of course it can't do all of the rendering techniques that they did in the film. If they could, the damn thing wouldn't have taken nearly as long to release! Honestly, what kind of question is this? Do you EXPECT them to provide that level of quality?
1.5 million verticies/2.5 fps, gives about 600,000 verticies per frame. Since the average human has less than 100K hairs, it works out. So what exactly is wrong with their math? Of course the Geforce3 doesn't render at 2000x1600 at full quality (it can't since it doesn't do a lot of the rendering techniques) but that level of geometry is still pretty damn impressive for a sub-500 dollar vid card.
Didn't you mean "sexclusive?"
Yes, XFree86 will happily detect modes that it supports. Unfortunately, these seem to be the standard VESA modes, so it will not detect modes like 1152x864 @ 85 Hz (which is what I run my monitor at). It defaults to the same res at 75Hz instead (which gives me a headache). In fact, I usually end up stealing the modelines of a BeOS machine, since BeOS does indeed detect the more strenuous modes correctly.
BTW> I was running XFree86 4.1 on Gentoo RC5.
Well, I look at you're message and see that you obviously lack the ability to follow an arguement. The guy who posted before me asked asked why an OEM should care what the hell software is on the CD. I said because sometimes the software is not compatible with mainstream OSs, which makes it harder to sell to stores. Obviously you missed the concept that an arguement can have subsections that are broader than the core issue.
.sig issue, I don't make fun of you for using an OS that lacks basic plug and play features (XFree can't detect non VESA monitor modes such as 1152x864 @ 85 Hz without resorting to modelines) so you don't make fun of me for using an OS that lacks a decent POSIX API.
As for the
The OEM agent has to sell the software to stores, no? Some don't want to deal with the added hassle of selling alternative software.
You still haven't said what prevents NVIDIA and ATI and the ARB from sitting at the table and coming up with an uniform API for such an extension.
>>>>>>>>
When they do, I'll be impressed. But they show no signs of it thus far. And I'll tell you what prevents them from working together: human arrogance, plain and simple.
Last time your cried, just like know, that the "hardware" is too different.
>>>
Care to cite that?
Bullshit. Direct3D is no better. You just have to decide on a freaking API and let the vendors implement that. Read elsewhere in this discussion about programmers not supporting DirectX N yet. How's that better than OpenGL's extension mechanism?
>>>>>>>
Because there are only two versions of DirectX ever in use. The current version, which is used by games already on the shelf (that would be 7.0) and the new version that is being used in games that are in development (that would be 8.0). Plus, DirectX is fully backwards compatible, which can't be said for all OpenGL extensions.
It's not better. You still have to rewrite stuff.
>>>>>>>>
No you don't. If you go from DirectX 7.0 to DirectX 8.0, you have to rewrite 0 lines of code, since they are 100% backwards compatible. To go from NVIDIA's extension to ATI's extension, you might have to rewrite a good bit of code, depending on the exact semantics of the extension.
The only difference is that some companies that will remain unnamed have placed stupid patents arround interfaces, not features, interfaces and other companies have to come up and implement their own.
>>>>>>>>>>>
You hit the nail on the head! "Interfaces, not features!" That's what OpenGL's extension mechanism misses. Two features with different interfaces might as well be two different features. With DirectX, every feature has exactly (1) interface, DirectX's. Not the same is true for OpenGL.
If you want to bitch at someone, bitch at the companies that patent interfaces and stop trolling about OpenGL not supporting current technology.
>>>>>>>>
OpenGL does support coherent technology, just not in a sane way. Extensions are bad design. Game developers don't like them, and users don't like them. They only people who like extensions are hardware manufacturers, because it allows them to lock people into using their products.
And this is a good thing? First, you can't just assume that everyone will copy NVIDIA's extensions and just use them blindly. Second, NVIDIA deciding OpenGL's extensions is a *good* thing? What if they decide to pull intellectual property? (Not that I'm accusing them, but they have the power to). At least with DirectX, its the game developers who decide what the API looks like.
I've programmed both, and I find DirectX to be *much* more powerful. For example, in DirectX you can render to a texture. Unless you dig up some SGI extension, you can't do the same in OpenGL. The problem is that while the core DirectX feature set will work on any card, specific extensions won't. The reason that DirectX doesn't have the same problem is that MS actively integrates new features into the core set. Meanwhile, OpenGL hasn't changed that much since 1.1. Let me give you a concrete example. Take this pixel shader thing. NVIDIA has a pixel shader implementation, and ATI has one. On OpenGL, they are exposed through different extensions. Thus, a developer must code for both extensions. In DirectX, they just have to write to the Pixel shader API. If Matrox comes along, they support the DirectX pixel shader API, but release a matrox-specific OpenGL extension. OpenGL developers now have 3 APIs to contend with, DirectX developers still have one. Eventually, the ARB gets around to making pixel shaders a standard extension, but in the meantime, the next big feature has come. Lather, rinse, and repeat.
Most of the DirectX -> OpenGL ports aren't that great. UT, for example, runs beter on Windows than on Linux. (Given that the lead programmer for the project has publicly dissed OpenGL, I'm not surprised). Plus, the ones that are there are ported are from pretty substantial companies. Besides, are you saying that more DirectX games is a *good* thing?
Obviously someone who has now clue how DirectX is designed! The DirectX team doesn't get led around by NVIDIA. The vast majority of the new features in DirectX get there because game developers want them. MS doesn't go into a room with NVIDIA and then send a DirectX release out. Instead, hardware vendors talk about what features they are thinking of putting in, software developers then ask for features that should be put in, and it goes back and forth until another DirectX comes out. Microsoft has some incredibly arrogant and stupid practices, but for a long time, I've had a hunch that the DirectX team wasn't part of the core MS culture. For example, they don't go to absurd lengths to make every single piece of a code a full-blown COMponent that can be remotely marshalled. DirectX's implementation of COM is so simplistic, I'm sure they got heat for it from the abstraction-obsessed Win32 guys.
This story actually gives me a chance to bitch about OpenGL! None of these new features are a part of the standard OpenGL. "Extensions! Extensions!" you shout. However, due to the differences between hardware, you'll end up with ATI and NVIDIA versions of the same extensions, since the ARB won't touch such new/untested features. This makes sense in the pro segment, where hardware is slow to evolve, but in the consumer segment, it will make the API seem antiquated. Plus, the extension mechanism isn't even suited to such uses anyway, since it was meant to expose features, not radically different methods of rendering. And yes, these are radically different. Part of the reason that the GeForce3 has 57 million transistors is that it has to have a standard geometry engine for DirectX 7 and a new vertex shader-based geometry engine.
In the long run, this will make OpenGL unpopular with game developers. Sure guys like Carmack and afford to suck it in and develop to all the extensions, but for a small development house that wants to make an impressive game, they'll go with DirectX to save themselves the development costs. And when they do, there goes the possibility of a native Linux port.
Now there are two solutions to this. First, the ARB could get off their asses and start integrating extensions. This could be problemetic for the pro segment, which wants a stable API. On the other hand, the ARB could fork OpenGL into a pro and a consumer version, but that results in two incompatible APIs. I think Microsoft is doing the right thing by supporting the latest featuers (in essense, baiting all the hardware manufactuers to integrate these features) but it *does* make DirectX unsuitable for pro use.
In general when comparing archtectures, then yes, some architectures are better than others at some things... but the x86 is CRAP AT EVERYTHING. IT SUCKS. IT HAS ALWAYS SUCKED.
;)
>>>>>>>>>
I wouldn't go that far. It sound like trolling to me.
It is register starved, has a crappy "grown" CISC instruction set that's a bitch to optimise,
>>>>>
I don't know about GCC, but Intel does a damn good job at it. (Check out Intel C++ 5.0)
has a wierd memory map that, again, is a bitch to optimise, tends to have crappy I/O throughput, cache coherency issues (related to aforementioned instrcution set and memory map),
>>>>>>
What "weird" memory map? I've actually read the whole x86 system designer docs, and the only wierdness is that I/O devices are mapped in at 640K instead of high up where they should be. That and the 4GB virtual address space (think big mmaps) but you can hardly fault it for being 32 bit.
highish latency on task switching
>>>>>>
Only if you use the standard TSS system (which nobody does). Plus, it has lots of optimizations (like global PTEs and delayed saving of the FP/SSE registers) that make task-switching quite speedy. Plus, from the (admittedly old) lmbench benchmarks, Linux 1.3 on x86 context switches faster than any other OS on any other platform. (www.bitmover.com/lmbench, I think). Plus, QNX manages to get. 4.5 microsecond task switches on Pentium-class processors, so I doubt x86 task switching is THAT slow.
(well... that depends on how enamoured you are of memory protection, of course - see AmigaOS/AROS on x86 for near-minimal latenncy, with no mem-protection...) and is JUST CRAP.
>>>>>>>>>
QNX does memory protection (as does Linux
Basically, for a given MHz rating, the x86 will always come out slowest, no matter what test you do. Except running x86 binaries, of course...
>>>>>>
Actually, the P4 runs SSE ops *really* fast.
Thanks to Open Source, I can now happily use Linux on PPC and ARM boxes, and there's finally some nice, cheap PPC MoBos that aren't apple coming onto the market.
>>>>>>>
So you want to pay more to get less functionality?
Seriously, x86 doesn't suck as much as you think it does. Intel and AMD have invested a huge amount of money in improving the architecture, and even if it is often slower in instructions per clock, the sheer clockspeed of x86 chips often make them outperform their competitors. Plus, they have great price/performance ratio.
Check this 4 CPU Intel vs the 1 CPU Sun considering plain speed... ;) The P4 doesn't do SMP yet, so the comparison is even.
>>>>>>>>>
I believe it says Pentium 4 as in the "Pentium 4," not 4 Pentium CPUs
CINT2000: Intel Corporation Intel D850GB motherboard(1.5 GHz, Pentium 4 processor) - 536 524
CFP2000: Intel Corporation Intel D850GB motherboard(1.5 GHz, Pentium 4 processor) - 558 549
CINT2000: Sun Microsystems Sun Blade 1000 Model 1900 - 467 438
CFP2000: Sun Microsystems Sun Blade 1000 Model 1900 - 482 427
CINT2000: Advanced Micro Devices Tyan Thunder K7 Motherboard, 1.2GHz Athlon MP Processor - 522 495
CFP2000: Advanced Micro Devices Tyan Thunder K7 Motherboard, 1.2GHz Athlon MP Processor - 481 433
>>>>>>>>>>
So you just proved that the P4 chop-shops the UltraSparc in SPEC...
Throughput on the Sun with 2 CPU, but strangely enough, none for any Intel hardware. Throw a 2 CPU AMD in there, though...
>>>>>>>>>
Again, P4 doesn't do SMP, but Athlon does.
CINT2000 rate: Sun Microsystems Sun Blade 1000 Model 2900 - 10.7 9.97
CFP2000 rate: Sun Microsystems Sun Blade 1000 Model 2900 - 10.2 9.09
CINT2000 rate: Advanced Micro Devic Tyan Thunder K7 Motherboard, 1.2GHz 2CPU - 10.8 11.1
CFP2000 rate: Advanced Micro Devic Tyan Thunder K7 Motherboard, 1.2GHz 2CPU - 8.30 9.14
>>>>>>>>
So, the dual CPU athlon beats the UltraSparc in SPEC as well.
Avoid showing data that refutes you claims...
Linux or Windows 2000? Because there are SMP problems on Linux, but I haven't heard of any on Windows.
Really? Empirically, NVIDIA's graphics drivers are the best out there, quality-wise. They've never frozen on my machine (the GF2/3s might be different) and they have by far the best OpenGL support of any consumer cards.
Actually, NVIDIA has been consistantly making quality hardware for years now. Just as you don't expect a reliable company like Intel to produce buggy chipsets, you don't expect NVIDIA to produce buggy products either. It sometimes does happen (Pentium FDIV and i820) but not often enough to get cynical about.
Actually, you won't see many procs still selling that are slower than a 1.1 GHz PIII. The minimum specs for a $1000 machine are 1GHz Athlon (significantly faster than the 1.1GHz PIII for most things). And this is at CompUSA, which overcharges like hell. If you compare Gateway's comps to Apple's comps, you'll find that you get a much faster CPU (1.4 GHz Athlon vs 733 Mhz G4, for example), about double the RAM, a significantly better graphics card (Radeon 64MB vs GeForce MX, for example) and similar support and warrenties. At the high end, the $3500 (does't appear to include monitor) that you have to shell out for a basic dual G4 800 is easily enough to build a dual Athlon 1.2 GHz machine with tons of RAM, IDE RAID, GeForce3 graphics, and Klipsch 4.1 speakers. Face it, Apple's computers may be good in many ways, but they are underperforms that are overpriced.
How is this flamebait? Seems like quite a good summery of the respective respectibilities of the two companies!
True, but these things will fall into place. I have a serious doubt that they won't for BeOS. I would like nothing more than to slap BeOS back on my drive and then see if the Windows CD melts quickly, or slowly. But I don't see that happening too soon.
No, "illiterate" means not being able to spell "multifaceted."
PS> No offense, of course.
1. It really isnt a UNIX like OS. Not that there's anything wrong with that, but I like UNIX.
>>>>>>>
Neither is Linux. Of course, they're both POSIX complient.
2. No text console.
>>>>>>>>>>
Didn't you see the terminal in the screenshot?
3. Everything in the kernel, particularly video drivers and GUI. That's a bad design. PC video hardware is too crappy to stake your OSes reliability on them or the video drivers.
>>>>>>>>>>
Did you bother to read the documentation?!! The thing is a hybrid-type kernel, and has an app_server that does the GUI bit. If the low level architecture is anything like BeOS's (it doesn't say exactly) then it should run the bulk of the video driver in the context of the app_server, and then use a kernel driver to bang interrupts and registers and whatnot.
AtheOS seems to have a lot of potential. The code looks nice and clean, but drivers are iffy. Even basic things like the IDE driver is fairly immature, and vid card support is almost non-existant. So if you have some development time, instead of coding another abstraction on top of X, please contribute to this worthy project.
PS> Why do windowing system designers never use the X11 driver API as their standard, so drivers can be ported easily? It's not *that* bad!