I had the great fortune of meeting Benjamin Mako Hill at Penguicon 6.0. We exchanged cards but didn’t get a chance to speak. His Laptop Liberation presentation was good and re-inforced a lot of the philosophy of the project that I had initially learned at the plenary session on OLPC at last year’s Shmoocon. I didn’t get a chance to ask about the departure of Ivan Krstić who was part of that plenary session or about their content chief also resigning.

There was another OLPC event at which Mako showed up, what the program formally called a roundtable but was conducted more like a birds of a feather session. Some of the other attendees asked the questions I had in mind about the departures and restructuring as well as some of the rumors and issues around Windows support on the XO1.

Mako characterized the changes as a consequence of now having thousands of laptops effectively in production. This has forced a shift in focus to maintenance and other production concerns. He feels that this requires more of a focus on product and project management. This echoes some of the sentiments that Negroponte himself has voiced. Mako went further to suggest that the more innovative personalities key to the project’s early development are at odds with this change in focus. He stressed this was not a personal judgement, just an observation of what the organization now needs and how the two skill sets are largely non-overlapping.

Make also commented on the question of supporting Windows. He cited the driver here being possibly custom education software. There is apparently a fair amount of such code out there and it is unrealistic to expect schools to port it to Linux, in fact asking them to do so would be a pretty distinct barrier to getting OLPC’s laptops into many school systems. This also resonates with some of Negroponte’s own thoughts about making Sugar more operating system agnostic. He ceded that the hefty requirements of running Windows were a challenge but could not comment on much else on the technical issues involved as it is outside of his work with the project and his areas of expertise.

He also emphasized a point I first heard Krstić make in response to a similar session put to that plenary session. OLPC is about child ownership and user freedom. As counter intuitive as it may sound this leads to a position where if the laptop owner needs or wants to run a closed operating system it is not the project’s place to prevent that. In fact such lock in would actually be reducing the freedom the owner would be able to express. It may be a bit of a slipper slope, though, as this doesn’t necessarily suggest that OLPC will expend a great deal of its own resources supporting closed software, just that they will not get in the way.

In response to some of the dire predictions made in the wake of the recent departures.

[It] is in transition [continuing from his earlier remarks on the re-organization]. OLPC is actually hiring aggressively.

Mako was repeatedly positive about the project and its supporting foundation. The extent of his concern seemed to be making that transition into production sooner than they were perhaps ready for. He suggested this is likely an unanticipated consequence of the give one, get one program. In addition to some legitimate issues with the laptop itself, the nature of the charitable participants in this program has taken the XO1 into places where the project wasn’t focusing originally like corporate networks and small offices/home offices. They’ve been working to separate out issues unique to those environments as opposed to what is strictly needed by educational systems, for example WPA support and direct printing capabilities.

I have been of the recent opinion that succeed or fail, OLPC has succeeded in challenging technology manufactures to rethink some things. As Mako pointed out in his main presentation, technology is entering the developing world no matter what. The problem is that without a system like the OLPC’s laptop, that technology is mostly closed, like cell phones and portable media devices. Questions of sustainability are unaltered by adding the XO1 however its presence gives these nations a chance to control and program the rest of the cheap technology with which they are being inundated and that has got to be worth the effort alone.

Thanks to Daring Fireball I saw this post over on one of the Sun blogs, yesterday.

There is a good bit of detail around Adam Leventhal’s investigation from mere curiosity to morbid fascination. His findings seem pretty definitive. While Apple is not advertising that they are conditionally disabling the new DTrace port in Leopard, it didn’t seem difficult for Adam, clearly an experienced DTrace user, to discover the truth of the matter.

I understand his point about how conditionally disabling DTrace for some applications is contradictory to the purpose of DTrace. Given how quickly hackers and makers have legitimately reverse engineered most proprietary code, let alone Apple’s, I think I can understand their decision making process. Especially since they still have a hefty stake in DRM.

Can you imagine the legal bruhaha they’d invite if a dedicate open media enthusiast cracked up the DRM around their rentals or just discovered how to fool iTunes into extending the play period? Now imagine someone, rightly or wrongly, attributing that to the presence of DTrace on Leopard. It isn’t hard to see how quickly Apple’s content partners would either abandon or sue them. Or both.

I am no fan of the rental idea, I didn’t like it the first time when it was called DivX. However, it is clearly an important money deal to Apple. And good, evil or otherwise, Apple is obligated to make money on behalf of their shareholders.

The real question is, is it better to have a crippled DTrace rather than no DTrace at all? How could Apple have better negotiated their money obligations with the open source and community commitments they also seem willing to undertake?

