I think that everyone's thinking about this the wrong way. Computers automate processes, but that doesn't necessarily mean that the entire process needs to be automated from the minute it's turned on. This fundamental, flawed assumption is always at the heart of these kinds of fiascos.
If you can write a program to do it, you can also design a manual process. But more importantly, if it's a complex process, you can first break it up into sub-processes, and then automate the parts that involve tasks that are already well understood, and have existing implementations, and do the rest manually. Then replace the manual parts with automated processes piece by piece. The monolithic replacement approach is ridiculous. The side benefit of a hybrid automated/manual approach is that the algorithms and procedures are transparent, and non-programmers can learn them, understand them, critique them, improve them and finally describe them in a form which can be automated. Once manual processes stabilize, they could probably be scripted easily enough, as an intermediate step before conversion to fully custom code modules.
Now, this would have to be managed, of course, and there would have to be some kind of standards imposed for data formats, but assuming all of the raw data is always digital, and the manual work is mostly comprised of moving the output from one automated step to the next automated step, you would have an ad hoc system that could be evolved into a custom system, while always working the whole time.
Of course, given that they already have a working system, they should in fact simply be replacing elements of the existing system with modern replacements, one at a time. They could write adapter layers between the existing parts and the replacement parts. It's clear from the description that the system is distributed, running on multiple (hundreds, thousands?) of computers.
I'm not saying it would be easier or cheaper, but it would work from the get-go, and evolve, and by the time it was finished, the users would already be trained and management could have high confidence that the system worked.
This goes far beyond Americanization of English. Note the imaginary word "layed" in place of "lain". Just because a person reads slashdot doesn't mean that they can write worth a damn.
If only the slashdot editors had any kind of real claim to that title, then they might actual edit stories, instead of just filtering them.
Let me know when they invent the knife you can't cut a person with.
Imagine having a job where you're paid big money to state the obvious. The dream of all useless people is to become an analyst.
Undoubtedly someone will point out that one tool is more useful for nefarious deeds than another, but then how many people get killed by staplers? This is not news!
Ignoring the quite possibly legitimate desire to harrass "pirates" (yar!), this move boils down to MS giving away their product.
Last time I checked, giving away your product was considered an anti-competitive practise, although IANAL.
Giving away samples, like trial sizes or, in the software industry, limited use versions, is strictly marketing-related. If you give away the whole thing, you're not marketing -- you're giving away the product, for crying out loud.
Then again, when it gets you news articles that make you look good, it certainly is PR.
But it's also a bold attempt to help solidify the monopoly by giving it away to people who won't buy it, because either they can't afford it or it's simply not worth the sticker price, to them. It's better to give it away because then they can be sucked into the upgrade process.
Also it's to MS's benefit to reduce the number of installs that cannot be upgraded to SP2. They need SP2 adoption to put some kind of brakes on the spyware explosion, which is really hurting their image amongst regular folks.
Listen to yourself. I doubt you actually read the article, since you're not responding to the points he made, only the capsule. Then again you admit that you're just soap-boxing. Seriously, wtf does Turbine have to do with this discussion? Unfortunately you're just... wait for it... a noob, by Bartle's definition. And mine. Crying for what you want,.
To say that "Many MMORPGs succeed" is a big stretch. What's your definition of "many"? Five? Ten? It's sure not a hundred. Even in the context of MMOGs, the majority of those which have succeeded are not the 3D graphical MMORPGs you're talking about, but the text-based MUDs. Only a handful of 3D MMOGs have succeeded. And those that have sometimes suck, by some people's standards.
As for your other "arguments", they're empty and not worth even giving heed to.
This discussion, of course, can never get anywhere, because logic has nothing to do with it. There's a conflict of goals. Success in art/craft is measured by critics, self-appointed experts and regular people with opinions, while success in commerce is measured by profit. Same for books and movies and other mass-produced popular art. Which type of assessment do you care about? It would be nice to have both, but they usually work against one another, and only one can be measured objectively (in dollars).
What Bartle forgot to mention was that his argument is in no way new, and that it applied to other areas of art long before computers were even thought of. MMOGs only add a different spin, but one not especially different from television; both are a serial experience, prone to imitation and repetition. Both are generally weak thanks to the driving need to pander to lowest common denominator eyeballs, since eyeballs == $$. Before television it was serial novels.
If people want to understand the issues, it would help if they knew something about them.
For sheer audacity, creativity, and ground-breaking, Marathon owns all other games. The only thing was it was too long, and they didn't update the technology enough between games, so by the third one, it was really dated.
I was gonna say "Ah, gee, it's just a rampant A.I." but your post was way better.
I agree (although I have a Mac which won't meet the requirements of the Mac version on CPU).
As for memory, I think the minimum RAM in the system should be no less than around half the cycles of the CPU, so for a 2GHz CPU you want 1GB+ of RAM, or thereabouts.
I have 1.5GB of RAM in my dual-867. It's just so much better for your hard drive not to have to rely on swap.
I know a lot of people feel the way you do, but personally I am much happier with dynamism. If I want to ensure that an object can receive a message I want to send it, I just send it -respondsToSelector: first. It means that I have to do part of the work instead of the compiler, but this pays dividends later when you want to extend the software, since later, one can add a category to any object that implements a method corresponding to the selector -- no subclassing required, and no fragile base class problem. I love it.
Of course it is easy to abuse, but I just don't do that. Self-control is important in Objective-C. But in exchange, you get the power of delegation, which is so sweet I can't begin to express it. For end-user apps on Mac OS X, you'd be crazy to overlook it.
In addition, the Finder will always ask for a password, regardless whether it is blank or otherwise. So the "enter your password" window will come up. The user simply does not have to type anything in the password box.
See my post above but that won't work for two reasons: 1, only an applescript will work (not any old executable, welcome to Mac OS), and even if you use the vulnerable in-between script called OpnApp.scpt (which will happily call any executable), the extra line which you need to specify the executable shell script does not support spaces (they come through as "%20" and are unreadable) and so you cannot use "rm%20-rf" or whatever.
Thankfully this exploit is not quite that easy to take advantage of.
This is not an exploit against a browser. This is an OS-level compromise. Any browser will do. Firefox works fine. The current fix is to use MisFox or similar (even old IE) to change the "help:" protocol to another app. Taking the "runscript" power out of Help Viewer would be a nice thing, too, but any program with that ability could be provide in its place, wittingly or otherwise.
The real power is to combine the script running with providing your own script via disk:// protocol, which mounts.dmg disk images silently in the background at/Volume/yourDiskImage -- so Help Viewer can always find it!
PowerMac G5's are 4-core CPUs. They are not made out of 4 identical, full-featured cores, but this is what they say, nonetheless. (1 core is the main ALU, the other 3 are Altivec cores.)
Ah, but the irony in Bill's post is that software development will be automated. The only reason hardware is cheap is because it's development and manufacturing processes have become so streamlined due to automation (made possible by mass production).
If visual design tools and other automation improvment can be realized, development costs in human hours, and better reusability, will see software reliability improve dramatically while costs drop substantially. In which case, software should become really cheap, just like hardware. And the raw materials of software are technically free (or at any rate, not in limited supply) unless you count patent fees and the costs of managing the complexity of choosing the right tool for the job, which still requires human brain power.
The improvement of tools is absolutely and utterly the main roadblock to a mind-boggling improvement in software quality and functionality.
So, if Bill gets what he wants, he won't get what he expects.
For any programmers out there that are even remotely interested in getting Linux On The Desktop, consider this a call.
It is a little early in the game to have such grandiose expectations. Fortunately the developers appear more level-headed. Still, they too might be letting their enthusiasm get ahead of them
After a brief skim of Mark Thomas's paper, I have a number of concerns with the direction the project is taking. Up front I'll admit to being heavily influenced by the Cocoa libraries from Apple/NeXT, but they are light years ahead of everything else.
Implementation Language: Using C will be a problem. In order to achieve object orientation, they have to implement it in code, instead of getting it from the language itself. That will make the learning curve a lot steeper and make the code hard to maintain. It necessitates things like callbacks, which are a clumsy, primitive design pattern.
U.I. Design: It looks like they are imitating X and defining layout of U.I. in code. This is not in keeping with modern user interface libraries. It slows development dramatically. They need to emulate the Mac OS and others and define resource files that describe the U.I., so non-programmers can edit interfaces and so interface editing does not require a re-compile. Likewise, all localizable strings should be stored in text resources. Resources aren't even addressed in Thomas's paper.
Support Libraries: Any complex U.I. library will depend on a lot of data types and classes (or equivalents) that are not strictly U.I.-related. These ought to be in a distinct library.
Implementation mixed with Design: A debatable point, but there is a lot of implementation detail mixed in with the design goals, which muddies the discussion. The project really needs a detailed set of project goals, organized roughly by the order they hope to attain them. This will help ensure that bad design decisions early on don't hamper later work.
I have been programming Cocoa for three years now, mostly in my own time between course work. I am just starting to learn X in school, and let me tell you, it is a depressing step backwards. There is no doubt that X is in sorry need of replacement, for the sake of programmer effectiveness as well as for feature parity.
Still, you cannot just start up a new replacement project willy nilly and expect not to fall into all of the same traps. I'm sure that the X developers felt that they were future-proofing to some extent, and they must have succeeded, but why start up a whole new project just to end up in the same place in another ten years? You might as well just work with what you have.
Alternately, if this is a research project to explore new design principles, then I wholeheartedly encourage the team. In which case it is even more important for them to set out their goals and project development order, otherwise it's unclear how they will be able to assess their own success.
I share 3Mbit DSL with my room-mate. We pay CAN$70 + $10 for fixed IP. I get 360KB (kiloBYTE)downloads regularly, say from Apple. It's fantastic. We get 40GB up and 40GB down per month plus unlimited data transfer from 12am-8am. Needless to say this more than meets our needs. With the selection of stuff on the 'net, we totally cancelled cable. Stick it, Rogers.
It's the "make as much money as you can" that needs elaboration. Two things:
1. Wealth distribution is skewed because it seems that a minority of people are unable to acquire a minimum skill set to do anything useful in the current technocracy, and of those with the abilities, only a few are eligible for the minority of jobs that pay really well.
2. There seems to be a problem in identifying what is truly valuable, or at any rate the values of corporations and the values of individuals are very different, so the kind of work that goes into making widgets is almost completely information-based: designers, systems analysts, product research, marketing, management, advertising. Even the tooling of the manufacturing equipment is more and more being handled by machines and their operators. So while people might just want a nice table, the ability for a non-university educated person to contribute to the production of that table is decreasing all the time. And no carpenter can compete with Ikea's production system.
We seem to be approaching a watershed where the computerized systems we are creating will be able to sustain themselves with a fixed number of knowledge workers, but will be able to produce finished goods for a virtually unlimited number of consumers -- except that only the participants in the production system will make enough money to afford any but the cheapest goods.
In other words, the number of people required to maintain a high tech society is shrinking, or at least reaching a plateau, meaning that those inside don't need those outside any more. And what are these superfluous people going to do? They can't get good work and they can't produce, so they must do unskilled labour, the sort that is still too complex to be done my machines. But there is a limited amount of this unskilled work. People will nevertheless invent new (and more demeaning) ways to serve the wealthy, causing the growth of a kind of indentured service to the technocrats.
I believe that this has happened at other times in history, so it's not a permanent state necessarily, but the phenomenon is world-wide, now. We can't just open up a new frontier on another continent and ship our surplus population there. At least, not until we can afford space colonization, and that looks to be a few hundred years away yet, at this rate, if ever, considering the current state of the aerospace industry.
I'm not sure if Robocop had programmed ethics, however, unless you count the obvious borrowing from Asimov. But the ethics in Asimov's robots are fundamental, not superficial like LaMuth's, which act only on the way sentences are parsed and produced. Robots act -- this "ethical A.I." only listens and talks.
The question is moot, however, because this guy's patent is science fiction itself! Why can't the U.S. patent office distinguish between a rough strategy for how to proceed with engineering a non-existent system (like LaMuth's) and the design of an actual, workable system? He built a system out of parts, but a bunch of the parts in that system don't exist in any form that would be usable by the system as sketched. And let's be honest, that "diagram" is nothing more than a sketch of how it might eventually be done, but, probably, won't.
I could build you a great robot if you gave me a working artificial brain, a power source, arms, legs and a torso according to my specifications. Could I patent that?
Quote:
Except that the Octane's bus is theoretically much, much faster. It has an end-to-end point speed of only about 3 and half GB/sec, but it can connect any of the individual systems to each other simultaneously at full speed
Uh, for those of you on the short bus, Apple's new memory chip is also point-to-point. From the G5 (system, not chip) white paper:
Advanced System Controller
A new system controller is central to the overall performance of the Power Mac G5. This revolutionary application-specific integrated circuit (ASIC)â"one of the industryâ(TM)s fastestâ"is built using the same state-of-the-art IBM 130-nanometer process technology as the PowerPC G5 processor. A superefficient point-to-point architecture rovides each primary subsystem with dedicated throughput to main memory, so massive amounts of data can traverse the system without contention for bandwidth. In contrast,
subsystems that share a bus, as on other PCs, must deal with time-consuming arbitration while they negotiate for access and bandwidth across a common data path.
You should learn to enjoy the game instead of being fixated on the surface quality. Kiki is a great game. I don't know what complaints you could have about the graphics.
Clearly you have totally missed the point. This was a 3-month make-a-game contest in order to get people to be creative and contribute to the community. Did you try Astro Squid? Or Raptor? If you are prejudiced against 2D action games, well, that's one thing, but the graphics quality of those is quite high.
Now, Mac and other game developers have access to 3D code, input code, game logic code, and more, to help them get started on making their own games.
I don't deny that there is a shortage of artists for open source games, but what do you think people can manage in three months? Also, have a look at PlaneShift, the Crystal Space game -- amazing art content.
It's about percentages. I bitch about this to my MMORPG-playing friends all the time. You cannot have a world (or universe or galaxy or whatever) wherein the majority (Molyneux forbid it is everyone) are "special" -- adventurers or what-have-you. It makes no sense!
I think that, in order to have fun at actually role playing, the ratio of NPCs to PCs has to be about 100:1, where NPCs are people living "by the rules", and the PCs are people doing whatever the hell they please. It does not matter whether the NPCs are virtual or if they are played by actors. Both are expensive propositions.
I agree with the other poster who called for small bands of players, but I think, in a big enough world, you could probably support hundreds of these bands, if they were dispersed well enough. Problem is, the worlds are also too small. When you think about a world being 20km by 20km or so, at first it sounds impressive (see Xenus or Morrowind). But how many lost dungeons can you reach on a day's hike? This is "mitigated" by speeding up time by six or so, but that's a bit of a cheat if all the player is doing is walking outdoors.
Let's just change the name to MMOG and forget the role playing until the environments are suited to and inspire it.
Programs don't change, only languages
on
The Post-OOP Paradigm
·
· Score: 2, Interesting
Has anybody mentioned that all of this talk of languages and programming models is purely for the sake of forcing programmings to adopt good practices, mostly by restricting their freedom to screw themselves?
Let's remember that, once you compile a program, you are left with the same thing no matter what language you used: instructions and data. Because all you really have to work with is memory and processors (and I/O, but you can treat that like the other two).
I am far more interested in the progress of automating the development of programs than in the formalization of How Not to Do Stupid Things (TM). I choose languages and tools which save me time and repetition, because tedious (and mindless) repetition is a sure way to increase the probability of human error. Silly ideas of aesthetics and tradition are of no use to me.
Perhaps the new frontier of programming is not the language, but the development environment. Then again, that's really what a language is: an environment for managing the production of machine code. But environments are more than languages now, so why not exert some serious effort, and do some serious studies, of the impact of the whole environment?
Slashdot Mirror
I think that everyone's thinking about this the wrong way. Computers automate processes, but that doesn't necessarily mean that the entire process needs to be automated from the minute it's turned on. This fundamental, flawed assumption is always at the heart of these kinds of fiascos.
If you can write a program to do it, you can also design a manual process. But more importantly, if it's a complex process, you can first break it up into sub-processes, and then automate the parts that involve tasks that are already well understood, and have existing implementations, and do the rest manually. Then replace the manual parts with automated processes piece by piece. The monolithic replacement approach is ridiculous. The side benefit of a hybrid automated/manual approach is that the algorithms and procedures are transparent, and non-programmers can learn them, understand them, critique them, improve them and finally describe them in a form which can be automated. Once manual processes stabilize, they could probably be scripted easily enough, as an intermediate step before conversion to fully custom code modules.
Now, this would have to be managed, of course, and there would have to be some kind of standards imposed for data formats, but assuming all of the raw data is always digital, and the manual work is mostly comprised of moving the output from one automated step to the next automated step, you would have an ad hoc system that could be evolved into a custom system, while always working the whole time.
Of course, given that they already have a working system, they should in fact simply be replacing elements of the existing system with modern replacements, one at a time. They could write adapter layers between the existing parts and the replacement parts. It's clear from the description that the system is distributed, running on multiple (hundreds, thousands?) of computers.
I'm not saying it would be easier or cheaper, but it would work from the get-go, and evolve, and by the time it was finished, the users would already be trained and management could have high confidence that the system worked.
This goes far beyond Americanization of English. Note the imaginary word "layed" in place of "lain". Just because a person reads slashdot doesn't mean that they can write worth a damn.
If only the slashdot editors had any kind of real claim to that title, then they might actual edit stories, instead of just filtering them.
Let me know when they invent the knife you can't cut a person with.
Imagine having a job where you're paid big money to state the obvious. The dream of all useless people is to become an analyst.
Undoubtedly someone will point out that one tool is more useful for nefarious deeds than another, but then how many people get killed by staplers? This is not news!
Ignoring the quite possibly legitimate desire to harrass "pirates" (yar!), this move boils down to MS giving away their product.
Last time I checked, giving away your product was considered an anti-competitive practise, although IANAL.
Giving away samples, like trial sizes or, in the software industry, limited use versions, is strictly marketing-related. If you give away the whole thing, you're not marketing -- you're giving away the product, for crying out loud.
Then again, when it gets you news articles that make you look good, it certainly is PR.
But it's also a bold attempt to help solidify the monopoly by giving it away to people who won't buy it, because either they can't afford it or it's simply not worth the sticker price, to them. It's better to give it away because then they can be sucked into the upgrade process.
Also it's to MS's benefit to reduce the number of installs that cannot be upgraded to SP2. They need SP2 adoption to put some kind of brakes on the spyware explosion, which is really hurting their image amongst regular folks.
My interpretation only.
Listen to yourself. I doubt you actually read the article, since you're not responding to the points he made, only the capsule. Then again you admit that you're just soap-boxing. Seriously, wtf does Turbine have to do with this discussion? Unfortunately you're just ... wait for it... a noob, by Bartle's definition. And mine. Crying for what you want, .
To say that "Many MMORPGs succeed" is a big stretch. What's your definition of "many"? Five? Ten? It's sure not a hundred. Even in the context of MMOGs, the majority of those which have succeeded are not the 3D graphical MMORPGs you're talking about, but the text-based MUDs. Only a handful of 3D MMOGs have succeeded. And those that have sometimes suck, by some people's standards.
As for your other "arguments", they're empty and not worth even giving heed to.
This discussion, of course, can never get anywhere, because logic has nothing to do with it. There's a conflict of goals. Success in art/craft is measured by critics, self-appointed experts and regular people with opinions, while success in commerce is measured by profit. Same for books and movies and other mass-produced popular art. Which type of assessment do you care about? It would be nice to have both, but they usually work against one another, and only one can be measured objectively (in dollars).
What Bartle forgot to mention was that his argument is in no way new, and that it applied to other areas of art long before computers were even thought of. MMOGs only add a different spin, but one not especially different from television; both are a serial experience, prone to imitation and repetition. Both are generally weak thanks to the driving need to pander to lowest common denominator eyeballs, since eyeballs == $$. Before television it was serial novels.
If people want to understand the issues, it would help if they knew something about them.
Yes but perl cannot be used to write an operating system, last I checked.
The point is to measure *EFFORT*, not code functionality or power or quality or anything else. Read the relevant article(s).
If you want to create a measure of code capability, you are more than welcome to do so! Then we can all criticize your short-sightedness.
For sheer audacity, creativity, and ground-breaking, Marathon owns all other games. The only thing was it was too long, and they didn't update the technology enough between games, so by the third one, it was really dated.
I was gonna say "Ah, gee, it's just a rampant A.I." but your post was way better.
Mod parent up!
I agree (although I have a Mac which won't meet the requirements of the Mac version on CPU). As for memory, I think the minimum RAM in the system should be no less than around half the cycles of the CPU, so for a 2GHz CPU you want 1GB+ of RAM, or thereabouts. I have 1.5GB of RAM in my dual-867. It's just so much better for your hard drive not to have to rely on swap.
I know a lot of people feel the way you do, but personally I am much happier with dynamism. If I want to ensure that an object can receive a message I want to send it, I just send it -respondsToSelector: first. It means that I have to do part of the work instead of the compiler, but this pays dividends later when you want to extend the software, since later, one can add a category to any object that implements a method corresponding to the selector -- no subclassing required, and no fragile base class problem. I love it.
Of course it is easy to abuse, but I just don't do that. Self-control is important in Objective-C. But in exchange, you get the power of delegation, which is so sweet I can't begin to express it. For end-user apps on Mac OS X, you'd be crazy to overlook it.
In addition, the Finder will always ask for a password, regardless whether it is blank or otherwise. So the "enter your password" window will come up. The user simply does not have to type anything in the password box.
See my post above but that won't work for two reasons: 1, only an applescript will work (not any old executable, welcome to Mac OS), and even if you use the vulnerable in-between script called OpnApp.scpt (which will happily call any executable), the extra line which you need to specify the executable shell script does not support spaces (they come through as "%20" and are unreadable) and so you cannot use "rm%20-rf" or whatever.
Thankfully this exploit is not quite that easy to take advantage of.
This is not an exploit against a browser. This is an OS-level compromise. Any browser will do. Firefox works fine. The current fix is to use MisFox or similar (even old IE) to change the "help:" protocol to another app. Taking the "runscript" power out of Help Viewer would be a nice thing, too, but any program with that ability could be provide in its place, wittingly or otherwise.
The real power is to combine the script running with providing your own script via disk:// protocol, which mounts .dmg disk images silently in the background at /Volume/yourDiskImage -- so Help Viewer can always find it!
PowerMac G5's are 4-core CPUs. They are not made out of 4 identical, full-featured cores, but this is what they say, nonetheless. (1 core is the main ALU, the other 3 are Altivec cores.)
Ah, but the irony in Bill's post is that software development will be automated. The only reason hardware is cheap is because it's development and manufacturing processes have become so streamlined due to automation (made possible by mass production).
If visual design tools and other automation improvment can be realized, development costs in human hours, and better reusability, will see software reliability improve dramatically while costs drop substantially. In which case, software should become really cheap, just like hardware. And the raw materials of software are technically free (or at any rate, not in limited supply) unless you count patent fees and the costs of managing the complexity of choosing the right tool for the job, which still requires human brain power.
The improvement of tools is absolutely and utterly the main roadblock to a mind-boggling improvement in software quality and functionality.
So, if Bill gets what he wants, he won't get what he expects.
It is a little early in the game to have such grandiose expectations. Fortunately the developers appear more level-headed. Still, they too might be letting their enthusiasm get ahead of them
After a brief skim of Mark Thomas's paper, I have a number of concerns with the direction the project is taking. Up front I'll admit to being heavily influenced by the Cocoa libraries from Apple/NeXT, but they are light years ahead of everything else.
I have been programming Cocoa for three years now, mostly in my own time between course work. I am just starting to learn X in school, and let me tell you, it is a depressing step backwards. There is no doubt that X is in sorry need of replacement, for the sake of programmer effectiveness as well as for feature parity.
Still, you cannot just start up a new replacement project willy nilly and expect not to fall into all of the same traps. I'm sure that the X developers felt that they were future-proofing to some extent, and they must have succeeded, but why start up a whole new project just to end up in the same place in another ten years? You might as well just work with what you have.
Alternately, if this is a research project to explore new design principles, then I wholeheartedly encourage the team. In which case it is even more important for them to set out their goals and project development order, otherwise it's unclear how they will be able to assess their own success.
Well, not exactly, but this one has no moving parts: Aerogel Clothing. Can't seem to find any prices for any of this stuff ;-)
I share 3Mbit DSL with my room-mate. We pay CAN$70 + $10 for fixed IP. I get 360KB (kiloBYTE)downloads regularly, say from Apple. It's fantastic. We get 40GB up and 40GB down per month plus unlimited data transfer from 12am-8am. Needless to say this more than meets our needs. With the selection of stuff on the 'net, we totally cancelled cable. Stick it, Rogers.
E
1. Wealth distribution is skewed because it seems that a minority of people are unable to acquire a minimum skill set to do anything useful in the current technocracy, and of those with the abilities, only a few are eligible for the minority of jobs that pay really well.
2. There seems to be a problem in identifying what is truly valuable, or at any rate the values of corporations and the values of individuals are very different, so the kind of work that goes into making widgets is almost completely information-based: designers, systems analysts, product research, marketing, management, advertising. Even the tooling of the manufacturing equipment is more and more being handled by machines and their operators. So while people might just want a nice table, the ability for a non-university educated person to contribute to the production of that table is decreasing all the time. And no carpenter can compete with Ikea's production system.
We seem to be approaching a watershed where the computerized systems we are creating will be able to sustain themselves with a fixed number of knowledge workers, but will be able to produce finished goods for a virtually unlimited number of consumers -- except that only the participants in the production system will make enough money to afford any but the cheapest goods.
In other words, the number of people required to maintain a high tech society is shrinking, or at least reaching a plateau, meaning that those inside don't need those outside any more. And what are these superfluous people going to do? They can't get good work and they can't produce, so they must do unskilled labour, the sort that is still too complex to be done my machines. But there is a limited amount of this unskilled work. People will nevertheless invent new (and more demeaning) ways to serve the wealthy, causing the growth of a kind of indentured service to the technocrats.
I believe that this has happened at other times in history, so it's not a permanent state necessarily, but the phenomenon is world-wide, now. We can't just open up a new frontier on another continent and ship our surplus population there. At least, not until we can afford space colonization, and that looks to be a few hundred years away yet, at this rate, if ever, considering the current state of the aerospace industry.
Meanwhile, internation tensions increase...
The question is moot, however, because this guy's patent is science fiction itself! Why can't the U.S. patent office distinguish between a rough strategy for how to proceed with engineering a non-existent system (like LaMuth's) and the design of an actual, workable system? He built a system out of parts, but a bunch of the parts in that system don't exist in any form that would be usable by the system as sketched. And let's be honest, that "diagram" is nothing more than a sketch of how it might eventually be done, but, probably, won't.
I could build you a great robot if you gave me a working artificial brain, a power source, arms, legs and a torso according to my specifications. Could I patent that?
Quote: Except that the Octane's bus is theoretically much, much faster. It has an end-to-end point speed of only about 3 and half GB/sec, but it can connect any of the individual systems to each other simultaneously at full speed Uh, for those of you on the short bus, Apple's new memory chip is also point-to-point. From the G5 (system, not chip) white paper: Advanced System Controller A new system controller is central to the overall performance of the Power Mac G5. This revolutionary application-specific integrated circuit (ASIC)â"one of the industryâ(TM)s fastestâ"is built using the same state-of-the-art IBM 130-nanometer process technology as the PowerPC G5 processor. A superefficient point-to-point architecture rovides each primary subsystem with dedicated throughput to main memory, so massive amounts of data can traverse the system without contention for bandwidth. In contrast, subsystems that share a bus, as on other PCs, must deal with time-consuming arbitration while they negotiate for access and bandwidth across a common data path.
has shipped over six billion ICs. But who's counting?
You should learn to enjoy the game instead of being fixated on the surface quality. Kiki is a great game. I don't know what complaints you could have about the graphics.
Clearly you have totally missed the point. This was a 3-month make-a-game contest in order to get people to be creative and contribute to the community. Did you try Astro Squid? Or Raptor? If you are prejudiced against 2D action games, well, that's one thing, but the graphics quality of those is quite high.
Now, Mac and other game developers have access to 3D code, input code, game logic code, and more, to help them get started on making their own games.
I don't deny that there is a shortage of artists for open source games, but what do you think people can manage in three months? Also, have a look at PlaneShift, the Crystal Space game -- amazing art content.
I think that, in order to have fun at actually role playing, the ratio of NPCs to PCs has to be about 100:1, where NPCs are people living "by the rules", and the PCs are people doing whatever the hell they please. It does not matter whether the NPCs are virtual or if they are played by actors. Both are expensive propositions.
I agree with the other poster who called for small bands of players, but I think, in a big enough world, you could probably support hundreds of these bands, if they were dispersed well enough. Problem is, the worlds are also too small. When you think about a world being 20km by 20km or so, at first it sounds impressive (see Xenus or Morrowind). But how many lost dungeons can you reach on a day's hike? This is "mitigated" by speeding up time by six or so, but that's a bit of a cheat if all the player is doing is walking outdoors.
Let's just change the name to MMOG and forget the role playing until the environments are suited to and inspire it.
--
Feeling Bored?
--
Feeling Bored?
Let's remember that, once you compile a program, you are left with the same thing no matter what language you used: instructions and data. Because all you really have to work with is memory and processors (and I/O, but you can treat that like the other two).
I am far more interested in the progress of automating the development of programs than in the formalization of How Not to Do Stupid Things (TM). I choose languages and tools which save me time and repetition, because tedious (and mindless) repetition is a sure way to increase the probability of human error. Silly ideas of aesthetics and tradition are of no use to me.
Perhaps the new frontier of programming is not the language, but the development environment. Then again, that's really what a language is: an environment for managing the production of machine code. But environments are more than languages now, so why not exert some serious effort, and do some serious studies, of the impact of the whole environment?
--
My blog: The Bored Astronaut