Getting them installed in Ubuntu is a breeze, thanks to a script I found.
To install the Vista ClearType fonts in Ubuntu, you need to install cabextract first. Cabextract is a utility found in the universe repository, so before you run the following command, make sure you have universe enabled in your repository list. Once this is done, install cabextract using:
$sudo apt-get install cabextract

Then, once that is done, use this script to install the Vista fonts. Create a file called “vista-fonts-installer.sh” in your home (~) directory.
Then open up a text editor and copy and paste the script into that file.
Do a chmod a+x ~/vista-fonts-installer.sh to make the file/script executable.
Then run the script using:
$ ~/vista-fonts-installer.sh

The script downloads the Powerpoint Viewer installer from microsoft.com, and then extracts the Vista cleartype fonts using cabextract. These fonts are then installed in the ~/.fonts directory.

Please remember that the ClearType Vista fonts are not free as in they are not GPL-ed or made available under a re-distributable license. Since you are downloading the fonts from the MS website, and since you might already have a Windows XP/Vista license, this is not a crime, but consider yourself warned against the perils of supporting closed systems :)

Update::

1. Looks like the use of these fonts are restricted to only Microsoft Windows/Vista operating systems according to the terms of the license. I am sorry, but you’ll be installing them at your own risk.
2. Also, please make sure you use the bash shell, or change the first line of the code to #!/bin/bash
3. In retrospect, this was a bad post – I think we’re better off not using stuff folks don’t want us to use – let’s use the better, freer, easier to install fonts.

Jorge, I for one, would love to see your mug again on Planet Ubuntu. I would love to see whiprush.org up and about again.

Jorge’s disappearance from the interwebs was followed by pleas for his return, about 9 months ago (you can find his last post here if you really want to). I used to love reading what Jorge had to say. It’s good to have him back in the Ubuntu world, now if only we could have his blog back too :) Welcome back, Jorge!

So when I had to find a replacement, and was short on time and money, I settled for another Acer. An Acer Aspire 5003 LMi. Piece of junk. The plastic looks cheap. The “Aluminum” next to the keyboard is poorly spray painted plastic. The area next to the touchpad, and the left-click button have lost all their paint due to repeated use, and then look white. All within a year. For the last few days, occasionally, I would open up the laptop, and the display wouldn’t work properly. Loud cracks can be heard at the hinges when I open it up. I’d usually fix the display problem by opening the lid to an angle where the display worked. Today it failed completely. No matter what I did, I couldn’t get the display to display anything coherent. The quality of the parts, and the “casing”, is terrible. I admit, this was a cheap laptop, but it had what I needed at a minimum. I am not someone who buys the cheapest thing around. I buy computers with exactly the minimum I need. This one has a Broadcom wireless card, but I thought I could live with that for a bit. I don’t need a separate video card – I never play games. I do need a large screen, and a DVD-burner – well, you get the point. I would have gladly paid $250 more to Acer for the same laptop with better quality.

Personally, I have vouched for Acer laptops, and have directly influenced my friends into buying at least 3-4 Acers. Now I feel like an idiot. I have to try something new. I don’t like how ThinkPads are designed with the recessed screen and clunky looks and all. The Sony Vaios I have known through friends and others have all been terrible – each of them making the trip back to Sony at least once. That leave the glitzy HPs and the Dells. I’d rather have a MacBook or the Pro, which looks infinitely cooler. Wish I had the money for a new MacBookPro. It has way more features and power than I need, though. Anyways, I feel much better having written this – may those that I recommended Acers to find it in them to forgive me!

Trivial, I know, and not too original either, since I got it from LiveJournal, but I couldn’t resist posting this :)

However, the stat freak in me got another tool, and the results are surprising!

I did not have any clue that the number of 45-65 year olds that visit my site are above the average numbers for the internet by around 25-45%. Also, most of my visitors are as poor as I am, with an income of less than $30K a year. That is surprising when you realize that college graduates outnumber any other kind of visitor, based on education. Finally, the male-female disparity is not too high – I get 25% less female visitors, and 25% more male visitors than the average site. Here’s my quantcast report.

Now, like me, you must be thinking, what about ubuntu.com?
Maybe Canonical should sign up for the quantcast setup like WordPress.com and then we could start fixing the problem where, right now, my blog seems to get more visitors than ubuntu.com. Clearly, quantcast is orders-of-magnitude off with the numbers. Let’s hope the percentages are right when it comes to the demographics. If they are, then then, again, Ubuntu seems to attract a middle-aged, may I say “mature” crowd. Ubuntu.com attracts more Asian, Hispanics and “Others” than the average website out there. Also, “linux drivers” seems to be leading the charge of visitors to Ubuntu.com. It would be good to put something related to drivers – perhaps an article with links peppered throughout to the various compatibility resources and hardware profiling tools somewhere on the front page of help.ubuntu.com which seems to be quite a popular destination. Of course, if I had a say in how Ubuntu’s websites worked, I would first ensure that the help pages show up where they belong on Google searches. Somehow, I can’t seem to end up at the Ubuntu help wiki after a web search. I suspect the wiki software’s intricacies, and the “https://” (now why does a help wiki have to be served over https?), are partly responsible for that issue. You get the idea that shipit must be doing something right, since it seems to be quite a popular destination. Also, OpenSuse, FreeSpire and Damn Small Linux seem to the other Linux distributions that are popular among those that visit the Ubuntu website. Scanning the quantcast results might help lots of folks involved with planning, developing and marketing Ubuntu – whether it is deciding what/who to focus on, or finding out how meta-plans are working out.

As is often the case, I found something better than SecureCRT – a panel applet for GNOME that gives me a drop-down list of SSH connections. SSHMenu is cool, way too cool.


