At the prices medical-grade titanium goes for, it is most certainly not wasted. The machined Ti is reclaimed (or at least it would be if I were in charge). Stating that there is 80% waste is marketing hyperbole. A fairer comparison would count the unsintered powder in the 3D build machine, and would end up being unfavorable to the 3D process.
But if you're in the business of making replacement body parts, you might well be starting with a generic titanium casting (or one of a series of different sizes) and machining it down to fit. Artificial hip joints are sometimes made that way.
Don't get me wrong, 3D printing makes a lot of sense for highly-custom items... although one needs to worry about the potential infection and reaction issues given the inherent porosity of sintered material that give purchase for pathogens, and lots of surface area for irritants that will slowly leech out.
1. "All the Keyboards" didn't apparently include a Kinesis. At least there isn't one visible amongst the few photos linked.
2. The new keyboard looks an awful lot like a Kinesis.
3. I stopped watching the video after the first 10 seconds because it was too awful.
4. The web site shows a keyboard with what appears to be a metal case, and the text references aluminum, as does the blog. Wood isn't part of the equation here. Maybe in the early prototypes, but not in the production models, apparently.
5. Any decent keyboard driver (and there are lots of aftermarket add-ons) support macro definitions. Nice that this new keyboard supports it, but certainly not a defining characteristic.
6. Just go buy a Kinesis. It's been in production for a long time, and they work great.
What, too soon?
That's an accurate and sensible response.
In fact, 3rd party client encryption tools might be better than built-in support by Dropbox. They can be produced outside the USA by companies or individuals unaffiliated with DropBox and potentially harder to pressure into backdooring the software in an update.
I'll stick to SpiderOak personally, despite the awful transfer speeds and somewhat clunky usability, because I just want a remote store that stores my gibberish bytes and gives me the same gibberish bytes back later.
A lot of those early mathematicians were a bit on the crazy side, having come to that realization and not having any of the framework for coping with the idea.
Not being able to ack important message packets seems like a design flaw.
Even though we have a LOT more hardware now than we did back in the day, you still can't BFI your way through a lot of the big data applications that companies are starting to try to get into. In the past, the company would just throw more hardware at a poorly designed application and that would "solve" the problem. I once saw a team throw 48 gigabytes of RAM at a leaky Java program, and schedule weekly restarts for the goddamn thing. But it's a lot easier to hit hard walls with big data, to the point where you absolutely can't throw more hardware at the problem.