They have followed the same path over the past two decades
Nintendo's not a 20-30 year old company like Apple.
Nintendo's a one hundred and sixteen-year old company.
Nintendo has always made sure to expand its market to ensure that it's not ever in any danger. They own the Seattle Mariners, branched out into the taxi business as well as sex hotels and vacuum manufacturing.
Video games really made them a household name, but Nintendo has always been worried about being tied to a too-small portion of the populace. Then again, you don't get to be a 116 year old company without that worry.
IGN's quote is taken out of context. Gamespot's is more in detail.
Another question was presented to Sakurai. "How will Super Smash Bros. Brawl take advantage of the Wii controller?" The designer said he had been working with different ideas, and had found that too much use of the controller's pointing and motion-sensor functions was not a good thing. He then dropped a hint, saying gamers may not want to throw away their old GameCube controllers, which the Wii supports. Sakurai then said he wants to support the console, but offer something different than other Wii games.
He's not saying that you can't play it with the Wii controller. Just that it probably won't use many (or any) functions of it. Keep in mind that SSB doesn't really need much more than an analog stick and two buttons, which the controller and nunchaku have.
And if that's all you use, you could use a GameCube controller as well, if you felt like it.
If they'd really been sure that they'd have it for a while now, they would've had prototypes (not manufactured items - just sensors shoved in a controller shell) well beforehand. They didn't. We're not talking about a mass-produced controller here. They only needed one, for the developers - so it should've been hand made.
Hell, it sounds pretty much like the WarHawk devs didn't even know for sure if this was going to happen until last week. If they had honestly been planning this for a year, they would've known much earlier.
However, I'd say "completed at the last minute" would be appropriate.
Honestly, they can't have been working on it long: the WarHawk demo didn't go well (just read any of the reviews), and they must've known that it would've taken time for them to get the kinks worked out.
Regardless of how good the technology is, the implementation takes time, and they only gave the guys a week and a half. That just screams "last minute implementation" to me. If they'd been working on it for a year, I can't believe they wouldn't've been working more closely with them for longer.
To me, "hastily tacked on" means that the decision to add the feature came late in development and was then added at the last minute.
They found out in the last week or so. See here. They did the tuning in just the last few days.
I highly doubt that they wouldn't've given the controller to them if it had been ready earlier - or if they even knew it was going to work much earlier. This was a "have this work by E3 or else" announcement, and I'm surprised that it works at all.
I interpreted Theo's comments to imply that they want the radio firmware to be open down to the hardware level. Pushing binary blobs into flash and publishing an API into a buggy hardware driver does not do what he wants...
No: he doesn't care if you do that. That's not a 'blob' - that's a loadable firmware. That's fine. Just give them a copyright that allows them to redistribute it, and he's happy.
What he cares about are binary-only driver blobs - as in, some object file that gets linked with a wrapper file that converts OpenBSD API references to some API that they use, and then executes it.
If the device fails, that's one thing - it's recoverable, and it's debuggable. But if the processor suddenly jumps off into never-never land, that'll be hell to handle.
To quote:
The first kind to mention is firmwares. Firmwares (like for instance on a Intel wireless card, or a such) are binary pieces of code that will run on the little processor that is on the wireless card. As an operating system, we need to load the code out to the card. To include a firmware in OpenBSD, we simply need a nice copyright statement from the vendor that lets us distribute the firmware. Some vendors won't even go that far, though.
Then he goes on to discuss blobs. So he's not upset about firmware. He's upset about blobs.
For $1.99, I'd rather get Lost on iTMS and pipe it to my TV from my iPod.
I think you can still do that.
You can download a copy of it to your computer. It's quibbling on their part to say you can't transfer it elsewhere (so long as it stays for your personal, noncommercial use, and you only have one copy, I think you're fine).
Eh. Their silly player doesn't allow a full-screen version (just a 'kinda-full screen'). If I'm going to watch TV, I'd prefer it to be full-screen. This would allow me to do it.
Besides, it's not stealing: read the website's terms of use.
See? Right there. We can download one copy for personal, noncommercial home use only. Granted, by the letter of the law you can't copy it to like, an iPod, or something, but I doubt a judge would quibble all that much if someone did that.
How nice of them to let us do that - I'm surprised that no one else has mentioned it.
(Now, they might not *intend* for you to be able to rip the Flash stream, but hey, I'm just reading their own Terms of Use.)
That's strange: in 1995, 98% of the people killed in 2-vehicle crashes involving passenger cars and trucks were in the passenger cars.
Seems like when a truck and a car meet, the bigger vehicle wins.
For walking, my risk is fairly low
Yours may be.
But in general studies, walking in many areas (see Washington DC) is far more dangerous than driving (something like 10 times more dangerous, if memory serves). Now, that's because most people in general aren't as attentive to safety precautions as you are.
But the same, of course, is true, for motorcycles.
For bicycle and motorcycle riding, I can't avoid risky circumstances to the same degree.
Huh? Go the speed limit, or less. Avoid busy roads. Only drive during the day. Wear protective clothing. Don't drive a vehicle you don't know how to drive. Don't drive in poor weather.
In fact, I think it's easier to do the above than it is to always be able to always walk on sidewalks, for instance. Sidewalks often tend to only be built by the busiest roads - which are, of course, the most dangerous.
That'd be easy. Have it be a switch in the bottom of the cellphone (depressed, so you can't actually push it by accident). Then make a charging cradle for a car. Put the cellphone in the cradle, and it knows you're not available.
You're right. That would be very nice. I'm terrified whenever someone calls me talking on the cellphone while driving.
So if I'm reading this right you claim that motorcycles are just as safe as cars so long as not ridden at night or in bad weather?
Yup.
I'll play that game - crash 5 cars and 5 bikes in perfect weather, who's less hurt?
You apparently don't know the way this game works. You're assuming that motorcycles and cars will experience similar crash rates. I don't believe that's true. Motorcycles are far more agile, and, quite frankly, smaller. See the very good response to your post above.
Cars can't avoid obstacles as easily as motorcycles can.
A motorcycle rider has nothing around them
Except, like, armor. If you're riding a bike without protective clothing, you're crazy. They now even make jackets that inflate like air bags when a rider becomes separated from the cycle.
Ride one if you want but please spare me the speaches about how it's safe - it's not.
Spare me the crappy statistics and anecdotes. Riding a motorcycle is more difficult than driving a car, but that doesn't make it less safe. Try to find decent statistics out there about motorcycle accident rates and injury severity. I haven't been able to find them.
That's not to say there's anything wrong with the statistics out there. Most motorcycle injury information is intended to do what it should - make people realize that riding a motorcycle can be very dangerous if done wrong. That's fine. But when people pervert that information into concluding that they're death traps, that's just crazy.
unless you're saying that 10 times more motorcyclists ride drunk than automobile drivers drive drunk...
That is what I'm saying (mostly).
Though not just with driving drunk, though by percentage, many more motorcyclists ride drunk than people who drive cars drive drunk. The set of people who ride motorcycles are the same set of people that drive drunk in a car, that don't wear a seatbelt, that go 90+ on a highway. These type of people cause the majority of fatal accidents in normal cars too.
Also note that some of those things don't apply to cars. There aren't that many people who drive a car with the entire metal chassis stripped away, yet there are motorcyclists who drive without a helmet. If you want to compare similar (but not entirely similar) things directly there, the percentage of people who ride without a helmet is easily ten times higher than the percentage of people who drive without a seat belt.
So if you combined driving drunk, speeding, not using proper safety precautions, and not using a vehicle you can't use safely, yes, I do think that the percentage of people that do that with motorcycles could be as high as 10 times that for cars. (Could be. I'd say more like 5 times is safer.)
In the end, motorcycles would still end up being less safe for general use than a car, because motorcycles get more dangerous at night and in poor conditions. But if you restrict the use to decent weather and during the day, and properly control the demographics, I doubt that the fatality rates are all that different.
Most motorcycle fatalities are caused by the same factors:
Driving under the influence
Driving without proper protection
Driving a motorcycle you're not familiar with
Driving too fast
Driving recklessly
If you constrained the accidents to avoid all of these factors (which are controllable), the accident rate and fatality rate would go way down. At least in the US, I know that something like 60-70% of the fatalities in motorcycle accidents are caused by speeding. Something like 30% of the fatalities were from people who didn't have a valid license. 30% were intoxicated. 50% weren't wearing helmets. A lot of those factors overlap, but still if you eliminated most of them, you get a lot closer to that 2% number.
A lot of motorcycle riders are speed junkies. Said people have a higher fatality rate in normal cars. It's just that that gets amplified in motorcycles because they're a higher percentage of the riders.
You're assuming that the vehicle is the problem. It's not. It's the driver.
It's actually really frustrating to look up motorcycle accident statistics. I'm not interested in the aggregate rate. Why would I? I don't drink. I wear a helmet (and other protection). I don't speed. I know how to drive my motorcycle. I don't drive at night. Yet all I see is "hey, if you were as dumb as these other people, you'd be really likely to die in a motorcycle accident!" Yes. Thank you. Then again, if I were as dumb as those other people, I'd just be more likely to die in general, now wouldn't I?
The assets were sold off to someone. That person probably doesn't even know they own said assets, but I guarantee that the assets were in fact sold off to someone.
Do you really think Kirk got a Constitution class Starship right out of the acadamy? Check again!
Kirk took command of the Enterprise in 2263. He entered the Academy in 2250, and left in 2251. That's twelve years, not right out.
Spock was on the Enterprise under Pike from around 2252-2262 or so, and the Enterprise was his first assignment. That puts them at the Academy at the same time.
I'm not obsessed about this stuff, but I can read.
I'm not even sure it would be canonical for Kirk and Spock to have been at the academy together.
Kirk took command of the Enterprise in 2263. Spock served with Pike for 11 years, which would mean he was out of the Academy by 2252. The Enterprise was supposed to be his first assignment, as a Cadet. Kirk started in the Academy by 2250. So yeah, it works out. Barely.
Thankfully this information is compiled at Wikipedia, because God knows I wouldn't've done it myself.
If Alice and Bob are going to do the key exchange thing, what is to stop Eve from stepping into the middle before it begins. Then Alice actually winds up doing a key exchange with Eve and Eve does a corresponding (but different one) with Alice.
Keep in mind that Eve's (let's call her Mallory, M) key must be different. A's key is random, and there's no way to forcably regenerate A's states given B's intended reception.
So instead of sending the OTP you want to use for the message, send more. Let's send three times the amount, in fact. We'll use one third for the message (once it's verified secure), and one third to verify the key. The other third I'll explain in a bit.
Note that each of those thirds is independent, but if you have one third, you have all thirds. So you send this OTP, and then A establishes communications with B via a different channel. Doesn't have to be secure. Just has to be definitely with B. This includes physically going to B's location (I guess I'm assuming that M can't physically clone and replace B and somehow convince A that M's in B's location...).
Now, once that's done: so B definitely has a copy of A's OTP. Included in that OTP is one third that won't be used for anything - A uses this in the next OTP transmission to insert keyed states - that is, instead of a completely random string, there are 1s and 0s in places that are determined by the previous OTP. M can't know this - she doesn't have the previous OTP. And she can't recognize anything's wrong until the entire key's transmitted and she does a frequency analysis and realize that it doesn't look entirely random.
The problem was that she attempted to send the OTP to B without knowing about those positions. So she sent random noise in those locations. So now B knows that M isn't A, and the attack fails.
The one-third OTP can continue to be used in future exchanges to verify that A is A and B is B.
That sort of thing could be done with a normal OTP exchange too, I think. The main benefit is the initial exchange, where you know that if your recipient has one third of the key - or really, any part - they, and only they - have the whole thing.
Which is why 'physically going there' is probably unnecessary. It doesn't matter if someone wiretaps the phone hearing the verification OTP. That doesn't help them at all. The only thing 'physically going there' prevents is a universal man-in-the-middle attack.
However if we assume that Mallory is also between A and B for all conventional communication (i.e. not the quantum chanel) then things are different.
Yes, but there you'd have to assume that M is between A and B for literally all communications.
Including A driving over to B and getting some of the overlong OTP for verification (i.e. you transmit more than the OTP you're planning on using - you use the excess part for verification).
Once the first secure OTP is transmitted, that OTP can be used to key future communications to be completely untappable even if M is between A and B: because part of the previous OTP (unused, obviously) could be used to insert keyed states in the OTP stream. M, lacking previous OTPs, wouldn't be able to convince B that he's A because he wouldn't be able to recognize the keyed states in A's OTP stream until it's too late. (Actually, he wouldn't be able to recognize them at all - he'd just be able to recognize that there are keyed states in the stream. Which means all he'd know is that he's screwed.)
All you need to do, therefore, to set up a connection that's secure from everything except inside jobs is set up the link, send an initialization OTP, drive to the other side, verify that the initialization OTP was sent correctly, and then begin the secured traffic. The instant someone taps, or tries to insert themselves in between, you'll know.
P.S. Of course, QC is not perfect, because inside jobs can still steal the data, sabotage the sender/receiver or use the classic Man-In-The-Middle attack
How is the Man-in-the-Middle attack doable? Practically, at least.
Double the size of the OTP transmitted. Keep in mind Bob doesn't have Alice's key - it's just that Bob has a key and Alice has a key and those two keys happen to mathematically be related.
So Alice can ask Bob to transmit up to half of her OTP (which is twice as long as they need). This can be done via multiple insecure channels, as that portion of the data is discarded. It could be done physically, for that matter. All it does is verify that the recipient of the OTP is who you intended it to be.
The man-in-the-middle can't grab a random half of the OTP and let the other half get to Bob, and the OTP that M sends to Bob won't be the same as the one A sends to M. Once the OTP is verified, Alice knows Bob has the OTP, and no one else does.
The only real way to do a man-in-the-middle attack in this case would be to subvert all communications channels between Alice and Bob.
And once a first secure channel is initiated, I think you could even be super-super clever and use something like a key verification for future OTP streams. That is, insert into the OTP stream fixed states (rather than quantum superpositions - so you'd send a perfectly left-polarized photon, for instance) at positions determined by previous OTP streams (the dummy portion of the OTP stream. So probably to be safe, triple the OTP length and use one for the encoded message, one for verification, and one for the future keying positions).
A hypothetical man-in-the-middle has no way of knowing when a photon is supposed to be a fixed state (since he doesn't have the previous OTP) and so he'll send mixed states instead. The fixed states for him will just look like random noise. Yes, sure, afterwards once he sees the full stream, he'll be able to say 'oh, crap, those weren't random...' but on a bit by bit basis, he can't know. On the other end, when they try to verify the key positions, they won't verify, and they'll know that someone sent them a fully-random stream rather than an only partially-random stream.
Which means unless I'm missing something, all you need is a *first* secure exchange, which could be verified in person. Once that's done, the future communications between Alice and Bob are completely secure and utterly untappable.
I'm pretty sure quantum key distribution is safe against man-in-the-middle attacks. Inside jobs, however... that's a different story.
Does the author (or the person who tried to explain it to him) mean that ice uses holes as the charge carrier just like P-type semiconductor, and he just messed it up/reinterpreted it as protons?
The holes are protons (or at least, they could be. I need to find a decent article on the process to see: let's just assume it's really the hydrogens are proving the effect, and not the oxygens, okay?). Holes are just unfilled states in a valence band.
If you imagine pure hydrogen, for instance, the valence bands are - well - the electrons. A hole in pure hydrogen, then, is going to be located at a proton.
Now, that's still not entirely right, though, because while the hole would be located at the proton, it wouldn't be the proton, because if you talk about the hole moving, it would really be an electron moving - that is, an electron from an adjacent proton would hop over, and the 'hole' would move.
So the author is both right, and wrong.
But to be fair: the slipup that he's making is very often made. It's akin to saying 'electrons move at a third the speed of light in a copper conductor' - which is wrong. But also to be more fair - if you posted a video of the process, it really would look like a proton was being conducted along. It's not like you can tell the difference between the proton that's got an electron around it and the proton that doesn't.
I've yet to experience this sort of behaviour on any Windows system, although I've heard it bandied around frequently. I suspect it's much like that "Internet Explorer is part of the Windows kernel" that gets similarly parroted on Slashdot. Sure you're not repeating hearsay dating from NT 3.x and 4.0 ?
Hang on. Let me go check the Windows XP box upstairs defragmenting a violently fragmented 80 GB HD that took four days to even start the defrag test. Keep in mind said drive is only about 50% full? Maybe less? But I copied over a few DVD images to burn, took it to about 95%, burned them, deleted them, and a week or so later, oh, hey, look, the partition's fragmented to hell.
Yup. I'm not repeating old info.
Have you ever let Windows fill a disk above, say, 90%? Windows reserves the first 12% for the master file table, and when you fill above that level, it starts fragmenting the MFT extremely fast.
And then performance goes to hell. Certain services start randomly failing due to timeouts, and Windows occasionally thinks its run out of swap space and starts denying memory requests, causing all hell to break loose.
Yes. I can't even remember the time I saw a Windows NT machine crash where faulty hardware or bad drivers wasn't directly responsible (and easily identifiable as such).
Happened to me last week - due to the above. Back when I had only a 20 GB drive in that computer (with ~12 GB to Windows), it happened at least once or twice a month. I eventually switched to Linux (which only had ~5 GB for the home directory, which means I was filling it up every time I made a new DVD) which completely couldn't care that I was doing that.
I think Windows is fine so long as you have A) plenty of drive space, and B) plenty of RAM. And 'plenty' here is dynamic - it means 'whatever's needed to make sure you're not running out'. Whenever either of those two become crunched, Windows doesn't do so well.
Slashdot Mirror
They have followed the same path over the past two decades
Nintendo's not a 20-30 year old company like Apple.
Nintendo's a one hundred and sixteen -year old company.
Nintendo has always made sure to expand its market to ensure that it's not ever in any danger. They own the Seattle Mariners, branched out into the taxi business as well as sex hotels and vacuum manufacturing.
Video games really made them a household name, but Nintendo has always been worried about being tied to a too-small portion of the populace. Then again, you don't get to be a 116 year old company without that worry.
He's not saying that you can't play it with the Wii controller. Just that it probably won't use many (or any) functions of it. Keep in mind that SSB doesn't really need much more than an analog stick and two buttons, which the controller and nunchaku have.
And if that's all you use, you could use a GameCube controller as well, if you felt like it.
If they'd really been sure that they'd have it for a while now, they would've had prototypes (not manufactured items - just sensors shoved in a controller shell) well beforehand. They didn't. We're not talking about a mass-produced controller here. They only needed one, for the developers - so it should've been hand made.
Hell, it sounds pretty much like the WarHawk devs didn't even know for sure if this was going to happen until last week. If they had honestly been planning this for a year, they would've known much earlier.
However, I'd say "completed at the last minute" would be appropriate.
Honestly, they can't have been working on it long: the WarHawk demo didn't go well (just read any of the reviews), and they must've known that it would've taken time for them to get the kinks worked out.
Regardless of how good the technology is, the implementation takes time, and they only gave the guys a week and a half. That just screams "last minute implementation" to me. If they'd been working on it for a year, I can't believe they wouldn't've been working more closely with them for longer.
To me, "hastily tacked on" means that the decision to add the feature came late in development and was then added at the last minute.
They found out in the last week or so. See here. They did the tuning in just the last few days.
I highly doubt that they wouldn't've given the controller to them if it had been ready earlier - or if they even knew it was going to work much earlier. This was a "have this work by E3 or else" announcement, and I'm surprised that it works at all.
Govn't raises MPG standards for all vehicles produced moving forward. Closing the SUV hole is a good start.
They did, several months ago. Look under 'Future'.
Why didn't this get more press?
It doesn't set in until 2010, but that's basically needed due to the delay between design and implementation in the auto industry.
No: he doesn't care if you do that. That's not a 'blob' - that's a loadable firmware. That's fine. Just give them a copyright that allows them to redistribute it, and he's happy.
What he cares about are binary-only driver blobs - as in, some object file that gets linked with a wrapper file that converts OpenBSD API references to some API that they use, and then executes it.
If the device fails, that's one thing - it's recoverable, and it's debuggable. But if the processor suddenly jumps off into never-never land, that'll be hell to handle.
To quote:
Then he goes on to discuss blobs. So he's not upset about firmware. He's upset about blobs.
For $1.99, I'd rather get Lost on iTMS and pipe it to my TV from my iPod.
I think you can still do that.
You can download a copy of it to your computer. It's quibbling on their part to say you can't transfer it elsewhere (so long as it stays for your personal, noncommercial use, and you only have one copy, I think you're fine).
Their Terms of Use is surprisingly liberal.
why would you want to record the Flash version?
Eh. Their silly player doesn't allow a full-screen version (just a 'kinda-full screen'). If I'm going to watch TV, I'd prefer it to be full-screen. This would allow me to do it.
Besides, it's not stealing: read the website's terms of use.
See? Right there. We can download one copy for personal, noncommercial home use only. Granted, by the letter of the law you can't copy it to like, an iPod, or something, but I doubt a judge would quibble all that much if someone did that.
How nice of them to let us do that - I'm surprised that no one else has mentioned it.
(Now, they might not *intend* for you to be able to rip the Flash stream, but hey, I'm just reading their own Terms of Use.)
size has little to do with it.
That's strange: in 1995, 98% of the people killed in 2-vehicle crashes involving passenger cars and trucks were in the passenger cars.
Seems like when a truck and a car meet, the bigger vehicle wins.
For walking, my risk is fairly low
Yours may be.
But in general studies, walking in many areas (see Washington DC) is far more dangerous than driving (something like 10 times more dangerous, if memory serves). Now, that's because most people in general aren't as attentive to safety precautions as you are.
But the same, of course, is true, for motorcycles.
For bicycle and motorcycle riding, I can't avoid risky circumstances to the same degree.
Huh? Go the speed limit, or less. Avoid busy roads. Only drive during the day. Wear protective clothing. Don't drive a vehicle you don't know how to drive. Don't drive in poor weather.
In fact, I think it's easier to do the above than it is to always be able to always walk on sidewalks, for instance. Sidewalks often tend to only be built by the busiest roads - which are, of course, the most dangerous.
That'd be easy. Have it be a switch in the bottom of the cellphone (depressed, so you can't actually push it by accident). Then make a charging cradle for a car. Put the cellphone in the cradle, and it knows you're not available.
You're right. That would be very nice. I'm terrified whenever someone calls me talking on the cellphone while driving.
I'm curious how to best project a presence.
A horn.
Seriously. Motorcyclists don't use their horn nearly enough (most drivers in the US don't use their horn enough).
If someone cuts you off too close, honk. A while. Horns grab people's attention unlike a lot of other things, for some reason.
Unless, of course, the idiot's talking on his cell phone. But then he should just have his freaking license revoked.
So if I'm reading this right you claim that motorcycles are just as safe as cars so long as not ridden at night or in bad weather?
Yup.
I'll play that game - crash 5 cars and 5 bikes in perfect weather, who's less hurt?
You apparently don't know the way this game works. You're assuming that motorcycles and cars will experience similar crash rates. I don't believe that's true. Motorcycles are far more agile, and, quite frankly, smaller. See the very good response to your post above.
Cars can't avoid obstacles as easily as motorcycles can.
A motorcycle rider has nothing around them
Except, like, armor. If you're riding a bike without protective clothing, you're crazy. They now even make jackets that inflate like air bags when a rider becomes separated from the cycle.
Ride one if you want but please spare me the speaches about how it's safe - it's not.
Spare me the crappy statistics and anecdotes. Riding a motorcycle is more difficult than driving a car, but that doesn't make it less safe. Try to find decent statistics out there about motorcycle accident rates and injury severity. I haven't been able to find them.
That's not to say there's anything wrong with the statistics out there. Most motorcycle injury information is intended to do what it should - make people realize that riding a motorcycle can be very dangerous if done wrong. That's fine. But when people pervert that information into concluding that they're death traps, that's just crazy.
unless you're saying that 10 times more motorcyclists ride drunk than automobile drivers drive drunk...
That is what I'm saying (mostly).
Though not just with driving drunk, though by percentage, many more motorcyclists ride drunk than people who drive cars drive drunk. The set of people who ride motorcycles are the same set of people that drive drunk in a car, that don't wear a seatbelt, that go 90+ on a highway. These type of people cause the majority of fatal accidents in normal cars too.
Also note that some of those things don't apply to cars. There aren't that many people who drive a car with the entire metal chassis stripped away, yet there are motorcyclists who drive without a helmet. If you want to compare similar (but not entirely similar) things directly there, the percentage of people who ride without a helmet is easily ten times higher than the percentage of people who drive without a seat belt.
So if you combined driving drunk, speeding, not using proper safety precautions, and not using a vehicle you can't use safely, yes, I do think that the percentage of people that do that with motorcycles could be as high as 10 times that for cars. (Could be. I'd say more like 5 times is safer.)
In the end, motorcycles would still end up being less safe for general use than a car, because motorcycles get more dangerous at night and in poor conditions. But if you restrict the use to decent weather and during the day, and properly control the demographics, I doubt that the fatality rates are all that different.
where the only way you can record digital cable or HDTV is to connect the cable box to your video in, and hit play and record on two remotes.
Uh, you do realize that it's not only possible, but rather easy, to set up MythTV to work with cable boxes?
Hit play and record on two remotes? What is this, 1980?
Most motorcycle fatalities are caused by the same factors:
If you constrained the accidents to avoid all of these factors (which are controllable), the accident rate and fatality rate would go way down. At least in the US, I know that something like 60-70% of the fatalities in motorcycle accidents are caused by speeding. Something like 30% of the fatalities were from people who didn't have a valid license. 30% were intoxicated. 50% weren't wearing helmets. A lot of those factors overlap, but still if you eliminated most of them, you get a lot closer to that 2% number.
A lot of motorcycle riders are speed junkies. Said people have a higher fatality rate in normal cars. It's just that that gets amplified in motorcycles because they're a higher percentage of the riders.
You're assuming that the vehicle is the problem. It's not. It's the driver.
It's actually really frustrating to look up motorcycle accident statistics. I'm not interested in the aggregate rate. Why would I? I don't drink. I wear a helmet (and other protection). I don't speed. I know how to drive my motorcycle. I don't drive at night. Yet all I see is "hey, if you were as dumb as these other people, you'd be really likely to die in a motorcycle accident!" Yes. Thank you. Then again, if I were as dumb as those other people, I'd just be more likely to die in general, now wouldn't I?
The assets were sold off to someone. That person probably doesn't even know they own said assets, but I guarantee that the assets were in fact sold off to someone.
Do you really think Kirk got a Constitution class Starship right out of the acadamy? Check again!
Kirk took command of the Enterprise in 2263. He entered the Academy in 2250, and left in 2251. That's twelve years, not right out.
Spock was on the Enterprise under Pike from around 2252-2262 or so, and the Enterprise was his first assignment. That puts them at the Academy at the same time.
I'm not obsessed about this stuff, but I can read.
I'm not even sure it would be canonical for Kirk and Spock to have been at the academy together.
Kirk took command of the Enterprise in 2263. Spock served with Pike for 11 years, which would mean he was out of the Academy by 2252. The Enterprise was supposed to be his first assignment, as a Cadet. Kirk started in the Academy by 2250. So yeah, it works out. Barely.
Thankfully this information is compiled at Wikipedia, because God knows I wouldn't've done it myself.
If Alice and Bob are going to do the key exchange thing, what is to stop Eve from stepping into the middle before it begins. Then Alice actually winds up doing a key exchange with Eve and Eve does a corresponding (but different one) with Alice.
Keep in mind that Eve's (let's call her Mallory, M) key must be different. A's key is random, and there's no way to forcably regenerate A's states given B's intended reception.
So instead of sending the OTP you want to use for the message, send more. Let's send three times the amount, in fact. We'll use one third for the message (once it's verified secure), and one third to verify the key. The other third I'll explain in a bit.
Note that each of those thirds is independent, but if you have one third, you have all thirds. So you send this OTP, and then A establishes communications with B via a different channel. Doesn't have to be secure. Just has to be definitely with B. This includes physically going to B's location (I guess I'm assuming that M can't physically clone and replace B and somehow convince A that M's in B's location...).
Now, once that's done: so B definitely has a copy of A's OTP. Included in that OTP is one third that won't be used for anything - A uses this in the next OTP transmission to insert keyed states - that is, instead of a completely random string, there are 1s and 0s in places that are determined by the previous OTP. M can't know this - she doesn't have the previous OTP. And she can't recognize anything's wrong until the entire key's transmitted and she does a frequency analysis and realize that it doesn't look entirely random.
The problem was that she attempted to send the OTP to B without knowing about those positions. So she sent random noise in those locations. So now B knows that M isn't A, and the attack fails.
The one-third OTP can continue to be used in future exchanges to verify that A is A and B is B.
That sort of thing could be done with a normal OTP exchange too, I think. The main benefit is the initial exchange, where you know that if your recipient has one third of the key - or really, any part - they, and only they - have the whole thing.
Which is why 'physically going there' is probably unnecessary. It doesn't matter if someone wiretaps the phone hearing the verification OTP. That doesn't help them at all. The only thing 'physically going there' prevents is a universal man-in-the-middle attack.
However if we assume that Mallory is also between A and B for all conventional communication (i.e. not the quantum chanel) then things are different.
Yes, but there you'd have to assume that M is between A and B for literally all communications.
Including A driving over to B and getting some of the overlong OTP for verification (i.e. you transmit more than the OTP you're planning on using - you use the excess part for verification).
Once the first secure OTP is transmitted, that OTP can be used to key future communications to be completely untappable even if M is between A and B: because part of the previous OTP (unused, obviously) could be used to insert keyed states in the OTP stream. M, lacking previous OTPs, wouldn't be able to convince B that he's A because he wouldn't be able to recognize the keyed states in A's OTP stream until it's too late. (Actually, he wouldn't be able to recognize them at all - he'd just be able to recognize that there are keyed states in the stream. Which means all he'd know is that he's screwed.)
All you need to do, therefore, to set up a connection that's secure from everything except inside jobs is set up the link, send an initialization OTP, drive to the other side, verify that the initialization OTP was sent correctly, and then begin the secured traffic. The instant someone taps, or tries to insert themselves in between, you'll know.
P.S. Of course, QC is not perfect, because inside jobs can still steal the data, sabotage the sender/receiver or use the classic Man-In-The-Middle attack
How is the Man-in-the-Middle attack doable? Practically, at least.
Double the size of the OTP transmitted. Keep in mind Bob doesn't have Alice's key - it's just that Bob has a key and Alice has a key and those two keys happen to mathematically be related.
So Alice can ask Bob to transmit up to half of her OTP (which is twice as long as they need). This can be done via multiple insecure channels, as that portion of the data is discarded. It could be done physically, for that matter. All it does is verify that the recipient of the OTP is who you intended it to be.
The man-in-the-middle can't grab a random half of the OTP and let the other half get to Bob, and the OTP that M sends to Bob won't be the same as the one A sends to M. Once the OTP is verified, Alice knows Bob has the OTP, and no one else does.
The only real way to do a man-in-the-middle attack in this case would be to subvert all communications channels between Alice and Bob.
And once a first secure channel is initiated, I think you could even be super-super clever and use something like a key verification for future OTP streams. That is, insert into the OTP stream fixed states (rather than quantum superpositions - so you'd send a perfectly left-polarized photon, for instance) at positions determined by previous OTP streams (the dummy portion of the OTP stream. So probably to be safe, triple the OTP length and use one for the encoded message, one for verification, and one for the future keying positions).
A hypothetical man-in-the-middle has no way of knowing when a photon is supposed to be a fixed state (since he doesn't have the previous OTP) and so he'll send mixed states instead. The fixed states for him will just look like random noise. Yes, sure, afterwards once he sees the full stream, he'll be able to say 'oh, crap, those weren't random...' but on a bit by bit basis, he can't know. On the other end, when they try to verify the key positions, they won't verify, and they'll know that someone sent them a fully-random stream rather than an only partially-random stream.
Which means unless I'm missing something, all you need is a *first* secure exchange, which could be verified in person. Once that's done, the future communications between Alice and Bob are completely secure and utterly untappable.
I'm pretty sure quantum key distribution is safe against man-in-the-middle attacks. Inside jobs, however... that's a different story.
Does the author (or the person who tried to explain it to him) mean that ice uses holes as the charge carrier just like P-type semiconductor, and he just messed it up/reinterpreted it as protons?
The holes are protons (or at least, they could be. I need to find a decent article on the process to see: let's just assume it's really the hydrogens are proving the effect, and not the oxygens, okay?). Holes are just unfilled states in a valence band.
If you imagine pure hydrogen, for instance, the valence bands are - well - the electrons. A hole in pure hydrogen, then, is going to be located at a proton.
Now, that's still not entirely right, though, because while the hole would be located at the proton, it wouldn't be the proton, because if you talk about the hole moving, it would really be an electron moving - that is, an electron from an adjacent proton would hop over, and the 'hole' would move.
So the author is both right, and wrong.
But to be fair: the slipup that he's making is very often made. It's akin to saying 'electrons move at a third the speed of light in a copper conductor' - which is wrong. But also to be more fair - if you posted a video of the process, it really would look like a proton was being conducted along. It's not like you can tell the difference between the proton that's got an electron around it and the proton that doesn't.
I've yet to experience this sort of behaviour on any Windows system, although I've heard it bandied around frequently. I suspect it's much like that "Internet Explorer is part of the Windows kernel" that gets similarly parroted on Slashdot. Sure you're not repeating hearsay dating from NT 3.x and 4.0 ?
Hang on. Let me go check the Windows XP box upstairs defragmenting a violently fragmented 80 GB HD that took four days to even start the defrag test. Keep in mind said drive is only about 50% full? Maybe less? But I copied over a few DVD images to burn, took it to about 95%, burned them, deleted them, and a week or so later, oh, hey, look, the partition's fragmented to hell.
Yup. I'm not repeating old info.
Have you ever let Windows fill a disk above, say, 90%? Windows reserves the first 12% for the master file table, and when you fill above that level, it starts fragmenting the MFT extremely fast.
And then performance goes to hell. Certain services start randomly failing due to timeouts, and Windows occasionally thinks its run out of swap space and starts denying memory requests, causing all hell to break loose.
Yes. I can't even remember the time I saw a Windows NT machine crash where faulty hardware or bad drivers wasn't directly responsible (and easily identifiable as such).
Happened to me last week - due to the above. Back when I had only a 20 GB drive in that computer (with ~12 GB to Windows), it happened at least once or twice a month. I eventually switched to Linux (which only had ~5 GB for the home directory, which means I was filling it up every time I made a new DVD) which completely couldn't care that I was doing that.
I think Windows is fine so long as you have A) plenty of drive space, and B) plenty of RAM. And 'plenty' here is dynamic - it means 'whatever's needed to make sure you're not running out'. Whenever either of those two become crunched, Windows doesn't do so well.
If you read the article, you'll find that the size is only 1400km
~1400 miles. ~2200-2300 kilometers.