Some updates from Erick http://iebctechkenya.tumblr.com/post/44706681378/updates-going-manual-clarif... ./bernard On Mar 7, 2013 12:00 PM, "Bernard Mwagiru" <bmwagiru@gmail.com> wrote:
John, It is in this light, amid sympathise for IEBC's efforts, and in the "absence" of an official root cause analysis that this thread can form some basis for brain storming. At this point, in this discussion, we have a rough idea of at the very least, the call flow of data to/from Bomas. We can use this to decipher potential weaknesses in the system. DB experts can for instance provide a scenario of what happens when the archiver process fails, etc or if a db instance in a cluster fails, etc. I'm sure there's a big opportunity to learn and avert future problems.
We cannot just sit pretty and wait for communication. If it does happen, we would be sufficiently armed.
./bernard On Mar 7, 2013 11:35 AM, "John Gitau" <jgitau@gmail.com> wrote:
I just cant wrap my head around it when such semingly easy things go wrong and then get blamed on IT/ICT/technology. Do you know how nice and easy it would have been to upgrade/sell migrate to automation if this had worked and really worked properly? it would have been the perfect case study for people in the technology space.
I strongly feel we should make astudy out of this. As far as I know there are only about 3 max five major components to this electronic voting and tallying system:
TX = transmission
*polling stations with some data capture devices <===TX==> Tallying
centers(constituency,county,national and presentation centers like Nyayo stadium <==some more TX==>Result presentation system *
that last component is I assume where the online results, media results and i think bomas should have got the results from so we all have a synchronized picture of their results. Please note I make a lot of assumptions here but it has really been bugging me what in those few components failed.
Note in each area some design considerations during planning would come to play.SO the question from me is if this thing was actually planned, documented, tested and can those be made public at some point? everything from the network, the applications the servers and Security in my opinion being the biggest one. Everything from encryption in TX , isolation to firewalls and on to secure access to DB's. I am of the view that what failed was not really a capacity issue but something else went wrong. I don't see how that dataset can affect even this server seated behind my desk at home. maybe some proprietary apps? or maybe we they had integrity affecting issues?
Either way for a country with so many experts in each and every one of the areas that might have gone wrong I do not see how as a guy that queued for almost 4 hrs to vote (I REALLY REALLY hate queuing) I won't get a proper explanation - technical on what went wrong. This should never every happen again.
Either way I think the IEBC made really great calls to ensure the integrity of the entire process is protected and for that Im happy, I just wish now we were a bit involved in how the technology was going to work. I strongly feel the technical community myself included dropped the ball on this one! I think we should have helped or offered to...I don't know...its just a sad state of affairs ...
JGitau
On Wed, Mar 6, 2013 at 9:24 AM, Odhiambo Washington <odhiambo@gmail.com>wrote:
+!
I keep saying that too. "Transmission" is the wrong term for them to use. It's the processing.
@Mwagiru, during the first day of their "processing", I was reliably informed that their server crashed as a result of "disk full" - well, that was first hand information. I still cannot digest this personally. The database(s) could not grow to an extent that it fills a disk, unless the server was having maybe a 4GB HDD! So I kept asking myself whether that explanation was reasonable. Could they have been logging aggressively without knowing? I am saying this because if they knew about it, they could have installed a separate disk just for the logs alone. I think these guys are mostly clueless folks who have relatives in those organizations and were not necessarily recruited on the basis of their demonstrable competencies. IMHO, that is ALL the possible flaw!
Sometimes it makes sense that technical employees of such public institutions like IEBC/KNEC be vetted by their peers - they should NOT be a well-guarded secret as they are a shame to the ICT fraternity.
On 5 March 2013 21:53, Bernard Mwagiru <bmwagiru@gmail.com> wrote:
Its a general agreement that transmission of data is not the issue here. Processing is. So, that said, and since the IEBC developers are a well guarded secret, can we deliberate on the possible design and what the possible flaws could crop up?
./bernard On Mar 5, 2013 9:47 PM, "Wilson Bandi" <bandson67@gmail.com> wrote:
Stupidly.. they dint think of transmitting via sms...
On Tue, Mar 5, 2013 at 9:44 PM, Dickson <dhikims@gmail.com> wrote:
Whatever infrastructure they have , I don't understand why sending such small data that can fit on SMS would have hitches. They are failing tech world in this country. Let them give us technical enough reason why the failure.
Best Regards,
Dickson.
---- http://qhim.wordpress.com
Sent from my BlackBerry®
-----Original Message----- From: Kennedy Kairu Kariuki <kkairu@gmail.com> Sender: skunkworks-bounces@lists.my.co.ke Date: Tue, 5 Mar 2013 20:22:18 To: Skunkworks Mailing List<skunkworks@lists.my.co.ke> Reply-To: Skunkworks Mailing List <skunkworks@lists.my.co.ke> Subject: Re: [Skunkworks] IEBC Systems
_______________________________________________ skunkworks mailing list skunkworks@lists.my.co.ke ------------ List info, subscribe/unsubscribe http://lists.my.co.ke/cgi-bin/mailman/listinfo/skunkworks ------------
Skunkworks Rules http://my.co.ke/phpbb/viewtopic.php?f=24&t=94 ------------ Other services @ http://my.co.ke _______________________________________________ skunkworks mailing list skunkworks@lists.my.co.ke ------------ List info, subscribe/unsubscribe http://lists.my.co.ke/cgi-bin/mailman/listinfo/skunkworks ------------
Skunkworks Rules http://my.co.ke/phpbb/viewtopic.php?f=24&t=94 ------------ Other services @ http://my.co.ke
-- Kind Regards,
Wilson B.
_______________________________________________ skunkworks mailing list skunkworks@lists.my.co.ke ------------ List info, subscribe/unsubscribe http://lists.my.co.ke/cgi-bin/mailman/listinfo/skunkworks ------------
Skunkworks Rules http://my.co.ke/phpbb/viewtopic.php?f=24&t=94 ------------ Other services @ http://my.co.ke
_______________________________________________ skunkworks mailing list skunkworks@lists.my.co.ke ------------ List info, subscribe/unsubscribe http://lists.my.co.ke/cgi-bin/mailman/listinfo/skunkworks ------------
Skunkworks Rules http://my.co.ke/phpbb/viewtopic.php?f=24&t=94 ------------ Other services @ http://my.co.ke
-- Best regards, Odhiambo WASHINGTON, Nairobi,KE +254733744121/+254722743223 _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ I can't hear you -- I'm using the scrambler.
_______________________________________________ skunkworks mailing list skunkworks@lists.my.co.ke ------------ List info, subscribe/unsubscribe http://lists.my.co.ke/cgi-bin/mailman/listinfo/skunkworks ------------
Skunkworks Rules http://my.co.ke/phpbb/viewtopic.php?f=24&t=94 ------------ Other services @ http://my.co.ke
-- **Gitau _______________________________________________ skunkworks mailing list skunkworks@lists.my.co.ke ------------ List info, subscribe/unsubscribe http://lists.my.co.ke/cgi-bin/mailman/listinfo/skunkworks ------------
Skunkworks Rules http://my.co.ke/phpbb/viewtopic.php?f=24&t=94 ------------ Other services @ http://my.co.ke