Sub-division landscapes

Oh, my, these pictures from the ever-wonderful Big Picture blog are simply mesmerizing.

What must the aliens think of us as they gaze down from outer space?

OpenIndiana? LibreOffice?

Lots of little bits and pieces of news continue to dribble out about the future of the various Open Source software efforts that Sun Microsystems had initiated:

• ComputerWorld reports that some OpenOffice.org developers have established a new foundation to distribute the newly-named LibreOffice (formerly OpenOffice).


• PCWorld reports that some OpenSolaris developers have established a new foundation to distribute the newly-named OpenIndiana (formerly OpenSolaris).

It's all rather confusing, and I don't think I'm the only one who's trying to suss it all out. Here's a short report from Rob Weir, an IBM'er who's much involved with Open Office, who says:

This will be an interesting test of openness in action. This is as close as we have seen to “twins separated at birth”, a rare but key subject for studying the relative contribution of hereditary and environmental factors on the development of personal traits. With LibreOffice and OpenOffice.org we have a similar “experiment”, a separation of identical code bases, with the same license, only varying the openness of the community.

Meanwhile, The Inquirer gives its take on Open Indiana:

If the Open Indiana project wants to provide a viable alternative to Linux and BSD in servers, then the project needs to adopt a low profile, quietly work on producing a stable and complete release, formulate release schedules and support structures, and then come back to beat the drum. Otherwise it will be seen as a rabble of hobbyists playing around with the long since discarded scraps of an industry behemoth, which won't do justice to the talents of the coders involved

Update: Here's an interesting short essay from James Governor with his take on some related issues, as well as some very interesting comments at the end of the essay from several readers.

Wild theories about Stuxnet

This weekend, the media was practically boiling over with strange and curious theories about the Stuxnet worm.

Both Kaspersky and Symantec have promised to release detailed technical analyses of the worm at the annual Virus Bulletin conference, which starts tomorrow. I'm quite looking forward to whatever information they share.

In the meantime, I found this overview on Steve Bellovin's weblog to be among the most balanced and informative summaries of what we know so far.

Great Sandy Bridge article at Real World Technologies

The folks over at Real World Technologies have put together an extremely detailed and thorough analysis of the new Sandy Bridge microprocessor architecture that Intel is rolling out:

In the coming year, three new microarchitectures will grace the x86 world. This abundance of new designs is exciting; especially since each one embodies a different philosophy. At the high-end, Sandy Bridge focuses on efficient per-core performance, while Bulldozer explicitly trades away some per-core performance for higher aggregate throughput. AMD’s Bobcat takes an entirely different road, emphasizing low-power, but retaining performance.

The complexity of these new systems is breath-taking. Consider this description of the Sandy Bridge memory subsystem:

The load buffer grew by 33% and can track 64 uops in-flight. Sandy Bridge’s store buffer increased slightly to 36 stores, for an overall 100 simultaneous memory operations, roughly two thirds of the number of the total uops in-flight. To put this in perspective, the number of memory uops in-flight for Sandy Bridge is greater than the entire instruction window for the Core 2 Duo. Again, like Nehalem, the load and store buffers are partitioned between threads.

For the most part, the details of modern processor architectures are hidden from people like me. Even though most programmers would consider the low-level C-language server programming that I do to be very "close to the metal", there's still layers and layers below me:

• C runtime libraries


• Compiler-generated code


• Operating system APIs


• Device drivers


• Microcode

And then we get down to "the hardware" itself, which, as is clear from reading the RWT analysis, is extremely sophisticated and multi-layered as well.

It's a very well-written and fascinating whirlwind tour through the latest CPU architecture, and certainly worth your time to read.

Maverick Meerkat is two weeks away

The final countdown is well underway for the next Ubuntu software release, Maverick Meerkat. The expected release date is October 10th, and Canonical have a very good track record of achieving their dates, so I think the release is pretty likely to arrive around this date.

There is a wealth of information available about the upcoming release, so much information that I made no attempt to study it all. One of the most intriguing projects is the "paper cuts" project, which you can read about here. The paper cuts project has been around for a while: Ars Technica did a great article on it during the summer of 2009. The core idea is to try to fix a lot of small problems, with the intention that, by paying attention to these details, the overall experience will be dramatically improved. As Siegel describes it:

