Yes. But no. The leap second corrects the _day_ from being one second off, which is one second out of 86400. What that second is, spread out over one year (since it has nothing to do with the year whatsoever, except that it usually is applied on the last day of June or December), is not very relevant at all.
No, but one second out of 86400 is. The leap second has nothing to do with the length of the year (the time it takes for the earth to orbit the sun), whatsoever. This is instead handled by leap days. The leap second is used to keep the day (rising and setting of the sun, tea-time, midnight and stuff) synchronized with UTC.
My internet line went down yesterday, will not be back up again until next week (upgrading from ADSL to VDSL, lame ass ISP, disconnecting the old service before sending me a new modem). Posting this at work. I am experiencing fear, loneliness and boredom. Will probably experience stress tonight, if I try hooking up the old POTS modem...
The magic, is not actually in the code, the magic is in the usability features and concepts.
So, while most of us implement usability features and concepts by writing them in some kind of code (such as C++ and COBOL), Apple instead just pours some UF&C-enriched MacMagic iSprinkles (tm) over the binaries to get their look&feel...
"Why would anyone in their right mind sign over a license to anyone that was not revocable?"
Why would anyone, judging from the statements they made in the recent months, have any reason to believe that the people in SCO's management are in their right minds?
They just took an acronym they wanted ("What comes after ATX, could it be ATY or BTX?"), and just for some kind of completenes, make up a "meaning" for it, which really doesn't matter since noone is going to use anything other than the acronym anyway.
Re:This goes back to the early days of Apple
on
Beatles Bite Apple
·
· Score: 4, Funny
It really has nothing to do with any of the Beatles songs, but the rights to the name "Apple", which is now own3d by EMI.
But what will come out of this? -EMI losing, since the record company Apple essentially doesn't exist (is declared partially rotten and is discarded) -HugeCashSettlement (let's give more money to the large record companies!) -Apple starts a subsidiary (Banana or Pineapple) and transfers all music-related things there -Name is changed to The Computer Company Formerly Known As Apple (TCCFKAS) -Apple uses the Chewbacca defense
This reminds me of a rather famous April fools joke here in Sweden. Some guy (known for his technical expertise in different matters) said, on TV, that if you put nylon stockings or pantyhose over the screen, you got color TV (this was in 1962).
Not really. Then you can't extract single files (or for that matter, adding or removing) from the archive without decrypting and decompressing the whole thing. If you do the tar last (and obviously, compression before encryption), you can get to individual files without bothering about the rest of them. On the other hand, as long as the archives aren't that huge (and the machine handling them isn't too feeble), it's not that big a deal.
I once saw a simple proof-of-concept in which the server could identify the client based on the browser cache. A (dynamic) HTML page contained a bunch (about 100 or so) of img tags (and recorded which client got which set of img tags, they all had an ID in the URL). The next time the same client loaded the page, it got a different set of ID numbers, some of which were the same, and since those were cached, they weren't fetched from the server. So based on merely what information the client requested (or rather, _didn't_ request), it could be identified anyway. Sure, some browsers cache things differently (or not at all), and some don't even load images (lynx). But at least it worked with the default settings of the two major browsers at the time (MSIE and Netscape, both 4.something). IIRC, those 100 img tags was enough to keep track of several thousand clients.
If a site doesn't want anyone to "deep link" to them, why not just check the HTTP_REFERER HTTP header, and send those requests that come frome a "deep link" (anything outside their own site, probably) to the front page? Sure, you can set your own referer header and fool such things, but "ordinary users" wouldn't bother doing that.
(Or do Big Evil Compaines always try to take legal action first, and if that fails, go for a technical solution?)
Whenever a "distribution method" is killed for some reason, it just means a new and improved one will pop up instead. Example: MP3 files. A few years ago, you could fairly easily grab them via normal HTTP (just download links from web pages) or FTP. When that got the attention of Harry Fox et al, enter Napster, which flourished for a while. When that got shut down, Gnutella and KaZaa/FastTrack came around. Every iteration just brings better file sharing systems that are harder to kill off. BitTorrent might not have been the most resilient one around, but it probably will be in its next form, whenever that happens.
PHP5 toghether with PHP4
on
PHP 5 Beta 1
·
· Score: 1
I'm currently running PHP 4.3.2 on Apache 2.0.45. I would really like to try out php5 without messing up php4 (to see what needs fixing before upgrading to the "real" php5, whenever it is released). I got my libphp5.so compiled and all, but is there a nice&easy way to tell Apache to use it for files named.php5 (for instance), and the old version for.php? I could have two separate LoadModule lines (in httpd.conf), but I can't tell them apart in AddType. I'd really like not having to run a second httpd (on another port)...
I think I counted to exactly 10 (two in the top, two on each side, one on the CPU and and one in the PSU in the back). Put it next to a blender filled with gravel chugging away at "liquify", and you almost won't hear the blender at all.
It is possible to have another machine, not the router itself, do the proxy arp stuff. _Might_ even be possible to do it on the sending mac itself (if you somehow could "intercept" outgoing ARP requests).
86400 seconds (==24 hours) is a reasonable time to cache DNS queries. That means that if AOL's DNS server has queried one of the root servers about something (such as "where are the DNS servers for.com?"), it shouldn't make that same query for another day. The data in the root servers (a bunch of names and glue records for all the top-level domains) doesn't change that often, so 24 hours is definitely not too long.
If you change the IP address of foo.bar.com, that is done in the bar.com DNS servers, and the higher-level DNS servers (.com and root servers) have nothing to do with it. In that case, people won't be able to reach that site for (at worst) 24 hours. And if you plan a little ahead, you just set the TTL (time-to-live, the maximum allowed time to cache a record) down a couple of days before you change the IP. If all DNS resolvers do what they should (which they of course don't, hence some of the unnecessary load), "DNS downtime" shouldn't have to be more than a couple of minutes.
AFAIK, it is even mathematically/physically proven to be unbreakable. The aren't really any complex algorithms involved in "basic quantum encryption", but some quite simple quantum physics (well, at least simple for quantum physics). The method has been known for some time, but noone has been able to build the hardware for it until quite recently (you need to have an optical link over which you can send one single photon at a time, and the information is carried by the polarization of it).
Slashdot Mirror
Yes. But no. The leap second corrects the _day_ from being one second off, which is one second out of 86400. What that second is, spread out over one year (since it has nothing to do with the year whatsoever, except that it usually is applied on the last day of June or December), is not very relevant at all.
No, but one second out of 86400 is.
The leap second has nothing to do with the length of the year (the time it takes for the earth to orbit the sun), whatsoever. This is instead handled by leap days.
The leap second is used to keep the day (rising and setting of the sun, tea-time, midnight and stuff) synchronized with UTC.
...I'm changing clothes on a train going from New York to Stockholm at 80 mph that leaves at 8pm local time.
I would sure like to see a _train_ from New York to Stockholm. Even better would be seing someone trying to put clothes on it.
1/10000 actually is less than 1/1000, so the original post really was correct. 0.01% is, on the other hand, _not_ less than 1/10000.
But then again, who cares.
My internet line went down yesterday, will not be back up again until next week (upgrading from ADSL to VDSL, lame ass ISP, disconnecting the old service before sending me a new modem). Posting this at work.
I am experiencing fear, loneliness and boredom. Will probably experience stress tonight, if I try hooking up the old POTS modem...
The magic, is not actually in the code, the magic is in the usability features and concepts.
So, while most of us implement usability features and concepts by writing them in some kind of code (such as C++ and COBOL), Apple instead just pours some UF&C-enriched MacMagic iSprinkles (tm) over the binaries to get their look&feel...
"Why would anyone in their right mind sign over a license to anyone that was not revocable?"
Why would anyone, judging from the statements they made in the recent months, have any reason to believe that the people in SCO's management are in their right minds?
They just took an acronym they wanted ("What comes after ATX, could it be ATY or BTX?"), and just for some kind of completenes, make up a "meaning" for it, which really doesn't matter since noone is going to use anything other than the acronym anyway.
It really has nothing to do with any of the Beatles songs, but the rights to the name "Apple", which is now own3d by EMI.
But what will come out of this?
-EMI losing, since the record company Apple essentially doesn't exist (is declared partially rotten and is discarded)
-HugeCashSettlement (let's give more money to the large record companies!)
-Apple starts a subsidiary (Banana or Pineapple) and transfers all music-related things there
-Name is changed to The Computer Company Formerly Known As Apple (TCCFKAS)
-Apple uses the Chewbacca defense
They probably plan just to sell one copy of "Legend", and they sell it just to keep a backup of their original.
This reminds me of a rather famous April fools joke here in Sweden. Some guy (known for his technical expertise in different matters) said, on TV, that if you put nylon stockings or pantyhose over the screen, you got color TV (this was in 1962).
Not really. Then you can't extract single files (or for that matter, adding or removing) from the archive without decrypting and decompressing the whole thing. If you do the tar last (and obviously, compression before encryption), you can get to individual files without bothering about the rest of them.
On the other hand, as long as the archives aren't that huge (and the machine handling them isn't too feeble), it's not that big a deal.
I once saw a simple proof-of-concept in which the server could identify the client based on the browser cache.
A (dynamic) HTML page contained a bunch (about 100 or so) of img tags (and recorded which client got which set of img tags, they all had an ID in the URL). The next time the same client loaded the page, it got a different set of ID numbers, some of which were the same, and since those were cached, they weren't fetched from the server. So based on merely what information the client requested (or rather, _didn't_ request), it could be identified anyway.
Sure, some browsers cache things differently (or not at all), and some don't even load images (lynx). But at least it worked with the default settings of the two major browsers at the time (MSIE and Netscape, both 4.something).
IIRC, those 100 img tags was enough to keep track of several thousand clients.
If a site doesn't want anyone to "deep link" to them, why not just check the HTTP_REFERER HTTP header, and send those requests that come frome a "deep link" (anything outside their own site, probably) to the front page?
Sure, you can set your own referer header and fool such things, but "ordinary users" wouldn't bother doing that.
(Or do Big Evil Compaines always try to take legal action first, and if that fails, go for a technical solution?)
Whenever a "distribution method" is killed for some reason, it just means a new and improved one will pop up instead.
Example: MP3 files. A few years ago, you could fairly easily grab them via normal HTTP (just download links from web pages) or FTP. When that got the attention of Harry Fox et al, enter Napster, which flourished for a while. When that got shut down, Gnutella and KaZaa/FastTrack came around. Every iteration just brings better file sharing systems that are harder to kill off. BitTorrent might not have been the most resilient one around, but it probably will be in its next form, whenever that happens.
I'm currently running PHP 4.3.2 on Apache 2.0.45. I would really like to try out php5 without messing up php4 (to see what needs fixing before upgrading to the "real" php5, whenever it is released). .php5 (for instance), and the old version for .php? I could have two separate LoadModule lines (in httpd.conf), but I can't tell them apart in AddType.
I got my libphp5.so compiled and all, but is there a nice&easy way to tell Apache to use it for files named
I'd really like not having to run a second httpd (on another port)...
I think I counted to exactly 10 (two in the top, two on each side, one on the CPU and and one in the PSU in the back). Put it next to a blender filled with gravel chugging away at "liquify", and you almost won't hear the blender at all.
It is possible to have another machine, not the router itself, do the proxy arp stuff. _Might_ even be possible to do it on the sending mac itself (if you somehow could "intercept" outgoing ARP requests).
That has to be real. No way I would ever think that that grill is an April Fool's joke. Never.
Man, this is the third time today I got fooled by that same RFC...
86400 seconds (==24 hours) is a reasonable time to cache DNS queries. That means that if AOL's DNS server has queried one of the root servers about something (such as "where are the DNS servers for .com?"), it shouldn't make that same query for another day. The data in the root servers (a bunch of names and glue records for all the top-level domains) doesn't change that often, so 24 hours is definitely not too long.
If you change the IP address of foo.bar.com, that is done in the bar.com DNS servers, and the higher-level DNS servers (.com and root servers) have nothing to do with it. In that case, people won't be able to reach that site for (at worst) 24 hours.
And if you plan a little ahead, you just set the TTL (time-to-live, the maximum allowed time to cache a record) down a couple of days before you change the IP. If all DNS resolvers do what they should (which they of course don't, hence some of the unnecessary load), "DNS downtime" shouldn't have to be more than a couple of minutes.
Mystery solved:
1. [A-Za-z ]+
2. Imagine a beowulf cluster of (1).
3. Profit!!
AFAIK, it is even mathematically/physically proven to be unbreakable. The aren't really any complex algorithms involved in "basic quantum encryption", but some quite simple quantum physics (well, at least simple for quantum physics). The method has been known for some time, but noone has been able to build the hardware for it until quite recently (you need to have an optical link over which you can send one single photon at a time, and the information is carried by the polarization of it).
Oops. Should be "Use Linux to power Bill".
Now I've totally spoiled it.
"Use Linux power Bill"
Bill Gates being a robot/cyborg/android would be far less surprising than him being powered by Linux