Above, you can see my list of ssh accounts in all their glory. A connection is just a click away.

When you set up the connections, you can specify the geometry – ie, where on your desktop you want the gnome-terminal window to pop up, as well as a “profile” for the gnome-terminal instance – very handy if you want to have different color schemes for different ssh accounts to be able to distinguish between them better.

What’s even better is, in the “Hostname (etc)” field, you can prepend ssh options to the hostname. The figure below shows my port forwarding setup for IRC at school, since I can’t chat using port 6667 at school.

There’s a Debian/Ubuntu repository for SSHMenu, and of course, nothing stops you from downloading the .deb packages and installing them if you don’t wish to add another repository to you list of repositories. I wonder how long before SSHMenu finds itself into the Ubuntu repositories :)

Once you get SSHMenu installed, you can add it to your panel by right-clicking on your GNOME panel, and selecting “Add to Panel”. SSHMenu should be listed as “SSH Menu Applet” under the “Utilities” section. Then all you have to do is use the tool to add accounts that pops-up when you install the applet, or add the accounts later by clicking on the “SSH” in your panel. However, this still doesn’t take us to “one-click” login, since you will be prompted for your password by the server you are trying to connect to.

To make the connections truly one-click (or two-click), you might want to setup password-less logins using ssh-keygen and ssh-copy-id. A quick overview of that process follows:
On your local computer, type:
$ssh-keygen -t rsa
When prompted for a password, you may want to enter none. If you enter a password there, you will have to enter it everytime you try to use the “passwordless” login, which kind of defeats the purpose.

Enter a password here. Then when you try to connect to the accounts using SSHMenu, you will asked for the password only once, the very first time. (Thanks to Grant, SSHMenu’s author for the explanation in the comments).

Once your RSA key-pair is generated, you need to add the public key to your server’s ~/.ssh/authorized_keys file. You can do this very easily by typing (on your local computer):
$ssh-copy-id ~/.ssh/id_rsa.pub username@example.com
This will copy your public key for the just-generated RSA keypair to the example.com ssh account, where your username is “username”.
Of course, for this passwordless login to work, the server needs to accept this method of authentication. There’s an old article at the Debian Administration blog that describes the process in a little more detail, and countless others have written about this, so you won’t have trouble finding info.

Should the save icon be replaced by something else (a picture of a cd/usb drive)? Or should floppy discs be “icon”ized forever?
Somehow, all these days, the above thought never occurred to me. That icon with a floppy drive in it meant “Save” and to be honest, I have failed to think “floppy” when I have seen the icon before.

Do I? I can honestly say I don’t. I write for the competent computer user who has switched to Ubuntu. Anything that 90-95% of the people who formerly used Windows or Macs, and are competent enough to help others won’t be published here. Guaranteed. I can say that since I have a target audience of one – myself before I knew what I wrote here. I write so that, some day in the future, when I search for a solution to a problem, I get the pleasure that only a goojà vu (google + déjà vu :)) can provide – finding something you wrote as the result of a Google search is priceless.

There are some authors of blogs that write tutorials and guides that cover all and sundry. The installation of some software that should be pretty straightforward to install, and so on, ad nauseum. I understand that the pleasure of earning a check through Google’s adsense can be great, and I wish these authors good luck. There are also the book equivalent of these sites that really do treat Ubuntu users as dunces.

But Jem, what’s the problem with any of that? The world needed a “Linux for Dummies” – something that is inanely simple to install, setup, use and maintain – and that is exactly what Ubuntu is. Power users don’t need to fear it since it does not take away anything in doing that. So there you are – a Linux-based OS that is simple enough for the stupid and as (if not more) flexible and powerful than the best OSes out there. It’s not like there aren’t books out there that don’t address the intricacies of subjects that are technically complex. The wiki and the Official Ubuntu Book, not to mention all the documentation and books out there for Debian all address the power users’ documentation needs.

I was happy to read that article, especially the parallels drawn with how Mac users were once perceived the way the author perceives Ubuntu users now. I was happy because it is a sign that we are moving in the right direction – towards a “Linux for Human Beings” (regardless of IQ).

Well, by some strange coincidence, which cannot be explained rationally, I ran into her again on the tubes. I followed the user profile link at this comment on Ask MetaFilter to end up at her profile page.

Of the billions of unknown users of the internet, we are two.

What are the chances?, I ask you!! The mind blows. :)

In other news, there is no news – I’m on the slow track to the Ph.D.

The doctor said I had tenosynovitis – which is a member of the much talked-about Repetitive Strain Injuries. He advised me against using the laptop on my lap – this keep my hands all hunched up together. He also advised a couple of days of rest. So needless to say, I haven’t typed much over the weekend, though I wanted to write a short guide on implementing a Getting Things Done workflow in Linux. I had set things up for GTD the past week, and the search for tools that work on Linux was frustrating, to say the least. I finally had to narrow it down to an online tool that seems very capable of the task. I have been itching to write the article and yet have resisted.

Monday brought me back to work, and I thought I should look at options to reduce the risk of recurrence of the pain. For two reasons – the pain was real bad, and the doctor said that repeated occurrences of RSI would lead to the much-dreaded Carpal Tunnel Syndrome and perhaps permanent numbness of the digits in my hands.

GNOME is very advanced when it comes to providing methods to save your hands.

There is the Typing Break in GNOME’s keyboard preferences dialog (System -> Preferences -> Keyboard). Here’s a snapshot:

It is easy enough to ask you computer to lock up every once in an hour or so for 5 minutes to enforce a break.

But for those of us who are not satisfied with a fly swatter to swat flies, there is workrave, with the little sheep for a mascot.

You can install workrave using:
$sudo apt-get install workrave

Once installed, you can add it to your panel as an applet by right-clicking on a panel and adding the applet:
.

