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


Forgot your password?

Slashdot videos: Now with more Slashdot!

  • View

  • Discuss

  • Share

We've improved Slashdot's video section; now you can view our video interviews, product close-ups and site visits with all the usual Slashdot options to comment, share, etc. No more walled garden! It's a work in progress -- we hope you'll check it out (Learn more about the recent updates).


Comment: You can keep secrets (Score 4, Insightful) 155

by valen (#28907139) Attached to: Apple and the Scalability of Secrecy

  So, this is bullshit. You can keep secrets as long as the people involved think secrecy is warranted.

  Google have an astonishing track record of not leaking projects to the press. They've worked on some incredible stuff, and the vast majority don't get leaked at all, or get leaked accidentally. Huge numbers of internal/infrastructure projects never get told about outside the company. Sure, some projects are pre-announced because by working with outside companies they assume there will be leaks (ChromeOS, Android).

  Internally people get told "Please don't leak unannounced projects. A leak could cause your co-workers to have to launch an unfinished or unpolished project ahead of time, reducing the impact of months or years of their time".

  The problem with Apple is that they work with a lot of outside agents, all of whom can leak without thinking of the personal consequences to friends, just financial/legal ones (which can be avoided). Their own engineers have a pretty good track record of keeping quiet about 'important' things.

Comment: Re:Gee, thanks for the notice (Score 5, Interesting) 255

by valen (#26256057) Attached to: Leap Second To Be Added Dec 31, 2008

Yeah, we had problems in Google with these too; we have large networks of machines that used to use multiple different NTP servers (for resilience). Turns out not all NTP servers implemented leap seconds the same way, and many cluster based applications get upset when they aren't synchronized to within 100ms.

  Now, we run a dry-run of a fake leap-second with all software a few weeks before the leap-second failover. It's the only way to be 100% sure that applications changed since the last leap second won't have problems. Though, most unittest frameworks now have the ability to implement second skewing, since the suffering caused by the 2005 leap second.

  The main problem is that the POSIX description of how to do a leap second is retarded; you basically go from 00:00:00 to 00:00:59, some apps also get upset when they see the same time twice.


Great spirits have always encountered violent opposition from mediocre minds. -- Albert Einstein