I clearly hadn't read more than the first few lines of the help on Java TimeZone info or I could have found out that the answer was already there, without having to wait for it. As another poster pointed out IBM already provides free Java timezone updates.

Let me google that for you! But more to the point, writing a tool that will grab those updates for yourself and storing it where you need it looks like a bash script or batch file candidate. Our brains are more than a match for Oracle's bean counters. Let's use them!

cheers...ank

I've never heard the name Olson before in relation to timezone updates. Thanks for the enlightenment but yes, this article was at least a little bit necessary, if not as earth shattering as an approaching asteroid.

cheers...ank

So, who is surprised by Oracle's move here? Nobody with a eyes and a brain. Oracle just doesn't know what to do with a community.
Does this make Microsoft or C# look so great? No way! They started out less free than Oracle is now and haven't really changed.
Why do I develop in Java (I also know C, C++ [and the assembler code they generate], Python, SQL [MS and non-MS dialects] -- so why choose Java?)? Because I want to write programs for my slightly less shackled Android phone.
And the next plan of action is...?

There are a bunch of options... for starters, google the problem. Next, just wait: some bright spark will put out a tool that uses local time zone info (configurable) to update some Java installation's (configurable) idea of time zones automatically (or not, configurable).

It happened with MySQL, it'll happen with Java. "The more you tighten your grip, the more star systems will slip through your fingers."

Douglas Adams' fictional book cover still has the right initial instruction: "Don't Panic!"

cheers...ank

Does anyone who Knows have anything to say about Bob Cringely's analysis of this departure?

just wondering, hangning up and listening...ank

If you must have a pong, Heiko Selber's honourable mention beats Piotr Dabrowski's hands down, in my opinion -- yours is pretty classy Piotr but I prefer the full field, myself (same reason I detest tablet-ized interfaces).

But I don't think the logo should go crazy on sideways references; hence I cannot vote for any of the other "presented" options. My top 6 are, therefore, #1, #7 and #9 from the accepted list, and Pocholo Peralta's, Erik Berglund's and Pete Mendoza's honourable mention entries.

* #1 refers to these polls, a strong feature of slashdot from so long ago that it might as well be the beginning.
* #7 has classic lines and is self-referential to its topic
* #9 is almost Matrix-y and ASCII-art-ish without being a 100% send-up of either
* I preferred Pocholo Peralta's logo over Sean Murphy's #31 because I view animated graphics, generally, as abominable. This works in the 15th anniversary theme tastefully and effectively.
* Erik Berglund's logo embodies slashdot's quirky take on everything -- give it a twist!
* I like Pete Mendoza's contribution for the same reason I prefer #7 to the ones to vote for. I'm disappointed that nobody used the default Slashdot logo font in the same way, actually.

I think I'd have to vote for #1, as much as anything because I can suffix my vote with

you insensitive clod...ank

In 27 years of professional software development I have watched numerous co-workers succumb to various RSIs, require ergonomic keyboards just to be able to bear the pain of working. The one difference I notice between me and these unfortunate folks is this: I avoid using the mouse.

I use keyboard shortcuts, I prefer a text editor that allows me to do everything including navigating from a standard QWERTY keyboard (in my case, the One True Editor, vim but there are other options -- I've also used BRIEF, OS-9's stylograph and IBM's Personal Editor in my time). Hot-keys, short-cut keys, accelerators, anything that keeps my hands on home row have been my safeguard.

It's also fair to say that I have been playing piano since I was 5 but I still think that "stay away from the mouse" is the best advice anyone will give you.

cheers...ank

Because when you learn it you may gain a whole new way of looking at the languages you already know.

cheers...ank

If someone thinks wikipedia looks so ugly, let them do the hard work of designing new CSS suites for what they think should look great

especially "...if you can't hold a developer for five years, then you have a morale problem that will cause pain..."

never said a truer word. even difficult legacy code can be endured if the company has no systemic negative morale factors.

cheers...ank

Sorry... just to be clear "This kind of comment" was referring to the question, "Why is Wikipedia so ugly?", not to parent. I agree with parent 100% and more.

cheers...ank

This kind of comment comes from the same kind of morons who brought us the re-tooling, for instance, of GMail. It was great (to use) the way it was. Now I hear nothing (NOTHING!) but complaints about it (or blank stares which when probed yield statements of powerlessness). If the underlying code was ugly, the first update cycle should have been to upgrade the code in a way that none of the users would notice.

Note to Jimmy Wales: resist the UX-groupthink mob who would tell you to make Wikipedia more tablet friendly. If it's ugly, it's ugly the way the old White Pages were ugly. Ugly and informative. The way a real newspaper used to be ugly (especially the front sections up to where the editorials, letters and Op-Ed pieces lay): ugly, information rich and informative.

Note to the groupthink mob: if you must make something tablet-friendly, make sure it's still screen friendly during the design before you foist it on those of us who haven't caved-in to constant computing through tablet ownership.

<quickly hitting submit before going off and doing something real>...ank

Agile is just a structure. Like anything else, it's only going to be as good as the people you put in place to execute it. A properly constituted agile team will put documentation (of designs, code, deployment, whatever) up as stories/tasks that need to be accomplished right alongside working features. Documentation is an end-product just as surely as working code and unit tests are.

If the team doesn't identify those tasks and sign up for them, you hired the wrong people. Reform your recruiting process before you blame a process that delivers a working solution at the end of every sprint. And if your so-called Agile doesn't pretty much do that, then you really are being scammed.

cheers...ank
(I've been a developer for 26 years; some form of Agile has covered the most productive and enjoyable parts of my careeer)

Because Apple's rate of innovation is about to drop past the rate of Microsoft's innovation?

First, thank you so much for this. Someone else has already talked about Most Informative Post to slashdot this year. I agree.

Second, your point on peer review and secrecy is well taken. In the case of Polywell, the only reason it's known about outside the US Navy is the invasion of Iraq and now that they have enough money to pour into it once again, it's going dark again. Whenever I hear complaints against Polywell about peer review, I feel a bit like Bussard and his team are being painted with the Cold Fusion brush which isn't fair. It'd be nice if someone could take the data that's already out in the public and find enough funding, at least to try to duplicate their results. Or is the data that's out there even enough for that?

Whatever other things get blamed, I still say it's secrecy that hampers scientific advance more than anything else.

This doesn't get a lot of public exposure. I had never seen this diagram or anything like it.

But some of the rhetoric sounds a bit weird: "We predicted this result (experimental) in the 70s and achieved it in the 90s." Now that's a long development cycle. In the meantime, I got impatient. Can anyone blame me?

And I still have a problem with doing D-T fusion that sends so many wild and crazy neutrons out into the world where they'll make things outside the reaction chamber radioactive (or brittle) (or both). Don't the inherent risks in that reaction make it incumbent on us to find other source reactions that don't have those problems?

But thanks for the link. That was interesting...ank