Not to mention the difficulty of meaningfully defining "trustworthy" in this context...
Defining it from the customer standpoint alone is certainly feasible. Pet-names spring to mind among some other methodologies.
The problem is, if your goal is to shaft the customer in the first place, then well... You're trying to bridge a gap between opposites in a single definition.
"Oh. So I don't get to choose who I trust? Right. What are you calling 'trust' again?"
who have any claim to getting your ID from you for any reason other than an optional transaction are the police
Yep, that's who I was talking about.
just for the possibility of getting to tell someone who doesn't have that right to blow off.
You can get in a pretty complicated legal situation if you don't hand over ID you've got in your pocket. If you left it at home, things are a lot simpler.
Note: I'm not advocating being rude to cops. However, that doesn't make it ok to sit around and watch people's freedoms get trampled on either.
so tell me again, WHY it's ever a better idea NOT to have ID on your person??
Um... To aggravate people like you? Believe me, that has far more effect on my long-term health prospects than whether I get an immediate transfusion in some hypothetical scenario that'll never happen.
Note: Whenever I take my life in my hands by driving, I *do* bring ID. It also happens to be required by law...
Oh yeah good point. I was forgetting unpredictability. I must be having a really really dreary day.
I always said in philosophy class that free will is significant because no one can predict what I (or anyone else) will do... Kind of scary to think it has practical application.
Sheesh, I think the grandparent just proved electronic voting "can" be done securely.
Are you claiming you have a method in strait C for taking a float (that isn't dereferenced), treating it as in int (without casting), and avoiding the possibility of memory operations?
Sorry. You're right. We need a moderation titled "Well crafted Troll" so people will quit turning off their brain when they see a post marked "Troll".
Note: You answered your own question with that last line. This beautiful hack has about as much to do with Newton's Method as it does with C language structure. They're both in there, but they're really just scenery.
Then I'm afraid the whole article is going to be lost on you...
We've got a floating point being operated on as an integer. We've got a mysterious constant. We've got a two's complement sign-flip combined with a bit-shift.
The only thing missing from this party is hookers and beer.
and honestly I just think it's kind of crazy in general to leave your house without ID. It's hard for me to think of a reason NOT to always have it on me.
Um... *owning* an ID makes sense, and carrying it to the polls on election day doubly so. But having it all the time? Get real. Why should I need it? More to the point, I purposely don't carry ID when I don't need it just in case someone asks me for my papers. I'd like to truthfully be able to tell them just how hard to stuff it and where.
The structures were excited with an in-plane sinusoidal magnetic field resulting in a gyrotropic movement of the vortex core around the equilibrium position.
Translation: They made the suckers spin by applying AC current!
Ya, the big breakthrough appears to be that hitting the core with a very fast perpendicular field flips the needle about 300 times easier than hitting it with a very slow parallel field.
Guess these little "needles" are much easier to spin than to force through the substrate... Of course, I'm not really sure I understand how the whole "anti-vortex" explanation fits with the notion of spinning the assembly. That could be down to fitting the explanation into existing models in a strange way, or it could just be I don't understand it. (Knowing a couple physicists, and looking at the graphics, I'm guessing the original models might not account for perpendicular fields...)
If 7 million people want Wii's, and 7 million want PS3's (the number of xbox 360's so far sold) there will be 5.5 million unhappy Nintendo fans and 6.2 million unhappy PS3 fans this christmas.
Kinda sad when you think about it. If Nintendo and Sony were smart, they'd both poor all their advertising dollars into production for a while. No point in hyping something no one can buy.
Dinosaur marketing executives claim there is "no business model" in climbing out of the la brea tar pits.
Right. Let's see how long they survive without HDTV... Advertisers pay per eyeball, not depending on the medium. Getting enough eyeballs is up to the broadcaster. Presumably HDTV helps with that at some point.
Expecting advertisers to *pay extra* for HDTV commercials is a little like expecting customers to pay full price for copies they don't own... Oh wait I guess this'll fly after all. Hello DMCA and further regulation. Goodbye competition.
No one's hacked the PS3 or 360 to run Wii games. Even if they did, it'd be doubtful they'd run at full speed since emulation is quite a bit slower than native. Plus, it'd be illegal and violate the DMCA and all that jazz.
Finally, the Wii has a (potentially) superior input device. So even if you could provide full speed emulation of the Wii, you wouldn't get to use a Wiimote, which is likely going to ruin many of the games. If this new input device turns out to be nearly as big a revolution as the HDTV is to output, then Nintendo is going to be in a really really good market position very shortly.
Adding HDTV capability to the next Nintendo console (or possibly even the Wii itself) is going to be very easy. Competing with the Wiimote without violating any patents is going to be very hard.
Well.. in some sense routers are still "store and forward". They do have to store data from one link for a short time before sending data on to a next link. Ethernet cards can't broadcast all the time, they have to wait their turn.
Wouldn't this just be a bit like waiting a lot longer (say for hours or days instead of fractions of a second) before giving up on "best-effort" transfer across certain links? (I suppose you'd also want better dynamic routing, but that's something like a holy grail of networking in any case...)
I guess what I'm asking is: Are we still talking about a reliable transport layer on top of a lossy network layer, or are we now expecting to have a single lossless layer doing both network and transport? (Note: One layer sounds like a step backward given the history of network communications...)
The problem is, discarding extraneous packets is actually a VERY GOOD THING when it comes to the internet. Several store and forward systems pre-dated the current TCP/IP stack, but guess what. They weren't as efficient in terms of required hardware resources or latency. This is because in a store and forward network, certain problems (like network cards going nuts and spewing tons of garbage) can cause lots and lots of data to accumulate in the network, and then you have to wait for every single packet to move on before you get to the new and relevant data.
The OSI model and network researchers in general recognize that reliable transport facilities can easily be built on top of unreliable "best-effort" communication networks, whereas it's nigh impossible to create light-weight best-effort services on top of a store and forward network. Since both kinds of applications exist, those that need reliable transport, and those that need speed. It only makes sense to provide an underlying fast and light weight network which doesn't provide, and isn't expected to provide, 100% reliability.
Finally, in practice, it actually turns out to be rediculous to expect 100% reliability from anything, particularly a low-level networking scheme since in the real world, no network is 100% reliable. Life can get very interesting indeed when you're supposed to rely on 100% packet delivery and one of your packets never arrives.
The real problem IMO when dealing with wireless networks is that so many developers try to shoehorn existing land-line applications and methodologies into the wireless world. There's a big difference between a network with an avg latency of 80ms, standard deviation of 2ms and 0.3% packet loss compared to a network with an avg latency of 500ms, a non-standard deviation pattern ranging between 200ms and 6 seconds and 20% packet loss. And that's completely ignoring issues related to moving between coverage zones and maintaining proper routing.
Basically, TCP, FTP, and many of their friends can wind up being very bad deals in such an environment. And things get even *more* interesting when someone tries to "fix" the network to work well with them... (by, for instance, blocking up groups of packets and waiting for a certain data-size to accumulate before sending.)
I thought routing tables and what not meant you don't need to know the route from source to destination. (trunk servers are supposed to have links with weight costs etc etc, where packets take a non-ideal route when a line is down for example.) Of course, it's very true that in practice this is rarely the case. No one seems to build reliable networks these days.
Sure, doing it with 0% packet loss might be new, but how important is that when you've got TCP to handle that?
Further, when was the last time a set of teachers and students could agree on what constituted a good research statement?
This "research" appears to have gone looking to prove "students are tech idiots" and found exactly what it was looking for. Woohoo, nice job guys. Perhaps we should conduct a similar study on whether or not most researchers are idiots by grading them on how well they can solve real world problems... (Since these researchers apparently felt it was appropriate to judge the tech idiocy of students based on their research skills.)
Wow, revelation of the century, students are bad at research and communication. That's because those are hard things to teach and they're quite often glossed over. Even some "researchers" are bad at this stuff! Heck being crappy at it sometimes even earns you more money than being good at it. (Kind of like writing software...)
Just have creators cryptographically sign their creations with a private key. Then, keep track of all such signed originals in a database along with who created them and who owns them.
Such items could easily be monitored. If someone made a slightly modified copy, then the digital signature of the creator would be altered and the copy would be exposed as a rip-off. (It could say "made by Handsom Hal" if original or "made by Slimey Susan" if it was a fake for example.)
Anyone with a well known designer's signature on their items would have "costly originals" while anyone without a signature would have "cheap imposters". There could even be a new trade in officially certifying content with a certification agency that checks for similar items that appear to be rip-offs.
The problem is.... Put yourself in the shoes of party A and put AOL Time Warner in the shoes of party B.
Who's going to win that kind of lawsuit regardless of the merits of the case?
Then again... If you've got something you know you can prove isn't a violation, those are some pretty deep pockets to go after. Not sure why no-one has gone take-down fishing in court yet... Or more importantly why no lawyers are knocking down the doors of those who've been mis-treated by DMCA takedown notices.
Or, perhaps there are some serious gotchas in the part where the copyright holder becomes liable...
Ya, because his second question was about deadlocks.
How is a deadlocked thread going to "test for shouldRun and exit"? It's already stuck in some obscure call that someone used to think was safe for critical sections to execute...
Not to mention the difficulty of meaningfully defining "trustworthy" in this context...
Defining it from the customer standpoint alone is certainly feasible. Pet-names spring to mind among some other methodologies.
The problem is, if your goal is to shaft the customer in the first place, then well... You're trying to bridge a gap between opposites in a single definition.
"Oh. So I don't get to choose who I trust? Right. What are you calling 'trust' again?"
who have any claim to getting your ID from you for any reason other than an optional transaction are the police
Yep, that's who I was talking about.
just for the possibility of getting to tell someone who doesn't have that right to blow off.
You can get in a pretty complicated legal situation if you don't hand over ID you've got in your pocket. If you left it at home, things are a lot simpler.
Note: I'm not advocating being rude to cops. However, that doesn't make it ok to sit around and watch people's freedoms get trampled on either.
so tell me again, WHY it's ever a better idea NOT to have ID on your person??
Um... To aggravate people like you? Believe me, that has far more effect on my long-term health prospects than whether I get an immediate transfusion in some hypothetical scenario that'll never happen.
Note: Whenever I take my life in my hands by driving, I *do* bring ID. It also happens to be required by law...
Oh yeah good point. I was forgetting unpredictability. I must be having a really really dreary day.
I always said in philosophy class that free will is significant because no one can predict what I (or anyone else) will do... Kind of scary to think it has practical application.
Sheesh, I think the grandparent just proved electronic voting "can" be done securely.
Wait.
Are you claiming you have a method in strait C for taking a float (that isn't dereferenced), treating it as in int (without casting), and avoiding the possibility of memory operations?
If so, please share.
Sorry. You're right. We need a moderation titled "Well crafted Troll" so people will quit turning off their brain when they see a post marked "Troll".
Note: You answered your own question with that last line. This beautiful hack has about as much to do with Newton's Method as it does with C language structure. They're both in there, but they're really just scenery.
If this doesn't make your head swim:
int i = *(int*)&x;
i = 0x5f3759df - (i >> 1);
Then I'm afraid the whole article is going to be lost on you...
We've got a floating point being operated on as an integer.
We've got a mysterious constant.
We've got a two's complement sign-flip combined with a bit-shift.
The only thing missing from this party is hookers and beer.
Also... electronic voting is a far more complex, so the number of people who would recognize something fishy going on shrinks dramatically.
As to "one programmer" have you read Ken Thompson's thoughts on trusting trust? Okay. So maybe it's got to be a *smart* programmer. One guy can certainly do it.
and honestly I just think it's kind of crazy in general to leave your house without ID. It's hard for me to think of a reason NOT to always have it on me.
Um... *owning* an ID makes sense, and carrying it to the polls on election day doubly so. But having it all the time? Get real. Why should I need it? More to the point, I purposely don't carry ID when I don't need it just in case someone asks me for my papers. I'd like to truthfully be able to tell them just how hard to stuff it and where.
Who's to say that Joe, Jim and Jake Schmoe aren't both issued the same "code" while Sally Stockholder's vote is applied to 3 codes?
Note: I'm not saying secure computer-assisted voted is impossible. Just that nothing remotely close has been invented yet.
The structures were excited with an in-plane sinusoidal magnetic field resulting in a gyrotropic movement of the vortex core around the equilibrium position.
Translation: They made the suckers spin by applying AC current!
Wow, that's really eerie. I wonder if he just read this article.
Actually... I think they just rotated a field ninety degrees and tweaked out the pulse duration.
The best solutions are often the simple ones.
Ya, the big breakthrough appears to be that hitting the core with a very fast perpendicular field flips the needle about 300 times easier than hitting it with a very slow parallel field.
Guess these little "needles" are much easier to spin than to force through the substrate... Of course, I'm not really sure I understand how the whole "anti-vortex" explanation fits with the notion of spinning the assembly. That could be down to fitting the explanation into existing models in a strange way, or it could just be I don't understand it. (Knowing a couple physicists, and looking at the graphics, I'm guessing the original models might not account for perpendicular fields...)
If 7 million people want Wii's, and 7 million want PS3's (the number of xbox 360's so far sold) there will be 5.5 million unhappy Nintendo fans and 6.2 million unhappy PS3 fans this christmas.
Kinda sad when you think about it. If Nintendo and Sony were smart, they'd both poor all their advertising dollars into production for a while. No point in hyping something no one can buy.
Dinosaur marketing executives claim there is "no business model" in climbing out of the la brea tar pits.
Right. Let's see how long they survive without HDTV... Advertisers pay per eyeball, not depending on the medium. Getting enough eyeballs is up to the broadcaster. Presumably HDTV helps with that at some point.
Expecting advertisers to *pay extra* for HDTV commercials is a little like expecting customers to pay full price for copies they don't own... Oh wait I guess this'll fly after all. Hello DMCA and further regulation. Goodbye competition.
No one's hacked the PS3 or 360 to run Wii games. Even if they did, it'd be doubtful they'd run at full speed since emulation is quite a bit slower than native. Plus, it'd be illegal and violate the DMCA and all that jazz.
Finally, the Wii has a (potentially) superior input device. So even if you could provide full speed emulation of the Wii, you wouldn't get to use a Wiimote, which is likely going to ruin many of the games. If this new input device turns out to be nearly as big a revolution as the HDTV is to output, then Nintendo is going to be in a really really good market position very shortly.
Adding HDTV capability to the next Nintendo console (or possibly even the Wii itself) is going to be very easy. Competing with the Wiimote without violating any patents is going to be very hard.
Well.. in some sense routers are still "store and forward". They do have to store data from one link for a short time before sending data on to a next link. Ethernet cards can't broadcast all the time, they have to wait their turn.
Wouldn't this just be a bit like waiting a lot longer (say for hours or days instead of fractions of a second) before giving up on "best-effort" transfer across certain links? (I suppose you'd also want better dynamic routing, but that's something like a holy grail of networking in any case...)
I guess what I'm asking is: Are we still talking about a reliable transport layer on top of a lossy network layer, or are we now expecting to have a single lossless layer doing both network and transport? (Note: One layer sounds like a step backward given the history of network communications...)
What a complete crock...
Real Loonies GM Paranoia.
The problem is, discarding extraneous packets is actually a VERY GOOD THING when it comes to the internet. Several store and forward systems pre-dated the current TCP/IP stack, but guess what. They weren't as efficient in terms of required hardware resources or latency. This is because in a store and forward network, certain problems (like network cards going nuts and spewing tons of garbage) can cause lots and lots of data to accumulate in the network, and then you have to wait for every single packet to move on before you get to the new and relevant data.
The OSI model and network researchers in general recognize that reliable transport facilities can easily be built on top of unreliable "best-effort" communication networks, whereas it's nigh impossible to create light-weight best-effort services on top of a store and forward network. Since both kinds of applications exist, those that need reliable transport, and those that need speed. It only makes sense to provide an underlying fast and light weight network which doesn't provide, and isn't expected to provide, 100% reliability.
Finally, in practice, it actually turns out to be rediculous to expect 100% reliability from anything, particularly a low-level networking scheme since in the real world, no network is 100% reliable. Life can get very interesting indeed when you're supposed to rely on 100% packet delivery and one of your packets never arrives.
The real problem IMO when dealing with wireless networks is that so many developers try to shoehorn existing land-line applications and methodologies into the wireless world. There's a big difference between a network with an avg latency of 80ms, standard deviation of 2ms and 0.3% packet loss compared to a network with an avg latency of 500ms, a non-standard deviation pattern ranging between 200ms and 6 seconds and 20% packet loss. And that's completely ignoring issues related to moving between coverage zones and maintaining proper routing.
Basically, TCP, FTP, and many of their friends can wind up being very bad deals in such an environment. And things get even *more* interesting when someone tries to "fix" the network to work well with them... (by, for instance, blocking up groups of packets and waiting for a certain data-size to accumulate before sending.)
I thought routing tables and what not meant you don't need to know the route from source to destination. (trunk servers are supposed to have links with weight costs etc etc, where packets take a non-ideal route when a line is down for example.) Of course, it's very true that in practice this is rarely the case. No one seems to build reliable networks these days.
Sure, doing it with 0% packet loss might be new, but how important is that when you've got TCP to handle that?
...have anything to do with tech savvy?
Further, when was the last time a set of teachers and students could agree on what constituted a good research statement?
This "research" appears to have gone looking to prove "students are tech idiots" and found exactly what it was looking for. Woohoo, nice job guys. Perhaps we should conduct a similar study on whether or not most researchers are idiots by grading them on how well they can solve real world problems... (Since these researchers apparently felt it was appropriate to judge the tech idiocy of students based on their research skills.)
Wow, revelation of the century, students are bad at research and communication. That's because those are hard things to teach and they're quite often glossed over. Even some "researchers" are bad at this stuff! Heck being crappy at it sometimes even earns you more money than being good at it. (Kind of like writing software...)
Just have creators cryptographically sign their creations with a private key. Then, keep track of all such signed originals in a database along with who created them and who owns them.
Such items could easily be monitored. If someone made a slightly modified copy, then the digital signature of the creator would be altered and the copy would be exposed as a rip-off. (It could say "made by Handsom Hal" if original or "made by Slimey Susan" if it was a fake for example.)
Anyone with a well known designer's signature on their items would have "costly originals" while anyone without a signature would have "cheap imposters". There could even be a new trade in officially certifying content with a certification agency that checks for similar items that appear to be rip-offs.
The problem is.... Put yourself in the shoes of party A and put AOL Time Warner in the shoes of party B.
Who's going to win that kind of lawsuit regardless of the merits of the case?
Then again... If you've got something you know you can prove isn't a violation, those are some pretty deep pockets to go after. Not sure why no-one has gone take-down fishing in court yet... Or more importantly why no lawyers are knocking down the doors of those who've been mis-treated by DMCA takedown notices.
Or, perhaps there are some serious gotchas in the part where the copyright holder becomes liable...
Ya, because his second question was about deadlocks.
How is a deadlocked thread going to "test for shouldRun and exit"? It's already stuck in some obscure call that someone used to think was safe for critical sections to execute...