Once on the panel, you get to right click on the panel applet and set preferences:

There’s a whole lot to choose from – you can choose to have micro-breaks of less than minute every 10 minutes, say. You can also enforce a longer break every hour or so. A break of 5 minutes every hour seems normal. You can also choose whether to be able to postpone the break when you get the warning of an impending break or not. A break can be either just a disabled keyboard, or a locked screen too, just so you don’t use your mouse to sneak a peek at you mail, or visitor stats :)

Workrave also has a neat feature where you can exercise your fingers, wrist, neck and arms during the break – there is an on-screen display of how to do the exercise and a virtual character does it with you. Marcel has written about workrave in detail and even has some more screenshots – including one of the dudette who does the exercises with you.

In addition to the forced typing breaks, I am thinking this would be a good time to switch to the Dvorak keyboard layout. The initial learning phase where typing gets really slow is what’s holding me back. Maybe that is one thing to filed under “someday/maybe” in my GTD system. :)

as you may have noticed, updates to this blog are few and far between. Sadly, I’ve found it harder and harder to find Xubuntu-related material to blog about. I imagine it’s because I’ve shifted more towards GNOME and Openbox. That being said, I felt that was no reason to go months without blogging. To make up for it, I’ve decided to start a more general-purpose Linux blog:

http://toodumbforgentoo.wordpress.com/

Unlike this blog, this one won’t be tied to any certain niche. It’ll basically run on the basis of posting whatever I like whenever I like. That being said, I won’t be abandoning this blog altogether. My blog partner Vincent will still be around to make posts, and I’ll probably pop in and blog from time to time.

It’s been a great 2 years with this blog, but now I feel it’s time to move on to something more. :)

That meeting led to several decisions, the most important one being that Cody Somerville was appointed as Xubuntu’s project leader and assigned to create a strategy for Xubuntu, so that everybody knows where Xubuntu stands and what its goals are.

Well, Cody set to the task and, after gathering feedback at the Ubuntu Developer Summit, came up with the first draft of what is to be the Xubuntu Strategy Document.

This being a first draft, everybody is invited to send feedback to Cody’s email address cody-somerville@ubuntu.com.

My first impression was that Cody did a great job on this one: Xubuntu has a bright future ahead under his lead :)

This how-to is extremely easy and short, but it helps me work with one of my favourite programs. In short: uninstall jackd.

1) Go to Xfce Menu > Accessories > Terminal, and enter in the following:

sudo apt-get remove jackd

Reopen up Audacity. Hopefully, it should start working again as it should. If not, you may have to quit the jackd program. Go back to the terminal and enter the following:

killall jackd

Now Audacity should be working just as it did before. Good luck!

(Credit goes to http://ubuntuforums.org/showpost.php?p=4812244&postcount=5.)

As some of you already know, I’m in the process of applying to Google’s
Summer of Code as a mentoring organisation. Xfce applied in 2006, but
wasn’t accepted. I don’t really know why, but hopefully this year we
can do a bit better. To that end, I’ve created a few pages on our wiki,
and people have been working on them for the past couple weeks:

http://wiki.xfce.org/gsoc-2008-ideas
http://wiki.xfce.org/gsoc-2008-mentors
http://wiki.xfce.org/gsoc-2008-students

Now, we won’t know if we’ve been accepted into the program until March
17th. However, I’d like to generate some interest for our participation
in the program; in particular, I’d like to get some names on that
‘students’ wiki page.

So, if you don’t mind, if you have a blog, or some other means of
publishing to a group of people (via means other than spam, of course),
could you please do a little advertising for us? Just point out that
we’re applying to the program, we’re looking for student participants,
and give a link to our wiki page (the main ‘ideas’ page).

Thanks!

He also posted the following on his blog:

While we haven’t been accepted into the program yet, we (Xfce) are applying to participate in the 2008 Google Summer of Code as a mentoring organisation. Please see our wiki page for more information, and add your name to the students list if you’d like to work on one of the projects. Feel free to add to the project ideas list as well.

If you’d like to act as a mentor, you still have a few more days before I submit the application. Add your name to the mentors list and email me to let me know.

The message is simple: if you’re a student that likes Xfce and would like to earn some money improving it over the summer, be sure to add your name to the list so Google can see there are students willing to participate, hopefully being a reason for approving Xfce.

If you own a personal website, a blog, or happen to know a student passionate about Xfce: spread the word! This is an excellent opportunity to improve upon our favourite desktop environment, so make sure Xfce can grab it!

An idea on brainstorm can easily be linked to a Launchpad blueprint as well as to a bug or a forum discussion thread. In this way we expect to bridge the locations where ideas are often submitted now, as forum posts or bug reports, with the blueprint format they should be expressed in to be implemented.

Here are the current ideas for Xubuntu: http://brainstorm.ubuntu.com/search?keywords=Xubuntu&ordering=mostvotes

Do you have an idea that you’ve been itching to share with the developers, but didn’t know how? Now’s your chance to post it at the Brainstorm!

1) If you haven’t already, install audio-convert. To do so, open up a terminal (Xfce Menu > Accessories > Terminal) and run the following:

sudo apt-get install nautilus-script-audio-convert

2) Next, open up the Thunar file manager and go to Edit > Configure custom actions…. Click the Add (plus) sign and put in the following:

a) Under the Basic tab:

Name: audio-convert
Command: /usr/share/nautilus-scripts/ConvertAudioFile %f

b) Under the Appearance Conditions tab:

Put a checkmark next to Audio files. Click Ok and exit out of the actions manager.

Now you can right click any audio file and go to audio-convert. audio-convert will do the work from there. Enjoy!

Hello Friends,

