On a mechanical typewriter, the levers were arranged in strict left-to-right order, ignoring the row.
That is, the actual order was 1QAZ2WSX3EDC4RFV... well you get the idea. Keys on the same row were four levers apart, much reducing the risk of jamming.
You can still find a few common letter combinations, but you should be looking up/down rather than left/right.
Consider contents of the file, compressed, to be the hash. It fulfills the premises: depends on the file contents, is shorter than the file (or at least not longer), uniquely identifies the file. So, while md5 is not unique, bzip2 can be treated as a 100% duplicate-free hash creation program.
Not necessarily:-)
The "counting argument" can be used to show that no compression algorithm can hope to reduce the size of every file. Hence most (all?) compression programs will, from time to time, have to store an uncompressed version of the input file, and will thus have to have some mechanism for signalling to the decompressor that they have done so. Even if this "flag" is one bit long it will still represent an increase in size compared to the input file.
Real-life compression programs will of course be storing other information in the output file (e.g. original filename, size/checksum) so in practice we are talking about several bytes increase rather than one bit.
Note it's still possible to create a hash that is unique (like the above) but retrieving the content of the file from it (decompressing) is impossible. Just take your.bz2 "hash" and encrypt it, using its own MD5 as password.
Not actually impossible, just decidedly time-consuming. As mentioned above, a.bz2 file will have a recognizable internal structure. It's then just a matter of brute-forcing the decryption until a file of the appropriate format appears. With 128 bits of MD5 "key" this will take quite a while, but it's theoretically possible.
Then it's simply a matter of getting the magnet "out of the way"
I think that's likely to be a serious problem with your approach. Moving the magnet means you are doing actual work on the magnet itself, which would increase power consumption and reduce efficiency.
And if you're thinking of interposing some sort of magnetic shield, that would itself be a physical object which would interact with the magnet, thus altering the work done and hence the power consumption. You would also be straying dangerously close to "perpetual motion machine" territory: see the write-up on magnetic shields at The Museum of Unworkable Devices.
Worms, of course, have not as yet been polite enough to ask for permission before installing themselve. Thus the legal difference.
Actually, some worms do ask for permission.
For example, the Repad worm will terminate if you click 'No' on the 'Do you wish to continue?' box. Of course they're not quite there because the yes/no box isn't a click-through licence per se, but it's pretty close.
Yes, you're right: if the CD gets scratched, this will result in audible distortion as there's no ECC to save the day any more.
I am wondering how J.Random User will view this: the CD works fine when they buy it, but starts playing badly after about a month. They're bound to notice sooner or later...
IP version 5 was allocated for something called "ST Datagram Mode". RFC1190 (Experimental Internet Stream Protocol, Version 2, October 1990) has more details, but like most RFCs it's heavy reading.
Suffice to say it was for an experimental protocol that was supposed to be more amenable to handling voice traffic. As far as I am aware it never moved from "experimental" status.
According to the list of IP version numbers kept at the Internet Assigned Numbers Authority (www.iana.org - the exact page is at http://www.isi.edu/in-notes/iana/assignments/versi on-numbers), IP version 8 was assigned to "The P Internet Protocol".
Checking back through the RFCs will swiftly reveal this was a competitor for what we now know as IP version 6. Given that version 9 was allocated to TUBA (another competitor) I would hazard a guess that the next "live" version of IP after IP version 6 will probably be IP version 10.
Unfortunately, WebsterXL doesn't implement alpha transparency properly. But at least the application is still being developed. Maybe next release...:-)
Nice to see Webster XL get a mention, but not so happy to see the "not under development" comment. Unless of course I was hallucinating the upgrade that arrived a month or so ago...
If anyone could point me at some test images I'd gladly check out the "alpha transparency" issue.
One possible reason for this is that in order to go after the French, BT would need a European patent as well as an American patent. Do they have a European patent? I don't know.
As far as Minitel goes, see my other post about "Viewdata", which was being developed in the UK prior to Minitel.
The Post Office (who at the time were the UK's PTT) were developing a videotex system known as "Viewdata" in the mid-1970s - this is the system alluded to in the patent. Some time around 1975 (I don't have my references to hand) the display was changed to agree exactly with the "teletext" display being developed by the UK broadcasters.
My reading of the patent is that it was a modification to an early version of Viewdata (which originally required the user to enter the full page number of the desired page) in order to permit the more user-friendly "hot key" method of operation ("Press 1 for more, press 9 for menu"). In the context of a videotex system this was probably an innovation, but it's a huge stretch to try to claim it represents "hyperlinks".
As the BBC article states, Linkguard now knows that there are on average 52 links per page on the world wide web.
Checking that number of links could well slow down page load times, especially if the pages in question are on another server. Yes you're only doing a HEAD rather than a full page fetch but it still takes time. And users can get rather irritated at slow-loading pages...
The problem isn't with web servers, but with firewalls.
Many firewalls block traffic with "unusual" option bits set. If the French want to introduce a new IP option it will take time for the firewall manufacturers to update their software, and even longer for end-user sites to upgrade their firewalls.
The French could find themselves locked-out of a lot of Web sites in the meantime.
One way would be for Yahoo to check the source IP address against a list of address blocks known to be allocated to French ISPs: this would of course be in addition to checking for ".fr" on reverse lookup.
There is one screamingly obvious problem: it would catch some people in different countries who happened to get their service from a French ISP (and hence were given a "French" IP address).
In any case it would be trivial to circumvent: can you say "public proxy in another country"?
H.R.4176 is "The Information Technology Act of 2000". It was referred to House Committee on 4/4/2000. It is NOT law, at least not yet.
There appear to be only 4 sections to the bill, so reference to "section 101 para (e)(1)(a)" is completely bogus. For what it's worth, the bill is primarily concerned with "training program grants" and related matters.
S.1618 appeared in 1998, and subesquently died in the House. BYKTA.
Slashdot Mirror
On a mechanical typewriter, the levers were arranged in strict left-to-right order, ignoring the row.
That is, the actual order was 1QAZ2WSX3EDC4RFV... well you get the idea. Keys on the same row were four levers apart, much reducing the risk of jamming.
You can still find a few common letter combinations, but you should be looking up/down rather than left/right.
I'm just waiting until US authorities start arresting people who run sites in foreign countries because they accepted logins from Americans.
What, you mean like the BetOnSports incident?
Oh, you were being ironic. Silly me. OK, as you were...
2016 is exactly 10 years in the future.
"Heavenly Puss"
Congratulations on opening a big can of worms.
You can't call it "Great Britain" - that leaves out Northern Ireland.
You can't call it "Great Britain and Northern Ireland" - too long-winded, and it could upset certain factions.
The most common solution is to use "United Kingdom", or UK for short. Most people will know which country is being referred to.
2 miles is walking distance, and yes I do walk to work (but that puts me in a tiny minority).
Not necessarily :-)
The "counting argument" can be used to show that no compression algorithm can hope to reduce the size of every file. Hence most (all?) compression programs will, from time to time, have to store an uncompressed version of the input file, and will thus have to have some mechanism for signalling to the decompressor that they have done so. Even if this "flag" is one bit long it will still represent an increase in size compared to the input file.
Real-life compression programs will of course be storing other information in the output file (e.g. original filename, size/checksum) so in practice we are talking about several bytes increase rather than one bit.
Note it's still possible to create a hash that is unique (like the above) but retrieving the content of the file from it (decompressing) is impossible. Just take your .bz2 "hash" and encrypt it, using its own MD5 as password.
Not actually impossible, just decidedly time-consuming. As mentioned above, a .bz2 file will have a recognizable internal structure. It's then just a matter of brute-forcing the decryption until a file of the appropriate format appears. With 128 bits of MD5 "key" this will take quite a while, but it's theoretically possible.
A swift Google led me to this site.
I think that's likely to be a serious problem with your approach. Moving the magnet means you are doing actual work on the magnet itself, which would increase power consumption and reduce efficiency.
And if you're thinking of interposing some sort of magnetic shield, that would itself be a physical object which would interact with the magnet, thus altering the work done and hence the power consumption. You would also be straying dangerously close to "perpetual motion machine" territory: see the write-up on magnetic shields at The Museum of Unworkable Devices.
This formed the basis for a method of sending messages for free in years gone by.
Not quite, no.
Demon issues subdomains of the form "nospam.demon.co.uk", but the user's email address will be "user@nospam.demon.co.uk", not "nospam@demon.co.uk".
A number of other UK ISPs do issue addresses in a way that might invalidate the patent, but I don't know which of them were doing so prior to 1999.
Try www.paulgraham.com instead. The .org address is a photographer in Glasgow :-)
Actually, some worms do ask for permission.
For example, the Repad worm will terminate if you click 'No' on the 'Do you wish to continue?' box. Of course they're not quite there because the yes/no box isn't a click-through licence per se, but it's pretty close.
I am wondering how J.Random User will view this: the CD works fine when they buy it, but starts playing badly after about a month. They're bound to notice sooner or later...
Suffice to say it was for an experimental protocol that was supposed to be more amenable to handling voice traffic. As far as I am aware it never moved from "experimental" status.
Checking back through the RFCs will swiftly reveal this was a competitor for what we now know as IP version 6. Given that version 9 was allocated to TUBA (another competitor) I would hazard a guess that the next "live" version of IP after IP version 6 will probably be IP version 10.
Unfortunately, WebsterXL doesn't implement alpha transparency properly. But at least the application is still being developed. Maybe next release... :-)
If anyone could point me at some test images I'd gladly check out the "alpha transparency" issue.
As far as Minitel goes, see my other post about "Viewdata", which was being developed in the UK prior to Minitel.
My reading of the patent is that it was a modification to an early version of Viewdata (which originally required the user to enter the full page number of the desired page) in order to permit the more user-friendly "hot key" method of operation ("Press 1 for more, press 9 for menu"). In the context of a videotex system this was probably an innovation, but it's a huge stretch to try to claim it represents "hyperlinks".
Checking that number of links could well slow down page load times, especially if the pages in question are on another server. Yes you're only doing a HEAD rather than a full page fetch but it still takes time. And users can get rather irritated at slow-loading pages...
Oh, I remember the advert for BC3K. But then I had a reason for that :-)
Many firewalls block traffic with "unusual" option bits set. If the French want to introduce a new IP option it will take time for the firewall manufacturers to update their software, and even longer for end-user sites to upgrade their firewalls.
The French could find themselves locked-out of a lot of Web sites in the meantime.
There is one screamingly obvious problem: it would catch some people in different countries who happened to get their service from a French ISP (and hence were given a "French" IP address).
In any case it would be trivial to circumvent: can you say "public proxy in another country"?
There appear to be only 4 sections to the bill, so reference to "section 101 para (e)(1)(a)" is completely bogus. For what it's worth, the bill is primarily concerned with "training program grants" and related matters.
S.1618 appeared in 1998, and subesquently died in the House. BYKTA.