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,
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:
For the button positioning, however, there was absolutely no official
stance from the design team on the reasoning behind it. In a recent Ars
Technica article, Ryan Paul states that Ivanka Majic posted explanations in
her blog [here
]. As I previously stated in this bug report, not only her blog post
mentions only the questions and no answers, but clearly states that she
does not agree with the design herself.
I doubt that revealing the reasoning would satisfy all users, but at least
they would have a base to build arguments on. Right now, a lot of people
are *assuming* the reasons and criticizing Canonical based on those
assumptions. This is wrong, but there's little else possible when an
official statement does not exist.
Mark Shuttleworth did provide
something of an "official statement" further down in the bug comments:
The default position of the window controls will remain the left,
throughout beta1. We're interested in data which could influence the
ultimate decision. There are good reasons both for the change, and
against them, and ultimately the position will be decided based on what
we want to achieve over time.
Moving everything to the left opens up the space on the right nicely,
and I would like to experiment in 10.10 with some innovative options
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
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
You've said a couple of times that the idea is to free up the right hand
corner for Other Stuff You Will Put There Later, which is a valid
idea. What I don't get, though, is why you think it makes sense to do the
freeing-up before you've got around to inventing the Other Stuff. It gives
people all the drawbacks of the re-arranging with none of the benefits of
the Cool New Stuff, so it's not that surprising that they wind up
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:
We have a kernel team, and they make kernel decisions.
You don't get to make kernel decisions unless you're in that kernel
team. You can file bugs and comment, and engage, but you don't get to
second-guess their decisions. We have a security team. They get to make
decisions about security. You don't get to see a lot of what they see
unless you're on that team. We have processes to help make sure we're
doing a good job of delegation, but being an open community is not the
same as saying everybody has a say in everything.
This is a difference between Ubuntu and several other community
distributions. It may feel less democratic, but it's more meritocratic,
and most importantly it means (a) we should have the best people making
any given decision, and (b) it's worth investing your time to become the
best person to make certain decisions, because you should have that
competence recognised and rewarded with the freedom to make hard
decisions and not get second-guessed all the time.
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
[Who's] in a position to tell him his designs are bad if not the external
Ubuntu community? You can't really expect Canonical employees to go
toe-to-toe with him when he's made up his mind. That's the problem with
organizational structures that are built on cults-of-personality... the
lines between what it means to be a meritocracy and an autocracy get a
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:
Ubuntu is utterly and completely Shuttleworth's baby. If he wants to
collaborate with the community that has been drawn into the project's
promise of transparency..then he should make good on that promise and be
transparent and communicate about plans. If he wants to be Steve Jobs 2.0
and wow potential consumers with innovative product offerings born from
behind closed doors with no community input then he can be that instead. He
just needs to decide be consistent about how he wants to interact with the
Ubuntu community. Consumer or collaborators...his choice.
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
Look, I understand this is risky. In my judgment, it's worth the risk.
Being able to tackle risky things is one of the things that gives us the
chance to catch up to the big guys, and beat them. That doesn't mean we
should be cavalier, but I'm not going to shy away from an opportunity to
do something much better now just because Microsoft did something a
particular way 20 years ago.
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
Ubuntu is plenty big enough that there is an area where anybody can make
themselves an expert, take on responsibility, and lead. But it's also
big enough that if we try to make everybody feel like they can weigh in
on *every* decision, we'll grind to a halt.
This is a flashpoint, but most decisions are not as contentious as this
one. I'm backing this decision because I think it's the right one in the
long term. It may be right, it may be wrong, but I have a mandate to
take the decision. The same is true of our kernel lead, and our
community governance leads. They are fallible (I certainly am) but they
are nevertheless empowered to take decisions.
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)
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
"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
We believe open source accelerates customer adoption of our software.
Most firms have a plethora of systems in their shop and they
continually run afoul of technology not built on open standards, open
APIs, etc. They have additional concerns about a chronic inability to
get consulting resources from proprietary vendors to make changes they
require along their business timelines. Open source changes those
paradigms, and present customers with an alternative that is open, has
a much lower price point, and affords them the flexibility to jump
right in (or have a trusted consulting resource jump right in) and
make the changes they require.
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
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
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
Comments (4 posted)
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
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
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:
PHP6 will have Unicode support everywhere; in the engine, in
extensions, in the API. It's going to be native and complete; no
hacks, no external libraries, no language bias. English is just
another language, it's not the primary language.
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
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
Well, the obvious original reason is that ICU uses UTF-16
internally and the logic was that we would be going in and out of
ICU to do all the various Unicode operations many more times than
we would be interfacing with external things like MySQL or files on
disk. You generally only read or write a string once from an
external source, but you may perform multiple Unicode operations on
that same string so avoiding a conversion for each operation seems
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:
By using UTF-16 as default encoding we'd have to convert the script
code and all data passed from or to the script (request data,
database results, output, ...) from another encoding, usually
UTF-8, to UTF-16 or back. The need for conversion doesn't only
require CPU time and more memory (a UTF-16 string takes double
memory of a UTF-8 string in many cases) but makes the
implementation rather complex as we always have to figure out which
encoding was the right one for a given situation. From the
userspace point of view the implementation brought some backwards
compatibility breaks which would require manual review of the
These all are pains for a very small gain for many users
where many would be happy about a tighter integration of some
functionality. This all led to a situation for many
contributors not willing to use "trunk" as their main development
tree but either develop using the stable 5.2/5.3 trees or refuse to
do development at all.
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
I've been thinking for a while what we should do about PHP6 and its
future, because right now it seems like there isn't much future in
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
The real decision is not whether to have a version 5.4 or not, it
is all about solving the Unicode problem. The current effort has
obviously stalled. We need to figure out how to get development
back on track in a way that people can get on board. We knew the
Unicode effort was hugely ambitious the way we approached it.
There are other ways.
So I think Lukas and others are right, let's move the PHP 6 trunk
to a branch since we are still going to need a bunch of code from
it and move development to trunk and start exploring lighter and
more approachable ways to attack Unicode.
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:
We don't need timelines right now. What we need is some hacking
time and to bring some fun back into PHP development. It hasn't
been fun for quite a while. Once we have a body of new interesting
stuff, we can start pondering releases...
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)
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
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
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
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
Comments (11 posted)
Page editor: Jonathan Corbet
Inside this week's LWN.net Weekly Edition
- Security: Cookie-based authentication; New vulnerabilities in curl, krb5, qt, samba,...
- Kernel: The end for Video4Linux1; KVM, QEMU, and kernel project management; Defining trace events; The end of the huge page series.
- Distributions: Debian Project Leader election 2010; new releases from Fedora Unity, FreeBSD, openSUSE Education, Owl, Ubuntu, and XtreemOS; Paul Frields: FPL future; Interview with CrunchBang creator...
- Development: Not much of an email review; Ardour; GDB; Greenlet; Python; ...
- Announcements: Tokyo stock exchange system built on RHEL; Novell Rejects Elliott Associates' Proposal; HTC responds to Apple; ACTA treaty; conference videos...