I am pleased to announce the immediate release of a brand new and sparkling, Fedora 8 Xfce Spin. Fedora Xfce Spin is a bootable Fedora Live CD image available for x86 and x86_64 architecture. It can be optionally installed to hard disk or converted into boot USB images and is ideal for Xfce fans and for users running Fedora on relatively low resource systems. As a additional bonus, this release rolls in updates for Fedora 8 released till yesterday (2008/02/12).

Xfce is a lightweight desktop environment available in Fedora. Designed for productivity, it loads and executes applications fast, while conserving system resources. More information at http://xfce.org

Nicu has posted some screenshots, and it looks as if this spin-off is really focusing on being light-weight and minimalistic. Some Xubuntu users might want to give this a try – being based on Fedora might prevent the speed decrease Xubuntu has by being based on Ubuntu.

In any case, seeing another big distribution providing an Xfce version is always good news, so it will be interesting to read some reviews. Have you tried it? If so, how did you like it?

Luckily, David Mooney comes to the rescue: in a post to the xubuntu-users mailinglist, he explains how to restore GRUB:

If for some odd reason you missed having the Windows operating system and you decided to install it on another partition, you will notice your GRUB is missing afterwords. This usually happens and is a huge headache for those trying to get their GRUB back. Here’s what you need to do to get it back:

Put your bootable Ubuntu/Xubuntu install disk in the CD drive and run it. Instead of installing anything, click on the menu to open the terminal application.

In terminal mode, type the following:

sudo grub
find /boot/grub/stage1
root (x,y)
setup (x)
quit
sudo shutdown "now" -r

The resulting “find” command will display something like (hd0,1). In this example, you would then type root (hd0,1) and then setup (hd0) in the above area. These numbers might be different; that’s why I included the “find” command so that folks who might have their Ubuntu partitions located either in front or behind their Windows installation or on a completely separate internal/external hard drive so that you will get the appropriate/correct setup numbers.

Ok, now you got your GRUB-on, but what about that darn GRUB menu? It’s not displaying what you want it to display? Well, let just see here…

Upon reboot, select “Recovery Mode”, usuaully the second option down on the GRUB menu. This will allow you to boot into the root. Once you’re in the terminal mode, type:

editor /boot/grub/menu.lst

Well, the rest is pretty much self explanatory. There should be enough comments in the menu.lst to direct you to what you can and cannot do to your GRUB menu.lst.

I usually put the Windows option at the top of the menu so that others (none-Linux users) who use my computer can find it easily if they have to do a reboot. Your Windows installation will have a different root than your Ubuntu/Xubuntu, but it’s usually automatically placed by GRUB once it’s set up again (like the above). I also recommend removing the timeout option as this is sometimes annoying. Have fun!

-David :D

P.S.- If you have a question, I’ll be happy to answer to the best of my ability.

Thanks David!

Read the guide here: http://ubuntuforums.org/showthread.php?t=653006

Containers are transforming the way people think about virtual machines (LXD) and apps (Docker). They give us much better performance and much better density for virtualisation in LXD, and with Docker, they enable new ways to move applications between dev, test and production. These two aspects of containers – the whole machine container and the process container, are perfectly complementary. You can launch Docker process containers inside LXD machine containers very easily. LXD feels like KVM only faster, Docker feels like the core unit of a PAAS.

The density numbers are pretty staggering. It’s *normal* to run hundreds of containers on a laptop.

And that is what creates one of the real frustrations of the container generation, which is a shortage of easily accessible IP addresses.

It seems weird that in this era of virtual everything that a number is hard to come by. The restrictions are real, however, because AWS restricts artificially the number of IP addresses you can bind to an interface on your VM. You have to buy a bigger VM to get more IP addresses, even if you don’t need extra compute. Also, IPv6 is nowehre to be seen on the clouds, so addresses are more scarce than they need to be in the first place.

So the key problem is that you want to find a way to get tens or hundreds of IP addresses allocated to each VM.

Most workarounds to date have involved “overlay networking”. You make a database in the cloud to track which IP address is attached to which container on each host VM. You then create tunnels between all the hosts so that everything can talk to everything. This works, kinda. It results in a mess of tunnels and much more complex routing than you would otherwise need. It also ruins performance for things like multicast and broadcast, because those are now exploding off through a myriad twisty tunnels, all looking the same.

The Fan is Canonical’s answer to the container networking challenge.

We recognised that container networking is unusual, and quite unlike true software-defined networking, in that the number of containers you want on each host is probably roughly the same. You want to run a couple hundred containers on each VM. You also don’t (in the docker case) want to live migrate them around, you just kill them and start them again elsewhere. Essentially, what you need is an address multiplier – anywhere you have one interface, it would be handy to have 250 of them instead.

So we came up with the “fan”. It’s called that because you can picture it as a fan behind each of your existing IP addresses, with another 250 IP addresses available. Anywhere you have an IP you can make a fan, and every fan gives you 250x the IP addresses. More than that, you can run multiple fans, so each IP address could stand in front of thousands of container IP addresses.

We use standard IPv4 addresses, just like overlays. What we do that’s new is allocate those addresses mathematically, with an algorithmic projection from your existing subnet / network range to the expanded range. That results in a very flat address structure – you get exactly the same number of overlay addresses for each IP address on your network, perfect for a dense container setup.

Because we’re mapping addresses algorithmically, we avoid any need for a database of overlay addresses per host. We can calculate instantly, with no database lookup, the host address for any given container address.

More importantly, we can route to these addresses much more simply, with a single route to the “fan” network on each host, instead of the maze of twisty network tunnels you might have seen with other overlays.

You can expand any network range with any other network range. The main idea, though, is that people will expand a class B range in their VPC with a class A range. Who has a class A range lying about? You do! It turns out that there are a couple of class A networks that are allocated and which publish no routes on the Internet.

