Called Project Aria...for the gaming world that is....
Called Project Aria...for the gaming world that is....
It's a case of critical needs....
C -- memory mgmt/direct access (rigid -- ok, lots of freedom but you can get hurt quick)
Java -- Object oriented (OOA/D) (semi rigid)
Pyhton -- lose the type safety for ease of development (loose)
C++ -- utmost flexibility (looser)
cost, aerodynamics, assembly....
that don't address the main feature of a mirror--safety.
Back in the 90's it was nerds that had some great ideas & skills, not so much on business. Some monetized (lucky ones), some didn't (most).
In the 00's the kids got smart
In the 10's the MBA's (which the VCs LOVE) now run Silicon Valley. Wall Street is heavily involved to tie ideas into existing corporations (Facebook, Google, etc...) for efficiencies of scale and funnel ideas back into the execs that run those companies since there's a lot of investor bulls that "long" those stocks. Some of the old school 'change the world' attitude is still there, but most of it are in VCs that have partners that ran those companies in the 90's.
Flashback to 1997, I recall working in a startup where we were partnered w/Orbital (in VA/Chandler Az) on a high altitude system using airships (balloons) as an alternative to Orbcomm and Iridium back in the day. The transceivers were to handle IP traffic. OSC was to supply the electronics, and we teamed with Gore Industries for the airships (to be flown at 120000ft) since Gore was the main vendor for materials on those high alt balloon experiments. The effort of course, collapsed with the space industry at the time. Looking at the people involve, Space Data has merit in the idea, but NDAs w/Google is another investigation that will determined this lawsuit's outcome.
Those were fun days, the Internet was just ramping up from dial up, Iridium was driving great ideas in the space communications industry and mobile phones were taking off.
Funny thing was back then, our balloon competitor was Alexander Haig and his odd partner-- and tackling regulations to get their balloon system off the ground via gov't permission instead of focusing on tech.
Fun days I sure miss...
It's now about AI-voice type stuff, like Amazon Skills.
Instead of apps, we're now building skills, tasks, context aware software that usually has a voice or touch interface.
All this push is mainly to monetize your every thought.
Currently it's to monetize your every voice command (a superset)
And before that it was to monetize your every question (a super-superset)
And before that was to monetize your every transaction (a super-super-superset)
And before that was to monetize your every 'access' (a super-super-super-superset)
You get the point.
I recall back in the 90's IBM attempt to develop tech to charge a penny for every byte that when through a router... charge by byte vs a subscription or even free access.
But we are a simulation.
Reason being that I always called simulations, turning a bunch of knobs to get the answer you want vs the answer one gets. It's 100% control basically in reality's sense and humankind like that aspect (that "we" are in control)...
Take it from the drone world. Car will learn from the drone industry...
FAA realized autonomous flying in 2007 (basis for the 2012 act). The tech became realized in 2013 (6yrs) and cool in 2014 (7ys). And "niche mainstream" (i.e. single purpose camera drones) this year (10yrs). Regulations are finally catching up and we'll really hit mainstream in say 2019 as long as a regulation disaster doesn't happen & companies continue to grow with new applications.
The same will happen for autonomous cars... just 50% [or more] faster because
a. the car is a well established platform (vs a drone)
b. infrastructure regs are well established (for manned vehicles, hence a template)
c. scale hasn't changed much (millions of cars is nothing new vs millions of drones)
d. the applications & use cases are well known.
In 5yrs == autonomous taxis & public transport are pretty much guaranteed. Hence, the 5yr prediction is reasonable. As for general private use--it depends if the companies are making money & some crazy disaster doesn't happen...it will fall into the same regulation mess that drones are in. So that's an additional 3 yrs...
I once had a saying from working in that field:
If I can see you, you can see me. The uncertainty principle is a pretty powerful context.
Now delaying or preventing you to see me.... that's intelligence work.
But the rest of the world and considering illegal frequencies being used around the US will make this problem harder than one thinks.
So you come up with a great solution for 900Mhz, problem is you can't use it in the EU or Asia. Or how about 433? nope, more conflicts outside the US.
Then there's the 1W vs 25mW (rest of the world) requirement....
Not only is this a tech and regulation problem, it's a frequency management and standards nightmare.
At least you can drive a DARPA challenge car or a biped robot in pretty much any country without conflicting tech (but conflicting regs).
You only change based on the need.
a. HDMI to micro: the need was super slim laptop output, try finding a 1" thick laptop nowadays
b. USB to micro USB: the need was super slim smart phones, try finding a 0.4" thick smartphone nowadays.
c. Ethernet: there are plenty of 1U+ blades, desktop computers, and industrial stuff (Ethercat) that are fine using RJ45. There is no need.
d. RPi could use a smaller ethernet connector but:
a few 100K pi's vs a million blade servers.... spanning models from 2000 to 2016 (not everyone is Google, Facebook, or Amazon that can replace their 2015 servers asap).
Designs like the RPi should goto a connect that makes sense. If the users want less size, then listen to them (add the RJ.5).
RPi really gets is chops via WiFi anyway.
Eventually it will be as easy as Amazon one-click. Bioweapons are going to be the worse of the bunch.
Open architectures and consumer autonomous products will enable it all. Add the fact that data sabotage is on the rise will make it nearly impossible to identify these things after an incident.
Basically if you use XBees, which are common in pro setups....
a. use API mode
b. use digi's built in encryption (AES)
c. Message authentication (key ids, crcs, etc...)
You can do all the other things he suggested, but this will stop 98% of the attacks out there. I'm surprised why he says Digi's onboard encryption was too slow. We do the above on all our drones (albeit a custom GCS) and do additional data link (Mesh ID based) and application layer things for added security, and still see 2ms lag from AES when turned on. Then again our packets are not too big. Done 30Hz control off this setup (50Hz like an R/C controller is a push)....
The problem is most F/OSS and vendor systems used XBees out of the box in transparent mode cause it's easy to setup and you can debug the serial line, or with packages like QGC with look at ascii or incomplete wire protocols that can be easily reversed engineered. Problem is... there's a reason they call it transparent mode--it's just a global serial buffer....
Really, that industry is motivated by incentives.
The market obviously has spoken the current incentives aren't worth it. It's a buyers market right now if you think about it. Bring on the [real] incentives (e.g. money, power, etc... choose one...), and then you'll see a different story.
I've got a bad feeling about this.