My friend Noah mentioned the game VVVVVV. I was confused because I thought he was talking about the visual programming language vvvv. I went to Wikipedia to clear up my confusion but ended up on the article on VVVVV which is about the Latin phrase "vi veri universum vivus vici" meaning, "by the power of truth, I, while living, have conquered the universe".

There is no Wikipedia article on VVVVVVV. That would be ridiculous.

08 Mar 2014 12:50am GMT

how I was surprised by a large AWS charge and how to calculate the break-even point

Glacier Archival of S3 Objects

Amazon recently introduced a fantastic new feature where S3 objects can be automatically migrated over to Glacier storage based on the S3 bucket, the key prefix, and the number of days after object creation.

This makes it trivially easy to drop files in S3, have fast access to them for a while, then have them automatically saved to long-term storage where they can't be accessed as quickly, but where the storage charges are around a tenth of the price.

…or so I thought.

S3 Lifecycle Rule

My first use of this feature was on some buckets where I store about 350 GB of data that fits the Glacier use pattern perfectly: I want to save it practically forever, but expect to use it rarely.

It was straight forward to use the S3 Console to add a lifecycle rule to the S3 buckets so that all objects are archived to Glacier after 60 days:

(Long time readers of this blog may be surprised I didn't list the command lines to accomplish this task, but Amazon has not yet released useful S3 tools that include the required functionality.)

Since all of the objects in the buckets were more than 60 days old, I expected them to be transitioned to Glacier within a day, and true to Amazon's documentation, this occurred on schedule.

Surprise Charge

What I did not expect was an email alert from my AWS billing alarm monitor on this account letting me know that I had just passed $200 for the month, followed a few hours later by an alert for $300, followed by an alert for a $400 trigger.

This is one of my personal accounts, so a rate of several hundred dollars a day is not sustainable. Fortunately, a quick investigation showed that this increase was due to one time charges, so I wasn't about to run up a $10k monthly bill.

The line item on the AWS Activity report showed the source of the new charge:

$0.05 per 1,000 Glacier Requests x 5,306,220 Requests = $265.31

It had not occurred to me that there would be much of a charge for transitioning the objects from S3 to Glacier. I should have read the S3 Pricing page, where Amazon states:

Glacier Archive and Restore Requests: $0.05 per 1,000 requests

This is five times as expensive as the initial process of putting objects into S3, which is $0.01 per 1,000 PUT requests.

There is one "archive request" for each S3 object that is transitioned from S3 to Glacier, and I had over five million objects in these buckets, something I didn't worry about previously because my monthly S3 charges were based on the total GB, not the number of objects.5306220

Overhead per Glacier Object

josh.monet has pointed out in the comments that Amazon has documented some Glacier storage overhead:

For each S3 object migrated to Glacier, Amazon adds "an additional 32 KB of Glacier data plus an additional 8 KB of S3 standard storage data".

Storage for this overhead is charged at standard Glacier and S3 prices. This makes Glacier completely unsuitable for small objects.

Break-even Point

After stopping to think about it, I realized that I was still saving money on the long term by moving objects in these S3 buckets to Glacier storage. This one-time up front cost was going to be compensated for slowly by my monthly savings, because Glacier is cheap, even compared to the reasonably cheap S3 storage costs, at least for larger files.

Here are the results of my calculations:

• Monthly cost of storing in S3: 350 GB x $0.095/GB = $33.25

• Monthly cost of storing in Glacier: $8.97

  • 350 GB x $0.01/GB = $3.50
  • Glacier overhead: 5.3 million * 32 KB * $0.01/GB = $1.62
  • S3 overhead: 5.3 million * 8 KB * $0.95/GB = $3.85

• One time cost to transition 5.3 million objects from S3 to Glacier: $265

• Months until I start saving money by moving to Glacier: 11

• Savings per year after first 11 months: $291 (73%)

For this data's purpose, everything eventually works out to an advantage, so thanks, Amazon! I will, however, think twice before doing this with other types of buckets, just to make sure that the data is large enough and is going to be sitting around long enough in Glacier to be worth the transition costs.

As it turns out, the primary factor in how long it takes to break even is the average size of the S3 objects. If the average size of my data files were larger, then I would start saving money sooner.

Here's the formula… The number of months to break even and start saving money when transferring S3 objects to Glacier is:

break-even months = 631,613 / (average S3 object size in bytes - 13,011)

(units apologies to math geeks)

In my case, the average size of the S3 objects was 70,824 bytes (about 70 KB). Applying the above formula:

631,613 / (70,824 - 13,011) = 10.9

or about 11 months until the savings in Glacier over S3 covers the cost of moving my objects from S3 to Glacier.

Looking closely at the above formula, you can see that any object 13 KB or smaller is going to cost more to transition to Glacier rather than leaving it in S3. Files approaching that size are going to save too little money to justify the transfer costs.

The above formula assumes an S3 storage cost of $0.095 per GB per month in us-east-1. If you are storing more than a TB, then you're into the $0.08 tier or lower, so your break-even point will take longer and you'll want to do more calculations to find your savings.

[Update 2012-12-19: Included additional S3 and Glacier storage overhead per item. Thanks to josh.monet for pointing us to this information buried in the S3 FAQ.]

[Update 2013-03-07] Amazon S3 documentation now has a section on Glacier Pricing Considerations that has some good pointers.

Original article: http://alestic.com/2012/12/s3-glacier-costs

07 Mar 2014 11:29pm GMT

Headsets come in many sorts and shapes. And laptops come with different sorts of headset jacks - there is the classic variant of one 3.5 mm headphone jack and one 3.5 mm mic jack, and the newer (common on smartphones) 3.5 mm headset jack which can do both. USB and Bluetooth headsets are also quite common, but that's outside the scope for this article, which is about different types of 3.5 mm (1/8 inch) jacks and how we support them in Ubuntu 14.04.

You'd think this would be simple to support, and for the classic (and still common) version of having one headphone jack and one mic jack that's mostly true, but newer hardware come in several variants.

If we talk about the typical TRRS headset - for the headset itself there are two competing standards, CTIA and OMTP. CTIA is the more common variant, at least in the US and Europe, but it means that we have laptop jacks supporting only one of the variants, or both by autodetecting which sort has been plugged in.

Speaking of autodetection, hardware differs there as well. Some computers can autodetect whether a headphone or a headset has been plugged in, whereas others can not. Some computers also have a "mic in" mode, so they would have only one jack, but you can manually retask it to be a microphone input.
Finally, a few netbooks have one 3.5 mm TRS jack where you can plug in either a headphone or a mic but not a headset.

So, how would you know which sort of headset jack(s) you have on your device? Well, I found the most reliable source is to actually look at the small icon present next to the jack. Does it look like a headphone (without mic), headset (with mic) or a microphone? If there are two icons separated by a slash "/", it means "either or".

For the jacks where the hardware cannot autodetect what has been plugged in, the user needs to do this manually. In Ubuntu 14.04, we now have a dialog:

In previous versions of Ubuntu, you would have to go to the sound settings dialog and make sure the correct input and output were selected. So still solvable, just a few more clicks. (The dialog might also be present in some Ubuntu preinstalls running Ubuntu 12.04.)

So in userspace, we should be all set. Now let's talk about kernels and individual devices.

Quite common with Dell machines manufactured in the last year or so, is the version where the hardware can't distinguish between headphones and headsets. These machines need to be quirked in the kernel, which means that for every new model, somebody has to insert a row in a table inside the kernel. Without that quirk, the jack will work, but with headphones only.
So if your Dell machine is one of these and not currently supporting headset microphones in Ubuntu 14.04, here's what you can do:

• Check which codec you have: We currently can enable this for ALC255, ALC283, ALC292 and ALC668. "grep -r Realtek /proc/asound/card*" would be the quickest way to figure this out.
• Try it for yourself: edit /etc/modprobe.d/alsa-base.conf and add the line "options snd-hda-intel model=dell-headset-multi". (A few instead need "options snd-hda-intel model=dell-headset-dock", but it's not that common.) Reboot your computer and test.
• Regardless of whether you manage to resolve this or not, feel free to file a bug using the "ubuntu-bug audio" command. Please remove the workaround from the previous step (and reboot) before filing the bug. This might help others with the same hardware, as well as helping us upstreaming your fix to future kernels in case the workaround was successful. Please keep separate machines in separate bugs as it helps us track when a specific hardware is fixed.

Notes for people not running Ubuntu

• Kernel support for most newer devices appeared in 3.10. Additional quirks have been added to even newer kernels, but most of them are with CC to stable, so will hopefully appear in 3.10 as well.
• PulseAudio support is present in 4.0 and newer.
• The "what did you plug in"-dialog is a part of unity-settings-daemon. The code is free software and available here.

07 Mar 2014 10:17am GMT

Today I started work on the third release of Qimo. I'm slowly but surely learning how to do it better.

In the first release of Qimo I unpacked an Ubuntu ISO by hand, changed things by hand, and then re-packed the ISO….by hand. It was really quite a bit of work.

By the second release I had learned to build debian packages to install Qimo's artwork, configurations and dependencies. This make things a good bit easier, but I was still unpacking Ubuntu's ISO, ripping things out, installing my new packages, hacking a few more things together, and then packing it up again.

Now, for the third release, I'm learning how to use debootstrap to create a brand new ISO, just for Qimo, with just the things that Qimo needs to run. I'm still learning how it all works, but I'm hoping it will reduce the time and effort it takes to spin up a new CD image, which will let me iterate faster on the actual development of Qimo, and maybe even provide regular image downloads during development.

Who knows, if all goes well, I might even have time to fix up the website.

07 Mar 2014 9:00am GMT

Hi,

Today, Ubuntu GNOME Team has submitted a proposal for being an LTS release to Ubuntu Technical Board Team and that is for Trusty Tahr Cycle.

It means, if the Ubuntu Technical Board approves our proposal, Ubuntu GNOME 14.04 will be LTS - fingers crossed.

What does LTS mean?
Please see this Wiki Page.

Whether Ubuntu GNOME 14.04 will be an LTS release or not, we shall definitely need 'more active contributors and manpower'. The community is growing fast, both in quality and quantity which is very promising and this has absolutely increased our confidence that we could do more and go the extra miles. Our need to 'more contributions' will never stop since we have decided to go that path.

There are lots of areas where you can help and support Ubuntu GNOME with. Please have a read at:
Getting Involved with Ubuntu GNOME.

If you have any question, please don't hesitate to Contact Us.

"I am because we are."

"All of us are smarter than any one of us."

Thank you for choosing and supporting Ubuntu GNOME!

07 Mar 2014 6:32am GMT

As some of you will know, I founded the Community Leadership Summit that takes place in Portland, Oregon every year. The event brings together community leaders, organizers and managers and the projects and organizations that are interested in growing and empowering a strong community. Each year we discuss, debate and continue to refine the art of building an effective and capable community, structured in a set of presentation and attendee-driven unconference sessions.

This year's event is happening on 18th - 19th July 2014 (the two days before OSCON), and is shaping up to be a great event. We have over 180 people registered already, with a diverse and wide-ranging set of attendees. The event is free to attend, you just need to register first. We hope to see you there!

In a few weeks though we have an additional sister-event to the main Community Leadership Summit at the Open Source Think Tank.

The Community Leadership Summit and Open Source Think Tank have partnered to create a unique event designed for executives and managers involved in community management planning and strategic development. While the normal annual Community Leadership Summit serves practicing community managers and leaders well, this unique event is designed to be very focused on executives in a strategic leadership position to understand the value and process of building a community.

I have been wanting to coordinate a strategic leadership event such as this for some time, and the Think Tank is the perfect venue; it brings together executives across a wide range of Open Source organizations, and I will be delivering the Community Leadership Summit track as a key part of the event on the first day.

The event takes place on 24th March 2014 in Napa, California. See the event homepage for more details - I hope to see you there!

The track is shaping up well. We will have keynote sessions, break-out groups discussing gamification, metrics, hiring community managers, and more, a dedicated case study (based on a real organization with the identity anonymized) to exercise these skills and more.

If you want to join the Community Leadership Summit track at the Open Source Think Tank, please drop me an email as space is limited. I hope to see you there!

06 Mar 2014 11:03pm GMT

Next week we have our Ubuntu Developer Summit, taking place online from Tues 11th March 2014 - Thurs 13th March 2014. Go and see the schedule - we still have lots of schedule space if you want to run a session. For details of how to propose a session, see this guide.

I just want to highlight a session I would like to really invite input on in particular.

Today the online Ubuntu Developer Summit is largely based on the formula from our physical UDSs that we used to have, and that formula goes back to 2004. While these have traditionally served the project well, I am cognizant that our community is much bigger and more diverse than it used to be, and our current Ubuntu Developer Summit doesn't serve our wider community as well as it could; there is more to Ubuntu to rigorous software engineering.

UDS is great if you are a developer focused on building software and ensuring you have a plan to do so, but for our translators, advocates, marketeers, app developers, and more…the format doesn't suit those communities as well.

As such, I would like to discuss this and explore opportunities where UDS could serve our wider community better. The session is here and is on Wed 12th March at 15.00UTC. I hope you can join me!

06 Mar 2014 10:51pm GMT

Continuing our discussion of the testing within ubuntu, today's post will talk about how you can help ubuntu stay healthy by manually testing the images produced. No amount of robots or automated testing in the world can replace you (well, at least not yet, heh), and more specifically your workflow and usage patterns.

As discussed, everyday new images are produced for ubuntu for all supported architecture types. I would encourage you to follow along and watch the progression of the OS through these images and your testing. Every data point matters and testing on a regular basis is helpful. So how to get started?

Settle in with a nice cup of tea while testing!

The Desktop
For the desktop images everything you need is on the image tracker. There is a wonderful video and text tutorial for helping you get started. You report your results on the tracker itself in a simple web form, so you'll need a launchpad account if you don't have one.

The secondary way to help keep the desktop images in good shape is to install and run the development version of ubuntu on your machine. Each day you can check for updates and update your machine to stay in sync. Use your pc as you normally would, and when you find a bug, report it! Bugs found before the release are much easier to fix than after release.

Phablet
Now for the phablet images you will need a device capable of running the image. Check out the list. Grab your device and go through the installation process as described on the wiki. Make sure to select the '-proposed' channel when you install so you will see updates to get the latest images being worked on every time they are built. From there you can update everyday. Use the device and when you find a bug, report it! Here's a wiki page to help guide your testing and help you understand how and where to report bugs.

Don't forget there's a whole team of people within ubuntu dedicated to testing just like you. And they would love to have you join them!

06 Mar 2014 10:26pm GMT

Another year, our fellow (and Ubuntu member) Nathan Heafner prepared the Ubuntu community survey, a simple and quick test (no more than 2 minutes, trust me) whose results will help a lot to the entire community of those (like us!) who make Ubuntu and its flavours more secure, useable and beautiful. You'll be asked about your preferred desktop (I'm sure it's LXDE for Lubuntu), web browser, if you

06 Mar 2014 9:42pm GMT

The bottom edge is the most pleasurable edge to use. Grab a phone, any phone, and slide your thumb up over the bottom edge, then back. Go on, do it a few times. Feel good? Yeah, our extensive research suggests this feels pretty amazing to pretty much everyone.

Hmmm…. Feels good!

That's why we've given the bottom edge to you, the developer, for your app. It's the best one and we thought you could make the best use of it. If you want to create a truly "Ubuntu!" experience for your app you'll want to invest in thoughtful but also creative interpretations of this edge in your app.

In fact, getting THIS ONE THING perfect is the most important thing you do when you bring your app to Ubuntu. Pretty much everything else is just… you know, obvious. But creating a bottom edge experience that is exactly perfect for your app and consistent with our values is where the magic happens.

Be perfect, be yourself, be exciting

There is no one answer for "the bottom edge". There are definitely some values we can apply to judge if it's a GREAT bottom edge, and there are several patterns that you'll see, but you should start with a blank canvas and set yourself the goal of making your bottom edge experience YOURS.

Just to get the creative juices flowing, here are three great examples:

Think phases. Go beyond "one thing" in the gesture

The bottom edge swipe very naturally lends itself to what we call a "ranged gesture". This is a gesture where going further does more. In other words, a great bottom edge will often be more than a simple transition. For example, you are unlikely to be great if you just reveal a toolbar, or pause a movie. You've got the opportunity to take several (well, two, at most three) logical "steps" on the way from the bottom edge up to the full stretch of the thumb.

When we design ranged gestures, though, we have to do a couple of things right to make them feel slick.

1. Make them connect smoothly

If your bottom edge gesture is going to have two phases, make sure that you pick two things which are related, so that the second one feels like a natural extension of the first.

A good example is the way we use the left edge: a little bit of left edge shows your *favourite* apps, a lot shows you ALL the apps. Seeing "all the apps" is a natural place to go if seeing your favourite apps wasn't enough… it's "more apps". That makes a really good ranged gesture.

If the second phase was totaly unrelated to the first, it would feel jarring. Don't do that!

Some examples of great ranged gestures:

1. In a movie player, start with the player controls, then go further to reveal the chapter selection, and maybe even further to pop out of the movie to show other movies available on the device.

2. In a map, use the bottom edge to zoom out. This is very sexy because the further you go the further you zoom, and zooming back is very naturally a tap where you want to zoom in.

3. In a calendar, use the bottom edge to go from day to week to month to year view, like zooming out in time.

4. In a turn-based game, use the bottom edge to pause the game and present game options.

5. Go radial - present a radial menu of 5 top actions. Make it fade in beautifully so people want to use the bottom edge just to see those things show up. Make it fast so you just have to slide to one of them and release to invoke the action. Slick. Fast. Yum.

2. Be reversible. Let people change their mind easily.

Your user might not have intended to invoke the bottom edge, so it should always be possible for them to change their mind before they let go and slide back down, at which point their app is unchanged, they haven't switched mode or done anything that they have to undo. Sliding back down is like saying "Oops, not down this corridor!" and you should respect that perfectly.

So, don't pause or commit to any change until the finger is lifted off the screen - make sure that someone can unwind the use of the edge just by changing direction.

Actually… I don't need to create a new note

3. Make it visually sexy

This is a FANTASTIC opportunity to show off some really beautiful visual design and motion graphics skills. A really beautiful set of transitions or effects will make people say "ooooh!". If you get this really right, you'll see people showing their friends that experience. "Check this out!". "Ooooooh". "Do it again!". "Aaaaah.", "Can I try?"…. that's what you want to get when you show it to friends and family before you reveal it to the world.

Trust us, there are a million options for you, but to make it really work well will take a lot of thought and testing…. but it's definitely worth it! Remember the "desktop cube" and how much fun it was to show people that? Now imagine getting the same reaction to your bottom edge… that's what you're shooting for.

The very best bottom edge experience will have movement associated with every tiny move of your finger. It will feel "on rails", as you move your finger up it feels like you are totally in control of the scene that is unfolding, all the way up to the point where the final phase of your experience "clicks" into place, the final commit.

4. Hint, reveal, commit

We have a pattern we call "hint, reveal, commit". For any substantial change that a gesture might drive, we want first to hint that it will happen, then we want a stretch of the gesture which reveals the first part of the change without actually making it happen, and finally we want a "click" which is the commit.

A good example is the launcher. First, we show a shadow. If you just tap at the edge, all you see is that shadow, briefly. That's the hint. There is "something on the edge". If you slide a little bit from the edge, you start to see the launcher and the app dims slightly. That's the reveal, it tells you what's coming, but still lets you change your mind. And finally, before the launcher is fully revealed, there is a point at which it "clicks" into place. That's the commit. Letting go of the screen after the commit, you KNOW you will have the launcher.

Hint. Reveal. Commit.

Now, here's the fun part. With a ranged gesture, you want to think about hint, reveal, commit for EACH PHASE of the gesture. It's OK for the commit of one phase to immediately give you a hint of the next - you are, after all, in mid-gesture. In fact, that's what we usually do ourselves, we show the second phase hint at the same time as the first phase commit.

The reveal is usually the place where you want to make it feel like the user is in total control: have something that tracks the movement of the finger up the screen; it could be fading something in, or moving something in response to that movement. The important thing is that every tiny movement of the finger should reveal more, or less, until the commit.

Prioritise. Really, PRIORITISE

You have one bottom edge. Only one. It's the sexiest thing for a user to do. They can even do it without looking where they are pressing - it's an instinctive thing, pure muscle memory.

So you should think carefully about what's REALLY IMPORTANT and CENTRAL in your app. Maybe there is something that the user will do all the time and you want to make it easy for them to do it fast, no hunting and pecking for buttons. Maybe there's a natural "zoom out" expression in your app (those are usually good if you can make them beautifully visual). There is only one first phase to your bottom edge, it's the first thing people will try - make it great, choose wisely!

Provide a visual cue

Having a magical bottom edge that nobody discovers is no fun at all!

We can't guarantee that every app will use the bottom edge. Some apps will be so straightforward that a bottom edge experience would be superfluous - just for show. And we don't want that.

So users can't be CERTAIN there is a bottom edge worth trying. That's risky, because if they try it a few times and get no result, they'll stop trying it for apps which DO have a great bottom edge. So, you want to provide some sort of cue that it's worth their while to give it a go.

Sometimes you can provide that cue as part of a transition into the app. You could show the stuff that's in there, and animate it away into the edge after a few seconds during the app launch, so people know its there. That might be enough.

You might also want to leave a visual cue on the screen all the time. If you do, though, keep it REALLY small. Just a hint, just a clue, just a taste. For example, you might have a teeny little tab with a (+) on it if that edge holds the magic for adding something. Or you might have a teeny tab with the word "London" on it, if the bottom edge will reveal more cities, starting with London. Or just a highlighted line might do the trick.

Be creative on the cue. Make it fit with the story you are telling. There are a million possibilities and only one is best for your particular design. Have fun, but don't forget the cue!

Common patterns

Yes, if you're stuck for inspiration, there are a few common patterns you might want to consider. We put this LAST because we really think you want to be inspired by the essence of YOUR APP, not just following a pattern that works elsewhere, in case you miss a chance to invent something really great for yourself and for others.

Zooming out

Many apps have the idea of an "outer" layer, or levels. Maps are an obvious case, calendars also have the idea of a "wider view" (days, weeks, months, years). But the concept of "taking a step back from the coal face" is very common. For example, in a word processor, you might step back to switch between files. In a browser, you might step back to switch between tabs. In a game, you might step back to change settings or invite a friend to play. In Evernote, stepping back from the current note might show you other notes in the same album, or other albums altogether.

By scaling down the content (objects, time, space) we offer a quicker way to navigate across large amounts of content. Step back, go HERE is a great way to get around.

Toggle

If your app has two, and only two, main faces, then the bottom edge is a fast, controlled way to switch between them. You can do a nice cross-fade, or a page-over effect that makes the user feel in control.

Controls

If your app has a set of controls - for example, a music player - then the bottom edge might be a great way to bring those smoothly onto the screen.

A great idea is to think carefully about the various controls, and have a ranged gesture which reveals steadily more. For example, first just play, pause, back and forward, then things like chapter selection which provide a broader view of the content.

Quick draw

Your app may have a particular thing that you want people to be able to do instantly, with nothing but a reflex reaction. For example, a note-taking app might use the bottom edge as a quick-draw "new note" facility.

Make it great!

This is bottom edge is something unique to Ubuntu - we've given it to you because it really is the prime edge from a user perspective, and the app has all the user's attention. It's worth taking time to think carefully, try a range of options, test them on your friends, and craft it beautifully.

06 Mar 2014 4:09pm GMT

Happy by Sergei Pozdnyak

The submissions process for Ubuntu 14.04 is now closed. If you'd like to look at the images head over to the Flickr Group. From here on a group of dedicated and splendid individuals will get together to select the images that are going to go into the next release of Ubuntu. We'll be hanging out on #1404wallpaper on Freenode and you can come listen in

We generally welcome discussion but please remember that a decision is needed from the time that people volunteer so not too much additional debate.

We'll start with a meeting tomorrow, Friday 7th March, at 19:00GMT.

06 Mar 2014 3:33pm GMT

Ubuntu Touch has been under the spotlight of Ubuntu community, interested users and third parties. But following the steps and participating in the development of this revolutionary platform has been a real challenge for the Tunisian LoCo Team.

Currently the official development device, Google/LG Nexus 4, is not available for the Tunisian market which makes it harder to get hands on for testing purposes.

On the other hand, regardless of hardware availability problems for the Tunisian LoCo team, our community have kept a good pace following and mastering the latest Ubuntu technologies.

Actually, the Tunisian community supported Ubuntu Touch since the beginning and dedicated the time to introduce it during Ubuntu Global Jam 13.03. Few months later was the first serious Ubuntu Touch development experience in September 2013 during the Ubuntu Touch coding sprint held in GNU30 event (Organized by Esprit Libre in collaboration with more than ten local FLOSS communities and clubs, including Ubuntu-TN).

Later in 2014, three Ubuntu Touch training sessions were ensured by three of the developer members from the GNU30 sprint (organized by Ubuntu-TN in collaboration with CLLFSM and ISIMUX).

Moreover, many upcoming events in Tunisia will concentrate on Ubuntu Touch, such as the local Ubuntu Dev Challenge and other Ubuntu Touch conferences and workshops. Thus, the need of a hardware device to showcase Ubuntu Touch and to test the serious applications.

Fortunately, I was lucky to get the support of Mr Amjed Abdejlil. The owner of a little store in Arizona (USA), but a big tech enthusiast and a supporter for the Tunisian Community. Actually, Mr Amjed was very happy to send me the official Ubuntu Touch development phone (Nexus 4). And I am very thankful for his great support.

So, I only got the phone last week, and I recently flashed Android 4.4 with the radio of Android 4.3 then installed Ubuntu Trusty in dual boot.

Following is an album with some pictures of the phone.

https://plus.google.com/photos/+AhmedSghaier/albums/5987373871308300337

I would be also happy to post a review and a little tutorial when possible.

More importantly, is that I intend to provide a "best effort" Ubuntu Touch application testing for local community developers. But I can promise this only for Ubuntu-TN FreedomFighter members, and will grant them a priority testing. (Please work harder to become an FF member in order to gain more community privileges)

To conclude with, this is a very exciting news for me. And I expect it to be as exciting for our LoCo team. I hope this will be just another push forward to see Tunisian Ubuntu developers soon.

06 Mar 2014 4:35am GMT

Packages for the release of KDE's document suite Calligra 2.8 are available for Kubuntu 12.04 LTS and 13.10. You can get it from the Kubuntu Backports PPA (alongside KDE SC 4.12). They are also in our development release.

05 Mar 2014 10:37pm GMT

Next in Kubuntu:

Allowing you to give us viable information on a crash even if you don't feel like reporting a lengthy bug report over at bugs.kde.org.

05 Mar 2014 3:07pm GMT

With the latest Kubuntu 14.04 Beta 1 out the door, the Kubuntu team is hard at work to deliver the highest possible quality for the upcoming LTS release.

As part of this we are introducing basic test cases that every user can run to ensure that core functionality such as instant messaging and playing MP3 files is working as expected. All tests are meant to take no more than 10 minutes and should be doable by just about everyone. They are the perfect way to get some basic testing done without all the hassle testing usually involves.

If you are already testing Beta 1, head on over to our Quality Assurance Headquarters to get the latest test cases.

Feel free to run any test case, at any time.

If you have any questions, drop me a mail at apachelogger@kubuntu.org, or stop by in #kubuntu-devel on irc.freenode.net.

kitten by David Flores

05 Mar 2014 3:05pm GMT

05 Mar 2014 11:21am GMT