Monday, October 4, 2010

According to this article Marvell has given the OLPC project a $5.6 million dollar grant to fund designing the XO-3 around a complete system on a chip (SOC) produced by Marvell. -Which will be based on the Marvell Moby reference platform.

Friday, October 1, 2010

Marvell Technology Group Ltd has announced a $100K challenge to developers interested in making creative, innovative, and engaging educational applications for their $99 Android based ARM tablet. Aka the Moby Reference Platform. Note: this is the same reference design which the OLPC intends to use as the basis for the XO-3.

Wednesday, February 17, 2010

Open Source is an integral part of a well rounded computing education.

While I will praise efforts to raise awareness of demographic barriers in open source development, I would challenge Mark to do a better job lining up his arguments and checking his references. Especially when many of his links have little or nothing to do with the statements attributed to them.

His link "more closed and less diverse than commercial software" links to a National Center for Women in Technology recruitment flyer. -Which sounds like a wonderful organization, but having read it now 3 times through says nothing about open source being more closed or less diverse.

The next link "overwhelmingly White or Asian and male" links to a OSCON presentation which says a lot about the male/female ratio... but nothing about white/asian demographics. Furthermore, it is a presentation which shows that the open source community is making efforts to draw awareness to the issue and improve the situation.

Mark attribute a quote to Linus Torvalds: "Talk is cheap. Show me the code." -But that quote is notably absent on the page he links to to reference it.

I'll grant, that that quote certainly sounds like something Linus would say. I have heard it many times in many open source projects. Taken out of context, it is used to imply that talk and conversation are undervalued. However, that saying is most frequently asserted during a conversation about:

1) A potential bug2) Someone asserting that one implementation is preferable or superior to another