I don’t know the answer to either, not currently being an active Apple hacker. I do know how frustrated I would be, and am under different circumstances, when my usual debugging and investigation tools do not work as expected. How widely is this symbol defined? Is it just user space applications like iTunes or could it really interfere with trying to trace an applications calls into the lower level services? I find it hard to imagine the latter, otherwise the port would be pretty pointless. Regardless of such a rationale, it is possible for Apple to disable DTrace for any part of their proprietary code and Adam discovered they are willing to exercise that possibility.

At a minimum, it would have been better, not good or best just better, if they had made an effort to let potential DTrace users know about their slight change. As it is, many in the open source community are going to perceive this as a black eye and it will certain increase friction and distrust regardless of whether that reaction is entirely warranted.

The article Slashdot references is from a journal on software engineering for the defense industry. Provably correct software is a big deal for hackers in that trade and probably colors the editorial a bit.

It is important to not that this is not a lambasting as Java in education, but its selection as a first language. I think you could easily stub in a whole slew over other, simple languages and the commentary would make as much sense. However, I cannot disagree with their view that educators have shifted to Java as a first language to cater to perceived industry demand.

Outside of the author’s industry, I would have to downgrade their concerns over mathematics. Maybe for pure research, like algorithmic complexity, or systems engineering math is still critical but for general programming, not as much. I would lump their comments on understanding discrete, floating point math alongside Java fostering an ignorance of machine architecture. I know my own entry into programming via Java and similar languages delayed my full understanding of low level machine architecture, organization and operation. I cannot say it has hurt my career overly much but I doe recognize that if someone ignorant of these topics was working on real time, embedded software, that would be a huge risk.

More generally, I agree with their issue with any curriculum that takes more of a cookbook approach. I think the implication that CS curricula need to train engineers how to problem solve more generally with good discipline, regardless of particular technology or language, is one I can readily endorse.

However, the economic reality is that much paid development is simply application development that really is little more than plumbing. Systems engineering and other more demanding disciplines have been in decline in the market for some time. It is unrealistic to train every CS graduate for the minority need in the marketplace.

I don’t think application development would be hurt, really, by better low level understand and skills. I just don’t think the time or cost required is appropriate for situations of scale. That is to say the majority of work for which the software programming market is currently paying. Better to ask how to ensure at least a viable minority of systems engineers are produced each year to balance the majority and ensure there are always some engineers of all required stripes. Honestly, systems engineering will never go away but neither do I think its proportion in the paid workplace will increase in relation to applications development.

I read another piece by Jeff Atwood that I found infuriating this week. This confirms my impression that while Jeff may be a UI or HCI professional of some quality and even a tech geek to some degree, he is no hacker.

First and foremost, I don’t necessarily disagree with his main point. Code without a purpose is a waste. However, that purpose may simply be for the enjoyment or education of the author. Regardless, suggesting that the ultimate utility of the code far outstrips all other concerns, including language choice and coding style is dangerously naive. It is not the same thing as suggesting it is the first priority, a point with which I would have gladly agreed.

Programming languages come with their own strengths and weaknesses. Atwood’s discussion even touches on this point with regards to Perl. It is easy to learn and code but difficult to clearly and consistently express intention. Maintainability, in my experience flows directly from how easy it is to deduce the original author’s intent in a piece of code.

I don’t care how useful your software is to an end user, if you cannot fix bugs and add features in a cost effective manner, that will eventually become apparent to your users. Microsoft would be a prime example. The open source database, which I would lay solid money is MySQL, to which Atwood refers through his acquaintance, is another example. Yes, to the vast majority of hackers who just need a simple database that works, MySQL works well enough. To anyone who has everyone read any of its sources, there are much more preferable choices, like PostgreSQL, that are better engineered.

In this instance, with an open source product, the code quality is much more telling as poor quality may chill contributions and patches, on which open source thrives. In the case of Microsoft, a closed source example, you don’t need to look far to find stories of annoyances where if all things were equal, those irritations would cause a user to select something else.

Here is where some of Atwood’s disingenuousness shows. When Bugzilla was written, it was the only practical open source choice. That is no longer the case. MySQL trades on the practice, for reasons that are unclear to me, of being bundled and most widely supported by a lot of other open source software. I know I have been in situations where I would rather have dropped in PostgreSQL but couldn’t because the software I am installing only supports MySQL. I rather suspect MySQL’s popularity is similar to what used to happen with Microsoft Access. A developer would use it for small scale development and just keep rolling it out even into situations where it was a poor technology choice.

