Anyone considering doing a raspberry pi project may want to look at the new beaglebone black. It is marginally more expensive, has better performance, is completely open and has a fairly good software support community.
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.
The initial mobius.io device has 16 general purpose I/O lines, several serial ports, and analog in, so it is much more flexible than Nest. As for Android@Home, mobius also has its own cloud service, so you don't need to worry about infrastructure. What we would like to do is to have the same functionality of something like NI USB-6009 (http://sine.ni.com/nips/cds/view/p/lang/en/nid/201987) without the computer. And we also have LabVIEW drivers for our device. So you can automate things in your business/home from anywhere using JS/LabVIEW/HTTP GET if you wanted to.
Thanks for the link. I figured YC knew the risk if PG asked for more hardware people to apply. It's true that it's very hard to have the same type of growth in a hardware startup as software, but someone has to make the gadgets. Additionally, while Kickstarter gives you funding, they don't provide the same type of mentorship that YC may offer.
Thanks for the tips. As for enterprise, we want to eat ni.com's lunch since a lot of threir lower end systems require a computer to operate. We're thinking of doing a kick starter to get 50 to 100 prototypes built and the case design finalized. The hardware is solid and the firmware/server side features are pretty much done.
Feel free (anyone else too) to contact me if interested in a demo. We're in Mountain View.
mobius.io here, we make hardware and were pretty excited when we read http://www.paulgraham.com/hw.html. Got rejected today and checked the server logs, saw nobody ever logged into our demo site. Is this typical or just means that our application was really, really bad?
Send mail to the following address:
Technical Publications
SGI
1600 Amphitheatre Parkway, M/S 535
Mountain View, California 94043–1351
• Send a fax to the attention of “Technical Publications” at +1 650 932 0801.
SGI values your comments and will respond to them promptly
Great article, I am glad MSDS was touched on before machining cast parts. The only thing I would add is that users should check MSDS before machining ANY material. There are a few exotic metal alloys whose dust can cause severe respiratory trauma.
If they are referring to TI's OMAP processors, then they typically feature multiple ARM cores with various media accelerators (http://www.ti.com/lit/ml/swpt034b/swpt034b.pdf). These are like all-in-one chips designed for mobile platforms that are optimized for displaying media on a LCD-ish display at minimum power. The OMAP offerings are pretty similar to chips from Broadcom or Samsung, however, it makes sense for them to get integrated with their biggest customer. They already have NDAs in place and TI probably has field engineers that essentially work for Amazon, they would just be transferring financial stake different production processes.
Having said that, the reason that you probably don't want to run a EC2 instance on an OMAP, or any ARM for that matter, is because they are not 64bit compatible, they do not have good virtualization support, and you would not be taking advantage of various media/display capability.
I have a cubicle and a lab area at work where I do hardware/software development, which means a large portion of my work involves a computer. I decided to try a standing desk about two years ago, however, I didn't want to commit fully and we don't have desks that raise and lower automatically. I decided the best solution would be convert my lab workstation to standing. I built something to hold mouse and keyboard at proper height and raised my monitors/docking station to eye level. I also added a 3/4" textured mat to stand on and keep a set of comfortable shoes at work.
My findings are that I am more alert standing up, however, I focus better on documentation while sitting down, so I alternate between the two throughout the day. Having both standing and sitting desks seemed to be optimal since a proper sitting desk chair can be more comfortable than a tall chair at a standing desk.
