No, they're saying that you can't just take their research and make claims that it doesn't substantiate and then appeal to their authority to support your claims.

To give a computer science analogy (I'm out of stock of car analogies), imagine that you worked on Hadoop and you'd made sorting large data sets go 50% faster. Then someone publishes a book arguing that P=NP and uses your result (which doesn't even do comparison-based sorting) as the basis for their claim. You'd be in pretty much the same position as the researchers in TFA. Would you say that the author is an idiot, or would you keep quiet?

Crusade had a few bad episodes, but hinted at some interesting story arcs and was mostly fun. Legend of the Rangers was mostly good, but fell into the trap of 'here's a big bad enemy who's even bigger and more bad than the last big bad enemy you fought'. It would have needed a later episode to discover (quite soon!) that The Hand were overstating their abilities and history.

I suspect that part of the problem is that JMS won't embrace new distribution methods. I would happily throw $50 into a pot to create a new series in the B5 universe to be released under a license that permits free non-commercial redistribution, with commercial boxed sets available for purchase for collectors. I suspect that there are enough B5 fans who'd be willing to do the same that it would be possible to finance one.

I enjoyed Crusade, but it was killed before any of the major plot elements could be resolved, which was annoying.

Some do. For example, there's a big window in the captain's office that looks out over the centre of the station (they're really inconsistent about gravity in B5, but that's a different issue), and it was only when I watched a 'making of' thing after seeing the entire series that I realised that it was meant to be a window. I thought it was a painting. I still think the space scenes look okay, but some of the backdrops - especially on planets - are pretty bad. They used CGI because they couldn't afford the location / model work that bigger-budget shows used.

The flashbacks to the telepath war in Crusade make it look interesting, and apparently it is in the novels. The real problem with season 5 was that it was set in the lull between interesting things. After the Shadow War, after the Civil Wars (human and minbari), but before the Telepath War or any of the other things that JMS had put into the timeline. Even the fall of Centauri Prime was more setup than main event (providing a base for the Drakh to operate from over the next 20 years). It was Part 1, but you can't put Part 1 at the end of a 5-year story.

Boxleitner grew into the role, but at the start he lacked the gravitas that O'Hare brought to the part. He just didn't seem like someone that I'd trust to be in charge of something as complex as a battleship, let alone a huge diplomatic outpost.

ARM's Mali has supported OpenCL (not just the mobile subset) for a couple of generations too. The problem is that Google hates OpenCL and tries hard to make sure that it doesn't work on Android. I don't know what makes nVidia think that they're different in this regard.

Oh, sorry. I was thinking of Sean. Both of you switched jobs at almost the same time.

How long ago and what were the games? On startup, The Witcher 2 (which isn't even a very recent game anymore) seems to read several hundred MBs and then loads more for each environment. Fast random reads would seem to be a benefit there - the CPU in my laptop isn't at 100% even reading the data from SSD...

The reason that we've open sourced our CPU (not the one in TFA) is to promote research. The vast number of papers published in computer architecture conferences and journals evaluate their approach solely on a simulator and hope that there's some relationship between the simulator and reality. While a softcore CPU is not exactly like a real CPU, being able to implement your ideas in an FPGA (and pass timing!) does at least mean that it is possible to implement them in a real CPU, although it doesn't guarantee that they'd be more efficient than another approach. It also lets you do evaluation with real software: we can boot FreeBSD on our system and run real programs on it for benchmarking, which is a lot more realistic than taking some existing instruction trace, permuting it based on some assumptions, and then feeding it into your simulator.

I have here a log file containing the output from a command-line build of our CPU using the Altera tools. This file is 10460 lines long. The relevant information it contains can be summarised as: No errors, passed timing.

Occasionally, we've had serious issues reported (the reset line on the ethernet MAC wasn't connected, so ended up being set high, which cost us over a week of time debugging the driver and trying to discover why the FIFOs weren't behaving correctly), but they're hidden in so much noise that there's absolutely no chance that a human will ever see them. They're not differentiated from trivial warnings that no one will ever care about.

In the software world, we've (with my Clang developer hat on) learned that warnings have to have a low false-positive rate or you end up with everyone ignoring them. We therefore expect reasonable developers to be able to set -Werror on large codebases and fix everything that breaks the build. If your code doesn't build with -Werror, then it's a big warning sign.

In the FPGA world, thousands of warnings (and even more 'information' lines) in the output are normal for any nontrivial build.

This is precisely the issue that we have. Our core (MIPS IV compatible, 7-stage pipeline, branch predictor, SMP support) is open source (Apache-style), but it's written in a proprietary high-level HDL. After compiling it, you get Verilog, but even that isn't very useful by itself. There are a few open source Verilog simulators, but if you want to either run it on an FPGA or synthesise an ASIC, you're going to need proprietary tools. There's little incentive to produce open source versions, because they tend to be tied quite closely with their targets (either expensive FPGAs or even more expensive fabs).

I like the APIs for Apple's PDFKit, but without cross-platform support I wouldn't use it for anything other than toy projects.

Having the source doesn't help you if it's an unmaintainable piece of crap, which is presumably where the OP's requirement for a community came from - if a load of people are hacking on it actively then there's a good chance that, if you end up needing to maintain it in-house, there's a pool of people to hire or send consulting work to.