Population equaled power a hundred years ago. Now its more of a nuisance than anything else. The problem is that the tax base doesn't grow proprotional to the population, since much of it is tax-exempt. Bangladesgh, for example (a small country next to India) tax-expempts 90% of its population of 120 million. If that population was around 20 million (appropriate for a country of that size) then the tax base wouldn't be smaller, and might even be larger because the average wealth of people would increase. That's why organizations like USAID (US deparment for foreign development) are working to spread birth control to third world countries.
PS> A funny tidbit. The US maintains several Pentium II computers each connected to its own private T-1 line to track US condom shipments to foreign countries.
First, with you're hypothetical case, you're wrong. The driver writer doesn't have to implement this in software, he just returns a capabilities structure without support for this feature. Since Direct3D interfaces are immutable, old games won't notice this change, and new games will simply detect the lack of the feature and compensate accordingly. Sure it requires two cases, but it requires ONLY two cases. In the same situation, OpenGL requires a *minimum* of two cases.
In reference to extensions, you miss my point. You are equating extensions with features. That's not right. Extensions, in the real world, are one implementation of a feature. OpenGL requires you to support each extension seperately, even if they refer to the same feature. Let's try a concrete example. NVIDIA has an extension called GL_NV_fog_distance. Its functionality is not supported by any of the GL_EXT extensions, so a game developer uses this extension directly. Let's say ATI releases a new card that also supports the functionality of GL_NV_fog_distance. Since they won't (and probably can't) use NV's extension, they go ahead and make their own GL_ATI_fog_distance extension. Then Matrox comes along. There still isn't a GL_EXT_fog_distance, so they make their own GL_MATROX_fog_distance extension. Now, you the hapless game developer must support each of the three extensions seperately, plus handle the no hardware support case. If you were a DirectX developer, you would only have to handle two cases, the hardware supported, and hardware unsupported case. Now lets say this game ships, with support for the three major extensions. Now, PowerVR releases the Kyro II, with its own GL_PVR_fog_distance extension. Now you, the game owner, own this game and a Kyro II. With OpenGL, you have to wait for the game developer to patch his product, or live without support for this feature in your game, even though your hardware supports it. If you were using DirectX, PowerVR would have implemented support for the IDirect3D8->FogDistance() function, and you're game would have automatically taken advantage of it, no matter which card you used. Think of DirectX features as mandatory OpenGL extensions. HW makers either implement the DirectX API calls for a feature, or don't expose the feature at all. That allows all games to use the DirectX API, and assume that any supported features will be exposed through this single set of calls.
...
Somewhat different to this fictive "uniform hardware" you imply DirectX supports.
>>>>>>
You have to make the difference between an extensions and a feature. If a DirectX card doesn't support a feature, it will simply return a capabilities structure that says that feature is unavailable. If it *does* support the feature, then the app can use the standard API without worrying about what card the feature is implemented on. In OpenGL, the game not only has to be concerned about whether the feature is supported, but has to worry about how the vendor chose to expose that feature. Again, its a matter of two codepaths (which will always be present as long as hardware supports different features) or a minimum of two code paths (which isn't necessary if all implementations of a feature are forced to use the same API to access that feature, as is required with DirectX).
What you are saying is that it's good to have an API that "gets fixed" every year.
>>>>>>>>>
In that statement you show your grognard roots. It doesn't get "fixed" every year, its been great since 6.0. It evolves every year. It supports new features and technologies that didn't exist the year before. NVIDIA's product generation is one year, with a refresh cycle every six months. If the API cannot keep up with the pace setter of the graphics industry (and OpenGL can't) then it has some problems in its development model that need to be addressed.
Wow. That's a good thing?
>>>>>>>>>>
Yes, support for new features and new hardware IS a good thing.
With DirectX (and in particular, with Direct3D) that's doable. Why? There's one implementation.
>>>>>>>>
That's false. With DirectX 8.0, drivers are nearly as full an implementation as an OpenGL one. Read the article in MaximumPC magazine with the Matrox driver engineers (might be floating around on the 'net too.) It tells how OpenGL and DirectX drivers compare in terms of implementation complexity. Besides, that doesn't make a difference. In DirectX there is *one* API that manufacturers are forced to code for. ATI's driver, NVIDIA's driver, Matrox's driver, all of them use the same exact API. All of them expose vertex skinning through the same calls, pixel shading through the same calls, low-level resource management through the same calls. OpenGL doesn't have *one* API. Each card is allowed to expose major features through extensions. That's a *bad* thing. That means a game developer can't rely on all hardware being the same (as one can with DirectX) but must look at specific models. DirectX is a capabilities-based system. The game developer looks to see if the card supports vertex-skinning. If it does, it uses a standard vertex skinning API. This is a *good* thing. OpenGL's extension mechanism is manfacturer based. The game developer looks to see if a card supports a particular extension and uses that. Because of this, you end up with a game that supports hardware vertex-skinning running on a card that supports hardware vertex-skinning that doesn't run accelerated because the card's manufacturer wasn't important enough for the game developer to pay attention to. Unless OpenGL supports these features in the core standard (or releases ARB extensions quickly so manfacturers don't invent their own) then this situation will continue to hurt the consumer. Look, extensions for consumer-level API's is a bad idea. Microsoft tried to make DirectX extendible because it makes their job easier. They got rejected because game-developers hated extensions; it is too much a pain in the ass for them to deal with them.
DirectX is not a standard.
>>>>>>>>
Programatically, DirectX IS a standard. If I'm running a DirectX 8.0 complient system, there are a set of API calls and services that I can count on being available. In this respect, it is OpenGL that is not a standard. If I'm running DirectX 8.0 and it says that hardware-vertex skinning is available, I can just go use the standard API for it. Under OpenGL, I have to use non-standard vendor-specific APIs to access this functionality. Again, extensions were a good idea when only one or two were needed on a given implementation. Now, with over a dozen extensions for a given card, it is hard to call OpenGL a "true" standard.
No, it doesn't. It adds stages to the pipeline. You can still do traditional T&L with DX8.
>>>>>>>>>
Yea, you can, but why buy a card with vertex shaders if you can't make full use of them? Without several extensions, OpenGL *can't* make full use of vertex shaders, and the extensions vendors will come up with to allow OpenGL to do so will be propriatory and card specific. That means that OpenGL games will be behind the curve in supporting the latest features and that unless you buy from NVIDIA, it is likely that your're hardware will expose extensions that game developers didn't code for. OpenGL wasn't meant for the consumer graphics industry, it was meant for the pro graphics industry. In that industry, companies come up with majorly different hardware every half decade or so, and it is acceptable to only make new OpenGL releases every several years, with extensions filling in small additions inbetween. In the consumer graphics industry, however, major changes come every year, or even sooner if vendors' schedules overlap. In that market, it is not acceptable to only release new versions every several years. OpenGL is trying to adapt to the quickly changing market by using extensions to implement major functionality. Extensions just weren't designed to do that. If you want to take full advantage of an NVIDIA card, you have to code specifically for well over a dozen extensions. At that point, you're so close to writing card-specific code, that OpenGL can't be called a "standard."
And, BTW, you assume I have an NVIDIA card. I don't. The OpenGL implementation I use just happens to
support some GL_NV extensions. It's a very different thing.
>>>>>>>>>>>
It might support some GL_NV extensions, but those are ones that are well-established (read: old). I can guarentee you that it doesn't support any of NVIDIA's new extensions. The fact remains, that extensions are rarely implemented across the industry. Expecting manufacturers to use other company's extensions is like expecting them to use a consistant hardware standard without being forced too. Its just not realistic. At the end of the day, if you're a game developer, you have two options. You can go with OpenGL, and get the support of alternative OSs (whoop de doo), and then deal with supporting dozens of different extensions, or you could go with Direct3D, lose the alternative OS support, and lose the headache of supporting vendor specific code. If you're a consumer, you can buy an OpenGL game (which is the only option for alternative OS users) and live with the fact that you're PowerVR card will have a bunch of unsupported features, or buy a DirectX game and be assured that you're experience will only be limited by the quality of your drivers, not how big-name your card manufacturer is.
Then howcome the OpenGL implementation I use lists some non-trivial ammount of non ARB non EXT extensions? But don't take my word for it:
>>>>>>>>>>>>>
So does mine. My NVIDIA card lists a whole bunch of NV extensions. ATI cards list a whole bunch of ATI-specific extensions.
The fact that the extension is called GL_NV_foo doesn't mean, alone, that it can't be implemented by other vendors.
>>>>>>>>>>
But it does mean that vendors aren't FORCED to implement a particular extension. Say DirectX 8.0 adds vertex shader support. Since NVIDIA cards have vertex shaders, they implement this part of the API. ATI comes along with a card that features vertex shaders, and thus they implement the API too. Now, a game developer can just write to the DirectX API, and every piece of hardware that implements that API (ie. every piece of hardware that has vertex shaders; it would be stupid to have the feature and not expose it) gets accelerated. The OpenGL version of this story is different. NVIDIA releases the GeForce3 with NV_vertex_shader extensions. ATI comes along, can't use the existing extension, and makes its own ATI_vertex_shader extension. Now a game developer must detect each extension, and adjust his code path appropriatly. The burden of supporting different harware shifts from the hardware makers themselves, to the game developer. The API's integrity is weakened, and consumers who have cards that support a feature, but aren't popular enough for the game developers to code for, lose out. The world comes to an end. This could easily have been averted if
A) The ARB would release another version of OpenGL that supports these features. This is the optimal method because it allows these features to be more well-integrated. This is especially important for something like vertex or pixel shaders, because they fundementally change the 3D pipeline. And before you say that it would lead to uncontrolled releases, take a look at how MS does it. They talk to game developers and ask what features they want. They talk to hardware manufacturers and ask what features they're working on. They combine this input and come up with a new API every year or so. MS does a lot of things wrong, but this ain't one of them.
B) The ARB does the same MS-type going around, and implements standard extensions before hardware manufacturers get around to releasing their own. Thus, the ARB_vertex_shader extension would be out, and both ATI and NVIDIA would use it.
In fact, other vendors are encouraged to implement those extensions. The problem is they can not do it without entering into an IP problem. You can get a license and blah blah blah, but that's not the point. The point is why is there are patent in the first place? Afraid someone comes up with a better idea, uh?
>>>>>>>>>>>>>>>
Company's are like that. You can't do ivory-tower design, you have to adapt to how people work and think. The ARB's system doesn't do that.
OpenGL has to be extended... funny, that sounds awfully like extensions to me, doesn't it? The one thing you can't do with extensions is changing the order of the pipeline. Your triangles will be transformed before they are discarded by a depth test. You can turn things on and off, but you can't change the order of the pipeline. Other than that, you are pretty much free to do whatever you want.
>>>>>>>>>>>
You don't understand. Stuff like vertex shaders DO change the order of the pipeline! The move vertecies through a set of mathematical experession before sending them to be rasterized. I suppose this could be crudely emulated through the transform matrix, but with that you lose a lot of the features of vertex shading (such as the ability to filter verticies and implement different transforms on them). Also, it hides the uploading of experessions to the shader, which would kill performance. As for your comment about extensions, you miss the point. Extensions (for most cases) can do the job. The problem is that extensions are not standard parts of the API. This fragments the API (you *NIX guys call it diversity) and gives developers and consumers headaches. Like I said, if the ARB would be proactive in implementing ARB or EXT extensions, or if the ARB would be more frequent with its OpenGL releases, and implement these features into new releases, OpenGL could keep up, feature-wise, with DirectX. With the state of affairs as it is, it simply can't.
I've looked at SDL before, and I just looked at the site for Allegro. Neither of them is in the same league as DirectX. Just read the docs for each. There is so much that SDL and Allegro just don't do.
Yes it does, if you knew anything about DirectX. Because there were so many layers of abstraction under Win32, game makers used DOS. However, they had to create dozens of hardware-specific drivers since DOS doesn't support advanced functionality. DirectX allowed vendors to get the performance of DOS, and the hardware abstraction of Windows. FYI, DirectX had the following design goals:
A) Be thin and fast: Meet or exceed the performance of DOS.
B) Be flexible: Take advantage of hardware acceleration whenever possible, emulate when not. Support hardware features quickly, and provide new emulated features that provide a carrot for hardware manufacturers to implement these new features in next-gen hardware.
C) Be humble: Stay out of the developer's way, don't impose any artifical constraints on game design.
First, there is a lot more the DirectX than just D3D. DirectInput is the most complete input API on the planet, DirectSound is a very good sound API, and DirectMusic blows everything else out of the water (except maybe Be's media kit, but that isn't meant for games:( DirectPlay is great because it is protocol independant, and DirectShow/etc is great because it takes full advantage of video hardware.
Second, D3D *is* more complicated than OpenGL, but that's because its so much more powerful. It allows to to manage the nitty-gritty aspects of the graphics pipeline that OpenGL abstracts away. For example, OpenGL doesn't even give you control over the uploading of texture or allocation of vertex buffers without using (sometimes unavailable) extensions. Also, D3D these days is much more feature filled and power than OpenGL (unless you count prorietory extension's like NVIDIA's or ATI's, which, FYI are not compatible with each other). Lastly, D3D 8.0 seems to be a hair faster than OpenGL (again, the cost of abstraction) a well.
DirectX is probably the single best thing about Windows, and it's actually one damned good game developement API.
>>>>>>>>>>>
Amen to that my DX brotha'!
Actually, I kinda wish somebody would implement something like DirectX for Linux. Its a shame such good technology is tied to Windows.
Hell, no! If you are going to improve on DirectX, improve it on every platform. This "special feature" is exactly the kind of crap NVIDIA pulls with their OpenGL extensions.
>>>>>>>>>>
Hey, don't blame this on NVIDIA. ATI does it too. The reason they have to do this is because OpenGL doesn't implement any cool features in the core API. Because Microsoft works with vendors to release a new version of DirectX every year or so, it supports the latest technologies. Meanwhile, it takes up to 6 months after a feature becomes common in hardware for it to show up as a standard OpenGL extension. If you don't like this state of affairs, go kick the ARB in the ass and ask them to improve OpenGL rather than blame NVIDIA, who is simply trying to work past OpenGL's limitations.
Win32 isn't entirely irrelevant in this discussion. Firstly, DirectX objects are just a subset of the set of all possible COM objects. If you're going to reproduce DirectX on a system, you'll have to reproduce OLE (at least to some degree.) Secondly, several games programmers use the ->GetDC() member of the IDirectDrawSurface interface at some spot in their games. When the surface is locked and a device context handle is returned, the program is obviously going to use it in classic GDI calls.
>>>>>>>
I don't know how terribly common the GDI is in *real* games. The GDI is awefully slow, and most games use their own text rendering functions anyway. As far as I can see, the only game that might have some problems with a lack of the GDI might be Unreal, which (I think) uses the GDI to display options dialogues. Besides, this whole thing is running with Wine, so the GDI issue is moot.
Right, and in fact this newest release makes the whole DirectDraw discussion pretty much dead. In any case, the way that COM objects are meant to be designed is that updated interfaces must be queried. Right now, a game might attempt to create the first version of the DirectDraw object: CoCreateInstance(CLSID_DirectDraw, NULL, CLSCTX_INPROC_SERVER, IID_IDirectDraw, (void**)*pdd) and if it fails then the game can abort with a message that the required version of DirectX isn't installed. So long as OLE/COM is supported properly, there won't be any problem with the changes made to DirectX from year to year that Windows machines without the latest libraries won't have too.
>>>>>>>>
I know how DirectX works, its my favorite API to work with. However, my point was that DirectX changes very significantly (particularly between 6.0, 7.0 and 8.0) and it might be too hard for a company to keep up with the changing interfaces. Even if older code works well, it is usually only a matter of a weeks before new games using the latest interfaces come out. They might not be able to keep up with the changing interface.
Who cares? The people who buy the PCs care that they get something well designed. This applies as equally to
Macs as to PCs, to cars. It means more to some than to others, but quality is what people pay for!
>>>>>>>>
I didn't mean who cares about quality, I meant who cares that Apple does it all themselves? People do care about quality, but doing everything in one company does not necessarily bring that quality.
And thus the real question; are you actually acknowledging that Macs are higher quality than PCs?
>>>>>>>>
Depends on what you're talking about. If you're talking build quality and hardware quality, then no, PCs are just as high quality (or more so, depending on the vendor) as Macs. If you're talking about the quality of the architecture, then yes, Macs are more high quality because they don't have to deal with the vargacies of the PC architecture. This doesn't effect stability or reliability, but effects the platform's ease of use.
Still, if the PC has problems because of limitations in the architecture, that's still a problem. Why is it that
Compaq or Dell have not 'engineered' their own solution to overcome these limitations? Macs use the same
AGP and PCI busses, memory busses, USB, Firewire, ATA drive specs, video connectors, etc, so it's possible.
Why is it none of the PC manufacturers have done it yet?
>>>>>>>>>>>>>>>>
You have no idea what you're talking about do you? Sure they use the same hardware, but Macs don't have to deal with software and hardware that assumes there are 16 IRQs with IRQ2 as a cascade. Apple doesn't have to deal with software that expects a sound blaster to be at a particular port address with a particular IRQ and with software that assumes IRQ 5 is the ATA interface. Mac designers don't have to bother with the ISA bus or with a limited number of DMA channels. Mac designers don't have to treat the first meg of memory with great reverence and maek sure that DMA-able memory is under 16MBs so the ISA cards can do DMA. PC hardware manufacturers *can't* fix these issues, there is just too much software that depends on these issues.
Why the heck is Apple stupid? HP uses it's own motherboard (not a stock one from Tyan, MSI, or Intel), though it probably relies on chipsets from Intel or something.
>>>>>>>>>>
Hah! I don't know about HP, but I know that Dell's "engineered" motherboards are simply modified Intel ones. And Compaq used to make their own motherboards, but everybody hated them so they switched to stock ones. As for chipsets, only one company makes its own chipsets, and that is Micron, who uses their own chipsets in their workstations and servers.
By doing this Apple can provide it's own feature set at
the advantage of everyone else.
>>>>>>>>>
Yea, but they also tie users to their motherboards. As I said, everybody hated Compaq's LPX motherboards because their riser cards and cases were proprietory. Everyone also hates Dell's motherboards and power supplies because the power connectors are specific to Dell's motherboards.
Apple was one of the earliest adopters of USB, because it could build it into the system instead of waiting for Intel or Tyan to design the motherboards with USB support.
>>>>>>>>
But does Apple let other companys make Apple compatible chipsets? AMD made their own chipset as well to add features for the K7 platform, but allowed other companys to take over the K7 chipset market as the platform matured. I don't see Apple allowing VIA to make Apple chipsets.
It's called innovation, and it's called leading the pack. They can either wait for someone else to do it, and bundle it, or they can do it themselves!
>>>>>>>>>>>
That's fine. But even after other companies support it, they continue to lock them out. That's called monopolizing the platform!
You're 99% sure? I'm pretty sure than in an Open PPC system, you'd get identical results as today's open PC
system.
>>>>>>>>>>>>
The 99% sure is because, like IBM and their OpenPPC system, somebody might fuck up.
Crap devices with crap drivers and crap systems.
>>>>>>>
It's called a Mac. Crap graphics cards, crap OS, crap hardware.
Don't tell me they don't exist!
>>>>>>>>>
I'm not saying they don't exit because they do. At least with PC's, however, you have the option of not buying crap hardware! Besides, there is crap hardware and crap drivers on every platform, even Apple's. The only advantage the Apple platform has is that it doesn't inherit the limitations of the IBM PC. An OpenPPC platform would inherit these limitations either, and would be better than an Apple system because it was open.
Apple may be the cream of the crop in such a market
>>>>>>
In the crap hardware market? Seriously though, until recently, Apple was the king of crap hardware. Rage II+ graphics chips, Crystal sound chips, too little RAM, 50MHz system busses, the list goes on. Even now that Apple has good hardware (GeForce3's, DDR-SDRAM, etc) its only because manufacturers from the PC industry decided to include Apple in their plans. And they still can't get a decent set of bundled speakers!
but tell me how Apple gets an advantage in an Open system? Apple gets no advantage,
>>>>>>>>>>
That's a good thing for the consumer.
and the users gets one advantage: The ability to choose their own motherboard (that's it! Everything else in a Mac is already standard!)
>>>>>>>>>
No, they get the ability to build their own system. With that comes the ability not know to choose your motherboard, but choose alternate chipsets, mix-and-match parts, and have access to cheaper hardware. Right now, if I buy an Apple, I would have to throw away the entire sound system and replace it with a Live! and a set of Klipschs. I'd have to lose the on board ATA card and install at ATA RAID array. Why bother? With the PC, I can go to a manufacturer that offers these standard (or build my own) and not pay for parts that I don't want.
And do you seriously think there would be a company that build a better motherboard than Apple? If they do,
they should *already* be building better motherboards than Apple today!
>>>>>>>>>>
Yes. Where'd you get the idea that Apple builds the best motherboards in the world? They don't, and because of the closed nature of the Apple platform, nobody is allowed toc compete with them.
Okay, so now we get to the meat of your argument. That the platform is being killed by a non open standard.
>>>>>>>
Actually, I think Apple is bouncing back. I just think a lot more people would use it if they got to have control over their system. I know I would (once the quad 1Ghz G4 mobo's come out, of course;)
Well, 2 things.
Apple *is* the standard.
>>>>>>>>>>
What? Clarify what you mean.
Anyone (Dell, Compaq, etc) can release their own PPC systems if they wanted, but they would need an OS.
Apple, as a business, need not 'give' their OS to a competitor. Think about it.
>>>>>>>>>>>
They could not build a PPC system that would run MacOS. Besides, Apple could sue them. Do you think Dell could clone the Playstation hardware without Sony sueing their asses off? Hell no! I think you need to read up on the definition of "closed platform." Besides, Apple forcing people to buy hardware by withholding their OS is worse than MS's tactics!
Apple sells what it sells, and people buy it. It suits their needs, despite the comparison you bring up. It's stable enough, full featured enough, fast enough, powerful enough.
>>>>>>>>>>>
Ohhh. It's enough. If enough were enough, then mediocrity would be celebrated, not spat upon.
If they weren't, people wouldn't buy Apple. They would buy Compaq, or Dell, or like yourself, build their own
system.
>>>>>>>>>>
People (statistically) DON'T buy Apples.
The platform you speak of is easy to use *because* of everything you point out. That Apple does it's own
hardware and software and drivers
>>>>>>>
You contradict yourself. If Apple does everything themselves (they don't, NVIDIA writes the drivers, Crystal writes the drivers, Adaptec writes the drivers, etc) how can most of the hardware on an Apple be standard? Apple uses mostly PC hardware, but makes their own motherboards and chipsets, and doesn't allow anyone to clone them. The only thing that makes Mac's easier to use (besides the OS, which isn't relevant in this discussion) is the fact that Apple isn't stradled with a two decade old architecture. That's IT. If Dell and Compaq etc all were allowed to make their own versions of the Mac, the Mac would be no less easy to use.
because they have their own OS
>>>>>>>
There OS is easy to use. I'll give you that.
You can't get that *anywhere* else because no one else does it. Microsoft will soon, when they release their XBox, and then you'll have *all* the same arguments against them as you do against Apple!
>>>>>>>>>>>>
Well, both the XBox and the Mac have crappy OSs, so their is one comparison. Still, you're making what we in the psychology world call a "fundmental attribution error." You're attributing the Mac's ease of use to the fact that Apple builds it, not to the quality of the architecture. If the PC didn't have all these IRQs and DMAs and all, then you could still buy chipsets from all over the place, graphics cards from all over the place, etc, and still have a system that's as easy to use as a Mac. (If you buy good hardware, but again, crappy hardware is universal.)
So... You designed your own motherboards and chipsets, wrote your ROM bios code, spec-ed out your capicitors and diodes, pressed your own sheetmetal cases, injection molded your own case-skins, wrote your own firewire spec, then implemented the CMOS for it, and then wrote the drivers for it, designed and built the wireless antennas for your PC, and drafted your own bus specs and implementations?
>>>>>>>>>>>
Who cares? In the PC industry, the people who do these jobs do it as well (or better) than Apple does it. The only reason that the PC's aren't as high-quality as Macs is because of the limitations in the architecture, not bad build quality.
You can create a PC as well as any 'lacky' who throws parts together. You may chose better or worse parts than
any lacky, but when you buy Apple, you buy all of the above, and if you don't want to pay for that, then you
can't get a PPC system.
>>>>>>>>>>>>>>>
A) I don't WANT a PPC system.
B) Apple is stupid for doing all this itself. It hems the customer into using whatever Apple feels they should use, and drives up cost. Build quality isn't drastically improved (I'm 99% sure that an Open PPC system would be just as high quality as the closed Apple system. Besides, the old Apple clones were just as good as real Apples) and the industry hates you for it. Companys hate Intel for sucking it all in and doing their own chipsets, motherboards, CPUs, and graphics cards, and (if Apple becomes big enough to matter) people will hate Apple for the same reasons.
Now I don't contest that a PC you build is stable or reliable; it cannot be denied that a multi-million dollar corp can build crap PCs too.
>>>>>>>>>>>
The PC I built I just as high quality as any Apple machine. With plug & play (and BeOS) adding hardware is just as easy as with an Apple machine. Its cheaper, more powerful, and more well-supported (in terms of replacement hardware). And I'm not too sure of how much Apple cares about product quality. This is the same company that for years shipped systems with graphics cards two generations out of date, system busses two bins too slow, OSs two bits short of stable, and sound hardware that couldn't compete with my kazoo. With $3500 (or less!), I could easily build a 1.33Ghz Athlon PC with 1GB RAM, A GeForce3 (or ATI's upcoming, BeOS supported, Radeon II;), Klipsch 4.1 speakers, 80GB RAID array (4 drives!) and a Sound Blaster Live! card. A Mac user, on the other hand, would have to shell out $3500 for a 733MHz G4 (benchmarks put a $500 Mhz G4 at about the speed of an Athlon 750. I doubt a 733 will clear an Athlon 1.1, much less a 1.3) with a third the RAM, 60GB-non RAID drive, Apple "Pro" speakers, and a no-name sound chip. By the time you bring this anemic thing up to PC standard, the price balloons to well over $5000. PPC seems to be a good platform. Motorola and IBM are getting their act together and releasing 1GHz G4s, which should beat with the fastest x86 chips. The platform has always been easy to use, and with the upcoming DDR-SDRAM chipsets, will be on a speed-parity with the x86 platform. Despite it all, Apple is killing it by keeping it closed.
I wasn't trolling. Linux 2.4 IS a better system than Mach/FreeBSD 3.2. First, Mach is a pretty crappy microkernel. Second, FreeBSD 3.2 is several years out of date, and FreeBSD 4.0 is a much better system. I don't know how Linux 2.4 stands up to FreeBSD 4.0, but I know that they are close, which suggests that 3.2 couldn't compare to Linux 2.4.
Mod this up. This is damn funny! (At least the first part of it.)
BTW> Netscape lost money because its browser sucked ass, not because it gave it away.
PS> Redhat does suck. They're the Linux equivilant of Microsoft. The only thing that saves RedHat is the fact that Linux is so stable and secure to begin with. (And the fact that other people write the code;)
Even Linux From Source. The Linux kernel should have a unified way of handling and configuring hardware, and there should be a standard userspace tool to configure and manage hardware. (Kinda like how kernel-level networking is configured through the userspace program ifconfig.)
I think the prices need to be adjusted. 768k SDSL should be more accurately priced around $250/month
for it to be worth it to these DSL providers.
>>>>>>>>>>>>>>
Uh no. I happen to *like* SDSL for $50.
I don't know how much sense porting OS-X to Linux would make. Altough Linux 2.4 is a much better system than Mach/FreeBSD 3.2, by taking out BSD and Mach, you get rid of much of OS X. Maybe you're thinking of porting Quartz, Aqua, and OpenStep to Linux? In that case, you won't be happy to hear that all of the above are closed source, and thus will not run on x86 unless Apple ports it.
From the Debian About page: "Although Debian is non-profit." Thus, Debian made *no* profit last year. Also, I doubt Linux will ever make much money on the desktop, but I can see them making quite a bit of money in the corporate world, where support costs usually outweigh license costs.
From where? If the 3D model is bigger than RAM, its on the harddrive. If the harddrive transfers at 30MB/sec (at best) and PCI is 100MB/sec (optimal: 133MB/sec) then it does no good to speed up the PCI bus! PCI bus speeds used to matter, but unless you have an >4 drive U160 SCSI RAID array, it really doesn't any more, since the only thing on there is the hard drive and sound card.
Slashdot Mirror
Population equaled power a hundred years ago. Now its more of a nuisance than anything else. The problem is that the tax base doesn't grow proprotional to the population, since much of it is tax-exempt. Bangladesgh, for example (a small country next to India) tax-expempts 90% of its population of 120 million. If that population was around 20 million (appropriate for a country of that size) then the tax base wouldn't be smaller, and might even be larger because the average wealth of people would increase. That's why organizations like USAID (US deparment for foreign development) are working to spread birth control to third world countries.
PS> A funny tidbit. The US maintains several Pentium II computers each connected to its own private T-1 line to track US condom shipments to foreign countries.
Germany and France? That's not the big news. The big news is that nobody has partitioned Poland for more than 50 years! (European History joke ;)
First, with you're hypothetical case, you're wrong. The driver writer doesn't have to implement this in software, he just returns a capabilities structure without support for this feature. Since Direct3D interfaces are immutable, old games won't notice this change, and new games will simply detect the lack of the feature and compensate accordingly. Sure it requires two cases, but it requires ONLY two cases. In the same situation, OpenGL requires a *minimum* of two cases.
In reference to extensions, you miss my point. You are equating extensions with features. That's not right. Extensions, in the real world, are one implementation of a feature. OpenGL requires you to support each extension seperately, even if they refer to the same feature. Let's try a concrete example. NVIDIA has an extension called GL_NV_fog_distance. Its functionality is not supported by any of the GL_EXT extensions, so a game developer uses this extension directly. Let's say ATI releases a new card that also supports the functionality of GL_NV_fog_distance. Since they won't (and probably can't) use NV's extension, they go ahead and make their own GL_ATI_fog_distance extension. Then Matrox comes along. There still isn't a GL_EXT_fog_distance, so they make their own GL_MATROX_fog_distance extension. Now, you the hapless game developer must support each of the three extensions seperately, plus handle the no hardware support case. If you were a DirectX developer, you would only have to handle two cases, the hardware supported, and hardware unsupported case. Now lets say this game ships, with support for the three major extensions. Now, PowerVR releases the Kyro II, with its own GL_PVR_fog_distance extension. Now you, the game owner, own this game and a Kyro II. With OpenGL, you have to wait for the game developer to patch his product, or live without support for this feature in your game, even though your hardware supports it. If you were using DirectX, PowerVR would have implemented support for the IDirect3D8->FogDistance() function, and you're game would have automatically taken advantage of it, no matter which card you used. Think of DirectX features as mandatory OpenGL extensions. HW makers either implement the DirectX API calls for a feature, or don't expose the feature at all. That allows all games to use the DirectX API, and assume that any supported features will be exposed through this single set of calls.
...
Somewhat different to this fictive "uniform hardware" you imply DirectX supports.
>>>>>>
You have to make the difference between an extensions and a feature. If a DirectX card doesn't support a feature, it will simply return a capabilities structure that says that feature is unavailable. If it *does* support the feature, then the app can use the standard API without worrying about what card the feature is implemented on. In OpenGL, the game not only has to be concerned about whether the feature is supported, but has to worry about how the vendor chose to expose that feature. Again, its a matter of two codepaths (which will always be present as long as hardware supports different features) or a minimum of two code paths (which isn't necessary if all implementations of a feature are forced to use the same API to access that feature, as is required with DirectX).
BTW, wouldn't you prefer a good game of chess?
What you are saying is that it's good to have an API that "gets fixed" every year.
>>>>>>>>>
In that statement you show your grognard roots. It doesn't get "fixed" every year, its been great since 6.0. It evolves every year. It supports new features and technologies that didn't exist the year before. NVIDIA's product generation is one year, with a refresh cycle every six months. If the API cannot keep up with the pace setter of the graphics industry (and OpenGL can't) then it has some problems in its development model that need to be addressed.
Wow. That's a good thing?
>>>>>>>>>>
Yes, support for new features and new hardware IS a good thing.
With DirectX (and in particular, with Direct3D) that's doable. Why? There's one implementation.
>>>>>>>>
That's false. With DirectX 8.0, drivers are nearly as full an implementation as an OpenGL one. Read the article in MaximumPC magazine with the Matrox driver engineers (might be floating around on the 'net too.) It tells how OpenGL and DirectX drivers compare in terms of implementation complexity. Besides, that doesn't make a difference. In DirectX there is *one* API that manufacturers are forced to code for. ATI's driver, NVIDIA's driver, Matrox's driver, all of them use the same exact API. All of them expose vertex skinning through the same calls, pixel shading through the same calls, low-level resource management through the same calls. OpenGL doesn't have *one* API. Each card is allowed to expose major features through extensions. That's a *bad* thing. That means a game developer can't rely on all hardware being the same (as one can with DirectX) but must look at specific models. DirectX is a capabilities-based system. The game developer looks to see if the card supports vertex-skinning. If it does, it uses a standard vertex skinning API. This is a *good* thing. OpenGL's extension mechanism is manfacturer based. The game developer looks to see if a card supports a particular extension and uses that. Because of this, you end up with a game that supports hardware vertex-skinning running on a card that supports hardware vertex-skinning that doesn't run accelerated because the card's manufacturer wasn't important enough for the game developer to pay attention to. Unless OpenGL supports these features in the core standard (or releases ARB extensions quickly so manfacturers don't invent their own) then this situation will continue to hurt the consumer. Look, extensions for consumer-level API's is a bad idea. Microsoft tried to make DirectX extendible because it makes their job easier. They got rejected because game-developers hated extensions; it is too much a pain in the ass for them to deal with them.
DirectX is not a standard.
>>>>>>>>
Programatically, DirectX IS a standard. If I'm running a DirectX 8.0 complient system, there are a set of API calls and services that I can count on being available. In this respect, it is OpenGL that is not a standard. If I'm running DirectX 8.0 and it says that hardware-vertex skinning is available, I can just go use the standard API for it. Under OpenGL, I have to use non-standard vendor-specific APIs to access this functionality. Again, extensions were a good idea when only one or two were needed on a given implementation. Now, with over a dozen extensions for a given card, it is hard to call OpenGL a "true" standard.
No, it doesn't. It adds stages to the pipeline. You can still do traditional T&L with DX8.
>>>>>>>>>
Yea, you can, but why buy a card with vertex shaders if you can't make full use of them? Without several extensions, OpenGL *can't* make full use of vertex shaders, and the extensions vendors will come up with to allow OpenGL to do so will be propriatory and card specific. That means that OpenGL games will be behind the curve in supporting the latest features and that unless you buy from NVIDIA, it is likely that your're hardware will expose extensions that game developers didn't code for. OpenGL wasn't meant for the consumer graphics industry, it was meant for the pro graphics industry. In that industry, companies come up with majorly different hardware every half decade or so, and it is acceptable to only make new OpenGL releases every several years, with extensions filling in small additions inbetween. In the consumer graphics industry, however, major changes come every year, or even sooner if vendors' schedules overlap. In that market, it is not acceptable to only release new versions every several years. OpenGL is trying to adapt to the quickly changing market by using extensions to implement major functionality. Extensions just weren't designed to do that. If you want to take full advantage of an NVIDIA card, you have to code specifically for well over a dozen extensions. At that point, you're so close to writing card-specific code, that OpenGL can't be called a "standard."
And, BTW, you assume I have an NVIDIA card. I don't. The OpenGL implementation I use just happens to
support some GL_NV extensions. It's a very different thing.
>>>>>>>>>>>
It might support some GL_NV extensions, but those are ones that are well-established (read: old). I can guarentee you that it doesn't support any of NVIDIA's new extensions. The fact remains, that extensions are rarely implemented across the industry. Expecting manufacturers to use other company's extensions is like expecting them to use a consistant hardware standard without being forced too. Its just not realistic. At the end of the day, if you're a game developer, you have two options. You can go with OpenGL, and get the support of alternative OSs (whoop de doo), and then deal with supporting dozens of different extensions, or you could go with Direct3D, lose the alternative OS support, and lose the headache of supporting vendor specific code. If you're a consumer, you can buy an OpenGL game (which is the only option for alternative OS users) and live with the fact that you're PowerVR card will have a bunch of unsupported features, or buy a DirectX game and be assured that you're experience will only be limited by the quality of your drivers, not how big-name your card manufacturer is.
Running Windows XP? Home edition? Not everything is a *NIX server folks.
Then howcome the OpenGL implementation I use lists some non-trivial ammount of non ARB non EXT extensions? But don't take my word for it:
>>>>>>>>>>>>>
So does mine. My NVIDIA card lists a whole bunch of NV extensions. ATI cards list a whole bunch of ATI-specific extensions.
The fact that the extension is called GL_NV_foo doesn't mean, alone, that it can't be implemented by other vendors.
>>>>>>>>>>
But it does mean that vendors aren't FORCED to implement a particular extension. Say DirectX 8.0 adds vertex shader support. Since NVIDIA cards have vertex shaders, they implement this part of the API. ATI comes along with a card that features vertex shaders, and thus they implement the API too. Now, a game developer can just write to the DirectX API, and every piece of hardware that implements that API (ie. every piece of hardware that has vertex shaders; it would be stupid to have the feature and not expose it) gets accelerated. The OpenGL version of this story is different. NVIDIA releases the GeForce3 with NV_vertex_shader extensions. ATI comes along, can't use the existing extension, and makes its own ATI_vertex_shader extension. Now a game developer must detect each extension, and adjust his code path appropriatly. The burden of supporting different harware shifts from the hardware makers themselves, to the game developer. The API's integrity is weakened, and consumers who have cards that support a feature, but aren't popular enough for the game developers to code for, lose out. The world comes to an end. This could easily have been averted if
A) The ARB would release another version of OpenGL that supports these features. This is the optimal method because it allows these features to be more well-integrated. This is especially important for something like vertex or pixel shaders, because they fundementally change the 3D pipeline. And before you say that it would lead to uncontrolled releases, take a look at how MS does it. They talk to game developers and ask what features they want. They talk to hardware manufacturers and ask what features they're working on. They combine this input and come up with a new API every year or so. MS does a lot of things wrong, but this ain't one of them.
B) The ARB does the same MS-type going around, and implements standard extensions before hardware manufacturers get around to releasing their own. Thus, the ARB_vertex_shader extension would be out, and both ATI and NVIDIA would use it.
In fact, other vendors are encouraged to implement those extensions. The problem is they can not do it without entering into an IP problem. You can get a license and blah blah blah, but that's not the point. The point is why is there are patent in the first place? Afraid someone comes up with a better idea, uh?
>>>>>>>>>>>>>>>
Company's are like that. You can't do ivory-tower design, you have to adapt to how people work and think. The ARB's system doesn't do that.
OpenGL has to be extended... funny, that sounds awfully like extensions to me, doesn't it? The one thing you can't do with extensions is changing the order of the pipeline. Your triangles will be transformed before they are discarded by a depth test. You can turn things on and off, but you can't change the order of the pipeline. Other than that, you are pretty much free to do whatever you want.
>>>>>>>>>>>
You don't understand. Stuff like vertex shaders DO change the order of the pipeline! The move vertecies through a set of mathematical experession before sending them to be rasterized. I suppose this could be crudely emulated through the transform matrix, but with that you lose a lot of the features of vertex shading (such as the ability to filter verticies and implement different transforms on them). Also, it hides the uploading of experessions to the shader, which would kill performance. As for your comment about extensions, you miss the point. Extensions (for most cases) can do the job. The problem is that extensions are not standard parts of the API. This fragments the API (you *NIX guys call it diversity) and gives developers and consumers headaches. Like I said, if the ARB would be proactive in implementing ARB or EXT extensions, or if the ARB would be more frequent with its OpenGL releases, and implement these features into new releases, OpenGL could keep up, feature-wise, with DirectX. With the state of affairs as it is, it simply can't.
I've looked at SDL before, and I just looked at the site for Allegro. Neither of them is in the same league as DirectX. Just read the docs for each. There is so much that SDL and Allegro just don't do.
Yes it does, if you knew anything about DirectX. Because there were so many layers of abstraction under Win32, game makers used DOS. However, they had to create dozens of hardware-specific drivers since DOS doesn't support advanced functionality. DirectX allowed vendors to get the performance of DOS, and the hardware abstraction of Windows. FYI, DirectX had the following design goals:
A) Be thin and fast: Meet or exceed the performance of DOS.
B) Be flexible: Take advantage of hardware acceleration whenever possible, emulate when not. Support hardware features quickly, and provide new emulated features that provide a carrot for hardware manufacturers to implement these new features in next-gen hardware.
C) Be humble: Stay out of the developer's way, don't impose any artifical constraints on game design.
First, there is a lot more the DirectX than just D3D. DirectInput is the most complete input API on the planet, DirectSound is a very good sound API, and DirectMusic blows everything else out of the water (except maybe Be's media kit, but that isn't meant for games :( DirectPlay is great because it is protocol independant, and DirectShow/etc is great because it takes full advantage of video hardware.
Second, D3D *is* more complicated than OpenGL, but that's because its so much more powerful. It allows to to manage the nitty-gritty aspects of the graphics pipeline that OpenGL abstracts away. For example, OpenGL doesn't even give you control over the uploading of texture or allocation of vertex buffers without using (sometimes unavailable) extensions. Also, D3D these days is much more feature filled and power than OpenGL (unless you count prorietory extension's like NVIDIA's or ATI's, which, FYI are not compatible with each other). Lastly, D3D 8.0 seems to be a hair faster than OpenGL (again, the cost of abstraction) a well.
DirectX is probably the single best thing about Windows, and it's actually one damned good game developement API.
>>>>>>>>>>>
Amen to that my DX brotha'!
Actually, I kinda wish somebody would implement something like DirectX for Linux. Its a shame such good technology is tied to Windows.
Hell, no! If you are going to improve on DirectX, improve it on every platform. This "special feature" is exactly the kind of crap NVIDIA pulls with their OpenGL extensions.
>>>>>>>>>>
Hey, don't blame this on NVIDIA. ATI does it too. The reason they have to do this is because OpenGL doesn't implement any cool features in the core API. Because Microsoft works with vendors to release a new version of DirectX every year or so, it supports the latest technologies. Meanwhile, it takes up to 6 months after a feature becomes common in hardware for it to show up as a standard OpenGL extension. If you don't like this state of affairs, go kick the ARB in the ass and ask them to improve OpenGL rather than blame NVIDIA, who is simply trying to work past OpenGL's limitations.
Win32 isn't entirely irrelevant in this discussion. Firstly, DirectX objects are just a subset of the set of all possible COM objects. If you're going to reproduce DirectX on a system, you'll have to reproduce OLE (at least to some degree.) Secondly, several games programmers use the ->GetDC() member of the IDirectDrawSurface interface at some spot in their games. When the surface is locked and a device context handle is returned, the program is obviously going to use it in classic GDI calls.
>>>>>>>
I don't know how terribly common the GDI is in *real* games. The GDI is awefully slow, and most games use their own text rendering functions anyway. As far as I can see, the only game that might have some problems with a lack of the GDI might be Unreal, which (I think) uses the GDI to display options dialogues. Besides, this whole thing is running with Wine, so the GDI issue is moot.
Right, and in fact this newest release makes the whole DirectDraw discussion pretty much dead. In any case, the way that COM objects are meant to be designed is that updated interfaces must be queried. Right now, a game might attempt to create the first version of the DirectDraw object: CoCreateInstance(CLSID_DirectDraw, NULL, CLSCTX_INPROC_SERVER, IID_IDirectDraw, (void**)*pdd) and if it fails then the game can abort with a message that the required version of DirectX isn't installed. So long as OLE/COM is supported properly, there won't be any problem with the changes made to DirectX from year to year that Windows machines without the latest libraries won't have too.
>>>>>>>>
I know how DirectX works, its my favorite API to work with. However, my point was that DirectX changes very significantly (particularly between 6.0, 7.0 and 8.0) and it might be too hard for a company to keep up with the changing interfaces. Even if older code works well, it is usually only a matter of a weeks before new games using the latest interfaces come out. They might not be able to keep up with the changing interface.
Except that Win32 is entirely irrelevent for this discussion. We're talking DirectX, and that changes significantly every year.
Who cares? The people who buy the PCs care that they get something well designed. This applies as equally to
;)
Macs as to PCs, to cars. It means more to some than to others, but quality is what people pay for!
>>>>>>>>
I didn't mean who cares about quality, I meant who cares that Apple does it all themselves? People do care about quality, but doing everything in one company does not necessarily bring that quality.
And thus the real question; are you actually acknowledging that Macs are higher quality than PCs?
>>>>>>>>
Depends on what you're talking about. If you're talking build quality and hardware quality, then no, PCs are just as high quality (or more so, depending on the vendor) as Macs. If you're talking about the quality of the architecture, then yes, Macs are more high quality because they don't have to deal with the vargacies of the PC architecture. This doesn't effect stability or reliability, but effects the platform's ease of use.
Still, if the PC has problems because of limitations in the architecture, that's still a problem. Why is it that
Compaq or Dell have not 'engineered' their own solution to overcome these limitations? Macs use the same
AGP and PCI busses, memory busses, USB, Firewire, ATA drive specs, video connectors, etc, so it's possible.
Why is it none of the PC manufacturers have done it yet?
>>>>>>>>>>>>>>>>
You have no idea what you're talking about do you? Sure they use the same hardware, but Macs don't have to deal with software and hardware that assumes there are 16 IRQs with IRQ2 as a cascade. Apple doesn't have to deal with software that expects a sound blaster to be at a particular port address with a particular IRQ and with software that assumes IRQ 5 is the ATA interface. Mac designers don't have to bother with the ISA bus or with a limited number of DMA channels. Mac designers don't have to treat the first meg of memory with great reverence and maek sure that DMA-able memory is under 16MBs so the ISA cards can do DMA. PC hardware manufacturers *can't* fix these issues, there is just too much software that depends on these issues.
Why the heck is Apple stupid? HP uses it's own motherboard (not a stock one from Tyan, MSI, or Intel), though it probably relies on chipsets from Intel or something.
>>>>>>>>>>
Hah! I don't know about HP, but I know that Dell's "engineered" motherboards are simply modified Intel ones. And Compaq used to make their own motherboards, but everybody hated them so they switched to stock ones. As for chipsets, only one company makes its own chipsets, and that is Micron, who uses their own chipsets in their workstations and servers.
By doing this Apple can provide it's own feature set at
the advantage of everyone else.
>>>>>>>>>
Yea, but they also tie users to their motherboards. As I said, everybody hated Compaq's LPX motherboards because their riser cards and cases were proprietory. Everyone also hates Dell's motherboards and power supplies because the power connectors are specific to Dell's motherboards.
Apple was one of the earliest adopters of USB, because it could build it into the system instead of waiting for Intel or Tyan to design the motherboards with USB support.
>>>>>>>>
But does Apple let other companys make Apple compatible chipsets? AMD made their own chipset as well to add features for the K7 platform, but allowed other companys to take over the K7 chipset market as the platform matured. I don't see Apple allowing VIA to make Apple chipsets.
It's called innovation, and it's called leading the pack. They can either wait for someone else to do it, and bundle it, or they can do it themselves!
>>>>>>>>>>>
That's fine. But even after other companies support it, they continue to lock them out. That's called monopolizing the platform!
You're 99% sure? I'm pretty sure than in an Open PPC system, you'd get identical results as today's open PC
system.
>>>>>>>>>>>>
The 99% sure is because, like IBM and their OpenPPC system, somebody might fuck up.
Crap devices with crap drivers and crap systems.
>>>>>>>
It's called a Mac. Crap graphics cards, crap OS, crap hardware.
Don't tell me they don't exist!
>>>>>>>>>
I'm not saying they don't exit because they do. At least with PC's, however, you have the option of not buying crap hardware! Besides, there is crap hardware and crap drivers on every platform, even Apple's. The only advantage the Apple platform has is that it doesn't inherit the limitations of the IBM PC. An OpenPPC platform would inherit these limitations either, and would be better than an Apple system because it was open.
Apple may be the cream of the crop in such a market
>>>>>>
In the crap hardware market? Seriously though, until recently, Apple was the king of crap hardware. Rage II+ graphics chips, Crystal sound chips, too little RAM, 50MHz system busses, the list goes on. Even now that Apple has good hardware (GeForce3's, DDR-SDRAM, etc) its only because manufacturers from the PC industry decided to include Apple in their plans. And they still can't get a decent set of bundled speakers!
but tell me how Apple gets an advantage in an Open system? Apple gets no advantage,
>>>>>>>>>>
That's a good thing for the consumer.
and the users gets one advantage: The ability to choose their own motherboard (that's it! Everything else in a Mac is already standard!)
>>>>>>>>>
No, they get the ability to build their own system. With that comes the ability not know to choose your motherboard, but choose alternate chipsets, mix-and-match parts, and have access to cheaper hardware. Right now, if I buy an Apple, I would have to throw away the entire sound system and replace it with a Live! and a set of Klipschs. I'd have to lose the on board ATA card and install at ATA RAID array. Why bother? With the PC, I can go to a manufacturer that offers these standard (or build my own) and not pay for parts that I don't want.
And do you seriously think there would be a company that build a better motherboard than Apple? If they do,
they should *already* be building better motherboards than Apple today!
>>>>>>>>>>
Yes. Where'd you get the idea that Apple builds the best motherboards in the world? They don't, and because of the closed nature of the Apple platform, nobody is allowed toc compete with them.
Okay, so now we get to the meat of your argument. That the platform is being killed by a non open standard.
>>>>>>>
Actually, I think Apple is bouncing back. I just think a lot more people would use it if they got to have control over their system. I know I would (once the quad 1Ghz G4 mobo's come out, of course
Well, 2 things.
Apple *is* the standard.
>>>>>>>>>>
What? Clarify what you mean.
Anyone (Dell, Compaq, etc) can release their own PPC systems if they wanted, but they would need an OS.
Apple, as a business, need not 'give' their OS to a competitor. Think about it.
>>>>>>>>>>>
They could not build a PPC system that would run MacOS. Besides, Apple could sue them. Do you think Dell could clone the Playstation hardware without Sony sueing their asses off? Hell no! I think you need to read up on the definition of "closed platform." Besides, Apple forcing people to buy hardware by withholding their OS is worse than MS's tactics!
Apple sells what it sells, and people buy it. It suits their needs, despite the comparison you bring up. It's stable enough, full featured enough, fast enough, powerful enough.
>>>>>>>>>>>
Ohhh. It's enough. If enough were enough, then mediocrity would be celebrated, not spat upon.
If they weren't, people wouldn't buy Apple. They would buy Compaq, or Dell, or like yourself, build their own
system.
>>>>>>>>>>
People (statistically) DON'T buy Apples.
The platform you speak of is easy to use *because* of everything you point out. That Apple does it's own
hardware and software and drivers
>>>>>>>
You contradict yourself. If Apple does everything themselves (they don't, NVIDIA writes the drivers, Crystal writes the drivers, Adaptec writes the drivers, etc) how can most of the hardware on an Apple be standard? Apple uses mostly PC hardware, but makes their own motherboards and chipsets, and doesn't allow anyone to clone them. The only thing that makes Mac's easier to use (besides the OS, which isn't relevant in this discussion) is the fact that Apple isn't stradled with a two decade old architecture. That's IT. If Dell and Compaq etc all were allowed to make their own versions of the Mac, the Mac would be no less easy to use.
because they have their own OS
>>>>>>>
There OS is easy to use. I'll give you that.
You can't get that *anywhere* else because no one else does it. Microsoft will soon, when they release their XBox, and then you'll have *all* the same arguments against them as you do against Apple!
>>>>>>>>>>>>
Well, both the XBox and the Mac have crappy OSs, so their is one comparison. Still, you're making what we in the psychology world call a "fundmental attribution error." You're attributing the Mac's ease of use to the fact that Apple builds it, not to the quality of the architecture. If the PC didn't have all these IRQs and DMAs and all, then you could still buy chipsets from all over the place, graphics cards from all over the place, etc, and still have a system that's as easy to use as a Mac. (If you buy good hardware, but again, crappy hardware is universal.)
So... You designed your own motherboards and chipsets, wrote your ROM bios code, spec-ed out your capicitors and diodes, pressed your own sheetmetal cases, injection molded your own case-skins, wrote your own firewire spec, then implemented the CMOS for it, and then wrote the drivers for it, designed and built the wireless antennas for your PC, and drafted your own bus specs and implementations?
;), Klipsch 4.1 speakers, 80GB RAID array (4 drives!) and a Sound Blaster Live! card. A Mac user, on the other hand, would have to shell out $3500 for a 733MHz G4 (benchmarks put a $500 Mhz G4 at about the speed of an Athlon 750. I doubt a 733 will clear an Athlon 1.1, much less a 1.3) with a third the RAM, 60GB-non RAID drive, Apple "Pro" speakers, and a no-name sound chip. By the time you bring this anemic thing up to PC standard, the price balloons to well over $5000. PPC seems to be a good platform. Motorola and IBM are getting their act together and releasing 1GHz G4s, which should beat with the fastest x86 chips. The platform has always been easy to use, and with the upcoming DDR-SDRAM chipsets, will be on a speed-parity with the x86 platform. Despite it all, Apple is killing it by keeping it closed.
>>>>>>>>>>>
Who cares? In the PC industry, the people who do these jobs do it as well (or better) than Apple does it. The only reason that the PC's aren't as high-quality as Macs is because of the limitations in the architecture, not bad build quality.
You can create a PC as well as any 'lacky' who throws parts together. You may chose better or worse parts than
any lacky, but when you buy Apple, you buy all of the above, and if you don't want to pay for that, then you
can't get a PPC system.
>>>>>>>>>>>>>>>
A) I don't WANT a PPC system.
B) Apple is stupid for doing all this itself. It hems the customer into using whatever Apple feels they should use, and drives up cost. Build quality isn't drastically improved (I'm 99% sure that an Open PPC system would be just as high quality as the closed Apple system. Besides, the old Apple clones were just as good as real Apples) and the industry hates you for it. Companys hate Intel for sucking it all in and doing their own chipsets, motherboards, CPUs, and graphics cards, and (if Apple becomes big enough to matter) people will hate Apple for the same reasons.
Now I don't contest that a PC you build is stable or reliable; it cannot be denied that a multi-million dollar corp can build crap PCs too.
>>>>>>>>>>>
The PC I built I just as high quality as any Apple machine. With plug & play (and BeOS) adding hardware is just as easy as with an Apple machine. Its cheaper, more powerful, and more well-supported (in terms of replacement hardware). And I'm not too sure of how much Apple cares about product quality. This is the same company that for years shipped systems with graphics cards two generations out of date, system busses two bins too slow, OSs two bits short of stable, and sound hardware that couldn't compete with my kazoo. With $3500 (or less!), I could easily build a 1.33Ghz Athlon PC with 1GB RAM, A GeForce3 (or ATI's upcoming, BeOS supported, Radeon II
I wasn't trolling. Linux 2.4 IS a better system than Mach/FreeBSD 3.2. First, Mach is a pretty crappy microkernel. Second, FreeBSD 3.2 is several years out of date, and FreeBSD 4.0 is a much better system. I don't know how Linux 2.4 stands up to FreeBSD 4.0, but I know that they are close, which suggests that 3.2 couldn't compare to Linux 2.4.
Mod this up. This is damn funny! (At least the first part of it.)
;)
BTW> Netscape lost money because its browser sucked ass, not because it gave it away.
PS> Redhat does suck. They're the Linux equivilant of Microsoft. The only thing that saves RedHat is the fact that Linux is so stable and secure to begin with. (And the fact that other people write the code
Even Linux From Source. The Linux kernel should have a unified way of handling and configuring hardware, and there should be a standard userspace tool to configure and manage hardware. (Kinda like how kernel-level networking is configured through the userspace program ifconfig.)
I think the prices need to be adjusted. 768k SDSL should be more accurately priced around $250/month
for it to be worth it to these DSL providers.
>>>>>>>>>>>>>>
Uh no. I happen to *like* SDSL for $50.
Isn't the /. crowd the one so obsessed with diversity? Besides, BeOS isn't based on *NIX either.
PS> Yea, I know BeOS isn't major, but does RedHat have a contract with Sony?
I don't know how much sense porting OS-X to Linux would make. Altough Linux 2.4 is a much better system than Mach/FreeBSD 3.2, by taking out BSD and Mach, you get rid of much of OS X. Maybe you're thinking of porting Quartz, Aqua, and OpenStep to Linux? In that case, you won't be happy to hear that all of the above are closed source, and thus will not run on x86 unless Apple ports it.
From the Debian About page: "Although Debian is non-profit." Thus, Debian made *no* profit last year. Also, I doubt Linux will ever make much money on the desktop, but I can see them making quite a bit of money in the corporate world, where support costs usually outweigh license costs.
From where? If the 3D model is bigger than RAM, its on the harddrive. If the harddrive transfers at 30MB/sec (at best) and PCI is 100MB/sec (optimal: 133MB/sec) then it does no good to speed up the PCI bus! PCI bus speeds used to matter, but unless you have an >4 drive U160 SCSI RAID array, it really doesn't any more, since the only thing on there is the hard drive and sound card.
That's bullshit. I spent more time "engineering" my computer than any Dell (or Apple) lacky spent throwing a system together.
Not yet, but give me six months to finish it ;)
Seriously though I meant the box. I built every computer in my house, and I find that the big name guys just don't pack in the proper parts.