1) Reaction time to a specific, anticipated event, you're likely right. But there's one crucial element to navigation that humans can do that computers currently can't - make arbitrary, seemingly illogical decisions in the heat of the moment. Take GP's hypothetical about the cliffside road - most humans, thanks to self-preservation instinct, will choose to rear-end the other car rather than drive off the ledge; what would a computer that is programmed to "avoid contact with other cars at all costs" do in that situation? Hyperbole aside, there's no way of knowing until we put one in that real world situation.
Do a quick search for 'fuzzy logic'. It sorts out all the issues that you're talking about here. This problem has already been solved.
2) I'll give you that one, I suck at distance estimation, although I wouldn't go so far as to imply that machine calculations are infallible, either. They are programmed by humans, and subject to elemental factors, after all.
If my radar system isn't working because of the rain/snow, trust me, you're eyes won't be working either.
3) If vision is the only sense you use when driving, you shouldn't be driving.
So you're using sound and touch as well. Impressive, especially considering that there is no way in hell computer systems can have sound and touch inputs. Oh wait...
4) an auto-car may maintain speed better, assuming that it is receiving accurate information from its sensors, and interpreting said information correctly. What happens when the auto-car's front facing range finder gets just enough mud on it to make the car think there's an object.2mm from the front end of the vehicle? Will it refuse to move forward, or perhaps start reversing furiously to avoid the "obstacle" it's certain it's about to smash into?
It will probably tell you to clean the mud off of the sensor, or use a wiper/spray to do it for you.
5) A hacker doesn't need to gain access to the actual auto-driving mechanism to cause problems (though, considering the fact these things use Wifi and other forms of RF communication betwix themselves, it wouldn't be a stretch to think they could be compromised), all the perp would need to do is provide enough false or junk data to confuse the auto-driving algorithm into abnormal behavior. This can be done with readily available, off the shelf electronics.
So, how do you propose to disrupt RADAR, LIDAR and camera based systems in a way that wouldn't affect human drivers?
Speaking of which... how do you suppose an auto-car would handle a construction blasting zone, in which drivers are legally required to shut down all radios?
By using the LIDAR and camera based systems, leaving out the RADAR and pre-downloading map data. Easy peasy. They can even leave GPS running.
They don't need to. Just upload a little executable that sends everything over wifi/3G to them, and listens to new commands over those interfaces as well.
He never said anything about interrupts. You invented that, and put it into his mouth.
What other mechanism do you propose with which to cause a thread to go idle? Sleeps in the thread? Well, are you aware of the mechanism used to make the sleep work? It uses... wait for it... timer based interrupts!
Interrupts are always better. I have experience on embedded ARM Cortex M3 based chips, Intel 8051,Freescale MC9S08GT16, plus misc Linux work. Polling is nice, easy and dirty, until you need to do anything else as well, or you want to limit your power usage. You don't always have one core available for each listener interface, and the context switching from threads and sleeps is just as bad as from interrupts. The difference is that threads and sleeps trigger a lot no matter how much you are using them, whereas interrupts only happen when you actually have data to process. One of the main issues with power usage on Linux is that it is polling all the time instead of using interrupts, waking the CPU up from the lower power states.
BS. I have a friend who has gone through about 7 phones in the last 5 years. He buys the replacements. How has he damaged them? He leads an active lifestyle - rock climbing, hiking, rides a motorbike. He also got mugged twice.
So I would say that old people don't engage in activities which could result in a phone breaking because they are... well... old.
Note that since your SSH client is idling that CPU could have gone to your foreground task but instead the CPU is sitting idle.
This is what I had a problem with, it is blatantly incorrect. There is no way that the second core is idle because of an interrupt, which is preventing the foreground task from using the core. Moreover, nowhere does this imply "single-threaded app". If he meant that the foreground app was single-threaded, then how does
that CPU could have gone to your foreground task but instead the CPU is sitting idle
fit in? If he meant single-threaded, this sentence contradicts that, and as such it has nothing to do with my reading comprehension.
And interrupts... it depends how often you need them. If you have keyboard input, interrupts are great. If you have network packets arriving 10x a second, interrupts are great. If you want to check something at exactly 1000Hz, not so much, unless your interrupt is hardware driven and you're using a realtime OS or no OS at all; however, polling would give you pretty crap results then as well, besides the fact that it would munch your CPU and any concurrent use of the CPU would result in all sorts of inaccuracies. I use interrupts on embedded stuff all the time, and I can get much higher performance and accuracy via interrupts than I ever could with polling, especially once I start trying to use more than one input source at a time (ie. always). In a higher level system, interrupts can be replaced with event-driven design, they're essentially the same thing. Polling is horribly inefficient compared to interrupts/events, I'm not sure if you're being serious when you advocate it's use, but... yuck.
When a process is waiting on an interrupt it doesn't consume a core. That's basic multiprocessing. The foreground task is free to use that second core, there is nothing stopping it, even if you have 10 background SSH's running, all waiting on interrupts. That's the beauty of interrupts - they don't consume CPU.
What stupid operating system would allocate an entire core to handle a single interrupt? Even if it was sitting in idle, it's still stupid, and guess what? It doesn't work that way.
Note that since your SSH client is idling that CPU could have gone to your foreground task but instead the CPU is sitting idle.
I'm sorry, WHAT!?!?!?!
Have you ever heard of using system wait/interrupts instead of asm("nop"); ? Because the people who actually write decent, useful programs have, and it doesn't suffer from this problem.
I'm sure further up in the thread you said you weren't a complete idiot... you might want to re-evaluate that.
The 'bipolar difficulty' I don't really see as a problem. A lot of the questions are just there as checkups to see if you have been paying attention (and keep you paying attention). Others require you to think a bit. I did the self-driving car course, and I also noticed this, however I found it useful. I don't want to get bogged down in a hard question every 5 minutes of lectures, but I also like quick checkups every 5 minutes. The quick checkups don't have enough depth to fully test some components, so there will be harder questions. If it's a big, complicated concept, the question will be big and complicated. Big deal. Get over it.
As AC alluded to, they can only be charged with perjury if they don't have rights to the work they claim is being infringed. If your work is nothing to do with the work they claim is infringed, you have no recourse. So to troll the system all you have to do is have a random copyright on something, and claim everything you see infringes on it.
Slashdot Mirror
1) Reaction time to a specific, anticipated event, you're likely right. But there's one crucial element to navigation that humans can do that computers currently can't - make arbitrary, seemingly illogical decisions in the heat of the moment. Take GP's hypothetical about the cliffside road - most humans, thanks to self-preservation instinct, will choose to rear-end the other car rather than drive off the ledge; what would a computer that is programmed to "avoid contact with other cars at all costs" do in that situation? Hyperbole aside, there's no way of knowing until we put one in that real world situation.
Do a quick search for 'fuzzy logic'. It sorts out all the issues that you're talking about here. This problem has already been solved.
2) I'll give you that one, I suck at distance estimation, although I wouldn't go so far as to imply that machine calculations are infallible, either. They are programmed by humans, and subject to elemental factors, after all.
If my radar system isn't working because of the rain/snow, trust me, you're eyes won't be working either.
3) If vision is the only sense you use when driving, you shouldn't be driving.
So you're using sound and touch as well. Impressive, especially considering that there is no way in hell computer systems can have sound and touch inputs. Oh wait...
4) an auto-car may maintain speed better, assuming that it is receiving accurate information from its sensors, and interpreting said information correctly. What happens when the auto-car's front facing range finder gets just enough mud on it to make the car think there's an object .2mm from the front end of the vehicle? Will it refuse to move forward, or perhaps start reversing furiously to avoid the "obstacle" it's certain it's about to smash into?
It will probably tell you to clean the mud off of the sensor, or use a wiper/spray to do it for you.
5) A hacker doesn't need to gain access to the actual auto-driving mechanism to cause problems (though, considering the fact these things use Wifi and other forms of RF communication betwix themselves, it wouldn't be a stretch to think they could be compromised), all the perp would need to do is provide enough false or junk data to confuse the auto-driving algorithm into abnormal behavior. This can be done with readily available, off the shelf electronics.
So, how do you propose to disrupt RADAR, LIDAR and camera based systems in a way that wouldn't affect human drivers?
Speaking of which... how do you suppose an auto-car would handle a construction blasting zone, in which drivers are legally required to shut down all radios?
By using the LIDAR and camera based systems, leaving out the RADAR and pre-downloading map data. Easy peasy. They can even leave GPS running.
I second that a computer has a faster reaction time than you do. Sorry, man, you seem outnumbered on this one.
ISS isn't sufficiently shielded to be outside of LEO
Random deviation caused by the brewer having an especially good/bad batch, or a judge being in a good mood when they sample the beer, or whatever.
I love it when people who make jokes about vegetarians have terrible grammar.
Obviously, just barcode the people. It will make things much easier for admin.
They don't need to. Just upload a little executable that sends everything over wifi/3G to them, and listens to new commands over those interfaces as well.
They did it via a malicious webpage. I said hack, not jailbreak.
Read the link:
http://thenextweb.com/apple/2012/09/19/dutch-security-researchers-hack-apple-iphone-4s-exploiting-safari/
They did it via a malicious webpage, which IMO is even worse than via NFC.
http://thenextweb.com/apple/2012/09/19/dutch-security-researchers-hack-apple-iphone-4s-exploiting-safari/
At the same event, they also hacked iOS6. Just to give an unbiased view...
He never said anything about interrupts. You invented that, and put it into his mouth.
What other mechanism do you propose with which to cause a thread to go idle? Sleeps in the thread? Well, are you aware of the mechanism used to make the sleep work? It uses... wait for it... timer based interrupts!
Interrupts are always better. I have experience on embedded ARM Cortex M3 based chips, Intel 8051,Freescale MC9S08GT16, plus misc Linux work. Polling is nice, easy and dirty, until you need to do anything else as well, or you want to limit your power usage. You don't always have one core available for each listener interface, and the context switching from threads and sleeps is just as bad as from interrupts. The difference is that threads and sleeps trigger a lot no matter how much you are using them, whereas interrupts only happen when you actually have data to process. One of the main issues with power usage on Linux is that it is polling all the time instead of using interrupts, waking the CPU up from the lower power states.
In my country they usually go up to 5, but I know when I travel to the US/EU the ATM only accepts the first 4.
Dunno - one of my friends won one in a competition, but that's all I've seen.
BS. I have a friend who has gone through about 7 phones in the last 5 years. He buys the replacements. How has he damaged them? He leads an active lifestyle - rock climbing, hiking, rides a motorbike. He also got mugged twice.
So I would say that old people don't engage in activities which could result in a phone breaking because they are... well... old.
Note that since your SSH client is idling that CPU could have gone to your foreground task but instead the CPU is sitting idle.
This is what I had a problem with, it is blatantly incorrect. There is no way that the second core is idle because of an interrupt, which is preventing the foreground task from using the core. Moreover, nowhere does this imply "single-threaded app". If he meant that the foreground app was single-threaded, then how does
that CPU could have gone to your foreground task but instead the CPU is sitting idle
fit in? If he meant single-threaded, this sentence contradicts that, and as such it has nothing to do with my reading comprehension.
And interrupts... it depends how often you need them. If you have keyboard input, interrupts are great. If you have network packets arriving 10x a second, interrupts are great. If you want to check something at exactly 1000Hz, not so much, unless your interrupt is hardware driven and you're using a realtime OS or no OS at all; however, polling would give you pretty crap results then as well, besides the fact that it would munch your CPU and any concurrent use of the CPU would result in all sorts of inaccuracies. I use interrupts on embedded stuff all the time, and I can get much higher performance and accuracy via interrupts than I ever could with polling, especially once I start trying to use more than one input source at a time (ie. always). In a higher level system, interrupts can be replaced with event-driven design, they're essentially the same thing. Polling is horribly inefficient compared to interrupts/events, I'm not sure if you're being serious when you advocate it's use, but... yuck.
When a process is waiting on an interrupt it doesn't consume a core. That's basic multiprocessing. The foreground task is free to use that second core, there is nothing stopping it, even if you have 10 background SSH's running, all waiting on interrupts. That's the beauty of interrupts - they don't consume CPU.
What stupid operating system would allocate an entire core to handle a single interrupt? Even if it was sitting in idle, it's still stupid, and guess what? It doesn't work that way.
Note that since your SSH client is idling that CPU could have gone to your foreground task but instead the CPU is sitting idle.
I'm sorry, WHAT!?!?!?!
Have you ever heard of using system wait/interrupts instead of asm("nop"); ? Because the people who actually write decent, useful programs have, and it doesn't suffer from this problem.
I'm sure further up in the thread you said you weren't a complete idiot... you might want to re-evaluate that.
Whoosh!
Surely this means that network operators have no incentive to increase their coverage?
Deserts. They are big, don't have people or plants, and get year round sun. They're even made out of the primary ingredient in solar panels!
It's because there's just so much of it...
The 'bipolar difficulty' I don't really see as a problem. A lot of the questions are just there as checkups to see if you have been paying attention (and keep you paying attention). Others require you to think a bit. I did the self-driving car course, and I also noticed this, however I found it useful. I don't want to get bogged down in a hard question every 5 minutes of lectures, but I also like quick checkups every 5 minutes. The quick checkups don't have enough depth to fully test some components, so there will be harder questions. If it's a big, complicated concept, the question will be big and complicated. Big deal. Get over it.
So, down to 4 problems.
As AC alluded to, they can only be charged with perjury if they don't have rights to the work they claim is being infringed. If your work is nothing to do with the work they claim is infringed, you have no recourse. So to troll the system all you have to do is have a random copyright on something, and claim everything you see infringes on it.
Because, according to TFS:
While the rising pressure within the magma chamber is of concern, it is but one factor among many that lead to eruptions.