"NASA, the suit-sat has been deployed and is now 500 meters away. It's an interesting looking satellite, with the arms waving about as the suit tumbles.
"Um, where's Commander Jones? Anyone seen him around?"
I've been following this guy's progress for more than a year now - sometime before he had the final schematics finished, and well before he actually started building anything.
This is the uber-geekiest project ever and I'm quite dismayed by the number of posts that are saying, effectively "So what? He could've bought a better computer off the shelf!".
Bah! To all you naysayers. This man deserves a Hacker-of-the-year award for seeing this through.
I've done one 22 day through hike in the CA Sierras, all without technology.
I'll bet you did it without electronics, but not without technology. You probably used a qualofill (sp?) sleeping bag and a ripstop nylon backpack on an aluminum pack frame and some freeze-dried food.
Make the same trip with a couple of wool blankets, a sack full of dried corn and forage for food on the trail (not that the USFS would appreciate that last part). That would be leaving technology behind.
[Disclaimer: you've still done more than I've got guts to try.]
It may be easy to opt out of a system, but what happens when stores decide (on their own) that the front door won't open unless the customer is carrying the proper ID?
Yeah, you can opt out, but suddenly everyone else opts out of doing business with you. (Sounds like the springboard for an "In Soviet Russia..." joke.)
I believe it's called "The Last One's Law of Program Generators": "A program generator generates programs that are more buggy than the program generator."
I disagree. To co-opt your analogy, asserts are more like the walk-around you do on your car before you get in to drive away. (Er, you did read the owner's manual for your car, didn't you?) e.g. assert(CarStillHasFourWheels); asser t(HoodIsLatchedDown);
These are assumptions that the program, once it is debugged, should be able to rely upon. They check that the program in internally consistent. However, it pays during debugging to have the program test those assumptions. It could just be that what you assumed to be true, isn't.
When an assumption proves to be wrong (the assert fires) the program stops and tells you where the fault was found, lets you bring up a debugger, etc.
Checks are a different thing from asserts. Checks should, once the program is released, keep the program from processing corrupt/illegal data, when such data might be expected (like input from an operator). If your program is (truely) internally consistent, then only the inputs (and status of output operations) should need to be checked for the program to run.
You never turn off checks in production code, but at some point you can take off the training wheels (assertions).
And before anyone can jump on me about assuming anything while programming, take a look at your own code. Unless you test every freakin' index and/or pointer every freakin' time you use it, you are making assumptions on almost every line (at least, with C/C++ code).
They have some values in common, but TLE's are different, and are used more often for satellite tracking.
Yeah, you might use a TLE to target a satellite, but if you're sophisticated enough to shoot down a satellite, you'll have the resources to construct your own TLE's from observational data.
Your chief weapon is surprise...surprise and fear...fear and surprise.... Your two weapons are fear and surprise...and ruthless efficiency.... Your *three* weapons are fear, surprise, and ruthless efficiency...and an almost fanatical devotion to the penguin.... Your *four*...no... *Amongst* your weapons.... Amongst your weaponry...are such elements as fear, surprise....
I haven't yet been able to get my wife to distinguish between Windows and the internet. When something goes wrong, all she knows is that "the internet isn't coming up".
I can't believe the negative opinions flying around here. Maybe if I give a basic outline of the plotline of this episode we can work up some enthusiasm:
1. Deanna Troi 2. T'Pol 3. Decontaminating gel 4. (There is no ???) 5. Sell realtime streaming video access 6. Profit!
Hard drives use a servo track to position the heads for reading and writing.
In ancient days, one surface out of a whole stack of platters would be used to hold the servo track for all the platters (a "dedicated servo"). So reading on all heads might have been feasible then.
But modern drives (ever since around 1989 or so) now interleave the servo track with the data on each surface (an "embedded servo"). This allows the positioning to be much more precise for each surface, but you can no longer depend on the track on one surface aligning with the track on another surface.
In fact, now that I think of it, I don't think that tracks even start at the same rotational position on the different surfaces. I remember writing code to switch heads on the fly while writing servo tracks. That would cause sector zero of each track to start at a different place.
Slashdot Mirror
I'm putting my entire neighborhood on E-Bay.
Does that help?
I can think of few problems that would be more interesting, and motivating, than falling through the air wondering why your parachute won't open.
And think of all the exercise you'd get flapping your arms for that last thousand feet or so!
"NASA, the suit-sat has been deployed and is now 500 meters away. It's an interesting looking satellite, with the arms waving about as the suit tumbles.
"Um, where's Commander Jones? Anyone seen him around?"
You finally made it to the front page of /.
About time too.
I've been following this guy's progress for more than a year now - sometime before he had the final schematics finished, and well before he actually started building anything.
This is the uber-geekiest project ever and I'm quite dismayed by the number of posts that are saying, effectively "So what? He could've bought a better computer off the shelf!".
Bah! To all you naysayers. This man deserves a Hacker-of-the-year award for seeing this through.
My guess is it this guy. Seems to have the same personality (13 yr old fanboy).
Make the same trip with a couple of wool blankets, a sack full of dried corn and forage for food on the trail (not that the USFS would appreciate that last part). That would be leaving technology behind.
[Disclaimer: you've still done more than I've got guts to try.]
OK, so we know what port she uses for internet access.
In Civil Law, or even the french Criminal law, Restarting Subsystem Error Not able to start Message server Server will shutdown.
You are saying that the judicial system needs a complete reboot? Most insightful.
But it would be cool when your eyes turned silver and you gained super-psychic powers when you actually hit the termination shock.
The parent is rated "funny".
Am I the only one that thinks that any format that Sony agrees to will have "screw the consumer" as one of the chief design requirements?
</drool>
It may be easy to opt out of a system, but what happens when stores decide (on their own) that the front door won't open unless the customer is carrying the proper ID?
Yeah, you can opt out, but suddenly everyone else opts out of doing business with you. (Sounds like the springboard for an "In Soviet Russia..." joke.)
I'm done with the internet. My needs are far beyond what can be done with int's.
I'm waiting for the floaternet.
I believe it's called "The Last One's Law of Program Generators":
"A program generator generates programs that are more buggy than the program generator."
I disagree. To co-opt your analogy, asserts are more like the walk-around you do on your car before you get in to drive away. (Er, you did read the owner's manual for your car, didn't you?)r t(HoodIsLatchedDown);
e.g.
assert(CarStillHasFourWheels);
asse
These are assumptions that the program, once it is debugged, should be able to rely upon. They check that the program in internally consistent. However, it pays during debugging to have the program test those assumptions. It could just be that what you assumed to be true, isn't.
When an assumption proves to be wrong (the assert fires) the program stops and tells you where the fault was found, lets you bring up a debugger, etc.
Checks are a different thing from asserts. Checks should, once the program is released, keep the program from processing corrupt/illegal data, when such data might be expected (like input from an operator). If your program is (truely) internally consistent, then only the inputs (and status of output operations) should need to be checked for the program to run.
You never turn off checks in production code, but at some point you can take off the training wheels (assertions).
And before anyone can jump on me about assuming anything while programming, take a look at your own code. Unless you test every freakin' index and/or pointer every freakin' time you use it, you are making assumptions on almost every line (at least, with C/C++ code).
But the number one quote would be:
"If we just stand perfectly still he won't... AAAAAAHH!"
That would give the T-Rex an advantage, because his prey would be rolling on the floor laughing.
Not keplarian - TLE (NORAD 2-line elements).
They have some values in common, but TLE's are different, and are used more often for satellite tracking.
Yeah, you might use a TLE to target a satellite, but if you're sophisticated enough to shoot down a satellite, you'll have the resources to construct your own TLE's from observational data.
Slip your badge into the teacher's pocket, then. That'll raise a few eyebrows.
Your chief weapon is surprise...surprise and fear...fear and surprise.... Your two weapons are fear and surprise...and ruthless efficiency.... Your *three* weapons are fear, surprise, and ruthless efficiency...and an almost fanatical devotion to the penguin.... Your *four*...no... *Amongst* your weapons.... Amongst your weaponry...are such elements as fear, surprise....
Tell me about it.
I haven't yet been able to get my wife to distinguish between Windows and the internet. When something goes wrong, all she knows is that "the internet isn't coming up".
It's been done in TOS. The episode was called "A Piece of the Action". :)
I can't believe the negative opinions flying around here. Maybe if I give a basic outline of the plotline of this episode we can work up some enthusiasm:
1. Deanna Troi
2. T'Pol
3. Decontaminating gel
4. (There is no ???)
5. Sell realtime streaming video access
6. Profit!
So... he likes to boldly goes where no man has gone before?
No, you're thinking of Michael Jackson.
No, no, no!
This is a case for "the blue screen of death" if ever I saw one!
You'd be right about the misalignment.
Hard drives use a servo track to position the heads for reading and writing.
In ancient days, one surface out of a whole stack of platters would be used to hold the servo track for all the platters (a "dedicated servo"). So reading on all heads might have been feasible then.
But modern drives (ever since around 1989 or so) now interleave the servo track with the data on each surface (an "embedded servo"). This allows the positioning to be much more precise for each surface, but you can no longer depend on the track on one surface aligning with the track on another surface.
In fact, now that I think of it, I don't think that tracks even start at the same rotational position on the different surfaces. I remember writing code to switch heads on the fly while writing servo tracks. That would cause sector zero of each track to start at a different place.