Catch up on stories from the past week (and beyond) at the Slashdot story archive

 



Forgot your password?
typodupeerror

Comment Re:The problem, and the IMHO correct solution. (Score 1) 233

Hello there cpt obvious. :-)

The implementation we have at Google is obviously just 'yet another hack'. It's not lossy in the same way as unix time is lossy - but we're using unix time, but with a "hack" to avoid having a repeat-second.

It's a nasty hack. It works, but it's nasty.

Comment Re:The problem, and the IMHO correct solution. (Score 1) 233

Thanks for the pointer! I've just had a skim through it.

Initial thoughts: code is king. If it gets adopted, then that's what we have to deal with.

Personal opinion; the standard is .. not the way I'd like it to be. Neither for TZ nor leapsecond information. I dislike the idea of stashing this in a SRV record in DNS. I dislike the lack of authority on where the information comes from. A laptop moving from one network to another could be in contact with systems that provide TZ data from different sources, but legitimate from the standard, instead of a single source of internet-wide truth.

I furthermore dislike the complexity of the standard. The TZ data really doesn't need localization. This can be provided client side. Imagine a laptop talking to one TZ server not understanding the replies from a different one, due to localization [not entirely sure if this is correct, I might have skimmed too quickly].

Then we have the 'version' string in the replies that is sloppily defined. Why have it so general, instead of a simple .. timestamp in seconds since epoch?

There are lots of other nits and pieces I rather dislike - but also the entire idea that we should base it on HTTP and JSON. It also seems a bit too closely integrated with iCal from the get go.

To sum it up: I'm not a fan of the standard. But as I didn't put my money where my mouth is and created my own when I started becoming interested in this problem some ~10 years ago, I'll go "mergh. ok then" if it's adopted in general.

Comment Re:Massive stupidity (Score 1) 233

David Mills approach is a hack around a broken standard, namely POSIX.1. It's a good hack.

Your solution is obvious and correct, but isn't possible to implement while being POSIX compliant.

We all suffer from a broken standard. It's not possible to be both posix compliant and doing this correctly.

Comment The problem, and the IMHO correct solution. (Score 4, Interesting) 233

First off, the problem with leap seconds and unix is that unix time isn't UTC. Unix time is defined as seconds since epoch, ignoring leapseconds. Unix time is 'lossy' in that a the moment a leapsecond occurs can't be differentiated from the second before it. More information about that here: https://en.wikipedia.org/wiki/...

The problem is that POSIX.1 is plain stupid when it comes to leapsecond.

The correct solution to this problem would be as follows:
1. Fix POSIX.1 to define unix time as TAI.
2. Implement conversion routines i gettimeofday and other relevant functions.
3. Use a handy store for leapseconds.

Now, number 3 here is a bit tricky. Purists would probably want this in the TZ database or somesuch. This is well and good, but has the problem that the TZ files need to be packaged and updated on all the servers. If I remember correctly (please correct me if I'm wrong) Java is shipped with its own TZ files, and might also need them updated separately. Due to this, I think the most maintainable and portable way to do this across unixes would be to simply have an /etc/leapseconds file which lists the leapseconds since epoch. It does, however, depend on unix time being defined as TAI first.

Comment Re:Why is this on Slashdot? (Score 1) 221

Sometimes I wonder whether the US has a similar troll-farm like Russia has. Where people get paid to post inane comments instead rational thought.

If you actually aren't such a troll, it might be a good idea to read up on who the person is, and read up on the issue at hand.

Comment Re:YANAL (Score 1) 245

No, the most annoying thing in IT is the person you're responding to, who doesn't understand how TLS for email works in the first place, but pretends to do so, and participates in discussions as if he knows the subject matter at hand.

The error being that there is no encryption applied by the person who writes the email, but opportunistically by the email servers if both sending and receiving email servers supports TLS. This is done transparantly to the end users (ie the people who write the email).

Comment Re:Always RTFA (Score 1) 245

Oh come on.

It's always hilarious when people pretending to be techies on slashdot discuss technical matters without understanding the matter at hand.

There is no encryption being removed here. What is being removed is the negotiation of encryption. There's a huge difference.

What happens here is that modern MTAs that are configured to use TLS will issue a STARTTLS command to the receiving email server. If the receiving email server is configured to accept TLS connection, it will respond in kind. If it rejects the command, the conversation continues unencrypted.

Most email servers are still not configured to use TLS.

What happens in this case is removal of ngeotiation of opportunistic encryption. It's of course very very wrong to do this, but it does not remove existing encryption - it prevents it from happening in the first place. It makes the parties believe that neither side supports it.

Comment Re:so what's ARPA doing in my computer? (Score 1) 85

If that was a serious question, and not trolling:

The in-addr.arpa DNS zone is used for reverse DNS.

Basically, you forward-map hostnames to IP addresses. At the same time, you can reverse-map IP-addresses to hostnames.

The forward mapping is done via 'A' records.
The reverse mapping is done via 'PTR' records, and it's done in the in-addr.arpa hiearchy.

Comment Run away! (Score 4, Insightful) 294

Given your description, you're the sole sysadmin. This means you're the person who should take these decision - nobody else. If the company disagrees with this, then either you've done a poor job previously, or they don't trust you to do your job for some strange reason.

Now, if it's you that have fscked up on previous occasions, then it's understandable that they want the red tape.

If you haven't, then it's time to put down the foot and say "Nope, that's my job". If they disagree with that - linkedin should be a relatively short distance away, and after you find yourself a new job - simply hand in your resignation pointing out that you have no interest in having babysitters.

Comment Re:turnover? (Score 1) 142

What repopulates the area? Easy.

Taxes & import duty are very tiny. You've got some of the most beautiful nature you can imagine. There's lots of researchers connected with universities etc. - making for lots of interesting people to talk with.

A lot of the turnover is actually students wrapping up their studies.

"Once they go up, who cares where they come down? That's not my department." -- Werner von Braun

Working...