I think the linux missed out on exploiting a weakness in Windows - gaming
Could you please give reasons or cite examples that prove that gaming is a weakness for Windows, rather than a strength? I don't want to get into the "Windows has a bigger market, and so that's the only reason it has a large market for games" argument, as that doesn't address the issue -- specifically, that Windows is technically inadequate for gaming while Linux is technically superior (extrapolating from your statement that gaming is a weakness of Windows, and that Linux should attempt to beat Windows there).
I'm serious, here. I don't see how you can justify saying that gaming on Windows is a weakness, so please give me reasons. Thanks.
Re:A great example of open-source at work.
on
Five Years of KDE
·
· Score: 1
Maybe so, but why must it be a VMS relationship? Hint: MS is also an abbreviation for Microsoft...
However, the official company line, as I stated, is that it doesn't stand for anything. If you want the real story, dig up whoever came up with that name, and ask him
Five years to develop this brilliant stuff is just unbelievably short. Not even Microsoft can build their lousy Win3.1 to another lousy Win2K, that took them more than 5 years...
Please note that KDE is simply a desktop environment/object model/bunch of apps. If Microsoft only changed the interface between win3.x and win2k (or even between win3.x and win95), then that would be a valid comparison. However, the evolutions you refer to involve the core operating system as well (especially your comparison of win3.x to win2k, but even win3.x to win95 included core OS changes, such as the switch to native 32-bit protected mode, using DOS only as a boot strap, rather than being little more than a DOS shell).
KDE is a great product, and I agree that it has come far in a relatively short amount of time, but please compare apples to apples. And don't forget that KDE didn't have to do all the "difficult" research that Microsoft did. 12 years after the GUI became "mainstream" (1984, Apple Macintosh), KDE began their project. Both Apple and Microsoft had gone through numerous iterations, making mistakes on the way, and eventually coming up with paradigms that Just Work. KDE was able to use all this design that came before it. (Note that I'm not saying that's a bad thing.)
Re:A great example of open-source at work.
on
Five Years of KDE
·
· Score: 3, Informative
But the Windows NT kernel was essentially just VMS force-fitted to DOS-style conventions. In fact, WNT = VMS with all the letters incremented. The "New Technology" line was force-fitted later for marketing:-)
Err, wrong. NT has no VMS code in it at all. Perhaps you're referring to the fact that Microsoft hired a number of big-time VMS developers to create NT? That would explain VMS-isms in NT, while supporting the fact that NT != VMS. As far as the acronym goes, that's pretty much BS (in the way that crap like numerology is BS. You can always come up with those types of "interesting" correlations that mean absolutely nothing). The company line on NT is that it has no meaning. It's simply the letters 'N' and 'T'. "New Technology" is something that the media dreamed up to assign meaning where there was none.
How does Scheme, as a lisp (successor? derivative? argh) not force you to design more recursively and/or functionally (ie, functional programming)? Certainly straight-up procedural programming is not encouraged except as a speed "hack"?
Scheme (and lisp, though I haven't played around much with CL) is flexible enough to let your program procedurally or OO. It's a functional language, and relies a lot on recursion, but that doesn't mean you have to recurse. There is syntactic sugar to write things such as for loops or while loops (obviously I'm using the C/Java style syntax here, because it's been forever since I've used scheme). That syntax may very well translate into recursion calls, but as far as programming goes, it looks procedural. OO, when I learned Scheme, was more of a message-passing type of paradigm (think ObjC, if you're familiar with that), rather than a class.method type of syntax. The point is not the syntax, but the concept, and scheme lets you explore all three major paradigms within a single language. The best C++ can do is two out of three, and Java's pretty much a one-pony show (OO, and screw you if you want to do anything else), though I guess you could hack your way into a procedural paradigm (lots of static methods, for instance).
As far as I know, it's encouraged that you program recursively in scheme (specifically, use tail recursion if at all possible, for performance reasons), but that wasn't really my point. My point was that you can get a taste of all three with only one language, one syntax.
I take serious offense at this notion that advanced conceptual computer science can only be taught in a commercially-backwater language like Scheme or LISP. It is the same ivory tower elitism at work here as that which so often causes types like Harvard anthropology majors or Berkeley political science majors to view the rest of modern, industrialized society with disdain.
I think you misunderstood the point I was trying to make (which is as much my fault as yours, as I only mentioned it once, in passing). That major point was that scheme/lisp makes for a very good introductory language. You know, your first one or two CS classes, where you start learning the core concepts, but before you could even dream about being able to apply your new-found knowledge to real world tasks. It's extremely important in those early stages to be able to level the playing field. It's great if a student comes into the curriculum already knowing C++, Java, or whatever else (as long as s/he hasn't formed any bad habits, anyway, which is unlikely). However, there are always going to be neophytes that are interested in computer science but have never had the time or opportunity to learn a language on their own. Choosing a language such as scheme (for example. You could pick any easy-to-learn-but-obscure language, if you really want) makes it so that those with prior language knowledge aren't at too much of an advantage, and those that have no prior knowledge are not at too much of a disadvantage. There's always the oddball that comes into such a class already konwing scheme, but that's much rarer than if said class were taught in Java (for example). Also, as a vehicle for teaching early CS concepts (the major types of paradigms, for example), scheme excels. With C++, you can't write functional code ("functional" meaning "functions are first-class objects, a la scheme, lisp, sml, etc" not "working"). With Java, it's hard to write anything but OO code. With scheme, you can introduce all through concepts within the bounds of a single language. This is perfect for presenting the concepts without relying overly much on syntax.
I went to MIT over ten years ago and I was taught Scheme by Hal Abelson and Gerald Sussman. I also worked in Common LISP on Symbolics LISP machines and Texas Instruments Explorers. These things I learned were supposedly the pinacle of computer science education of the day. I mention this not to brag, but rather due to the specific topical relevance of my past experience. In short, I feel qualified to say that -- in my experience -- Scheme and LISP offered nothing that I could not have also learned through the use of a more commercially-relevant language. In fact, in my personal opinion, I would almost go so far as to say that some of the vaunted abstract concepts that they go through pains to indoctrinate their students with verge on being counter-productive in the real world.
Just to fill in a little bit of my own background, I graduated from the University of Illinois - Urbana/Champaign a little over a year and a half ago. When I began my education there, the initial CS course for CS majors was taught in scheme, so perhaps I'm a little biased. However, roughly two years into my education, the school began moving classes over to java, beginning with that class. Having younger friends who took this class in java, I saw a noticeable deficiency of various core concepts that they should've been taught in that class. I'm not blaming java 100% for that, but it surely owns some of the guilt. As far as later classes go, I have no problem with them using whatever language is appropriate (typically prolog and lisp for AI work, C++ or java for data structures, and so on), but to teach an introductory course in an infelxible language is doing a disservice to the students.
Why not learn C++, and OOD instead of scheme? Its in the industry, and it teaches them the theory they need to know.
OOP is not C++-specific. Believe it or not, you can use other programming paradigms in scheme than just functional programming. You can write procedural code, if you wish, or even OO code. The point of using Scheme in introductory CS classes is two-fold.
It levels the playing field. Students coming into the class already knowing C++ or Java or even Basic no longer have as much of an advantage over students that come into the class knowing little or nothing about programming. (and while you might argue that the latter people shouldn't be learning CS anyway, that's a very narrow-minded and short-sighted view, and one that's not even worth acknowledging)
It allows the teacher to focus on concepts rather than language idiosyncracies. Scheme can be taught to the students within the first two weeks of class. After that, they'll have all the tools necessary to learn about different programming paradigms and other CS concepts. This is much better than Java, for instance, which more or less forces you into OO design.
Even though it's unlikely scheme is going to directly affect your job marketability, there are good reasons for using it in education. Foremost of the reasons is that a four-year Computer Science degree is aimed at doing more than just developing currently-marketable talents. You're learning how to think and problem-solve, and how to learn, so that in five years when Java is no more, or when C++ finally goes by the way-side, or when whatever marketable skill you have is no longer applicable (and that will eventually be the case), you are capable of quickly grasping the new technologies because you have learned how to learn. If you don't want to learn this, don't bother with a university degree. A two-year tech college, or even a couple of well-chosen certifications (guh, don't even get me started on the uselessness of those) will be much better for you, and save you money in the short run. (In the long-run, you're going to continue to pay out the rear to keep your "education" up-to-date by taking more classes or certifications.)
Re:You really need to stop smoking that cheap shit
on
J#
·
· Score: 1
Either you have some severe reading comprehension problems, or you didn't even bother to read my post. Try reading it again. The.NET Framework (CLR and C#) has been submitted to ECMA, and thus anyone may write their own implementations. While it's true that the.NET Servers (Hailstorm, for instance) are Windows-only, there's nothing that says a well-implemented CLR (for instance, the Mono project) will not be able to run the bytecode for those servers (assuming, of course that the.NET servers are built using the.NET Framework, and thus target the CLR). As well,.NET is a concept, that of XML-based web services, and a platform, built on the.NET Framework (which I've already established has the potential to be cross-platform, where "platform" here refers to cpu/os combinations).
If you want to jerk your knee, that's fine. But at least pick apart what you think is wrong with my post.
Re:This is good news...
on
J#
·
· Score: 4, Interesting
Is it a good idea? I can see that it would be - if it weren't for the small point that it only runs on Windows. If you're only going single platform then surely you'd be better off going native code and just using the same compiler back-end for all languages (as Borland do for Delphi and C++ Builder - which both run like sh*t off a shiny shovel).
For now, yes, the.NET framework is only available for Windows. However, Microsoft has committed to providing a reference implementation for the *BSDs (FreeBSD, I believe), and other projects like Mono have sprung up to bring an implementation to Linux and other unix-like operating systems. Since Microsoft has submitted both the CLR and C# to ECMA for standardization (say what you will about ECMA, but at least it's a standards body), anybody can write their own implementation. Sun's backed out several times on submitting Java to ECMA.
Of course, if they didn't have this CLR, then they couldn't make the claim that they were going multi-platform so it looks like they just found a way to slow down your Windows code for no good reason.
That would be true, if it were the case that CLR bytecode only ran under the VM. However, that's not the case at all. The CLR has the ability to compile its bytecode down to native code for whatever machine you're on. Most likely the way this will happen is that CLR bytecode will be "shipped" (in a box, or as a download), and as part of the installation that bytecode will get compiled to your platform. What that means is that, taking a Windows-only view for a moment, when you buy Office.NET (just as an example -- I don't know whether Office.NET will be targetting the CLR or not), it won't matter whether you're running on a 32-bit x86-based system, or on a 64-bit iTanium (or whatever AMD's 64-bit chip is called), the same version will run on both. And with native speed, because after installation, you'll be running native code. Obviously, it's developer choice whether or not to compile down to native code, but that's the point -- the choice exists. And given full CLR implementations on other platforms, I don't see any reason why pure CLR bytecode wouldn't be perfectly cross platform, even to the point of compiling down to native code and running as a native app on your chosen system. Perhaps this is how we'll eventually see IE, Office, etc on Linux? (Through the efforts of Mono)
I still don't after all this time understand exactly what is the point, or rather the benefit of.NET. I've even had the on-campus M$ rep try to explain it to me, all to no avail.
Check out http://www.microsoft.com/net/whatis.asp for an explanation on what.NET is. Take special note that.NET is not the Common Language Runtime, or the C# programming language, or Visual Studio.NET, or Visual Basic.NET, or the SOAP Toolkit, etc. Those are part of the.NET Framework, or the platform that enables you to build.NET services (since.NET is all about XML-based web services).
As far as what benefit you gain, that's twofold. With the.NET Framework, specifically the Common Language Runtime, you gain the ability to easily work with objects across many different languages, without any grunt work to get in the way (such as making sure you write everything as a COM object, and doing your own reference counting, and making sure you initialize and deinitialize COM). And since all the objects from code targetting the CLR are exposed as COM objects, you can even use them from languages that don't support the runtime, such as C, non-Managed C++ (aka, C++), VB6, Delphi, or any other language that supports COM objects.
.NET itself is more about server-server communication over the web. By passing around SOAP messages (via SSL, when security is an issue), you can implement anything from alerting users that they're being out-bid on something like eBay, to providing stock quotes more easily (without having to "scrape" html pages), to offering choice hotel information when you book a plane flight, and so on. Yes, all of that can be done now, but.NET aims to make it much easier. The potential for XML-based web services is pretty much bounded only by your (editorial your) imagination, and since it's all based on standard communication methods (HTTP(s), SOAP), you won't have to define new protocols for passing data around each time you want to do something new.
There are similar things out there, such as XML-RPC, but they don't focus as much on providing web services as.NET does.
Of course "no one" will use it
on
J#
·
· Score: 4, Insightful
and some commentary saying basically, "No one will use it".
Maybe I missed the point, but it's a migration tool. It's not meant to take the place of Java, or even really compete with Java, other than it makes it possible for developers to take their existing java code and move it to the.NET platform with relatively few changes. This means the old objects are now accessible to all.NET languages (C#, VB, Managed-C++, and all the other marginal languages that have been ported), making it less painful to move over to C#. Until the old modules are reimplemented, they're still available. Moreover, even non-.NET languages will have access to those objects as COM objects, since that's a benefit of the CLR. So if you want to write code in C, or non-managed C++, you can still get at those objects (which you couldn't do before without extra work).
To me, the fundamental feature missing is foreign key constraint, which I see is not even mentioned among the new features.
Exactly! Take a look at http://www.mysql.com/doc/B/r/Broken_Foreign_KEY.ht ml and see why they don't have foreign key support yet. They simply say it's scheduled for inclusion in the "near future" (I'm not sure what their definition of "near" is, but that page has been up for months now, and foreign key support still isn't slated for 4.0 or 4.1). Don't hold your breath, and either switch to a real rdbms (a la pgsql), or continue to work around mysql's deficiencies on an app-by-app basis.
With the introduction of the Berkely DB table type, MySQL gained transactional support. It'd be nice to have native transactions for all table types, but at least this is better than nothing at all. Of course, if you want to complain about useful-but-missing features, complain about decent stored procedure support (coming, but the keyword here is "decent" -- if they only support one language, like perl, then it becomes useless), foreign keys, subselects (apparently coming in 4.1), and triggers. Of course, the way the MySQL project seems to be going, they're going to end up reinventing the wheel originally designed by Oracle 20+ years ago, while steadfastly denying that the missing functionality is useful up until the point where they announce that they'll be adding said functionality.
the choice is clear: many people voluntarily pick different UI styles on any platform--otherwise, WinAmp, QuickTime4, Kai's tools, etc. wouldn't have succeeded.
All the applications you mentioned are "creative" applications in one form or another (media players, image manipulators). Skinning is an accepted method of bringing forth this creative side. Even Windows XP has acknowledged the usefulness of skinning with its new Visual Styles. However, if you look at productivity-type applications (office suites, text editors, fax apps, etc), you'll notice that most do not deviate significantly from the published guidelines for their target OS, and those that do fail miserably (IBM had a suite of apps that had "real-life" skins, like a fax app that looked like a fax machine, a phone that looked like a phone, a PIM that looked like a day planner, and so on. The suite failed because the interface was awful. The metaphor of the real object did not carry over to the application).
The important thing to get from this is that Mozilla is not a media player, or a fanciful image manipulator. It's a productivity tool, and differentiates its UI for no other reason than simply to be different. The code had to go into the XUL backend to support each OS anyway, why not simply make it a light wrapper around various toolkits (win32, aqua/carbon, gtk, qt, whatever) and gain the benefits (performance, consistency) of native widgets? There's a bug in Mozilla right now that is a direct result of their decision. And unless I'm mistaken, there are only two solutions to the bug -- 1) duplicate the behavior inside the mozilla code itself, in which case you run the risk of being inconsistent if the native widget behavior changes; or 2) wrap the native widgets (with owner-drawn code, for instance, if you must have themes). I'm obviously ignoring the, "Don't worry about it," response, and it's pretty unlikely that response 2 will happen at this late stage, so expect more bloat and future inconsistencies.
yeah, that sure worked for divx (divx as in the failed dvd rental biz, not the streaming video codec)
(Yes, I realize that was sarcasm. But...) That's apples and oranges. Divx was flawed, because you were expected to pay nearly the same price as a normal DVD for the media, and then pay each time you play. Also, divx was a physical medium, while the example giving is not. I understood the examples to be freely-downloaded samples (think demos for games or shareware apps, or an online chapter of an upcoming book that entices you to purchase a dead-tree copy, or cdnow.com's audio clips that give you a taste of the songs on a CD but not the entire song) that expire after a certain amount of time, so that if you want to continue reading or using the media, you'll have to pay for it. Likely, that will be a one-time payment, not the pay-per-view model of divx.
Yes, I realize that there's probably nothing stopping people from implementing a divx-like scheme using DRM, but I would hope that the failure of the divx platform would act as a useful object lesson.
Actually, they finally got rid of that damn split infinitive, and used the phrase "let us go boldly..." or something to that extent (maybe "let us boldly go", but the point being, it no longer splits an infinitive).
How is it flamebait to mention that Microsoft is going strong, while other people in this thread mentioned the same about Apple? Moderators, just because you don't agree with a statement doesn't mean it's not true, nor that it's not worth seeing by other people.
Microsoft is still going steady. I've not heard of any layoffs or site closings, and they have a number of excellent products (well, your opinion may vary, but I'm of the opinion that Windows XP, PocketPC 2002, XBox, Flight Sim 2K, and so on are all great products) in line for release very soon, or already released in a few cases.
Probably not the kind of thing you'd expect to hear on slashdot, but it's the truth. Take it or leave it.
Then I can call tech support and bitch about the Nvidia driver that comes installed with no opengl support, and the new Nvidia Driver that wont play the new CS1.3 patch.
You must either be using an old beta, or having some sort of hardware problems, because the RC1 I'm running installed nVidia's 12.41 Detonator driver, and worked perfectly fine with DX and OpenGL. I'm now running the latest 21.xx driver in nVidia's Detonator XP series, and it works flawlessly. Granted, I don't play Half-Life or CS, but Quake 3, UT, Red Faction, Black & White, Giants, Startopia, Wolf3D MP test, etc all work beautifully.
And for benchmarking, you should head over to MadOnion and grab 3DMark2001, as that's the "standard" benchmark used for graphics these days (to the point where Max Payne actually published minimum 3DMark2k1 scores as part of the required and recommended specs on the box).
nothing much has changed except for the fact that normal users have access to raw network sockets.
Uh... you'd be correct about the raw sockets if the original poster had mentioned Win9x/ME, but since he asked about upgrading from Win2k, that's a non-issue -- NT has always had raw sockets.
Anyway, aside from the obvious GUI enhancements (which can easily be disabled by simply choosing to use the Classic theme, which also has the property of not really being a theme, and so doesn't use the resources other themes would), there are other niceties, like fast user switching (logout or switch to another user, but let your current user's applications continue to run), enhanced Terminal Services (aka, Remote Desktop), advanced video and imaging support built in, built-in firewalling (Win2k had packet filtering capabilities, but needed code to take advantage of that), enhanced file system encryption, better app compatibility (nice to have for those games that expect a user to be running win9x), better group policies, Cleartype (if he's using a laptop or LCD display), and more. Check out this feature chart for a better idea of what XP has that 2K doesn't.
What's so hard about setting up a fake account? Like you have to give them a "valid" e-mail address. Pshaw. Just pick something, like me@you.com, and have at it.
Re:How will this affect the Nintendo GameCube?
on
XBox Delayed
·
· Score: 1
The reality for the XBox will be different then for sony, because sony owns ALL the technology in the PS2. They can have their fab make as many chips as they need. Even nintendo can do this because they have a license to the PPC core from IBM. Microsoft, however, is in a different boat. They bought pieces of technology from companies that do business in a different world then Nintendo and Sony. The manufacturers that Microsoft buys from will have increasing costs where Sony and Nintendo have decreasing costs. Microsofts factories may get more efficient, but the 3rd party parts are what are going to get more expensive. The components are already ramped up and at the bottom of their price cycle. There is nowhere to go but up. Everywhere that Sony and Nintendo use a propriatary part and MS uses a commodity part they have a long term win over MS.
Three things --
The PS2 does not use completely proprietary parts. For example, it uses Rambus memory (yes, the kind of memory you use with a P4, and is expesive as all hell). Without digging into the architecture more than I have, I don't have any other examples, but I'm sure that the memory is not the only commodity piece.
You contradict yourself by noting that Nintendo has a license to the PPC core and thus will enjoy decreasing manufacturing costs, while insinuating that Microsoft can not possibly have the same sort of deal with Intel. Oh, and neither Nintendo nor Microsoft have their own fabs, so that's not an advantage for one or the other either.
How do Rambus, IBM, ATI, etc all do "do business in a different world" than Intel and nVidia?.
It doesn't matter that XBox isn't a PC in this manner, because it uses PC parts! The XBox will not follow the price decrease trend of a console, it will follow the trend of PC components because that's what it is made out of. The parts come from the same place no matter what they are used for. Intel will stop manufacturing P3s this year. If MS creates a demand for them with the XBox anyway, what do you think is going to happen to the cost of a P3 chip? Maybe MS will switch to P4. Having a different CPU in half of the boxes would make it a stable platform...
First off, the XBox is not PC hardware. It may use a number of PC hardware components, but the overall design is not a PC. The motherboard is unique to the XBox, for instance. I already covered the problem of Intel stopping manufacturing of P3 chips (what happens if IBM decides to stop manufacturing the PPC chip Nintendo needs? Or what happens if Rambus finally goes out of business?). As a bit of conjecture, let's think about this for a moment -- nVidia is partnering very closely with Microsoft on this. nVidia has their own fabs. nVidia stands to make a lot of money, which means investment in infrastructure to increase capacity would be expected. Intel and Microsoft are close partners. Therefore, would it not make sense for Intel to license the P3 design to nVidia for the purposes of fabricating chips for the XBox? Hell, they could integrate the design directly into the motherboard, rather than using the standard socket or slot connection. Of course, that's all just guesswork, but it makes as much sense as anything else.
I was not claiming that the $280 machine is a gaming machine comprable to the XBox, I'm saying that the $280 machine of tomorrow will be a better gaming machine then the XBox. A year ago before the Geforce2 was a gleam in the Nvidia retail channel's eye, I bet you would have killed to replace your TNT2/P3 500 with a 700 Mhz machine with a Gforce 2 MX 400.
Unless your defintion of "tomorrow" is really "two to three years from now", I really don't think you're going to be able to get a comparable PC for $280. Maybe $500 in a year and a half or so, but by that time the XBox will be $200 or less. And as far as my own machine goes, about a year ago I replaced my p3 500 with a tbird 1GHz, and about six months ago I replaced my TNT2 Ultra (which was the top of the line when I bought it 2.5 years ago) with a GeForce 3 (which was top of the line when I bought it, and currently still is). I'll probably keep that video card for two years, and then upgrade to whatever the latest and greatest nVidia board is at the time.
Care for a friendly wager about when the Gforce4 will come out (Or whatever they end up calling it)
I'll take that wager. Historically, nVidia works like so: Release a chipset, six months later release a new driver set that increases performance, three to six months after that release a "Ultra" refresh of the last chipset (and lately, release the neutered MX, the Quadro version, and the GO version for laptops) and/or another driver set with increased performance, roughly six months later release a brand new chipset. Right now, we're at the point in the cycle where the first updated drivers have been released since the GeForce3. That means that in 3-6 months (let's say 4.5 months, for the sake of argument), we'll see the GF3 Ultra, MX, Go, and Quadro. Then, six to nine months later, we'll see the theoretical GeForce 4 (or whatever they call it). That means, a minimum of 9 months (though probably averaging closer to a year) from now before we see the GF4, with the potential to be as much as 15 months out, or even more. Of course, I'm just going by nVidia's recent history, so I could easily be wrong.
Re:How will this affect the Nintendo GameCube?
on
XBox Delayed
·
· Score: 1
If I recall the X-Box has a 700Mhz CPU for starters.
Yes, but if you notice, I qualified exactly why I chose to price out a 1GHz processor, as opposed to a 700MHz, for a "comparable" machine -- the XBox will not be multi-tasking apps in the background (yes, there are always processes running in the background that will get time slices on a PC, even while playing games), the XBox is stable hardware so that developers can target it directly (compared to a PC, where you will always have to go through a higher-level API. Yes, the XBox uses DirectX. However, do you really think most third-generation XBox titles will use DirectX exclusively when the developers can use the money from their first title or two to develop their own low-level, raw hardware libraries?), and the fact that the XBox hardware is well-integrated makes it not-quite-a-PC.
I just put a 700Mhz box together for my mom for $280.
The likelihood of that machine being a true "gaming machine" is highly suspect. First off, I'd bet that your so-called "GeForce2" is really the MX version, which is neutered (half the rendering pipelines makes for roughly half the speed). A GeForce2 MX can't hold a candle to a GeForce3, nor will it be able to stand up to the XBox. Second, what kind of sound hardware is in that system? It's highly unlikely you're going to get hardware accelerated 3D-sound in Dolby Digital 5.1 from whatever budget sound chipset is in there. Third, see the above comment about CPU speeds. On top of that, it's likely that 700MHz CPU is a duron or celeron, which while being nice and cheap, are not quite the caliber of a P3 or Thunderbird. I could go on, but I realize that you probably never expected that machine to be used for gaming anyway (nothing more than solitaire or freecell).
Nvidia is coming out with new Geforce cards that are better then what's in the X-Box in a few months, so Geforce 3's will drop in price
The next chipset nVidia will release will likely be the GF3 Ultra. Don't expect the GF3 to drop too much (probably no more than $50) with this refresh. Maybe a year down the line, with the theoretical GF4, will you see the GF3 drop to the $150 or less mark (let me qualify this by saying that I'm not referring to any MX cards, as I don't consider them to be useful for gaming). What this means is that even six months from now, expect to spend $200 or more on a GF3.
The X-Box will not be able to drop in price much though, because they will need to continue using the same parts even after the rest of the industry moves on.
First, you need to understand how console manufacturing works. As the factories ramp up, and increase their effectiveness, the price of manufacturing decreases. This is why, as you mentioned, the PS2 will be getting cheaper -- manufacturing becomes more efficient as it progresses. The same scale will hold for the XBox. If Microsoft is able to charge $299 at launch, while the PS2 was $399 at launch and has just recently (past few months) hit $299, why wouldn't Microsoft be able to keep up in the price war with Sony?
As time goes on the X-Box is going to get more expensive to produce, and good PCs and PS2s are going to get cheaper.
By bringing the PS2 into the equation, your argument just backfired. Comparatively, yes, the XBox will probably appear to be more expensive to produce than a PC as time goes on (well, until you reach the point where building a comparable PC is more expensive due to scarcity of parts), but the XBox is a console, just as the PS2 is a console. They both use some proprietary parts (the PS2 more than the XBox), and they both use some commodity parts (the XBox more than the PS2). However, as I mentioned before, manufacturing trends tend towards a reduction of cost as volume and efficiency increases. There's no reason to expect that to be any different for the XBox than for the PS2. And to address your point about Intel discontinuing production of the P3 chipset, I'm sure Microsoft and Intel have anticipated this, and being long-time partners, have likely worked out a mutually beneficial deal wherein Microsoft will continue to get P3 chipsets for a decent price and Intel will continue to get Microsoft's business. Or something. (Let me qualify this by saying I have no clue what kind of arrangement they have, if any, so I'm not speaking with any type of authority here)
What it boils down to is that the XBox is a console, not a PC, and so standard console trends will most likely apply (I say "most likely" only because the XBox is not released yet, and thus I have no hard data to back this up). That is, hardware prices will continue to drop while games will continue to push the limits of the hardware more and more, doing things you'd never expect to see on that piece of hardware (for example, compare Final Fantasy IX to Final Fantasy VII on the PSOne). The first generation XBox titles may be something you'd possibly see on high-end PCs today, or mid-range PCs in a year. But given 2-3 years of development experience, and XBox titles will probably still be pushing what a high-end PC can do at that point in time, with lower hardware specs, because those specs are constant and the developers can leverage the knowledge they've gained from their past several games.
Re:How will this affect the Nintendo GameCube?
on
XBox Delayed
·
· Score: 1
it'll set you back as much as a PC that has the same features
Uh... what? Last I checked, the cheapest price on a GeForce 3 was $260 (check Pricewatch). That leaves you a total of roughly $40 to spend on the rest of your PC for it to have the same features as an XBox. For argument's sake, let's just do a bit of a price comparison:
Motherboard - $45 for a P3, $44 for an Athlon (Pricewatch)
1GHz P3 - $164 (see Sharky Extreme's Weekly CPU price list). Alternatively, an athlon 1GHz -- $74. Also, note that I'm using a higher speed CPU here, because with a PC you don't get the benefit of allowing the programmers to write directly to the hardware, so you need a bit more raw speed to compensate.
Sound Card - $150 Hercules Game Theater XP (or, you could go ~$100 for an SB Live!). Obviously, since nVidia designed the audio chipset for the XBox, you won't be able to get the exact same audio hardware (well, maybe not until nForce-based motherboards are released).
Video - $260 (the aforementioned GeForce 3). No other video card is worth mentioning, if you're strict about wanting near-XBox-level performance.
Memory - $30 (price for PC133 512MB, since more memory is always better when developers don't have the ability to micromanage the memory how they please). (Pricewatch)
That comes to a total of $801 (before S/H and tax) for a P3 system, or $710 for an AMD system. Both of those prices are more than twice the price of an XBox. Also note that I didn't take into account any software costs (I don't know what the expected OEM cost for XP Home is).
Yes, I do realize that you can buy a PC for much less than that, but it's not going to be the "equivalent" of an XBox, either.
Slashdot Mirror
Could you please give reasons or cite examples that prove that gaming is a weakness for Windows, rather than a strength? I don't want to get into the "Windows has a bigger market, and so that's the only reason it has a large market for games" argument, as that doesn't address the issue -- specifically, that Windows is technically inadequate for gaming while Linux is technically superior (extrapolating from your statement that gaming is a weakness of Windows, and that Linux should attempt to beat Windows there).
I'm serious, here. I don't see how you can justify saying that gaming on Windows is a weakness, so please give me reasons. Thanks.
Maybe so, but why must it be a VMS relationship? Hint: MS is also an abbreviation for Microsoft ...
However, the official company line, as I stated, is that it doesn't stand for anything. If you want the real story, dig up whoever came up with that name, and ask him
Please note that KDE is simply a desktop environment/object model/bunch of apps. If Microsoft only changed the interface between win3.x and win2k (or even between win3.x and win95), then that would be a valid comparison. However, the evolutions you refer to involve the core operating system as well (especially your comparison of win3.x to win2k, but even win3.x to win95 included core OS changes, such as the switch to native 32-bit protected mode, using DOS only as a boot strap, rather than being little more than a DOS shell).
KDE is a great product, and I agree that it has come far in a relatively short amount of time, but please compare apples to apples. And don't forget that KDE didn't have to do all the "difficult" research that Microsoft did. 12 years after the GUI became "mainstream" (1984, Apple Macintosh), KDE began their project. Both Apple and Microsoft had gone through numerous iterations, making mistakes on the way, and eventually coming up with paradigms that Just Work. KDE was able to use all this design that came before it. (Note that I'm not saying that's a bad thing.)
Err, wrong. NT has no VMS code in it at all. Perhaps you're referring to the fact that Microsoft hired a number of big-time VMS developers to create NT? That would explain VMS-isms in NT, while supporting the fact that NT != VMS. As far as the acronym goes, that's pretty much BS (in the way that crap like numerology is BS. You can always come up with those types of "interesting" correlations that mean absolutely nothing). The company line on NT is that it has no meaning. It's simply the letters 'N' and 'T'. "New Technology" is something that the media dreamed up to assign meaning where there was none.
Scheme (and lisp, though I haven't played around much with CL) is flexible enough to let your program procedurally or OO. It's a functional language, and relies a lot on recursion, but that doesn't mean you have to recurse. There is syntactic sugar to write things such as for loops or while loops (obviously I'm using the C/Java style syntax here, because it's been forever since I've used scheme). That syntax may very well translate into recursion calls, but as far as programming goes, it looks procedural. OO, when I learned Scheme, was more of a message-passing type of paradigm (think ObjC, if you're familiar with that), rather than a class.method type of syntax. The point is not the syntax, but the concept, and scheme lets you explore all three major paradigms within a single language. The best C++ can do is two out of three, and Java's pretty much a one-pony show (OO, and screw you if you want to do anything else), though I guess you could hack your way into a procedural paradigm (lots of static methods, for instance).
As far as I know, it's encouraged that you program recursively in scheme (specifically, use tail recursion if at all possible, for performance reasons), but that wasn't really my point. My point was that you can get a taste of all three with only one language, one syntax.
Why am I not surprised to see Rahul kicking in with the LISP material? Excellent points, all.
I think you misunderstood the point I was trying to make (which is as much my fault as yours, as I only mentioned it once, in passing). That major point was that scheme/lisp makes for a very good introductory language. You know, your first one or two CS classes, where you start learning the core concepts, but before you could even dream about being able to apply your new-found knowledge to real world tasks. It's extremely important in those early stages to be able to level the playing field. It's great if a student comes into the curriculum already knowing C++, Java, or whatever else (as long as s/he hasn't formed any bad habits, anyway, which is unlikely). However, there are always going to be neophytes that are interested in computer science but have never had the time or opportunity to learn a language on their own. Choosing a language such as scheme (for example. You could pick any easy-to-learn-but-obscure language, if you really want) makes it so that those with prior language knowledge aren't at too much of an advantage, and those that have no prior knowledge are not at too much of a disadvantage. There's always the oddball that comes into such a class already konwing scheme, but that's much rarer than if said class were taught in Java (for example). Also, as a vehicle for teaching early CS concepts (the major types of paradigms, for example), scheme excels. With C++, you can't write functional code ("functional" meaning "functions are first-class objects, a la scheme, lisp, sml, etc" not "working"). With Java, it's hard to write anything but OO code. With scheme, you can introduce all through concepts within the bounds of a single language. This is perfect for presenting the concepts without relying overly much on syntax.
Just to fill in a little bit of my own background, I graduated from the University of Illinois - Urbana/Champaign a little over a year and a half ago. When I began my education there, the initial CS course for CS majors was taught in scheme, so perhaps I'm a little biased. However, roughly two years into my education, the school began moving classes over to java, beginning with that class. Having younger friends who took this class in java, I saw a noticeable deficiency of various core concepts that they should've been taught in that class. I'm not blaming java 100% for that, but it surely owns some of the guilt. As far as later classes go, I have no problem with them using whatever language is appropriate (typically prolog and lisp for AI work, C++ or java for data structures, and so on), but to teach an introductory course in an infelxible language is doing a disservice to the students.
OOP is not C++-specific. Believe it or not, you can use other programming paradigms in scheme than just functional programming. You can write procedural code, if you wish, or even OO code. The point of using Scheme in introductory CS classes is two-fold.
Even though it's unlikely scheme is going to directly affect your job marketability, there are good reasons for using it in education. Foremost of the reasons is that a four-year Computer Science degree is aimed at doing more than just developing currently-marketable talents. You're learning how to think and problem-solve, and how to learn, so that in five years when Java is no more, or when C++ finally goes by the way-side, or when whatever marketable skill you have is no longer applicable (and that will eventually be the case), you are capable of quickly grasping the new technologies because you have learned how to learn. If you don't want to learn this, don't bother with a university degree. A two-year tech college, or even a couple of well-chosen certifications (guh, don't even get me started on the uselessness of those) will be much better for you, and save you money in the short run. (In the long-run, you're going to continue to pay out the rear to keep your "education" up-to-date by taking more classes or certifications.)
Either you have some severe reading comprehension problems, or you didn't even bother to read my post. Try reading it again. The .NET Framework (CLR and C#) has been submitted to ECMA, and thus anyone may write their own implementations. While it's true that the .NET Servers (Hailstorm, for instance) are Windows-only, there's nothing that says a well-implemented CLR (for instance, the Mono project) will not be able to run the bytecode for those servers (assuming, of course that the .NET servers are built using the .NET Framework, and thus target the CLR). As well, .NET is a concept, that of XML-based web services, and a platform, built on the .NET Framework (which I've already established has the potential to be cross-platform, where "platform" here refers to cpu/os combinations).
If you want to jerk your knee, that's fine. But at least pick apart what you think is wrong with my post.
For now, yes, the .NET framework is only available for Windows. However, Microsoft has committed to providing a reference implementation for the *BSDs (FreeBSD, I believe), and other projects like Mono have sprung up to bring an implementation to Linux and other unix-like operating systems. Since Microsoft has submitted both the CLR and C# to ECMA for standardization (say what you will about ECMA, but at least it's a standards body), anybody can write their own implementation. Sun's backed out several times on submitting Java to ECMA.
That would be true, if it were the case that CLR bytecode only ran under the VM. However, that's not the case at all. The CLR has the ability to compile its bytecode down to native code for whatever machine you're on. Most likely the way this will happen is that CLR bytecode will be "shipped" (in a box, or as a download), and as part of the installation that bytecode will get compiled to your platform. What that means is that, taking a Windows-only view for a moment, when you buy Office.NET (just as an example -- I don't know whether Office.NET will be targetting the CLR or not), it won't matter whether you're running on a 32-bit x86-based system, or on a 64-bit iTanium (or whatever AMD's 64-bit chip is called), the same version will run on both. And with native speed, because after installation, you'll be running native code. Obviously, it's developer choice whether or not to compile down to native code, but that's the point -- the choice exists. And given full CLR implementations on other platforms, I don't see any reason why pure CLR bytecode wouldn't be perfectly cross platform, even to the point of compiling down to native code and running as a native app on your chosen system. Perhaps this is how we'll eventually see IE, Office, etc on Linux? (Through the efforts of Mono)
Check out http://www.microsoft.com/net/whatis.asp for an explanation on what .NET is. Take special note that .NET is not the Common Language Runtime, or the C# programming language, or Visual Studio.NET, or Visual Basic.NET, or the SOAP Toolkit, etc. Those are part of the .NET Framework, or the platform that enables you to build .NET services (since .NET is all about XML-based web services).
As far as what benefit you gain, that's twofold. With the .NET Framework, specifically the Common Language Runtime, you gain the ability to easily work with objects across many different languages, without any grunt work to get in the way (such as making sure you write everything as a COM object, and doing your own reference counting, and making sure you initialize and deinitialize COM). And since all the objects from code targetting the CLR are exposed as COM objects, you can even use them from languages that don't support the runtime, such as C, non-Managed C++ (aka, C++), VB6, Delphi, or any other language that supports COM objects.
.NET itself is more about server-server communication over the web. By passing around SOAP messages (via SSL, when security is an issue), you can implement anything from alerting users that they're being out-bid on something like eBay, to providing stock quotes more easily (without having to "scrape" html pages), to offering choice hotel information when you book a plane flight, and so on. Yes, all of that can be done now, but .NET aims to make it much easier. The potential for XML-based web services is pretty much bounded only by your (editorial your) imagination, and since it's all based on standard communication methods (HTTP(s), SOAP), you won't have to define new protocols for passing data around each time you want to do something new.
There are similar things out there, such as XML-RPC, but they don't focus as much on providing web services as .NET does.
Maybe I missed the point, but it's a migration tool. It's not meant to take the place of Java, or even really compete with Java, other than it makes it possible for developers to take their existing java code and move it to the .NET platform with relatively few changes. This means the old objects are now accessible to all .NET languages (C#, VB, Managed-C++, and all the other marginal languages that have been ported), making it less painful to move over to C#. Until the old modules are reimplemented, they're still available. Moreover, even non-.NET languages will have access to those objects as COM objects, since that's a benefit of the CLR. So if you want to write code in C, or non-managed C++, you can still get at those objects (which you couldn't do before without extra work).
Exactly! Take a look at http://www.mysql.com/doc/B/r/Broken_Foreign_KEY.ht ml and see why they don't have foreign key support yet. They simply say it's scheduled for inclusion in the "near future" (I'm not sure what their definition of "near" is, but that page has been up for months now, and foreign key support still isn't slated for 4.0 or 4.1). Don't hold your breath, and either switch to a real rdbms (a la pgsql), or continue to work around mysql's deficiencies on an app-by-app basis.
With the introduction of the Berkely DB table type, MySQL gained transactional support. It'd be nice to have native transactions for all table types, but at least this is better than nothing at all. Of course, if you want to complain about useful-but-missing features, complain about decent stored procedure support (coming, but the keyword here is "decent" -- if they only support one language, like perl, then it becomes useless), foreign keys, subselects (apparently coming in 4.1), and triggers. Of course, the way the MySQL project seems to be going, they're going to end up reinventing the wheel originally designed by Oracle 20+ years ago, while steadfastly denying that the missing functionality is useful up until the point where they announce that they'll be adding said functionality.
All the applications you mentioned are "creative" applications in one form or another (media players, image manipulators). Skinning is an accepted method of bringing forth this creative side. Even Windows XP has acknowledged the usefulness of skinning with its new Visual Styles. However, if you look at productivity-type applications (office suites, text editors, fax apps, etc), you'll notice that most do not deviate significantly from the published guidelines for their target OS, and those that do fail miserably (IBM had a suite of apps that had "real-life" skins, like a fax app that looked like a fax machine, a phone that looked like a phone, a PIM that looked like a day planner, and so on. The suite failed because the interface was awful. The metaphor of the real object did not carry over to the application).
The important thing to get from this is that Mozilla is not a media player, or a fanciful image manipulator. It's a productivity tool, and differentiates its UI for no other reason than simply to be different. The code had to go into the XUL backend to support each OS anyway, why not simply make it a light wrapper around various toolkits (win32, aqua/carbon, gtk, qt, whatever) and gain the benefits (performance, consistency) of native widgets? There's a bug in Mozilla right now that is a direct result of their decision. And unless I'm mistaken, there are only two solutions to the bug -- 1) duplicate the behavior inside the mozilla code itself, in which case you run the risk of being inconsistent if the native widget behavior changes; or 2) wrap the native widgets (with owner-drawn code, for instance, if you must have themes). I'm obviously ignoring the, "Don't worry about it," response, and it's pretty unlikely that response 2 will happen at this late stage, so expect more bloat and future inconsistencies.
(Yes, I realize that was sarcasm. But ...) That's apples and oranges. Divx was flawed, because you were expected to pay nearly the same price as a normal DVD for the media, and then pay each time you play. Also, divx was a physical medium, while the example giving is not. I understood the examples to be freely-downloaded samples (think demos for games or shareware apps, or an online chapter of an upcoming book that entices you to purchase a dead-tree copy, or cdnow.com's audio clips that give you a taste of the songs on a CD but not the entire song) that expire after a certain amount of time, so that if you want to continue reading or using the media, you'll have to pay for it. Likely, that will be a one-time payment, not the pay-per-view model of divx.
Yes, I realize that there's probably nothing stopping people from implementing a divx-like scheme using DRM, but I would hope that the failure of the divx platform would act as a useful object lesson.
Actually, they finally got rid of that damn split infinitive, and used the phrase "let us go boldly ..." or something to that extent (maybe "let us boldly go", but the point being, it no longer splits an infinitive).
How is it flamebait to mention that Microsoft is going strong, while other people in this thread mentioned the same about Apple? Moderators, just because you don't agree with a statement doesn't mean it's not true, nor that it's not worth seeing by other people.
Microsoft is still going steady. I've not heard of any layoffs or site closings, and they have a number of excellent products (well, your opinion may vary, but I'm of the opinion that Windows XP, PocketPC 2002, XBox, Flight Sim 2K, and so on are all great products) in line for release very soon, or already released in a few cases.
Probably not the kind of thing you'd expect to hear on slashdot, but it's the truth. Take it or leave it.
You must either be using an old beta, or having some sort of hardware problems, because the RC1 I'm running installed nVidia's 12.41 Detonator driver, and worked perfectly fine with DX and OpenGL. I'm now running the latest 21.xx driver in nVidia's Detonator XP series, and it works flawlessly. Granted, I don't play Half-Life or CS, but Quake 3, UT, Red Faction, Black & White, Giants, Startopia, Wolf3D MP test, etc all work beautifully.
And for benchmarking, you should head over to MadOnion and grab 3DMark2001, as that's the "standard" benchmark used for graphics these days (to the point where Max Payne actually published minimum 3DMark2k1 scores as part of the required and recommended specs on the box).
Uh ... you'd be correct about the raw sockets if the original poster had mentioned Win9x/ME, but since he asked about upgrading from Win2k, that's a non-issue -- NT has always had raw sockets.
Anyway, aside from the obvious GUI enhancements (which can easily be disabled by simply choosing to use the Classic theme, which also has the property of not really being a theme, and so doesn't use the resources other themes would), there are other niceties, like fast user switching (logout or switch to another user, but let your current user's applications continue to run), enhanced Terminal Services (aka, Remote Desktop), advanced video and imaging support built in, built-in firewalling (Win2k had packet filtering capabilities, but needed code to take advantage of that), enhanced file system encryption, better app compatibility (nice to have for those games that expect a user to be running win9x), better group policies, Cleartype (if he's using a laptop or LCD display), and more. Check out this feature chart for a better idea of what XP has that 2K doesn't.
What's so hard about setting up a fake account? Like you have to give them a "valid" e-mail address. Pshaw. Just pick something, like me@you.com, and have at it.
Three things --
First off, the XBox is not PC hardware. It may use a number of PC hardware components, but the overall design is not a PC. The motherboard is unique to the XBox, for instance. I already covered the problem of Intel stopping manufacturing of P3 chips (what happens if IBM decides to stop manufacturing the PPC chip Nintendo needs? Or what happens if Rambus finally goes out of business?). As a bit of conjecture, let's think about this for a moment -- nVidia is partnering very closely with Microsoft on this. nVidia has their own fabs. nVidia stands to make a lot of money, which means investment in infrastructure to increase capacity would be expected. Intel and Microsoft are close partners. Therefore, would it not make sense for Intel to license the P3 design to nVidia for the purposes of fabricating chips for the XBox? Hell, they could integrate the design directly into the motherboard, rather than using the standard socket or slot connection. Of course, that's all just guesswork, but it makes as much sense as anything else.
Unless your defintion of "tomorrow" is really "two to three years from now", I really don't think you're going to be able to get a comparable PC for $280. Maybe $500 in a year and a half or so, but by that time the XBox will be $200 or less. And as far as my own machine goes, about a year ago I replaced my p3 500 with a tbird 1GHz, and about six months ago I replaced my TNT2 Ultra (which was the top of the line when I bought it 2.5 years ago) with a GeForce 3 (which was top of the line when I bought it, and currently still is). I'll probably keep that video card for two years, and then upgrade to whatever the latest and greatest nVidia board is at the time.
I'll take that wager. Historically, nVidia works like so: Release a chipset, six months later release a new driver set that increases performance, three to six months after that release a "Ultra" refresh of the last chipset (and lately, release the neutered MX, the Quadro version, and the GO version for laptops) and/or another driver set with increased performance, roughly six months later release a brand new chipset. Right now, we're at the point in the cycle where the first updated drivers have been released since the GeForce3. That means that in 3-6 months (let's say 4.5 months, for the sake of argument), we'll see the GF3 Ultra, MX, Go, and Quadro. Then, six to nine months later, we'll see the theoretical GeForce 4 (or whatever they call it). That means, a minimum of 9 months (though probably averaging closer to a year) from now before we see the GF4, with the potential to be as much as 15 months out, or even more. Of course, I'm just going by nVidia's recent history, so I could easily be wrong.
Yes, but if you notice, I qualified exactly why I chose to price out a 1GHz processor, as opposed to a 700MHz, for a "comparable" machine -- the XBox will not be multi-tasking apps in the background (yes, there are always processes running in the background that will get time slices on a PC, even while playing games), the XBox is stable hardware so that developers can target it directly (compared to a PC, where you will always have to go through a higher-level API. Yes, the XBox uses DirectX. However, do you really think most third-generation XBox titles will use DirectX exclusively when the developers can use the money from their first title or two to develop their own low-level, raw hardware libraries?), and the fact that the XBox hardware is well-integrated makes it not-quite-a-PC.
The likelihood of that machine being a true "gaming machine" is highly suspect. First off, I'd bet that your so-called "GeForce2" is really the MX version, which is neutered (half the rendering pipelines makes for roughly half the speed). A GeForce2 MX can't hold a candle to a GeForce3, nor will it be able to stand up to the XBox. Second, what kind of sound hardware is in that system? It's highly unlikely you're going to get hardware accelerated 3D-sound in Dolby Digital 5.1 from whatever budget sound chipset is in there. Third, see the above comment about CPU speeds. On top of that, it's likely that 700MHz CPU is a duron or celeron, which while being nice and cheap, are not quite the caliber of a P3 or Thunderbird. I could go on, but I realize that you probably never expected that machine to be used for gaming anyway (nothing more than solitaire or freecell).
The next chipset nVidia will release will likely be the GF3 Ultra. Don't expect the GF3 to drop too much (probably no more than $50) with this refresh. Maybe a year down the line, with the theoretical GF4, will you see the GF3 drop to the $150 or less mark (let me qualify this by saying that I'm not referring to any MX cards, as I don't consider them to be useful for gaming). What this means is that even six months from now, expect to spend $200 or more on a GF3.
First, you need to understand how console manufacturing works. As the factories ramp up, and increase their effectiveness, the price of manufacturing decreases. This is why, as you mentioned, the PS2 will be getting cheaper -- manufacturing becomes more efficient as it progresses. The same scale will hold for the XBox. If Microsoft is able to charge $299 at launch, while the PS2 was $399 at launch and has just recently (past few months) hit $299, why wouldn't Microsoft be able to keep up in the price war with Sony?
By bringing the PS2 into the equation, your argument just backfired. Comparatively, yes, the XBox will probably appear to be more expensive to produce than a PC as time goes on (well, until you reach the point where building a comparable PC is more expensive due to scarcity of parts), but the XBox is a console, just as the PS2 is a console. They both use some proprietary parts (the PS2 more than the XBox), and they both use some commodity parts (the XBox more than the PS2). However, as I mentioned before, manufacturing trends tend towards a reduction of cost as volume and efficiency increases. There's no reason to expect that to be any different for the XBox than for the PS2. And to address your point about Intel discontinuing production of the P3 chipset, I'm sure Microsoft and Intel have anticipated this, and being long-time partners, have likely worked out a mutually beneficial deal wherein Microsoft will continue to get P3 chipsets for a decent price and Intel will continue to get Microsoft's business. Or something. (Let me qualify this by saying I have no clue what kind of arrangement they have, if any, so I'm not speaking with any type of authority here)
What it boils down to is that the XBox is a console, not a PC, and so standard console trends will most likely apply (I say "most likely" only because the XBox is not released yet, and thus I have no hard data to back this up). That is, hardware prices will continue to drop while games will continue to push the limits of the hardware more and more, doing things you'd never expect to see on that piece of hardware (for example, compare Final Fantasy IX to Final Fantasy VII on the PSOne). The first generation XBox titles may be something you'd possibly see on high-end PCs today, or mid-range PCs in a year. But given 2-3 years of development experience, and XBox titles will probably still be pushing what a high-end PC can do at that point in time, with lower hardware specs, because those specs are constant and the developers can leverage the knowledge they've gained from their past several games.
Uh ... what? Last I checked, the cheapest price on a GeForce 3 was $260 (check Pricewatch). That leaves you a total of roughly $40 to spend on the rest of your PC for it to have the same features as an XBox. For argument's sake, let's just do a bit of a price comparison:
That comes to a total of $801 (before S/H and tax) for a P3 system, or $710 for an AMD system. Both of those prices are more than twice the price of an XBox. Also note that I didn't take into account any software costs (I don't know what the expected OEM cost for XP Home is).
Yes, I do realize that you can buy a PC for much less than that, but it's not going to be the "equivalent" of an XBox, either.