There is no excuse for having congestion in your network on a daily or weekly. It can happen once in a blue moon when a line becomes unexpectedly busy, but it should never be the normal mode of operations.

At least not in a pretend-first-world-country where it is easy to lay backbone fiber.

Of course the screen lock in X was a security device; back when X was designed most workstations were shared.

XScreenSaver has some atrocious code to work around the deficiencies in X. Most of the time it succeeds.

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.

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 washtimes.com, and that is all that was actually required.

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

Alas, noise regulations prevent departures between 11pm and 7am at the Santa Monica airport.

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.)

Yes. They are that bad. Read the threads about Gnome vs. systemd-timesyncd vs. Chrony and weep.

http://www.spinics.net/lists/f...

And Poettering in his usual ignorant condescending style:

http://www.spinics.net/lists/f...

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.

SystemD does not have an NTP client. It has an SNTP client. Just like OpenNTPD.

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.)

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.

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.

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.

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.

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.

This is exactly why it would be nice to use SSH instead. SSH key handling is easy.

The slowness and excessive round trips that SSH connections require makes it entirely impractical to replace HTTPS, of course, but I would LOVE if the key handling parts were copied.