Astronomers are the ones who are pushing for a standard with leap seconds to be used for general timekeeping. Their lobbying is what is stopping legislation from being sane.
I would be perfectly happy to let my servers run in such a mode, but I do not know of any NTP implementation which allows the system time to be set to TAI. Also, NTP synchronization around the leap second event is a mess, because some NTP servers smear the time.
And finally, if I fail to update one of the servers in the time between a leap second is announced and the time that it takes effect, the server will now be one second fast. Unless it somehow records that NTP showed a leap second event happening. If NTP carried TAI and a separate field with current offset between TAI and UTC, this would no longer be a problem.
The second is defined as "the time of 9,192,631,770 periods of the radiation corresponding to the transition between the two hyperfine levels of the ground state of the caesium 133 atom at rest at a temperature of 0 K" and it stays as it is.
Not on any system connected to NTP, it doesn't.
The "very robust" code can handle timezone changes gracefully, but not leap seconds. Maybe it can be made more robust and handle both?
It can handle leap seconds gracefully, except the warning time is too short. However, if you use time zone handling for leap seconds, you suddenly find yourself without any means of synchronizing your time with the rest of the world. Running like that is not very helpful.
The majority of NTP servers deliver UTC which has leap seconds. Calculate the monotonic time from that. The calculation is in principle not extremely different from retroactively calculating the local time using TZ files.
The majority of NTP servers deliver UTC, which is exactly the problem. There is no way to determine from the NTP time how many seconds elapsed since the start of the epoch. If NTP had been delivering an actually useful time standard, we would not be in this mess.
The only problem with Windows time zone handling is the BIOS time being set to local time rather than UTC. If Windows has a time server configured, it will know whether the BIOS adjustment was made, so it is really not much of a problem in practice. It is only a problem if you dual boot, and that is probably deliberate.
Yes, Java uses its own zone files, but they get updated regularly too.
I haven't had an iPhone for many years, so I don't know how they do with time zones.
Changing from leap seconds to leap minutes would move the problem from NTP to time zone files. Time zone files are well tested, regularly updated, and generally high quality.
We have high quality libraries which can calculate the time difference between two arbitrary times in different time zones. This is not possible for leap seconds, because they do not get scheduled in with a decent amount of warning. Changing time zones is tested in many locales twice a year, it basically never breaks.
If they think a "leap second" is a big deal then a "leap minute" or "leap hour" is going to really cause problems. They'll have longer periods of time for more bugs to accumulate and when they happen everything will have problems because either they'll fail or something they depend on will fail.
Leap minutes or leap hours would be handled by the existing time zone handling, not by messing with the length of a second. That code is well tested and very robust.
Warnings about leap minutes or leap hours could be made years in advance, leaving plenty of time to update the files on even the most remote systems.
And yes, technically leap seconds should be handled via the time zone system as well. GNU even distributes a set of zone files for that purpose, the ones that start with "right" instead of "posix". No one uses them because they break if you use NTP. NTP does not distribute a leap-second free time scale. THAT is the true disaster in all this.
It's not like someone's forcing you to use UTC, UT1R, or one of the other UT systems that are specifically intended to deal with issues of local noon.
That is exactly where you are wrong. We are all forced to live in UTC, because that is what the law requires in multiple countries, and it is the only time distributed in NTP.
Screw you astronomers. You don't really care about UTC anyway; you need to correct for position and find the actual local time, so you can just continue doing your own thing. Leave UTC alone.
I am rarely in a place where solar noon is within half an hour of actual noon anyway. Why do I care if it's 30 minutes + 17 seconds out, rather than only 30 minutes? If night is turning into day, we fix the time zones. They change regularly anyway, and we have excellent methods of dealing with the changes. The code gets tested regularly and the only problem is when legislation gives less than a few months warning of changes. Code which does not like the changes sets the time zone to GMT+0 and all is well. No such fix is possible for leap seconds.
I give you Frigate Peder Skram. Missile coordinates were given to the launch computer, and the Harpoon missile launched, without the launch keys being inserted.
And that was back when computer code was small enough to be reasonably scrutinized.
If you are referring to the MPEG decoding stuff, there is no restriction in the firmware that prevents it from working. It is merely that the RPi's creators require you to buy a licence to unlock the user land software that can make use of it because that is the agreement they signed with the manufacturer.
This is simply wrong. The user land software is the same, the firmware functions are unlocked cryptographically. If it had been user land, cracks would have been available within hours of the release of the software.
Who knows which firmware functions could be unlocked if you send the right cryptographic checksum to the firmware? Perhaps the send_ssh_key_to_NSA function? Unlikely, but it is also unlikely that anyone will ever find out.
Until very recently, the cheapest option to get 10Gbps was SFP+ and Direct Attach Cables. It is still by far the most energy efficient option, unless you use 10Gbase-T with energy saving that lowers the port speed to 100Mbps when not much bandwidth is used (and that has latency implications).
I have not yet touched a single 10Gbase-T-port but 10Gbps SFP+ is everywhere. A few get actual fiber SFP+ modules inserted, but the vast majority is DAC.
Are 10 gig parts that complicated that they're staying so expensive for so long?
Yes. 10Gbase-T runs a complicated encoding which requires power-hungry processing. Note how you cannot buy a 10Gbase-T SFP+ module for love or money; the power/cooling budget of SFP+ does not permit it to exist. Yet you can trivially get optical SFP+ modules designed for 80km, where 10Gbase-T is struggling to reach 100m.
10Gbps+ ethernet for the home will happen, but I doubt it will be 10Gbase-T.
Raspberry Pi is a GPU with a CPU bolted on the side. The CPU is entirely dependent on the GPU, it cannot even boot without it. The GPU driver is fairly trivial; it mostly consists of stub calls to the firmware blob.
The firmware blob is proprietary and closed, to the point that it even has restrictions on which instructions the GPU is allowed to use. You can buy an unlock code to remove the restrictions. Even Android devices are not that closed down in general.
Even gigabit routers (which are technically gigabit layer 3 switches) need an ASIC in order to fully saturate your WAN bandwidth if you are with a gig provider.
Gigabit is reasonably trivial to do in software if you have a half-decent CPU. Get a OneAccess 1645 or a Juniper SRX220 and you are good to go. Yes, you can overwhelm at least the latter with 64-byte packets, but why would you do that? Both are using fairly lousy CPU's.
If you go Intel, it is difficult to find a processor slow enough that it would not route 1Gbps, even if you look at CPU's intended for tablets. Perhaps one of the really low-end phone processors.
At least that way the surveillance equipment gets installed beforehand. Otherwise they have to send in undersea crews afterwards, right at the same time as three different ships accidentally cut three different cables in the area...
If you get the surveillance in beforehand, you avoid a lot of expenses later.
You're being ridiculous. I am an energy-efficiency wonk. You can build as many nuclear power plants as you want, as long as they can compete with other forms of clean energy on price.
Once we have switched to zero-carbon electricity or at least made polluting forms of energy pay appropriate taxes to offset the damage they do, you can use as much energy as you want. That is between you and your wallet. But until then, your electricity consumption is partially paid for by me. Do not waste MY money.
She brags about her security clearance and about how she knows so much about what is going on. She may not be all that bright, but surely given that information she could figure out why they needed the server capacity.
Her defence of waterboarding shows what a disgusting person she is. I am ashamed that I was working for HP at the time.
Even if Windows was a microkernel and TrueCrypt was running without privileges and so on, I think that many users use TrueCrypt to encrypt their system partition. Once TrueCrypt is compromised, the attacker can replace e.g. SVCHOST.EXE or another critical Windows system file with anything they want. I am not aware of any security technology which can stop an attacker who has broken the file system driver for the root file system. I am not sure what that kind of technology would even look like -- all the ideas I can think of are completely impractical.
The Danish grid as of today would work just fine if you cut all the international cables. This will not be the case in the future, but right now the power plants in Denmark would be able to stabilize the grid and provide sufficient power.
I can assure you that no pumped storage exists in Denmark. When electricity prices go negative (which happens a few times a year), the large wind turbines shut down. Some power is dumped as heat in large (many MW) electric boilers for district heating, and hopefully the installation of more electric boilers will virtually eliminate negative prices.
But anyway, pumped storage is not in any way fundamentally necessary for a functioning grid. It is certainly helpful, but when your tallest hill is 173m above sea level, pumped storage sucks.
Life is basically a way to export entropy elsewhere. Life uses low-entropy energy like sunlight and turns it into high-entropy energy like deep infrared in order to stay complex and low-entropy (unusual combination) itself.
The assumption is that if you have more efficient processes, you use them to do more useful work, not to sit around singing Kumbayah. I.e. efficiency increases are offset by increased consumption. This certainly seems like a reasonable assumption for life as we know it.
No worries, someone will design a car with 8 wheels; the usual four plus an extra four that descend to touch the ground only during hard acceleration or braking, thus doubling the amount of friction available.
End-to-end encryption does very little against metadata surveillance. It will obscure what you talk about, which is good, but it will not obscure who you talk to, and the latter is generally what the NSA and its ilk cares most about.
Slashdot Mirror
Astronomers are the ones who are pushing for a standard with leap seconds to be used for general timekeeping. Their lobbying is what is stopping legislation from being sane.
Because it is the astronomers who are causing the problems. They are the ones who lobby to keep leap seconds in UTC.
You can. It just does not help any, because NTP and the kernel will fuck up the system time during the leap second.
The kernel has absolutely no business knowing about leap seconds.
I would be perfectly happy to let my servers run in such a mode, but I do not know of any NTP implementation which allows the system time to be set to TAI. Also, NTP synchronization around the leap second event is a mess, because some NTP servers smear the time.
And finally, if I fail to update one of the servers in the time between a leap second is announced and the time that it takes effect, the server will now be one second fast. Unless it somehow records that NTP showed a leap second event happening. If NTP carried TAI and a separate field with current offset between TAI and UTC, this would no longer be a problem.
The second is defined as "the time of 9,192,631,770 periods of the radiation corresponding to the transition between the two hyperfine levels of the ground state of the caesium 133 atom at rest at a temperature of 0 K" and it stays as it is.
Not on any system connected to NTP, it doesn't.
The "very robust" code can handle timezone changes gracefully, but not leap seconds. Maybe it can be made more robust and handle both?
It can handle leap seconds gracefully, except the warning time is too short. However, if you use time zone handling for leap seconds, you suddenly find yourself without any means of synchronizing your time with the rest of the world. Running like that is not very helpful.
The majority of NTP servers deliver UTC which has leap seconds. Calculate the monotonic time from that. The calculation is in principle not extremely different from retroactively calculating the local time using TZ files.
The majority of NTP servers deliver UTC, which is exactly the problem. There is no way to determine from the NTP time how many seconds elapsed since the start of the epoch. If NTP had been delivering an actually useful time standard, we would not be in this mess.
The only problem with Windows time zone handling is the BIOS time being set to local time rather than UTC. If Windows has a time server configured, it will know whether the BIOS adjustment was made, so it is really not much of a problem in practice. It is only a problem if you dual boot, and that is probably deliberate.
Yes, Java uses its own zone files, but they get updated regularly too.
I haven't had an iPhone for many years, so I don't know how they do with time zones.
Changing from leap seconds to leap minutes would move the problem from NTP to time zone files. Time zone files are well tested, regularly updated, and generally high quality.
We have high quality libraries which can calculate the time difference between two arbitrary times in different time zones. This is not possible for leap seconds, because they do not get scheduled in with a decent amount of warning. Changing time zones is tested in many locales twice a year, it basically never breaks.
If they think a "leap second" is a big deal then a "leap minute" or "leap hour" is going to really cause problems. They'll have longer periods of time for more bugs to accumulate and when they happen everything will have problems because either they'll fail or something they depend on will fail.
Leap minutes or leap hours would be handled by the existing time zone handling, not by messing with the length of a second. That code is well tested and very robust.
Warnings about leap minutes or leap hours could be made years in advance, leaving plenty of time to update the files on even the most remote systems.
And yes, technically leap seconds should be handled via the time zone system as well. GNU even distributes a set of zone files for that purpose, the ones that start with "right" instead of "posix". No one uses them because they break if you use NTP. NTP does not distribute a leap-second free time scale. THAT is the true disaster in all this.
It's not like someone's forcing you to use UTC, UT1R, or one of the other UT systems that are specifically intended to deal with issues of local noon.
That is exactly where you are wrong. We are all forced to live in UTC, because that is what the law requires in multiple countries, and it is the only time distributed in NTP.
Screw you astronomers. You don't really care about UTC anyway; you need to correct for position and find the actual local time, so you can just continue doing your own thing. Leave UTC alone.
I am rarely in a place where solar noon is within half an hour of actual noon anyway. Why do I care if it's 30 minutes + 17 seconds out, rather than only 30 minutes? If night is turning into day, we fix the time zones. They change regularly anyway, and we have excellent methods of dealing with the changes. The code gets tested regularly and the only problem is when legislation gives less than a few months warning of changes. Code which does not like the changes sets the time zone to GMT+0 and all is well. No such fix is possible for leap seconds.
I give you Frigate Peder Skram. Missile coordinates were given to the launch computer, and the Harpoon missile launched, without the launch keys being inserted.
And that was back when computer code was small enough to be reasonably scrutinized.
If you are referring to the MPEG decoding stuff, there is no restriction in the firmware that prevents it from working. It is merely that the RPi's creators require you to buy a licence to unlock the user land software that can make use of it because that is the agreement they signed with the manufacturer.
This is simply wrong. The user land software is the same, the firmware functions are unlocked cryptographically. If it had been user land, cracks would have been available within hours of the release of the software.
Who knows which firmware functions could be unlocked if you send the right cryptographic checksum to the firmware? Perhaps the send_ssh_key_to_NSA function? Unlikely, but it is also unlikely that anyone will ever find out.
Until very recently, the cheapest option to get 10Gbps was SFP+ and Direct Attach Cables. It is still by far the most energy efficient option, unless you use 10Gbase-T with energy saving that lowers the port speed to 100Mbps when not much bandwidth is used (and that has latency implications).
I have not yet touched a single 10Gbase-T-port but 10Gbps SFP+ is everywhere. A few get actual fiber SFP+ modules inserted, but the vast majority is DAC.
Are 10 gig parts that complicated that they're staying so expensive for so long?
Yes. 10Gbase-T runs a complicated encoding which requires power-hungry processing. Note how you cannot buy a 10Gbase-T SFP+ module for love or money; the power/cooling budget of SFP+ does not permit it to exist. Yet you can trivially get optical SFP+ modules designed for 80km, where 10Gbase-T is struggling to reach 100m.
10Gbps+ ethernet for the home will happen, but I doubt it will be 10Gbase-T.
Raspberry Pi is a GPU with a CPU bolted on the side. The CPU is entirely dependent on the GPU, it cannot even boot without it. The GPU driver is fairly trivial; it mostly consists of stub calls to the firmware blob.
The firmware blob is proprietary and closed, to the point that it even has restrictions on which instructions the GPU is allowed to use. You can buy an unlock code to remove the restrictions. Even Android devices are not that closed down in general.
Even gigabit routers (which are technically gigabit layer 3 switches) need an ASIC in order to fully saturate your WAN bandwidth if you are with a gig provider.
Gigabit is reasonably trivial to do in software if you have a half-decent CPU. Get a OneAccess 1645 or a Juniper SRX220 and you are good to go. Yes, you can overwhelm at least the latter with 64-byte packets, but why would you do that? Both are using fairly lousy CPU's.
If you go Intel, it is difficult to find a processor slow enough that it would not route 1Gbps, even if you look at CPU's intended for tablets. Perhaps one of the really low-end phone processors.
At least that way the surveillance equipment gets installed beforehand. Otherwise they have to send in undersea crews afterwards, right at the same time as three different ships accidentally cut three different cables in the area...
If you get the surveillance in beforehand, you avoid a lot of expenses later.
So you think that deregulating nuclear power can yield 50% cost savings or more (since we are removing the primary cost)? Good luck with that.
You're being ridiculous. I am an energy-efficiency wonk. You can build as many nuclear power plants as you want, as long as they can compete with other forms of clean energy on price.
Once we have switched to zero-carbon electricity or at least made polluting forms of energy pay appropriate taxes to offset the damage they do, you can use as much energy as you want. That is between you and your wallet. But until then, your electricity consumption is partially paid for by me. Do not waste MY money.
She brags about her security clearance and about how she knows so much about what is going on. She may not be all that bright, but surely given that information she could figure out why they needed the server capacity.
Her defence of waterboarding shows what a disgusting person she is. I am ashamed that I was working for HP at the time.
Even if Windows was a microkernel and TrueCrypt was running without privileges and so on, I think that many users use TrueCrypt to encrypt their system partition. Once TrueCrypt is compromised, the attacker can replace e.g. SVCHOST.EXE or another critical Windows system file with anything they want. I am not aware of any security technology which can stop an attacker who has broken the file system driver for the root file system. I am not sure what that kind of technology would even look like -- all the ideas I can think of are completely impractical.
The Danish grid as of today would work just fine if you cut all the international cables. This will not be the case in the future, but right now the power plants in Denmark would be able to stabilize the grid and provide sufficient power.
I can assure you that no pumped storage exists in Denmark. When electricity prices go negative (which happens a few times a year), the large wind turbines shut down. Some power is dumped as heat in large (many MW) electric boilers for district heating, and hopefully the installation of more electric boilers will virtually eliminate negative prices.
But anyway, pumped storage is not in any way fundamentally necessary for a functioning grid. It is certainly helpful, but when your tallest hill is 173m above sea level, pumped storage sucks.
Life is basically a way to export entropy elsewhere. Life uses low-entropy energy like sunlight and turns it into high-entropy energy like deep infrared in order to stay complex and low-entropy (unusual combination) itself.
The assumption is that if you have more efficient processes, you use them to do more useful work, not to sit around singing Kumbayah. I.e. efficiency increases are offset by increased consumption. This certainly seems like a reasonable assumption for life as we know it.
No worries, someone will design a car with 8 wheels; the usual four plus an extra four that descend to touch the ground only during hard acceleration or braking, thus doubling the amount of friction available.
Friction does not work that way unfortunately.
End-to-end encryption does very little against metadata surveillance. It will obscure what you talk about, which is good, but it will not obscure who you talk to, and the latter is generally what the NSA and its ilk cares most about.
It is really annoying that "metered" isn't something that the network can announce. Can we get it in IPv6 Router Advertisements please?