What all this really suggests is that selection of software is a multivariate exercise for the buyer or user. Language choice and programming style rarely enter into their thought process, I’ll concede that. I do not believe this excuses developers from making good choices and exercising solid discipline, as Atwood seems to suggest. I think that it is irresponsible to suggest anything like this. Customers are also paying for reliability, security and many other qualities that derive from the caliber of the engineering, which itself starts with the rigor of clear coding conventions and expressive, intentional sources.

I just read an article that, among other things, provides a nice primer on spintronics in the October SciAm. Unfortunately to get even the online version, you need to be a subscriber. But if you are, this article gives some nice background on spintronics, with the usual helpful graphics that SciAm produces so well, which I’d recommend to go along with the recent news story I discussed talking about a breakthrough using silicon instead of artificial diamond, as the rest of the article discusses, or other costly semiconductors.

In Jonathan Erickson’s editorial for the September Dr. Dobb’s, he dropped this link to a Berkely page dedicate to the landscape of general parallel computing. I’ve seen stories similar to his editorial for a few years, now, and I think that both multicore and “manycore” computing are more than likely the near to mid-term form of personal computing. The popularity that multicore has enjoyed since Intel’s first forays into “hyperthreading” seems to bear this out.

The Berkeley page seems like a good resource to bookmark and watch in addition to keep an eagle out on the the news feeds for any breaking developments.

We already have Symbian, embedded flavors of Java and Mameo, none of which are compatible with each other. Into this mix, Google has announced their own contribution, Android. The Register’s article even points out that the open coalition approach is nothing new.

I’ll give Google credit for taking an open approach and even managing to muster some consensus. But I have to wonder why they didn’t try to re-use existing offers, in particular working with the OpenMoko folks. They sure could use the support and I don’t see why that project might not be suitable for their purposes.

Another aspect of this development I am curious about but have not heard comment is how the carriers will react. One of my biggest questions about OpenMoko has always been what the typical user experience is for using one of these phones on the network of your choice. Sure, the wireless carriers are more likely to pay attention to Google, especially if they get to share at some point in the as yet to be realized ad revenue. But they don’t have a great track record of supporting this sort of edge of the network innovation. Too much of their current business model is predicated on control over which devices can and cannot be attached.

You cannot read too much into stories of early investment. Despite the insanities of the first internet bubble, venture capitalists still often show questionable judgment in choosing which endeavors to fund.

Regardless, seeing significant investment in a Rails oriented startup can be interpreted as a sign of the framework being taken seriously as a business tool, as opposed to an open source toy. I do not know if FiveRuns is the first such company to receive this kind of investment, but the fact that they make systems management software for Rails also points to a real market for supported and managed applications and applications development.

I will admit to be a little confused after reading of CDBaby’s travails with their Rails re-write. Perhaps this interest from the business community will see an increased focus in scaling the framework. It’s not a guarantee and this outside interest is likely to generate some friction with the core framework maintainers as they will want different priorities in future development almost as a certainty.

Daring Fireball pointed out John Siracusa’s review of Leopard. Like Gruber, I haven’t spent much time with the land slide of reviews. I’d prefer to experience the upgrade, myself, once my 5-pack arrives from Amazon rather than succumb to other people’s preferences and biases.

Siracusa, though, has done a phenomenally in-depth tour of Leopard. I’m a bit agnostic to some of the UI gripes but his reasoning is consistent and perceptive, regardless. The kernel details are engrossing especially since you don’t have to be a kernel hacker to appreciate what he’s written. Siracusa does a wonderful job of providing sufficient detail to appreciate where the lower levels of the OS have evolved or stagnated and why.

It is a lengthy read, I’ve spent several hours and am still not done, but I think well worth it if you want to speak about Leopard in an informed fashion relative to other operating systems like Windows and Linux and in contrast to what has come before with OS X.

This is a meme that will not die. Just because Joe Average, the business analyst, cannot write his own software, we are in a software dark age. I don’t buy it and I think it is an entirely fallacious argument. To me it is like saying medicine is in a dark age because a pharmacist cannot diagnose, manufacture and prescribe their own medication.

Well, strictly speaking, that analogy is flawed. But my point remains. The typically business analyst cannot specify their way out of a paper bag, let alone engineer a product. And I don’t think there is anything wrong with that. Business analysts, such as they are, have a valid domain interacting with human principals. This requires a different and non-overlapping skill set from crafting the instructions, that is software, that drives machines.

