For that to happen I'd imagine that first we need to see a separation between dowloading the file, browsing a site and searching multiple sites.
The first two are available with FTP, though they are separated which allows you to do some more advanced things. (Like bouncing data without user intervention.) The latter is available with old progams like Archie and Veronica. (Searching multiple FTP sites that is.)
Most current P2P tools put all of these, and a few more, features in one package. Once you start seeing P2P tools which are sufficiently modularized I bet that more people with use them as dedicated servers. But before that you might just as well use FTP/Samba/NFS.
nown as "swarming" the download [...] It is my further understanding that you can only do this from people who have the *complete* file.
Not really. There is nothing stopping you from sharing the file befire you have all of it. It might be that it's not implemented in the different P2P programs, but that's just a coding issue. (Most likely to avoid problems with different files and such. You want to be sure that the file you have is correct before you begin sharing.)
For a WWW site this is not adequate however. As has been commented before the basis for Napster/Kazaa/etal is that the users are logged in a long time. Then it makes sense to wait until the download is completed before you start uploading. On a website you generally get the file and then go browse somewhere else. In other words, you don't gain anything.
Programs like Swarmcast use more advanced algorithms to distribute the files. They chop it up and then make redundant packages, so you increase the odds of getting valid ones. This also mean that you don't need to bother with administrating chains and other similar things. If a user is slow you will just not get all that many packets from him/her.
I'd recommend people that are interested in these more 'intelligent' P2P features to read the papers the Swarmcast guys have made. (www.opencola.com I think.) Lot's of interesting info there.
Hopefully we'll soon see these more advanced downloading schemes being used in normal P2P programs as well.
Well IMHO tar -xzf is more reliable that Teamware. The version we used even segfaulted on SUN's own OS/hardware. Naturally it was a reocurring bug nad simple to recreate. I'm just very happy that I never had to perform a rollback with it.
Do you/really/ think that 9/11 could have/anything/ to do with the game design? I wonder if there could be a simple way to find out if it were, something as easy as clicking the link and finding references to 9/11 on basically every page.
And I think you misspelled "FIRST POST" in the header.;-)
Mary's computer isn't decoding the movie, it's only storing it. And since information like this would be stored redundantly in a network such as this it doesn't matter if she stops sharing files all of a sudden. The user in Helsinki would only get the movie from some other place instead. (Most likely it would be assembled from multiple sources already so he wouldn't notice anything.)
See Freenet, SwarmCast and MojoNation for similar ideas already in use. (MojoNation is the closest which actually has distributed storage and a micro-economy. It just doesn't work very well in my experience.)
But a cookie wouldn't be able to do that any more magically, right?
It would be up to the broswer to refill the forms you have filled out and up to the state machine on the server to realise that you went back to a previous page. (And thus remove any posts you made.)
Actually with the number of cookie editors around I would actually assume that the risk is higher for a cookie.
And the cookie file is easily editable with Notepad/Emacs in any case. If you want to spoof another user by changing a hidden field you'd have to download the file, edit it and then spoof it so that it would seem to the server as if you had just accessed the page from the server itself.
And if you are nervous about spoofing ID's in the first place you should use a cryptographic hash as the session ID. Good luck spoofing that!
BEST DIRECTOR: Peter Jackson
Won't, but should. His work in showing characters of disproportionate size in the same shots is hugely underrated. It takes talent to fit that as seamlessly into a movie as Jackson did.
It was done in the editing room, with computers.
Not all of it was done digitally. They also had a lot of "scale doubles" who did scenes were possible. And a lot of perspective tricks, like using moving platforms to make the scale look the same as the camera was moved.
And stuff like finding the different enviroments could be accredited to Peter Jackson as well.
BTW the part about "scale doubles" should go for the costume people as well. They did have to make several identical (except for size) clothes for the actors and their doubles after all.
COSTUME DESIGN:
Shouldn't. Fantasy adventure is pretty easy to make neat-looking costumes for.
IMHO the costume design was fabulous. They had and incredible attention to detail. Such as the buttons their clothing were hand made and had small carvings in them. These were not visible in the film though. Now if/that/ isn't attention to detail I don't know what is.
WRITING (ADAPTED SCREENPLAY):
Shouldn't. Much of what made the book great was edited down, and the dialogue was run of the mill push-the-plot-forward stuff [...]
Well, it wouldn't be possible to include everything which made the book great, unfortunately. And at least I enjoyed how they added chapter titles as lines. And for instance how the Council of Elrond scene was adapted to screen. (The ring "wispering" to make the party quarrel.)
I was under the impression that Jikes is faster because it's iterative. (Well, it's probably a bit faster anyways.) It's not entirely compatible with javac though, eg you can't switch/case on bytes in Jikes but you can in Javac. I don't think you're supposed to do it however.
He also points out that "I can't be bothered to look up the statistics so I just make them up, but at least I'm honest about it.".
I'd also like to point out that I don't have that book (Dilbert [Principle|Future]) here right now so I can't be bothered to look up the exact quote, but at least I'm honest about it.
Someone else already mentioned that this is regarding mutual exclusion and not really pre-emption; but there is a neat tie in.
Or is there a way to prevent that from being preemptable?
Yes, you use spin-locks. These are basically semaphores but they work in an SMP context as well. These were already in the kernel, to make SMP work. They can also be used for pre-emption, because the basic problem is quite similar. So with this patch you are essentially running an SMP kernel, with a modified scheduler.
The reason your machine "feels" faster is that the GUI becomes more responsive. But that is pure illusion!
Well, you do decrease the actual latency of the system. That is the entire point of the patch. It is true that you also decrease the throughput of the system, so it will take longer to get the same work done. (Just as you stated.)
So when you click a button it actually/does/ respond faster, there is no illusion about that. As long as you are not already having throughput problems then this patch shouldn't completely wreck your system. (Well it might, but due to other parts of the system not wanting to be pre-emptible.)
I seem to recall that one of the bigger issues was that Linus wanted the problems to be fixd, not the symptoms.
That is, the correct way to fix this was not to make the kernel pre-empt., it was to make the slow parts in the kernel faster.
Seems like he changed his mind on that account though. (Or perhaps he just figures that this is a good way to "fix it for later". I would assume that they [core kernel hackers] have enough to do in any case.
And naturally the patch can (and has) introduce new bugs into the kernel which are complicated to debug. (Since when the kernel/driver were written it was assumed that it would be non pre-empt.)
Naturally, you should make it possible for lumberjacks to use chainsaws. It is also "common sense" that you don't give a chainsaw to your 5 year old to play with.
Choice is very good, but too much choice is generally bad. Particularly when you give the options to people which clearly shouldn't have them.
This is why it's not a good idea to let unsafe code be executed on a machine. Even if the user presses "OK" and thus at least the programmer or Microsoft can't be blamed. After all, if the user had any common sense he would know that it is bad to run untrusted code.
Unfortunately common sense isn't.
And if people didn't agree to things they didn't understand a lot of people would never get past the first install prompt they faced. As said, if you make user friendly programs and OS's, then you should expect that you will have a lot of computer novices behind the wheels.
Yes, but the people controlling that heli were "professionals". The point of the MIT one is to make it "dummy proof". So you have a rather advanced fly-by-wire system in it.
I'd say that is has mostly to do with how the engine actually works. Duke3D had room above rooms as well, it was still really a 2D engine with hacks though... (You could not see more than one height coordinate for one (x,y) coord on the map at once.)
I don't know how Marathon did it though. It seemed more like the Duke3D hack than the Quake way. And naturally Descent beat both AFAIK.
For me Quake was the first game which made me think "Now *this* is 3D." in any case.
he cautions against classifying games as an art form
So he's not suggesting that coding isn't art. He's stating that their games are not "art".
Perhaps we will see games in the future which are "art" in the sense that some movies are. Most likely they will not be very popular.;-)
If you want art in respect to graphic coding I'd suggest looking for it in the demo scene instead. That seems (to me at any rate) to be closer to the usual idea of "art".
I remember reading in an interview with Douglas Adams that one thing he wanted to do was a PDA+GPS+wireless(possibly) and then use it as a Hitch Hikers Guide to Earth. That was one of the ideas behind the H2G2 project.
That idea always appealed to me. It would be very nice to be able to leave small virtual GPS caches around for other people. And to get current information about any place in the world.
You really wouldn't need all that frequent updates, stopping by at an internet cafe once a week or so would do it easily. (Could be problematic if you're visiting California though.;-)
Slashdot Mirror
The iBook doesn't have magnesium cover, that's the TiBook. The iBook just have painted plastic. (Which is why these hacks are so easy to do.)
I do know that Direct Connect let's you download directories. Which is basically this. (As long as the 'publisher' has the data organized.)
For that to happen I'd imagine that first we need to see a separation between dowloading the file, browsing a site and searching multiple sites.
The first two are available with FTP, though they are separated which allows you to do some more advanced things. (Like bouncing data without user intervention.) The latter is available with old progams like Archie and Veronica. (Searching multiple FTP sites that is.)
Most current P2P tools put all of these, and a few more, features in one package. Once you start seeing P2P tools which are sufficiently modularized I bet that more people with use them as dedicated servers. But before that you might just as well use FTP/Samba/NFS.
Not really. There is nothing stopping you from sharing the file befire you have all of it. It might be that it's not implemented in the different P2P programs, but that's just a coding issue. (Most likely to avoid problems with different files and such. You want to be sure that the file you have is correct before you begin sharing.)
For a WWW site this is not adequate however. As has been commented before the basis for Napster/Kazaa/etal is that the users are logged in a long time. Then it makes sense to wait until the download is completed before you start uploading. On a website you generally get the file and then go browse somewhere else. In other words, you don't gain anything.
Programs like Swarmcast use more advanced algorithms to distribute the files. They chop it up and then make redundant packages, so you increase the odds of getting valid ones. This also mean that you don't need to bother with administrating chains and other similar things. If a user is slow you will just not get all that many packets from him/her.
I'd recommend people that are interested in these more 'intelligent' P2P features to read the papers the Swarmcast guys have made. (www.opencola.com I think.) Lot's of interesting info there.
Hopefully we'll soon see these more advanced downloading schemes being used in normal P2P programs as well.
Well IMHO tar -xzf is more reliable that Teamware. The version we used even segfaulted on SUN's own OS/hardware. Naturally it was a reocurring bug nad simple to recreate. I'm just very happy that I never had to perform a rollback with it.
And Google Boy to the rescue:
Next Time, What Say We Boil a Consultant
What is that I hear? Another "Ask Slashdot" question being typed in? Up up and away!
Do you /really/ think that 9/11 could have /anything/ to do with the game design? I wonder if there could be a simple way to find out if it were, something as easy as clicking the link and finding references to 9/11 on basically every page.
;-)
And I think you misspelled "FIRST POST" in the header.
Mary's computer isn't decoding the movie, it's only storing it. And since information like this would be stored redundantly in a network such as this it doesn't matter if she stops sharing files all of a sudden. The user in Helsinki would only get the movie from some other place instead. (Most likely it would be assembled from multiple sources already so he wouldn't notice anything.)
See Freenet, SwarmCast and MojoNation for similar ideas already in use. (MojoNation is the closest which actually has distributed storage and a micro-economy. It just doesn't work very well in my experience.)
But a cookie wouldn't be able to do that any more magically, right?
It would be up to the broswer to refill the forms you have filled out and up to the state machine on the server to realise that you went back to a previous page. (And thus remove any posts you made.)
Actually with the number of cookie editors around I would actually assume that the risk is higher for a cookie.
And the cookie file is easily editable with Notepad/Emacs in any case. If you want to spoof another user by changing a hidden field you'd have to download the file, edit it and then spoof it so that it would seem to the server as if you had just accessed the page from the server itself.
And if you are nervous about spoofing ID's in the first place you should use a cryptographic hash as the session ID. Good luck spoofing that!
What's stopping you from putting a session ID in the hidden field? That would yield the same result.
I do agree with you though. At least I don't have a big problem with cookies.
DRI is only used if you actually have a need for high performance graphics. If you run a server with unstable DRI drivers then you deserve pain.
Naturally sane Windows admins would also refrain from using the latest cards from ATI or nVida or whatever and then installing alpha drivers.
It is less of an issue on *nix though, since you actually have to go out of your way to mess it up like that.
Not all of it was done digitally. They also had a lot of "scale doubles" who did scenes were possible. And a lot of perspective tricks, like using moving platforms to make the scale look the same as the camera was moved.
And stuff like finding the different enviroments could be accredited to Peter Jackson as well.
BTW the part about "scale doubles" should go for the costume people as well. They did have to make several identical (except for size) clothes for the actors and their doubles after all.
IMHO the costume design was fabulous. They had and incredible attention to detail. Such as the buttons their clothing were hand made and had small carvings in them. These were not visible in the film though. Now if
Well, it wouldn't be possible to include everything which made the book great, unfortunately. And at least I enjoyed how they added chapter titles as lines. And for instance how the Council of Elrond scene was adapted to screen. (The ring "wispering" to make the party quarrel.)
I was under the impression that Jikes is faster because it's iterative. (Well, it's probably a bit faster anyways.) It's not entirely compatible with javac though, eg you can't switch/case on bytes in Jikes but you can in Javac. I don't think you're supposed to do it however.
He also points out that "I can't be bothered to look up the statistics so I just make them up, but at least I'm honest about it.".
I'd also like to point out that I don't have that book (Dilbert [Principle|Future]) here right now so I can't be bothered to look up the exact quote, but at least I'm honest about it.
Yes, you use spin-locks. These are basically semaphores but they work in an SMP context as well. These were already in the kernel, to make SMP work. They can also be used for pre-emption, because the basic problem is quite similar. So with this patch you are essentially running an SMP kernel, with a modified scheduler.
Very clever trick.
Well, you do decrease the actual latency of the system. That is the entire point of the patch. It is true that you also decrease the throughput of the system, so it will take longer to get the same work done. (Just as you stated.)
So when you click a button it actually
I seem to recall that one of the bigger issues was that Linus wanted the problems to be fixd, not the symptoms.
That is, the correct way to fix this was not to make the kernel pre-empt., it was to make the slow parts in the kernel faster.
Seems like he changed his mind on that account though. (Or perhaps he just figures that this is a good way to "fix it for later". I would assume that they [core kernel hackers] have enough to do in any case.
And naturally the patch can (and has) introduce new bugs into the kernel which are complicated to debug. (Since when the kernel/driver were written it was assumed that it would be non pre-empt.)
Naturally, you should make it possible for lumberjacks to use chainsaws. It is also "common sense" that you don't give a chainsaw to your 5 year old to play with.
Choice is very good, but too much choice is generally bad. Particularly when you give the options to people which clearly shouldn't have them.
This is why it's not a good idea to let unsafe code be executed on a machine. Even if the user presses "OK" and thus at least the programmer or Microsoft can't be blamed. After all, if the user had any common sense he would know that it is bad to run untrusted code.
Unfortunately common sense isn't.
And if people didn't agree to things they didn't understand a lot of people would never get past the first install prompt they faced. As said, if you make user friendly programs and OS's, then you should expect that you will have a lot of computer novices behind the wheels.
Yes, but the people controlling that heli were "professionals". The point of the MIT one is to make it "dummy proof". So you have a rather advanced fly-by-wire system in it.
I'd say that is has mostly to do with how the engine actually works. Duke3D had room above rooms as well, it was still really a 2D engine with hacks though... (You could not see more than one height coordinate for one (x,y) coord on the map at once.)
I don't know how Marathon did it though. It seemed more like the Duke3D hack than the Quake way. And naturally Descent beat both AFAIK.
For me Quake was the first game which made me think "Now *this* is 3D." in any case.
So he's not suggesting that coding isn't art. He's stating that their games are not "art".
Perhaps we will see games in the future which are "art" in the sense that some movies are. Most likely they will not be very popular.
If you want art in respect to graphic coding I'd suggest looking for it in the demo scene instead. That seems (to me at any rate) to be closer to the usual idea of "art".
Haha, I was just on the verge of posting a comment "Serious?" but you beat me to it.
;-)
"-1, Off-topic" indeed. It's a tough world to be witty in.
I remember reading in an interview with Douglas Adams that one thing he wanted to do was a PDA+GPS+wireless(possibly) and then use it as a Hitch Hikers Guide to Earth. That was one of the ideas behind the H2G2 project.
;-)
That idea always appealed to me. It would be very nice to be able to leave small virtual GPS caches around for other people. And to get current information about any place in the world.
You really wouldn't need all that frequent updates, stopping by at an internet cafe once a week or so would do it easily. (Could be problematic if you're visiting California though.