Um, last time I checked (which was a couple of weeks ago) the Munich project was going extremely well.

Well, I live in Surrey, and regularly travel between Woking, Guildford, London, Oxford and Cambridge (I don't have a car). And I literally can't remember the last time a train I wanted to travel on was cancelled, or sufficiently late that I missed a connection or important connection.

Although in fairness I must point out that, despite running on time, First Capital Connect trains from Kings Cross to Cambridge are incredibly shitty and crowded.

Don't forget, folks: the plural of "anecdote" is not "data"!

Confirming that the "environmental concerns" are really concerns over property prices on the part of people rich enough to own country homes in the Chiltern Hills...

Note that the biggest problem with that route is the section between Cardiff and Swansea, where the terrain is so hilly that the only way to speed up the existing tortuous train route would be to rebuild it entirely with lots of tunnels. Note that the main reason that the government recently decided not to electrify that section was that the increased speed benefits of lighter, faster electric trains would not be realised on that section of line.

Once the trains get past Bristol, they do get up to full speed. Also, note that the three hours on that route includes several stops, which bring down the overall average speed quite severely! London to Brussels only stops at Ebbsfleet, Calais, and Lille on the way, and runs on very high speed lines all the way.

I don't think it's really fair to compare those two routes, TBH. When you think about it, the Swansea-London trains are actually doing pretty well...

They are building the line to the European loading gauge. The line is designed to be fully compatible with European very-high-speed lines, as DB and SNCF have expressed an interest in running through trains from European cities to Birmingham through the Channel Tunnel once the Eurotunnel monopoly expires. Additionally, the line is being built to serve very long trains (up to 12 European-length carriages).

All-in-all, the wider/taller loading gauge (which provides the option for double-decker carriages) and the long platforms will mean that HS2 will provide enormous numbers of seats between London and Birmingham.

It's not practical to upgrade most UK lines to the larger gauge, because it would mean rebuilding every station, raising every platform, re-laying every piece of track with wider separation (displacing hundreds of thousands of homes and businesses near train lines), widening every cutting and embankment, rebuilding every bridge, and reboring every tunnel. It would be possible, but not politically viable (imagine the voter response to being told that there will be no train service between London and Bristol for the next five years due to regauging, and oh by the way, we're taking half your back garden).

Yes, that's probably exactly what they're after.

It's a pretty trivial board. I'd quote at most a day's work (8-10 hours) for a board of that complexity, even assuming I was handrouting the whole thing...

Xilinx Application Note 623 is an excellent introductory guide to PDS design.

Just to expand on your points: the main thing to bear in mind is that the higher the frequency you're running it, the smaller the cap values you need and the more important it is to keep loop inductance low. There are two cases in which I place my decoupling caps on the reverse side inside the package footprint (usually BGAs have an area free of pins in the centre of the die). Firstly, when I'm running at very high frequencies (> 100 MHz) and it's essential to use really tiny capacitors. Secondly, when I have a very restricted number of layers and putting the caps inside the footprint simplifies my fanout.

Thank you for confirming that Java sucks for anything that needs to be slightly performant.

I don't know of any architectures that can do unaligned compare-and-swap of a element with a non-power of two extent, so you need to use either a 64-bit (CMPXCHG8B) or 128-bit (CMPXCHG16B) combined value.

My issue with .NET is its lack of portability and extremely dubious legal status. I have no opinion on the language's technical aspects.

java.util.concurrent.atomic is a perfect example of why Java is not a viable choice for the work I'm doing. One of the tasks I currently have to handle is multiprocess disjoint set construction (using the wait-free union-find algorithm), on a very large corpus. This algorithm requires each disjoint set tree node to contain two fields: a reference to its superset, and a rank counter. In Java, the only choice I have is to use an array of AtomicStampedReference<V>, which will always occupy at least two platform words. Because I know the exact size of the corpus, in C I can easily do some trivial pointer arithmetic to halve the amount of storage required on 64-bit platforms. Not only does this allow me to process larger datasets on my workstation without suffering from memory exhaustion, but because the computation turns out to be memory bandwidth-limited, it allows me to process it faster as well.

Oh, and .NET can DIAF.

I was talking about multiprocessing, not multithreading.

I'll switch to using a language other than C when a language other than C allows me to use wait-free shared-memory multiprocessing algorithms.

Yes, because that's exactly what's going on here.

Oh wait -- no it's not, it's something completely different!

I watch every episode of Top Gear and enjoy the show immensely, but even I think that segment was extremely dodgy, to say the least.

Well, at the moment, the University of Arizona is. At the moment the Biosphere 2 facility is being used to do research into climate change, among other things. The researcher I was talking to was doing research on soil ecologies, IIRC. There are lots of practical Earth-bound applications for this kind of application.

Also, the second Biosphere 2 mission (1994) was a success, in that the crew managed to achieve self-sufficiency in food (and oxygen) production...