Comment Re:Artificial Scarcity of Freedom. (Score 1) 568
To me "Internet" means "freedom of information"
To me "The Internet" is a series of tubes... Or a dump truck.
To me "Internet" means "freedom of information"
To me "The Internet" is a series of tubes... Or a dump truck.
Why would you limit yourself to ssh, when there's so many useful unpatched exploits for so many other server applications? Among other things, you're missing out on all the easily exploitable Windows ME boxen out there.
ssh defaults to port 22. Port 23 is usually telnet.
For those who missed the reference and didn't click the links, this is a reference to Fahrenheit 451.
Anyone who didn't get the references need to: Go back to highschool chemistry, and read more books.
We can't!
1) Clock drift in excess of a minute per day is not unheard-of.
I don't think I have ever seen numbers that high myself, but if needed, the time_diff could be recalculated more often. If the page notice a large clock drift between two calculations of the diff, it could schedule the next recalculation to occur sooner.
2) If the AJAX request fails, what do you do?
For the first calculation of the diff, you don't really need to use AJAX since the page already includes the server time in the "clock"-element. If a later AJAX-request fails, you could simply reuse the old diff and schedule a new calculation at a much sooner time that otherwise.
3) If the AJAX request hits a high asymmetric delay (not unheard-of), you'll be off by a good fraction of a minute.
You're right, I don't have a good solution for that problem. Maybe take a look at how NTP deals with it.
4) If the user can't set their computer's clock, what makes you think they can set the computer's timezone?
I don't think I said anything about the user setting the timezone anywhere, so I fail to see your point.
I did mention the "Europe/London"-timezone, but that timezone would be set by the BBC site, not the user.
5) Related to 4, what happens during a daylight savings time shift? You can't count on the local clock changing by an hour, but you also can't count on it *not* changing.
What daylight savings time? There's a reason why I'm using milliseconds since Epoch.
If you know the time in milliseconds since Epoch and you know when the transition between standard time and daylight savings occur (or any other change of offset from UTC), you can calculate the local time. You can find the transition times and offsets in the tzdatabase and do the calculation yourself or you can use the tzdata-javascript library I mentioned.
You can use local time as an estimate of the time zone, since time zones are only in 30 minute or an hour increments.
Or 15 minutes...
$ date -u ; TZ=Pacific/Chatham date
Thu Jun 6 22:54:10 UTC 2013
Fri Jun 7 11:39:10 CHAST 2013
What the BBC said was that they would find it difficult and expensive to accurately show the time at the user's location, when the user's time settings were wrong.
This is roughly how I would do it:
Wouldn't that work?
An adequate bootstrap is a contradiction in terms.