99 percent of any and all past and present attacks against airline travel perpetrated - through passengers or baggage! - were committed by people who a) claimed they were doing it for Islam and b) who have declared as being of Muslim faith.
Even if the above statement were true...
Therefore, it is not only logical to exclude non-Muslims from security checks but beneficial, as it wastes less resources and security staff to search improbable suspects.
The above conclusion would be terribly short-sighted. Assuming that only Muslims need to be checked as potential terrorists is like holding up a giant "BOMB HERE" sign to the next Timothy McVeigh or Aum Shinrikyo.
In short, just because a condition is true today doesn't mean it will be true tomorrow. Especially if you start cutting corners in such a way that makes it very easy for non-muslim terrorists to, well, terrorize.
Then it goes on to say "meaning the 20 batteries are capable of delivering roughly one megawatt of electricity almost instantaneously" WTF does that mean?
It seems pretty obvious to me... it means that the output of those batteries is available at a moment's notice, i.e. as soon as the operator presses the "gimme battery power" button. Compare that with, say, a natural gas turbine that might need 20 minutes to spin up to full power.
Neat. There's some similarity to Matlab, and some to Renderman, and some of the syntax is borrowed from Haskell.
Sure, but the real fun is trying to find the cleverly concealed back door so that will allow the NSA to trivially bypass any "secure" algorithm you develop. Don't look for it in the reference implementation, as that would be too obvious and easy to work around. No, it will be somewhere in the language specification itself...
I wouldn't want to be the unfortunate bird or jetliner that happens to wander into the path of such a concentrated beam of radiation,
Two easy solutions to that: either put the beam in a 'no fly zone' so that jetliners won't be in the area (sorry birds!), or just don't make the beam concentrated. I don't think there is any reason why the energy couldn't be collected over a fairly large area.
This is not a good thing: by definition x86 code is not portable across platforms.
Sure it is... x86 byte code is a byte code like any other.... bytes are bytes. That's why programs like VirtualPC are able to run Windows executables on PowerPC-based Macs.
Of course, you might be able to get higher efficiency on an x86-based host due to the similarity between this bytecode and its hardware instruction set... but that's just a convenient detail;^)
they blockify the contents of their case statements
Agreed that it's not always necessary to do that, but then again it sometimes is... i.e. when you are declaring class objects on the stack in your case statements. If you don't, you get an error like this:
test.cpp: In function 'int main(int, char**)': test.cpp:17: error: jump to case label test.cpp:14: error: crosses initialization of 'A a'
Given that, I can see why some people would just put in the braces all the time, to avoid having to deal with the problem.
put a break after the last statement in a switch
That's actually a very wise thing to do, as a defense against the time in the future when some bozo adds another case to the end of the switch statement, and forgets to add a break statement above it. Voila, he's accidentally created an unintended fall-through condition where two cases get executed instead of just one... and a hard-to-find logic error that will be a bitch to debug. Better to just put in the (harmless) extra break statement up front and save debugging time later.
Can you think of even one situation where forgetting a semicolon would still result in code that compiles? I wouldn't be completely surprised if there is, but I can't think of one, and if it exists it's an edge thing.
Well, since you asked... here's one that has bit me once or twice:
int x= 10; while(DecrementAndReturnValue(&x) > 0) ; printf("All done!\n");
Okay, that example is a bit contrived... but the point is, if you forget the semicolon in line 2, the code will compile and do the wrong thing. (specifically, it will print "All done!" ten times instead of just once at the end)
Moral of the story: do it this way instead, to avoid any chance of trouble:
The problem with C++ is that it's a crazy, crazy language. At first, it was just a superset of C, but now there's all kinds of stuff...it's mutated into a totally different kind of thing. C has this elegant simplicity going for it. There's nothing the matter with C++...except that C is (pretty much) perfect.
That's all true... but I think you're missing something: all of that crazy stuff was added to C++ because it is useful. Of course, any given program will probably only need a small subset of those features, but for the programs that really do need feature X, having it available in the language is a big time-saver.
I've done a good amount of both C and C++ programming, and these days when I need to write in C I generally end up writing a fair amount of code to manually re-implement functionality that I would get 'for free' in C++.
I'd say C++ is a lot like English: a big, overgrown, complicated, mess -- and damn useful if you want to get things done. (If you care more about elegance and simplicity, there is always Esperanto, for whatever good that does you)
I think I might like Obj-C over C++, due solely to the really nice init/release/autorelease mech for memory allocation.
I've done just a bit of Obj-C programming, and I didn't see much advantage of init/release/autorelease over plain old C malloc()/free(). What I mean is, under C, I have to remember to free() each object that I malloc(). Under Obj-C, OTOH, I have to remember to [release] each object that I alloc (or retain). In either case I need to remember to explicitly execute a cleanup/release action to match the allocate/retain action, and if I don't get it right, the object is (effectively) leaked. That means I have to manually check every code-path to ensure that each of my ref-count-incrementing actions is matched by exactly one ref-count-decrementing action, which is tedious and error-prone. It's actually even worse than that, as Objective C has several different conventions regarding how system APIs handle ref-counts... some of them will have ref-counted the objects they return and expect you to [release] the objects when you're done with them, others don't... so it's quite easy to do the wrong thing.
Compare that to C++, where I can (and do) use templates to create a reference-counting system that automatically frees objects at the appropriate time, and no explicit calls to free()/release()/decrement_ref_count()/whatever-you-want-to-call-it() necessary, ever:
void FooBar() { MyClassRef myRef(new MyClass);// MyClassRef constructor increments the new object's refcount to 1 MyClassRef anotherRef(myRef);// MyClassRef copy constructor increments the object's refcount to 2 /* anotherRef's destructor executes here, decrements the object's refcount to 1 */ /* myRef's destructor executes here, decrements the object's refcount to 0, and so the object is auto-deleted */ }
With that system, there is almost no way for me to mess things up(*). I don't have to remember explicitly to call any sort of (release) or (dealloc) function for each object I create, because it is guaranteed to be called for me by the destructor of the last Ref object.
So I must be missing some key insight about Objective C's memory management system, because even with reference counting it seems almost as error-prone as C's manual memory management.
(*) One way to still mess things up would be to create cyclic references, i.e. A refs B and B refs A. But that's a problem for any reference-counting scheme, and the solution is either to avoid cyclic references or go with a full-blown garbage collector.... and I've yet to find that I need to do the latter.
If all cars operated today were electric, and charged at night when there is less demand, there would still not be enough generation and transmission capacity to power them all.
Possibly true, but definitely irrelevant. You might as well say "if everybody in the US went out for ice cream tonight, there wouldn't be enough ice cream in the stores to feed them all". That's also possibly true, but since that's not going to happen either, it doesn't matter.
What will happen is that as demand for electricity to recharge automobiles gradually increases, supply will increase with it. Same as it ever was.
An idle computer has no reason to remove things from RAM, as there's nothing it needs the space for.
The thing is, it probably wasn't idle for 18 hours. It probably did a disk index or something in the middle of the night, which had the side effect of paging out all of the user's GUI data and replacing it with cached disk data. That would explain why the GUI stuff gets paged back in when he sits down to use the machine.
I suppose a really clever OS might note what times of day its user usually resumes using it, and could then for a re-page-in of all the user's data a few minutes before then....
Re:I don't know why this story's flagged "endofday
on
Python 3.0 Released
·
· Score: 1
Python 3000 is released - December 4, 2008
991 years ahead of schedule, no less. Take that, Microsoft!
That's a DDoS, and would kick your one-man-and-a-dog site off the net. For a while, at least. And there would be nothing you could do about it.
Well, not nothing... you could always keep copies of your web site available on various hosts around the Internet, and when one of them gets DDOS'd, start serving from another one.
But how to set up a large number of mirroring servers for free? Your best bet is to use a botnet to do it...
Also I get nauseous when I try to use a CRT screen running in less than 85 hz. People are indeed adapting.
Perhaps, but I'm not sure what is 'adaptive' about getting nauseous... a better adaptation would be one that lets you use CRTs of any frame rate (high or low) without problems. Perhaps people are just becoming fussier?
I did not say there were no middle roads. Merely that greenies will never accept them.
I'm a greenie, and I accept them, so that's clearly untrue. Or perhaps your definition of "greenie" is "anyone who doesn't accept them"? In that case your argument is tautological and pointless.
Nuclear power expansion is the ideal middle road today after all. Barely needs any space. Lots of power. Cheap. Fuel many times recyclable. 1 kg fuel powers new york for a year. Few, tiny mines... what else could you ask for ?
Well... I could ask for a power source that isn't so easily weaponizable, one that we would be happy to share even with, say, Iran. I could ask for one whose infrastructure doesn't present an opportunity for theft of radioactive materials that could then be made into terrorist devices, held for ransom, etc. I could ask for one that isn't dependent on a finite fuel supply that has to be dug out of the ground in potentially unfriendly areas. I could ask for one that doesn't generate any hazardous waste. I could ask for one whose power plants don't form giant centralized targets for terrorists.
I'm not saying that nuclear isn't an option, just that it isn't the be-all and end-all of power technologies.
So not only are you bragging with your confederation's legislation
Was he bragging, or merely stating a fact? Your assumption of the former suggests a certain defensiveness about our country's wise and glorious IP law...;^)
The only way to live green is to lay down and die, after having demolished the last city and killed the last human being.
I call sophistry... you're using the fallacy of the excluded middle, not to mention constructing a hell of a straw man. In reality, there are a spectrum of option between the two extremes ("humanity commits suicide" and "humanity does nothing to avoid damaging the environment", but you choose to ignore them because your goal is to paint your political opponents as unreasonable.
Why not put down your political wanker's hat for a while, and put on your engineer's hat instead? Instead of coming up with ways to prove that nothing can be done, you could be coming up with constructive ways to solve the real problems we face.
They would be better off making robots look like 'droids' not people; as Wall-e and even Star Wars have shown, you can express emotion-equivalents without entering into the creepiness-zone of not-quite-human that you can get in some computer animation or clowns
Unless, of course, creeping people out is one of your goals. There are certainly entire industries devoted to that...
What about the animal? The poor thing will be the only one of its species in existence. No chance of reproduction (unless it's close enough to an elephant to mate), no herd to grow up in, no point to its life other than for us to ooh and aah over.
And yet would the mammoth's life experiences be any different from those of millions of other animals being kept as pets already? It would certainly have a much longer and healthier life than that of your average cow, chicken, or lab rat....
I think your sympathies are misplaced.
As for whether there would be a "point" to its life... it would be a significant scientific and technological milestone. That's more "point" than most domesticated animals have.
No, the reason Apple won't allow Flash on the iPhone is because it's garish, obnoxious, a battery-life-draining resource hog, and, the typical complaints from the Internet's battery of Apple-haters nonwithstanding, almost completely useless.
You realize you've just described 95% of the apps currently available on Apple's site, right?
No offense, but if you're having trouble installing postgresql and django/python on mac os x via macports, you're misunderstanding something...
That could be... or perhaps the OP encountered one or more bugs in the installation routines that you didn't encounter. It's not uncommon for an install to go smoothly on one system, and fail inexplicably on another for whatever stupid reason.
Slashdot Mirror
99 percent of any and all past and present attacks against airline travel perpetrated - through passengers or baggage! - were committed by people who a) claimed they were doing it for Islam and b) who have declared as being of Muslim faith.
Even if the above statement were true...
Therefore, it is not only logical to exclude non-Muslims from security checks but beneficial, as it wastes less resources and security staff to search improbable suspects.
The above conclusion would be terribly short-sighted. Assuming that only Muslims need to be checked as potential terrorists is like holding up a giant "BOMB HERE" sign to the next Timothy McVeigh or Aum Shinrikyo.
In short, just because a condition is true today doesn't mean it will be true tomorrow. Especially if you start cutting corners in such a way that makes it very easy for non-muslim terrorists to, well, terrorize.
Then it goes on to say "meaning the 20 batteries are capable of delivering roughly one megawatt of electricity almost instantaneously" WTF does that mean?
It seems pretty obvious to me... it means that the output of those batteries is available at a moment's notice, i.e. as soon as the operator presses the "gimme battery power" button. Compare that with, say, a natural gas turbine that might need 20 minutes to spin up to full power.
Neat. There's some similarity to Matlab, and some to Renderman, and some of the syntax is borrowed from Haskell.
Sure, but the real fun is trying to find the cleverly concealed back door so that will allow the NSA to trivially bypass any "secure" algorithm you develop. Don't look for it in the reference implementation, as that would be too obvious and easy to work around. No, it will be somewhere in the language specification itself...
(adjusts tinfoil hat)
It's not so hard to factor a 32-bit number with a 64-bit computer. It is very hard to efficiently factor a 2048-bit number with a 64-bit computer.
Hmm, that raises the question... has anyone tried to build a 2048-bit computer?
Sounds like it might be fun project for the right TLA with a multi-billion dollar budget...
I wouldn't want to be the unfortunate bird or jetliner that happens to wander into the path of such a concentrated beam of radiation,
Two easy solutions to that: either put the beam in a 'no fly zone' so that jetliners won't be in the area (sorry birds!), or just don't make the beam concentrated. I don't think there is any reason why the energy couldn't be collected over a fairly large area.
This is not a good thing: by definition x86 code is not portable across platforms.
Sure it is... x86 byte code is a byte code like any other.... bytes are bytes. That's why programs like VirtualPC are able to run Windows executables on PowerPC-based Macs.
Of course, you might be able to get higher efficiency on an x86-based host due to the similarity between this bytecode and its hardware instruction set... but that's just a convenient detail ;^)
they blockify the contents of their case statements
Agreed that it's not always necessary to do that, but then again it sometimes is... i.e. when you are declaring class objects on the stack in your case statements. If you don't, you get an error like this:
test.cpp: In function 'int main(int, char**)':
test.cpp:17: error: jump to case label
test.cpp:14: error: crosses initialization of 'A a'
Given that, I can see why some people would just put in the braces all the time, to avoid having to deal with the problem.
put a break after the last statement in a switch
That's actually a very wise thing to do, as a defense against the time in the future when some bozo adds another case to the end of the switch statement, and forgets to add a break statement above it. Voila, he's accidentally created an unintended fall-through condition where two cases get executed instead of just one... and a hard-to-find logic error that will be a bitch to debug. Better to just put in the (harmless) extra break statement up front and save debugging time later.
Can you think of even one situation where forgetting a semicolon would still result in code that compiles? I wouldn't be completely surprised if there is, but I can't think of one, and if it exists it's an edge thing.
Well, since you asked... here's one that has bit me once or twice:
int x= 10;
while(DecrementAndReturnValue(&x) > 0) ;
printf("All done!\n");
Okay, that example is a bit contrived... but the point is, if you forget the semicolon in line 2, the code will compile and do the wrong thing. (specifically, it will print "All done!" ten times instead of just once at the end)
Moral of the story: do it this way instead, to avoid any chance of trouble:
int x= 10;
while(PrintDecrementAndReturn(x) > 0) {/* empty */}
printf("All done!\n");
The problem with C++ is that it's a crazy, crazy language. At first, it was just a superset of C, but now there's all kinds of stuff...it's mutated into a totally different kind of thing. C has this elegant simplicity going for it. There's nothing the matter with C++...except that C is (pretty much) perfect.
That's all true... but I think you're missing something: all of that crazy stuff was added to C++ because it is useful. Of course, any given program will probably only need a small subset of those features, but for the programs that really do need feature X, having it available in the language is a big time-saver.
I've done a good amount of both C and C++ programming, and these days when I need to write in C I generally end up writing a fair amount of code to manually re-implement functionality that I would get 'for free' in C++.
I'd say C++ is a lot like English: a big, overgrown, complicated, mess -- and damn useful if you want to get things done. (If you care more about elegance and simplicity, there is always Esperanto, for whatever good that does you)
I think I might like Obj-C over C++, due solely to the really nice init/release/autorelease mech for memory allocation.
I've done just a bit of Obj-C programming, and I didn't see much advantage of init/release/autorelease over plain old C malloc()/free(). What I mean is, under C, I have to remember to free() each object that I malloc(). Under Obj-C, OTOH, I have to remember to [release] each object that I alloc (or retain). In either case I need to remember to explicitly execute a cleanup/release action to match the allocate/retain action, and if I don't get it right, the object is (effectively) leaked. That means I have to manually check every code-path to ensure that each of my ref-count-incrementing actions is matched by exactly one ref-count-decrementing action, which is tedious and error-prone. It's actually even worse than that, as Objective C has several different conventions regarding how system APIs handle ref-counts... some of them will have ref-counted the objects they return and expect you to [release] the objects when you're done with them, others don't... so it's quite easy to do the wrong thing.
Compare that to C++, where I can (and do) use templates to create a reference-counting system that automatically frees objects at the appropriate time, and no explicit calls to free()/release()/decrement_ref_count()/whatever-you-want-to-call-it() necessary, ever:
void FooBar() // MyClassRef constructor increments the new object's refcount to 1 // MyClassRef copy constructor increments the object's refcount to 2
/* anotherRef's destructor executes here, decrements the object's refcount to 1 */
/* myRef's destructor executes here, decrements the object's refcount to 0, and so the object is auto-deleted */
{
MyClassRef myRef(new MyClass);
MyClassRef anotherRef(myRef);
}
With that system, there is almost no way for me to mess things up(*). I don't have to remember explicitly to call any sort of (release) or (dealloc) function for each object I create, because it is guaranteed to be called for me by the destructor of the last Ref object.
So I must be missing some key insight about Objective C's memory management system, because even with reference counting it seems almost as error-prone as C's manual memory management.
(*) One way to still mess things up would be to create cyclic references, i.e. A refs B and B refs A. But that's a problem for any reference-counting scheme, and the solution is either to avoid cyclic references or go with a full-blown garbage collector.... and I've yet to find that I need to do the latter.
If all cars operated today were electric, and charged at night when there is less demand, there would still not be enough generation and transmission capacity to power them all.
Possibly true, but definitely irrelevant. You might as well say "if everybody in the US went out for ice cream tonight, there wouldn't be enough ice cream in the stores to feed them all". That's also possibly true, but since that's not going to happen either, it doesn't matter.
What will happen is that as demand for electricity to recharge automobiles gradually increases, supply will increase with it. Same as it ever was.
An idle computer has no reason to remove things from RAM, as there's nothing it needs the space for.
The thing is, it probably wasn't idle for 18 hours. It probably did a disk index or something in the middle of the night, which had the side effect of paging out all of the user's GUI data and replacing it with cached disk data. That would explain why the GUI stuff gets paged back in when he sits down to use the machine.
I suppose a really clever OS might note what times of day its user usually resumes using it, and could then for a re-page-in of all the user's data a few minutes before then....
Python 3000 is released - December 4, 2008
991 years ahead of schedule, no less. Take that, Microsoft!
That's a DDoS, and would kick your one-man-and-a-dog site off the net. For a while, at least. And there would be nothing you could do about it.
Well, not nothing... you could always keep copies of your web site available on various hosts around the Internet, and when one of them gets DDOS'd, start serving from another one.
But how to set up a large number of mirroring servers for free? Your best bet is to use a botnet to do it...
Also I get nauseous when I try to use a CRT screen running in less than 85 hz. People are indeed adapting.
Perhaps, but I'm not sure what is 'adaptive' about getting nauseous... a better adaptation would be one that lets you use CRTs of any frame rate (high or low) without problems. Perhaps people are just becoming fussier?
All you need is a handful of hunting rifles of polar bear hunting capability,
That would work, I suppose, but I'd prefer to let the pirates see Reason.
Spinning media already is dead. It's just that no one's told it yet.
Talk like that will have it spinning in its grave.
Seems pretty simple to me:
I did not say there were no middle roads. Merely that greenies will never accept them.
I'm a greenie, and I accept them, so that's clearly untrue. Or perhaps your definition of "greenie" is "anyone who doesn't accept them"? In that case your argument is tautological and pointless.
Nuclear power expansion is the ideal middle road today after all. Barely needs any space. Lots of power. Cheap. Fuel many times recyclable. 1 kg fuel powers new york for a year. Few, tiny mines ... what else could you ask for ?
Well... I could ask for a power source that isn't so easily weaponizable, one that we would be happy to share even with, say, Iran. I could ask for one whose infrastructure doesn't present an opportunity for theft of radioactive materials that could then be made into terrorist devices, held for ransom, etc. I could ask for one that isn't dependent on a finite fuel supply that has to be dug out of the ground in potentially unfriendly areas. I could ask for one that doesn't generate any hazardous waste. I could ask for one whose power plants don't form giant centralized targets for terrorists.
I'm not saying that nuclear isn't an option, just that it isn't the be-all and end-all of power technologies.
So not only are you bragging with your confederation's legislation
Was he bragging, or merely stating a fact? Your assumption of the former suggests a certain defensiveness about our country's wise and glorious IP law... ;^)
The only way to live green is to lay down and die, after having demolished the last city and killed the last human being.
I call sophistry... you're using the fallacy of the excluded middle, not to mention constructing a hell of a straw man. In reality, there are a spectrum of option between the two extremes ("humanity commits suicide" and "humanity does nothing to avoid damaging the environment", but you choose to ignore them because your goal is to paint your political opponents as unreasonable.
Why not put down your political wanker's hat for a while, and put on your engineer's hat instead? Instead of coming up with ways to prove that nothing can be done, you could be coming up with constructive ways to solve the real problems we face.
They would be better off making robots look like 'droids' not people; as Wall-e and even Star Wars have shown, you can express emotion-equivalents without entering into the creepiness-zone of not-quite-human that you can get in some computer animation or clowns
Unless, of course, creeping people out is one of your goals. There are certainly entire industries devoted to that...
What about the animal? The poor thing will be the only one of its species in existence. No chance of reproduction (unless it's close enough to an elephant to mate), no herd to grow up in, no point to its life other than for us to ooh and aah over.
And yet would the mammoth's life experiences be any different from those of millions of other animals being kept as pets already? It would certainly have a much longer and healthier life than that of your average cow, chicken, or lab rat....
I think your sympathies are misplaced.
As for whether there would be a "point" to its life... it would be a significant scientific and technological milestone. That's more "point" than most domesticated animals have.
No, the reason Apple won't allow Flash on the iPhone is because it's garish, obnoxious, a battery-life-draining resource hog, and, the typical complaints from the Internet's battery of Apple-haters nonwithstanding, almost completely useless.
You realize you've just described 95% of the apps currently available on Apple's site, right?
No offense, but if you're having trouble installing postgresql and django/python on mac os x via macports, you're misunderstanding something...
That could be... or perhaps the OP encountered one or more bugs in the installation routines that you didn't encounter. It's not uncommon for an install to go smoothly on one system, and fail inexplicably on another for whatever stupid reason.