Leading items

Ubuntu and window controls

User interface design changes are often contentious, but when the changes are to something fundamental that users are accustomed to, the outcry is even louder. On the flipside, though, good UI design is best done within a small group of dedicated folks, who may—should—be willing to think "outside the box". Innovations often come from setting aside historical precedents, but, if the process is done quietly, and presented suddenly, the shock value alone can be enough to anger users. Ubuntu's recent bug report flamewar shows just how that can play out.

As part of the Ubuntu rebranding effort, there were some obvious changes, like the move from brown to purple, but there were some more subtle changes as well. In the new Gtk theme as presented in that new brand, there were changes to the window controls. Instead of the traditional—for Linux anyway—buttons in the upper right of a window, they had moved to the upper left. But the "close" button stayed in the same relative position, so that it was no longer in the corner, but was to the right of the "maximize" and "minimize" buttons (which had swapped positions).

When the rebranding was announced, most observers focused on the color, logo, and other changes; few noticed, or mentioned, the window control changes—until those changes landed in the first Lucid Lynx (10.04) beta. Once users were faced with actually using the change, they ended up noticing it—and many weren't very happy about it. A bug was filed in Launchpad on March 5, and various arguments broke out in the bug entry about whether it was a bug, whether it was a good change or not, what the bug status should be, and who it should be assigned to. As is often the case when users don't feel that a bug report is being handled correctly, there were many status, importance, and assignment changes, with others resetting the values back to what they were—pretty typical bug tracker gamesmanship.

There were also lots of comments about the change—376 at the time that this was written. There are, of course, ways to revert the behavior, either via a personal package archive (PPA) or the command line:

    $ gconftool-2 --set /apps/metacity/general/button_layout \
                   --type string "menu:minimize,maximize,close"

One of the concerns expressed is that Lucid is a long-term support (LTS) release, so any change will be supported (and lived with) for three years. Another was the way in which the change came about, i.e. with essentially no warning or explanation. "Conscious User" described how it looked:

Mark Shuttleworth did provide something of an "official statement" further down in the bug comments:

But that explanation wasn't really satisfying to many of the commenters. It didn't really explain why the change was done, other than the somewhat vague statement that it opened up space on the right for unnamed "innovative options". As several commenters noted, leaving the buttons on the right opens up the left side, so it is not clear why moving the controls was needed to support these innovations. Conscious User, among others, asked Shuttleworth for "concrete, non-vague arguments in favor of the left side", but, so far at least, those arguments have not been forthcoming.

In noting that the change "landed without warning" and that there "aren't any good reasons for that", Shuttleworth tried to defuse the situation to some extent. But much of the underlying unhappiness is not just that there was no warning, but that the reasons behind the change are, at best, murky. Without knowing what the innovative plans for the right-hand side are, it makes it harder for people to understand and accept as Adam Williamson points out:

There are some hints, though, that the "Other Stuff" has been invented, or at least discussed, by the design team. That leads some to speculate that there might be Canonical business reasons not to disclose these new ideas. That runs counter to how some people believe that community distributions should be run. There is concern that important distribution decisions are being taken out of the hands of the community. Shuttleworth doesn't completely shy away from that characterization, while noting that there is room for more experts on the decision-making teams:

But the secrecy and way that these decisions have been handled led some to wonder whether there is an autocratic element at play. Atel Apsfej wondered about Shuttleworth's credentials: "Who certified him an expert designer? He may be passionate about design but it doesn't automatically make him good at it." Further, Apsfej thinks that the Ubuntu community has the responsibility to push back:

While Apsfej was one of the harsher critics, his points seem to sum up the concerns of quite a few commenting on the thread. There is concern that Shuttleworth is not quite meeting the transparency promises that he has made. As Ubuntu matures, and fixing Bug #1 ("Microsoft has a majority market share") becomes more and more important, is there a need for Shuttleworth and Canonical to take a stronger hand on the rein? Apsfej explains the difference, though in characteristically stark terms:

For his part, Shuttleworth does recognize that mistakes were made in how the design team made this change. The change is not fixed in stone, and may be reverted before the final release of Lucid. But he is not concerned about shipping a change like this in an LTS release: "If I'm confident that 10.10, 11.04 and future releases will have the controls on the left, it makes even more sense to do it now (because the LTS will then not look dated compared to newer releases)". He notes the precedent of shipping Firefox 3.0 beta for the 8.04 LTS release, which "caused an uproar but was the right decision given that 2.0 was nearing its end of life at the time".

There are risks to any change, and Shuttleworth is cognizant of those, but he also sees big opportunities:

In the end, though, Shuttleworth is defending how decisions are made in and for Ubuntu, including this one. Because it affects every window that people use, and is thus in their faces many times a day, the level of outrage got particularly high. But that kind of backlash can't stop the decision makers:

