Follow Slashdot blog updates by subscribing to our blog RSS feed


Forgot your password?
Check out the new SourceForge HTML5 internet speed test! No Flash necessary and runs on all devices. ×

Comment Unfortunately the most important building is gone. (Score 1) 80

.. and I never got to see it, only the sign that remains. Namely the building that hosted the Shockley Semiconductor Laboratory. The lab that basically started Silicon Valley.

It was located at 391 San Antonio Road, Mountain View, California. Now all that remains is a signpost.

Comment Re:New Math Needed?? (Score 4, Insightful) 126

Uhh. When you start something new, you come up with a prediction. You don't necessarily base it on that much information.

Then you observe what happens when you do an experiment. Then you adjust your predictions.

This is how basic science is done. Nothing new here.

HOWEVER; what you're trying to do, is transfer errors in initial prediction into errors in observation and measurements. That is rather disingenuous of you. Please do argue honestly.

Comment Re:If not now... (Score 1) 1023

and that's why they're soooooooo big on everything being exactly the same in every restaurant (food-wise, anyway). You go there and you know what you're gonna get, no surprises. It's one of their keys to success.

But, you're wrong.

If you've been to McDonalds in the US and compare it to say McDonalds in the Philippines - you should notice a major difference in the food.

First of all, the US version will be flat, horrible and not look like the pictures at all. It's to damp buns with a meatpatty in the middle. Or three damp buns with two meatpatties for a Big Mac. With some salad. And it looks horrible.

Now, if you order the same thing in the Philippines, or any other country where a McDonalds job is a GOOD job and not just what poor people and students do - and you'll see the burgers being beautiful and look like in the *pictures* in the resto. The texture and taste is better too.

Comment Re:The biggest improvements involve the past sucki (Score 1) 177

Oh Kjella, how I disagree with you!

The leap from LP -> Cassette -> CD -> Music DVD -> Music BlueRay/whatever are much smaller than the leap from [Physical media] -> [small convenient files]

You can argue that the CD was digital and didn't require special ripping, you could just read the bits of'em and then play them from a computer. Except most computers didn't have 600MB drives in the 80s when the CDs started appearing. Those weren't common until around the mid 90s. And who would want to use their entire hard drive to rip a CD?

The amazing jump was when we went from having a handful of music, an album or so, per physical unit .. to having a physical unit containing more music than you're probably ever gonna bother listening to. That was the huge leap.

The same with VHS->DVD->Blueray. Whatever. It's a movie per physical unit. Now, if we just use a good codec for compression we can rip this into a nice mkv file with tons of subtitles and audio tracks for various languages - and store an amazing number of them on a simple USB stick. If we're not afraid of carrying around a little external usb drive, we can have *thousands* of them with us. Compared to one per unit with the 'old' style.

Comment Re: never heard of it (Score 1) 264

It was big for quite a bit more than a week. Several years in fact. But then it just .. died. Which was sad.

I seem to remember it basically died and nobody cared for it anymore around 2002-2004 or thereabouts.

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 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:

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.

Slashdot Top Deals

Real Programmers don't eat quiche. They eat Twinkies and Szechwan food.