Humans are dependent on solar power, not machines Where does this come from?
Humans are no more or less dependent on solar power than machines. We can just as easily make UV lamps if there is a power source available, and the same "law of thermodynamics" problems are going to bite the machines unless they have some solar satellites or something.
Humans raised in the Matrix don't know anything about the laws of thermodynamics because the Machines control everything they learn. See, this kind of kills the whole "We could be living in the Matrix!" thought that haunts you after the first time you watch it.
That old guy who talked to Neo in the second film seemed to have an inkling of the situation, but had no hard-science context to express it with since he'd never learned any real science. If by "that old guy" you mean The Architect, how did it possibly escape you that he's an AI?
Needless to say, none of the Matrix AI programs would have any need to understand physics outside of the Matrix either. And yet, once you start moving beyond Agents, the machines actually start to be curious.
I'd put that down as the main thing I think got badly fucked with in the sequels. In the original, the machines are cold and heartless, except Smith, who is downright evil. No AI is actually to where it could really pass for a human, yet.
In the sequels, there are other, equally interesting premises -- an AI which loves its daughter -- but that kills the whole concept of certain people who seem like machines in our world actually being machines, because after that, anyone could be an AI.
Fair enough. I'm assuming this isn't something you can just fix -- otherwise, I'd say that it's someone who still weighs 100 pounds, doesn't eat their vegetables and/or doesn't go to the gym.
But let me put it this way: If you were missing a leg, should you be a cop?
Same thing with the weight.
(By the way, the answer might be "yes", but I think essentially arguing that the taser is, in fact, for people who otherwise wouldn't physically be cut out for that kind of work, suggests that people who actually can handle themselves in close combat shouldn't carry tasers, or should almost never fire them.)
Use it like it was intended. Host your own official, public one if you like, but that can be over DSL, even.
Push the real traffic (patches, updates, etc) onto some mailing list, newsgroup, even forum -- those can be moved trivially, and your DVCS doesn't care what you're using, or can be adapted relatively quickly.
Freenet has been generally useless, as far as I can see. It's a very cool idea, but the only implementation I've ever seen is terminally fucking slow. Seriously, I browsed the Internet from a 200 mhz eMachine, running Windows 98, on a USB modem that lagged the system as badly as a floppy would (hey, remember Windows 98?) -- and that was faster than Freenet.
It's gotten better, but all of the above statements remain true. I'd consider Freenet if I really had something that needed that much hiding. For something like this, simple non-US development and synchronization via mailing list is enough, I think.
Quoting TFA again, for reference:
"I sent it to Strauss Zelnick's attorney. I would never send it to his mother," Mr. Thompson told me. *cough* BULLSHIT *cough*
Letter opens:
Dear Mrs. Zelnick:
Your son, as you may know (or maybe you donâ(TM)t know), is Chairman of Take-Two Interactive Software, Inc., whose most popular video games are the Grand Theft Auto murder simulator games banned in some countries but sold to children here. If that was really intended for the attorney, and not for the mother, Jack's even less coherent than we thought.
It's an older concept than that, even. Goes back to the strange Debian habit of using a tool called Jigdo -- it would provide essentially a recipe for building an ISO out of all the files needed, where the files were mostly available from standard Debian mirrors. ISOs were available from far fewer mirrors than standard Debian packages, you see.
So, you'd use Jigdo, and if all went well, it'd assemble a working image. But if a few packages couldn't be downloaded, you could always take your mostly-complete Jigdo file and use rsync with an rsync-capable mirror. (Or, more recently, BitTorrent on Ubuntu -- but that's another story.)
I don't think this tactic is very common, though, as most people seem to have no fucking clue how BitTorrent works. I've seen torrents with gigantic multipart RARs, with an SFV of those. Let's see... so, my torrent software is already checksumming everything, and RAR has a builtin checksum too, or at least, acts like it does (it says "ok" or not) -- and on top of that, there's an SFV checksum (crappy CRC32), too. Never mind that RAR saves you at most a few megabytes (video is already compressed), which, based on the size of these files, you'll spend more time unpacking the RAR than you would downloading the extra couple megs. Or that, once you unpack and throw away the RAR, you can't seed that torrent from the working video. Or that multipart anything is retarded on BitTorrent, as the torrent is splitting it into 512k-4meg chunks anyway.
Whoops, end of rant. Oh, by the way, that wasn't about me, it was about my friend. Wink wink.
It's obvious you have no clue how the Internet actually works. Shit happens, but the Internet is designed for it... Maybe it's the crappy cheap NAT router I'm fairly sure that's what GP meant.
Oh, man, reading that page... you just can't make this shit up:
I WILL CONTROL MY OWN DESTINY
In todayâ(TM)s world, maintaining self-confidence involves the need for self-protection. For independent, self-reliant women, the TASER® C2 is an effective personal protection device that fits any lifestyle. Ok, that I can go with... but "fits any lifestyle"? Hmm... Next slide:
THERE WHEN I CAN'T BE
The commitment to protect the family, is more than something rational. It is innate. What is rational is taking steps to reconcile the instinct to protect, to always be there when needed. This seems to be advocating giving tasers to friends and family. Still not too bad...
FASHION WITH A BITE
Let innovative design, unparalleled performance, and breakthrough style help you make a statement. Who says safety can't be stylish? Ok, WTF. What does it say about our society that we have designer fucking tasers?
TASER MPH HOLSTER mixing music with security
Play your favorite songs while on the go, with this combination TASER® C2 Holster and easy-to-use music player. The 1 GB TASER MPH Holster offers you both security and music while on the go. Yes... we are talking about a combination. Taser. And. MP3. Player.
Really, we can't be far off from this kind of stuff. (For those who don't know, that was one of their April Fools products.)
Well, actually, in Half-Life 2, you reflexively lower your shotgun when you'd rather talk to someone. Without mods, it's impossible to point your weapon at a friendly, let alone hurt them.
I suppose that would work... Erlang isn't quite that, though. That's how a purely-functional language would work, which Erlang isn't.
Variables may not be changed once bound, but they can be either bound or unbound, and that is a mutable state -- they can change from unbound to bound. If variables were globally accessible in Erlang, I could see race conditions happening.
The way Erlang avoids locks is by having a shared-nothing architecture. It's all done with message-passing.
That's the same as try/finally in Java or Python. Right. I like to use my language of choice in examples; I'm less likely to get it wrong that way.
It's either assembly language, C, C++ without iostream I see.
But that's not a case for goto -- that's a case against languages that lack good exception handling. Or it's a case for adding a 'finally' clause to C++.
Don't 'return' from the function. Instead, when you would 'return', do 'goto ret', which calls the destructors as needed. It seems like this would have the same problems. For example:
int do_some_calculation(int a, int b) {
return a/b; }
#define ERROR -1
void foo() {
do_library_setup_stuff();
int result = do_some_calculation(5, 0);
if (result == ERROR) {
goto ret;
}
do_something_with(result);
ret:
do_library_cleanup_stuff(); }
See the problem? You need to wrap it in a try block anyway -- or you need to wrap your resources in an object with proper destructors. I don't see what goto buys you, unless you can guarantee that exceptions won't be thrown.
From the Grand Central homepage:
You need Flash to use GrandCentral. Get it here Ok, is there any chance of this working with actual, published, open protocols for making and receiving calls?
My favorite quote so far:
You reject the idea that the intellectual elite, which I think is fairly represented here, should not run this country? MR. BECKERMAN: The law runs the country. This is a nation of law, not a country of lawyers who are best paid by large content owners. Ad-hominem or not, that just made my day.
Fair enough. I'm not so much debating that there will be any home directories...
I'm suggesting that the NFS solution may well work for central campus home directories, but looks like it would not work well at all for the kinds of files you'd be dealing with on a supercomputer.
There were quite a few of them that have to be set up and destroyed. These handlers could be passed around as parameters but there was an increasing number of them and passing them around was adding significant complexity. Wrap them in an object -- one object. That's not a lot of complexity.
Unfortunately exceptions are not always an option and may not be thrown when you want to, esp if the library you are interacting with does not throw exceptions. Presumably they do give you an error at some point, right?
begin
result = stuff_that_can_fail_horribly
throw 'It failed horribly' if result.nil?
do_more_stuff_that_throws_proper_exceptions ensure ... end
Even then an exception only works if you have a way to catch the needed calls when unrolling the stack. When would you not?
Oh, by the way -- "ensure", in Ruby, is a block which is guaranteed to run after the "begin" block finishes, exceptions or not. It seems to be the absolutely perfect, logical fit for what you're trying to do.
Sure you can wrap up the c handlers in c++ objects which then have automagic destructors, but that is a lot of extra layers and code just to get around using a goto. I still don't see how the goto is easier, in this case. Seems to me, you end up with the exact same problems -- when does that goto happen? How do you make sure it gets called, and how do you make sure you catch the error condition properly?
I hate to be a cynic, but come on. Quake 1 was released in 1996. It is 2008. According to Moore's Law, we are running on machines some four thousand times faster than Quake was designed for. Wake me up when we can play real games in Flash.
That said, at least it's better than people trying to build a 3D engine on top of 2D flash. Apparently, Flash 10 is actually going to have hardware-accelerated 3D.
And you're right, most Flash people are designers, but there's more than enough blame to spread around. I remember testing Flash on a 1.8 ghz amd64, versus mplayer and vlc on the same video. The Flash (on YouTube) used some 50% CPU in a window, and couldn't go fullscreen (at the time). None of the other video players (again, on the exact same video) used more than about 2% CPU, even fullscreen. So Flash is, at best, twenty-five times slower than a reverse-engineered, open source implementation of the same video codecs.
This particular problem has since been addressed, somewhat -- fullscreen flash is accelerated, I think. But I have absolutely no more faith in Adobe than I do in random Flash game developers.
Well, I don't know of anything else you'd replace it with. (I consider processes to be a higher level of abstraction.)
What else were you suggesting -- just ignore the issue? The implicit assumption here is that we must write programs which can scale to multiple cores, because single cores are running into the limitations of physics.
Erlang makes multithreading on the same machine easy, using a message-passing model. If you need to connect to a remote machine, you can do that pretty much as easily. It would work well on a Beowulf cluster.
I'm not sure how well it would work on a "single-image cluster farm", but I don't see why it would be any harder to create multiple Erlang processes on the same "machine" and have them pretend to be remote.
That is one of many, many things I find wrong with Erlang, although I would suggest that a good book on Erlang will help a lot. Erlang isn't purely functional, and it is actually pretty easy to pick up.
But Erlang also has horrible syntax, not particularly good Unicode support, and all the other problems you'd expect from a language that isn't popular. I'd much rather steal Erlang's message-passing and use it in another language.
And message-passing really is a good deal more intuitive than locks, semaphores, and all the other threading things. Threading is hard. Doing it shared-nothing, as processes, is much easier.
The main problem I have with Java threads, vs Erlang, is that Java threads are still using locks. They're locks with nice syntactic sugar on them, but locks nonetheless.
Slashdot Mirror
Humans are no more or less dependent on solar power than machines. We can just as easily make UV lamps if there is a power source available, and the same "law of thermodynamics" problems are going to bite the machines unless they have some solar satellites or something. Humans raised in the Matrix don't know anything about the laws of thermodynamics because the Machines control everything they learn. See, this kind of kills the whole "We could be living in the Matrix!" thought that haunts you after the first time you watch it. That old guy who talked to Neo in the second film seemed to have an inkling of the situation, but had no hard-science context to express it with since he'd never learned any real science. If by "that old guy" you mean The Architect, how did it possibly escape you that he's an AI? Needless to say, none of the Matrix AI programs would have any need to understand physics outside of the Matrix either. And yet, once you start moving beyond Agents, the machines actually start to be curious.
I'd put that down as the main thing I think got badly fucked with in the sequels. In the original, the machines are cold and heartless, except Smith, who is downright evil. No AI is actually to where it could really pass for a human, yet.
In the sequels, there are other, equally interesting premises -- an AI which loves its daughter -- but that kills the whole concept of certain people who seem like machines in our world actually being machines, because after that, anyone could be an AI.
Fair enough. I'm assuming this isn't something you can just fix -- otherwise, I'd say that it's someone who still weighs 100 pounds, doesn't eat their vegetables and/or doesn't go to the gym.
But let me put it this way: If you were missing a leg, should you be a cop?
Same thing with the weight.
(By the way, the answer might be "yes", but I think essentially arguing that the taser is, in fact, for people who otherwise wouldn't physically be cut out for that kind of work, suggests that people who actually can handle themselves in close combat shouldn't carry tasers, or should almost never fire them.)
Use it like it was intended. Host your own official, public one if you like, but that can be over DSL, even.
Push the real traffic (patches, updates, etc) onto some mailing list, newsgroup, even forum -- those can be moved trivially, and your DVCS doesn't care what you're using, or can be adapted relatively quickly.
Freenet has been generally useless, as far as I can see. It's a very cool idea, but the only implementation I've ever seen is terminally fucking slow. Seriously, I browsed the Internet from a 200 mhz eMachine, running Windows 98, on a USB modem that lagged the system as badly as a floppy would (hey, remember Windows 98?) -- and that was faster than Freenet.
It's gotten better, but all of the above statements remain true. I'd consider Freenet if I really had something that needed that much hiding. For something like this, simple non-US development and synchronization via mailing list is enough, I think.
Or maybe Teal'c, just to be ironic.
Letter opens: Dear Mrs. Zelnick:
Your son, as you may know (or maybe you donâ(TM)t know), is Chairman of Take-Two Interactive Software, Inc., whose most popular video games are the Grand Theft Auto murder simulator games banned in some countries but sold to children here. If that was really intended for the attorney, and not for the mother, Jack's even less coherent than we thought.
It's an older concept than that, even. Goes back to the strange Debian habit of using a tool called Jigdo -- it would provide essentially a recipe for building an ISO out of all the files needed, where the files were mostly available from standard Debian mirrors. ISOs were available from far fewer mirrors than standard Debian packages, you see.
So, you'd use Jigdo, and if all went well, it'd assemble a working image. But if a few packages couldn't be downloaded, you could always take your mostly-complete Jigdo file and use rsync with an rsync-capable mirror. (Or, more recently, BitTorrent on Ubuntu -- but that's another story.)
I don't think this tactic is very common, though, as most people seem to have no fucking clue how BitTorrent works. I've seen torrents with gigantic multipart RARs, with an SFV of those. Let's see... so, my torrent software is already checksumming everything, and RAR has a builtin checksum too, or at least, acts like it does (it says "ok" or not) -- and on top of that, there's an SFV checksum (crappy CRC32), too. Never mind that RAR saves you at most a few megabytes (video is already compressed), which, based on the size of these files, you'll spend more time unpacking the RAR than you would downloading the extra couple megs. Or that, once you unpack and throw away the RAR, you can't seed that torrent from the working video. Or that multipart anything is retarded on BitTorrent, as the torrent is splitting it into 512k-4meg chunks anyway.
Whoops, end of rant. Oh, by the way, that wasn't about me, it was about my friend. Wink wink.
Oh, and TCP checksumming isn't perfect.
More relevantly: Maybe someone still weighing 100 pounds hasn't been hitting the gym much, and should consider a different line of work.
In todayâ(TM)s world, maintaining self-confidence involves the need for self-protection. For independent, self-reliant women, the TASER® C2 is an effective personal protection device that fits any lifestyle. Ok, that I can go with... but "fits any lifestyle"? Hmm... Next slide: THERE WHEN I CAN'T BE
The commitment to protect the family, is more than something rational. It is innate. What is rational is taking steps to reconcile the instinct to protect, to always be there when needed. This seems to be advocating giving tasers to friends and family. Still not too bad... FASHION WITH A BITE
Let innovative design, unparalleled performance, and breakthrough style help you make a statement. Who says safety can't be stylish? Ok, WTF. What does it say about our society that we have designer fucking tasers? TASER MPH HOLSTER
mixing music with security
Play your favorite songs while on the go, with this combination TASER® C2 Holster and easy-to-use music player. The 1 GB TASER MPH Holster offers you both security and music while on the go. Yes... we are talking about a combination. Taser. And. MP3. Player.
Really, we can't be far off from this kind of stuff. (For those who don't know, that was one of their April Fools products.)
Well, actually, in Half-Life 2, you reflexively lower your shotgun when you'd rather talk to someone. Without mods, it's impossible to point your weapon at a friendly, let alone hurt them.
I suppose that would work... Erlang isn't quite that, though. That's how a purely-functional language would work, which Erlang isn't.
Variables may not be changed once bound, but they can be either bound or unbound, and that is a mutable state -- they can change from unbound to bound. If variables were globally accessible in Erlang, I could see race conditions happening.
The way Erlang avoids locks is by having a shared-nothing architecture. It's all done with message-passing.
But that's not a case for goto -- that's a case against languages that lack good exception handling. Or it's a case for adding a 'finally' clause to C++. Don't 'return' from the function. Instead, when you would 'return', do 'goto ret', which calls the destructors as needed. It seems like this would have the same problems. For example:
int do_some_calculation(int a, int b) {
return a/b;
}
#define ERROR -1
void foo() {
do_library_setup_stuff();
int result = do_some_calculation(5, 0);
if (result == ERROR) {
goto ret;
}
do_something_with(result);
ret:
do_library_cleanup_stuff();
}
See the problem? You need to wrap it in a try block anyway -- or you need to wrap your resources in an object with proper destructors. I don't see what goto buys you, unless you can guarantee that exceptions won't be thrown.
Yes, I got that... not sure how that's being ironic, though.
Or do I need to have Flash on my phone?
Meanwhile, back on Slashdot, where I can be as intellectually lazy as I like...
I wonder if it says something that a simple fact was taken as an ad hominem -- that it was taken so personally suggests it struck close to home.
MR. BECKERMAN: The law runs the country. This is a nation of law, not a country of lawyers who are best paid by large content owners. Ad-hominem or not, that just made my day.
Fair enough. I'm not so much debating that there will be any home directories...
I'm suggesting that the NFS solution may well work for central campus home directories, but looks like it would not work well at all for the kinds of files you'd be dealing with on a supercomputer.
Ugh, I hate that.
I haven't yet found a way around it, other than pretty much completely removing the code samples.
Oh, by the way -- "ensure", in Ruby, is a block which is guaranteed to run after the "begin" block finishes, exceptions or not. It seems to be the absolutely perfect, logical fit for what you're trying to do. Sure you can wrap up the c handlers in c++ objects which then have automagic destructors, but that is a lot of extra layers and code just to get around using a goto. I still don't see how the goto is easier, in this case. Seems to me, you end up with the exact same problems -- when does that goto happen? How do you make sure it gets called, and how do you make sure you catch the error condition properly?
Quake 1 fullscreen, wow.
I hate to be a cynic, but come on. Quake 1 was released in 1996. It is 2008. According to Moore's Law, we are running on machines some four thousand times faster than Quake was designed for. Wake me up when we can play real games in Flash.
That said, at least it's better than people trying to build a 3D engine on top of 2D flash. Apparently, Flash 10 is actually going to have hardware-accelerated 3D.
And you're right, most Flash people are designers, but there's more than enough blame to spread around. I remember testing Flash on a 1.8 ghz amd64, versus mplayer and vlc on the same video. The Flash (on YouTube) used some 50% CPU in a window, and couldn't go fullscreen (at the time). None of the other video players (again, on the exact same video) used more than about 2% CPU, even fullscreen. So Flash is, at best, twenty-five times slower than a reverse-engineered, open source implementation of the same video codecs.
This particular problem has since been addressed, somewhat -- fullscreen flash is accelerated, I think. But I have absolutely no more faith in Adobe than I do in random Flash game developers.
Well, I don't know of anything else you'd replace it with. (I consider processes to be a higher level of abstraction.)
What else were you suggesting -- just ignore the issue? The implicit assumption here is that we must write programs which can scale to multiple cores, because single cores are running into the limitations of physics.
Sounds like a case designed for Erlang.
Erlang makes multithreading on the same machine easy, using a message-passing model. If you need to connect to a remote machine, you can do that pretty much as easily. It would work well on a Beowulf cluster.
I'm not sure how well it would work on a "single-image cluster farm", but I don't see why it would be any harder to create multiple Erlang processes on the same "machine" and have them pretend to be remote.
That is one of many, many things I find wrong with Erlang, although I would suggest that a good book on Erlang will help a lot. Erlang isn't purely functional, and it is actually pretty easy to pick up.
But Erlang also has horrible syntax, not particularly good Unicode support, and all the other problems you'd expect from a language that isn't popular. I'd much rather steal Erlang's message-passing and use it in another language.
And message-passing really is a good deal more intuitive than locks, semaphores, and all the other threading things. Threading is hard. Doing it shared-nothing, as processes, is much easier.
The main problem I have with Java threads, vs Erlang, is that Java threads are still using locks. They're locks with nice syntactic sugar on them, but locks nonetheless.