There's a famous experiment where a frog eye was removed and reattached inverted 180 degrees, and the frog never compensated (it would shoot it's tongue out the wrong direction when trying to eat flies, and had to be fed by hand for the rest of it's life) (vision scientist types - do you know the name of the guy who did the experiment?)
I'll be damned if I remember anything more than these few details about it, but I recall reading about an experiment where a college kid was given glasses that reversed his vision vertically.. Sky was down, ground was up. Naturally, he had a hard time for a few weeks, and had to have somebody lead him around and such, but his brain eventually did reconfigure to the changed situation and he was able to walk and function normally. Then he took off the glasses and was screwed up for another few weeks until it went and reconfigured back to normal.
Could there be some kind of difference between a frog's brain and a human brain, in its ability to change itself to changed inputs?
In the movie piracy scene, generally films are released as either VCD or SVCD format. These are in BIN/CUE format, ready for burning. The BIN/CUE's are then RAR'd to take advantage of RAR's splitting capabilities and integrity checks. Then the RAR's are distributed.
In other words, this is normal. What's annoying is when somebody hosts a torrent that is the RAR files and not the uncompressed BIN/CUE's. The pirating group never goes so far as to release the thing onto torrents or such. They're sending files between ftp sites, usually on hacked systems or other systems with big fat pipes and lots of storage. They use tools that let them FTP between sites (similar to FSP), and sometimes from multiple sites (this is where having many RAR files comes in handy) to saturate bandwidth on the receiving sides.
Sometimes this is even automated. Those tools are pretty nifty, actually. You feed it a list of sites and a list of files. It FTPs the whole thing to the first site, then uses FSP to copy it to the second site (much faster than directly FTP'ing it there), then uses FSP to send it to the third site from both of the first two sites simultaneously, and so on. By the time it's done, 20-30 sites can have the thing, and it didn't take any longer than it would have took to send to 3 or 4 of them directly, thanks to the FSP using direct connections between sites and the RAR's being split so that it can send from multiple sites at once. More complicated tools can improve on this by transferring to many sites at once from many other sites and maximizing bandwidth on all of them.
In any case, these sites then get distributed to others via IRC, and people download the thing from these sites, and put it onto their 0-day hookups. This goes on for a bit, and then it eventually filters down to people who might actually watch the movie. Up until now, it's just people trading files because they like trading files fast. They might never actually use those files. Anyway, once it makes it onto sites where people will actually download the thing and thus watch it, it often goes from there onto the P2P networks. Some guy makes a Torrent out of it, somebody sticks it onto Usenet, etc, etc. Often it'll hit newsgroups before it gets made into a torrent somewhere. But by the time it's a torrent, you're at least 4-5 generations away from the original pirated site transfers.
This is so commonplace that tools exist to deal with the multiple layers of formatting. I suggest getting a copy of VCDGear (search google). It can convert RAR'd BIN/CUE's directly into MPG files for viewing. One step, instead of two or three.
Nothing scales forever. In the very specific realm of passwords and hashes generated from those passwords, you have a huge scaling problem.
Take a simple example: a-z,0-9, 8 chars, MD5.
That's 36^8, or slightly more than 2.8 trillion passwords. Storage for those would be 2.25 × 10^13 bytes, or 22 and a half terrabytes. Now, storing the MD5 password along with them is another 16 bytes, so we need to triple that, and thus we have 67.5 terrabytes of storage needed. Now, what's the size of the index on this thing? It's going to be pretty big, I'm sure. Just searching the index is probably going to require an index itself.
Now, realize that you're going to be searching for the MD5 here, not the password. So sorting it is a bit of a PITA too, and could take a hell of a long time. Ever try to run a quicksort on a 3 trillion item array?
And all that only covers lowercase and digits, up to 8 characters. Yes, your data lookup could be made fast, if you have one hell of a big system to stick the whole thing on, and a few computers to handle the thing in sections. Big databases are not new, but when you start talking about fully populated databases created from arbitrary mathematical functions, you quickly get into the realm of the obnoxiously insanely big database. It's not practical, and it certainly isn't very fast unless you throw a ton of money at it.
Whereas this method trades off space for cpu time, by the reducing function thing. Reducing functions are not new, what's new here is to use a changing reducing function, which is kinda nifty. It has its limitations as well, but the big evil database has some pretty major ones too.
This "metadata" is actually called an "NTFS stream" and has been around since at least NT4.
If you move the file around the NTFS drive, or from one NTFS drive to another, then yes, the metadata goes with it. If you move it to a FAT volume though, the metadata is lost forever. Not a huge deal as NTFS is getting more and more users nowadays.
XP uses these metadata streams to some degree, actually. Some of the things in the properties page for a file are actually NTFS streams.
Longhorn will make more extensive use of them, I'm certain.
I agree that using constants, even if it's just #define's, is a good thing. But the whole concept of firing somebody because they didn't is silly. That sort of stuff rarely gets noticed. Much more critical bugs often go by unchecked, and you're expecting people to not only notice but fire people over something like not using constants? Come on, pull the other one, it's got bells on.
They store all this stuff in a table, and now getting passwords to most systems is nothing more than a quick table lookup.
As should be obvious, a table lookup through a few terabytes of data isn't all that quick.
That's what this is all about. Rainbow crack, which is what the original posts site is using, is a faster way to look things up in tables. So when they say it works for anything a-z,0-9, then they mean that they have precalculated all those passwords (up to 8 chars) and what you are in fact doing by submitting this request is essentially a table lookup over 47 gigs of data.
The point is that efficent table searching for this sort of thing is relatively new. There was a/. article about this new table lookup method some time back.
Are you serious? The guy who wrote the original application quit *ages* ago. If everybody got fired for making "magic numbers" in the applications, there'd be no freakin' applications! There'd be no programmers, no software, nothing.
You show me an application without magic numbers, and I'll show you a coder who's out of work and bored and coding something without a deadline. I'll also show you a program that few, if any, people actually use.
It's just that countries get a range of those two characters. While the US has 1*, 4*, and 5*, and Canada has 2*, Mexico has 3A-3W and Costa Rica has 3X-37.
The whole first three characters (known as the WMI) get assigned by the SAE, according to whatever-the-hell-system they feel like using. They just happen to assign it certain ways.
Google for "VIN Country Codes" for the complete list.
The problem is that there's a lot of countries that we don't import vehicles from that have country codes assigned. They don't really need them. Take the whole range of F* codes:
FA-FE Ghana FF-FK Nigeria FF-FK Madagascar FL-F0 not assigned GA-G0 not assigned HA-H0 not assigned
While there's the G and H codes to steal from essentially nobody, the F codes are pretty useless to those countries too, as they don't make cars for the US. See, the codes only really apply to cars here in the US, other countries can do whatever the hell it is that they want to do. So we could gank the whole F series without much problem.
I misphrased that. By "particular car" I meant like "Ford" or "Chrysler" or "Toyota". While a manufacturer than use the 3rd digit to denote the specific car type (like "Impala" or "Taurus" or "WhateverPieceOfShitToyotaMakes"), few do that. Most use a letter in the serial number instead.
The VIN includes a year code (10th character from the left) that denotes the year the car was made. However, this loops after 30 years (they left out potentially confusing chars in the yearcode, like I, O, U, Q, Z, and zero).
But in 2011, the year loops. That's the only problem, really.
If they produce more than a million units of any particular car in a year, they use letters in here. Sometimes they use letters anyway, to denote different car types and such. The last six characters can be essentially anything 0-Z, it leaves it up to the manufacturer.
The problem is not that duplicates will occur, it's that the year number will repeat starting in 2011. The 7th character (from the right) denotes the year, and anybody can see, this means that it loops over every 36 years. Not particularly good planning, methinks.
One simple solution is to recommend both use of all 36 chars in the serial number and to denote the first character of that number to be a character never used there before by most manufacting companies. In most cases, car companies rarely use anything above A or B for the first character of the serial, so for some this will be easy to work around. For others, it may be more difficult as they'll have to change their own internal coding scheme for the serial.
Most probable change is that the characters for countries (first character) will be stolen, like happened with 4 and 5 for US cars.
The town names are Brockway, Ogdenville, and North Haverbrook. I believe that they actually ripped them off from an old Twilight Zone episode, although I can't find any info on which episode that was.
The point of having multiple spam bots sending your crap out is to increase the amount of crap you can send. If they are going around setting up SMTP relay bots, then whole exercise is rather pointless, as the bandwidth is still all being shuffled through that relay.
Look at it like this: With two computers, I've got twice the bandwidth as one computer, and so can send twice the spam. But with one computer relaying through the other, the bandwidth of that computer is now irrelevant, everything has to go through the relay. Instead of having a relay, it's more efficent to just send the spam from the relay.
Relaying doesn't fix the problem for spammers. And your idea about originating ports is useless, because they're blocking based on destination port, not originating port. Nobody gives a shit about originating port, for almost any protocol. If you want to send spam to ISP's, then you have to connect to SMTP servers to send your spam to, and you have to connect on the port they use, which is port 25 by convention. You cannot work around that fact.
No, sorry, I was mistaken. What ml_ipod is doing is saving it's smart playlist rules into a separate file on the iPod, which the iPod itself does not use. Then it builds normal playlists based on this file. This is not a true smart playlist in the iPod sense.
No, in point of fact, ml_ipod does not support real smart playlists.
A smart playlist, with regards to the iPod, is a playlist that has the definition for that playlist embedded in the iPod's database itself. For 1st and 2nd generation iPods, this is basically unnecessary, and the iPod ignores them. For 3rd generation and up iPods, however, the iPod rebuilds the playlist, in real time, based on the rules for that playlist.
So if you have a smart playlist that has a rule of "last played is not in the last 2 weeks", and then go play a song in that playlist, then when you leave and come back to that playlist later, it will have changed *without* syncing it to a computer.
I have examined the ml_ipod code, and it does not support smart playlists. It can create normal playlists using a rules based scheme, but this is not the same thing.
And On-The-Go Playlist support is easy. We have code to read and use this information off the iPod. However, foobar 2000 is a bit of a different kind of player, and so at the moment it doesn't really make sense to read the OTGPlaylist off the thing and into foobar. Thoughts are being developed along those lines, and the smart playlist interface being built may be actually a playlist manager type of thing, which would likely support such a functionality.
Most of the iPod's data files have already been worked out to a great degree. Not everything, mind you, but most of it. All the important bits, anyway. It just takes a bit of searching around.
I wrote a set of C++ classes for dealing with the iPod's data files, and with the help of Aero, we've refined it to cover just about everything in a plug-in for foobar 2000 called foo_pod.
We're almost there with real, live updating, smart playlist support now (which no other third party iPod-capable app has yet, that I know of). Just a few minor things left to be done on the back end, and the interface sounds like it is coming along nicely.:)
There's very little an actual SDK could add at this point. When the iPod is connected to the computer, it just appears to be a hard drive to the computer. No special communication channels we can find at all.
First, considering the vast amount of code that was changed to ensure that nothing happened, the fact that nothing happened only show sthat somebody did their job correctly.
Second, a lot did, in fact, happen. A hell of a lot of code out there failed when rollover occurred. Nothing critical happened because that code was known to be critical and was thoroughly tested prior to the rollover.
Third, Russia and other countries are not full of fools, you know. They spent quite a lot doing Y2K related changes also. You're making unwarrented assumptions.
I grant you that the media frenzy was stupid, but that's the media. At one point I saw some media jack-off claiming that elevators would plummet to the ground, killing those trapped inside and causing major property damage and so forth. Let's be freakin' realistic. Nothing as silly as that would happen because embedded systems like that don't often depend on the frickin' date to work properly. The real risks were in financial software, for the most part. Stuff that did depend on date. And most of it was fixed before the problem happened.
Thus nothing happened because that was the desired outcome, and the reason we spent so much money in the first place. If something major had occurred, you'd have a real reason to bitch about the money that was spent, wouldn't you?
I wouldn't be surprised if that sort of thing exists, but they simply haven't documented it publically yet.
My guess is that they'll integrate it into the Google Toolbar at some point. Of course, this is a Windows/IE only thing, but the method it'll use can be found if/when that occurs. The method I posted before will work as an interim solution if needed by somebody.
Write a program that does http. Have it load up the gmail pages and parse them and such (exercise left to the reader) until you see a URL that looks like this: http://gmail.google.com/gmail?search=inbox& view=tl &start=0&init=1&zx=XXXXXXXXXXXXXX
With the "XXXXX" replaced by some form of key.
In the source of that page, you'll find a bit of text that looks like this:
D(["ds",1,0,0,0,0,0]
D is a javascript function, but frankly you don't care.. The first number after the "ds" (in this case, 1) is the number of unread mails you have in your inbox. Reload this from time to time and check that number. Simple as that.
1) gravity isn't constant, it is inversely proportional to distance.
This is true, but not very useful. Standing on the ground you are a good 4000 miles from the Earth's center of gravity. Jumping another few hundred miles away doesn't make enough of an impact to seriously mess up "back of the napkin" type calculations, like he was obviously using. He did say "Low Earth Orbit" which is somewhere between 100-500 miles up.
2) orbital speed isn't constant either. In geosynchronous orbits, an object orbits once every 24 hours.
True, but then he did say "low earth orbit". A geosync sat does move slower through space, true, but energy-wise, it's a hell of a lot further up too. LEO is between 100-500 miles or so, while geosync orbits are 22,000 miles up. In any case, his energy calculations are correct, in a back-of-the-napkin kind of way. It does take a hell of a lot of energy to get into orbit, and it's a big leap to go from a ballistic jump to actual orbital velocities.
This is one hell of an achievement, I grant you. But Mach 3 just ain't gonna friggin' cut it. It's not how high you go, it's how fast you go that really counts, with regard to getting into orbit.
Slashdot Mirror
There's a famous experiment where a frog eye was removed and reattached inverted 180 degrees, and the frog never compensated (it would shoot it's tongue out the wrong direction when trying to eat flies, and had to be fed by hand for the rest of it's life) (vision scientist types - do you know the name of the guy who did the experiment?)
I'll be damned if I remember anything more than these few details about it, but I recall reading about an experiment where a college kid was given glasses that reversed his vision vertically.. Sky was down, ground was up. Naturally, he had a hard time for a few weeks, and had to have somebody lead him around and such, but his brain eventually did reconfigure to the changed situation and he was able to walk and function normally. Then he took off the glasses and was screwed up for another few weeks until it went and reconfigured back to normal.
Could there be some kind of difference between a frog's brain and a human brain, in its ability to change itself to changed inputs?
In the movie piracy scene, generally films are released as either VCD or SVCD format. These are in BIN/CUE format, ready for burning. The BIN/CUE's are then RAR'd to take advantage of RAR's splitting capabilities and integrity checks. Then the RAR's are distributed.
In other words, this is normal. What's annoying is when somebody hosts a torrent that is the RAR files and not the uncompressed BIN/CUE's. The pirating group never goes so far as to release the thing onto torrents or such. They're sending files between ftp sites, usually on hacked systems or other systems with big fat pipes and lots of storage. They use tools that let them FTP between sites (similar to FSP), and sometimes from multiple sites (this is where having many RAR files comes in handy) to saturate bandwidth on the receiving sides.
Sometimes this is even automated. Those tools are pretty nifty, actually. You feed it a list of sites and a list of files. It FTPs the whole thing to the first site, then uses FSP to copy it to the second site (much faster than directly FTP'ing it there), then uses FSP to send it to the third site from both of the first two sites simultaneously, and so on. By the time it's done, 20-30 sites can have the thing, and it didn't take any longer than it would have took to send to 3 or 4 of them directly, thanks to the FSP using direct connections between sites and the RAR's being split so that it can send from multiple sites at once. More complicated tools can improve on this by transferring to many sites at once from many other sites and maximizing bandwidth on all of them.
In any case, these sites then get distributed to others via IRC, and people download the thing from these sites, and put it onto their 0-day hookups. This goes on for a bit, and then it eventually filters down to people who might actually watch the movie. Up until now, it's just people trading files because they like trading files fast. They might never actually use those files. Anyway, once it makes it onto sites where people will actually download the thing and thus watch it, it often goes from there onto the P2P networks. Some guy makes a Torrent out of it, somebody sticks it onto Usenet, etc, etc. Often it'll hit newsgroups before it gets made into a torrent somewhere. But by the time it's a torrent, you're at least 4-5 generations away from the original pirated site transfers.
This is so commonplace that tools exist to deal with the multiple layers of formatting. I suggest getting a copy of VCDGear (search google). It can convert RAR'd BIN/CUE's directly into MPG files for viewing. One step, instead of two or three.
Nothing scales forever. In the very specific realm of passwords and hashes generated from those passwords, you have a huge scaling problem.
Take a simple example: a-z,0-9, 8 chars, MD5.
That's 36^8, or slightly more than 2.8 trillion passwords. Storage for those would be 2.25 × 10^13 bytes, or 22 and a half terrabytes. Now, storing the MD5 password along with them is another 16 bytes, so we need to triple that, and thus we have 67.5 terrabytes of storage needed. Now, what's the size of the index on this thing? It's going to be pretty big, I'm sure. Just searching the index is probably going to require an index itself.
Now, realize that you're going to be searching for the MD5 here, not the password. So sorting it is a bit of a PITA too, and could take a hell of a long time. Ever try to run a quicksort on a 3 trillion item array?
And all that only covers lowercase and digits, up to 8 characters. Yes, your data lookup could be made fast, if you have one hell of a big system to stick the whole thing on, and a few computers to handle the thing in sections. Big databases are not new, but when you start talking about fully populated databases created from arbitrary mathematical functions, you quickly get into the realm of the obnoxiously insanely big database. It's not practical, and it certainly isn't very fast unless you throw a ton of money at it.
Whereas this method trades off space for cpu time, by the reducing function thing. Reducing functions are not new, what's new here is to use a changing reducing function, which is kinda nifty. It has its limitations as well, but the big evil database has some pretty major ones too.
This "metadata" is actually called an "NTFS stream" and has been around since at least NT4.
If you move the file around the NTFS drive, or from one NTFS drive to another, then yes, the metadata goes with it. If you move it to a FAT volume though, the metadata is lost forever. Not a huge deal as NTFS is getting more and more users nowadays.
XP uses these metadata streams to some degree, actually. Some of the things in the properties page for a file are actually NTFS streams.
Longhorn will make more extensive use of them, I'm certain.
I think you missed my point...
I agree that using constants, even if it's just #define's, is a good thing. But the whole concept of firing somebody because they didn't is silly. That sort of stuff rarely gets noticed. Much more critical bugs often go by unchecked, and you're expecting people to not only notice but fire people over something like not using constants? Come on, pull the other one, it's got bells on.
They store all this stuff in a table, and now getting passwords to most systems is nothing more than a quick table lookup.
/. article about this new table lookup method some time back.
As should be obvious, a table lookup through a few terabytes of data isn't all that quick.
That's what this is all about. Rainbow crack, which is what the original posts site is using, is a faster way to look things up in tables. So when they say it works for anything a-z,0-9, then they mean that they have precalculated all those passwords (up to 8 chars) and what you are in fact doing by submitting this request is essentially a table lookup over 47 gigs of data.
The point is that efficent table searching for this sort of thing is relatively new. There was a
Are you serious? The guy who wrote the original application quit *ages* ago. If everybody got fired for making "magic numbers" in the applications, there'd be no freakin' applications! There'd be no programmers, no software, nothing.
You show me an application without magic numbers, and I'll show you a coder who's out of work and bored and coding something without a deadline. I'll also show you a program that few, if any, people actually use.
Welcome to the real world, friend.
It's just that countries get a range of those two characters. While the US has 1*, 4*, and 5*, and Canada has 2*, Mexico has 3A-3W and Costa Rica has 3X-37.
The whole first three characters (known as the WMI) get assigned by the SAE, according to whatever-the-hell-system they feel like using. They just happen to assign it certain ways.
Google for "VIN Country Codes" for the complete list.
The problem is that there's a lot of countries that we don't import vehicles from that have country codes assigned. They don't really need them. Take the whole range of F* codes:
FA-FE Ghana
FF-FK Nigeria
FF-FK Madagascar
FL-F0 not assigned
GA-G0 not assigned
HA-H0 not assigned
While there's the G and H codes to steal from essentially nobody, the F codes are pretty useless to those countries too, as they don't make cars for the US. See, the codes only really apply to cars here in the US, other countries can do whatever the hell it is that they want to do. So we could gank the whole F series without much problem.
I misphrased that. By "particular car" I meant like "Ford" or "Chrysler" or "Toyota". While a manufacturer than use the 3rd digit to denote the specific car type (like "Impala" or "Taurus" or "WhateverPieceOfShitToyotaMakes"), few do that. Most use a letter in the serial number instead.
The VIN includes a year code (10th character from the left) that denotes the year the car was made. However, this loops after 30 years (they left out potentially confusing chars in the yearcode, like I, O, U, Q, Z, and zero).
But in 2011, the year loops. That's the only problem, really.
If they produce more than a million units of any particular car in a year, they use letters in here. Sometimes they use letters anyway, to denote different car types and such. The last six characters can be essentially anything 0-Z, it leaves it up to the manufacturer.
The problem is not that duplicates will occur, it's that the year number will repeat starting in 2011. The 7th character (from the right) denotes the year, and anybody can see, this means that it loops over every 36 years. Not particularly good planning, methinks.
One simple solution is to recommend both use of all 36 chars in the serial number and to denote the first character of that number to be a character never used there before by most manufacting companies. In most cases, car companies rarely use anything above A or B for the first character of the serial, so for some this will be easy to work around. For others, it may be more difficult as they'll have to change their own internal coding scheme for the serial.
Most probable change is that the characters for countries (first character) will be stolen, like happened with 4 and 5 for US cars.
The town names are Brockway, Ogdenville, and North Haverbrook. I believe that they actually ripped them off from an old Twilight Zone episode, although I can't find any info on which episode that was.
The point of having multiple spam bots sending your crap out is to increase the amount of crap you can send. If they are going around setting up SMTP relay bots, then whole exercise is rather pointless, as the bandwidth is still all being shuffled through that relay.
Look at it like this:
With two computers, I've got twice the bandwidth as one computer, and so can send twice the spam.
But with one computer relaying through the other, the bandwidth of that computer is now irrelevant, everything has to go through the relay. Instead of having a relay, it's more efficent to just send the spam from the relay.
Relaying doesn't fix the problem for spammers. And your idea about originating ports is useless, because they're blocking based on destination port, not originating port. Nobody gives a shit about originating port, for almost any protocol. If you want to send spam to ISP's, then you have to connect to SMTP servers to send your spam to, and you have to connect on the port they use, which is port 25 by convention. You cannot work around that fact.
No, sorry, I was mistaken. What ml_ipod is doing is saving it's smart playlist rules into a separate file on the iPod, which the iPod itself does not use. Then it builds normal playlists based on this file. This is not a true smart playlist in the iPod sense.
I take that back. They appear to have added some actual smart playlist support in the last couple of weeks. My apologies.
No, in point of fact, ml_ipod does not support real smart playlists.
A smart playlist, with regards to the iPod, is a playlist that has the definition for that playlist embedded in the iPod's database itself. For 1st and 2nd generation iPods, this is basically unnecessary, and the iPod ignores them. For 3rd generation and up iPods, however, the iPod rebuilds the playlist, in real time, based on the rules for that playlist.
So if you have a smart playlist that has a rule of "last played is not in the last 2 weeks", and then go play a song in that playlist, then when you leave and come back to that playlist later, it will have changed *without* syncing it to a computer.
I have examined the ml_ipod code, and it does not support smart playlists. It can create normal playlists using a rules based scheme, but this is not the same thing.
And On-The-Go Playlist support is easy. We have code to read and use this information off the iPod. However, foobar 2000 is a bit of a different kind of player, and so at the moment it doesn't really make sense to read the OTGPlaylist off the thing and into foobar. Thoughts are being developed along those lines, and the smart playlist interface being built may be actually a playlist manager type of thing, which would likely support such a functionality.
Most of the iPod's data files have already been worked out to a great degree. Not everything, mind you, but most of it. All the important bits, anyway. It just takes a bit of searching around.
:)
I wrote a set of C++ classes for dealing with the iPod's data files, and with the help of Aero, we've refined it to cover just about everything in a plug-in for foobar 2000 called foo_pod.
We're almost there with real, live updating, smart playlist support now (which no other third party iPod-capable app has yet, that I know of). Just a few minor things left to be done on the back end, and the interface sounds like it is coming along nicely.
There's very little an actual SDK could add at this point. When the iPod is connected to the computer, it just appears to be a hard drive to the computer. No special communication channels we can find at all.
The only problem with that is my brain can't process the flash advertising that fast. It's slooooooow.
First, considering the vast amount of code that was changed to ensure that nothing happened, the fact that nothing happened only show sthat somebody did their job correctly.
Second, a lot did, in fact, happen. A hell of a lot of code out there failed when rollover occurred. Nothing critical happened because that code was known to be critical and was thoroughly tested prior to the rollover.
Third, Russia and other countries are not full of fools, you know. They spent quite a lot doing Y2K related changes also. You're making unwarrented assumptions.
I grant you that the media frenzy was stupid, but that's the media. At one point I saw some media jack-off claiming that elevators would plummet to the ground, killing those trapped inside and causing major property damage and so forth. Let's be freakin' realistic. Nothing as silly as that would happen because embedded systems like that don't often depend on the frickin' date to work properly. The real risks were in financial software, for the most part. Stuff that did depend on date. And most of it was fixed before the problem happened.
Thus nothing happened because that was the desired outcome, and the reason we spent so much money in the first place. If something major had occurred, you'd have a real reason to bitch about the money that was spent, wouldn't you?
I wouldn't be surprised if that sort of thing exists, but they simply haven't documented it publically yet.
My guess is that they'll integrate it into the Google Toolbar at some point. Of course, this is a Windows/IE only thing, but the method it'll use can be found if/when that occurs. The method I posted before will work as an interim solution if needed by somebody.
Write a program that does http. Have it load up the gmail pages and parse them and such (exercise left to the reader) until you see a URL that looks like this:& view=tl &start=0&init=1&zx=XXXXXXXXXXXXXX
http://gmail.google.com/gmail?search=inbox
With the "XXXXX" replaced by some form of key.
In the source of that page, you'll find a bit of text that looks like this:
D(["ds",1,0,0,0,0,0]
D is a javascript function, but frankly you don't care.. The first number after the "ds" (in this case, 1) is the number of unread mails you have in your inbox. Reload this from time to time and check that number. Simple as that.
1) gravity isn't constant, it is inversely proportional to distance.
This is true, but not very useful. Standing on the ground you are a good 4000 miles from the Earth's center of gravity. Jumping another few hundred miles away doesn't make enough of an impact to seriously mess up "back of the napkin" type calculations, like he was obviously using. He did say "Low Earth Orbit" which is somewhere between 100-500 miles up.
2) orbital speed isn't constant either. In geosynchronous orbits, an object orbits once every 24 hours.
True, but then he did say "low earth orbit". A geosync sat does move slower through space, true, but energy-wise, it's a hell of a lot further up too. LEO is between 100-500 miles or so, while geosync orbits are 22,000 miles up. In any case, his energy calculations are correct, in a back-of-the-napkin kind of way. It does take a hell of a lot of energy to get into orbit, and it's a big leap to go from a ballistic jump to actual orbital velocities.
This is one hell of an achievement, I grant you. But Mach 3 just ain't gonna friggin' cut it. It's not how high you go, it's how fast you go that really counts, with regard to getting into orbit.
As recently as last week. I got a g-mail invite to my hotmail account, signed up, and am now using gmail. Works fine.
These are not "music" cd's. They're hybrid audio/data discs using the Blue Book standard. It'll appear like a Data CD to your computer.