We also plan to submit an IETF RFC for the fan, for address expansion. It turns out that “Class E” networking was reserved but never defined, and we’d like to think of that as a new “Expansion” class. There are several class A network addresses reserved for Class E, which won’t work on the Internet itself. While you can use the fan with unused class A addresses (and there are several good candidates for use!) it would be much nicer to do this as part of a standard.

The fan is available on Ubuntu on AWS and soon on other clouds, for your testing and container experiments! Feedback is most welcome while we refine the user experience.

Configuration on Ubuntu is super-simple. Here’s an example:

In /etc/network/fan:

# fan 241
241.0.0.0/8 172.16.3.0/16 dhcp

In /etc/network/interfaces:

iface eth0 static
address 172.16.3.4
netmask 255.255.0.0
up fanctl up 241.0.0.0/8 172.16.3.4/16
down fanctl down 241.0.0.0/8 172.16.3.4/16

This will map 250 addresses on 241.0.0.0/8 to your 172.16.0.0/16 hosts.

Docker, LXD and Juju integration is just as easy. For docker, edit /etc/default/docker.io, adding:

DOCKER_OPTS=”-d -b fan-10-3-4 –mtu=1480 –iptables=false”

You must then restart docker.io:

sudo service docker.io restart

At this point, a Docker instance started via, e.g.,

docker run -it ubuntu:latest

will be run within the specified fan overlay network.

Enjoy!

But first, thank you to all who have made such witty suggestions in webby forums. Alas, the “wacky wabbit” and “watery walrus”, while weird enough and wisely whimsical, won’t win the race. The “warty wombat”, while wistfully wonderful, will break all sorts of systems with its wepetition. And the “witchy whippet”, in all its wiry weeness, didn’t make the cut.

Instead, my waggish friends, the winsome W on which we wish will be… the “wily werewolf”.

Enjoy!

Ubuntu is right at the heart of the “internet thing” revolution, and so we are in a good position to raise the bar for security and consistency across the whole ecosystem. Ubuntu is already pervasive on devices – you’ve probably seen lots of “Ubuntu in the wild” stories, from self-driving cars to space programs and robots and the occasional airport display. I’m excited that we can help underpin the next wave of innovation while also thoughtful about the responsibility that entails. So today we’re launching snappy Ubuntu Core on a wide range of boards, chips and chipsets, because the snappy system and Ubuntu Core are perfect for distributed, connected devices that need security updates for the OS and applications but also need to be completely reliable and self-healing. Snappy is much better than package dependencies for robust, distributed devices.

Transactional updates. App store. A huge range of hardware. Branding for device manufacturers.

In this release of Ubuntu Core we’ve added a hardware abstraction layer where platform-specific kernels live. We’re working commercially with the major silicon providers to guarantee free updates to every device built on their chips and boards. We’ve added a web device manager (“webdm”) that handles first-boot and app store access through the web consistently on every device. And we’ve preserved perfect compatibility with the snappy images of Ubuntu Core available on every major cloud today. So you can start your kickstarter project with a VM on your favourite cloud and pick your processor when you’re ready to finalise the device.

If you are an inventor or a developer of apps that might run on devices, then Ubuntu Core is for you. We’re launching it with a wide range of partners on a huge range of devices. From the pervasive Beaglebone Black to the $35 Odroid-C1 (1Ghz processor, 1 GB RAM), all the way up to the biggest Xeon servers, snappy Ubuntu Core gives you a crisp, ultra-reliable base platform, with all the goodness of Ubuntu at your fingertips and total control over the way you deliver your app to your users and devices. With an app store (well, a “snapp” store) built in and access to the amazing work of thousands of communities collaborating on Github and other forums, with code for robotics and autopilots and a million other things instantly accessible, I can’t wait to see what people build.

I for one welcome the ability to install AI on my next camera-toting drone, and am glad to be able to do it in a way that will get patched automatically with fixes for future heartbleeds!

This is in a sense the biggest break with tradition in 10 years of Ubuntu, because snappy Ubuntu Core doesn’t use debs or apt-get. We call it “snappy” because that’s the new bullet-proof mechanism for app delivery and system updates; it’s completely different to the traditional package-based Ubuntu server and desktop. The snappy system keeps each part of Ubuntu in a separate, read-only file, and does the same for each application. That way, developers can deliver everything they need to be confident their app will work exactly as they intend, and we can take steps to keep the various apps isolated from one another, and ensure that updates are always perfect. Of course, that means that apt-get won’t work, but that’s OK since developers can reuse debs to make their snappy apps, and the core system is exactly the same as any other Ubuntu system – server or desktop.

Whenever we make a fix to packages in Ubuntu, we’ll publish the same fix to Ubuntu Core, and systems can get that fix transactionally. In fact, updates to Ubuntu Core are even smaller than package updates because we only need to send the precise difference between the old and new versions, not the whole package. Of course, Ubuntu Core is in addition to all the current members of the Ubuntu family – desktop, server, and cloud images that use apt-get and debs, and all the many *buntu remixes which bring their particular shine to our community. You still get all the Ubuntu you like, and there’s a new snappy Core image on all the clouds for the sort of deployment where precision, specialism and security are the top priority.

This is the biggest new thing in Ubuntu since we committed to deliver a mobile phone platform, and it’s very delicious that it’s borne of exactly the same amazing technology that we’ve been perfecting for these last three years. I love it when two completely different efforts find underlying commonalities, and it’s wonderful to me that the work we’ve done for the phone, where carriers and consumers are the audience, might turn out to be so useful in the cloud, which is all about back-end infrastructure.

Why is this so interesting?

