Legally it is not a problem for most of the flight. Send it off from a ship in international waters and be sure to fly only over international waters. The legal problems start when you reach North Korean waters, of course.
It is not a realistic prospect. For daemons, the automatic handling by systemd is so much of an advantage that we will see server software depending on it. It will have to be emulated by the other init daemons, and so far I have not seen any of them work in that direction.
For GUI stuff, GNOME is already partially dependent on systemd, and KDE is going that way too.
The only "throttling" you get is at peak times due to network congestion, but even then i'am still unable to see any service impact or major delay.
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 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...)
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.)
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.
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.
...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.
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.
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.
OpenSSL, Netscape NSS, GnuTLS, as well as various proprietary SSL implementations have all had serious bugs over the last few years. Some of the bugs affected multiple unrelated code bases.
How much diversity do you want? How did the diversity help?
Alas, power production is not the only expense. In most of the world, price at the plug socket is disconnected from the price in the actual power market.
They didn't alarm all the time but they didn't stop
You have a strange definition of stop.
There were climbing; their air speed was not too high. They were stalling because their air speed was too low and the AoA was too high; they just didn't believe the warnings.
I do not know where you get the impression that we disagree about this. Of course they stalled because their speed was too low and the AoA was too high.
After 54s, the stall warning started cutting out because the airspeed approached zero.
While the stall alarm sounded continuously for 54s the captain, urgently called back from a rest break, re-entered the cockpit just as it ceased. The warnings then became intermittent, owing to A330 logic that cuts out the alarm if airspeeds become invalid
SNPL president Jean-Louis Barber said the pitot failure "constituted the trigger" and the pilots then faced a "delicate, unexpected" and "totally novel" situation.
It insists the design of the stall warning "misled" the pilots. "Each time they reacted appropriately the alarm triggered inside the cockpit, as though they were reacting wrongly. Conversely each time the pilots pitched up the aircraft, the alarm shut off, preventing a proper diagnosis of the situation.
No that is also incorrect. Stall [wikipedia.org] warnings are when there is not enough lift. Most of the time (and in this accident), this is when the airspeed is too low or the angle of attack is too high.
Do you really think you need to tell me what a stall is? Yes, the stall happened because airspeed was too low. However, the stall warnings did the worst thing possible: turn off when airspeed is low and turn on when airspeed increases.
Base load is so low that it is completely uninteresting. The problem with nuclear is that it produces 100% of the time or it loses money. You can do load-following nuclear, but not in a market-based system -- the price goes negative most of the time, and ridiculously high at peak times.
Nuclear is dependent on a command economy or on proper load-following fossil or hydro power.
Notice how new nuclear in the UK is guaranteed 0.085 GBP per kWh, at 3 am on a summer night when prices are negative. For 35 years.
Slashdot Mirror
I'll see your 10kWh battery bank and raise you a 1 m3 fuel tank. Every house used to have one. 3 orders of magnitude more energy.
Hydro is the perfect peak load. It is a waste to use it for base load, but in many places it is abundant enough to use for that as well.
Legally it is not a problem for most of the flight. Send it off from a ship in international waters and be sure to fly only over international waters. The legal problems start when you reach North Korean waters, of course.
It is not a realistic prospect. For daemons, the automatic handling by systemd is so much of an advantage that we will see server software depending on it. It will have to be emulated by the other init daemons, and so far I have not seen any of them work in that direction.
For GUI stuff, GNOME is already partially dependent on systemd, and KDE is going that way too.
The only "throttling" you get is at peak times due to network congestion, but even then i'am still unable to see any service impact or major delay.
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.)
Things really *are* bad, aren't they?
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.
...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.
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.
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.
OpenSSL, Netscape NSS, GnuTLS, as well as various proprietary SSL implementations have all had serious bugs over the last few years. Some of the bugs affected multiple unrelated code bases.
How much diversity do you want? How did the diversity help?
Alas, power production is not the only expense. In most of the world, price at the plug socket is disconnected from the price in the actual power market.
California is a particularly dysfunctional case.
They didn't alarm all the time but they didn't stop
You have a strange definition of stop.
There were climbing; their air speed was not too high. They were stalling because their air speed was too low and the AoA was too high; they just didn't believe the warnings.
I do not know where you get the impression that we disagree about this. Of course they stalled because their speed was too low and the AoA was too high.
The stall warnings happened continuously throughout the time until the condition was corrected. It was never corrected.
This is a factual bit we disagree about.
See e.g. Stall warning controversy haunts AF447 inquiry
After 54s, the stall warning started cutting out because the airspeed approached zero.
While the stall alarm sounded continuously for 54s the captain, urgently called back from a rest break, re-entered the cockpit just as it ceased. The warnings then became intermittent, owing to A330 logic that cuts out the alarm if airspeeds become invalid
SNPL president Jean-Louis Barber said the pitot failure "constituted the trigger" and the pilots then faced a "delicate, unexpected" and "totally novel" situation.
It insists the design of the stall warning "misled" the pilots. "Each time they reacted appropriately the alarm triggered inside the cockpit, as though they were reacting wrongly. Conversely each time the pilots pitched up the aircraft, the alarm shut off, preventing a proper diagnosis of the situation.
No that is also incorrect. Stall [wikipedia.org] warnings are when there is not enough lift. Most of the time (and in this accident), this is when the airspeed is too low or the angle of attack is too high.
Do you really think you need to tell me what a stall is? Yes, the stall happened because airspeed was too low. However, the stall warnings did the worst thing possible: turn off when airspeed is low and turn on when airspeed increases.
Base load is so low that it is completely uninteresting. The problem with nuclear is that it produces 100% of the time or it loses money. You can do load-following nuclear, but not in a market-based system -- the price goes negative most of the time, and ridiculously high at peak times.
Nuclear is dependent on a command economy or on proper load-following fossil or hydro power.
Notice how new nuclear in the UK is guaranteed 0.085 GBP per kWh, at 3 am on a summer night when prices are negative. For 35 years.