mtdev

They have a bunch of stuff on their eBay page that is not on the floor but is available for local pickup.

This article is a little misleading in that it seems to indicate that FB will trash Xeon servers and drop in ARM processors. Current ARM processors (SOC and standalone silicon) have poor data throughput. You can mask this using media accelerators, e.g. decode x264 video in the GPU so you have smooth playback while saving some data bandwidth. ARMv8 (allegedly sampling in 2014-2015) will double the AHB/CoreLink width and instruction size to 64 bits, but we are not there yet. What is much more likely is that they will incorporate specialized hardware using FPGA/ASIC and use ARM cores as supervisory modules. That way, they can use a general purpose OS and use ARM tools to develop for the supervisor module, and still get the data throughput of the custom controller. This is how data processing is already done on 1080/2k/4k video streams. Xilinx and likely Altera already provide FPGAs with hard ARM cores (in addition to IP for soft cores) which makes it very easy to roll your own data controller with an ARM core managing it. Makes a lot more sense for FB to go this route for custom NAS boxes, possibly network switch/router hardware to follow in Google's path.

Focusing on mainly on electronics, I will agree that hardware is having a glamour moment, but not because more funding is available. I am an embedded designer and I work closely with several hardware startups (in silicon valley and other places) ranging from novel LED lighting to data acquisition systems. Every one of those startups had to bootstrap themselves until they were financially viable from sales before they were able to get any outside investments. My sample size is small, however, the data agree five out of five times.

The article is dead on with respect to the falling costs of prototyping, I would also add the falling cost of integrated circuits in general. For example, I can get high quality PCB prototypes for about $30 shipped in one week (5cm x 5cm, two layer, 6/6/6 design rules). This was unheard of five years ago. Furthermore, you can now get a 32-bit ARM processor (which doesn't need many external components) in the same package as 8-bit microcontrollers for about the same cost. You can run a open-source IP/USB/BT stack on those without having to cobble together your own. Having the extra performance available, at the low cost/high integration factor, allows the designer similar agile capability as compared to lean software startups, where you can use available code to prototype first and then optimize after you have your feature set. This makes it easier to develop smarter devices that integrate with a broader software stack, e.g. cloud connected embedded devices.

You can add some functionality to limit scope and implement a caching system (which is also proposed here) to deal with M*N issues with a focus on keeping backwards compatibility. E.g. the caching is done automatically, the scope spamming control is a best effort solution based on static analysis (for example).

Moving from headers to modules is a fundamental change in how the language operates and is guaranteed to further break compatibility between compilers further. I worry that jumping to add these features to the language standard is premature and we should instead look further to optimizations within the preprocessor and linker to see if we can improve performance first.

You can maintain backwards compatibility while fixing bugs. It's equally a Big Deal to have discipline while working on language architecture to minimize feature creep/bloat.

Looks like the core issue is a poor preprocessor implication. It's a good idea in principle, however, we would be adding new features to address shortcomings in existing features instead of fixing the problems in the existing code.

I don't see any contact info in your profile, send me an email (contact in profile) and I can set something up.