I was under the assumption anyone could be a Jedi if they just tried hard enough and not because of some noble upbringing or good genetics.
Is this where everyone who doesn't like midi-chlorians is coming from? I had no real problem with midi-chlorians, and I always thought force-usage did run in families (with the occasional random person getting just the right genes where previous family history was unknown).
Canon-wise, the only proof in the movies was Luke's statement of "the force is strong in my family" in ROTJ, which indicates that there may be at least some genetic reason for high force ability. Going down the list of official source, there's a book ("The Crystal Star", I think) which mentions the Emperor trying to breed two force-sensitive individuals to attempt to make a strong jedi (but resulted in a child that had no force ability at all). Dorsk 81 comes from a race of clones with no previously known force ability in his clone history, but both he and his predecessor (Dorsk 82) are force sensitive, showing the possibility of a random mutation which is then introduced to the succeeding clones.
If a company can sell fewer units for a greater cost, then it might be good. You sell at the point where the price and number of units sold maximize your profit, not where you can sell the most units.
Not that this is what is happening with the 360. The eBay numbers prove that the 360 is sold way below equilibrium price.
Re:Maybe a grain of salt, but it's what I'd predic
on
Wine vs Windows Benchmarks
·
· Score: 2, Insightful
They often do things under very specific conditions and are useless elsewhere. If you're not a compiler expert (which I definately am not), it's unlikely you'll have any apreciable performance gain. It's quite possible that you'll see a performance loss if things aren't done correctly. Even an expert may or may not get a gain.
I love Gentoo myself, but I'm not delusional about performance gains. I do it for the customizability it offers. For instance, last I checked, you could get a Debian package that contained the Perl bindings for Vim, or the Python bindings for Vim, but not both. With Gentoo, I can easily instruct Portage to build in both.
Read the article. These aren't dev-created benchmarks, but standard benchmark suites like 3DMark and Quake 3.
Some of the tests look really weird. For instance, in the 3DMark2000 Fill Rate test, Single Texture on Wine gets 2,402.8 MTexels/s and 11% behind Windows, but on the Multi-Texture test it soars to 6,695.1 MTexels/s and 74.5% in front of Windows. There's got to be some freaky driver code or something implemented oddly or some background process that wasn't noticed.
I don't think these benchmarks were run rigoriously enough to say anything, except that Wine is capable of running 3DMark.
Corp takeover. Grabbed an incredible ammount of items. If it had happened to me, I probably would have quit the game instead of trying to start over from scratch.
When 3dfx did SLI way back with the VooDoo 2, the first cards only had a single chipset ("GPU" had not been invented yet). A year or two later, when single-chipset VooDoo 2's were starting to show their age, SLI on a single card started to come out.
VooDoo 2 was a great chipset for its time. Held up with newer games well past its prime.
Of course, the real reason is that SLI makes spoiled rich kids spend twice as much on their video cards, a reason which goes away if you put two GPUs on one card . . .
No, read the article. In this case, Darl very specifically mentioned the initial purchase price. We can argue about TCO costs, but that's not the argument Darl made.
No, the optimial is that all users are also node admins. Freenet is highly scalable by design, and actually works better (at least on a theoretical basis) if all users run nodes.
FCP is specifically designed to work over localhost only, and (last I checked) the current implementation only allows external connections from specific IP addresses. The constant connection/teardown of the protocol makes it rather inefficient for remote connections.
I don't think they're sold anymore, and they're so cheep now that you wouldn't save much, anyway. Just ignore whatever extras come with the board.
In fact, you just might save a few bucks in the long run by using the on-board stuff, since it may use less power than the equivilent slot-based stuff.
Steam's anti-piracy ideas are utter crap. That I agree with.
However, there's something far more important here: elimination of middle-men. Through Steam, Valve can sell games directly without a publisher. Game development houses tend to get a patheticlly small percentage of the total revenue from their game. Publishers suck it all up. Getting rid of publishers is a Good Thing, and something I've been waiting for the Internet to do for a while.
I doubt it. People are going to complain (fairly) for a week or so. Then Valve will work out the problems. People will be throwing saw blades at zombies and forget the Steam problems ever happened.
Further, this primarily effects the people who bought it at the store. Valve gets far more profit per unit sold when a player buys the game over Steam. People like me who preloaded and bought the game over Steam had little trouble.
Funny you mention SWG, as that's where I picked up opinons that completely agree with what was in the article.
Take the Jedi Problem, for instance. The SWG timeline is in a place where there should be almost no Jedi. If there are any around, they're in hiding from the Empire. However, players want to be a Jedi (point #1 from the article), for various reasons, so the developers made it possible to become one. Obviously, in keeping with this area of the Star Wars timeline, Jedi numbers should at least be kept low, and those that are should be in constant hiding.
Let's go over the orginal system for becoming a Jedi, just for review (this was replaced recently, but most existing Jedi right now became Jedi like this):
There are around 30 professions in the game. When your character is created, five of them are picked at random. You aren't told what they are. If you master all five, you open up your Force Sensitive slot and can work your way through the Jedi proffessions. To help this process along, 'holocrons' were added that would tell you one of the proffessions you needed. Master that, get another holocron, and then you get the second proffession, and so on. But you won't be told what the last proffession is.
Now, that's a daunting challenge. If I was a developer sitting back 1-2 years ago, before the game was even in beta, I would have thought that this, combined with permadeath on Jedi, would be plenty to keep the Jedi population low and in hiding.
But that's not what happend. Players complained that permadeath wasn't fair, so it was removed (see point #2 and #4 in the article). The developer's big mistake, and one that I would have made myself if I was a dev, is in underestimating the willingness of some players to be Jedi (which could fall under point #3, in that the game is based on a movie, and people want it to be just like their interpretation of that movie). Optimized grinds were created that would allow many professions to be mastered in a few hours--if you were willing to go through the utter boardom of sitting there, clicking the same blasted buttons over and over again. Someone with time off and enough drive and willingness to be board out of their skull could make Jedi in a week.
Thus, there are Jedi everywhere in SWG. Many of the non-Jedi complain about the large precentage of Jedi players, which also falls under our reinterpreted point #3.
More people complain, so the devs decide to do something about it by redevloping the Jedi system. The same people then complain about that (point #4), whining that the Jedi got two major game patches to themselves. But that's exactly what it would take to fix the system!
So here's my conclusion: The Jedi Problem is more the player community's fault than the devs. The devs made a system that, in all reasonableness, would seem to be able to keep the Jedi population low. They turned out to have missed a variable (the number of players determined enough to do the grind), and they were forced to conced the removal of a key design point (permadeath) or risk having lots of players delete their accounts and take the cash flow with them.
Let's take the Mario Bros. movie for example: The characters of Mario and Luigi are pretty well done, and more or less what you'd expect from a pre-Mushroom kingdom encounter. The movie plot? Relates NOT AT ALL to the plot of any of the games. A perfect example of game plot being disregarded as not worthy.
Huh? None of the Mario games had a plot beyond "save the princess".
Of course, the thing most remembered about most games is the music
Nintendo often does versions of their game music for full orchestras, and they're great. I particularly liked some of the Zelda music they did. You'll have to scrounge around eBay to find a CD of it, though.
Funny, I rather liked the current crop of games, for the exact same reason.
I don't think Metroid will work well as a movie, though (unless it's an artsy independant film). A lone, silent warrior in dark caves just doesn't work. In any case, with Woo directing, it should be a good blow-stuff-up movie.
You can't just write a page and stick it on your server
Sure you can, depending on your server's configuration. Under the Apache handler, if you're using the Gopher::Server::RequestHandler::File handler, then you can just stick it in your directory structure. Other handlers (which have yet to be written) may or may not allow this, but if they don't, it'll be because they do complex things that need more information than what is available in the file itself.
They're also a big reason web browser support is so poor.
If you're talking about desktop browsers, sure. But what about my cell phone, which is fully Internet connected? Using HTTP+HTML, I have to do all sorts of things to my markup to get it to look right, and the result will probably look too minimalistic on a desktop browser. With a Gopher client, the cell phone's client would be able to format the menu on it's own.
Menu items noted with a '!' (upside-down 'i') type are information that can be displayed to the user. This would be far less obnoxious than the singing, dancing banner ads on the web today (saw one a few weeks ago with a ~20 sec mpeg embedded in it!), but would still generate a little revenue to support servers.
There is a translater available that will convert a Gopher menu into HTML. But if you're running under Apache, you're probably better off switching off the directory indexer and pointing your document root to the same place as your Gopher server. It'll be almost the same thing as far as a standard desktop browser is concerned.
If you're running PyGopherd (an excelent server written in Python), then it can automatically detect an HTTP request on the Gopher port and handle it correctly.
gopher.quux.org is a huge repository (many of the quotes you see at the top of my site came out of QUUX's fortune files). I eventually plan on expanding gopher.wumpus-cave.net into a repository for weird or historical technology (Trebuchets built out of Legos, PDP-11 assembler opcodes, etc.), but right now it just has some Gopher implementations and some pictures of a burning stuffed Barney doll:)
One advantage is that any device can support Gopher without doing strange things to the text. Gopher orginizes everything in a heriarchal menu (tab-delimited), and then the client gets to do whatever it wants with it. You don't need to worry about "how does my page look on a PDA screen?", because a theoretical Gopher client on a PDA would already know how to format the output to be readable there. This is specifically because the Gopher protocol is dumb by design.
Exploring neat ideas for interactions between Gopher servers and clients is my hidden goal behind this project. One idea I have is to make a backend repository for game ROMs that use Gopher+ INFO blocks to send the information on how to execute that ROM for a given emulator. Emulators that require special ROMs (such as MAME, which changes what is actually needed to execute a game in almost every new version) can be handled with Gopher+ VIEWS. But I'll have to get down to implementing Gopher+ before I can do that.
I don't view Gopher as a replacement for the web, but as a nice augmentation in certain situations.
Slashdot Mirror
I was under the assumption anyone could be a Jedi if they just tried hard enough and not because of some noble upbringing or good genetics.
Is this where everyone who doesn't like midi-chlorians is coming from? I had no real problem with midi-chlorians, and I always thought force-usage did run in families (with the occasional random person getting just the right genes where previous family history was unknown).
Canon-wise, the only proof in the movies was Luke's statement of "the force is strong in my family" in ROTJ, which indicates that there may be at least some genetic reason for high force ability. Going down the list of official source, there's a book ("The Crystal Star", I think) which mentions the Emperor trying to breed two force-sensitive individuals to attempt to make a strong jedi (but resulted in a child that had no force ability at all). Dorsk 81 comes from a race of clones with no previously known force ability in his clone history, but both he and his predecessor (Dorsk 82) are force sensitive, showing the possibility of a random mutation which is then introduced to the succeeding clones.
If a company can sell fewer units for a greater cost, then it might be good. You sell at the point where the price and number of units sold maximize your profit, not where you can sell the most units.
Not that this is what is happening with the 360. The eBay numbers prove that the 360 is sold way below equilibrium price.
They often do things under very specific conditions and are useless elsewhere. If you're not a compiler expert (which I definately am not), it's unlikely you'll have any apreciable performance gain. It's quite possible that you'll see a performance loss if things aren't done correctly. Even an expert may or may not get a gain.
I love Gentoo myself, but I'm not delusional about performance gains. I do it for the customizability it offers. For instance, last I checked, you could get a Debian package that contained the Perl bindings for Vim, or the Python bindings for Vim, but not both. With Gentoo, I can easily instruct Portage to build in both.
Read the article. These aren't dev-created benchmarks, but standard benchmark suites like 3DMark and Quake 3.
Some of the tests look really weird. For instance, in the 3DMark2000 Fill Rate test, Single Texture on Wine gets 2,402.8 MTexels/s and 11% behind Windows, but on the Multi-Texture test it soars to 6,695.1 MTexels/s and 74.5% in front of Windows. There's got to be some freaky driver code or something implemented oddly or some background process that wasn't noticed.
I don't think these benchmarks were run rigoriously enough to say anything, except that Wine is capable of running 3DMark.
Corp takeover. Grabbed an incredible ammount of items. If it had happened to me, I probably would have quit the game instead of trying to start over from scratch.
Still 100% return on an investment isn't bad.
No, 100% return on investment is money that would have been better off sitting in a savings account generating interest.
Still, Serenity will probably have great DVD sales, so it can be expected to be profitable.
When 3dfx did SLI way back with the VooDoo 2, the first cards only had a single chipset ("GPU" had not been invented yet). A year or two later, when single-chipset VooDoo 2's were starting to show their age, SLI on a single card started to come out.
VooDoo 2 was a great chipset for its time. Held up with newer games well past its prime.
Of course, the real reason is that SLI makes spoiled rich kids spend twice as much on their video cards, a reason which goes away if you put two GPUs on one card . . .
In geologic timescales, a decade or two might as well be a few seconds ago.
The Skiffy channel likes it because they're owned by Universal, who also produced the movie.
No, read the article. In this case, Darl very specifically mentioned the initial purchase price. We can argue about TCO costs, but that's not the argument Darl made.
Last I checked, the web interface denies external connections by default, and can only allow specific addresses to connect (deny-by-default strategy).
No, the optimial is that all users are also node admins. Freenet is highly scalable by design, and actually works better (at least on a theoretical basis) if all users run nodes.
FCP is specifically designed to work over localhost only, and (last I checked) the current implementation only allows external connections from specific IP addresses. The constant connection/teardown of the protocol makes it rather inefficient for remote connections.
And that breaks the laws of thermodynamics. Go take High School Physics again.
I don't think they're sold anymore, and they're so cheep now that you wouldn't save much, anyway. Just ignore whatever extras come with the board.
In fact, you just might save a few bucks in the long run by using the on-board stuff, since it may use less power than the equivilent slot-based stuff.
I disagree.
Steam's anti-piracy ideas are utter crap. That I agree with.
However, there's something far more important here: elimination of middle-men. Through Steam, Valve can sell games directly without a publisher. Game development houses tend to get a patheticlly small percentage of the total revenue from their game. Publishers suck it all up. Getting rid of publishers is a Good Thing, and something I've been waiting for the Internet to do for a while.
I doubt it. People are going to complain (fairly) for a week or so. Then Valve will work out the problems. People will be throwing saw blades at zombies and forget the Steam problems ever happened.
Further, this primarily effects the people who bought it at the store. Valve gets far more profit per unit sold when a player buys the game over Steam. People like me who preloaded and bought the game over Steam had little trouble.
Funny you mention SWG, as that's where I picked up opinons that completely agree with what was in the article.
Take the Jedi Problem, for instance. The SWG timeline is in a place where there should be almost no Jedi. If there are any around, they're in hiding from the Empire. However, players want to be a Jedi (point #1 from the article), for various reasons, so the developers made it possible to become one. Obviously, in keeping with this area of the Star Wars timeline, Jedi numbers should at least be kept low, and those that are should be in constant hiding.
Let's go over the orginal system for becoming a Jedi, just for review (this was replaced recently, but most existing Jedi right now became Jedi like this):
There are around 30 professions in the game. When your character is created, five of them are picked at random. You aren't told what they are. If you master all five, you open up your Force Sensitive slot and can work your way through the Jedi proffessions. To help this process along, 'holocrons' were added that would tell you one of the proffessions you needed. Master that, get another holocron, and then you get the second proffession, and so on. But you won't be told what the last proffession is.
Now, that's a daunting challenge. If I was a developer sitting back 1-2 years ago, before the game was even in beta, I would have thought that this, combined with permadeath on Jedi, would be plenty to keep the Jedi population low and in hiding.
But that's not what happend. Players complained that permadeath wasn't fair, so it was removed (see point #2 and #4 in the article). The developer's big mistake, and one that I would have made myself if I was a dev, is in underestimating the willingness of some players to be Jedi (which could fall under point #3, in that the game is based on a movie, and people want it to be just like their interpretation of that movie). Optimized grinds were created that would allow many professions to be mastered in a few hours--if you were willing to go through the utter boardom of sitting there, clicking the same blasted buttons over and over again. Someone with time off and enough drive and willingness to be board out of their skull could make Jedi in a week.
Thus, there are Jedi everywhere in SWG. Many of the non-Jedi complain about the large precentage of Jedi players, which also falls under our reinterpreted point #3.
More people complain, so the devs decide to do something about it by redevloping the Jedi system. The same people then complain about that (point #4), whining that the Jedi got two major game patches to themselves. But that's exactly what it would take to fix the system!
So here's my conclusion: The Jedi Problem is more the player community's fault than the devs. The devs made a system that, in all reasonableness, would seem to be able to keep the Jedi population low. They turned out to have missed a variable (the number of players determined enough to do the grind), and they were forced to conced the removal of a key design point (permadeath) or risk having lots of players delete their accounts and take the cash flow with them.
Let's take the Mario Bros. movie for example: The characters of Mario and Luigi are pretty well done, and more or less what you'd expect from a pre-Mushroom kingdom encounter. The movie plot? Relates NOT AT ALL to the plot of any of the games. A perfect example of game plot being disregarded as not worthy.
Huh? None of the Mario games had a plot beyond "save the princess".
Of course, the thing most remembered about most games is the music
Nintendo often does versions of their game music for full orchestras, and they're great. I particularly liked some of the Zelda music they did. You'll have to scrounge around eBay to find a CD of it, though.
Funny, I rather liked the current crop of games, for the exact same reason.
I don't think Metroid will work well as a movie, though (unless it's an artsy independant film). A lone, silent warrior in dark caves just doesn't work. In any case, with Woo directing, it should be a good blow-stuff-up movie.
You can't just write a page and stick it on your server
Sure you can, depending on your server's configuration. Under the Apache handler, if you're using the Gopher::Server::RequestHandler::File handler, then you can just stick it in your directory structure. Other handlers (which have yet to be written) may or may not allow this, but if they don't, it'll be because they do complex things that need more information than what is available in the file itself.
They're also a big reason web browser support is so poor.
If you're talking about desktop browsers, sure. But what about my cell phone, which is fully Internet connected? Using HTTP+HTML, I have to do all sorts of things to my markup to get it to look right, and the result will probably look too minimalistic on a desktop browser. With a Gopher client, the cell phone's client would be able to format the menu on it's own.
Menu items noted with a '!' (upside-down 'i') type are information that can be displayed to the user. This would be far less obnoxious than the singing, dancing banner ads on the web today (saw one a few weeks ago with a ~20 sec mpeg embedded in it!), but would still generate a little revenue to support servers.
There is a translater available that will convert a Gopher menu into HTML. But if you're running under Apache, you're probably better off switching off the directory indexer and pointing your document root to the same place as your Gopher server. It'll be almost the same thing as far as a standard desktop browser is concerned.
If you're running PyGopherd (an excelent server written in Python), then it can automatically detect an HTTP request on the Gopher port and handle it correctly.
gopher.quux.org is a huge repository (many of the quotes you see at the top of my site came out of QUUX's fortune files). I eventually plan on expanding gopher.wumpus-cave.net into a repository for weird or historical technology (Trebuchets built out of Legos, PDP-11 assembler opcodes, etc.), but right now it just has some Gopher implementations and some pictures of a burning stuffed Barney doll :)
One advantage is that any device can support Gopher without doing strange things to the text. Gopher orginizes everything in a heriarchal menu (tab-delimited), and then the client gets to do whatever it wants with it. You don't need to worry about "how does my page look on a PDA screen?", because a theoretical Gopher client on a PDA would already know how to format the output to be readable there. This is specifically because the Gopher protocol is dumb by design.
Exploring neat ideas for interactions between Gopher servers and clients is my hidden goal behind this project. One idea I have is to make a backend repository for game ROMs that use Gopher+ INFO blocks to send the information on how to execute that ROM for a given emulator. Emulators that require special ROMs (such as MAME, which changes what is actually needed to execute a game in almost every new version) can be handled with Gopher+ VIEWS. But I'll have to get down to implementing Gopher+ before I can do that.
I don't view Gopher as a replacement for the web, but as a nice augmentation in certain situations.