Anyone remember the film version of 2010? This picture looks a lot like the effects they created near the end, when the zillions of monoliths were starting to eat Jupiter. Well, except for the Jupiter part.
>Not too long from now, you won't have to practice that perfect golf swing for months. You'll just go >to a walk-in clinic and have the responsible nerves anodized during lunch time, and be out on the >green, kicking butt and taking names by early afternoon.
Umn, no.
It might be possible to acquire abstract information this way, but most physical activities require MUCH more than the neural knowledge. You could get 'programmed' to play piano in an afternoon, sure, but you wouldn't suddenly get the muscular strength and flexibility in your fingers that would be necessary to implement that knowledge.
The same applies for any physical activity that currently requires practice -- there's much more than the "book learning" going on there, so your hypothetical golf swing in a simgle download is simply not going to happen.
"Well, my distro's company has 135 people on-staff, and yours only has 127."
"Oh, yeah, well, my distro uses the latest version of the KNODE desktop, and yours defaults to an older version of GNM!"
"Oh yeah, well, my distro has version 1.0.3a of libdumbthing, and yours is stuck at version 1.0.3!"
"Oh yeah, well my distro is supported in my native language, at least!"
"Oh yeah, well my distro's company channels 127% of their profits into development of Open Source software for getting food to Vietnamese orphans!"
"Oh yeah, _VIETNAMESE_ orphans... that went out with glibc 2.0. My distro's entire staff pays $25/hour for the privelege of contributing to the code, into a fund to educate Laotian children to program in Java."
I keep seeing a lot of "Glide is irrelevant because everyone's coding to OpenGL now" posts.
Umn, folks, the Quake GL-miniport, Mesa on Linux, basically _all_ of the hardware-accelerated OpenGL implementations _depend_ on Glide for their 3Dfx support.
This is a good thing, because there'd otherwise have to be individual register-level versions of, say, Mesa, for each new 3Dfx card that came out. Glide is a nice thin API layer insulating the hardware details of the card from the actual 3D toolkit being used.
Nobody writes directly to Glide any more, no, but it's still a _very_ important part of the 3Dfx acceleration stack. And, as an AC mentioned above, the only major 3D API that MS doesn't have a finger in.
I, for one, am glad to see 3Dfx trying to keep Glide clean to their vision, although I also would prefer it not be proprietary.
>I can understand distributed.net not releasing their source, because they're trying to conduct a fair and honest competition.
But isn't that what you want out of a game, too? Fair and honest competition? I'm not just being contrary, here, I'm actually interested in hearing schemes by which a multiplayer game could be totally Open Source, and still somehow offer fairness and honesty.
Then we're back to the same issue -- your scenario seems to assume anyone could throw up a server and participate in the same large communal world.
But if the code's open, there's nothing preventing someone from attaching a modified server that brings down the whole mess, either through malice or ignorance. Can't have that.
Or from starting up their own private server, creating a world where they can pick up arbitrarily cool items and experience for free, then connecting their newly-butch character back to the main network.
I need to do some more thinking on this, because I think there's something axiomatic here about the applicability of Open Source to cooperative versus competitive arenas. Hmmn.
I've been pondering a game project myself, lately, and while I'm a big believer in the power of Open Source to improve the quality of software, I have some reservations about opening the source to multiplayer games.
Specifically, once the source goes public, there is no feasible way to prevent end users from changing the code to give themselves unfair advantages -- faster movement, more powerful weapons, brighter gamma correction, whatever -- and so disrupting the balance of the game.
As a different model, I point to the distributed.net folks, who don't release their source for very similar reasons. I posit a game-development model that follows their model -- aggressive bug fixing, constant posting of updated binaries for as many OSes as possible, and generally the same speed and responsiveness as an Open Source project, just without the actual source out there. Something much like id's scheme, but faster and more multi-platform.
Thoughts? I'd like to think that Open Source is generally a Good Thing(tm), but I'd like to hear feedback on how to make sure everyone's on a level playing field if your client code can be modified.
Yes, that solves the rogue server problem. It also re-creates the original problem that opening the server code was supposed to solve -- scalability.
If you have to be trusted to join the primary network, you create an enormous headache for the administrators in terms of validating which servers can join. You obviously can't just let any current server admin approve some other server to connect to it, a la IRC, or you fall prey to con-man attacks where a seemingly-trustworthy server is allowed to attach, and then that admin lets all his script-kiddie buddies attach at his node.
And, finally, you'd have to do constant vigilance above and beyond the original validation of a new server, so you don't get servers that are validated as running good code, and then install rogue code later.
So, your scheme re-introduces the scalability nightmare that opening up the server code was supposed to address in the first place.
Slashdot Mirror
Anyone remember the film version of 2010? This picture looks a lot like the effects they created near the end, when the zillions of monoliths were starting to eat Jupiter. Well, except for the Jupiter part.
Just a passing thought.
--
>Not too long from now, you won't have to practice that perfect golf swing for months. You'll just go
>to a walk-in clinic and have the responsible nerves anodized during lunch time, and be out on the
>green, kicking butt and taking names by early afternoon.
Umn, no.
It might be possible to acquire abstract information this way, but most physical activities require MUCH more than the neural knowledge. You could get 'programmed' to play piano in an afternoon, sure, but you wouldn't suddenly get the muscular strength and flexibility in your fingers that would be necessary to implement that knowledge.
The same applies for any physical activity that currently requires practice -- there's much more than the "book learning" going on there, so your hypothetical golf swing in a simgle download is simply not going to happen.
--
...of course. Mozilla Public License v 1.1 according to the site.
-r--r--r-- 1 root root 1888809 Aug 2 1995 linux-1.2.13.tar.bz2
-rw-r--r-- 1 root root 6099082 Jun 14 05:15 linux-2.0.37.tar.bz2
-rw-r--r-- 1 root root 11235732 May 13 23:54 linux-2.2.9.tar.bz2
That's a 500% increase, in less than three years. NT in the same period has roughly doubled in size.
"Well, my distro's company has 135 people on-staff, and yours only has 127."
"Oh, yeah, well, my distro uses the latest version of the KNODE desktop, and yours defaults to an older version of GNM!"
"Oh yeah, well, my distro has version 1.0.3a of libdumbthing, and yours is stuck at version 1.0.3!"
"Oh yeah, well my distro is supported in my native language, at least!"
"Oh yeah, well my distro's company channels 127% of their profits into development of Open Source software for getting food to Vietnamese orphans!"
"Oh yeah, _VIETNAMESE_ orphans... that went out with glibc 2.0. My distro's entire staff pays $25/hour for the privelege of contributing to the code, into a fund to educate Laotian children to program in Java."
"Whatever."
"Moron."
I keep seeing a lot of "Glide is irrelevant because everyone's coding to OpenGL now" posts.
Umn, folks, the Quake GL-miniport, Mesa on Linux, basically _all_ of the hardware-accelerated OpenGL implementations _depend_ on Glide for their 3Dfx support.
This is a good thing, because there'd otherwise have to be individual register-level versions of, say, Mesa, for each new 3Dfx card that came out. Glide is a nice thin API layer insulating the hardware details of the card from the actual 3D toolkit being used.
Nobody writes directly to Glide any more, no, but it's still a _very_ important part of the 3Dfx acceleration stack. And, as an AC mentioned above, the only major 3D API that MS doesn't have a finger in.
I, for one, am glad to see 3Dfx trying to keep Glide clean to their vision, although I also would prefer it not be proprietary.
>I can understand distributed.net not releasing their source, because they're trying to conduct a fair and honest competition.
But isn't that what you want out of a game, too? Fair and honest competition? I'm not just being contrary, here, I'm actually interested in hearing schemes by which a multiplayer game could be totally Open Source, and still somehow offer fairness and honesty.
Then we're back to the same issue -- your scenario seems to assume anyone could throw up a server and participate in the same large communal world.
But if the code's open, there's nothing preventing someone from attaching a modified server that brings down the whole mess, either through malice or ignorance. Can't have that.
Or from starting up their own private server, creating a world where they can pick up arbitrarily cool items and experience for free, then connecting their newly-butch character back to the main network.
I need to do some more thinking on this, because I think there's something axiomatic here about the applicability of Open Source to cooperative versus competitive arenas. Hmmn.
I've been pondering a game project myself, lately, and while I'm a big believer in the power of Open Source to improve the quality of software, I have some reservations about opening the source to multiplayer games.
Specifically, once the source goes public, there is no feasible way to prevent end users from changing the code to give themselves unfair advantages -- faster movement, more powerful weapons, brighter gamma correction, whatever -- and so disrupting the balance of the game.
As a different model, I point to the distributed.net folks, who don't release their source for very similar reasons. I posit a game-development model that follows their model -- aggressive bug fixing, constant posting of updated binaries for as many OSes as possible, and generally the same speed and responsiveness as an Open Source project, just without the actual source out there. Something much like id's scheme, but faster and more multi-platform.
Thoughts? I'd like to think that Open Source is generally a Good Thing(tm), but I'd like to hear feedback on how to make sure everyone's on a level playing field if your client code can be modified.
Yes, that solves the rogue server problem. It also re-creates the original problem that opening the server code was supposed to solve -- scalability.
If you have to be trusted to join the primary network, you create an enormous headache for the administrators in terms of validating which servers can join. You obviously can't just let any current server admin approve some other server to connect to it, a la IRC, or you fall prey to con-man attacks where a seemingly-trustworthy server is allowed to attach, and then that admin lets all his script-kiddie buddies attach at his node.
And, finally, you'd have to do constant vigilance above and beyond the original validation of a new server, so you don't get servers that are validated as running good code, and then install rogue code later.
So, your scheme re-introduces the scalability nightmare that opening up the server code was supposed to address in the first place.