I used to have a Mac SE at work with a hard drive that would not spin up at powerup. I would hold it in the air with one hand, and whack it really hard on an edge to spin the whole Mac. The momentum differential would cause the platters to break free and spin up.
Another colleague's monitor would occasionally go on the fritz, and a good whack on the side would shape it up.
(Let me add to those about to reply that abusing machines are not good for their longevity, these were pretty much shot anyhow, and we all wanted new machines.)
This technique only occasionally worked with software.;-)
Is 1900-1949 really better than past 50 years? The jury is still out, so to speak, as evidenced by the number of US executions since 1930.
Looks like between 1930 and 1949 we were going hog-wild on executions. Average nearly 150 a year. Lots of people whacking each other. Nothing better to do.
But then TV came along. By 1968 people found watching Star Trek and Green Acres and Mutual of Omaha's Wild Kingdom much more amusing than whacking each other. No executions for capital crimes between 1968 and 1976.
Then Disco came in 1977 but only a few people whacked each other over it. It wasn't until the advent of 100+ channel cable in 1984 and the crappy shows that came with it that people started losing interest in the tube.
The Internet has really fouled things up. In the last five years more people have been executed than in the entire period from 1962 to 1994. Probably from people whacking each other while waiting for their files to download. Have you ever heard "You've Got Mail!" played backwards?
I'm hoping that ubiquitous broadband will bring television to the Internet and reverse this trend.
But eventually I learned that I could slow down and not announce every answer in an arrogant fashion, and could let others participate.
That's the point. There's no need to take everyone else's advice and point him away from his gift. You just need to make him AWARE that he needs to do it with grace and humility. That lesson will automatically require the socialization others talk about.
And that is FAR more difficult to teach or learn than science. I wonder if I ever will learn this myself.
Agree and would like to expand. Success in engineering often requires mastery and control over the material. The same skills, if applied to humans, will make others consider him arrogant or self-important. Negative experiences with other youth his age can cause him to withdraw further into technology.
When he realizes later in life that there is more to life than control of the material he will have to go through a lengthy, painful period discovering and reversing the assumptions he made early in life.
Better to expose him to situations that he has little or no control over the outcome of, especially without the help of others. It is key that he is comfortable in these situations (ie, most of life) so that when he enters them he can differentiate between them and scientific problems, and does not feel the compulsion to control them at the expense of others.
Your position is difficult. It is important that he be aware of his gift and be able to live it to its fullest, yet remain humble at the same time. It is important that his gift does not gradually turn into a private hell.
The best tool you can provide him is the desire to learn and grow outside of his discipline. Also to simply enjoy life. May I recommend this as one possible starting point for you to answer the question of what to teach him next.
there are not frequent drop-outs in the RF connection
the system does not temporarily suspend connectivity for one reason or another
the wireless data system is not built on top of one not intended for voice
alternatives to TCP are used instead
TCP was not designed to handle temporary dropouts characteristic of mobile data systems. When the subscriber is mobile, they are subject to temporary loss of packets through fading, multipath, and low signal strength. A big problem occurs when you are in marginal coverage areas. TCP's retransmission backs off by doubling the amount of time between retries. 0.5, 1, 2, 4, 8, 15, 30, 60, up to 120 seconds. If you happen to briefly come back into coverage, TCP does not know this, and happily continues to count down the retry timer. Then it fires, but you're out of coverage again, and it doubles the back-off time again, and you can be in great coverage, but no data will be sent until the next transmit opportunity. The backoff algorithm was intended to back off hosts to prevent collapse of the network due to congestion, but since it cannot sense the presence of the network, this "feature" causes a problem in mobile data networks.
To make matters worse, some networks give preference to voice callers and can clamp off the datastream in preference to them. Most carriers realize the impact of this, however, and provide a minimum channel allotment for data.
Data systems designed as overlays on voice systems (CDPD, for example) suffer the problem that voice can be deciphered by the human ear despite noise and dropouts, but data cannot. Therefore, a cellular footprint that is adequate for voice will be too small for data, and coverage holes will exist. Often these are inside of buildings where walls and leaded windows attenuate the signal.
The problem is mitigated by ensuring that signals are strong wherever there are users, but the cost and scarcity of frequencies and cell sites make this solution impractical.
Fixed systems do not generally have these problems because they don't move in and out of coverage and are less susceptible to multipath. Dumb mistakes, though, like installing the system in the woods in winter can cause failure in spring when the leaves grow on the trees and block the signal.
Alternatives to TCP. WAP and HDML employ their own reliable protocols over UDP because of problems with TCP on mobile wireless networks described above. The use of an alternative, T/TCP RFC 1644, has been proposed but it really only addresses transactions where all the data can fit into a single packet.
Even if a new protocol tweaked for wireless were designed to stand along with TCP and UDP in the transport layer, you face the challenge of getting it adopted as part of the stack of systems everywhere.
I would like to know Radio Shack's thoughts on this. Right now, it's probably driving lots of foot traffic into the store, and they are hardly mentioned. I wonder if they would step in and stop this nonsense if they became associated with this fiasco.
Slashdot Mirror
If these guys can crush cans with 3000 joules, think of what ten million joules can do.
I want to see the "after" pictures of a Yugo wrapped with a few turns of copper pipe in a lightning storm.
I used to have a Mac SE at work with a hard drive that would not spin up at powerup. I would hold it in the air with one hand, and whack it really hard on an edge to spin the whole Mac. The momentum differential would cause the platters to break free and spin up.
;-)
Another colleague's monitor would occasionally go on the fritz, and a good whack on the side would shape it up.
(Let me add to those about to reply that abusing machines are not good for their longevity, these were pretty much shot anyhow, and we all wanted new machines.)
This technique only occasionally worked with software.
Is 1900-1949 really better than past 50 years? The jury is still out, so to speak, as evidenced by the number of US executions since 1930.
Looks like between 1930 and 1949 we were going hog-wild on executions. Average nearly 150 a year. Lots of people whacking each other. Nothing better to do.
But then TV came along. By 1968 people found watching Star Trek and Green Acres and Mutual of Omaha's Wild Kingdom much more amusing than whacking each other. No executions for capital crimes between 1968 and 1976.
Then Disco came in 1977 but only a few people whacked each other over it. It wasn't until the advent of 100+ channel cable in 1984 and the crappy shows that came with it that people started losing interest in the tube.
The Internet has really fouled things up. In the last five years more people have been executed than in the entire period from 1962 to 1994. Probably from people whacking each other while waiting for their files to download. Have you ever heard "You've Got Mail!" played backwards?
I'm hoping that ubiquitous broadband will bring television to the Internet and reverse this trend.
But eventually I learned that I could slow down and not announce every answer in an arrogant fashion, and could let others participate.
That's the point. There's no need to take everyone else's advice and point him away from his gift. You just need to make him AWARE that he needs to do it with grace and humility. That lesson will automatically require the socialization others talk about.
And that is FAR more difficult to teach or learn than science. I wonder if I ever will learn this myself.
Agree and would like to expand. Success in engineering often requires mastery and control over the material. The same skills, if applied to humans, will make others consider him arrogant or self-important. Negative experiences with other youth his age can cause him to withdraw further into technology.
When he realizes later in life that there is more to life than control of the material he will have to go through a lengthy, painful period discovering and reversing the assumptions he made early in life.
Better to expose him to situations that he has little or no control over the outcome of, especially without the help of others. It is key that he is comfortable in these situations (ie, most of life) so that when he enters them he can differentiate between them and scientific problems, and does not feel the compulsion to control them at the expense of others.
Your position is difficult. It is important that he be aware of his gift and be able to live it to its fullest, yet remain humble at the same time. It is important that his gift does not gradually turn into a private hell.
The best tool you can provide him is the desire to learn and grow outside of his discipline. Also to simply enjoy life. May I recommend this as one possible starting point for you to answer the question of what to teach him next.
there are not frequent drop-outs in the RF connection
the system does not temporarily suspend connectivity for one reason or another
the wireless data system is not built on top of one not intended for voice
alternatives to TCP are used instead
TCP was not designed to handle temporary dropouts characteristic of mobile data systems. When the subscriber is mobile, they are subject to temporary loss of packets through fading, multipath, and low signal strength. A big problem occurs when you are in marginal coverage areas. TCP's retransmission backs off by doubling the amount of time between retries. 0.5, 1, 2, 4, 8, 15, 30, 60, up to 120 seconds. If you happen to briefly come back into coverage, TCP does not know this, and happily continues to count down the retry timer. Then it fires, but you're out of coverage again, and it doubles the back-off time again, and you can be in great coverage, but no data will be sent until the next transmit opportunity. The backoff algorithm was intended to back off hosts to prevent collapse of the network due to congestion, but since it cannot sense the presence of the network, this "feature" causes a problem in mobile data networks.
To make matters worse, some networks give preference to voice callers and can clamp off the datastream in preference to them. Most carriers realize the impact of this, however, and provide a minimum channel allotment for data.
Data systems designed as overlays on voice systems (CDPD, for example) suffer the problem that voice can be deciphered by the human ear despite noise and dropouts, but data cannot. Therefore, a cellular footprint that is adequate for voice will be too small for data, and coverage holes will exist. Often these are inside of buildings where walls and leaded windows attenuate the signal.
The problem is mitigated by ensuring that signals are strong wherever there are users, but the cost and scarcity of frequencies and cell sites make this solution impractical.
Fixed systems do not generally have these problems because they don't move in and out of coverage and are less susceptible to multipath. Dumb mistakes, though, like installing the system in the woods in winter can cause failure in spring when the leaves grow on the trees and block the signal.
Alternatives to TCP. WAP and HDML employ their own reliable protocols over UDP because of problems with TCP on mobile wireless networks described above. The use of an alternative, T/TCP RFC 1644, has been proposed but it really only addresses transactions where all the data can fit into a single packet.
Even if a new protocol tweaked for wireless were designed to stand along with TCP and UDP in the transport layer, you face the challenge of getting it adopted as part of the stack of systems everywhere.
I would like to know Radio Shack's thoughts on this. Right now, it's probably driving lots of foot traffic into the store, and they are hardly mentioned. I wonder if they would step in and stop this nonsense if they became associated with this fiasco.