Transactional updates have lots of useful properties: if they are done well, you can know EXACTLY what’s running on a particular system, and you can coordinate updates with very high precision across thousands of instances in the cloud. You can run systems as canaries, getting updates ahead of other identical systems to see if they cause unexpected problems. You can roll updates back, because each version is a complete, independent image. That’s very nice indeed.

There have been interesting developments in the transaction systems field over the past few years. ChromeOS is updated transactionally, when you turn it on, it makes sure it’s running the latest version of the OS. CoreOS brought aspects of Chrome OS and Gentoo to the cloud, Red Hat has a beta of Atomic as a transactional version of RHEL, and of course Docker is a way of delivering apps transactionally too (it combines app and system files very neatly). Ubuntu Core raises the bar for certainty, extensibility and security in the transactional systems game. What I love about Ubuntu Core is the way it embraces transactional updates not just for the base system but for applications on top of the system as well. The system is just one layer that can be updated transactionally, and so are each of the apps on the system. You get an extensible platform that retains the lovely properties of transactionality but lets you choose exactly the capabilities you want for yourself, rather than having someone else force you to use a particular tool.

For example, in CoreOS, things like Fleet are built-in, you can’t opt out. In Ubuntu Core, we aim for a much smaller Core, and then enable you to install Docker or any other container system as a framework, with snappy. We’re working with all the different container vendors, and app systems, and container coordination systems, to help them make snappy versions of their tools. That way, you get the transactional semantics you want with the freedom to use whichever tools suit you. And the whole thing is smaller and more secure because we baked fewer assumptions into the core.

The snappy system is also designed to provide security guarantees across diverse environments. Because there is a single repository of frameworks and packages, and each of them has a digital fingerprint that cannot be faked, two people on opposite ends of the world can compare their systems and know that they are running exactly the same versions of the system and apps. Atomic might allow you to roll back, but it’s virtually impossible to customise the system for your own preferences rather than Red Hat’s, and still know you are running the same secure bits as anybody else.

Developers of snappy apps get much more freedom to bundle the exact versions of libraries that they want to use with their apps. It’s much easier to make a snappy package than a traditional Ubuntu package – just bundle up everything you want in one place, and ship it. We use strong application isolation to keep data confidential between apps. If you install a bad app, it only has access to the data you create with that app, not to data from other applications. This is a key piece of security that comes from our efforts to bring Ubuntu to the mobile market, where malware is a real problem today. And as a result, we can enable developers to go much faster – they can publish their app on whatever schedule suits them, regardless of the Ubuntu release cadence. Want the very latest app? Snappy makes that easiest.

This is also why I think snappy will result in much simpler systems management. Instead of having literally thousands of packages on your Ubuntu server, with tons of dependencies, a snappy system just has a single package for each actual app or framework that’s installed. I bet the average system on the cloud ends up with about three packages installed, total! Try this sort of output:

$ snappy info
release: ubuntu-core/devel
frameworks: docker, panamax
apps: owncloud

That’s much easier to manage and reason about at scale. We recently saw how complicated things can get in the old packaging system, when Owncloud upstream wanted to remove the original packages of Owncloud from an old Ubuntu release. With snappy Ubuntu, Owncloud can publish exactly what they want you to use as a snappy package, and can update that for you directly, in a safe transactional manner with full support for rolling back. I think upstream developers are going to love being in complete control of their app on snappy Ubuntu Core.

$ sudo snappy install hello-world

Welcome to a snappy new world!

Things here are really nice and simple:

$ snappy info
$ snappy build .
$ snappy install foo
$ snappy update foo
$ snappy rollback foo
$ snappy remove foo
$ snappy update-versions
$ snappy versions

Just for fun, download the image and have a play. I’m delighted that Ubuntu Core is today’s Qemu Advent Calendar image too! Or launch it on Azure, coming soon to all the clouds.

It’s important for Ubuntu to continue to find new ways to bring free software to a wider audience. The way people think about software is changing, and I think Ubuntu Core becomes a very useful tool for people doing stuff at huge scale in the cloud. If you want crisp, purposeful, tightly locked down systems that are secure by design, Ubuntu Core and snappy packages are the right tool for the job. Running docker farms? Running transcode farms? I think you’ll like this very much!

We have the world’s biggest free software community because we find ways to recognise all kinds of contributions and to support people helping one another to bring their ideas to fruition. One of the goals of snappy was to reduce the overhead and bureaucracy of packaging software to make it incredibly easy for anybody to publish code they care about to other Ubuntu users. We have built a great community of developers using this toolchain for the phone, I think it’s going to be even better on the cloud where Ubuntu is already so popular. There is a lot to do in making the most of existing debs in the snappy environment, and I’m excited that there is a load of amazing software on github that can now flow more easily to Ubuntu users on any cloud.

Welcome to the family, Ubuntu Core!

The key ideas in that draft are:

Only call services “core” if the user can detect them.

How the cloud is deployed or operated makes no difference to a user. We want app developers to

Define both “core” and “common” services, but require only “core” services for a cloud that calls itself OpenStack compatible.

Separation of core and common lets us recognise common practice today, while also acknowledging that many ideas we’ve had in the past year or three are just 1.0 iterations, we don’t know which of them will stick any more than one could predict which services on any major public cloud will thrive and which will vanish over time. Signalling that something is “core” means it is something we commit to keeping around a long time. Signalling something is “common” means it’s widespread practice for it to be available in an OpenStack environment, but not a requirement.

Require that “common” services can be self-deployed.

Just as you can install a library or a binary in your home directory, you can run services for yourself in a cloud. Services do not have to be provided by the cloud infrastructure provider, they can usually be run by a user themselves, under their own account, as a series of VMs providing network services. Making it a requirement that users can self-provide a service before designating it common means that users can build on it; if a particular cloud doesn’t offer it, their users can self-provide it. All this means is that the common service itself builds on core services, though it might also depend on other common services which could be self-deployed in advance of it.

