Here's Nintendo's at launch titles for the GameCube:
* Luigi's Mansion
* Wave Race
* Rogue Squadron
Just to add my own personal feelings on the launch of the GameCube, I (and I'm sure many others) REALLY wanted a Mario game. Instead we got stuck with Luigi's Mansion. I remember trying it in the store, hoping that it was really the Mario game I was looking for. No dice. I played it for about 15 minutes, and just didn't find it fun.
And who's idea was it to drag out another Wave Race? Wave Race 64 was fun for its time, but everyone knew that it was filler until Nintendo got the games ramped up. Launching with Wave Race as one of the three (!) titles when there was no Mario, was like screaming out to the world, "We have no software!" As for Rouge Sqaudron, it was definitely a Rouge. I mean, who thought that a specialized launch title like that would appeal to the greater Nintendo audience?
While I'm not one to harp on the small number of launch titles (the SNES didn't exactly have a huge selection either), the quality of those titles will make or break the system on the first day. When the N64 was released, everyone wanted Mario. We didn't care about Pilot Wings 64 or even the upcoming Wave Race. We had Mario 64, and it kept our attention for more than long enough for Nintendo to crank up their game-producing engine.
To put it bluntly, I lost all interest in the GameCube the day I played Luigi's Mansion. While Nintendo did eventually produce several hit titles for the GameCube, it was never enough to change my mind about wanting it. Titles like Wario World even managed to continue my impression that the GameCube games were dull. While I did briefly consider getting a unit for my kids, I found that pulling the old NES out of the closet was a lot more fun for them than the GameCube demos they tried in the store.
So in effect, the GameCube (IMHO) just didn't reach its target market. But with the Wii, every part of my being is alreay screaming, "I want one!" Especially if I can play the games with my kids.
I'm thinking that this is going to be a fun generation.:-)
The PC and the console markets are incredibly different. PC Gamers have always been willing to pay incredible amounts of money for the absolute best gaming experience possible. Console gamers, on the other hand, have usually pushed in the exact opposite direction. There was some attempt at bridging the gap between PC Gamers and Console Gamers, but all that lead to was the 3DO. And I think we all know how well that went over.
...they can stop trying to install toolbars into my frickin' web browser. No, I don't want another upteenth widget that reduces my vertical viewing area, I don't want your special Yahoo! browser bundled with Internet service, and I don't want you to install your toolbar when all I want is desktop search! Someone stop the insanity!
That's my opinion, anyway. I'm sure there are those people out there who looooove their toolbars.
Interesting enough, the NES was, adjusted for inflation, was a little more expensive than the average of the two 360 price points ($350 or so).
But it was right in line with the consoles that preceeded it. The Atari 2600 was introduced at $199.95, as was the Colecovision. The Intellivison was introduced at $299, and the Bally's Personal Arcade was $350 back in '79. So adjusting for inflation, consoles have continued to get cheaper over time. Which is in-line with general electronics which have also gotten cheaper with time.
The problem with adjusting for inflation when setting new price points is that consumers are used to prices going down. Over time they will expect more for less. So if you give them a price that used to be acceptable (after adjusting for inflation), they'll feel you're overcharging them. Ergo, it's wisest to allow your pricing to follow the general trend of products.
With that $11 price tag, you are assuming they are using regular flash memory. Perhaps they want the 40x flash, which is faster and more expensive.
I doubt it. The flash is only used to store games downloaded from the Virtual Console service. When you consider how small most of these games are (barely a megabyte or two for the largest), you realize that using fast flash would be a waste of money.
I believe the Jaguar was based on Motorala 6800 CPU (16 bit, Mac).
Not exactly. The Jaguar had a Motorola 68000, a 32 bit DSP, a 32 bit GPU, a 64 bit object processor, and a 64 bit blitter. Basically, it had a LOT of custom processors stuffed into its case. Not to mention the 2MB of RAM, which was exceedingly expensive back in 1993. (4MB was still pretty standard on PCs.)
I wonder, how much trouble is it to make something like this on your own?
Probably not too hard. You'd need to develop a disk controller that takes an address and translates it to the correct bank of flash cards. Otherwise, you should be able to build the board with off-the-shelf parts.
The biggest issue is expense. Flash retails at about $20-$30 per GB. Which means that a DIY jobbie would cost about $640 - $960 for a 32GB model. Ouch.
Why do people say "price point" instead of "price"?
Because we're discussing things in business terms. When you look at marketing a product like a game console, pricing becomes a major marketting factor. As a result, a random price like $231.45 would be a poor choice. (Even if you could sell it for less that way.) Instead, marketeers will develop a set of price "points".
i.e. Should the Wii sell at $149.99, $199.99, $249.99, or $299.99?
Each price "point" is carefully analysed for marketting potency as well as expected returns. The idea is to select one of those points that will meet your goals as well as maximize profits. (Or minimize losses in some forms of the razor-blade model.)
As a result, everyone is trying to second guess Nintendo's choice in price points. Will they hold to tradition and sell for $199.99, or will they maximize profits on each unit and sell for $249.99. Or at the extremes, will they shock the world with a $149.99 price point? Or will they not be able to meet cost predictions and hit the $299.99 price point?
I don't recall if the N64 was released with a game at launch, but I do recall there being bundles.
It wasn't. Mario64 was sort of a killer title for the N64 and was thus sold separately. That being said, part of the need to sell it separately was that Catridges were very costly back then. Now that the Wii uses inexpensive optical disks, it is again cost effective to bundle a game with the system.
The only question then is, what is Nintendo's strategy? The market has gotten used to the idea that pack-ins are a thing of the past. Will Nintendo go with the flow on this one, or will they attempt to do further damage to Sony and Microsoft's positions by throwing in a killer title with the console?
Personally, I hope they take the pack-in route. Not only will it make their competitors look bad, but it might force them to cough up a pack-in themselves. Which given the costs associated with developing a game on their consoles, would further dig in their losses on each unit.
Kingston 512MB Flash Cards can be had off of Amazon for $11.39. The list price is claimed to be $39.99. Even if we assume that the $11.39 figure undercuts the actual cost for some reason, I think it's safe to assume that the bulk cost would easily be within the range of those figures.
Similarly, complex universal remotes retail for about $19.95. You can usually find them much cheaper than MSRP. The sensor bar's cost will likely depend on what it's made of. Since we can probably assume plastic, it probably won't be too costly either. The Wii itself uses off-the-shelf components for its hardware, making the only questions the CPU and GPU. Both of these appear to be modified forms of existing processors. Which means that in bulk they should be very affordable for Nintendo. Therefore, it's likely that Nintendo will be able to sell the Wii at a $199 price point without taking any sort of loss. At $250, they'd probably be making a profit.
In comparison, both Microsoft and Sony have built their consoles out of highly customized and/or cutting edge hardware that require significant expense to manufacture. (At least initially.) The result is that they have to sell at far higher price points. In Microsoft's case, it's expected that they're losing money on each unit. (Though I seriously doubt that they're losing as much as the $200 that has been claimed by the media.) Both Sony and Microsoft should have paid attention to history. The Jaguar, Saturn, Neo-Geo, and Turbografix were all consoles that were on the cutting edge of technology. They all lost out to consoles that were inexpensive, built with off-the-shelf components (plus/minus a custom part or two), and were easily manufactured using less-than-cutting-edge technology.
there's a very important assumption wrapped up in the above sentence that doesn't apply to the F/OSS community. There's no single point of failure in the system.
There's always a choke point. The key is in finding it. Microsoft has always proved very resourceful in finding the chokepoint in its competitors. Be it monetary, technological, or legal, they find a way. Patents seem like the most likely avenue, because they could completely shut down the project. (Free or no.) And even without patents, the mere threat of them will prevent most people from adopting the technology on the critical path. Which means that Microsoft can take a "die on the vine" approach to killing the project.
When you look at it, it's shocking how well Microsoft's attacks against Open Source and Linux have faired. Even if we technologists don't buy it, enough of the public buys into their FUD to make a lot of problems for the industry. Now that was an unfocused attack. Imagine if 100% of Microsoft's resources were devoted to killing a single OSS project!
For an example of Microsoft's FUD in action, check out this argument (cache) that is happening between The Heartland institute and LXer. You should be able to spot a gaping hole in his logic within the first paragraph. Yet people really believe this stuff! Now imagine if Microsoft followed up a FUD campaign with strong new product annoucements that "Give you all the freedom of OSS, but with none of the communism." Visions of the Visi-On debacle are already lighting up in the back of my head...
Will someone please give the man some mod points? If I'm going to invoke his name in public, he can at least have a chance to defend himself.
Free Java was making its own inroads and there were several people working on various angles of it (Kaffe, the Transgaming company, Classpath, Japhar and much more).
Kaffe was a joke until the new guard took over (we had really high hopes for it too), and despite its long life Classpath couldn't produce anywhere near the necessary libraries until recently. Part of the problem with these projects, I think, is that they rejected most good Java developers because they were supposedly "tainted" by merely looking at the src.zip file. This left them with very little to work with.
Now, that being said, I am amused by your suggestion that *I* have to work on the projects that *you* consider important.
I'm not suggesting that you should have wasted your time with developing Java if you didn't want to. However, as I remember it, you were a big fan of the language but didn't care for the fact that it wasn't "free" as in "libre". Yet you jumped on the chance to develop Mono even though anything Microsoft touches is suspect by definition. RMS himself scolded the Mono project for even suggesting putting it onto the critical path.
Basically, it seems like you traded a trustworthy company (Sun) for a far less trustworthy company (Microsoft) with suspect intentions and faint promises of openness. Time will prove you correct or not, but it certainly scares the hell out of me. In addition, this choice sent a clear message to the OSS community that Java was no longer considered a desirable platform by the OSS leadership, and that Mono would be the future.
If you consider free Java important enough, you should step up and make it happen (contribute code, time or money).
That's always the old fallback answer isn't it? Well, *I* don't personally feel the need to build an OSS Java. (At least not in the form of a regular JVM. An operating system, OTOH...) However, Stallman feels very strongly about Java needing to escape the (and I quote) "trap" Sun has set for us. Unfortunately, he lacks the resources to carry through on a complete project, and the OSS community has taken not quite a decade to build up enough steam to make Classpath viable. They're getting very close now (a testament to the people who are working on the project), but they're still not there. It's hard to say when and if it will happen.
The fact that a full Java later struggled is a topic worth debating, and I have put some thoughts in a recent blog post here.
I do have to admit a bit sheepishly that I hadn't seen that entry before I posted. Considering that it has been hot news and addresses this very topic, it kind of steals a bit of my wind. But I do hold by my assertion that the CLR was a bad choice. Nothing prevented you from going with a 100% clean-room VM design. But instead you chose to accept Microsoft's "good will". While it's too late to turn back (assuming you wanted to), I still question the wisdom of the choice. We won't know anything about Microsoft's real reaction until Mono reaches some sort of critical mass.
Good luck to you. For your sake I hope you're proven correct.
But I've never heard of MS suing an open source project or programmer. All MS can really do is change their software so it no longer interops with OSS (which hardly "crushes" any OSS) or distribute GPL software without making the source available.
OSS hasn't posed a serious threat, yet. But if Mono does take off, Microsoft will be looking to crush it. Which means that they'll use any dirty trick they can think of, including patent warfare. While they're pretty new to patents these days, I have no doubt that they'll abuse them if they need to. Some examples of former history:
- Microsoft promised "royalties" to SpyGlass for each copy of IE sold. IE was released for free, thus Microsoft didn't have to pay. - Microsoft refused to license Windows 95 to IBM in time for the launch if IBM didn't sever their relationship with Netscape. - Microsoft "offered" to make Netscape a Windows-only product, and threatened to crush them if they didn't agree. (We know what happened there.) - Microsoft annouced the non-existant Windows product when Visi-On became a threat to their DOS market. - Microsoft refused to license NT 4.0 code to Citrix so that Citrix could update their NT 3.51 product. Instead, Citrix was "graciously" offered to give their technology to Microsoft in exchange for the ability to market their ICA protocol as an add-on to the Windows Terminal Services product created with Citrix's technology. - Microsoft sics the BSA on companies who refused to upgrade to the latest version of Windows. (Because they must be pirating, you know.)
Those are just a few off the top of my head. There's a whole backlog of Microsoft's misdeeds that I could dig up. The scary part is that former Microsoft employees often admit to these misdeeds with pride! (see: Barbarians Lead by Bill Gates for an example.) Microsoft will do anything it takes to ensure dominance. They are not an entity you willingly trust if you can help it.
There are plenty of Java libraries that are not part of Sun's source, and whose specs are not even freely available.
Name one. I dare you. I'm willing to bet you'll find the specs right here.
Of course if you RTFA, you would know that this is what Stallman means when he refers to the "Java trap".
No, this is not what Stallman refers to. He believes that Java is a trap because the source code is not "free as in freedom", and that you'll be "trapped" by the convenience. He also complains that Sun doesn't allow him to call his software an implementation of a standard unless he's 100% compliant with the standard. (Duh.) God forbid that Sun require that implementations of a standard actually implement the standard.
There are no restrictions on accessing partial records in BDB Java Edition -- it is the same as the BDB C Edition in this respect. However, you may have a misunderstanding about the way partial records work in both products: neither product has a BLOB capability.
Well that's not so good. I was under the impression that BDB was able to easily handle large binary chunks up to 4GBs in size. From this page:
Because both keys and values can be up to four gigabytes in length, a single record can store images, audio streams, or other large data values. Large values are not treated specially in Berkeley DB. They are simply broken into page-sized chunks, and reassembled on demand when the application needs them. Unlike some other database systems, Berkeley DB offers no special support for binary large objects (BLOBs).
So as long as the data stayed small enough for BDB to address (i.e. <4GB), I thought that BDB was supposed to only load into memory the requested chunk of data. Was this an incorrect assumption? If so, how are large data sets handled on systems with limited memory? On many of the systems that BDB has traditionally been deployed on, it wasn't unusual for several hundred megs to be too large for main memory AND swap space combined.
It seems to me that BDB should be using memory mapping to force the operating system to manage memory chunks for it. Which would allow BDB to handle data sizes far above the total available memory. I thought that BDB already did this?
They put the delegate functionality in the source code comments. If you think that's a good design, you need your head checked.
Delegates can be easily replicated in Java via Reflection, but Microsoft didn't use that solution, now did they? In any case, it's a heavily discouraged solution. Objects can do everything that delegates can do without the need for special facilities. (Not to mention that they don't fail silently when the signature is wrong. Blech.)
Good GUI frameworks are event-based, meaning that you provide a function to be called when some event (like mouse click) happens. The way around this in Java is a mess of inner classes and listeners.
Listener classes are the natural solution to the problem. There's no "mess in inner-classes" except those done by lazy or bad programmers. But then again, I've seen some pretty crappy C/C++/ObjC implementations too, so don't get too high and mighty here. Especially with delegates, which tend to make just as much of a mess as inner classes do in Java.
Why is Java bad for generating code?
All langauges are bad at generated code, preprocessor or no. Modern Java IDEs use special comments to lock out the areas that are generated. This works just about as well as generated C code. (i.e. Not very well.) The "correct" solution is to use a resource file. In GNOME this is done in GLADE, in Mozilla it's XUL, and in Java you can take your pick. In the past I've built my own, but JAXX looks very nice. It looks like it's based heavily on XUL. (Which I happen to like.)
It is also impossible to debug generated code (like a.jsp) because the generator can't indicate to the compiler what the original line number of the source code was in the corresponding generated code.
You don't know what the hell you're talking about. JSP is actually easier to debug thanks to the fact that the page is inverted into a Java Class file. You can simply take a look at the generated source to find the problem. Most modern servlet containers also insert the line numbers of the JSP file as debugging information. This allows you to look directly in the JSP for the problem. This is made possible by the flexible nature of the Class file format. Something that other languages don't share. (At least, not while maintaining the performance advantages of fully compiled code.)
Why is Java bad for interoperating with other languages? The JVM was designed to run the Java language as specified 10 years ago, and nothing more.
Java is great at interoperating with other languages!
Okay, snarky comment aside, JNI is intended to maintain the integrity of the Java environment. It's not particularly convenient, but it works. Considering how *little* code needs to be written in JNI, this isn't a big deal. Most JNI code these days is autogenerated. (e.g. The JOGL project.) If you find yourself writing more than a VERY small percentage of your app using JNI, then you're doing something wrong. Java has all the libraries you need. You should be using those, and then a few small bindings to handle anything that needs to be native for compatibility.
Since it's C++, it has to be recompiled for every platform you want to distribute your code on.
Let me get this straight. You're complaining about having to recompile C++ bindings to native code? Is the native code you're interfacing with somehow magically cross-platform or something?
Now if only something could be done about the SQL part.
BDB comes in a (generally better supported than the Java version) native version AND it doesn't support SQL. So I guess that's double-plus good in your book.
Now I'm not saying that this is necessarily Java's fault, but something is wrong with Azureus, and I think Java may be contributing to the problem.
It has nothing to do with Java, and everything to do with Azureus's design. Azureus gobbles up system resources for performance. In addition, it's constantly computing pretty charts, graphs, and statistics which further its resource requirements. Not to mention all the plugins it loads to provide extra features.
People keep holding up Azureus as a "problem" even though its only "problem" is that it's a heavyweight application. If you don't want its heafty requirements, use something else. It's perfectly understandable if not everyone wants to have The Ultimate Control(TM) over their BitTorrent downloads.
Personally, I run Azureus for weeks at time while downloading large numbers of CD and DVD files. (Hello, distros.) It hogs some resources while it does its work, but not enough to bug me. Just make sure you limit your upload speed to a rate slightly below what your line can handle, or it will completely choke the connection. I learned this the hard way with the *original* Python BitTorrent client. I'd have it running for one file, then wonder why I couldn't surf anywhere.:-)
No, he says that SQLite's library-based architecture is a plus in such systems.
Ah, sorry. I misread that part. My point still holds, however. He's talking about native code, not Java.
That's right, as an alternative, suggesting the use of BDB as an option in the systems he's talking about.
He's comparing the native version of BDB. SQLite doesn't come in a Java version. And for J2ME platforms, you don't get the option of deploying a native binary. You either deploy all-Java, or you don't deploy at all. Which means that he should have suggested HSQL instead of SQLite.
i don't think that java is slow; i actually think that BDB JE is slow (at least the previous version).
The previous version loaded the entire record prior to reading/writing. This was a huge performance bottleneck if you were working with records above a kilobyte or two in size. In addition, the old version didn't make use of memory mapping like the C version did.
I'm still trying to confirm the exact design of the new version, but I get the impression that they're using memory mapping in Java to give the same sort of performance and sub-record select capabilities as the C version. In addition, they've added the ability for BDB to act as a natural object store.
1. He suggests SQLite instead of BDB. Which means that the system must have native APIs exposed.
2. He mentions that BDB's "library-based archtecture" is a problem for said platforms. This denotes that he statically compiles SQLite on systems lacking dynamic libarary support.
3. Nowhere does he mention Java capabilities, such as the type you'd use to power an engine like HSQL. Instead he goes off into discussions about larger native engines like MySQL.
Argue all you want, but he was referring to non-Java platforms. As such, this version of BDB wouldn't be very useful. Also, while I haven't checked out the code yet, it's even likely that it won't run on a J2ME device due to optimizations utilizing memory mapping and File Channels. This is a key optimization in the C version, so it's likely that the design has been moved over to take advantage of J5SE's NIO capabilities.
OpenOffice isn't written in Java. It optionally uses it for various scripting components. The speed of OOo (which is actually pretty good these days) has everything to do with the performance of C/C++ code.
And Azureus?
Works fine here. Maybe if you put more than 64MB in your system, you'd see better response out of programs that are memory demanding? And I can't think of anything that demands more memory than an app that caches hundreds of megs of P2P data in memory.
Why does my system slow to a crawl for more than a minute when I launch Yahoo Pool or Slime Volleyball?
For the exact same reason your system slows down when you launch that ActiveX game embedded in a webpage. (Hint: The game is using CPU.)
Speaking of Slime Volleyball, why does that damn game play at different speeds on every computer?
Because the developer programmed it that way? Seems obvious to me.
I'm talking about a 3GHz/2GB machine here.
Suuuuurrrreee you are. Which is to say that you have a 1GHz machine with 64MB of RAM, but you felt like bashing Java because Firefox is running slow on your system. (Hint: It needs at least 128MB to handle all the preloading it does.)
This is almost as good as the "I've been waiting for 20 minutes for a file to copy!" troll. Keep up the bad work and maybe you'll even start a new slashdot meme. (You wish.) </sarcasm>
* Yes, the 64MB remark is sarcastic hyperbole. I don't know how much RAM you have, but you're obviously doing something wrong.
Just an FYI, daemonization (is that even a word?) has very little to do with Database Management Systems. Daemonizing is simply a way of providing remote database services via a client/server architecture. Prior to the rise of common networking, DBMSes were regularly compiled into the program itself. Some mainframes even went as far as to compile the byte-level database access routines into every program. Which meant that a change in database schema would require that all programs be recompiled.
<old-foggie>You kids these days, with your fancy-smancy "Database Servers" think you know everything there is to know about database management, don'chaya? Why, back in MY day, stored the data in a fixed width heirarchy of records, and we LIKED it that way!</old-foggie>;-)
I guess I don't quite see how this is true, given that Mono is just a re-implementation of emca standards.
Mono also attempts to replicate many of the.NET libraries, which are not covered by the ECMA standard. This is extremely dangerous given Microsoft's history of crushing anyone who's in their way. And yet its necessary if Mono wants to be compatible with.NET.
Microsoft gave away just enough to make it completely useless to anyone who isn't willing to copy their libraries. It's a bit like the ECMAScript standard. By itself, it's pretty useless. Which is why most browsers copy Netscape's "DOM 0" APIs. Thankfully, ECMAScript can ususally be coupled with DOM 1-3 and various other standardized technologies that make the platform useful. Microsoft has made no such coupling possible with.NET.
Also, to say that the OSS community has jumped into bed with anyone is a bit of a falsehood, given how nebulous we are.
'Tis true. However, as grown people here, I assume that we can all glean the intended meaning without resorting to a long explanation every time the topic is raised.:-)
In case anyone else is interested in this, the JavaDocs appear to make no mention of the previous limitations BDB imposed on partial records. Can anyone else confirm that BDB no longer loads the entire record to read partial records? If so, I have a few multi-gigabyte uses that this would be perfect for.:-)
Slashdot Mirror
Here's Nintendo's at launch titles for the GameCube:
:-)
* Luigi's Mansion
* Wave Race
* Rogue Squadron
Just to add my own personal feelings on the launch of the GameCube, I (and I'm sure many others) REALLY wanted a Mario game. Instead we got stuck with Luigi's Mansion. I remember trying it in the store, hoping that it was really the Mario game I was looking for. No dice. I played it for about 15 minutes, and just didn't find it fun.
And who's idea was it to drag out another Wave Race? Wave Race 64 was fun for its time, but everyone knew that it was filler until Nintendo got the games ramped up. Launching with Wave Race as one of the three (!) titles when there was no Mario, was like screaming out to the world, "We have no software!" As for Rouge Sqaudron, it was definitely a Rouge. I mean, who thought that a specialized launch title like that would appeal to the greater Nintendo audience?
While I'm not one to harp on the small number of launch titles (the SNES didn't exactly have a huge selection either), the quality of those titles will make or break the system on the first day. When the N64 was released, everyone wanted Mario. We didn't care about Pilot Wings 64 or even the upcoming Wave Race. We had Mario 64, and it kept our attention for more than long enough for Nintendo to crank up their game-producing engine.
To put it bluntly, I lost all interest in the GameCube the day I played Luigi's Mansion. While Nintendo did eventually produce several hit titles for the GameCube, it was never enough to change my mind about wanting it. Titles like Wario World even managed to continue my impression that the GameCube games were dull. While I did briefly consider getting a unit for my kids, I found that pulling the old NES out of the closet was a lot more fun for them than the GameCube demos they tried in the store.
So in effect, the GameCube (IMHO) just didn't reach its target market. But with the Wii, every part of my being is alreay screaming, "I want one!" Especially if I can play the games with my kids.
I'm thinking that this is going to be a fun generation.
The PC and the console markets are incredibly different. PC Gamers have always been willing to pay incredible amounts of money for the absolute best gaming experience possible. Console gamers, on the other hand, have usually pushed in the exact opposite direction. There was some attempt at bridging the gap between PC Gamers and Console Gamers, but all that lead to was the 3DO. And I think we all know how well that went over.
...they can stop trying to install toolbars into my frickin' web browser. No, I don't want another upteenth widget that reduces my vertical viewing area, I don't want your special Yahoo! browser bundled with Internet service, and I don't want you to install your toolbar when all I want is desktop search! Someone stop the insanity!
That's my opinion, anyway. I'm sure there are those people out there who looooove their toolbars.
Interesting enough, the NES was, adjusted for inflation, was a little more expensive than the average of the two 360 price points ($350 or so).
But it was right in line with the consoles that preceeded it. The Atari 2600 was introduced at $199.95, as was the Colecovision. The Intellivison was introduced at $299, and the Bally's Personal Arcade was $350 back in '79. So adjusting for inflation, consoles have continued to get cheaper over time. Which is in-line with general electronics which have also gotten cheaper with time.
The problem with adjusting for inflation when setting new price points is that consumers are used to prices going down. Over time they will expect more for less. So if you give them a price that used to be acceptable (after adjusting for inflation), they'll feel you're overcharging them. Ergo, it's wisest to allow your pricing to follow the general trend of products.
With that $11 price tag, you are assuming they are using regular flash memory. Perhaps they want the 40x flash, which is faster and more expensive.
I doubt it. The flash is only used to store games downloaded from the Virtual Console service. When you consider how small most of these games are (barely a megabyte or two for the largest), you realize that using fast flash would be a waste of money.
I believe the Jaguar was based on Motorala 6800 CPU (16 bit, Mac).
Not exactly. The Jaguar had a Motorola 68000, a 32 bit DSP, a 32 bit GPU, a 64 bit object processor, and a 64 bit blitter. Basically, it had a LOT of custom processors stuffed into its case. Not to mention the 2MB of RAM, which was exceedingly expensive back in 1993. (4MB was still pretty standard on PCs.)
I wonder, how much trouble is it to make something like this on your own?
Probably not too hard. You'd need to develop a disk controller that takes an address and translates it to the correct bank of flash cards. Otherwise, you should be able to build the board with off-the-shelf parts.
The biggest issue is expense. Flash retails at about $20-$30 per GB. Which means that a DIY jobbie would cost about $640 - $960 for a 32GB model. Ouch.
P.S. There's a Wikipedia Article on the matter. Note in the graph how sales droop between price points.
Why do people say "price point" instead of "price"?
:-)
Because we're discussing things in business terms. When you look at marketing a product like a game console, pricing becomes a major marketting factor. As a result, a random price like $231.45 would be a poor choice. (Even if you could sell it for less that way.) Instead, marketeers will develop a set of price "points".
i.e. Should the Wii sell at $149.99, $199.99, $249.99, or $299.99?
Each price "point" is carefully analysed for marketting potency as well as expected returns. The idea is to select one of those points that will meet your goals as well as maximize profits. (Or minimize losses in some forms of the razor-blade model.)
As a result, everyone is trying to second guess Nintendo's choice in price points. Will they hold to tradition and sell for $199.99, or will they maximize profits on each unit and sell for $249.99. Or at the extremes, will they shock the world with a $149.99 price point? Or will they not be able to meet cost predictions and hit the $299.99 price point?
Clear as mud?
I don't recall if the N64 was released with a game at launch, but I do recall there being bundles.
It wasn't. Mario64 was sort of a killer title for the N64 and was thus sold separately. That being said, part of the need to sell it separately was that Catridges were very costly back then. Now that the Wii uses inexpensive optical disks, it is again cost effective to bundle a game with the system.
The only question then is, what is Nintendo's strategy? The market has gotten used to the idea that pack-ins are a thing of the past. Will Nintendo go with the flow on this one, or will they attempt to do further damage to Sony and Microsoft's positions by throwing in a killer title with the console?
Personally, I hope they take the pack-in route. Not only will it make their competitors look bad, but it might force them to cough up a pack-in themselves. Which given the costs associated with developing a game on their consoles, would further dig in their losses on each unit.
Kingston 512MB Flash Cards can be had off of Amazon for $11.39. The list price is claimed to be $39.99. Even if we assume that the $11.39 figure undercuts the actual cost for some reason, I think it's safe to assume that the bulk cost would easily be within the range of those figures.
Similarly, complex universal remotes retail for about $19.95. You can usually find them much cheaper than MSRP. The sensor bar's cost will likely depend on what it's made of. Since we can probably assume plastic, it probably won't be too costly either. The Wii itself uses off-the-shelf components for its hardware, making the only questions the CPU and GPU. Both of these appear to be modified forms of existing processors. Which means that in bulk they should be very affordable for Nintendo. Therefore, it's likely that Nintendo will be able to sell the Wii at a $199 price point without taking any sort of loss. At $250, they'd probably be making a profit.
In comparison, both Microsoft and Sony have built their consoles out of highly customized and/or cutting edge hardware that require significant expense to manufacture. (At least initially.) The result is that they have to sell at far higher price points. In Microsoft's case, it's expected that they're losing money on each unit. (Though I seriously doubt that they're losing as much as the $200 that has been claimed by the media.) Both Sony and Microsoft should have paid attention to history. The Jaguar, Saturn, Neo-Geo, and Turbografix were all consoles that were on the cutting edge of technology. They all lost out to consoles that were inexpensive, built with off-the-shelf components (plus/minus a custom part or two), and were easily manufactured using less-than-cutting-edge technology.
there's a very important assumption wrapped up in the above sentence that doesn't apply to the F/OSS community. There's no single point of failure in the system.
There's always a choke point. The key is in finding it. Microsoft has always proved very resourceful in finding the chokepoint in its competitors. Be it monetary, technological, or legal, they find a way. Patents seem like the most likely avenue, because they could completely shut down the project. (Free or no.) And even without patents, the mere threat of them will prevent most people from adopting the technology on the critical path. Which means that Microsoft can take a "die on the vine" approach to killing the project.
When you look at it, it's shocking how well Microsoft's attacks against Open Source and Linux have faired. Even if we technologists don't buy it, enough of the public buys into their FUD to make a lot of problems for the industry. Now that was an unfocused attack. Imagine if 100% of Microsoft's resources were devoted to killing a single OSS project!
For an example of Microsoft's FUD in action, check out this argument (cache) that is happening between The Heartland institute and LXer. You should be able to spot a gaping hole in his logic within the first paragraph. Yet people really believe this stuff! Now imagine if Microsoft followed up a FUD campaign with strong new product annoucements that "Give you all the freedom of OSS, but with none of the communism." Visions of the Visi-On debacle are already lighting up in the back of my head...
Will someone please give the man some mod points? If I'm going to invoke his name in public, he can at least have a chance to defend himself.
Free Java was making its own inroads and there were several people working on various angles of it (Kaffe, the Transgaming company, Classpath, Japhar and much more).
Kaffe was a joke until the new guard took over (we had really high hopes for it too), and despite its long life Classpath couldn't produce anywhere near the necessary libraries until recently. Part of the problem with these projects, I think, is that they rejected most good Java developers because they were supposedly "tainted" by merely looking at the src.zip file. This left them with very little to work with.
Now, that being said, I am amused by your suggestion that *I* have to work on the projects that *you* consider important.
I'm not suggesting that you should have wasted your time with developing Java if you didn't want to. However, as I remember it, you were a big fan of the language but didn't care for the fact that it wasn't "free" as in "libre". Yet you jumped on the chance to develop Mono even though anything Microsoft touches is suspect by definition. RMS himself scolded the Mono project for even suggesting putting it onto the critical path.
Basically, it seems like you traded a trustworthy company (Sun) for a far less trustworthy company (Microsoft) with suspect intentions and faint promises of openness. Time will prove you correct or not, but it certainly scares the hell out of me. In addition, this choice sent a clear message to the OSS community that Java was no longer considered a desirable platform by the OSS leadership, and that Mono would be the future.
If you consider free Java important enough, you should step up and make it happen (contribute code, time or money).
That's always the old fallback answer isn't it? Well, *I* don't personally feel the need to build an OSS Java. (At least not in the form of a regular JVM. An operating system, OTOH...) However, Stallman feels very strongly about Java needing to escape the (and I quote) "trap" Sun has set for us. Unfortunately, he lacks the resources to carry through on a complete project, and the OSS community has taken not quite a decade to build up enough steam to make Classpath viable. They're getting very close now (a testament to the people who are working on the project), but they're still not there. It's hard to say when and if it will happen.
The fact that a full Java later struggled is a topic worth debating, and I have put some thoughts in a recent blog post here.
I do have to admit a bit sheepishly that I hadn't seen that entry before I posted. Considering that it has been hot news and addresses this very topic, it kind of steals a bit of my wind. But I do hold by my assertion that the CLR was a bad choice. Nothing prevented you from going with a 100% clean-room VM design. But instead you chose to accept Microsoft's "good will". While it's too late to turn back (assuming you wanted to), I still question the wisdom of the choice. We won't know anything about Microsoft's real reaction until Mono reaches some sort of critical mass.
Good luck to you. For your sake I hope you're proven correct.
But I've never heard of MS suing an open source project or programmer. All MS can really do is change their software so it no longer interops with OSS (which hardly "crushes" any OSS) or distribute GPL software without making the source available.
OSS hasn't posed a serious threat, yet. But if Mono does take off, Microsoft will be looking to crush it. Which means that they'll use any dirty trick they can think of, including patent warfare. While they're pretty new to patents these days, I have no doubt that they'll abuse them if they need to. Some examples of former history:
- Microsoft promised "royalties" to SpyGlass for each copy of IE sold. IE was released for free, thus Microsoft didn't have to pay.
- Microsoft refused to license Windows 95 to IBM in time for the launch if IBM didn't sever their relationship with Netscape.
- Microsoft "offered" to make Netscape a Windows-only product, and threatened to crush them if they didn't agree. (We know what happened there.)
- Microsoft annouced the non-existant Windows product when Visi-On became a threat to their DOS market.
- Microsoft refused to license NT 4.0 code to Citrix so that Citrix could update their NT 3.51 product. Instead, Citrix was "graciously" offered to give their technology to Microsoft in exchange for the ability to market their ICA protocol as an add-on to the Windows Terminal Services product created with Citrix's technology.
- Microsoft sics the BSA on companies who refused to upgrade to the latest version of Windows. (Because they must be pirating, you know.)
Those are just a few off the top of my head. There's a whole backlog of Microsoft's misdeeds that I could dig up. The scary part is that former Microsoft employees often admit to these misdeeds with pride! (see: Barbarians Lead by Bill Gates for an example.) Microsoft will do anything it takes to ensure dominance. They are not an entity you willingly trust if you can help it.
There are plenty of Java libraries that are not part of Sun's source, and whose specs are not even freely available.
Name one. I dare you. I'm willing to bet you'll find the specs right here.
Of course if you RTFA, you would know that this is what Stallman means when he refers to the "Java trap".
No, this is not what Stallman refers to. He believes that Java is a trap because the source code is not "free as in freedom", and that you'll be "trapped" by the convenience. He also complains that Sun doesn't allow him to call his software an implementation of a standard unless he's 100% compliant with the standard. (Duh.) God forbid that Sun require that implementations of a standard actually implement the standard.
There are no restrictions on accessing partial records in BDB Java Edition -- it is the same as the BDB C Edition in this respect. However, you may have a misunderstanding about the way partial records work in both products: neither product has a BLOB capability.
Well that's not so good. I was under the impression that BDB was able to easily handle large binary chunks up to 4GBs in size. From this page:
So as long as the data stayed small enough for BDB to address (i.e. <4GB), I thought that BDB was supposed to only load into memory the requested chunk of data. Was this an incorrect assumption? If so, how are large data sets handled on systems with limited memory? On many of the systems that BDB has traditionally been deployed on, it wasn't unusual for several hundred megs to be too large for main memory AND swap space combined.
It seems to me that BDB should be using memory mapping to force the operating system to manage memory chunks for it. Which would allow BDB to handle data sizes far above the total available memory. I thought that BDB already did this?
Anyway, thanks for your help!
What an incredibly incorrect mess.
.jsp) because the generator can't indicate to the compiler what the original line number of the source code was in the corresponding generated code.
Microsoft realized this and tried to fix Java.
They put the delegate functionality in the source code comments. If you think that's a good design, you need your head checked.
Delegates can be easily replicated in Java via Reflection, but Microsoft didn't use that solution, now did they? In any case, it's a heavily discouraged solution. Objects can do everything that delegates can do without the need for special facilities. (Not to mention that they don't fail silently when the signature is wrong. Blech.)
Good GUI frameworks are event-based, meaning that you provide a function to be called when some event (like mouse click) happens. The way around this in Java is a mess of inner classes and listeners.
Listener classes are the natural solution to the problem. There's no "mess in inner-classes" except those done by lazy or bad programmers. But then again, I've seen some pretty crappy C/C++/ObjC implementations too, so don't get too high and mighty here. Especially with delegates, which tend to make just as much of a mess as inner classes do in Java.
Why is Java bad for generating code?
All langauges are bad at generated code, preprocessor or no. Modern Java IDEs use special comments to lock out the areas that are generated. This works just about as well as generated C code. (i.e. Not very well.) The "correct" solution is to use a resource file. In GNOME this is done in GLADE, in Mozilla it's XUL, and in Java you can take your pick. In the past I've built my own, but JAXX looks very nice. It looks like it's based heavily on XUL. (Which I happen to like.)
It is also impossible to debug generated code (like a
You don't know what the hell you're talking about. JSP is actually easier to debug thanks to the fact that the page is inverted into a Java Class file. You can simply take a look at the generated source to find the problem. Most modern servlet containers also insert the line numbers of the JSP file as debugging information. This allows you to look directly in the JSP for the problem. This is made possible by the flexible nature of the Class file format. Something that other languages don't share. (At least, not while maintaining the performance advantages of fully compiled code.)
Why is Java bad for interoperating with other languages? The JVM was designed to run the Java language as specified 10 years ago, and nothing more.
Java is great at interoperating with other languages!
Okay, snarky comment aside, JNI is intended to maintain the integrity of the Java environment. It's not particularly convenient, but it works. Considering how *little* code needs to be written in JNI, this isn't a big deal. Most JNI code these days is autogenerated. (e.g. The JOGL project.) If you find yourself writing more than a VERY small percentage of your app using JNI, then you're doing something wrong. Java has all the libraries you need. You should be using those, and then a few small bindings to handle anything that needs to be native for compatibility.
An example of such a binding would be XPCOM.
Since it's C++, it has to be recompiled for every platform you want to distribute your code on.
Let me get this straight. You're complaining about having to recompile C++ bindings to native code? Is the native code you're interfacing with somehow magically cross-platform or something?
Now if only something could be done about the SQL part.
BDB comes in a (generally better supported than the Java version) native version AND it doesn't support SQL. So I guess that's double-plus good in your book.
Now I'm not saying that this is necessarily Java's fault, but something is wrong with Azureus, and I think Java may be contributing to the problem.
:-)
It has nothing to do with Java, and everything to do with Azureus's design. Azureus gobbles up system resources for performance. In addition, it's constantly computing pretty charts, graphs, and statistics which further its resource requirements. Not to mention all the plugins it loads to provide extra features.
People keep holding up Azureus as a "problem" even though its only "problem" is that it's a heavyweight application. If you don't want its heafty requirements, use something else. It's perfectly understandable if not everyone wants to have The Ultimate Control(TM) over their BitTorrent downloads.
Personally, I run Azureus for weeks at time while downloading large numbers of CD and DVD files. (Hello, distros.) It hogs some resources while it does its work, but not enough to bug me. Just make sure you limit your upload speed to a rate slightly below what your line can handle, or it will completely choke the connection. I learned this the hard way with the *original* Python BitTorrent client. I'd have it running for one file, then wonder why I couldn't surf anywhere.
No, he says that SQLite's library-based architecture is a plus in such systems.
Ah, sorry. I misread that part. My point still holds, however. He's talking about native code, not Java.
That's right, as an alternative, suggesting the use of BDB as an option in the systems he's talking about.
He's comparing the native version of BDB. SQLite doesn't come in a Java version. And for J2ME platforms, you don't get the option of deploying a native binary. You either deploy all-Java, or you don't deploy at all. Which means that he should have suggested HSQL instead of SQLite.
i don't think that java is slow; i actually think that BDB JE is slow (at least the previous version).
The previous version loaded the entire record prior to reading/writing. This was a huge performance bottleneck if you were working with records above a kilobyte or two in size. In addition, the old version didn't make use of memory mapping like the C version did.
I'm still trying to confirm the exact design of the new version, but I get the impression that they're using memory mapping in Java to give the same sort of performance and sub-record select capabilities as the C version. In addition, they've added the ability for BDB to act as a natural object store.
1. He suggests SQLite instead of BDB. Which means that the system must have native APIs exposed.
2. He mentions that BDB's "library-based archtecture" is a problem for said platforms. This denotes that he statically compiles SQLite on systems lacking dynamic libarary support.
3. Nowhere does he mention Java capabilities, such as the type you'd use to power an engine like HSQL. Instead he goes off into discussions about larger native engines like MySQL.
Argue all you want, but he was referring to non-Java platforms. As such, this version of BDB wouldn't be very useful. Also, while I haven't checked out the code yet, it's even likely that it won't run on a J2ME device due to optimizations utilizing memory mapping and File Channels. This is a key optimization in the C version, so it's likely that the design has been moved over to take advantage of J5SE's NIO capabilities.
But why is OpenOffice dog-ass slow?
OpenOffice isn't written in Java. It optionally uses it for various scripting components. The speed of OOo (which is actually pretty good these days) has everything to do with the performance of C/C++ code.
And Azureus?
Works fine here. Maybe if you put more than 64MB in your system, you'd see better response out of programs that are memory demanding? And I can't think of anything that demands more memory than an app that caches hundreds of megs of P2P data in memory.
Why does my system slow to a crawl for more than a minute when I launch Yahoo Pool or Slime Volleyball?
For the exact same reason your system slows down when you launch that ActiveX game embedded in a webpage. (Hint: The game is using CPU.)
Speaking of Slime Volleyball, why does that damn game play at different speeds on every computer?
Because the developer programmed it that way? Seems obvious to me.
I'm talking about a 3GHz/2GB machine here.
Suuuuurrrreee you are. Which is to say that you have a 1GHz machine with 64MB of RAM, but you felt like bashing Java because Firefox is running slow on your system. (Hint: It needs at least 128MB to handle all the preloading it does.)
This is almost as good as the "I've been waiting for 20 minutes for a file to copy!" troll. Keep up the bad work and maybe you'll even start a new slashdot meme. (You wish.) </sarcasm>
* Yes, the 64MB remark is sarcastic hyperbole. I don't know how much RAM you have, but you're obviously doing something wrong.
This is exactly the sort of thing Java was invented for.
Java wasn't invented to run on systems with no JVM and lack of dynamic library support. SQLite and BDB, however, will run on those systems.
Just an FYI, daemonization (is that even a word?) has very little to do with Database Management Systems. Daemonizing is simply a way of providing remote database services via a client/server architecture. Prior to the rise of common networking, DBMSes were regularly compiled into the program itself. Some mainframes even went as far as to compile the byte-level database access routines into every program. Which meant that a change in database schema would require that all programs be recompiled.
;-)
<old-foggie>You kids these days, with your fancy-smancy "Database Servers" think you know everything there is to know about database management, don'chaya? Why, back in MY day, stored the data in a fixed width heirarchy of records, and we LIKED it that way!</old-foggie>
I guess I don't quite see how this is true, given that Mono is just a re-implementation of emca standards.
.NET libraries, which are not covered by the ECMA standard. This is extremely dangerous given Microsoft's history of crushing anyone who's in their way. And yet its necessary if Mono wants to be compatible with .NET.
.NET.
:-)
Mono also attempts to replicate many of the
Microsoft gave away just enough to make it completely useless to anyone who isn't willing to copy their libraries. It's a bit like the ECMAScript standard. By itself, it's pretty useless. Which is why most browsers copy Netscape's "DOM 0" APIs. Thankfully, ECMAScript can ususally be coupled with DOM 1-3 and various other standardized technologies that make the platform useful. Microsoft has made no such coupling possible with
Also, to say that the OSS community has jumped into bed with anyone is a bit of a falsehood, given how nebulous we are.
'Tis true. However, as grown people here, I assume that we can all glean the intended meaning without resorting to a long explanation every time the topic is raised.
In case anyone else is interested in this, the JavaDocs appear to make no mention of the previous limitations BDB imposed on partial records. Can anyone else confirm that BDB no longer loads the entire record to read partial records? If so, I have a few multi-gigabyte uses that this would be perfect for. :-)