Please create an account to participate in the Slashdot moderation system


Forgot your password?

Comment: Re:call me skeptical (Score 1) 360

by amorsen (#48835575) Attached to: NASA, NOAA: 2014 Was the Warmest Year In the Modern Record

Of course there is. One powerful negative feedback is that CO2 lets less and less infrared radiation escape, so every new added CO2 atom in the atmosphere has less effect than the previous one -- it cannot block radiation which was already blocked by other CO2 atoms.

This is part of the reason why doubling of CO2 levels "only" causes a linear temperature rise. CO2 only has a logarithmic effect on the temperature.

Which is lucky. Anything more complex than bacteria would have trouble surviving the wild temperature swings that a linear correlation between CO2 and temperature would cause.

Comment: Re:SOME visitors (Score 1) 56

by amorsen (#48833351) Attached to: Google Finally Quashes Month-Old Malvertising Campaign

And then you try to open a mainstream news site, like the Washington Times article linked to earlier, and you are presented with a full-page list of sites the page wants to load content from. It turns out the CSS one is, and that is all that was actually required.

I wish requestpolicy would label links by how they got pulled in (CSS, image, script...)

Comment: It is just Carrier Grade NAT (Score 1) 159

by amorsen (#48778335) Attached to: Inside North Korea's Naenara Browser

Plenty of people get RFC 1918 or RFC 6598 instead of public addresses from their ISP. I would guess that the majority of internet connections in the world are given private space.

It is not common in the US because the US is still drowning in IP addresses, and a lot of the customers are using cable or DSL. In Europe you will often be behind CGN when you use a mobile ISP, and in Asia you will likely be behind CGN no matter how you connect.

Welcome to 2015.

(Of course most ISP's do not hand out browsers at all, much less browsers which are remote controlled from a server somewhere. It is hardly a surprise that North Korea does.)

Comment: Re:Mathematics (Score 1) 79

by amorsen (#48774557) Attached to: OpenBSD Releases a Portable Version of OpenNTPD

Chrony is a complete working implementation of the NTP protocol. NTPD gets its knickers in a twist at the slightest excuse and sometimes ends up stepping the time even though it has perfectly good Internet connectivity and a reasonably good internal clock. Chrony keeps steady time even if Internet access is intermittent. It never gets confused and picks a falseticker pretending to be stratum one instead of a stratum 3 with correct time, unlike NTPD.

It even has interfaces to GPS clocks or other hardware clocks, so you can run your stratum 1 server on Chrony if you want.

Comment: Re:Fix NTP (Score 1) 289

by amorsen (#48759337) Attached to: Extra Leap Second To Be Added To Clocks On June 30

Time zones are fine. Astronomers are not to blame for those. Astronomers ARE to blame for the mess that is UTC. Give them UTC and UT1, and move all civil time to TAI with time zones. Change time zones when the offset gets too large (which is pretty large, considering that China does just fine in a single time zone -- they somehow survive that the sun is not precisely above them at 12.)

Comment: Re:Fix NTP (Score 1) 289

by amorsen (#48752675) Attached to: Extra Leap Second To Be Added To Clocks On June 30

I meant UT1 instead of TAI in that sentence. Sorry.

I do not care if they predict it in advance. Just issue a leap second in 5 years time if it looks like it will be necessary within 6 months. Yes, UT1 will drift away from UTC by more than 0.9 second, but who cares? It will never be far enough away for anyone other than astronomers to notice, and astronomers use UT1 anyway.

The best solution, of course, is to simply kick the astronomers out of civil timekeeping entirely. Bring them in for a consultation every thousand years and change time zones then, if necessary.

Comment: Re:Fix NTP (Score 1) 289

by amorsen (#48749987) Attached to: Extra Leap Second To Be Added To Clocks On June 30

Yes you are right, I had forgotten just how broken POSIX time is. Completely unfixable.

Which is stupid, because struct tm actually supports leap seconds and even (despite them not being possible) double leap seconds.

...and whatever data structures are used to keep tract of future scheduled events might have to be updated to reflect that, for example, July 1, 2015, 00:00:00 UTC is going to be one more second later than was expected at the time an event was scheduled for that date and time.

This bit you already have to handle due to daylight savings and time zone changes. If the user inputs a local date and time for a particular event, it is NOT valid to convert and store that as seconds after the epoch. That conversion can change anytime.

Comment: Fix NTP (Score 4, Interesting) 289

by amorsen (#48748483) Attached to: Extra Leap Second To Be Added To Clocks On June 30

The main problem is the wrong handling of UTC by NTP and Unix.

NTP is simply on the wrong time system. It is a system which is designed to accurately keep a monotonous steady time shared among millions of systems spread across time zones. It does not have any sensible way of dealing with the fact that some systems want to suddenly add a second or subtract one, just like it cannot deal with time zones or Mayan calendars. Those are simply outside its problem domain. Luckily the fix is simple: Stop handling leap seconds at all in NTP, just keep counting seconds. If you must handle it in NTP for those client systems too primitive to do it themselves, do it by transmitting the current offset between NTP time and UTC. The best solution would be to define NTP time to be TAI of course, but it will likely have to be TAI+offset to handle backwards compatibility.

Unix again does it wrong by keeping system time in UTC rather than TAI. UTC is useful for humans but difficult for machines, it should be handled by the human interface libraries, just like time zones. Kernel time should be TAI of course. When leap seconds are inserted, systems must be updated, but that is not particularly harder than keeping the time zone files up-to-date is already. Of course it would be a lot easier if the astronomers would let us know a few years in advance rather than six months, but then the offset between TAI and UTC could exceed 0.9 seconds, and as we all know that would bring Ragnarok.

GNU systems even have sets of time zones for precisely this reason: "POSIX" and "Right". Unfortunately it is not possible to use the "Right" time zones with current NTP.

Comment: Re:Public Key, not SSH. (Score 1) 203

by amorsen (#48731807) Attached to: Why Aren't We Using SSH For Everything?

I don't get what you are saying. I did not say the things you quoted.

I have my SSH private key saved securely. That is easy, it does not take up any room at all. My password database on the other hand is not backed up; I am not willing to make the compromises necessary to do so. I will just have to recreate passwords everywhere in case my drive crashes.

Life would be a lot easier if sites would accept my SSH key or my PGP key as ID.

Comment: Re:Public Key, not SSH. (Score 1) 203

by amorsen (#48726267) Attached to: Why Aren't We Using SSH For Everything?

This problem is exactly the same for passwords, at least if you follow decent security practices and never reuse passwords.

It is actually worse for passwords, since you can use the same private key securely with all sites. It is simple to backup a single private key, not so simple to backup your entire ever-changing database of passwords.

Computer programmers do it byte by byte.