Require that “common” services have a public integration test suite that can be run by any user of a cloud to evaluate conformance of a particular implementation of the service.

For example, a user might point the test suite at HP Cloud to verify that the common service there actually conforms to the service test standard. Alternatively, the user who self-provides a common service in a cloud which does not provide it can verify that their self-deployed common service is functioning correctly. This also serves to expand the test suite for the core: we can self-deploy common services and run their test suites to exercise the core more thoroughly than Tempest could.

Keep the whole set as small as possible.

We know that small is beautiful; small is cleaner, leaner, more comprehensible, more secure, easier to test, likely to be more efficiently implemented, easier to attract developer participation. In general, if something can be cut from the core specification it should. “Common” should reflect common practice and can be arbitrarily large, and also arbitrarily changed.

In the light of those ideas, I would designate the following items from Subhu’s list as core OpenStack services:

• Keystone (without identity, nothing)
• Nova (the basis for any other service is the ability to run processes somewhere)
  • Glance (hard to use Nova without it)
• Neutron (where those services run)
  • Designate (DNS is a core aspect of the network)
• Cinder (where they persist data)

I would consider these to be common OpenStack services:

• SWIFT (widely deployed, can be self-provisioned with Cinder block backends)
• Ceph RADOS-GW object storage (widely deployed as an implementation choice, common because it could be self-provided on Cinder block)
• Horizon (widely deployed, but we want to encourage innovation in the dashboard)

And these I would consider neither core nor common, though some of them are clearly on track there:

• Barbican (not widely implemented)
• Ceilometer (internal implementation detail, can’t be common because it requires access to other parts)
• Juju (not widely implemented)
• Kite (not widely implemented)
• HEAT (on track to become common if it can be self-deployed, besides, I eat controversy for breakfast)
• MAAS (who cares how the cloud was built?)
• Manila (not widely implemented, possibly core once solid, otherwise common once, err, common)
• Sahara (not widely implemented, weird that we would want to hardcode one way of doing this in the project)
• Triple-O (user doesn’t care how the cloud was deployed)
• Trove (not widely implemented, might make it to “common” if widely deployed)
• Tuskar (see Ironic)
• Zaqar (not widely implemented)

In the current DefCore discussions, the “layer” idea has been introduced. My concern is simple: how many layers make sense? End users don’t want to have to figure out what lots of layers mean. If we had “OpenStack HPC” and “OpenStack Scientific” and “OpenStack Genomics” layers, that would just be confusing. Let’s keep it simple – use “common” as a layer, but be explicit that it will change to reflect common practice (of course, anything in common is self-reinforcing in that new players will defer to norms and implement common services, thereby entrenching common unless new ideas make services obsolete).

And so it’s time to open the vatic floodgates and invite your thoughts and contributions to our soon-to-be-opened iteration next. Our ventrous quest to put GNU as you love it on phones is bearing fruit, with final touches to the first image in a new era of convergence in computing. From tiny devices to personal computers of all shapes and sizes to the ventose vistas of cloud computing, our goal is to make a platform that is useful, versal and widely used.

Who would have thought – a phone! Each year in Ubuntu brings something new. It is a privilege to celebrate our tenth anniversary milestone with such vernal efforts. New ecosystems are born all the time, and it’s vital that we refresh and renew our thinking and our product in vibrant ways. That we have the chance to do so is testament to the role Linux at large is playing in modern computing, and the breadth of vision in our virtual team.

To our fledgling phone developer community, for all your votive contributions and vocal participation, thank you! Let’s not be vaunty: we have a lot to do yet, but my oh my what we’ve made together feels fantastic. You are the vigorous vanguard, the verecund visionaries and our venerable mates in this adventure. Thank you again.

This verbose tract is a venial vanity, a chance to vector verbal vibes, a map of verdant hills to be climbed in months ahead. Amongst those peaks I expect we’ll find new ways to bring secure, free and fabulous opportunities for both developers and users. This is a time when every electronic thing can be an Internet thing, and that’s a chance for us to bring our platform, with its security and its long term support, to a vast and important field. In a world where almost any device can be smart, and also subverted, our shared efforts to make trusted and trustworthy systems might find fertile ground. So our goal this next cycle is to show the way past a simple Internet of things, to a world of Internet things-you-can-trust.

In my favourite places, the smartest thing around is a particular kind of monkey. Vexatious at times, volant and vogie at others, a vervet gets in anywhere and delights in teasing cats and dogs alike. As the upstart monkey in this business I can think of no better mascot. And so let’s launch our vicenary cycle, our verist varlet, the Vivid Vervet!

Exchange controls may appear to be targeted at a very small number of South Africans but their consequences are significant for all of us: especially those who are building relationships across Southern Africa such as migrant workers and small businesses seeking to participate in the growth of our continent. It is more expensive to work across South African borders than almost anywhere else on Earth, purely because the framework of exchange controls creates a cartel of banks authorized to act as the agents of the Reserve Bank in currency matters.

We all pay a very high price for that cartel, and derive no real benefit in currency stability or security for that cost.

Banks profit from exchange controls, but our economy is stifled, and the most vulnerable suffer most of all. Everything you buy is more expensive, South Africans are less globally competitive, and cross-border labourers, already vulnerable, pay the highest price of all – a shame we should work to address. The IMF found that “A study in South Africa found that the comparative cost of an international transfer of 250 rand was the lowest when it went through a friend or a taxi driver and the highest when it went through a bank.” The World Bank found that “remittance fees punish poor Africans“. South Africa scores worst of all, and according to the Payments Association of South Africa and the Reserve Bank, this is “..mostly related to the regulations that South African financial institutions needed to comply with, such as the Financial Intelligence Centre Act (Fica) and exchange-control regulations.”

