My first app for Ubuntu phones is in the Ubuntu phone app store!
It’s called “Riddling“, and it’s a puzzle game involving intelligence, psychology, lateral thinking, research, and guesswork.
If you have an Ubuntu phone, you can get it right now: just search for “Riddling” in the Applications scope and install it. Let me know what you think.
If you just want to play the game, the rest of this post will not be of interest to you. I wrote Riddling partially because I think it’s a good idea for a game, but also to get some more detailed experience of the whole process of creating a completed application for Ubuntu phones: everything from the app review process to all the work you need to do outside core gameplay to make a decent app, and including the tools for building and checking applications, how to test them on the phone, and so on. So below I’ll outline some thoughts on this whole process. The basic summary is that building apps for Ubuntu is great and you should do it. There are still a few rough edges in the whole process, and so I’m writing them down in the hope that it’s useful feedback. Your thoughts, links to Launchpad bugs, disagreements, improvements, and war stories are invited.App Creation
On with the show.
One creates an Ubuntu app with the Ubuntu SDK. That makes sense: an SDK is a collection of APIs which your app can use. For Ubuntu, though, “Ubuntu SDK” is also the name of the IDE, the development environment: to make an app, you open the Dash and search for “Ubuntu SDK” and then run it. That makes a certain amount of sense, but it makes this really hard to talk about: questions such as “how do I run my app in Ubuntu SDK” sound strange, because it’s entirely unclear whether you’re talking about the APIs or the IDE. This is why developer environments have names: Visual Studio, Xcode, Eclipse. I wish the “Ubuntu SDK” was called an actual name.
“But it’s got a name!”, some of you will be saying. “It is Qt Creator.” Ah, but it isn’t. It is Qt Creator with extra stuff. I can’t just say to people “to make an Ubuntu app, run Qt Creator” because they won’t have the extra stuff. “To make an Ubuntu app, run Qt Creator and then install this other thing and this other thing and configure this thing and this other thing…” is the way to having people say, that sounds really hard so I’m not going to do that. This is why I wish that “Ubuntu SDK” was called something. Branding is important. The Ubuntu app development experience is not just “Qt Creator with an Ubuntu plugin”, or at least it can’t be if it’s going to be successful.Custom build steps
Riddling is basically a game where you have to type in an answer for each level to proceed to the next level. Ubuntu users being what they are, a reasonable proportion of them will think, I can’t work out the answer for level 11, so I’ll just look in the source and get the answer from there. This would, obviously, spoil the game somewhat — the challenge is to research and think laterally, not to be a developer who knows what source code is — and so the game does not directly contain the answers; the game contains hashes of the answers and your entered answer is compared against that, in a similar way to how web services and Ubuntu itself check that your login password is correct without ever having a plain-text copy of that password around to check against. This is all well and good, but obviously I can’t be writing hashes all the time by hand. So my copy of the game contains the real plain-text answers, and when I build the game I take those plain-text answers and create the hashes of them to store in the released version. What this requires is a custom build step — a way to add an extra step to the build process as run by “Ubuntu SDK”, so I can add a step which does this answer encryption.
It is not possible to add a custom build step to the build process for Ubuntu SDK apps, at the moment. What this means in practice is that I have to write my own build process. I have a little shell script which does all the things I need: does the answer encryption, creates icon images from my original SVG icon, builds a click package. And I run that shell script instead of using the Ubuntu SDK thing. That’s quite annoying: it means that I’ve stepped almost entirely outside the Ubuntu SDK IDE at that point. (And indeed I’ve found myself doing most of my editing in my normal editor, Sublime Text.) To be clear, it is a credit to the Ubuntu SDK team that it’s perfectly possible to make Ubuntu apps without being forced to use the Ubuntu team’s choice of IDE. But I want to use their IDE — it’s all nicely integrated, it provides a whole bunch of stuff like device connection and code completion and debugging that others don’t — but I can’t because of this one blocker about custom build steps. All I’d need is some way to add a step which runs an arbitrary command: with that, I’d be golden. I spoke to some Qt Creator experts and it isn’t doable at the moment, but apparently it might be: this is exacerbated by how Qt Creator documentation basically assumes that you’re a C++ person and therefore “I want a custom build step” is “add something to your cmake file”, which doesn’t even exist if you’re writing a pure QML app as I think apps should be (and this one certainly should be, even if others shouldn’t). This feeling that “well, you’ll be writing C++ anyway, or you’re not a real programmer” does seem to rather pervade the community; it’s something that I hope Ubuntu can help fix.Lint
“Linting” is the process of checking some code for accuracy and completeness. In this example, it’s about checking your built click package to confirm that it’s correct. Alan Pope pointed me in the direction of the excellent click reviewers tools: once I’ve built my click package, I do click-reviewers-tools/bin/click-run-checks com.ubuntu.developer.whoever_1.0_all.click and it gives me a bunch of information about the package and catches a bunch of errors. It’s incredibly handy: I was, for example, providing a full path to the qmlscene binary, and that works fine on my computer and also when running my app by hand on the phone, but it doesn’t work when running the app on the phone from the Dash. The click-reviewers-tools caught that error and I fixed it. That’s great. These tools need more publicity. I understand that they’re supposed to be integrated into the IDE build process at some point, which will be excellent (although it wouldn’t have helped me because of my custom build script, as above).
QML is quite well documented by the Qt project. The Ubuntu SDK components are mediumly-well documented by the Ubuntu team, and that documentation improves and gets more detailed every day, so I’m not worried about that. What is both confusing and annoying is that those two bits of documentation are in different places and are unconnected. For example, the documentation for an Ubuntu.Components.Label shows that the only thing you can customise about a Label is its fontSize. The example then sets text on it. What’s text? That’s undocumented? And how do I set the colour of the text? What about rich formatted text?
Well, an Ubuntu.Components.Label is actually an augmented QML Text item. The QML documentation for Text shows a zillion other properties that are settable, and to make any use of a Label at all you need to know that it’s really a Text but with extra stuff. The Label documentation doesn’t help with this at all. I only know that a Label is really a Text because I asked someone and looked in the source for the Ubuntu SDK itself. And if I look at the Text docs they say I can set font.pixelSize… but if I’m really a Label then I’m not supposed to do that; I’m supposed to set fontSize to one of the chosen Ubuntu sizes, for consistency across the platform.
The documentation being split like this makes it way harder to work out what to do. I think my proposed solution is that the Ubuntu documentation site ought to include the QML documentation too, so a Label lists all its properties, not just the ones that differ from Text, and explains why you should use fontSize rather than font.pixelSize.
This is a fairly mammoth undertaking, and I’m sure that the Ubuntu documentation team are aware of it and are working on it. For the moment it’s doable — as I say, I have successfully written an app — but I think it will confuse new app developers who are unaware that the Ubuntu SDK documentation only tells half the story, and the Qt QML documentation isn’t necessarily the best way to build Ubuntu apps.Making a decent app
Part of the goal in writing Riddling was to really nail down the difference between “core gameplay” and “a finished app”. Riddling is ridiculously simple in concept: as mentioned, it’s just “allow the user to type in an answer and then check it against the list of answers”. I had the basics of the game implemented in, not kidding, 15 minutes. Everything else I did is bridging the gap between “prove the basic principle” and “make a game that people want to play”. All this bridging stuff is critical; it’s what makes the difference between a good idea and a good app. The idea (and the implementation of the idea) is about 5% of what makes an app good. Many open source apps haven’t quite grasped this and are just a bare implementation of the idea without the other 95% which takes it from idea to app. The Ubuntu philosophy is to do the other 95% too (whether that’s always succeeded is a different question, of course). So, for reference, here’s the list of other stuff I had to do to make Riddling once I’d made the core game in 15 minutes.
Work out how to encrypt the answers and encrypt them; add the “universal answer” which is accepted for every question so that I can test the game; choose a background gradient; choose font sizes; adjust the spacing between the clue, the text box, and the submission button on the front screen; work out how to convey the current level number; make the text box accept Enter to submit as well as pressing the button; add the list of previous answers; add an about page; have the app remember your current position when it’s closed and restarted; add a way to reset the game so you can hand the phone to your kids and they can play; add subtle sound effects for correct and incorrect answers; credit the freesound creators of those sound effects; add an animation transition to show a correct or incorrect answer; decide on the proper easing for those animations; write a one-line description of the game; write a longer description of the game; design an icon; make icons in various different sizes; decide on a licence; make a website of the game; take screenshots of the game; test the game on a phone; test the game on a desktop; decide how big the window should be on a desktop; upload new versions of the click package to the website; work out how to tell people about the app; post to G+, to reddit, to twitter.
None of that is to applaud myself for work; it’s to illustrate how much stuff still remains to be done once you’ve come up with an idea and then built a rough implementation of that idea. None of it is specific to building Ubuntu apps, either. I personally am enormously guilty of having an idea, knocking out a rough implementation of that idea, and then thinking to myself “cool, that works; turning that into an actual game is just a small matter of programming and is quite boring, so maybe I’ll just release this as it is”. That’s not acceptable now; I’m gradually starting to understand that.
Also: get a designer. My graphical guy (who would probably be called an “art director” if we were, say, Electronic Arts rather than just two blokes) went on and on about getting the typography and spacing right, and we went backwards and forwards on it repeatedly. And he’s right: it all feels better now. Thank you, Mike. If you need someone who’s great at this stuff, let me know and I’ll put you in touch.Submitting the app
At this point, I’ve built an app, I’m happy with it, and I’ve got a click package for it. Time to add it to the store so other people can play it! This will therefore be a laundry list of little complaints about the smoothness of the app submission process. Before I start, though, I should say this: it is fantastic that I can make an app and submit it and have it show up in the store after about 20 minutes. The team who built this and who do the reviews deserve congratulation: everything I outline below is merely a slightly roughened corner on an otherwise good process, and I’m confident that most of these issues are already known and that all of them will be fixed. In particular, I believe that it should be possible soon to submit an app direct from “Ubuntu SDK”, meaning that this whole web-based submission process will largely go away (although for people doing custom builds it will still need to stay around, of course). I should say that even if submission-from-the-IDE becomes a reality, there should be a submit-to-the-app-store command line tool to do it as well (which would do all the same stuff), so people with custom builds can use it and you’re not wholly tied to the IDE.
On the first screen of submitting an app, you’re asked for an “application name” and a “package name”. I at first thought that the “application name” was the human name for my app (“Riddling”) and the “package name” was the techie computer name which the click package is called (org.kryogenix.riddling). However, the “package name” doesn’t allow dots in it. After being hugely baffled by this, I asked on IRC, and popey confirmed that the “package name” is the last bit of the techie computer name: that is, all my apps are “org.kryogenix.something” and the “package name” is the something. The “org.kryogenix.” bit is called your “namespace”, and you select it when you first sign up for app submission; the “package name” is then glued onto the end of your namespace to make the name that the click package is called.
You’re asked for a “tagline”, a one-line description of your app. There are four different places to describe your app: the “tagline” in the submission process, the “description” in the submission process, the “description” in your manifest.json file, and the “Comment” in your appname.desktop file. It is not at all clear what the difference between these is. This, I think, could be solved by showing, as part of the app submission process, what the app preview in the Dash will look like for users once the app is submitted. What I discovered is that the manifest.json “description” is currently ignored (but will presumably become important once submission is done from the IDE), the appname.desktop “Comment” is also ignored, and the “tagline” and “description” are shown one after the other in the Dash app preview when installing an app. So if you have a paragraph which describes your app, the “tagline” should be the first sentence of it and the “description” should be the remainder.
The submission process asks for a 256x256px PNG icon. This icon is used by the Dash when looking at an uninstalled app, but it is not used as the icon for your app once the app is installed. Instead, the icon used once the app is installed is the one named as Icon in appname.desktop. There’s no guidance as to the size that this icon should be (I have emailed the Canonical design team asking for such guidance as part of the ongoing App Design Clinics), but I can tell you that 64×64 is too small and your icon will be zoomed up and look blurry. I used the same 256×256 icon that I added in the submission process, and that worked fine: nice sharp icon on the phone.
The “required hardware” option in the submission process says “PC Only”, and that’s all you can choose. That puzzled me for a while — surely there should be a “phone” option? What’s the point of providing a dropdown for this if there’s only one entry in it? — but I assume that this will change later, so just choose “PC Only” for now.
Sadly, there is currently no way to install a click package on the Ubuntu desktop. The process of developing an app, making a click package, and submitting it is rather excellent, but it’s close to impossible to make your app also available to Ubuntu desktop users, which would massively increase the number of people who are able to use it. Even if an app is built with convergence in mind — if it alters its display for more screen real estate, as Karma Machine does, or if it’s happy running in a small window and there’s no need to change, as Riddling is — actually getting the app to desktop users can’t really be done right now. I understand the reasoning here; click packages will be able to be installed on the desktop in the next release, and that’ll be fantastic. Right now, though, apps you build are to all intents and purposes phone only, unless you’re prepared to provide a bunch of techie instructions about installing dependencies and checking out bzr branches, or you’re prepared to build a .deb package. This will be cool once it’s improved, but right now it’s annoying.In summary
I’ve really enjoyed making Riddling (and from the feedback, people are enjoying playing it). It’s clear to me that all the moving parts of “the Ubuntu platform” are coming together to make something which is great to write apps for and easy to write and distribute apps for, and that’s what I want from my OS of choice. All the stuff I mention above will be fixed soon, I’m sure. Meanwhile, while you’re waiting for that, open up the Dash on your phone and search for “Riddling”. Maybe you’ll be the first to get to the end!
I've just been putting together a post about some modifications to Scratch for use in a school environment that I have used for the Code Club that I run. Everything went well on the school computers, but when I tried to do the same on my own Windows 7 desktop to get some screenshots things went a little weird.
First off, it is a pain to edit the required .ini file. Right click and edit doesn't give you administrator privileges so you can save it. My first thought was to run Explorer as administrator, but sadly the administrator privileges don't extend to Notepad when you right click and choose edit. As it happened I was only going to use Notepad for the screenshots, so I took them and then used Notepad++ to do the actual edit. A quick right click and "Edit with Notepad++" followed by closing it and opening it again with administrator privileges did the trick.
This is where things went from slightly annoying (isn't Windows always!) to weird. When I ran Scratch my edits to the .ini file didn't appear to have taken, so I checked the file - fine, nothing wrong there. So this being Windows I decided to try a logout and login just to be sure there wasn't anything odd going on there. No joy. So I decided to check from the command line with Edit. For some reason when I opened the .ini file up in Edit the extra two lines I had added were missing, so I checked in both Notepad and Notepad++ and they were there. I double checked I was working on the same file and there had been no name change for some strange reason and all was well - or at least I confirmed I was working on the same file.
At this point I realised that the command line I was using wasn't running as administrator, so I opened up an administrator command prompt and headed to the same directory to edit the file there. The only issue was that when I open it in Edit the two lines I had added were there. This would seem to imply that there are two versions of the file, one for the administrator with the edits and one for my user account without. Although then again, not, since when I edited in the GUI with Notepad or Notepad++ either as administrator or my standard user I did have the edits! This didn't make much sense. For a moment it looked as though I was going to have to mess around with changing the permissions to work out what was going on. Anyway, I switched to the non-administrative command prompt to edit the file, only to find that my changes have magically appeared (and I hadn't messed with the permissions yet)! So I tried Scratch again and there we go, the changes are working.
So it would appear that, for some reason, the edits I made to the file (using administrative privileges) took a few minutes and a logout and back in again to be visible to my user account! ...and some people wonder why I prefer using Linux!!
I’ve got a spare pair of tickets for the sold out official Doctor Who 50th anniversary celebration convention and I’m going to give them away as a thank you to someone who donates to my Malawi Mission. The tickets are adult tickets in the Ice Warrior entry group on Sunday 24th November.
Next summer I will climb the highest mountain in southern Africa to raise money for the AMECA Trust. I am going to get bitten by a lot of insects and generally have a tough time of it. Why am I doing this? The AMECA Trust don’t just hand out cash or pills. They have built a financially viable hospital in Malawi, where those who can afford to pay for healthcare make it possible for children to receive theirs for free. It’s an amazing feat. As if that wasn’t enough the AMECA Trust give nursing students from the UK bursaries to work in Malawi, making a real difference in the lives of people who have so little, and helping UK medical workers gain vital experience.
Just donate £10 (or more!) to my charity fund between 28th October and 10th November, mentioning “convention” in the message to be in with a chance to get your hands on the tickets. Remember to leave your e-mail address when you donate: Don’t donate anonymously!
If you are a UK tax payer, please give using Gift Aid. This helps charities reclaim a whopping 20% extra on top of the amount you donate.Donate here to enter the draw.
I’ll pull a lucky winner out of the virtual hat and e-mail them the eTickets.
Terms and Conditions
If you have any questions, please leave them in the comments.Pin It
Eat, Drink and talk LinuxEvent Date and Time: Wed, 30/10/2013 - 19:30 - 23:00
Some years ago I used to do a podcast called LugRadio. We did it for four years, delivered 140+ episodes, had 2 million downloads, and it spawned five live events. We wrapped it up as I moved to the USA, but then a little later Stuart Langridge and I experimented with a new show caled Shot Of Jaq. It was a different format and very focused on post-show discussion. We did 60+ shows.
We wrapped up Shot Of Jaq about three years ago and I had been getting the itch to do a show again. This time I wanted to do something more like LugRadio; four presenters, 45 mins to an hour long, include an interview, but this time for it to be a little less anarchic and more like Top Gear.
As such, I am delighted to present our new show Bad Voltage.
Bad Voltage takes a fun and amusing take on technology, music, politics and anything else we think we and our listeners would find interesting. It is not just about Open Source and Linux, but will naturally gravitate to those topics based on our experience.
The show has an amusing line-up with a diversity of experience. It includes Jeremy Garcia (founder of LinuxQuestions), Stuart Langridge (Web Development Consultant, co-founder of LugRadio), Bryan Lunduke (NetworkWorld writer, co-founder of the Linux Action Show, creator of Linux Tycoon), and myself.
The show takes a fun, loose, and amusing take on the topics we present. It is 45mins to an hour long, features an interview, a review of a product/service/software, features some topics for discussion, a letters segment where we read out and respond to letters to the show, and more.
We launched the show (Season 1 Episode 1 ‘Socially Awkward Headgear’) on Thursday and it includes:
Go and check it out here, and be sure to subscribe to it in your fave podcasting client or on iTunes!
The response had been fantastic. We have had over 60GB of downloads, 2000+ people check the show out, 120+ people join our Google+ Community, 90+ people join us on Twitter. We also have ‘#badvoltage’ on Freenode. Our community is forming, and they are cool people…they are Bad Voltage people.
Bad Voltage is all about the community, so be sure to come and join us and send over your feedback and thoughts on the show to firstname.lastname@example.org – we will read your emails out on the show and we really want to tighten up the format and make it as good as possible, so your thoughts on what works well and what works less well is appreciated.
Why? A combination of wanting to do something different coupled with the desire to reclaim my second bedroom, which is currently tied up as an office.
Working in an office in the future will be weird ("You mean I have to get dressed every day?!") but hopefully not unduly burdonsome.
My two-year plan still remains in effect: Pay off this flat as soon as possible, then purchase another and rent this one out. Giving me some income of my own, which I will need.
The "five" year plan involves me quitting work, so that I can stay home and raise children. That makes sense because sometime next year I'll become the partner who earns the least amount of monies, and I'll also be the partner with the lowest upper-bound on salary potential (short of moving to London/similar which I've always ruled out).
Having rental income for myself means I'm not utterly dependant on other money, and all being well this place will be 100% paid off within 18 months.
(After that lots of saving will take place for a deposit for the second place. We did bid on a couple of places locally, which were outstanding, but it is perhaps for the best we didn't win them. No more looking at ESPC!)
Bytemark now becomes a company I recommend 100% for hosting in the UK. In the past I've always said nice things, but I've not strongly recommended them/us, because I'm too biased.
All my personal hosting, except for one virtual machine, will remain at Bytemark indefinitely. Lovely, flexible, and great.
(I have one outside guest for the purposes of diversification. That currently lives at Mythic Beasts.)
I’ve been playing around with a Sony SmartWatch 2. Herein some thoughts on wearable devices and smart watches.
There’s been several iterations of the smart watch idea. The Verge smartwatch roundup covers the state of play; The Independent has an interesting article on why a Google smartwatch makes sense, and the Samsung Galaxy Gear advert demonstrates nicely the desire for these “James Bond” gadget watches over the years.
The Sony Smart Watch 2 is really nice hardware. It’s a decent size, but doesn’t feel too heavy or cumbersome on the wrist.
The “standby” watch face screen is easy to read. It also has a clever power saving feature where the display is turned off completely unless it detects you. I haven’t figured out how the detection works – presumably motion, touch, proximity or resistance. When the screen is on full it is bright and readable. The watch display is responsive, and swiping from screen to screen is fast and smooth.
The watch needs to be tethered to a phone, and this symbiotic relationship makes sense (up to a point). The watch on your wrist is more accessible than the phone in your pocket, so it’s easier and more natural to glance at the watch to see information. The challenge is figuring out what information you want to see, and getting that information displayed. For example, if you’re using a bluetooth headset and you receive an incoming call, caller ID is handy, along with the ability to accept or reject the call. SMS notifications are useful, but email notifications are too frequent and too verbose to be of much use.
Since the watch is strapped to your wrist and always on you, it allows nice features like warning you when you leave your phone behind. This works, and is useful. On the Sony watch, I achieved this using Augmented SmartWatch Pro; it vibrates the watch when the bluetooth connection to the phone is lost. It looks like similar functionality is on the Samsung Galaxy Gear.
You can’t install apps directly on the watch, you have to go via a management app on the phone. That makes sense, as the watch screen is not well-suited to browsing and buying from an app store. Sony claims more than 300 apps for the Smart Watch / Smart Watch 2. There’s a major flaw, however: you quickly realise that you want to customise the standby screen and watch faces, but those can’t currently be modified. So the alternate watch face apps are useless – you have to turn the watch display on, then navigate through the Sony watch face in order to see the alternate app. Or, you leave the app running and watch your battery drain in a matter of hours. It’s somewhat mitigated in that apps receiving notifications can light up the screen themselves. Apps like Augmented SmartWatch Pro go some way to offering useful alternate screens, even if they can’t be permanently displayed:
On the screen above: the weather forecast for my location, upcoming meetings, time, current temperature, phone battery status (graduated colour bar on the right) and watch battery status (left; non-existent).
Speaking of battery life: I’ve found it to be better than a phone, but still only lasting a few days (depending on usage). In a world where we get used to plugging in our phone every night that wouldn’t be so bad, except that the cover over the micro-USB charging slot is fiddly, and plugging in multiple devices quickly gets boring. This would have been a killer use case for wireless charging; leaving the watch on a powermat on the bedside table makes perfect sense. Without it, I have to check the battery status before deciding to wear the watch in the morning. VentureBeat reports that Sony is working on one hour wireless charging, which would be great but I’ll believe it when I see it.
So does the smart watch make sense? Almost. Some features are genuinely useful: answering calls from the watch using a bluetooth headset, seeing SMS messages, checking missed calls, reading the name of the Spotify track playing. None of these amount to “killer” features, and I’m not sure enough consideration has been given to what people could actually use a smart watch for – but perhaps that’s up to third-party developers to innovate and discover.
On the down side, there’s not enough fine-grained customisation or control over what content is delivered to the device. For example, I’d like only mail from certain people or with certain GMail labels to reach the device, rather than everything in my inbox. I’d like Twitter direct messages and certain hashtags to reach the device, but not all timeline tweets. I’d like to customise the watch face to display day of week, date, outside temperature, the time in other timezones, and custom notifications such as number of steps, but this isn’t currently possible. For a second-generation device, I’d hope many of these things would have been figured out by now. This is probably why Apple are waiting to release a watch – in order to answer the what, why, and how questions that Sony and Samsung have failed to cover.
Are smartwatches the future of gadget technology? Possibly. There’s genuine utility in the smartphone/smartwatch/bluetooth headset combination, even with the rough edges. The watch is killer screen real estate in a way the phone can never be, so the challenge is to figure out how to make best use of it.
Many of you will have heard about Ubuntu’s convergence goals on the client side — running a single, consistent code-base and experience that adapts to phones, desktops, tablets, and TVs…but are you aware of our convergence on the cloud?
Ubuntu and our cloud orchestration service, Juju, provides a platform and the tools to be able to deploy your service (from a simple blog to a full enterprise and production deployment) across a range of clouds…be it a public cloud, private cloud, or bare metal. Prototyping, staging, deploying to production, and scaling up are simple.
At the heart of Juju are the charms…the range of components that form a service (e.g. WordPress, Hadoop, Mongo, Drupal etc). Inside each charm is an encapsulation of best practice from domain experts for each component that automates how charms relate together in your service. Best practice connected to best practice in a service that easily scales is the backbone of Juju.
In much the same way we are building a consistent experience and set of features that run across phones, desktop, tablets, and TVs, we are also building a consistent experience and set of tools for delivering services across different clouds, bare metal, or local containers. Ubuntu for clouds is not merely bound to a single cloud…the point is that what matters is your service and you can easily migrate your service between public and private clouds and bare metal. Again, a converged experience across multiple services.
On the client side this convergence means a more consistent user experience with no fragmentation, consistent platform for deploying content across devices that is cheaper to deploy, and makes multiple product lines available to vendors and builds institutional knowledge across different product lines.
On the cloud side this convergence means that you are in control of your service. When you or your staff know how to use Ubuntu and the cloud orchestration tools we provide (such as Juju), you are in control of your service and you can prototype and deploy it where you want easily, whether a private or public cloud or bare metal, scale out when required, and build consistent institutional knowledge.
What makes Ubuntu on the cloud even more interesting is that Juju GUI also crosses the chasm between service topology on the office whiteboard and a running service – you can literally draw your service and everything spins up effortlessly.
Ubuntu is all about convergence and bringing simplicity and power to our devices, to our clouds, and all powered by Open Source.
I’ve just got back from an epic weekend at OggCamp. For my money this was the best event yet. There was a great atmosphere from the start. The exhibitors and hardware hackers kept everyone entertained and the Leaf tea shop provided the fuel necessary to get through a day. We even had giant beanbags and free arcade machines that took a pounding. There were some great scheduled speakers, the live podcast was good fun, and the famous rafflecast rounded off the event in style.
But the crowd really make the event what it is. Because it’s an unconference, things can just happen spontaneously. One talk prompted questions on the version control system “git”. So three OggCampers got together and gave a talk on it an hour later. Other things that “just happened” included a good-natured showdown between Firefox OS and Ubuntu Touch, and a demonstration of tri- and quad-copters.
There were great parties too, at the Leaf on Bold Street and the Racquet Club – easily the poshest OggCamp party venue yet!
I was busy tweeting as @oggcamp throughout the weekend, accompanying this post are some of the photos from the weekend.
Thanks to the sponsors and crew who make it possible, and of course everyone who attended.
— Félim Whiteley (@felimwhiteley) October 21, 2013
— Charlie Don't Surf (@sonniesedge) October 20, 2013
Feel fired up to give a shit about the world I live in, in a way I haven't for a while. Thanks #OGGCamp.
— Mark Holmes (@eyesparky) October 21, 2013Pin It