You know, if we didn't allow stupid and ugly people to procreate, I'm sure you wouldn't be here either...
That adhom attack aside, evolution only favors those who survive and reproduce. If the people *you* judge as unfit to reproduce *do* reproduce, it's obvious that nature thought they *were* fit to reproduce, and thus evolution's constraints were satisfied.
If you want to control evolution (by denying artificial wombs and such), you should go out and kill everyone who doesn't meet your critiera for evolutionary fitness. Otherwise just leave everyone well enough alone, lest you be targetted by some prettier, stronger, smarter ape who thinks you don't satisfy the notions of the race superior.
If you can't keep the texturing data separate from the geometric data, you can't play with geometric data in a general way (not even mentioning that clipping the curve against the view boundaries or another surface will raise the number of primitives by an order), and you have to live with texture element density along the surfaces varying according to the clipping constraints and degenerate cases where the texture is nothing more than a point, or you have visible seams between textures when texture density along the surface changes. You also lose the ability to rotate the texture, project a single texture across multiple surfaces, etc.
I was also expecting an implementation of genetic algorithms to 'scale' the monsters up against the players...
Or at least attempt to.
So that, no matter how much they cheat, the dragon they see on the mountaintop will still kick their ass. They can cheat as much as they want, the monsters and weapons are supposed to 'scale' against each other. Supposedly. At least, again, that's my goal.
Well, I can agree that you can never guarantee security in today's systems.
I also haven't looked at cheating, yet, but I have a couple ideas.
One: PKI. If every packet sent by the server is signed or encrypted, then a client should obviously only trust signed packets. Prevents some man in the middle issues. If both client-server uses PKI, then this applies in both up and down stream situations.
If you use both global and personal keys, then you can encrypt messages in two ways. Personal keys are for specific P2P communications (such as important state changes) while the global keys can be used for multicast information (like monster movements or screen updates). This of course depends on the strength and inassailability of the keys, but that is a technical issue and not a policy issue.
This doesn't address the ability of miniservers to create state. I haven't decided yet if that's going to be allowed, but if it is, one possibility is to have multiple mini servers correlate data, to increase security and robustness. This is still imperfect because a group of friends who play together can still cheat together (bad clients, for example, or proxies, or whatever)
On the other hand, cheating can be curbed, I think, by good game design; where cheating is reduced by making the benefits of not cheating much higher. That's another policy design. IE, a bunch of friends won't cheat each other, if they're really friends...
You can tell the story without explicitly demonizing anyone:
Romero did not quit, he was fired.
I no longer have the url but John Carmack said Romero would blow off the day by playing and not coding and would not listen to the other employess about ideas for the games. [fine, since this is hearsay] He and John Carmack held two different visions for the games they worked on. This got to the point where he [Romero] would not work on the same assignments as Carmack and would do his own thing. Carmack and the CEO fired Romero and another coworker [since it's very clearly lack of team effort, inability to perform adequatley, refusal to work, etc, no need to mention getting pised, or seting an example. Nor is it necessary to mention JC's perfectionism, which has no bearing on the story.] The whole team would go one way, and Romero refused to go with the flow. This, and not the long hours, is why he [Romero] left.
Client getting pushed too much information.
Client getting pushed too little information.
Planned, intentional, latency is much more workable than a classic DoS. As a workaround, for example, you introduce locality.
IE, people get clustered around deputized local servers, so that you can bypass spanning the network.
If I broadcast 'Hi', it only needs to go up to the server and back down, but it's only spread around the local group. That way people in the virtual geographic space don't get spammed with my packets and lag is much reduced.
Assuming you have a secure communication channel (whether it be trust, PKI, or other encryption), you can try to reduce lag by distributing resource request and allocation.
Rather than the server handling 100 clients, when it needs to push out identical data to all 100, you push out data to 10 of those clients and rely on those 10 clients to push out data to another 9 clients.
You can also push in the other direction. When client 1/100 says 'Hi!', rather than pushing it to the server to push it to 100 clients, the client pushes it to the client he's attached to, who pushes it out to the other 8 people, as well as to the server. The server then pushes the 'Hi' out to the other 9 clients it's connected to, who pushes out to their respective 9 clients.
It's akin to treating the connection to the server as some sort of nested tree; you introduce latency but reduce the amount of server lag.
Has anyone brought this up? Barring the copyright problems, this stacks up against the TiVo in most ways.
It may have more success as a way to time shift, and thus replace the conventional VHSR in the house, but because it's 2 years *after* TiVo, I wouldn't expect it to take off at all.
If this had been released 3 years ago (Possible! Sony had Digital8 around that time) and could record digitally onto standard VHS tapes and had a Firewire port for streaming of data around a Firewire network...
Heck, if they added that feature right now, I bet there would be a niche market for it!
Still, they should have released this product three years ago...
A $3k DP G4 vs a, what, $10k SGI workstation... I guess you can get 3x animators working, at that rate, but I still imagine that for some things the performance of the Fuel would still be superior?
If you're going to bring in MS and Windows... I'm going to have to say a stupid UI means stupid users. A UI that doesn't teach or protect or grow the user, is the Windows OS...
Not that there are much better, elsewhere! Just that MS is left holding the bar and standard since it's got the monopoly right now.
Oh. Right. Real insightful. Excuse the dripping sarcasm.
"It's not the OS it's the user that sucks. If it's user friendly, you get stupider people."
How self contradictory can you get? It's *not* the OS. No matter how user friendly or unfriendly, it's the user. Period. End of line.
If it's user friendly, you get a pleasant, useful, powerful, computing experience. That's it.
A user friendly OS and program with a stupid person does not make the OS insecure or the program flawed, or the UI wrong. It just means the user is stupid.
User friendly does not imply a stupid user.
This is so shortsighted!
on
Debian NetBSD
·
· Score: 3, Interesting
What happened to the concepts of diversity, hybrid vigor, competition, and cooperation?
With Microsoft we get a monoculture.
Are you suggesting the same for all other OSes?
If nothing else this project encourages and explores compatibility issues, source examination, bug catching, performance tuning, and a bunch of other things, if only because a new, fresh, set of eyes (Debian) is looking at old things (BSD), and the other way around, BSD people looking at Debian things.
This cross pollination can have so many surprising and unexpected benefits too. Like the fact that if the kernal is BSD and the userland is Debian... it means you could, besides a little project called Fink, place an entire Debian OS layer on top of Apple's Darwin or Apple's OS X.
Then there is the ports system, which sounds very good to me. It's currently a BSD thing, but there's nothing stopping it from running on top of the Debian-netBSD distro, with work, and therefore stopping it from working on GNU-Debian with just a little more work, with 'work' and 'little more work' being subjective here.
These are just obvious speculations on my part. Many more advantages can be found, I'm sure, of this type of project.
Actually, that means a company is forced to compete with it's own product, and therefore each release should be better and worth more than the release that preceeds it.
That's an excellent idea. You should go and do that:)
As it stands, Adobe has the right to follow it's own business model, because it works. Show them a better way that will make them more money, and I'm sure it will work out for all parties.
Sooo.... how does Adobe afford the production costs and the support costs and the bandwidth costs if they don't make any money on top of the distribution costs?
Slashdot Mirror
Who said natural?
All I'm saying is that anything that affects reproduction and survival affect evolution.
Or do you think sugar and margarine are 'natural parts of evolution n' stuff'?
Yes... and then evolutionary forces (like peanut butter or flights of stairs) apply their leverage and voila, evolution in action!
You know, if we didn't allow stupid and ugly people to procreate, I'm sure you wouldn't be here either...
That adhom attack aside, evolution only favors those who survive and reproduce. If the people *you* judge as unfit to reproduce *do* reproduce, it's obvious that nature thought they *were* fit to reproduce, and thus evolution's constraints were satisfied.
If you want to control evolution (by denying artificial wombs and such), you should go out and kill everyone who doesn't meet your critiera for evolutionary fitness. Otherwise just leave everyone well enough alone, lest you be targetted by some prettier, stronger, smarter ape who thinks you don't satisfy the notions of the race superior.
That's not so hard!
;D
If you can't keep the texturing data separate from the geometric data, you can't play with geometric data in a general way (not even mentioning that clipping the curve against the view boundaries or another surface will raise the number of primitives by an order), and you have to live with texture element density along the surfaces varying according to the clipping constraints and degenerate cases where the texture is nothing more than a point, or you have visible seams between textures when texture density along the surface changes. You also lose the ability to rotate the texture, project a single texture across multiple surfaces, etc.
Something like that
Or at least one with heavy input from him.
It doesn't matter *what* topic. Whatever he wants you to write about.
He can talk about hardware design.
Software design.
Cross platform design.
Optimization.
Algorithms.
Graphics trends.
Project management.
Racing.
I'd be interested.
Oh, that.
I was also expecting an implementation of genetic algorithms to 'scale' the monsters up against the players...
Or at least attempt to.
So that, no matter how much they cheat, the dragon they see on the mountaintop will still kick their ass. They can cheat as much as they want, the monsters and weapons are supposed to 'scale' against each other. Supposedly. At least, again, that's my goal.
Well, I can agree that you can never guarantee security in today's systems.
I also haven't looked at cheating, yet, but I have a couple ideas.
One: PKI. If every packet sent by the server is signed or encrypted, then a client should obviously only trust signed packets. Prevents some man in the middle issues. If both client-server uses PKI, then this applies in both up and down stream situations.
If you use both global and personal keys, then you can encrypt messages in two ways. Personal keys are for specific P2P communications (such as important state changes) while the global keys can be used for multicast information (like monster movements or screen updates). This of course depends on the strength and inassailability of the keys, but that is a technical issue and not a policy issue.
This doesn't address the ability of miniservers to create state. I haven't decided yet if that's going to be allowed, but if it is, one possibility is to have multiple mini servers correlate data, to increase security and robustness. This is still imperfect because a group of friends who play together can still cheat together (bad clients, for example, or proxies, or whatever)
On the other hand, cheating can be curbed, I think, by good game design; where cheating is reduced by making the benefits of not cheating much higher. That's another policy design. IE, a bunch of friends won't cheat each other, if they're really friends...
What's with the personal inferences?
You can tell the story without explicitly demonizing anyone:
Romero did not quit, he was fired.
I no longer have the url but John Carmack said Romero would blow off the day by playing and not coding and would not listen to the other employess about ideas for the games. [fine, since this is hearsay] He and John Carmack held two different visions for the games they worked on. This got to the point where he [Romero] would not work on the same assignments as Carmack and would do his own thing. Carmack and the CEO fired Romero and another coworker [since it's very clearly lack of team effort, inability to perform adequatley, refusal to work, etc, no need to mention getting pised, or seting an example. Nor is it necessary to mention JC's perfectionism, which has no bearing on the story.] The whole team would go one way, and Romero refused to go with the flow. This, and not the long hours, is why he [Romero] left.
There's several kind of lag to deal with:
Server getting too many requests for resources.
Client getting pushed too much information.
Client getting pushed too little information.
Planned, intentional, latency is much more workable than a classic DoS. As a workaround, for example, you introduce locality.
IE, people get clustered around deputized local servers, so that you can bypass spanning the network.
If I broadcast 'Hi', it only needs to go up to the server and back down, but it's only spread around the local group. That way people in the virtual geographic space don't get spammed with my packets and lag is much reduced.
Anyway, that's just an idea.
Assuming you have a secure communication channel (whether it be trust, PKI, or other encryption), you can try to reduce lag by distributing resource request and allocation.
Rather than the server handling 100 clients, when it needs to push out identical data to all 100, you push out data to 10 of those clients and rely on those 10 clients to push out data to another 9 clients.
You can also push in the other direction. When client 1/100 says 'Hi!', rather than pushing it to the server to push it to 100 clients, the client pushes it to the client he's attached to, who pushes it out to the other 8 people, as well as to the server. The server then pushes the 'Hi' out to the other 9 clients it's connected to, who pushes out to their respective 9 clients.
It's akin to treating the connection to the server as some sort of nested tree; you introduce latency but reduce the amount of server lag.
Has anyone brought this up? Barring the copyright problems, this stacks up against the TiVo in most ways.
It may have more success as a way to time shift, and thus replace the conventional VHSR in the house, but because it's 2 years *after* TiVo, I wouldn't expect it to take off at all.
If this had been released 3 years ago (Possible! Sony had Digital8 around that time) and could record digitally onto standard VHS tapes and had a Firewire port for streaming of data around a Firewire network...
Heck, if they added that feature right now, I bet there would be a niche market for it!
Still, they should have released this product three years ago...
Wow, you're kidding, right?
A $3k DP G4 vs a, what, $10k SGI workstation... I guess you can get 3x animators working, at that rate, but I still imagine that for some things the performance of the Fuel would still be superior?
I dunno. How do people learn about AIDs, STDs, poisons, etc?
There are mechanisms in society for teaching about bad things without bad things happening, right?
If you're going to bring in MS and Windows... I'm going to have to say a stupid UI means stupid users. A UI that doesn't teach or protect or grow the user, is the Windows OS...
Not that there are much better, elsewhere! Just that MS is left holding the bar and standard since it's got the monopoly right now.
Oh. Right. Real insightful. Excuse the dripping sarcasm.
"It's not the OS it's the user that sucks. If it's user friendly, you get stupider people."
How self contradictory can you get? It's *not* the OS. No matter how user friendly or unfriendly, it's the user. Period. End of line.
If it's user friendly, you get a pleasant, useful, powerful, computing experience. That's it.
A user friendly OS and program with a stupid person does not make the OS insecure or the program flawed, or the UI wrong. It just means the user is stupid.
User friendly does not imply a stupid user.
What happened to the concepts of diversity, hybrid vigor, competition, and cooperation?
With Microsoft we get a monoculture.
Are you suggesting the same for all other OSes?
If nothing else this project encourages and explores compatibility issues, source examination, bug catching, performance tuning, and a bunch of other things, if only because a new, fresh, set of eyes (Debian) is looking at old things (BSD), and the other way around, BSD people looking at Debian things.
This cross pollination can have so many surprising and unexpected benefits too. Like the fact that if the kernal is BSD and the userland is Debian... it means you could, besides a little project called Fink, place an entire Debian OS layer on top of Apple's Darwin or Apple's OS X.
Then there is the ports system, which sounds very good to me. It's currently a BSD thing, but there's nothing stopping it from running on top of the Debian-netBSD distro, with work, and therefore stopping it from working on GNU-Debian with just a little more work, with 'work' and 'little more work' being subjective here.
These are just obvious speculations on my part. Many more advantages can be found, I'm sure, of this type of project.
Who said anything about brutalize?
Can you at least credit me, since you've just reposted my post way down below?
That's great news.
:)
I use PE on OS X. Maybe I'll try MacGIMP and see if what you claim is true
Actually, that means a company is forced to compete with it's own product, and therefore each release should be better and worth more than the release that preceeds it.
Over 2000 years of contract laws and beliefs go out the window then.
Do I have the right to take your shoes?
That's an excellent idea. You should go and do that :)
As it stands, Adobe has the right to follow it's own business model, because it works. Show them a better way that will make them more money, and I'm sure it will work out for all parties.
Sure, I can understand that view. Buy Photoshop 3.0 for $5.
That still doesn't justify $5 for Photoshop 6.0
You know, I could say the same thing about... your blood, or your life, or your shoes.
Sooo.... how does Adobe afford the production costs and the support costs and the bandwidth costs if they don't make any money on top of the distribution costs?