Please create an account to participate in the Slashdot moderation system


Forgot your password?
Slashdot Deals: Cyber Monday Sale! Courses ranging from coding to project management - all eLearning deals 25% off with coupon code "CYBERMONDAY25". ×

Comment Re:They want to shift the problem to someone else. (Score 1) 291

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.

Comment Re:They want to shift the problem to someone else. (Score 1) 291

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.

Comment Re:They want to shift the problem to someone else. (Score 1) 291

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.

Comment Re:Let me think about it for a second .... (Score 1) 291

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.

Comment Re:They want to shift the problem to someone else. (Score 1) 291

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.

Comment Re:If you can't deal, don't use UTC (Score -1) 291

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.

Comment Re:false premise (Score 1) 121

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.

Comment Re:Yeah, a cheap 10 gig switch. (Score 1) 121

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.

Comment Re:Yeah, a cheap 10 gig switch. (Score 2) 121

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.

Comment Re:false premise (Score 1, Informative) 121

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.

Comment Re:No (Score 1) 121

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.

You don't have to know how the computer works, just how to work the computer.