The only motivator I can conceive of to eliminate this divide is cost. If a business can pay a business analyst to both interact with customers and deliver products, they have to pay only one resource, not two. And this urge is not new. The same tired arguments were used around the CASE tool craze. And again with the Unified Modeling Language idiots and now the Domain Specific Language numb skulls.

Blaming the state of software engineering for it is nonsensical. It has always been a bad idea, it always will be a bad idea. Even the most disciplined, highly trained programmers cannot write bullet proof code. How is having a less skilled business analyst trained in an entirely different discipline write the code going to improve that?

Oh, and if you cannot see the snake oil aspect of a guy, Simonyi, trying to sell software that lets analysts write code telling people that things are broken because the tools don’t work and allow just that, well, then you deserve whatever product the idiots you hire give you.

This is actually an interesting suggestion. Not sure it is interesting enough to me to purchase the book, but still interesting. Of course the Slashdot article that pointed me to it distorts the authors claims, but not as much as I would have thought. I do wonder if the notion of “process expression” is actually more complementary to traditional CS, and the algorithm, than the author lets on.

Maybe it can be formulated as a kind of superset? His discussion of operating systems in the article is apt, the set of inputs over time is nontrivially complex and hence unpredictable, although it is foolish to entertain that any kind of software is non-deterministic. That way lies madness.

Usually I am leery of high flown claims such as these, but something about the idea of parsing and expression seems more right than not. Maybe its a false resonance, an unsubstantiable similarity to compiler internals. Maybe thinking about ASTs and parse tokens has yielded a tool biased view that extrapolates out to these process expressions. Not sure.

Maybe I need to check out this book, after all.

Just saw this question up at Slashdot. If you ask me, this is the voice of the clueless. Sure, 80 columns is insufficient in a term window. I typically run mine 110 wide. But that’s not the point of why many coding conventions have a bias towards 80 columns. Well, it may have been originally, but there is far more value to this restriction than ancient termcaps dictate.

Functional decomposition teaches us that to manage complexity code should be digested into manageable chunks. For C-like languages, and many others besides, nesting depth is often a good cue where a particular function is doing to much and should be re-factoring into smaller pieces. If I write a section of code that continuously overflows 80 columns, well, a good bet is it is nested a bit deep. I may also be violation the Law of Demeter by dereferencing too deeply.

The point is that 80 columns is not as arbitrary as it seems. Nor is it strictly a historical artifact. As we code, we need reminders, sing posts, that help us be mindful of what we are doing. Having pulled a couple of marathon hacking runs, recently, the siren song of code is fresh in the mind. If you are too fixated on the source at hand and don’t use these cues to pull back and continuous check and re-consider, well, that’s how smelly code developers.

So keep your code to 80 columns. Understand why you do it, of course. And developer any other practices and tricks that keep you mindful of what you are doing and re-assessing so your code is ultimately the best you know how to write.

Let me count the ways this is an awful idea. It does not even have the amusement value of the hacker that re-implemented Unix in JavaScript. There are already any number of quite good free operating systems. Mozilla already has a free, powerful XML based development platform. The core of Java’s promise, as opposed to C/C++, was platform portability. There are at least half a dozen “Web” operating systems already.

None of these has displaced Microsoft or Google. I honestly do not see how combining aspects of all of these and pressing the fact that it is XML based over and over again is going to make XIOS any more successful than any of its more well considered antecedents.

What incentive is there, really, for developers to build on what I see as more or less just a curiosity? The fact that it is XML based doesn’t really mean much in terms of reducing learning curve. And speculating about developers generating revenue directly for themselves via subscriptions or ads doesn’t do anything for me either. Maybe it is Information Week’s editorial bias, but I didn’t see any compelling evidence of why this would be an improvement for application users over any of the current approaches.

It looks like I was right to be skeptical. A 16 qubit register is still an accomplishment, if it is verified during the peer review to which the vendor says they will submit their work. But the report of the system running slower than a typical home system is a bit surprising. How is this demo worthy? I’ll be a lot more impressed if they make their 1000 qubit goal.

I’ve tried to stay out of this debate. It is pretty non-sensical, as most religious debates are–vi vs. emacs, brace styles, etc. However, Robert Cooper makes some good points for consideration in defense of static typing. The first one, right off the bat, has nothing to do with safety but touches on one of my favorite programming principals: intentionality. His other points are well made and well substantiated.

I even tend to think that his points, if well received, might help improve dynamic languages, in this case specifically Ruby, without having to give up the advantages of dynamic typing. Unfortunately, when the original poster to whom Robert is responding thinks it is realistic or practical to just fire people for making mistakes that a bit more intelligence in the language design could easily help resolve–well, good reception might be asking for too much.