It is unfortunate that, for whatever reason, more details about the future plans for the right-hand side of a window's title bar are not available. One gets the sense that much of the anger and unhappiness that was spewed into the bug report would have been lessened, perhaps greatly, by a better communication of the "Cool New Feature" that may wind up there. Presumably in time we will see what the plans are and can judge at that point whether the secrecy was worth it. For now it seems to have gotten a lot of people up in arms, possibly without a very good reason.

Comments (51 posted)

Automated trading using Marketcetera

While Linux and free software have found a place in various stock exchanges and other financial firms, most of the code that is run on those systems is proprietary. Financial companies are not terribly interested in sharing their secret trading strategies with their competitors. But much of the underlying code—communicating with brokerage systems to buy and sell stocks and other financial instruments—doesn't necessarily need to be secret. Marketcetera, a San Francisco startup, is applying free software principles to its trading platform to allow more organizations, especially smaller, less well-heeled ones, to get access to the same algorithmic trading channels that the larger firms use.

First announced in January 2009, the Marketcetera Automated Trading Platform (MATP) is a GPLv2-licensed system for handling market data as an input and producing buy/sell orders as its output. In between, "strategy engines" can be used to decide what those orders should be, and which brokers to route them to. There is a sophisticated "signal analysis" module that filters and analyzes the incoming data stream of market-related information (bid, ask, executed trades, etc.) for use by the strategies. An "order routing server" handles bidirectional communication with brokers to submit orders. In addition, orders and their outcomes are stored in a MySQL database for record keeping purposes.

Overall, it is a rather complex Java application with lots of moving parts, many of which require interfacing with external organizations—some of whom are understandably rather picky about who they talk to. MATP uses the Financial Information Exchange (FIX) protocol both for retrieving market data and for sending and receiving order information. That allows users to connect to any FIX-enabled services and brokers, but there is often a "catch": these organizations typically require certification of the FIX connector before allowing orders to be entered into their system.

Users can go through that—presumably somewhat costly—process themselves, or they can get access to "pre-certified" connectors as part of a Marketcetera support contract. Like many free software businesses, Marketcetera's business model is centered around support and consulting. In addition, there is an element of the "open core" strategy, with "extras" that can be purchased to run on top of the core, including the FIX connectors and various market data adapters.

The core is a rather large chunk of code, however, with some fairly significant functionality. It is not exactly a turn-key system because the needs of each user are so different. The company seems to understand the benefits of free (or open source) software, touting them in its FAQ. Avoiding vendor lock-in is a key piece of that as Managing Director Roy Agostino describes:

Of course, there is also the community aspect of free software. Marketcetera has a separate domain (marketcetera.org) for its community portal. Unfortunately, much of the information available in the portal requires logging in after registering with the site. It's not exactly clear how that promotes community.

At the portal, logged-in visitors will find documentation, both for users and developers, a support forum, bug/feature tracker, and the like, but also the Marketcetera Open Labs. The labs are a Sourceforge-like site for community members to start new, related projects for "platform extensions, modules, new components, unofficial HOWTOs" and so on. Several projects for things like a CSV market data adapter, chart module, strategy authoring, and a few others have already been started in the labs.

For contributions to the core, Marketcetera has a contributor agreement that is based on MySQL's. It requires transferring the copyright of the code to Marketcetera and receiving a "broad license to re-use and distribute your contribution". It also requires granting a patent license to the company and its users for any patents that are held by the contributor on the contribution. There is a web page that describes some ideas of things to work on along with instructions on the logistics of code contribution.

Installation is fairly straightforward, though not very well integrated with Linux. To start with, you must be logged in to access the software, which comes in a 220MB tar file—containing a single 220MB shell script. In keeping with what seems to be a tradition in Java program installation, the Marketcetera code bundles a Java Runtime Environment (JRE) and MySQL into the installation. The installer gives a minor complaint if it isn't run on Ubuntu 8.04, for which it was tested, but it seemed to install and run just fine on Fedora 12 as there aren't many external dependencies.

There are actually two downloads available, the server components described above and the Photon GUI for order entry and strategy authoring. Photon is based on the Eclipse rich client platform (RCP), so its use will be familiar to anyone who has used Eclipse. It comes as a more traditional, though still 75MB, tarball. The RCP was chosen at least partially because Photon provides a way to develop strategies in Java or Ruby, which can be tested and run from within the GUI.

Photon also has order entry capabilities, so that user-initiated (rather than strategy-initiated) trades can be entered. Market data can be retrieved, filtered, and displayed in a variety of ways. There is a web browser component for looking at financial and other sites. Retrieving information on trades from the database is also possible in Photon. It is essentially a control panel for the entire system.

This is clearly a niche project, but in a rather large industry—at least as measured by revenues. Algorithmic, high-frequency trading is becoming ever more prevalent, so reducing the barriers to entry will allow more, and smaller, firms to get involved. Given the recent financial meltdown, that may not necessarily be a good thing, but keeping these tools in the hands of those who were "too big to fail" didn't work out all that well either.

Comments (4 posted)

Resetting PHP 6