In the first case it is notoriously difficult (http://www.shadowcat.co.uk/blog/matt-s-trout/show-us-the-whole-code/) to isolate a problem without access to the code.

In the second, the noise to signal ratio of conversations quickly become quite poor unless the conversation is rooted in actual code.

Legitimate Peripheral Participation exists in open source communities. Non-developers provide some of the best documentation. For the usability issues mentioned, non-developers are often better at writing documentation than the actual developers. They often help triage bug and issue tracking systems. And they can gradually move into development by bug testing and submitting tests which reproduce those bugs. And even when they don't gradually move into a developer role, they can become useful and respected members of a project by helping other users on mailing lists and IRC channels.

In Mark's closing paragraph, he disparages the open source community by painting it broadly with the religious zealot/fanatic brush stroke. It is true that open source has its zealots and fanboys. Apple, Microsoft, Google, etc. all have some rather intense supporters whose support relies more heavily on a go team mentality than on solid engineering. However, successful open source projects like the aforementioned companies also tend to have a core of solid engineers and skilled developers.

In closing, I applaud Mark for raising awareness of gender disparity in open source communities. And I would criticize him for implying that Open Source is "dangerous". I would remind everyone that correlation does not imply causation. There are many causes of a gender gap. My current employer has roughly 33% women developers in my department. When I started it was 0%. Things are getting better. That isn't an excuse to be complacent or dismissive of problems where they exist. We can and should strive to do better.

Sunday, February 7, 2010

Kiln People was published back in 2002. The plot can be quickly summarized as... In a future where individuals can send short-lived clones of themselves out to accomplish tasks and later reintegrate... A gumshoe detective in the midst of cornering his arch nemesis drops down a rabbit hole into a convoluted conspiracy of epic proportions.

David Brin performs his usual phenomenal job of exploring the possible effects of future technology on society. However, the story takes a back seat to world building. Kiln People is a good read, but it is not a page turner.

Surrogates was released Sept. 2009 and follows nearly the same plot (without crediting Brin). Instead of clay surrogates we have robots. The conspiracy is streamlined and simplified... but leads to the same destination. The introspection of technology and its affects on society are dumbed down to stereotypical hollywood levels: "pretty people", "personal tragedy", "love story", and "technology bad". Surrogates is a good popcorn and carbonated beverage flick. You'll probably enjoy the ride. But you won't take away much to ponder or think about.

(If you'd like to read David Brin's take on Surrogates, check out the following post on his blog.)

I'm a little cynical. Many good insights and areas for improvement are identified. But Perl needs to gain mindshare. And the only way to do that is to deliver the goods: Perl needs best of breed and/or innovative killer apps...

There is very little going on today which makes Perl relevant to anyone outside the Perl community. The reality is that Perl isn't much on anyone's radar except the people who already use it...

The insights which particularly appealed to me are:

Perl5 and Perl6 could definitely benefit from a "This is not your father's Oldsmobile" slogan. Perl doesn't market itself well.

Perl could use a modern clean cohesive comprehensive web portal which borgs the best of what the scattershot sites out there provide: CPAN, PAUSE, Perl Mongers, perldoc, perlmonks, ironman, use.perl, perlbuzz, the various community SCM repositories, professional training, perl jobs, etc. An effort to unify those disparate sites and services into a cohesive whole using modern and enlightened Perl would give Perl5 a chance to redefine itself.

Perl may look dead to outsiders, but there is a lot going on within the Perl ecosystem. There is: Perl6 (std, Parrot, Rakudo, SMOP), Moose, Catalyst, DBIx::Class, Web.pm. The list will vary from one Perl programmer to another. There is Padre, which shows promise of being of interest to non-Perl developers. And new in-roads into Bioinformatics. But O'Reilly and James Tisdall laid that foundation back in 2001 and 2003.

Another problem we need to answer, is why projects which are bootstrapped with Perl leave it behind?

Maybe they exist, but we're not aware of them? Muldis Rosetta is a truly relational RDMS (not SQL) being developed by Darren Duncan. Sounds interesting and promising... Does it work? Is it fast enough? Is it ready for use in production environments? Can it work with DBI, DBIx::Class, ODBC, JDBC, etc? Why aren't more developers involved with it?

Mojolicious looks like a fresh new MVC. In a fairly crowded field, it may be hard to distinguish itself. Take a look at Sebastian Riedel's recent Mojolicious::Lite blog.

Where are the other fertile grounds from which new solutions will arise? What other projects are out there which are using Perl to solve something new or solve an old problem in a better way?

Thursday, July 9, 2009

TimToady but the fact is, Perl 5 is basically in a no-win situation long term, which we first recognized in 2000PerlJam TimToady: now you're alienating all the staunch perl 5 supporters :)TimToady I'm only alienating them "long term"KyleHa If loving Perl 5 is wrong, I don't want to be right. 8-)PerlJam Someone mentioned (probably on use.perl somewhere) that Nicholas tried regular release cycles a while back. I'd like to know if that's true and if so, what became of it.ruoso I don't really think the regular releases is the issue...TimToady I love Perl 5 too, but it's stuck (culturally, and maybe technically) in a legacy trap, and the Perl 6 approach is the only long-term way out of that.moritz_ ruoso: it's not about *regular*, but about being able to release when there's something to fixTimToady Perl 5 is a velociraptor, but we need an acceloraptor now.

There ought to be a corollary to that saying about "Fast, Good and Cheap. -Pick any two". -Something to deal with legacy vs. innovation and revolution vs. evolution. But I suppose the latter is fundamentally a balance between looking backward while moving forward, the threshold of pain you're willing to undergo, and how you attempt to minimize it.

I wouldn't pretend to have the experience or wisdom to find the right balance. However, it doesn't appear to be a new problem.

C++ went through a period of upheaval not too long ago. There was a nice Dr. Dobb's article on it back in 1997. Well worth reading.

"Clearly, we are right to mock Solaris for making claims thatthey will never, ever, *ever* change an interface, not evenone that goes back sixteen years to Solaris 2.3. But itdoesn't follow the opposite point of view, that constantmutability of kernel interfaces to make sure that things arealways perfect and pure and clean is the right one either."