Comment Re:I thought this was a crypto/cypher challange (Score 2) 107
This sounds like they are more interested in recruiting people to analyze stuff like Stuxnet
Yes, that's probably exactly what they're after.
This sounds like they are more interested in recruiting people to analyze stuff like Stuxnet
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 has some good info on bypass caps and how they can be placed in their Spartan 6 docs.
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.
In contrast, C# has value types (structures), so it can pack the "value" reference and the "stamp" into either 2 pointers, or 1.5 if you mix 64-bit pointers and 32-bit ints. In C#, arrays of value types are packed, so the total size is... 1.5-2 pointers per entry, just like in C.
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
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
I was talking about multiprocessing, not multithreading.
Meanwhile, this Java code will work on all platforms, processors, and compilers, forever and ever:
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.
I'm sure you're right - it should be possible. But the point is that we don't know how to do it, and we'd have to spend some considerable amount of time and money to figure it out... in addition to all the other time and money requirements to build a starship. Who's paying for all this?
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...
As Elon Musk regularly points out in his press appearances: the land was not a "nice place to live" for fish, but eventually proto-amphibians crawled out of the oceans, overcoming the many challenges of adapting to such a hostile environment. The moon and Mars are not "nice places to live" for our species, but we already have the tools we need to tackle and eventually overcome the challenges that they present.
The Concorde was not grounded because of technical difficulties, it was grounded because of economics. No-one wanted to pay for the luxury of supersonic flight.
This is actually a drastic simplification of the rather complex reality. Firstly, the crash on in July 2000 was not due to a Concorde design or maintenance fault, but its robustness to future FOD damage was nevertheless greatly increased by some subsequent modifications. Secondly, the "return to flight" coincided with the massive slump in all air travel following the September 2001 terrorist attacks, which reduced consumer confidence, but most indications suggested that demand for Concorde resumed relatively quickly. However, the slump for all air travel created the perception of lack of demand for Concorde. Thirdly, both Air France and Airbus were, in fact, profiting from Concorde operations, but felt that profits could be increased by retiring the aircraft and concentrating on subsonic services. Finally, Air France was concerned about potential liability in the case of future accidents. Note that Richard Branson's attempt to purchase and continue to operate the Concorde fleet was stymied by Airbus refusing to provide continued maintenance, not by lack of demand.
Demand was present, and it was feasible to provide supersonic air travel at an economically viable price point. I think that the EADS/Japanese collaboration on NEXST/ZEHST is a good example of how the industry is still looking at ways to meet that demand.
He obviously worked at CERN. Don't be sarcastic.
The second problem is a ship going that fast will accrue mass as it gains speed. Even if we handwave away the issue of powering it, you still get to the point where you're flying a black hole. As you make your way through the cosmos you'll be causing all sorts of mayhem in the solar systems you pass.
Sounds awesome.
Also sounds like you've read Tau Zero by Poul Anderson.
"Protozoa are small, and bacteria are small, but viruses are smaller than the both put together."
