Finally - dusting off my Rpi...

It has been a brutal haul with catching up on the work front and a series of deadlines and activity on the CodeChix front.  I am pretty tired, but....

I have finally managed to squeeze out some time in the form of a free-for-all RaspberryPi Hacking Session at VMW this evening.  I figured if I organize it, I HAVE to be there and that will give me
exclusive time to work on my project :)  - at least, that is the fervent hope.
So, here I am in the VMW Prom C cafe, watching the beer disappear, people eating all sorts of goodies and cupcakes and trying to make progress....

I'm hoping that I can make some much-needed progress on my PiDoorbell project and finally getting around to updating my github account with the latest and greatest...

Hoping to remove the arduino from PiDoorbell completely and not break too much in the process....

And after 2 hours and helping others and chatting and having a great time, I haven't really got anything done.... but, I had great fun !! :))

Hari managed to crash his Rpi and brought it up in recovery mode (after the initial

Hackers at this one - Mike, Hari, Sunil, Iris, Darius, Rupa, Vivek
Can't wait for the next one....

AWS + CC-ONF-Driver + MUL +Mininet + tshark + issues.....

So, we have all our driver and MUL code compiled and ready to be tested on rather expensive instance of AWS - hey, we're trying to impress the judges, right?

And now I'm working with the team to test stuff and AWS seems to put restrictions on running controllers on loopback i/f's?

ubuntu@ip-172-31-44-94:~/test-harness/CodeChix-ONF-Submission/mul-cc-submission$ sudo mn --controller=remote,ip=127.0.0.1 --topo linear,1
*** Creating network
*** Adding controller
Unable to contact the remote controller at 127.0.0.1:6633
*** Adding hosts:
h1 
*** Adding switches:
s1 
*** Adding links:
(h1, s1) 
*** Configuring hosts
h1 
*** Starting controller
*** Starting 1 switches
s1 
*** Starting CLI:
mininet> 
mininet> dump



mininet> 

For tshark:

tshark -i lo -a duration:5 /tmp/my.pcap

Capturing on lo

tshark: The capture session could not be initiated (You don't have permission to capture on that device).

Please check to make sure you have sufficient permissions, and that you have the proper interface or pipe specified.

0 packets captured

More investigation and debugging ensues....

Have I mentioned how much fun this project is?  Yes, tiring and stressful, but really fun too... :)....

Yaaay !!! We *JUST* submitted our final version to the ONF Driver Competition ! Go Team CodeChix !!!

Submission was just sent  !!!   ---->

Exhausted team - ready for some bubbly !!!

Deepa - exhausted and happy !!!

Time to go home !!!  And SLEEEEEP !!

Compiling the MUL controller on the RaspberryPi.... CodeChix ONF Driver Competition Team !!

So, four of us have been hunkered down for days for the final push towards the CodeChix ONF Driver Competition (will post more on that - don't have time to do a post right now).

Final run through and submission checklisting before submission after 14+ hours today !

Compiling the CC-ONF-Driver codebase went through like a breeze.

Not so for the MUL controller code.  I kept getting glib errors even after installing libglib2.0-dev etc.  So, the following hacks were needed to get "./configure" to work and for the source to compile.

1. Get your local paths to the glib lib - "pkg-config --cflags glib-2.0"
2. Symlink stuff to whatever "configure" expects - "sudo ln -s /usr/lib/arm-linux-gnueabihf/glib-2.0/include/glibconfig.h /usr/include/glib-2.0/glib/glibconfig.h"
3. sudo mkdir -p /usr/include/glib-2.0/glib/.libs
4. sudo ln -s /usr/lib/arm-linux-gnueabihf/libglib-2.0.so /usr/include/glib-2.0/glib/.libs/libglib-2.0.so
5. sudo ln -s /usr/include/glib-2.0/glib.h /usr/include/glib-2.0/glib/glib.h
6. sudo make
7. sudo make install

And you should be good to go!

Shout out to Dipjyoti Saikia (from Korea)!  Dipjyoti - hope you can use my Rpi hacks above for ARM porting, should you need to do so.  We couldn't have done this without your support and help with the MUL controller over the last several months!  The team high-fives you virtually!

Ramya/Deepa just found a fix for a bug thread locks!  

Onwards towards submission..... and more champagne!

Half-life of knowledge and software/hardware careers???

I've been pondering this topic for a while (as of 2010) and have discussed it with a few select friends/colleagues over the years.  One of the reasons I started CodeChix is because I ran into this issue myself and saw many others who were also struggling with this realization as they hit their 30's.  This is what resulted in the Sunday afternoon workshops that CodeChix organizes and conducts to help women (and men) engineers try to stay "current".

This article hits the nail on the head (rather hard) and is worth reading.  What changes do we need in the industry to make it a profession that is valued with growth (in age/experience as well as technical knowledge)?

http://spectrum.ieee.org/riskfactor/computing/it/an-engineering-career-only-a-young-persons-game/?utm_source=techalert&utm_medium=email&utm_campaign=082913

I would like to do something to figure out if this issue can be addressed and how to go about doing it because if this is what it's going to be like, try telling your kids and see if they're remotely interested in STEM or engineering.  Hah!  They have sense - they'll run like hell.  I would have if someone had mentioned this to me when I was studying CS and wanted to be an engineer.   Is this what we want to emulate for the next generation?

The status quo is just not sustainable....

An associated post on the real STEM crisis:

http://spectrum.ieee.org/at-work/education/the-stem-crisis-is-a-myth