Immediately after the release you can see the camera view change from "swaying" to "tumbling", which would imply the main box is also falling freely.
3982 posts • joined 8 Oct 2009
Some mechanism with a tensioned spring that can only pull back the release pin once the balloon bursts, most easily implemented, I think, with a cord running from the spring to the balloon.
And the plane hanging nose-down under the launch box will probably make it drop away faster, decreasing the possibility of a collision (as I think has happened, judging from the shape of the hole in the port wing).
nor a brain scientist, but I don't see wind as much of a problem. You're launching from a balloon, which will be drifting with the wind; the plane itself has no propulsion and its (horizontal) speed respective to the surrounding air will not be vastly different from lower altitudes. Only air density and thus air resistance will be a factor.
Of course, if Chuck did indeed perform a steep dive from the release height to somewhere between 5000 and 10000 ft (165..330 double decker buses) his craft will have reached an appreciable aerial velocity which it would have retained initially when pulling out, but given the plane's aerodynamic profile and its weight it will have slowed down rather quickly and settled at a thrown-paper-plane airspeed and flight attitude.
is maybe a bit bigger and heavier than the keyfob/spypen cams, (133g total, with the camera at 29g), but it has the advantage of having the actual recorder separate from the camera, which would help with weight placement and the keeping warm of the recorder battery.
HSDPA/HSUPA, or even just UMTS/3G is just the trick to connect some local network to the Great Wide Internet when there's no suitable cabling around. These,and their predecessors have bene around for a good ten years, and are pretty ubiquitous nowadays.
But if you can't grok those newfangled technologies, just wait for the bus that trails a spool of telephone wire. Alternatively, trolleybuses may have Powernet installed.
A liter of water (at 277K and 1*10^6Pa) is indeed 1kg, but try varying the temperature or ambient pressure a bit and you'll be sufficiently off to throw any semblance of precision out the window. And precision counts in definitions. So anything that doesn't rely on other measurements is to be preferred: [large_number of stable_atoms] is quite a bit better than [amount of fluid that goes in a container of some size at this temperature and that pressure]
AWTT Assemble With Tinker Toys
BOD Beat on Drum
BRO BRanch and Overheat
BWABL Bells, Whistles and Blinking Lights
BWOP BeWilder Operator
CAF Convert Ascii to Farsic
CRN Convert to Roman Numerals
DSI Do Something Interesting
DSR Detonate Status Register
DSTD Do Something Totally Different
DSUIT Do Something Utterly, Indescribably Terrible
DTC Destroy This Command
ENF Emit Noxious Fumes
ENG Enable Gravity
EOI Execute Operator Immediate [a fast version of another instruction]
EP Execute Programmer
EPI Execute Programmer Immediate
FLD FLing Disc
HCF Halt and Catch Fire
IDC Initiate Destruct Command
LTS Loop Till Smokes
LUM LUbricate Memory
RIC Rotate Illogical thru Carry
RLI Rotate Left Indefinitely
ROD ROtate Diagonally
RRC Rotate Random thru Carry
SPA Sliding Point Arithmetic
Umm, the Agilent spin-off was ten years ago. Since then HP stopped inventing however much their slogan tries to convince you otherwise, with the possible exception of inventing more ways to turn pigments into money.
Getting EDS, and now Apoteker, on board is just par for the course.
But most of the systems I see today don't use pods. Usually there's a slot into which the checkout clerk can slip bills, and apparently those travel through the tubes just like that. With pods you would have to modify the tubes in a way that the entire pod could be diverted without jamming, but loose bills are much less restrictive that way.
in this case the printed chits, you can always do a manual recount and compare its result with what the counting machine is programmed to spit out.
Whether or not a manual count can be seen as sufficiently precise and fraud-free, at least it's a process that people know and have kindof trusted.
should be to keep those systems *OFF* the Internet. Period. Oh, it's convenient, yes. Security is inconvenient, *good* security is fscking inconvenient, and so a decision to do something like making SCADA systems accessible from anywhere "because it's convenient" should be shot down because of those three words alone.
A proposal to run such a system on Windows should be chucked out too. Including the proposer, and preferrably from the board-room floor of the main office.
"It is the only MP3 player available which has a decent sized hdd."
Well, the Creative Zen series has a few: 20, 30 and even 60G. I'm sure there are others.
Anyway, given the way it'll be used I'd rather have a smaller flash-based unit than a 40G rotating disk. And now with 32G (and even 64G) solid state media players there's no reason at all, other than aesthetics/UI, in going for an iPod, especially since most of the others appear as a mass storage device to their host, and can be easily filled without some bloaty proprietary tool. I didn't look too closely into it, but I suppose there are also players that have an SD slot. With such a player and carrying a few of those cards you could carry way more than 60G in less space, and with longer playing times too.
Review and delete buttons disabled, no frozen image in the display after you've taken a pic, no "best shot selector" option, 36 pics max (or 12 for the real pro) after which the camera simply goes into standby for a minute or so, and maybe 4 frames/sec max in motordrive mode.
aren't inkjets but use a dye transfer process, so no smudging, waiting for the ink to dry and clogged printheads. The dyes sit on a film that gets changed with the print paper. But yes, building an instant photocam around such a printer (the camera bit would be negligible, sizewise) might have been a better idea.
has a line of thumb drives with a titanium shell. I own two (a 512M and a 16G; the smaller one is noticeably larger), and stood on them (for demo purposes) several times each. Not a scratch, and no failures either. I'm fairly certain you could drop them off the top of a highrise building onto pavement, or drop a brick on them and they'd survive,
All hardware sucks, all software sucks. There's nothing that's non-sucky, with just a small amount of stuff that has a bearable suck-level. And with greater integration of functions the suckiness increases exponentially.
I believe the average rotary desk phone to be the last of the non-sucky telecoms devices (that's obviously excluding telco cockups).
No sweet spots? You're talking utter bollocks. Any tuned antenna's performance is affected by its loading, and the factor by which a load detunes the antenna depends its type (capacitive, resistive or inductive; in real-world situations a combination of all three) and on the position of said load with regard to the antenna feed point.
do this for three years, snap pics while all of you are about, and simultaneously record where you are. Still not a problem?
It's funny how people still keep saying "well, I could easily snoop open WiFi too, what's the big deal?". But that's just part of what Google was doing. It's the agglomeration of all the data, including GPS and pics, the googlomobiles are collecting that pushes it way beyond simple eavesdropping. It's also not just some random internet user collecting all that stuff, it's the largest adbroker around. Who has a serious commercial interest in knowing as much as it can about you, and not limited to your online behaviour.
>>The patent is odd, but we only currently have the word of some people who are suing Google on that one. Hardly unbiased information is it?<<
Aaaaaaand the text of the patent, linked to from one of the earlier articles in this series. Which is full of technical guff of what it does, and how, but nothing about what it doesn't do. Now, it's fair to expect the patent not to mention that this stuff doesn't do the dishes or feeds the cat, but it also doesn't mention packet payloads being discarded.
"The article you link to contains NO INFORMATION AT ALL about the patent, only what some lawyers who are suing google say"
The article Andy, and I, linked to contains the link to THE PATENT APPLICATION ITSELF, for all to read and dissect to the last comma. Do that, then tell us where it says they WON'T retain any data beyond SSID and MAC. I did, and it's totally silent on that point. And while Google may have been not evil at some point in the past, I don't trust them anymore.
Also, some Google spokesman may proclaim that the patent has no relation to the collection as it was done, but a) they initially denied having done so, and b) spokesmen output rarely has any bearing on what's actually happening.
critical posts are downvoted, and a common theme seems to be "I could do this too without problem, let Google have their way". Also, that handing the data over to privacy regulators is somehow worse than letting Google dispose of it (how would you know that they wiped *every* last copy anyway?). Maybe in the UK it would be irrelevant, the appropriate authorities apparently being a bunch of spineless, toothless penpushers, but their German (and EU!) counterparts pack quite a bit more clout. And why privacy regulators and not some justice department straightaway? It's not clear what Google have collected, their story morphing as stuff gets uncovered more and more. It may well be that their collecting wifi data, even unencrypted, is somehow illegal in itself already, but let's leave the legal stuff until it's been established *WHAT* exactly has been snooped.
In your hurry to defend your favourite adbroker, you sure picked the wrong person to address your ranting to. Take a good dose of valium and stay away from your computer for the next week or so.
Next step: go read the patent application linked to in http://www.theregister.co.uk/2010/06/03/google_wardriving_patent/ , and tell us where it explicitely says that they *WON'T* retain and/or analyse packet data beyond SSID and MAC
Biting the hand that feeds IT © 1998–2019