Written by Mike Young on Wednesday, 16 of July , 2014 at 10:49 pm
One of the little development wonders that I have really enjoyed working with lately is the Raspberry Pi. It’s a great little, very capable computer that has lots of 3rd party add-ons available for it. In fact, it has developed quite the ecosystem in just the couple of years it has been around. If you wish to use it as a platform for IoT development, then you have to seriously consider using the Alljoyn stack from AllSeen Alliance (@allseenalliance). Getting up and running for the first time can be a bit daunting as there are numerous options when you first walk through the git repository. So, here’s a little cheat sheet for getting up and running fast and building the core services. Bear in mind that I am working with the latest version of Raspbian, which is the Pi’s version of Debian, and 14.06 beta release of Alljoyn.
I’d like to give a special shout out to Joe Speed (@joespeed) of Linux Foundation (@linuxfoundation) for the pointer to a site out of China. Hopefully between our two write-ups you can get up and running with little to no pain.
Here we go:
- sudo apt-get install build-essential
- sudo apt-get install maven
- sudo apt-get install scons
- sudo apt-get install git
- sudo apt-get install curl
- sudo apt-get install openssl
- sudo apt-get install libssl-dev
- sudo apt-get install libjson0
- sudo apt-get install libjson0-dev
- mkdir ~/bin
- echo “export PATH=$PATH:~/bin” >> ~/.bashrc
- curl https://storage.googleapis.com/git-repo-downloads/repo > ~/bin/repo
- chmod a+x ~/bin/repo
- source ~/.bashrc
- mkdir -p ~/WORKING_DIRECTORY/alljoyn
- cd ~/WORKING_DIRECTORY/alljoyn
- git config —global user.name “[your name]”
- git config —global user.email “[your email address]”
- repo init -u https://git.allseenalliance.org/gerrit/devtools/manifest
- repo sync
- export AJ_ROOT=$(pwd)
- sudo ln -s /usr/bin/g++ /usr/bin/arm-angstrom-linux-gnueabi-g++
- sudo ln -s /usr/bin/gcc /usr/bin/arm-angstrom-linux-gnueabi-gcc
- scons OS=linux CPU=arm WS=off OE_BASE=/usr
- sudo ln -sf ~/WORKING_DIRECTORY/alljoyn/core/alljoyn/alljoyn_core/build/linux/arm/debug/dist/cpp/lib/liballjoyn.so /lib/arm-linux-gnueabihf/liballjoyn.so
- cd ~/WORKING_DIRECTORY/alljoyn/core/alljoyn/alljoyn_core/build/linux/arm/debug/dist/cpp/bin
- ldd alljoyn-daemon
- ./alljoyn-daemon –version
After executing alljoyn-daemon –version, you should see something like the following:
AllJoyn Message Bus Daemon version: v0.0.1
Copyright (c) 2009-2014 AllSeen Alliance.
Build: AllJoyn Library v0.0.1 (Built Wed Jul 16 19:20:47 UTC 2014 by myoung – Git: alljoyn branch: ‘(no branch)’ tag: ‘v14.06rc3′ (+68 changes) commit ref: 645991ec7c1762ade3a33cc6dbaae7e6aba65195)
Now you should be up and running with Alljoyn on your Pi.
Category: Alljoyn,Allseen,IoT,Pi,Raspberry Pi,Raspbian,Techy Stuff
Written by Mike Young on Wednesday, 7 of May , 2014 at 7:04 am
There has been a lot of activity over the past couple of months with respect to the acceptance of hardware accelerators within NFV. I can still recall back this time last year when accelerators were a four letter word within NFV. Now, we’re talking about creating entire shelves of them. For me, this notion of disaggregation is much more important that what others think about when they talk of other initiatives like OCP (Open Compute Project).
The reason for this is simple… we need accelerators in our various platforms. But we also need to be able to get better amortization of such additional hardware. Simply burdening every server blade with such technology is too costly. This drives up CAPEX considerably. And it simply contributes to the ongoing problem of over provisioning.
Instead, with disaggregation, we will some day have the ability to dynamically bind an accelerator to an application on an as needed basis. And this could be reconciled back to an customer SLA or some kind of equivalent business justification. And this is important. When we can rationalize and properly account for an additional business expense, we can understand how to ensure that we’re properly charging for it. So, those that truly need the functionality, not just everyone, can pay for the capability.
I’m happy to say that this subject was accepted into section 4.4.2 of the Compute Domain GS document, last month in the Cambridge face to face INF meeting.
Now comes the challenge of creating an ecosystem of accelerator shelves, which can be used as NFVI (NFV Infrastructure) gear. This is the fun part of NFV!
Category: NFV,Techy Stuff
Written by Mike Young on Wednesday, 7 of May , 2014 at 6:42 am
I’m so excited for our little girl– not so much because she got the stripe itself, but because she started Jiu Jitsu three and half months ago and has stuck with it. Not only did she stick with it, but she simply loves it. She hates to miss Jiu Jitstew (as she calls it). We had no idea that they were advancing the kids last night, so I wasn’t there. I suppose the biggest thrill for me was that the first thing she wanted to do, after class, was to call me and tell me.
This is Boo getting her stripe from her professor, Milton.
I don’t usually have New Years resolutions, but as the year was winding down, one of the things I knew I wanted to do was to get back into training. Injuries that I had incurred back in CO were simply messing me up for so long. And now that I was finally operating pain free, I wanted to get back in and start training at the first of the year. Then it struck me that I might be able to sweet talk my family into giving it a try. Surprisingly, Nikki was all for it and Boo wanted to give it a try too. So, after several attempts to get us over to the school, we finally succeeded. We went a couple of times so they could get an idea of how the kids and adult classes operated. And sure enough, their nerves got to them a bit. It can be quite intimidating to new students– seeing people rolling around grappling and choking one another.
Our little family has come a long way since the beginning of the year. Not only is Boo doing so well, but Nikki has been amazing. She’s like a sponge and wants to do BJJ 24/7. We even have mats laid out on the living room floor so that we can train there vs on our bedroom floor. Who would’ve imagined this could come true. Now, it’s just me feeling like the weak link in the family I have been doing BJJ for almost 5 years and miss the feeling of making progress. It’s nice to live a bit through them. And when I think about how it has become such a part of our family, all of my personal doubts and concerns seem to melt away. BJJ is a lifestyle. It’s simply not about stripes or belts, or even tapping the other guy out. I get to stay fit and also rest assured that my family might actually be able to defend themselves when the time comes. And there’s a lot of peace and comfort in that knowledge.
Written by Mike Young on Tuesday, 24 of September , 2013 at 6:29 am
In this article from the 5th, http://bit.ly/17GTsst, Marc Cohn says many good things, but seems to feel the bulk of the attention is on the management side of things, and that little attention has been given to Networking:
The NFV Use Cases are intended to drive the Virtualization Requirements, which in turn drive the End-to-End Architecture. NFV encompasses functionality in the compute, storage, and network domains. To date, the majority of the effort has been focused on the software virtualization framework, along with management and orchestration. Consequently, limited attention has been paid to the network.
I’d add that even less attention has been paid to Storage. There are so many things to consider when it comes to that — block vs file, scaleout vs scalein, what protocols, security schemes, etc. The list goes on and on.
Lately, I spend a lot of time thinking about hardware accelerators. The simple reality is the bottleneck is the storage part of the infrastructure, when it comes to virtualization. With that said, we still need the acceleration as well. And much time has been spent in the INF working group to discuss this.
Management and Orchestration (MANO) and SWA (Software Architecture) have their challenges primarily because it’s quite difficult to get multiple vendors to agree on APIs that are normally deemed proprietary. Often, software has to be re-architected to support a vendor-agnostic methodology. And when you consider that NFV is about the WHOLE system, e.g., Compute, Networking, Hypervisor, Application, Storage, Management, Business Logic, etc., that’s quite a lot of cats to try and herd.
Just felt the need to elaborate on his article as the INF working group meets at Brocade for the next couple of days to hash out all of these implications.
One of the reasons I love NFV is it’s where the rubber meets the road.
Wish us luck!
Written by Mike Young on Monday, 23 of September , 2013 at 6:44 am
It has been a couple years since I last posted. I am not quite sure that I lost my way, but I certainly lost my motivation. Frankly, nothing really interested me. It was all garbage, a distraction or some ruse. And I needed to find something that I could be passionate about again. Well, Network Functions Virtualization (aka NFV) is just such a thing.
On the surface of things, the NFV was formed to do something that others have already been doing, which is to take physical appliances and run them inside of virtual machines. But this is where we depart from the pack and I get to become a bit more controversial. NFV really stands to overhaul how we build our data centers.
Now, there are plenty of people who’ll try to contrast NFV with say SDN (Software Defined Networking), but they’re probably quite stupid. The two have very little, if anything, to do with one another. More likely, you will find people equating NFV to being almost entirely about cheaper hardware. And they’d be wrong as well, although a bit more accurate.
NFV was started by Operators. For those of you not sure what I’m referring to, I’m talking about those companies that you probably take for granted as they provide you those data, texting and talky capabilities over your phone. Talk about an unappreciated bunch. Think about each time you Skype over your cell phone, just to avoid consuming minutes or long distance. Now picture the poor blokes that don’t get a pay raise because you just robbed their company of revenue.
Okay, so maybe it’s not quite that bad. But it is bad in their industry as they compete with the likes of the Googles, Alibabas and Tencents of the world. They’re the wire that transports the hot services. And it’s the guys making the hot services that are actually making the money and getting the ridiculous valuations.
Now, I’m not going to try to right the world here. Instead, I’m just gonna tell you that I see an opportunity and I’m capitalizing on it. That opportunity is to take various open source software — best of breed — and to unify the management interfaces at all levels.
It might be natural to think this to be a rather trivial exercise and something that vendors or even open source maintainers could do themselves, but I don’t believe that to be the case. Consider open source maintainers for a moment. They really don’t generally have the time or the motivation to do this. And what standard will they use, considering there really is no standard currently? It’d be more likely for a vendor to do this. But the challenge there is interoperability with other vendors. You see, vendors have a need to maintain some level of competitive edge. And while I would suggest that integration, testing, and building the best “whole” product is a great way of doing that, they will no doubt face the temptation to differentiate themselves at the management API, as well.
So, in my warped madness, I have decided to do what I have done for years now and to fork various projects. But rather than just take them and incorporate them into an appliance of my own, I’ve decided to make them available via a new portal I’m launching at Yúnifai.com over the next few weeks.
You might wonder how I came up with such a strange name. Well, it’s easy. It’s getting increasingly more difficult to get good, easy domains with a “.com” extension. So you have to be somewhat clever about it. Also, “Yún” (or 云) is the Chinese pronunciation for “Cloud”. I work for a Chinese company with over 150,000 personnel and find it amazing that no one else has drawn the connection to this. But at the end of the day, when we discuss unifying our various software and hardware components, aren’t we primarily doing it for the cloud? Well, that was my thought at least.
In addition to unifying (or maybe I should start saying Yunifaing) the management interfaces, we need to optimize the architecture and start getting rid of some of the excess abstraction layers and copies that go on in a virtualized world. NFV, no offense to Microsoft, is very likely going to be built upon Linux as the core operating system. If we’re talking about Linux as the Host OS and Linux as the guest OS, do we really need to replicate so much? I don’t think so. Instead, we need to strive for a collection of open source components that can work together in a highly optimal fashion. And that will require vision, a strong will and much tequila. I do not envision this to be an easy road ahead. And I’m sure many will consider this far too ambitious. And I can live with that. I’ve been told so many worse things over the years.
There are too many reasons why the communications and IT industries really need the “next” model for open source development. Think about what Linus does and leads inside of the Linux kernel. Sure, we’re talking about some brilliant software designers doing some fantastic work. But for all of that to work so well is largely the product of one highly anal individual and his drive towards perfection. Many fault him for this. I applaud him. This has to occur at the application and hypervisor level in order for NFV to really make much sense. Now, if you think I might be somewhat right on that point, then please tell me how it can be done more efficiently. I am always open to suggestions.
I am hoping that this renewed energy won’t die off any time soon.
Be back with more soon!