This is a very small detail, and it was extremely simple to remedy, but it slipped through the cracks for two successive releases before I sat down to fix it. Part of the reason I put off fixing it is because it seemed inconsequential, as the amount of programming required to fix it was so small compared to other bugs in the application. Also, as with many other paper cuts, users (myself included) became habituated to this annoyance, learning to ignore and work around it.

In many ways, this is quite similar to the "Broken Windows" philosophy that I described last summer. I think that the paper cuts team has been doing great work over this last year, and I'm looking forward to seeing what arrives in Meerkat!

DOJ Cold-Calling decision

This week brought the DOJ's much-anticipated decision in the high-tech cold-calling investigation. I've been crawling around in the tiny bit of information available, trying to figure out what was actually decided, and what it means (if anything).

There isn't a lot of information. In addition to its summary of the case, the DOJ has published the actual complaint, and some supporting documents. Google published a very short comment about the decision. Chris O'Brien has an opinion piece in the San Jose Mercury News, and a few bloggers have weighed in with some thoughts.

But mostly, this action seemed to pass quite quietly through the media; nobody really had much to say about it. Far more attention has been paid to the "Angelgate" scandal.

So, what actually happened? The DOJ says:

The proposed settlement, which if accepted by the court will be in effect for five years, prohibits the companies from engaging in anticompetitive no solicitation agreements. Although the complaint alleges only that the companies agreed to ban cold calling, the proposed settlement more broadly prohibits the companies from entering, maintaining or enforcing any agreement that in any way prevents any person from soliciting, cold calling, recruiting, or otherwise competing for employees. The companies will also implement compliance measures tailored to these practices.

The Wall Street Journal says that this action was just the first step in a broader attempt to change the behavior throughout American industry:

A settlement with tech companies—or a court fight—could therefore help determine what kinds of agreements are acceptable in other industries as well.

At stake are dueling visions of how far companies should be able to go in agreeing to limit the kind of headhunting that can help valuable employees increase their compensation.

Chris O'Brien wonders whether the DOJ decision may open the door for disgruntled employees to sue for improper treatment:

Those who do think they got the shaft may sue. And because this is an antitrust finding, the settlement will allow anyone who wins in federal court to "recover three times the damages the person has suffered."

I find it hard to imagine the situation in which this might happen. Would this be an example of such a disgruntled employee? He doesn't seem likely to sue; rather just to move on to something else. Meanwhile, the papers are full of high-profile stories of high-tech companies competing vigorously over the top engineers.

I guess I'm left with the nagging sense that this decision was important (why else would the government have invested so much time and energy into it), but little deep understanding of what the government was trying to achieve and whether they believe they accomplished that. I'll keep my eyes open for some sort of explanation, and let me know if you think I'm misunderstanding this!

Contrastive Reduplication

Everyone needs a linguistics lesson from time to time.

At my old job, we used to have certain discussions:

"How's that project going?"

"Pretty good, I guess."

"Well, I need to know: are you done?"

"Uhm, do you mean 'done'? Or do you mean 'done done'? Because I'm pretty close to being done, but it will be a while before I'm done done."

Frankly, it used to drive me crazy. I would try to decipher what these people were saying, and wonder things like: will they at some point talk about being done done done? It was part of the reason I felt somewhat excluded: I literally couldn't speak the language they were speaking.

So here's a great essay, reviewing a recently-published Linguistics paper, that analyzes the phenomenon known as Contrastive Reduplication:

This paper presents a phenomenon of colloquial English that we call Contrastive Reduplication (CR), involving the copying of words and sometimes phrases as in 'It's tuna salad, not SALAD-salad', or 'Do you LIKE-HIM-like him?'

There's also a quite detailed article on Wikipedia, natch.

Oh, and regarding "done" versus "done done", I eventually came to, somewhat, understand what they meant in those discussions:

• Done: I've completed the design and implementation; it's been reviewed; the code is submitted to SCM and builds on our build system; the internal documentation is submitted to our wiki; the other relevant teams are aware of my work.


• Done Done: I've finished writing a suite of regression tests. They pass, and are run regularly by our build automation system. Our testing team is satisfied that their testing is complete. Our technical writers have finished the external documentation, and it's been reviewed. The support team has been through internal training on the work and is ready for customers to use it. All known bugs have been logged, and we've fixed the ones we intend to fix for this release, and annotated the others with workarounds and other discussion.

So there actually is a distinction between "done" and "done done", and it can be a useful communications technique.

Once you know what it means.