Today’s ruling by the Supreme Court of Appeal found administrative and procedural fault with the Reserve Bank’s actions in regards to me, and returned the fees levied, for which I am grateful. This case, however, was not filed solely in pursuit of relief for me personally. We are now considering the continuation of the case in the Constitutional Court, to challenge exchange control on constitutional grounds and ensure that the benefits of today’s ruling accrue to all South Africans.

This is a time in our history when it will be increasingly important to defend constitutional rights. Historically, these are largely questions related to the balance of power between the state and the individual. For all the eloquence of our Constitution, it will be of little benefit to us all if it cannot be made binding on our government. It is expensive to litigate at the constitutional level, which means that such cases are imbalanced – the State has the resources to make its argument, but the individual often does not.

For that reason, I will commit the funds returned to me to today by the SCA to a trust run by veteran and retired constitutional scholars, judges and lawyers, that will selectively fund cases on behalf of those unable to do so themselves, where the counterparty is the state. The mandate of this trust will extend beyond South African borders, to address constitutional rights for African citizens at large, on the grounds that our future in South Africa is in every way part of that great continent.

This case is largely thanks to the team of constitutional lawyers who framed their arguments long before meeting me; I have been happy to play the role of model plaintiff and to underwrite the work, but it is their determination to correct this glaring flaw in South African government policy which inspired me to support them.

For that reason I will ask them to lead the establishment of this new trust and would like to thank them for their commitment to the principles on which our democracy is founded.

This case also has a very strong personal element for me, because it is exchange controls which make it impossible for me to pursue the work I am most interested in from within South Africa and which thus forced me to emigrate years ago. I pursue this case in the hope that the next generation of South Africans who want to build small but global operations will be able to do so without leaving the country. In our modern, connected world, and our modern connected country, that is the right outcome for all South Africans.

Mark

Today, the pendulum is swinging back to government control of speech, most notably on the net. First, it became clear that total surveillance is the norm even amongst Western democratic governments (the “total information act” reborn).  Now we hear the UK government wants to be able to ban organisations without any evidence of involvement in illegal activities because they might “poison young minds”. Well, nonsense. Frustrated young minds will go off to Syria precisely BECAUSE they feel their avenues for discourse and debate are being shut down by an unfair and unrepresentative government – you couldn’t ask for a more compelling motivation for the next generation of home-grown anti-Western jihadists than to clamp down on discussion without recourse to due process. And yet, at the same time this is happening in the UK, protesters in Hong Kong are moving to peer-to-peer mechanisms to organise their protests precisely because of central control of the flow of information.

One of the reasons I picked the certificate and security business back in the 1990’s was because I wanted to be part of letting people communicate privately and securely, for business and pleasure. I’m saddened now at the extent to which the promise of that security has been undermined by state pressure and bad actors in the business of trust.

So I think it’s time that those of us who invest time, effort and money in the underpinnings of technology focus attention on the defensibility of the core freedoms at the heart of the internet.

There are many efforts to fix this under way. The IETF is slowly become more conscious of the ways in which ideals can be undermined and the central role it can play in setting standards which are robust in the face of such inevitable pressure. But we can do more, and I’m writing now to invite applications for Fellowships at the Shuttleworth Foundation by leaders that are focused on these problems. TSF already has Fellows working on privacy in personal communications; we are interested in generalising that to the foundations of all communications. We already have a range of applications in this regard, I would welcome more. And I’d like to call attention to the Edgenet effort (distributing network capabilities, based on zero-mq) which is holding a sprint in Brussels October 30-31.

20 years ago, “Clipper” (a proposed mandatory US government back door, supported by the NSA) died on the vine thanks to a concerted effort by industry to show the risks inherent to such schemes. For two decades we’ve had the tide on the side of those who believe it’s more important for individuals and companies to be able to protect information than it is for security agencies to be able to monitor it. I’m glad that today, you are more likely to get into trouble if you don’t encrypt sensitive information in transit on your laptop than if you do. I believe that’s the right side to fight for and the right side for all of our security in the long term, too. But with mandatory back doors back on the table we can take nothing for granted – regulatory regimes can and do change, as often for the worse as for the better. If you care about these issues, please take action of one form or another.

Law enforcement is important. There are huge dividends to a society in which people to make long term plans, which depends on their confidence in security and safety as much as their confidence in economic fairness and opportunity. But the agencies in whom we place this authority are human and tend over time, like any institution, to be more forceful in defending their own existence and privileges than they are in providing for the needs of others. There has never been an institution in history which has managed to avoid this cycle. For that reason, it’s important to ensure that law enforcement is done by due process; there are no short cuts which will not be abused sooner rather than later. Checks and balances are more important than knee-jerk responses to the last attack. Every society, even today’s modern Western society, is prone to abusive governance. We should fear our own darknesses more than we fear others.

A fair society is one where laws are clear and crimes are punished in a way that is deemed fair. It is not one where thinking about crime is criminal, or one where talking about things that are unpalatable is criminal, or one where everybody is notionally protected from the arbitrary and the capricious. Over the past 20 years life has become safer, not more risky, for people living in an Internet-connected West. That’s no thanks to the listeners; it’s thanks to living in a period when the youth (the source of most trouble in the world) feel they have access to opportunity and ideas on a world-wide basis. We are pretty much certain to have hard challenges ahead in that regard. So for all the scaremongering about Chinese cyber-espionage and Russian cyber-warfare and criminal activity in darknets, we are better off keeping the Internet as a free-flowing and confidential medium than we are entrusting an agency with the job of monitoring us for inappropriate and dangerous ideas. And that’s something we’ll have to work for.