Sorry, that information has been blocked.

Only if it also includes easily-exploitable security holes.

A lot of the longer songs also had "chopped" versions that were used for radio play. Especially if they had long drum solos or the like.

Although Attention Deficit Disorder is pretty much the order of the day these days, even back in simpler times, pop radio favored short songs over longer ones. If a particular number didn't amuse the listener, then keeping them short ensured that the listener would be less likely to switch to a different station, since the chances of something more agreeable coming along shortly were relatively high. Conversely, if your station is broadcasting the "Ring of the Nibelungs", then you'd darn well better be interested in the Nibelungslied, since you're in it for the long haul.

One thing that has disappeared over the last few decades is album-oriented play and its close relative, the late-night "album hour". That's where longer words such as the Dark Side of the Moon, Bob Dylan's extended ballads and Inna Gada Da Vida were most likely to be heard.

Again, just because a stopped clock can be indicating the correct time, that doesn't mean that it can be relied on to indicate the correct time. You cannot "bootstrap" credibility from an un-credible source just because the un-credible source sometimes repeats the truth. That is just as true whether you assert symbolically (mathematically) or in words. The mathematics, after all, is merely a codification of the words to permit seeing the problem more concisely.

An un-credible source may emit both true and false stories, but because it's un-credible, you cannot draw any conclusion as to the truth or falsehood of any invividual story. For that, you must disregard the un-credible source and go find credible ones.

To do otherwise is the opposite of wisdom.

It did and it didn't. On the one hand, it added a "New York Post" aspect that's not worth the screen space it pollutes.

On the other hand, it spews out a lot of general political nonsense in its editorial pages. But then, that largely predates Rupert's takeouver. And besides, if it wasn't for editorial pages, where would the wackos of the world get a chance to speak? Outside of talk radio, anyway.

On the gripping hand, the WSJ does seem to be reasonably sane when it comes to purely financial matters. David Wechsel's appearances on NPR always seemed to me to be relatively free of the sort of wishful thinking that ideological thinking colors interviews and reports with.

You are referring to the mathematical logic concept known as "implication". Just because P implies Q doesn't mean that Q cannot be true event if P is false, only that Q MUST be true if P is false.

Therefore just because Q is true, that doesn't make P a credible indicator. When Q is true, it is true regardless of P's truth or falsehood and therefore lends no credibility to P.

You're trying to turn it around and imply that just because a non-credible source occasionally reported the truth that you can therefore automatically accept that source's assertions are always true or that that particular assertion has somehow become credible all by itself.

You cannot "bootstrap" the credibility of a source off a one-off sample. Just because a stopped clock shows the correct time doesn't mean that it can be depended to do so anytime you look at it.

It rates up there with "the Enemy of my Enemy is my Friend" - they've already proven their ability to be an enemy.

I'm skeptical about that assertion. Windows doesn't have d-bus either. A d-bus interface doesn't jibe with "write once/run anywhere", so I'm doubtful that the standard JVM would have such a thing in it. We had enough trouble convincing Sun that if there were OS's that didn't support environment variables that the degenerate case of an apparently empty environment was compatible.

They stopped functioning long ago. It's damage control I'm more worried about now.

Maybe it's better now, but not that long ago I recall many an update announcement for Java where the update specifically stated as not being available on Apple.

Actually, Maven is the exact opposite of "let's download random code".

One of Maven's primary virtues is that it allows you to pull specific versions of the various products to produce a consistent result.

Unless, of course, some idiot substitutes "grab anything" for version numbers in the POM.

Crap programmers are cheap and plentiful and until customers demand the same levels of reliability from software that we routinely expect from hardware, crap software is what we're going to get and the software vendors are going to laugh at us all the way to the bank.

You can program crap in any language, of course, but better Java than a late-binding scripting language. At least in Java a certain percentage of the bugs get winnowed out at compile time. Which is why scripting languages are the "in" thing. If you don't have to fix errors at compile time, you get "done" quicker and you're "more productive".

The operative keyword is "Mac".

Apple has never been all that supportive of Java. They have their own agenda, and unlike Wintel, it wasn't a big enough market to make Sun/Oracle want to spend time doing the work that Apple didn't want to do.

Probably doesn't help that Apple has a reputation for being somewhat hostile to developers who want to do things Apple didn't do first.

The worst offender in the "custom JVM" variant was Microsoft and Visual J++. Which varied so much that Sun sued and won to stop them from peddling it.

Oracle was another big offender. IIRC they were hung up on Java 1.3 long after its corpse should have rotted away.

The big-name vendors are like that. They'll warrant their products for one specific platform because they don't want to deal with the cost of being more flexible, and often they'll even bundle their JVM of choice right in with their application.

Sun didn't jerk around minor releases, though. If a minor release change broke something it either had a bug in it or it had repaired a bug that someone else was exploiting in their applications. And, unfortunately, bug fixes are a major part of almost all language systems, so you cannot single out Java for that.

Java does port well. I spent years developing Java apps on 32-bit Windows machines to be deployed to 64-bit Sparc machines without any problems. But that's because I didn't get cute and attempt to exploit hardware or OS dependencies. It wasn't like it was that hard to do.

Pascal, unlike Java, was not self-contained. The primary examples being functions like println. More importantly, it wasn't object-oriented (although some OO variants were experimented with). And like it or loathe it, when you have a really large project, having stuff compartmentalized into predictable objects has some major selling points.