Shuttleworth sees fewer clouds in Ubuntu's future
'Firm decisions' needed
Magic Quadrant for Enterprise Backup/Recovery
There are some tough decisions ahead about which cloud open sourcers should support in the next major version of Ubuntu.
Canonical and Ubuntu founder Mark Shuttleworth has said that "firm decisions" are required about the cloud platforms that can be supported.
Shuttleworth made the announcement while revealing the animal-inspired code name for Ubuntu 11.10, due later this year. Ubuntu 11.10, the successor to 11.04 due next month, will be named Oneiric Ocelot – our dictionary, by the way, defines oneiric as "of or relating to dreams or dreaming".
Apparently looking beyond 11.10 to the next Long Term Support (LTS) release edition of Ubuntu, though, Shuttleworth talked of the need to be more selective on the distro's cloud platform picks. "In the cloud, we'll have to tighten up and make some firm decisions about the platforms we can support for 12.04 LTS," he said here.
Shuttleworth pretty much leaves it there, raising more questions than offering answers.
Instead, he expects there will be a "feisty debate" on the subject at the forthcoming Ubuntu Developer Summit, scheduled for May 9-13 in Budapest.
"UDS in Budapest will be full of feisty debate on that front, I'm sure, but I'm equally sure we can reach a pragmatic consensus and start to focus our energies on delivering the platform for widespread cloud computing on free and flexible terms," Shuttleworth said.
Ubuntu's Natty Narwhal, scheduled for next month, will pack APIs for two cloud architectures: OpenStack and Eucalyptus.
Shuttleworth confirmed the dual-cloud stance after The Reg reported that OpenStack APIs were being added to the forming Linux distro via the Ubuntu repositories by members of the Ubuntu community also working on OpenStack.
Ubuntu, however, had made a strong early show of support for Eucalyptus, with Shuttleworth understood to have personally invested in Eucalyptus Systems - the open-source company trying to sell services around Eucalyptus and commercially maintain the system. Shuttleworth invested before chief executive Marten Mickos took the helm in March 2010.
Since those early days, Eucalyptus has been put on the back foot by a swell of industry backing for OpenStack, with Canonical joining the OpenStack community in February.
Shuttleworth said in January that Ubuntu 11.04 would feature both clouds. "We will have both OpenStack- and Eucalyptus-based cloud options in Ubuntu 11.04 in April," he said.
On the flip side, there's uneasiness in the OpenStack community. Despite the project's open credentials, a single company has grown to dominate OpenStack's management structure: project cofounder RackSpace.
In an apparent attempt to assuage these concerns, Rackspace last week said that it was expanding OpenStack's newly renamed project policy board - previously the project oversight committee - which will now have 12 seats with eight elected and four nominated.
Its unlikely that Canonical would completely drop one cloud for the other. Rather, one might be deprecated and simply live on in the Ubuntu universe – or multiverse – getting updates from members of the community rather than from Canonical's own engineering team.
Shuttleworth, meanwhile, used the unveiling of the Oneiric Ocelot name to rally developers to keep pushing the Linux distro. Natty Narwhal will see major changes in look-and-feel as it moves to a new Unity interface as the official standard, and demotes Gnome.
He also called out support for Qt, the cross-platform and cross-device development framework until very recently owned by Nokia but now a casualty of Nokia's Windows Phone partnership with Microsoft.
"We'll need to keep up the pace of innovation on all fronts post-Natty. Our desktop has come together beautifully, and in the next release we'll complete the cycle of making it available to all users," Shuttleworth said.
In a nod to the hard work in making the move to Unity, he said: "Natty is a stretch release: we set out to redefine the look and feel of the free desktop. We'll need all the feedback we can get, so please test today's daily, or A3, and file bug reports! Keep up the discipline and focus on the Narwhal, and let's direct our daydreaming to the Ocelot." ®
COMMENTS
Clouds
They come and they go.
They scud across the skies
And piss all over those below.
@Andy E
"I always get the impression the utilities were written by clever people who just happen to be lazy and can't spell properly"
Actually, it was more like the Teletype ASR-33's in common use as terminals back when UNIX was being formed being sooooooooooooo sloooooooow, that people abbreviated commands and flags so that they could work reasonably quickly. It is also the reason why ed is incredibly terse, but ultimately very powerful as a line editor. I recommend to every serious UNIX/Linux user that they learn ed, just so they can use vi and sed effectively.
Another explanation is that they were lazy, a positive attribute for all good system admins. (do what's needed efficiently and with the least effort). At least, that's my opinion.
@Andy E
The downside of the VMS DCL command line model was that for every command, you had to add entries to the DCL command dictionary, whatever that was called (it's been a long, long time since I did any DCL configuration, and much of that was on RSX/11M not VMS). All of the command line parsing and in-line help that allowed abbreviations was done by the DCL command processor, although I do believe that it passed any unprocessed arguments through to the program as a last resort.
One of the most useful and irritating features (both at the same time) is that UNIX-like operating systems left that to the commands , although if you look at ancient UNIXes, there were very strong conventions that should have been followed (if you look back at the USENET archives, there are many quite animated discussions about whether the shell should do more command line processing than it did/does). This meant that you could easily add commands to UNIX, and that internal shell commands, functions, aliases and external programs appeared almost seamless.
One of the quirks, however, was that some of the ancient commands, many still used today, never did abide by the conventions (the most obvious of examples of this are the "dd" and "find" commands, that have been there almost since Epoch began, and never did conform).
Over time and UNIX versions, the conventions broke down. One character flags gave way to words, and as soon as that happened, you have to code around whether the arguments like "-Fart" are equivalent to "-F -a -r -t", or whether there is a wordy argument which actually tells the program to break wind (this is a quick example off the top of my head from the "ls" command. There may be better ones).
Then the BSD/GNU people got involved, and introduced what I regard as the abomination of the -- (double minus) argument, supposedly to allow the syntax to be extended, but actually misused my many post-linux developers to completely replace the original UNIX flag processing implemented by getopts.
Couple this with the fact that often the GNU and GNU-like commands were never documented by proper man pages (or even their supposed native "info" command), or even by informative usage strings, and that there was effectively no controlling influence (a flaw in the Open Source contributory model itself) and you get to today's mess. I can totally sympathise with you with it being difficult and awkward to use (I actually count VAX/VMS as being the OS I would prefer to use after UNIX)
I look back fondly to V7 and SVR2 and SVR3 days, when conventions meant something, and people bothered to use them.
My coat is the sad old gabardine raincoat with the Lyons annotated UNIX source in the pocket (which, in case anybody bothers to read to the bottom of my past comments, I lost, but have found again).
IT infrastructure monitoring strategies
Agentless Backup is Not a Myth
Top 10 SIEM implementer’s checklist
Steps to Take Before Choosing a Business Continuity Partner
Enabling efficient data center monitoring
