We've gotten cocky nowadays, but back then, what with bad torpedoes, ossified admirals who didn't want to use that "newfangled" radar, planes that couldn't keep up with the Mitsubishi Zero, it was anything but a guaranteed thing.
Can't emphasise this part enough. If you know nothing else about WWII in the Pacific, a person should really acquaint themselves with the Battle of Midway.
We had some advantages, and some disadvantages. But without incredible sheer luck, and the willing essentially suicidal sacrifices of the men of Torpedo Squadron 8, things would have turned out completely differently. If the same strokes of luck had happened for the Japanese instead of for the US, the balance of our entire carrier force would have been wiped out (which was what the Japanese plan was when they forced that action in the first place). Had that happened, at best it would have been years before we could have built enough replacements to make it a war again.
BTW: Of Torpedo Squadron 8, only one man (and none of the planes) survived their runs. Their planes were hopelessly obsolete, and scored no hits on either their carrier targets or enemy planes. However, their pitiful attacks drew the air cover down at just the moment other squadrons of US dive-bombers arrived on the scene from high altitude, and oddly found the skies up there uncontested...
The penchant of the Imperial Japanese Forces for mass slaughter was not just propaganda.
No, it was most certainly not. I follow a WWII twitter feed (@RealTimeWWII). They sent one last week talking about the Japanese airdropping food into Chengde full of plague-infected lice.
Now this is the kind of thing that is so cartoonishly evil that I immediately hit Google looking to debunk it. Nope, it happened (note: that link is the human-rights equivalent of a goatse link. Don't click it lightly). In fact, they did a great deal of research into weaponing diseases before discovering that infected lice survived being dropped from altitude better than free diseases do. Then they used it. Over half a million people died.
He actually is a celebrity, known amongst geeks for his character on Star Trek: The Next Generation.
In addition, back in the late 70's he also played the most famous and pivotal character (Kunta-Kinte) in the most watched TV series ever (Roots). His face is the large centerpiece on the cover of the DVD.
He was also the host of Reading Rainbow, probably the last great PBS educational kids show, before cable destroyed the concept with Nick and Cartoon Network.
Perhaps the GP never heard of the guy because he is young, or never watched a lot of TV. But in either case I fail to see why him not knowing a famous person should be shocking enough to report it to the world, or us to care.
The general gist is that UDP and TCP both have kind of an ideal mileu. UDP is great for small packets that you want delivered with a minimum of overhead, and if the packet is late, lost, or out of order, it won't kill anything.
TCP is great if you are sending large amounts of data at once, between a pair of systems, and in situations where its important not to lose packets or get them out of order, and you don't care that much if this takes a little extra time (occasionally perhaps a lot of extra time) to accomplish. Also good in situations where you'd like to know when your partner on the other side goes away for some reason.
Most applications are going to be in-between somewhere, so you have to make a decision. For example, if your packets are small and need to be delivered quickly, but you also need reliability, you might go with TCP just to get that reliability. Alternatively, if you can get away with it, you might instead go with UDP, but use dedicated links between the systems and a handshaking protocol at your application layer to prevent collisions.
Alternatively, you might do what Google is doing, and try to reimplement TCP's reliability in your application layer on top of UDP. The thing about UDP is that you can always reimplement any parts of TCP you need on top of it.
Verhoven films usually are a social commentary embedded in a nice action flick - so you can enjoy it as a pure action movie, or analyze it for the subtext. Robocop is another one commenting about society and policing. And oddly, it seems we're definitely headed towards the world Robocop was set in. Only took nearly 30 years.
No way. For instance, remember the scene in Robocop when the company executive took over the city of Detroit from the elected (black) mayor, with the mayor protesting futilely that this was completely undemocratic? That's completely ridiculous.
The Bugs are not a threat to humans. They defend themselves. They have no space flight capability. They have no means of attacking Earth. They are a manufactured threat.
OK. I'll admit to having watched the movie only once, in theaters. So my memory's a bit shaky on some points.
However, the way I remember it, during the movie the main character's home town got leveled by an attack from the "bugs" (presumably they were throwing meteors into earth's path or something?). Also, the planet where most of the action took place was in fact not the "bugs" native world, but rather some other planet they had invaded. Am I misremembering?
Those who do not serve have nearly all the rights of those who do not: the main two rights they don't get are the right to serve in law enforcement or the federal government, and the right to vote.
...which is where you know we are talking science fiction. In the real world, people who do not have the right to vote will very quickly be divested of any other rights they may have. There's a reason most of the activity around the Civil Rights movement of the 50's and 60's (pro and con) was centered around reestablishing voting rights.
In fact, without some kind of extra protection, even some groups of actual voters will lose rights if they are in a big enough minority. For example, in the '80s the rest of the electorate ganged up on US voters aged 18-20 and took away their right to drink.
You mean the party that kept sending bills to the senate...
...without making any attempt whatsoever to make those bills something that could pass in said senate?
Yeah, them.
Note that the Senate during this time also sent a bill to the house. By all accounts, it was a bill that would have passed in the house with flying colors, and the POTUS would have signed. It would also have represented a tremendous victory for Republicans, cutting food stamps by 4 billion dollars, and all sorts of other assorted (IHMO evil) cuts to the poor that Republicans were wanting. In the Bush era a Republican house would have jumped right on this.
The house's Republican leadership wouldn't bring it up for a vote. In fact, they changed their own rules specifically to prevent anyone from being able to bring this passable bill up on the House floor. Why not take a big legislative victory? Because the Republicans in the House don't care about legislative victories. They wanted to shut the government down. Simple as that.
Interesting. Do you consider successful poker bluffers "cheaters" as well? They operate on information gleaned from opposing physical "tells" too.
I'd thing it would be very interesting to play a few rounds with this robot. I bet with a bit of work any reasonably competent human will be able to fool it to make it lose every time. When it comes to "cheating", its tough to beat a human being.:-)
It's not a contract either, as the developer doesn't sign anything in advance agreeing to do work.
Its more like a bounty. "$100 for the head of the GUI bug that is ruining my day". Why they didn't go with that for a theme is beyond me. Boba Fett is far cooler as a model than some corrupt school board official.
This could be the difference between an hour and 10 minutes for builds of some projects.
If that's really the delta (one is 600% slower), then something is likely seriously pathologically wrong with one of those two compilers. Submit a bug report (not that it helps you, but it will help someone else).
But yes, different users in different phases will have different priorities. I'm not laying down an immutable law here, just trying to restore the proper proportion to a situation that we both agree is way out of wack.
OK. Much abashed, I went back through the article.
It turns out that there are numbers for an actual code benchmark. Its found about 2/3rds of the way through the report, in the third graph (untitled), after the balance of the text had already been devoted to compilation speed comparisons. Also, it only listed 2 of the 3 compilers, half the data was for unoptimized code (and thus useless), and it was hidden behind a sign that said "Beware of leopard".
OK, perhaps I made that last part up.
For the curious, the difference in at least that one table was never more than 5%. In my mind, hardly a differentiator unless you are doing heavy number crunching or stock trading programs.
Perhaps the remaining 1/3rd is all about more important things? I've lost interest. You're right. I'm weak.
First off, why wasn't Microsoft's C++ compiler included in this? That's the one we use at work, so that's the one I'd really like compared to all those others. Are we the only ones still using it or something?
More importantly, why on earth was compilation speed the only thing compared? I mean, I suppose its nice for g++ users to know that their 10 minute compiles would have been 2 minutes longer if they used the Intel compiler, but Intel users might not really care if they believe their resulting code is going to run faster. Speed of compilation of optimized code is a particularly useless metric, because different compilers have different definitions of "unoptimized", so its guaranteed you aren't comparing apples to apples.
I suppose compilation speed is a nice metric to brag about between compiler writers. But for compiler users, the most important things are roughly these, in order: Toolchain support, language feature support (eg: C++2012/14 features), clarity of error/warning messages, speed of generated code (optimization), and lastly speed of compilation. I'm not really sure why you took it upon yourself to measure the least important factor, and only that one.
C is a more accurate model of the machine, and nothing but the machine.
...
Denying that C is the best portable language we have to model the behaviors of the underlying hardware, is why
I can tell from this you've never implemented an actual compiler, and have probably never used any other system's programming language. The amateurish attempt to model low-level stuff like register allocations, incrementing, and CPU addressing modes is C's biggest problem as a language. It actively hampers optimization while simultaneously making programs harder to write properly, to understand, and debug. To make matters even worse, the language doesn't allow you to fully specify memory layout for its objects. For example, in Ada you can portably specify the exact size, location, and layout of every field in a record type. In C that simply cannot be done portably. So if suitability for the task of low-level programming were the criteria, while Lisp would probably not be the language of choice, C most certainly would not.
C succeeded over competitors like the Wirth languages and Ada back in the early 80's at first because compilers were easy to write, and later because of installed codebase. Other than stuff that made the first compilers easy to write in the '70's, C has succeeded in spite of its design, not because of it.
That is precisely why. A person should have some sense of style. I don't wear T-Shirts at work (reason supplied in a previous posting), but rather proper work clothes. So without some kind of flair, my visual effect is "yet another forgettable bland white guy."
The problem with C compilers that remove unstable code is that nearly every C program fed into it gets optimized down to hello_world. These new C compilers can just spit out a warning: "Your program is unsafe", and go on their merry way now. Actually having the compiler perform a check to verify that this is the case removes the 0.5% false positives, but most will find the extra compilation time not worth that.
I'm eggagerating of course. Hello_world is horribly unsafe too, because it uses printf.
Look into that a bit, and you may discover that the start of work on that website was delayed for years by lawsuits from Republican governeors. Problems with the new compressed schedule were noted during development, but any solution that required an act of Congress (eg: adjusting the deadline, the requirements, or adding money so more developers could be hired) was right out, as the Republican-led Congress would only vote to defund the entire effort altogether.
So yes, anything ACA-related that Republicans had a say in has turned to a complete fiasco, just like the Republicans wanted. Party affiliation had everything to do with it.
Well, in the spirt of messages from your elders...
Yes, most young people these days don't wear watches. This is unfortunate, as watches were one of the few socially-acceptible pieces of jewelry for men. This was cheifly due to their functional utility, but many high-end watches are so stylish they are well-nigh unfunctional for telling time in all but the most general way.
My dad has taken to wearing bracelets (really so big they are practically bracers). As someone with clear native american blood in Oklahoma he can get away with that, but my lily-white self can't really pull that off. So I keep wearing watches, even though they are barely more functional in this day and age than the watches with unreadable faces.
So yes, anything that can make my decorative wrist "watch" a functional item again has me pretty excited. That and senior discounts. Don't judge.
I can't speak for Pebble, but any Bluetooth device is going to require a fair bit more power than that. Even Bluetooth low energy uses up to 10mW during transmission.
I honestly don't see anything horribly wrong with this. I have one master device which I carry in my pocket or backpack or whatever, and one convienent small remote on my wrist capable of doing some of the more common and simple tasks with it (eg: caller ID, fiddle with my music, check the time, etc), but I still have the larger device I can dig out if I want to do something more complex.
Perhaps I lack vision here, but I can't see the watch ever replacing the phone. There's too much I need the larger form factor for. I could however see where your typical "phone" form factor might not be the ideal under this setup. Its a bit small for web-surfing. Perhaps in the future we will just have watches, tablets, and bluetooth headsets?
Slashdot Mirror
Actually, judging by the ads I see over the urinals, Friday Night is mostly sponsored by bail bondsmen.
We've gotten cocky nowadays, but back then, what with bad torpedoes, ossified admirals who didn't want to use that "newfangled" radar, planes that couldn't keep up with the Mitsubishi Zero, it was anything but a guaranteed thing.
Can't emphasise this part enough. If you know nothing else about WWII in the Pacific, a person should really acquaint themselves with the Battle of Midway.
We had some advantages, and some disadvantages. But without incredible sheer luck, and the willing essentially suicidal sacrifices of the men of Torpedo Squadron 8, things would have turned out completely differently. If the same strokes of luck had happened for the Japanese instead of for the US, the balance of our entire carrier force would have been wiped out (which was what the Japanese plan was when they forced that action in the first place). Had that happened, at best it would have been years before we could have built enough replacements to make it a war again.
BTW: Of Torpedo Squadron 8, only one man (and none of the planes) survived their runs. Their planes were hopelessly obsolete, and scored no hits on either their carrier targets or enemy planes. However, their pitiful attacks drew the air cover down at just the moment other squadrons of US dive-bombers arrived on the scene from high altitude, and oddly found the skies up there uncontested...
The penchant of the Imperial Japanese Forces for mass slaughter was not just propaganda.
No, it was most certainly not. I follow a WWII twitter feed (@RealTimeWWII). They sent one last week talking about the Japanese airdropping food into Chengde full of plague-infected lice.
Now this is the kind of thing that is so cartoonishly evil that I immediately hit Google looking to debunk it. Nope, it happened (note: that link is the human-rights equivalent of a goatse link. Don't click it lightly). In fact, they did a great deal of research into weaponing diseases before discovering that infected lice survived being dropped from altitude better than free diseases do. Then they used it. Over half a million people died.
He actually is a celebrity, known amongst geeks for his character on Star Trek: The Next Generation.
In addition, back in the late 70's he also played the most famous and pivotal character (Kunta-Kinte) in the most watched TV series ever (Roots). His face is the large centerpiece on the cover of the DVD.
He was also the host of Reading Rainbow, probably the last great PBS educational kids show, before cable destroyed the concept with Nick and Cartoon Network. Perhaps the GP never heard of the guy because he is young, or never watched a lot of TV. But in either case I fail to see why him not knowing a famous person should be shocking enough to report it to the world, or us to care.
The general gist is that UDP and TCP both have kind of an ideal mileu. UDP is great for small packets that you want delivered with a minimum of overhead, and if the packet is late, lost, or out of order, it won't kill anything.
TCP is great if you are sending large amounts of data at once, between a pair of systems, and in situations where its important not to lose packets or get them out of order, and you don't care that much if this takes a little extra time (occasionally perhaps a lot of extra time) to accomplish. Also good in situations where you'd like to know when your partner on the other side goes away for some reason.
Most applications are going to be in-between somewhere, so you have to make a decision. For example, if your packets are small and need to be delivered quickly, but you also need reliability, you might go with TCP just to get that reliability. Alternatively, if you can get away with it, you might instead go with UDP, but use dedicated links between the systems and a handshaking protocol at your application layer to prevent collisions.
Alternatively, you might do what Google is doing, and try to reimplement TCP's reliability in your application layer on top of UDP. The thing about UDP is that you can always reimplement any parts of TCP you need on top of it.
They are trying to dance in too many rodeos, and it's starting to show.
I've been to quite a few rodeos in my day, and I can't remember any dancing in any of them. In fact, I'd say dancing in any rodeo is too many.
Verhoven films usually are a social commentary embedded in a nice action flick - so you can enjoy it as a pure action movie, or analyze it for the subtext. Robocop is another one commenting about society and policing. And oddly, it seems we're definitely headed towards the world Robocop was set in. Only took nearly 30 years.
No way. For instance, remember the scene in Robocop when the company executive took over the city of Detroit from the elected (black) mayor, with the mayor protesting futilely that this was completely undemocratic? That's completely ridiculous.
The Bugs are not a threat to humans. They defend themselves. They have no space flight capability. They have no means of attacking Earth. They are a manufactured threat.
OK. I'll admit to having watched the movie only once, in theaters. So my memory's a bit shaky on some points.
However, the way I remember it, during the movie the main character's home town got leveled by an attack from the "bugs" (presumably they were throwing meteors into earth's path or something?). Also, the planet where most of the action took place was in fact not the "bugs" native world, but rather some other planet they had invaded. Am I misremembering?
Those who do not serve have nearly all the rights of those who do not: the main two rights they don't get are the right to serve in law enforcement or the federal government, and the right to vote.
...which is where you know we are talking science fiction. In the real world, people who do not have the right to vote will very quickly be divested of any other rights they may have. There's a reason most of the activity around the Civil Rights movement of the 50's and 60's (pro and con) was centered around reestablishing voting rights.
In fact, without some kind of extra protection, even some groups of actual voters will lose rights if they are in a big enough minority. For example, in the '80s the rest of the electorate ganged up on US voters aged 18-20 and took away their right to drink.
You mean the party that kept sending bills to the senate ...
...without making any attempt whatsoever to make those bills something that could pass in said senate?
Yeah, them.
Note that the Senate during this time also sent a bill to the house. By all accounts, it was a bill that would have passed in the house with flying colors, and the POTUS would have signed. It would also have represented a tremendous victory for Republicans, cutting food stamps by 4 billion dollars, and all sorts of other assorted (IHMO evil) cuts to the poor that Republicans were wanting. In the Bush era a Republican house would have jumped right on this.
The house's Republican leadership wouldn't bring it up for a vote. In fact, they changed their own rules specifically to prevent anyone from being able to bring this passable bill up on the House floor. Why not take a big legislative victory? Because the Republicans in the House don't care about legislative victories. They wanted to shut the government down. Simple as that.
So how long does it take to teach the robots not to stab humans, and how many lab technicians do they go through in the meantime?
Interesting. Do you consider successful poker bluffers "cheaters" as well? They operate on information gleaned from opposing physical "tells" too.
I'd thing it would be very interesting to play a few rounds with this robot. I bet with a bit of work any reasonably competent human will be able to fool it to make it lose every time. When it comes to "cheating", its tough to beat a human being. :-)
Well, we know where the funding came from now.
"Funny how the guy with the moveable prosthetic hand seems to win every round..."
It's not a contract either, as the developer doesn't sign anything in advance agreeing to do work.
Its more like a bounty. "$100 for the head of the GUI bug that is ruining my day". Why they didn't go with that for a theme is beyond me. Boba Fett is far cooler as a model than some corrupt school board official.
This could be the difference between an hour and 10 minutes for builds of some projects.
If that's really the delta (one is 600% slower), then something is likely seriously pathologically wrong with one of those two compilers. Submit a bug report (not that it helps you, but it will help someone else).
But yes, different users in different phases will have different priorities. I'm not laying down an immutable law here, just trying to restore the proper proportion to a situation that we both agree is way out of wack.
OK. Much abashed, I went back through the article.
It turns out that there are numbers for an actual code benchmark. Its found about 2/3rds of the way through the report, in the third graph (untitled), after the balance of the text had already been devoted to compilation speed comparisons. Also, it only listed 2 of the 3 compilers, half the data was for unoptimized code (and thus useless), and it was hidden behind a sign that said "Beware of leopard".
OK, perhaps I made that last part up.
For the curious, the difference in at least that one table was never more than 5%. In my mind, hardly a differentiator unless you are doing heavy number crunching or stock trading programs.
Perhaps the remaining 1/3rd is all about more important things? I've lost interest. You're right. I'm weak.
Interesting info, but I have a couple of issues:
First off, why wasn't Microsoft's C++ compiler included in this? That's the one we use at work, so that's the one I'd really like compared to all those others. Are we the only ones still using it or something?
More importantly, why on earth was compilation speed the only thing compared? I mean, I suppose its nice for g++ users to know that their 10 minute compiles would have been 2 minutes longer if they used the Intel compiler, but Intel users might not really care if they believe their resulting code is going to run faster. Speed of compilation of optimized code is a particularly useless metric, because different compilers have different definitions of "unoptimized", so its guaranteed you aren't comparing apples to apples.
I suppose compilation speed is a nice metric to brag about between compiler writers. But for compiler users, the most important things are roughly these, in order: Toolchain support, language feature support (eg: C++2012/14 features), clarity of error/warning messages, speed of generated code (optimization), and lastly speed of compilation. I'm not really sure why you took it upon yourself to measure the least important factor, and only that one.
C is a more accurate model of the machine, and nothing but the machine.
...
Denying that C is the best portable language we have to model the behaviors of the underlying hardware, is why
I can tell from this you've never implemented an actual compiler, and have probably never used any other system's programming language. The amateurish attempt to model low-level stuff like register allocations, incrementing, and CPU addressing modes is C's biggest problem as a language. It actively hampers optimization while simultaneously making programs harder to write properly, to understand, and debug. To make matters even worse, the language doesn't allow you to fully specify memory layout for its objects. For example, in Ada you can portably specify the exact size, location, and layout of every field in a record type. In C that simply cannot be done portably. So if suitability for the task of low-level programming were the criteria, while Lisp would probably not be the language of choice, C most certainly would not.
C succeeded over competitors like the Wirth languages and Ada back in the early 80's at first because compilers were easy to write, and later because of installed codebase. Other than stuff that made the first compilers easy to write in the '70's, C has succeeded in spite of its design, not because of it.
That is precisely why. A person should have some sense of style. I don't wear T-Shirts at work (reason supplied in a previous posting), but rather proper work clothes. So without some kind of flair, my visual effect is "yet another forgettable bland white guy."
So he hasn't even been arrested yet, and his punishement has already started?
The problem with C compilers that remove unstable code is that nearly every C program fed into it gets optimized down to hello_world. These new C compilers can just spit out a warning: "Your program is unsafe", and go on their merry way now. Actually having the compiler perform a check to verify that this is the case removes the 0.5% false positives, but most will find the extra compilation time not worth that.
I'm eggagerating of course. Hello_world is horribly unsafe too, because it uses printf.
Look into that a bit, and you may discover that the start of work on that website was delayed for years by lawsuits from Republican governeors. Problems with the new compressed schedule were noted during development, but any solution that required an act of Congress (eg: adjusting the deadline, the requirements, or adding money so more developers could be hired) was right out, as the Republican-led Congress would only vote to defund the entire effort altogether.
So yes, anything ACA-related that Republicans had a say in has turned to a complete fiasco, just like the Republicans wanted. Party affiliation had everything to do with it.
Well, in the spirt of messages from your elders...
Yes, most young people these days don't wear watches. This is unfortunate, as watches were one of the few socially-acceptible pieces of jewelry for men. This was cheifly due to their functional utility, but many high-end watches are so stylish they are well-nigh unfunctional for telling time in all but the most general way.
My dad has taken to wearing bracelets (really so big they are practically bracers). As someone with clear native american blood in Oklahoma he can get away with that, but my lily-white self can't really pull that off. So I keep wearing watches, even though they are barely more functional in this day and age than the watches with unreadable faces.
So yes, anything that can make my decorative wrist "watch" a functional item again has me pretty excited. That and senior discounts. Don't judge.
I can't speak for Pebble, but any Bluetooth device is going to require a fair bit more power than that. Even Bluetooth low energy uses up to 10mW during transmission.
I honestly don't see anything horribly wrong with this. I have one master device which I carry in my pocket or backpack or whatever, and one convienent small remote on my wrist capable of doing some of the more common and simple tasks with it (eg: caller ID, fiddle with my music, check the time, etc), but I still have the larger device I can dig out if I want to do something more complex.
Perhaps I lack vision here, but I can't see the watch ever replacing the phone. There's too much I need the larger form factor for. I could however see where your typical "phone" form factor might not be the ideal under this setup. Its a bit small for web-surfing. Perhaps in the future we will just have watches, tablets, and bluetooth headsets?