I'd disagree that Intel SMP with the BX chipset is buggy. First, the BX chipset is probably the most stable thing put out by a major manufacturer in recent years. There's a reason so many BX-133 mobos exist. Second, tons of people have been very happy with dual celeron BX systems (a lot hang out at BeNews;) and I've yet to hear any complaints of stability from the BX chipset.
It's still slower than a Duron, and more expensive to boot. On pricewatch a Celeron 766 ($155) is closest in price to a Thunderbird (not Duron) 950 ($160) It's time to switch to AMD. At least on the low-end to midrange. The only possible reason I can see for buying Intel at this point is if a P4 suits your needs.
Win2K better.. Haha, that's a good one! The ONLY thing better about Win2000 is the ability to run some more games..
>>>>>>>>>>>>>>
Right. The fact that it is as stable as Linux, that DirectX 8 whips the hell out of anything Linux has, and the fact that the hardware support and OpenGL perfromance of Win2K still beat Linux aren't really important, are they? Not to mention the advantages Win2K has for notebooks (better power management) and all the features that the GUI has that GNOME/KDE are still lacking (they're there, but immature, and not yet pervasively used.)
There is STILL a lot of settings that you can't change without having to reboot the computer. That's crap.
>>>>>>
Who cares? You only configure your computer once in awhile!
For a "production" machine, you shouldn't have to do that.
>>>>>>
Therin lies the rub. You're thinking from a server standpoint.
With Linux, the ONLY thing you have to restart for is a kernel rebuild, which is very rarely necessary.
>>>>>>>>>>
Except to add support for stuff that your distro maker didn't think was important to put in. For stable distros like Slack, that means ALSA, ReiserFS, firewalls, etc. Then you have the fact (that unless you use RedHat or Mandrake, which bring their own set of problems) you cannot upgrade the kernel (realistically) without recompiling!
Actually, I think that Redhat 7.0 only *seems* to have "no problems" in upgrading to 2.4 because of all the other problems that one has to live through using that distro;)
If you don't get it, its probably because you don't remember many years and numerous extensions to Street Fighter 2 that SF fans went through waiting for Capcom to finally release Street Fighter 3.
I don't know how much of a choice anybody has at this point. Linux is a macrokernel, and probably always will be. Sure, if everyone wanted to, it could be turned into a microkernel (and has, in the case of projects like MKLinux and L4/Linux) but it would end up as a single-server microkernel, which isn't really the pinnacle of the design. Traditionally, these single servers have been pretty dissapointing, both in performance (the fastest still aren't as fast as traditional *NIXs) and features (the single server limits a lot of the fault tolerence and distribution capabilities inherent in a microkernel.) Even if it was done, Linux is so far along that the project would slow kernel development by at least 6 months and in the end, I don't think the benifets are there. Also, modularity really doesn't suffer at the hands of a macrokernel. Linux's inability to transparantly use hardware is not the fault of the kernel architecture, but the actual implementation. Even Microsoft makes loadable drivers work pretty well with a monolithic kernel (Win95) and BeOS's ability to automagically detect and configure hardware probably has little to do with its being a microkernel.
Sell HW: Might work, but not all apps can work like this. It also depends on the quality of the HW you can make.
Sell support: Most people except a minimum level of free support for their products, free or not. Also, user groups, email, and the internet are negating much of what profit you might make from software.
Dual-license: Plausible, but it still requires that you make software free to some users.
You still don't answer my question. How can I sell open software without making it free. I want to be able to charge for each copy of the software the user buys, but I want to give them the freedom to modify the software for their needs, and distribute those mods to other users. There doesn't yet exist an OSS solution that does this (OS-X comes close, though) and the GPL certainly doesn't seem to allow this.
A portable engine can be just as fast as a non-portable one. Its called Quake III. Game engines don't use the OS. They call some initialization routines, and then use whatever APIs are available to shove the OS out of the way. The only thing they interface with is OpenGL, the filesystem APIs, and the networking APIs. In the core code, it doesn't interface with anything except custom game code, and maybe OpenGL. Games like Unreal even do their own memory management.
People keep saying that the P4 is a "different kind of beast" that is designed for pure clock speed. They argue that the P4 will attain such a high clock-speed, the inefficient architecture will not matter. The problem is, that its not certain whether the P4's clock advantage will hold. According to Intel's road map, they should have a 2GHz P4 out by the end of 2001. According to AMD's, the Athlon should be at 1.7 GHz by then. Quote from this Sharky Extreme article
"AMD is hoping that the re-worked core will bring the Athlon to at least 1.7GHz by the second half of 2001. By this time the 1.2GHz Athlon CPU on 266MHz front side bus will occupy the lowest rung on AMD's performance ladder. Once the Palomino runs out of headroom, the next horse will escape from the barn."
If the road-maps of both companies can be followed, then Intel has a serious mess on its hands.
The card performs very well in windows (200+fps easily in q3a),
>>>>>>>>>
Not really. GeForce cards are cheaper and faster. And it takes a P4 1.5GHz with a GeForce2 Ultra to run Q3 at 204fps at 640x480. I seriously doubt that a V5 get anywhere close to that.
nVidia's linux drivers are very fast. maybe the timedemos show better scores in Windows, but subjectively, playing Q3 in linux is smoother. I haven't played in W2K though. Maybe it has to do with 9x's sucky multi-tasking.
>>>>>>>>>>>
Screw Win2K, try NT4. It still has the smoothest QuakeIII experience out there.
Is the NVidia driver secure?
>>>>>>>>>>>>
Who cares? Are you doing 3D rendering on your server? Before you mention networked 3D rendering farms, let me remind you that none of the pro 3D rendering machines (Intergraph, SGI, Sun, etc) have open drivers.
You apparantly missed the subtlty of what I said. I was pointing out that everybody thinks that when Linus says "it's done when it's done" it's a fine thing (as evidenced by the recent "kernel 2.4 is vaporware" article) but when Be says "it's done when it's done" people look on it as more evidence that Be is abandoning BeOS.
While I like the BeOS API, I'd hesitate to say it would be the best way to write a cross-platform game. POSIX, like it or not, is a well-established standard. A game written with strict POSIX and OpenGL complience should be easily portable to BeOS, Windows, Linux, FreeBSD, etc. Games are probably the best place to write portable code, because they don't deal with the OS very much. The only place one would really need to break from standard OpenGL and POSIX routines would be in the OpenGL initialization stage, which isn't a very large part of the overall program.
Still, if you like the BeOS API, there is a cross-platform library called ZooLib that looks an aweful lot like the BeOS API (though the function names are less elegant) and supports X, Windows, MacOS, and BeOS. Also, like the BeOS, it encourages multi-threaded applications and is SMP-friendly. It's still a little immature, and is mostly undocmented, but its progressing, and seems to have a lot of potential. You can find the home page here.
Actually, I'm pretty sure that Win98 has the fastest, best graphics handling capabilities of any OS you mentioned. MacOS graphics, while very feature-filled from a color-matching, DTP point of view, tends to be slow. BeOS graphics are fast, but they don't support color profiles, gamma correction, or anything of the sort. Win98 supports almost as many features as MacOS (it might even support more these days) and thanks the the whole "in-kernel ASM code" bit, its probably the fastest of the three.
is still not out. Linus has said that it will be released 'when it's done.' I can't imagine how they'll have those kinds of graphics out for Linux without a new kernel. Hopefully Linus will release it soon, Linux users have been waiting for it for over a year.
Okay. Field this one for me. How can I make commerical and OSS work together? It seems, that according to the GPL, source must be freely distributable. That means I cannot really charge for a product without doing some "sell the support" bull. If you can teach me how to release a GPL product that must be payed for (per copy) just like any other product, then I think you're "commercial!=prorietory" arguement has some merit. Otherwise, it's just smoke.
No, I never said platform independance is a "load of bull" I said that "compile once, run everywhere" is a pile of bull. There's a difference. Given well-written POSIX apps, and well written POSIX implementations, you don't have to modify code when porting between OSs. In practice that might still not be true, but as POSIX compient OSs like BSD and Linux penetrate the market, I'll bet that both apps and implementations are going to improve.
I'm fundementally against the idea of Java. I don't think that the best way to implement apps is through I virtual machine. I think that API level compatibility is a simpler, faster way of doing things. Of course, I'm a speed freak and despise anything that is less efficient than it could be. While you might want to turn this into a C++ vs. Java debate, I'd say its more of a POSIX vs. Java debate. And from what I've seen so far, POSIX seems to be winning.
Slashdot Mirror
I'd disagree that Intel SMP with the BX chipset is buggy. First, the BX chipset is probably the most stable thing put out by a major manufacturer in recent years. There's a reason so many BX-133 mobos exist. Second, tons of people have been very happy with dual celeron BX systems (a lot hang out at BeNews ;) and I've yet to hear any complaints of stability from the BX chipset.
It's still slower than a Duron, and more expensive to boot. On pricewatch a Celeron 766 ($155) is closest in price to a Thunderbird (not Duron) 950 ($160) It's time to switch to AMD. At least on the low-end to midrange. The only possible reason I can see for buying Intel at this point is if a P4 suits your needs.
Win2K better.. Haha, that's a good one! The ONLY thing better about Win2000 is the ability to run some more games..
>>>>>>>>>>>>>>
Right. The fact that it is as stable as Linux, that DirectX 8 whips the hell out of anything Linux has, and the fact that the hardware support and OpenGL perfromance of Win2K still beat Linux aren't really important, are they? Not to mention the advantages Win2K has for notebooks (better power management) and all the features that the GUI has that GNOME/KDE are still lacking (they're there, but immature, and not yet pervasively used.)
There is STILL a lot of settings that you can't change without having to reboot the computer. That's crap.
>>>>>>
Who cares? You only configure your computer once in awhile!
For a "production" machine, you shouldn't have to do that.
>>>>>>
Therin lies the rub. You're thinking from a server standpoint.
With Linux, the ONLY thing you have to restart for is a kernel rebuild, which is very rarely necessary.
>>>>>>>>>>
Except to add support for stuff that your distro maker didn't think was important to put in. For stable distros like Slack, that means ALSA, ReiserFS, firewalls, etc. Then you have the fact (that unless you use RedHat or Mandrake, which bring their own set of problems) you cannot upgrade the kernel (realistically) without recompiling!
Why the hell was this modded up? It's not even true!
Actually, I think that Redhat 7.0 only *seems* to have "no problems" in upgrading to 2.4 because of all the other problems that one has to live through using that distro ;)
Actually, I think this was the joke you were trying to make
2.2
2.2-turbo
super-2.2
super-2.2-turbo
2.2-alpha
2.2-alpha-2
super-2.2-alpha
super-2.2-alpha-ex
super-2.2-alpha-ex-2
If you don't get it, its probably because you don't remember many years and numerous extensions to Street Fighter 2 that SF fans went through waiting for Capcom to finally release Street Fighter 3.
I don't know how much of a choice anybody has at this point. Linux is a macrokernel, and probably always will be. Sure, if everyone wanted to, it could be turned into a microkernel (and has, in the case of projects like MKLinux and L4/Linux) but it would end up as a single-server microkernel, which isn't really the pinnacle of the design. Traditionally, these single servers have been pretty dissapointing, both in performance (the fastest still aren't as fast as traditional *NIXs) and features (the single server limits a lot of the fault tolerence and distribution capabilities inherent in a microkernel.) Even if it was done, Linux is so far along that the project would slow kernel development by at least 6 months and in the end, I don't think the benifets are there. Also, modularity really doesn't suffer at the hands of a macrokernel. Linux's inability to transparantly use hardware is not the fault of the kernel architecture, but the actual implementation. Even Microsoft makes loadable drivers work pretty well with a monolithic kernel (Win95) and BeOS's ability to automagically detect and configure hardware probably has little to do with its being a microkernel.
Sell HW: Might work, but not all apps can work like this. It also depends on the quality of the HW you can make.
Sell support: Most people except a minimum level of free support for their products, free or not. Also, user groups, email, and the internet are negating much of what profit you might make from software.
Dual-license: Plausible, but it still requires that you make software free to some users.
You still don't answer my question. How can I sell open software without making it free. I want to be able to charge for each copy of the software the user buys, but I want to give them the freedom to modify the software for their needs, and distribute those mods to other users. There doesn't yet exist an OSS solution that does this (OS-X comes close, though) and the GPL certainly doesn't seem to allow this.
Which I haven't, as they don't exist. I said that QNX has Quake 3 and UT in beta.
A portable engine can be just as fast as a non-portable one. Its called Quake III. Game engines don't use the OS. They call some initialization routines, and then use whatever APIs are available to shove the OS out of the way. The only thing they interface with is OpenGL, the filesystem APIs, and the networking APIs. In the core code, it doesn't interface with anything except custom game code, and maybe OpenGL. Games like Unreal even do their own memory management.
BeOS actually does have gamma correction
>>>>>>>>
Really, and you get this info from where?
People keep saying that the P4 is a "different kind of beast" that is designed for pure clock speed. They argue that the P4 will attain such a high clock-speed, the inefficient architecture will not matter. The problem is, that its not certain whether the P4's clock advantage will hold. According to Intel's road map, they should have a 2GHz P4 out by the end of 2001. According to AMD's, the Athlon should be at 1.7 GHz by then. Quote from this Sharky Extreme article
"AMD is hoping that the re-worked core will bring the Athlon to at least 1.7GHz by the second half of 2001. By this time the 1.2GHz Athlon CPU on 266MHz front side bus will occupy the lowest rung on AMD's performance ladder. Once the Palomino runs out of headroom, the next horse will escape from the barn."
If the road-maps of both companies can be followed, then Intel has a serious mess on its hands.
Where do you shop? On pricewatch, a Voodoo3 is about $50, and you can get a GeForce2MX for the $80 you quoted.
The card performs very well in windows (200+fps easily in q3a),
>>>>>>>>>
Not really. GeForce cards are cheaper and faster. And it takes a P4 1.5GHz with a GeForce2 Ultra to run Q3 at 204fps at 640x480. I seriously doubt that a V5 get anywhere close to that.
nVidia's linux drivers are very fast. maybe the timedemos show better scores in Windows, but subjectively, playing Q3 in linux is smoother. I haven't played in W2K though. Maybe it has to do with 9x's sucky multi-tasking.
>>>>>>>>>>>
Screw Win2K, try NT4. It still has the smoothest QuakeIII experience out there.
If you're looking for
Performance: Get a GeForce2. In everything from 3D OpenGL to 2D X performance, it whips everything else out there (including the G400)
Features: Get a Matrox G400. They tend to have the most feature support.
Picture Quality: Get a Radeon. The Radeon's 3D and 2D quality is amazing, though the 2D performance is a little limp.
Is the NVidia driver secure? >>>>>>>>>>>> Who cares? Are you doing 3D rendering on your server? Before you mention networked 3D rendering farms, let me remind you that none of the pro 3D rendering machines (Intergraph, SGI, Sun, etc) have open drivers.
You apparantly missed the subtlty of what I said. I was pointing out that everybody thinks that when Linus says "it's done when it's done" it's a fine thing (as evidenced by the recent "kernel 2.4 is vaporware" article) but when Be says "it's done when it's done" people look on it as more evidence that Be is abandoning BeOS.
THe sad part is that it seems QNX RtP's gaming library is growing faster than BeOS's. THey have Quake III, and the UT port is in beta.
While I like the BeOS API, I'd hesitate to say it would be the best way to write a cross-platform game. POSIX, like it or not, is a well-established standard. A game written with strict POSIX and OpenGL complience should be easily portable to BeOS, Windows, Linux, FreeBSD, etc. Games are probably the best place to write portable code, because they don't deal with the OS very much. The only place one would really need to break from standard OpenGL and POSIX routines would be in the OpenGL initialization stage, which isn't a very large part of the overall program.
Still, if you like the BeOS API, there is a cross-platform library called ZooLib that looks an aweful lot like the BeOS API (though the function names are less elegant) and supports X, Windows, MacOS, and BeOS. Also, like the BeOS, it encourages multi-threaded applications and is SMP-friendly. It's still a little immature, and is mostly undocmented, but its progressing, and seems to have a lot of potential. You can find the home page here.
Why in god's name would you put an mpeg decoder in the kernel? Stuff like that belongs in userspace.
Actually, I'm pretty sure that Win98 has the fastest, best graphics handling capabilities of any OS you mentioned. MacOS graphics, while very feature-filled from a color-matching, DTP point of view, tends to be slow. BeOS graphics are fast, but they don't support color profiles, gamma correction, or anything of the sort. Win98 supports almost as many features as MacOS (it might even support more these days) and thanks the the whole "in-kernel ASM code" bit, its probably the fastest of the three.
is still not out. Linus has said that it will be released 'when it's done.' I can't imagine how they'll have those kinds of graphics out for Linux without a new kernel. Hopefully Linus will release it soon, Linux users have been waiting for it for over a year.
Okay. Field this one for me. How can I make commerical and OSS work together? It seems, that according to the GPL, source must be freely distributable. That means I cannot really charge for a product without doing some "sell the support" bull. If you can teach me how to release a GPL product that must be payed for (per copy) just like any other product, then I think you're "commercial!=prorietory" arguement has some merit. Otherwise, it's just smoke.
No, I never said platform independance is a "load of bull" I said that "compile once, run everywhere" is a pile of bull. There's a difference. Given well-written POSIX apps, and well written POSIX implementations, you don't have to modify code when porting between OSs. In practice that might still not be true, but as POSIX compient OSs like BSD and Linux penetrate the market, I'll bet that both apps and implementations are going to improve.
I'm fundementally against the idea of Java. I don't think that the best way to implement apps is through I virtual machine. I think that API level compatibility is a simpler, faster way of doing things. Of course, I'm a speed freak and despise anything that is less efficient than it could be. While you might want to turn this into a C++ vs. Java debate, I'd say its more of a POSIX vs. Java debate. And from what I've seen so far, POSIX seems to be winning.