Rightly or wrongly, many in our community see Perl 6 as the definitive example of vaporware. But what about PHP 6? This release was first discussed by the PHP core developers back in 2005. There have been books on the shelves purporting to cover PHP 6 since at least 2008. But, in March 2010, the PHP 6 release is not out - in fact, it is not even close to out. Recent events suggest that PHP 6 will not be released before 2011 - if, indeed, it is released at all.

PHP 6 was, as befits a major release, meant to bring some serious changes to the language. To begin with, the safe_mode feature which is the whipping boy for PHP security - or the lack thereof - will be consigned to an unloved oblivion; the "register_globals" feature will be gone as well. The proposed traits feature would bring "horizontal reuse" to the language; think of traits as a PHPish answer to multiple inheritance or Java's interfaces. A new 64-bit integer type is planned. PHP was slated to gain a goto keyword (though the plan was to avoid the scary goto name and add target labels to break instead). Some basic static typing features are under consideration. There was even talk of adding namespaces to the language and making function and class names be case-sensitive.

The really big change in PHP 6, though, was the shift to Unicode throughout. Anybody who is running a web site which does not use Unicode is almost certainly wishing that things were otherwise - trust your editor on this one. It is possible to support Unicode to an extent even if the language in use is not aware of Unicode, but it is a painful and error-prone affair; proper Unicode support requires a language which understands Unicode strings. The PHP 6 plan was to support Unicode all the way:

Unicode, however, appears to be the rock upon which the PHP 6 ship ran aground. Despite claims back in 2006 that the development process was "going pretty well," it seems that few people are happy with the state of Unicode support in PHP. Memory usage is high, performance is poor, and broken scripts are common. The project has been struggling for some time to find a solution to this problem.

From your editor's reading of the discussion, the fatal mistake would appear to be the decision to use the two-byte UTF-16 encoding for all strings within PHP. According to PHP creator Rasmus Lerdorf, this decision was made to ease compatibility with the International Components for Unicode (ICU) library:

But a lot of strings simply pass through PHP programs; in the end, the conversion turned out to be more expensive and less convenient than had been hoped. Johannes Schlüter describes the problem this way:

The end result of all this is that PHP 6 development eventually stalled. The Unicode problems made a release impossible while blocking other features from showing up in any PHP release at all. Eventually some work was backported to 5.3, but that is always a problematic solution; it brings back memories of the 2.5 kernel development series.

Developer frustration, it seems, grew for some time. Last November, Kalle Sommer Nielsen tried to kickstart the process, saying:

Things came to a head on March 11, when Jani Taskinen, fed up with being unable to push things forward, (1) committed some disruptive changes to the stable 5.3 branch, and (2) created a new PHP_5_4 branch which looked like it was meant to be a new development tree. That is when Rasmus stepped in:

And that is where it stands. The whole development series which was meant to be PHP 6 has been pushed aside to a branch, and development is starting anew based on the 5.3 release. Anything of value in the old PHP 6 branch can be cherry-picked from there as need be, but the process of what is going into the next release is beginning from scratch, and one assumes that proposals will be looked at closely. There are no timelines or plans for the next release at this point; as Rasmus explains, that's not what the project needs now:

So timing and features for the next PHP release are completely unknown at this point. Even the name is unknown; Jani's 5.4 branch has been renamed to THE_5_4_THAT_ISNT_5_4. There has been some concern about all of those PHP 6 books out there; it has been suggested that a release which doesn't conform to expectations for PHP 6 should be called something else - PHP7, even. There's little sympathy for the authors and publishers of those books, but those who bought them may merit a little more care. But that will be a discussion for another day. Meanwhile, the PHP hackers are refocusing on getting things done and having some fun too.

Comments (111 posted)

Evi Nemeth (an Ada Lovelace day tribute)

Sometime around 1981, when your editor was an undergraduate at the University of Colorado, he was introduced to the Computer Science department's prized VAX 11/780, which, at that time, was a dual boot system, switching between VMS and and early BSD Unix every afternoon. The chief of the Unix side was Evi Nemeth. The first thing that struck most people about Evi was a general sense of distraction and disorganization; it's only later that one realized the she was one of those smart people who make things happen.

Evi armed your editor with a dog-eared edition of the K&R C book and access to the Unix source. She encouraged the writing of a fix to the system's memory management code, which tended to let one memory hog take over the system - a bad feature on a multiuser computer. That "fix" has, happily, vanished from living memory, and any backups which exist will no longer be readable. But the pure fun of being able to dig into the operating system code lasts to this day.

These days, Evi lists her office as being "my sailboat, Wonderland, somewhere in the Caribbean." She has a relatively low profile in the Linux community, despite being one of the authors of (and the inspiration behind) the Linux Administration Handbook, but the USENIX crowd knows her well. Her time at CU launched a whole generation of hackers who are in the field for the joy of it, and every one of them thinks back fondly to one of the people who got them started. Well done, Evi; you helped make all this happen.

Comments (11 posted)