Tomorrow we will be running our very first online Ubuntu Developer Summit. The event will take place over two days and span a range of different tracks: Community, Client, Cloud & Server, App Developers, and Foundations. We have never run an event like this before, but we have prepared extensively to deliver the best online UDS experience we can. When UDS is complete we will then review any rough edges and fix those up for the next event in May.

With this being a new event, I wanted to share some key tips about how to get participate.

For Everyone

UDS takes place on Tues 5th – Wed 6th March 2013 from 2pm UTC. Please note: the original time was 4pm UTC, but we brought the event forward by two hours.

The full event is taking place online and everyone is welcome to join, irrespective of whether you are an active contributor to the community, a partner, a business, an enthusiast, or anyone else. We will be using Google+ Hangouts On Air to stream video from the active participants in the session, and we also provide quick embedded access to IRC, note-taking, and more.

The event will kick off on Tuesday at 2pm UTC with a keynote session. There will then be two hours of sessions, then an hour of plenaries, and then another two hours of sessions. On the Wednesday we will kick off into sessions at 2pm, and have lightning talks in the normal plenary slot. Jorge Castro is taking care of the plenary talks and lightning talks; reach out to him if you want to run a lightning talk.

There are five tracks, with each (apart from Foundations) having two video streams. Each track has two track leads:

• Client – Jason Warner, Sebastien Bacher
• Server and Cloud – Antonio Rosales, Daviey Walker
• Community – Jono Bacon, Daniel Holbach
• App Developers – Alan Pope, David Planella
• Foundations – Steve Langasek

You can find all sessions listed at summit.ubuntu.com. Just visit the session you are interested in at the time of the session to view it; everything is included on the session page. You don’t need anything other than a web browser to view sessions but you will need a Google+ account to actively participate in a hangout.

For Track Leads

You should have all received an email from me about how to schedule sessions and how to start and stop the video streams.

Remember to ensure your Google+ is verified (Michael Hall should have checked this with you).

You and your co-track lead should pick one of the two tracks you have for your track and take care of setting up those streams.

Five minutes before a session (e.g. 1.55pm) is due to begin you should start the video stream and update the session in summit.ubuntu.com with the hangout and broadcast URLS. Likewise, 55 minutes into a session (e.g. 2.55pm), be sure to stop the hangout. We need to start and stop the video streams to ensure the recordings are broken up into the different hour long chunks. Required participants will automatically see a link on the session page to invite them to join a hangout – this page does not auto-reload though, so you may want to ask them to refresh the page to join.

Please keep an eye on the sessions on your track and interact with the session leaders to ensure that any required participants can be invited to the session as needed. There may be times as the session is running that people will need to be invited to join the hangout (e.g. IRC participants) – you need to be available to do this when the session leader needs you. If you are not actively participating in the session, feel free to just mute your mic and keep an eye on IRC or listen for when you are needed.

Instructions for starting and stopping the streams is at https://wiki.ubuntu.com/UDS/Sessions.

For Session Leaders

As a session leader your responsibility is to run a quality session, and to ensure that the topic gets a good level of discussion, work is planned and distributed, and the blueprint gets updated with the agreed work items.

Some tips:

• Make sure your Internet connection and computer are working well in advance of the session. We recommend you stop any software or services that is using your net connection (e.g. switch off any downloads or other video streaming).
• The video hangouts will be started and stopped by the track leads (see above) – if you need to invite a new person to a hangout, ask the track lead to invite them.
• In your session you will have people in the hangout speaking as well as people on IRC offering their contributions too. Be mindful of the IRC contributors, and repeat comments and statements of interest from IRC.
• Think of the hangout as the inner ring of the fishbowl at a physical UDS. Unfortunately there only 10 seats on the hangout, so we need to ensure the most active participants are in the hangout. People in the hangout should be speaking and actively participating. If you have an active participant on IRC and have free seats on the hangout, be sure to invite them to the hangout. Likewise, if you see someone who is not contributing on the hangout and there is someone active on IRC, ask the hangout person to move to IRC to open up a slot to invite the IRC person and bring them into the hangout.
• At the beginning of the session, explain the goals and purpose of the session and encourage people to take notes in the embedded etherpad.
• Have the discussion in the session, and be sure to help everyone participate as much as possible. Remember, you should try to keep the most active members in the hangout.
• 10 minutes before the end of the session summarize the key decisions and log work items on the blueprint that are assigned to people. This will provide a great set of next steps to move forward with that blueprint.

For Attendees

Joining a session is easy – just look at the schedule and click on a session to view it. On each session page you can see the video stream, the embedded IRC channel, and the embedded etherpad collaborative note taking. You can also see links to the blueprint and other related content.

You don’t need anything other than a web browser to view sessions but you will need a Google+ account to actively participate in a hangout.

If you want to chat to others in general about UDS, you can also join #ubuntu-uds on freenode.

All sessions will be recorded and available on the schedule when they are completed.

Ardour is an application for recording, editing and mixing music. It is licensed under the terms of the GPL 2.

The upcoming 3.0 release seemed like a good opportunity to take another look at the logo I designed in 2006. A selection of drafts from back then, ending with the final design:

I had to ask myself: Is this logo (still) appropriate for Ardour?

The upcoming 3.0 release will be a digital audio and MIDI production application, available for Linux and Mac OS X. It is designed for frequent and prolonged use, being able to deal with huge amounts of material, complex signal pathways, precise and intense editing. Reliability, correctness and precision are of utmost importance.

The logo should take a matching stance, be sharp and have a strong presence. I think the old version does a fine job in this regard. It also happens to be well established and liked by the community (of course not by everyone). Back then I decided to use a free-form wave shape, less stylized, more realistic. Now I think a shape with even subdivisions will make the logo appear more precise.

I worked my way through variations of the curves that describe top and bottom of the wave, the number of teeth, their shape, relative height of the type and its consequences on letter spacing:

PDF of above image, in case you’d like to take a closer look.

Application icons, first column are the old ones. I reduced the number of teeth for the smaller versions, keeping them at least 1 pixel wide.

The new logo is already in use on the new website that went online about a week ago. I helped a bit with color selection, made a few suggestion and provided 3 icons:

Filed under: Ardour, Icons, Linux Audio, Logos, Planet Ubuntu

I just want to echo Tony’s appeal to help three year-old Sam who was diagnosed with high risk neuroblastoma, a particularly aggressive cancer. It has spread from the main tumor into his bones and bone marrow. That makes it a class 4 cancer, the most advanced on the scale. The long term survival rate for high risk neuroblastoma is 40%.

As Tony shares:

The good news is that Sam is responding well to chemotherapy. But Sam’s oncologist at Manchester Children’s Hospital has recommended that Sam receives immunotherapy treatment so that his own body can recognise and attack the neuroblastoma if it returns.

The most successful treatment is not available in the UK because some of the drugs are still being trialled. It costs over £250,000 in the US. Which is why Sam desperately needs your help. Carl and Christine are trying to raise the money to send Sam for treatment in the US.

If you would like to donate to help Sam, that would be brilliant. In the UK you can just text SAMS67 and the amount you’d like to donate (£1, £2 £3 £4 £5 or £10) to 70070. Alternatively you can donate on-line at the Sam Shaw Just Giving page. It’s Sam’s fourth birthday this week, so it would be a great birthday present to give him.

Also be sure to join the appeal’s Facebook page.

Your donation to Sam will have an incredible impact on his life as well as his parents, Christine and Carl, who must be having a hell of a time right now dealing with all of this. Let’s all show them that we care by helping them to cover their son’s treatment.

This week’s blog post is a bit different. It’s about Laura’s childhood friend Christine, her husband Carl and their three year old son, Sam.

In January, Sam was diagnosed with high risk neuroblastoma, a particularly aggressive cancer. It has spread from the main tumor into his bones and bone marrow. That makes it a class 4 cancer, the most advanced on the scale. The long term survival rate for high risk neuroblastoma is 40%.

The good news is that Sam is responding well to chemotherapy. But Sam’s oncologist at Manchester Children’s Hospital has recommended that Sam receives immunotherapy treatment so that his own body can recognise and attack the neuroblastoma if it returns.

The most successful treatment is not available in the UK because some of the drugs are still being trialled. It costs over £250,000 in the US. Which is why Sam desperately needs your help. Carl and Christine are trying to raise the money to send Sam for treatment in the US.

If you would like to donate to help Sam, that would be brilliant. In the UK you can just text SAMS67 and the amount you’d like to donate (£1, £2 £3 £4 £5 or £10) to 70070. Alternatively you can donate on-line at the Sam Shaw Just Giving page. It’s Sam’s fourth birthday this week, so it would be a great birthday present to give him.

If you would like to keep up-to-date with news about Sam and the appeal, please join join the Facebook group.

Thanks for reading.

Pin It

So we have come to the next logical step. I have to say I called it as soon as I seen the implementation of the phone in Qt/QML. Merging touch and Unity on the desktop was the obvious thing because now we can have pretty much the 1 interface across all platforms. And I have to complement the team who made touch, it looks exactly what I thought the future of Unity to be. So im very happy obviously that im going to be using it on my desktop in the not to distant future.

So that aside I thought id give my views about things like the good old days 2 years ago when I was blogging a lot more frequently.

Mir: sounds interesting, I read down though the plan and some made sense others didn't but I have never been a man for people talking graphics although I should probably at least understand what's going on eventually. I can see why they would go for a new system rather than bending to wayland or sticking with X which is older than I am (its from 1984 and im from 1988). The thing that jumped out at me was the focus on security which I find very interesting how they plan on making things both lightweight and secure to the extent where they aren't sacrificing one for the other. The other thing that I immediately thought about was about driver interaction and application interaction. For hardware:

With our X-integration in place, you can run Mir on your desktop machine if your system runs a GPU that supports the free driver stack. For the closed-source desktop drivers: We are in active conversations with GPU vendors to enable Mir on those drivers/GPUs, too. More to this, we are working towards a more unified driver model sitting on top of EGL.

So it looks like it doesn't work with non-free drivers yet. So hopefully they will fix that soon or hopefully the free drivers get better. Interesting side note, the free drivers run at 100fps on my system and the non free ones at 70fps its just the free drivers don't play games and have some strange artefacts on the screen sometimes which is a pain. On windows its 100fps solid so that is obviously what my card can do its just for what ever reason the non free drivers just are 30% slower exactly on Linux :-/

Rolling release model: I had pretty strong opinions about rolling release models for a while and I think they can work well if the model is right. I think the one proposed is safe but I don't think its right. How would I do it?

Well this idea is actually 2 or 3 years old and I had it written down somewhere (maybe it got lost when I switched from WP to Drupal). So what I suggest is having Ubuntu and a Ubuntu+1 or next or what ever you want to call it. Just having 1 constantly supported release of Ubuntu and a secondary testing version. So +1 would be similar to Debian unstable and testing mixed together. You push it out to +1 and test it, if it breaks fix it and rinse and repeat till you have something solid working. It can work exactly like how normal releases work currently except push when ready instead of solid point releases. So when the next version of Unity you feel is user ready push to +1 test it with the stack you want under it and push it out when it runs as expected.

This system avoids the issue that LTS releases have and that is stagnation and it means that you only have to support 1 version for enterprise and regular users who normally stick to the regular releases. The huge downside is if someone messes up it effects everyone equally but thats what the +1 is for making sure that nothing goes into mainline that shouldn't.

EDIT: I didn't read the bit regarding drivers with Mir so I changed the section where I was presuming things, so much to read and I wrote it pretty fast so forgive the mistake :)

Tags: 

• Ubuntu

Lyra, a talented artistic friend, coined the word 'hipstercrite' during a recent conversation. I couldn't help laughing at the pure genius and wordsmith-juggling skill of her creation and now want it to become part of our urban lingo:

hip·ster·crite
/ˈhipstərkrit/

Noun
1. A person who hates on so-called hipsters while actually being a hipster himself and denies it.


I secretly wait for any conversation where I can drop and share this new gem into the urban vernacular.

Apparently the word already exists in urban dictionary. Proving once again the rule that if it doesn't exist on the internet, it doesn't exist. Damn you internets full of hipstercrites, even the domain (which I wanted to buy) is gone.

This week Jono Bacon announced that Ubuntu Developer Summits will become a series of online events. Having thought about it a few days, I’m now ready to input my own opinion to the discussion.

In the announcement Jono lists openness, transparency and accessibility as the major goals of the Ubuntu Developer Summits (UDS). The decision to move to an online event is supposed to improve these.

In this article I will explain why I don’t think it will, and why the new format looks just another Canonical team sprint. I’ll also cover some of my concerns over the accessibility and equality of the new format and important things I think the online events will lack, but shouldn’t. I will also discuss some of my opinions on how this changes the nature of UDS and the meaningfulness to flavors as well as how this change affects the Canonical-community relations.

Openness, transparency and accessibility

I value openness and transparency very much. However, I’m not sure if the new online format will increase them in any way. Canonical is already making many decisions that affect the community in-house, behind closed doors. Unfortunately, these decisions and their results don’t always roll out as expected.

Until now the community has had at least some voice in the discussion, or at least have been able to react to changes, if they have been discussed in UDS. It’s a pessimistic view, but I can’t see why Canonical employees would start discussing and working more closely now with the community on decisions that have already been made. Now that the event is online, it’s much easier to have more discreet, even hidden meetings about things where community input would be largely unwanted or at least ignored à la the in-house pre-UDS sessions.

While it’s evident that a physical event has limitations when it comes to accessibility, so does an online event. One of the main reasons that made the Canonical-community communication so effective in UDS was that everybody got together, in the same place and at the same time. This means everybody participating in person is (ideally) always available and 100% focused on the sessions.

Now that the event takes place online, people will not be as committed to participating a session in every slot. Even when they are participating, the session might not get their full attention, because there are more distractions when working online.

When people aren’t participating in a session, they most probably won’t be available, which means there won’t be any substitution to the off-session discussions. This is sad, because this used to be one of the most powerful features of UDS for officially recognized flavors (such as Xubuntu) and I believe for numerous other teams as well. Even if people did have these off-session discussions, they are just as useful as contacting anybody via IRC or email any time, so there’s no real benefit of the centralized time. As a matter of fact, people might be even busier than usually during the online events, making it even harder to get a hold of them.

Concerns of equality

One of my worries is the level of openness UDS can create while being an online event. There are a few issues which are raised from the community already, but I want to repeat.

The platform itself is one of the major concerns for the community: many of us aren’t comfortable using a proprietary platform. While it’s an easy choice for Canonical to deploy, it’s also a weird move from a major open source project.

Due to the technical limitations of Hangouts, there can only be 10 people who are videoconferencing at any time in a given session. While there are some similar limitations even in a physical event, I think the online event makes the thresold to join those 10 people higher for a few reasons. First, not all of us are comfortable with videoconferencing for various reasons. Some of the people in the community don’t want to be on the spotlight or are too afraid to do that with total strangers, others might not want to be streamed live.

While 10 is more slots than the amount of chairs we had for important people in UDS Raring, these slots are now assigned by the session leader to people in order of importance that they think the specific people will have on the meeting. My concern is that this might make it harder for some people to be given slots, including those that are not generally well known in the community or people who are known to strongly disagree with the session leaders. We will have to see how this works out in the forthcoming online UDS, but before it’s over, I’ll keep my reservations.

Naturally there are other ways to communicate as well, namely IRC and Etherpad. To be fair, the communication via those mediums worked well enough in UDS Raring, if the session leader simply wanted (think: remembered) to use them. Taking this into account, I don’t really think that taking the event online really makes it any more accessible for anybody. On the other hand, it still doesn’t offer a feasible alternative for taking part physically or being one of the participants in the videoconference.

As written by Jono in the announcement, Canonical wants to make the event as accessible for anybody with a decent internet connection. However, based on the facts above, the equality is ironically mostly virtual. The format change might bring accessibility and some real equality between participants, but in its entirety, I think it’s a step backwards. Those who participated in person got unbeatable benefits and even if they paid for their flights and accommodation themselves, a fair substitution to their money.

Letting the social aspect go

As I mentioned before, off-session discussions with a variety of people were one of the best features of UDS. Those who have attend UDS know that these discussions go on even after the actual conference for the day has ended. Making new contacts and having interesting and important discussions went on all the way to the last drinks of the evening. It’s silly to expect people to take this much time off of their normal schedules and try to socialize online in any way that resembles the socializing in a physical event. This feature is gone.

Losing the social aspect of UDS doesn’t only impact productivity in during the event. One of the unwanted side-effects is less and worse human relations between Canonical and community teams. Meeting people face-to-face and getting to know them behind their IRC nicks and email addresses makes communication in the future smoother. When these personal relations do not exist, cooperation will be much harder and slower in the future, including ever-so-important dispute resolution.

Ultimately, I believe these changes will lead to lower work morale and loyalty towards Canonical in the community. Whether it happens in critical parts for business from the Canonical point of view is a different story.

For many of the volunteers in the community contributing is also about fun. There aren’t many better things than seeing an old friend after a long while, chatting about something you both are passionate about and then have a drink. As mentioned, the new online format is taking lot of this fun away from the community. One of the things that I predict to happen is an influx of people to other conferences like DebConf, especially amongst those people for whom Ubuntu is only one part of their open source ecosystem. It’s impossible to foresee the actual implications for UDS and Canonical, but ultimately one participant lost is one opportunity lost.

Business before community?

As several people have said, this change along with a rolling release are probably good decisions for Canonical as a business, but not Ubuntu as a community. Making UDS an online event will not only cut quite a lot of financial slack, it also lets them focus on the things that make sense to them financially. Ultimately Canonical gets more control over which matters are discussed, which opinions are given voice and who communicates about them in their own events.

In addition to losing the social aspect and Ubuntu being the thing that made the people come together, there are possibly some caveats to Ubuntu development as well. In the worst case scenario, Canonical will lose a lot of contributors from the community, and I can’t see how this wouldn’t affect Canonical’s business too.

The last cautionary sign for the openness, transparency and equality is the lacking and too late communication about changed plans for UDS. Because of this, the first online UDS arrives too early and unexpected for the majority of the community. The fact that majority of the sessions are going to be revolve around the controversial discussion about moving to a rolling release makes the situation even less bearable for the community. The chosen way of communication backs up the vision that these changes are purely business-oriented. Unfortunately, it isn’t very fair for the community.

Furthermore, this is not the first time the communication from Canonical has been lacking. Numerous people have expressed their concerns and distrust in the past about Canonical’s way to communicate about changes in the infrastructure. So far Canonical has avoided the worst damage, but the atmosphere is starting to get tighter. It’s more likely than ever that people will part ways with Ubuntu in a way or another. If people leave now, it’s going to be really hard to do significant damage management and regain trust from the (former) community members.

Impact on flavors

Due to the various reasons mentioned before and becoming a way more Canonical and Ubuntu OS-centric, UDS is becoming borderline irrelevant and useless for flavors. From what I’ve read in the last few days, I believe this is the unanimous response from the flavor teams. This is worrisome for the flavors and the community at large because it is possible that the taken direction excludes the community from decision making that concerns its own infrastructure as well.

It is too early to say what kind of actions several flavors will take and what their position will be, not least because the uncertainty about a rolling release model and its implications. However, there is one thing that will most probably happen: since the flavors are slowly and involuntarily sliding off of UDS, it will be less and less meaningful to organize their sessions parallel to the “main” virtual UDS. Once this happens, the future of the flavors is even more full of justified fear, uncertainty and doubt. The only thing Canonical can do to reduce this effect is start communicating and discussing about the changes that affect the community truly openly.

What’s in the future for us?

The future for UDS is still partly out of sight. In the announcement Jono somewhat vaguely says that after two online events Canonical will “review the success of the next two online events” and “assess whether to continue the online format”. Whether it means Canonical will either get back to the physical format or drop UDS for good if the online format fails remains to be seen.

Until the first online event is over we can’t evaluate how the new format works. However, it is clear that Canonical needs to get the community involved in the event if they wish to keep the community close to them. To be succesful in this, Canonical needs to make sure UDS is equal to all participants. If they can truly integrate the community to the discussion during the first event they will be able to regain some trust and hope in the community to their communication. Ultimately the community can only consider the event succesgull if Canonical is able to achieve all the aforementioned goals as well as the major goals they have set for UDS.

At the end of the day, we have to remember Canonical is a business trying to make money with their product. Keeping this in mind and as an entrepreneur myself, I can empathize with many of their decisions. In my opinion the partly harsh criticism is justified though. Since Canonical has promoted Ubuntu as a community-oriented project from the beginning, it would be only fair to actually involve the community in the decision making and discussions well in advance. If they do not wish to do this, they should clearly communicate this to the community and their users.

Thanks

I would like to thank the following people for their support, numerous discussions and influence to this article: Elizabeth Krumbach, Scott Kitterman, Micah Gersten and Jussi Kekkonen. Thank you!

A guest post from Thomas Voss’ blog. Thomas is the Technical Architect (Client) at Canonical:

Some time ago, Canonical started internal discussions about our convergence strategy, clearly spelling out the distant target of shaping and developing a single computing platform and operating system that is able to power the cloud, classic desktop machines, laptops, TV sets, phones and tablets (fridges anyone?). More to this, we stated that we want a single mobile device, a bundle of portable computing power together with the respective operating system, that seamlessly adapts to different form-factors and use-cases. Or to put it a little more catchy:

Your phone is your TV, is your desktop, is your … you name it.

And yes, we were aiming for the moon. We worked hard to draft a system that would allow us to reach the moon, while at the same time catering towards our other central goal of providing a beautiful and lean user experience. It became apparent in conversations and discussions that one of the cornerstones of the future system we were designing will be the graphics stack, including the Unity shell. After much discussions about existing solutions (X & Weston), and how we could leverage them, we took a step back and distilled down our (technical) requirements for a future graphics stack:

• Tailored towards an EGL/GL(ES) world.
• Minimal assumptions regarding the underlying driver model.
• Ability to leverage existing drivers implementing the Android driver model.
• Ability to leverage existing hardware compositors.
• Efficient, in terms of memory-, CPU- and GPU-consumption/usage.
• Tightly integrated with the Unity shell, fulfilling the shell’s requirements while at the same time not dictating any sort of semantics up the stack.
• An efficient and secure input subsystem supporting demanding mobile use-cases.
• Fully tested from the ground up.
• Adaptable to future requirements.

With these priorities in mind, we revisited and carefully evaluated existing solutions again and found that neither of them satisfies our requirements. In particular, X and its driver model is way too complicated and feature-laden, resulting in a less efficient system and a driver model that is unlikely to be widely supported on mobile platforms. In the case of Weston, the lack of a clearly defined driver model as well as the lack of a rigorous development process in terms of testing driven by a set of well-defined requirements gave us doubts whether it would help us to reach the “moon”. We looked further and found Google’s SurfaceFlinger, a standalone compositor that fulfilled some but not all of our requirements. It benefits from its consistent driver model that is widely adopted and supported within the industry and it fulfills a clear set of requirements. It’s rock-solid and stable, but we did not think that it would empower us to fulfill our mission of a tightly integrated user experience that scales across form-factors. However, SurfaceFlinger was chosen as our initial solution for getting started with the overall Ubuntu Touch project, planning to replace SurfaceFlinger with Mir as soon as possible.

In summary, our evaluation of existing solutions led us to the conclusion that neither of them fits our requirements and that adjusting/adapting them would require substantial efforts, too. For this, we decided to go for our own solution, catering directly towards our goals and our vision, effectively saying: Yes, we are going to do our own display server.

The project was born and we decided to name it Mir (as in the space station), as it would be our outpost that finally enables us to reach our goal of arriving at the moon, providing a seamless and beautiful user experience spanning multiple form-factors. The team set off to work on Mir while large parts of Canonical started working on the Ubuntu Touch project (relying on SurfaceFlinger). A lot of knowledge and experience was and is transferred from the Ubuntu Touch project to the Mir team, with the work on the phone and tablet revealing more and more technical requirements and subtleties that heavily influenced the Mir architecture and implementation. Thus, one of the earliest technical decisions that has been taken by the team concerned the protocol that applications rely upon to communicate to Mir. We evaluated Wayland and compared it to the SurfaceFlinger approach, realizing that neither of them fits our needs. Wayland is a very promising and sensible attempt at standardizing the way that applications talk to a display server, however, it exposes privileged sections like the shell integration that we planned to handle differently, both for security reasons and as we wanted to decouple the way the shell works on top of the display server from the application-facing protocol. In the end, we decided to implement Mir’s core in a protocol-agnostic way, considering the communication protocol a very important part of the overall story, but not the driving one. We have chosen Google’s protocol buffers as our data and interface description language (DDL & IDL) and implemented a lean RPC layer that abstract away transport-specific details (relying on an ordinary socket by default). It is well tested and the protobuf IDL and DDL provide us with forward- as well as backward-versioning capabilities. However, the communication component of the overall system is adaptable and can be adjusted to account for future requirements and developments.

A final word on timelines: At the time of this writing, we are preparing to deploy the next version of the Unity shell tightly integrated with Mir in the not-too-distant future on the phone and the tablet. However, regarding the desktop use-case: We have integrated X, leveraging the prior XWayland work, to run on top of Mir (XMir) and started initial porting efforts for toolkits with a focus on Qt5. With our X-integration in place, you can run Mir on your desktop machine if your system runs a GPU that supports the free driver stack. For the closed-source desktop drivers: We are in active conversations with GPU vendors to enable Mir on those drivers/GPUs, too. More to this, we are working towards a more unified driver model sitting on top of EGL.

As we are moving along with the development of Mir, we will work on integrating existing toolkits with the new display stack to allow application developers a seamless transition between different form-factors and prevent them from the burden of supporting multiple different display servers. As noted before, Qt5 is our first target here, with GTK3 and XUL being in the pipeline. To support legacy X applications that cannot be adjusted to work against Mir, we will provide a translation-layer that leverages the existing XMir implementation and allows legacy X apps to use Mir transparently.

And that’s pretty much it. Thanks for reading. I hope I could give you some insight into the history of Mir, its motivation and its trajectory. If you want to dive even further into the Mir world, head over to wiki.ubuntu.com/MirSpec. A lot of work has already been done, but more of it lies ahead of us. So if you are curious, have questions, want to help us or simply want to get to know the team, join the Mir sessions at the upcoming virtual UDS. You might also want to read Olli’s description of the bigger picture, including our overall convergence strategy for Unity.

To the moon,

Thomas

I worked with applications, bugs and test-cases in the last day of the UGJ. In this opportunity we have a great and very productive Jam, I share with you the applications list tested:

1- Deja-dup
2- Firefox
3- File Roller
4- Gnome-Screenshot
5- Network Manager
6- Ubuntu-One

Besides, I am at the top of the testers list ( A big accomplishment for me )

Top Application testers

Remember, if you want to be part of the UGJ, you will find information about testing procedures in our wiki pages, the official wiki page: https://wiki.ubuntu.com/UbuntuGlobalJam

And the Ubuntu QA team wiki page for UGJ:https://wiki.ubuntu.com/QATeam/Cadence/Raring/Week7UbuntuGlobalJam

This Sunday, March 4, an Ubuntu Global Jam event was hosted in the Novosibirsk State Pedagogical University.

Lots of heavy images under the cut, beware!

( Read more... )

I personally have to say that I was impressed by the event and the friendly atmosphere at it, and carried out a lot of positive emotions, and it delights me to see an ever-growing number of women in the LUG! Hopefully the next time, as promised to the coordinator, I'll finally be able to fit in that long-overdue speech about women and sexism in free software.

comments

Back from a (almost) entirely-offline week vacation, a lot of news were waiting for me. A full book was written. OpenStack projects graduated. An Ubuntu rolling release model was considered. But what grabbed my attention was the announcement of UDS moving to a virtual event. And every 3 months. And over two days. And next week.

As someone who attended all UDSes (but one) since Prague in May 2008, as a Canonical employee then as an upstream developer, that was quite a shock. We all have fond memories and anecdotes of stuff that happened during those Ubuntu developer summits.

What those summits do

For those who never attended one, UDS (and the OpenStack Design Summits that were modeled after them) achieve a lot of goals for a community of open source developers:

1. Celebrate recent release, motivate all your developer community for the next 6 months
2. Brainstorm early ideas on complex topics, identify key stakeholders to include in further design discussion
3. Present an implementation plan for a proposed feature and get feedback from the rest of the community before starting to work on it
4. Reduce duplication of effort by getting everyone working on the same type of issues in the same room and around the same beers for a few days
5. Meet in informal settings people you usually only interact with online, to get to know them and reduce friction that can build up after too many heated threads

This all sounds very valuable. So why did Canonical decide to suppress UDSes as we knew them, while they were arguably part of their successful community development model ?

Who killed UDS

The reason is that UDS is a very costly event, and it was becoming more and more useless. A lot of Ubuntu development happens within Canonical those days, and UDS sessions gradually shifted from being brainstorming sessions between equal community members to being a formal communication of upcoming features/plans to gather immediate feedback (point [3] above). There were not so many brainstorming design sessions anymore (point [2] above, very difficult to do in a virtual setting), with design happening more and more behind Canonical curtains. There is less need to reduce duplication of effort (point [4] above), with less non-Canonical people starting to implement new things.

Therefore it makes sense to replace it with a less-costly, purely-virtual communication exercise that still perfectly fills point [3], with the added benefits of running it more often (updating everyone else on status more often), and improving accessibility for remote participants. If you add to the mix a move to rolling releases, it almost makes perfect sense. The problem is, they also get rid of points [1] and [5]. This will result in a even less motivated developer community, with more tension between Canonical employees and non-Canonical community members.

I’m not convinced that’s the right move. I for one will certainly regret them. But I think I understand the move in light of Canonical’s recent strategy.

What about OpenStack Design Summits ?

Some people have been asking me if OpenStack should move to a similar model. My answer is definitely not.

When Rick Clark imported the UDS model from Ubuntu to OpenStack, it was to fulfill one of the 4 Opens we pledged: Open Design. In OpenStack Design Summits, we openly debate how features should be designed, and empower the developers in the room to make those design decisions. Point [2] above is therefore essential. In OpenStack we also have a lot of different development groups working in parallel, and making sure we don’t duplicate effort is key to limit friction and make the best use of our resources. So we can’t just pass on point [4]. With more than 200 different developers authoring changes every month, the OpenStack development community is way past Dunbar’s number. Thread after thread, some resentment can build up over time between opposed developers. Get them to informally talk in person over a coffee or a beer, and most issues will be settled. Point [5] therefore lets us keep a healthy developer community. And finally, with about 20k changes committed per year, OpenStack developers are pretty busy. Having a week to celebrate and recharge motivation batteries every 6 months doesn’t sound like a bad thing. So we’d like to keep point [1].

So for OpenStack it definitely makes sense to keep our Design Summits the way they are. Running them as a track within the OpenStack Summit allows us to fund them, since there is so much momentum around OpenStack and so many people interested in attending those. We need to keep improving the remote participation options to include developers that unfortunately cannot join us. We need to keep doing it in different locations over the world to foster local participation. But meeting in person every 6 months is an integral part of our success, and we’ll keep doing it.

Next stop is in Portland, from April 15 to April 18. Join us !

I just released a new PyGObject for GNOME 3.7.91. This brings some marshalling fixes, plugs tons of memory leaks, and now raises a Python DeprecationWarning when your code calls a method which is marked as deprecated in the typelib. Please note that Python hides them by default, so if you are interested in those you need to run python with the -Wd option.

Thanks to all contributors!

• Fix many memory leaks (#675726, #693402, #691501, #510511, #672224, and several more which are detected by our test suite) (Martin Pitt)
• Dot not clobber original Gdk/Gtk functions with overrides (Martin Pitt) (#686835)
• Optimize GValue.get/set_value by setting GValue.g_type to a local (Simon Feltman) (#694857)
• Run tests with G_SLICE=debug_blocks (Martin Pitt) (#691501)
• Add override helper for stripping boolean returns (Martin Pitt) (#694431)
• Drop obsolete pygobject_register_sinkfunc() declaration (Martin Pitt) (#639849)
• Fix marshalling of C arrays with explicit length in signal arguments (Martin Pitt) (#662241)
• Fix signedness, overflow checking, and 32 bit overflow of GFlags (Martin Pitt) (#693121)
• gi/pygi-marshal-from-py.c: Fix build on Visual C++ (Chun-wei Fan) (#692856)
• Raise DeprecationWarning on deprecated callables (Martin Pitt) (#665084)
• pygtkcompat: Add Widget.window, scroll_to_mark, and window methods (Simon Feltman) (#694067)
• pygtkcompat: Add Gtk.Window.set_geometry_hints which accepts keyword arguments (Simon Feltman) (#694067)
• Ship pygobject.doap for autogen.sh (Martin Pitt) (#694591)
• Fix crashes in various GObject signal handler functions (Simon Feltman) (#633927)
• pygi-closure: Protect the GSList prepend with the GIL (Olivier Crête) (#684060)
• generictreemodel: Fix bad default return type for get_column_type (Simon Feltman)

It didn't quite make it into the release, but we now have a very basic Upstart GUI that should appear in Ubuntu along with the Upstart 1.7 release soon.

What is it? upstart-monitor is a simple application that shows Upstart events as they are emitted. It can be used to view both system-level events and also session-level events when Upstart is running as a Session Init.

It requires Upstart 1.7.

What can I use it for? The tool allows you to see events as they occur which is an aid to understanding. It also helps with writing new jobs since, if you are not sure which event to use, provoke the scenario you want, then just copy the appropriate event that appears in upstart-monitor to your .conf file (more details on this in a future post...).
How do I use it? Just start it to see events being emitted:




If you'd prefer a command-line version, run it with the '-n' option:



Where can I get it? If you can't wait for it to land in Ubuntu, you can grab it from here:

• http://people.canonical.com/~jhunt/upstart/gui/upstart-monitor.py

We've just released Upstart 1.7 which expands Upstarts abilities a lot. I'll follow up with a further post explaining what these changes mean for users as this release is soon to appear in Ubuntu.

Summary of changes

• New initctl commands: set-env, unset-env, get-env, list-env, reset-env, list-sessions (all except last with corresponding D-Bus methods).
• New D-Bus-only signals EventEmitted, Restarted, and EndSession method.
• Ability to run with PID >1 to allow Upstart to manage a user session.
  Running Upstart as a 'Session Init' in this way provides features
  above and beyond those provided by the original User Jobs such that
  the User Job facility has been removed entirely: to migrate from
  a system using User Jobs, simply ensure the user session is started with
  'init --user'.
• New upstart-event-bridge bridge which proxies system-level events down to Session Inits, allowing users jobs to react to udev events.
• Ability to read job configuration and override files from multiple freedesktop-compliant locations (Session Init only).
• Ability to shutdown both via a system shutdown request and via a user logout request (Session Init only).
• Additionally, there are a few bug fixes and 94 new tests.

Thanks to all the contributors, reviewers, testers and users!

Download
Get it here https://launchpad.net/upstart

Subunit V2 is coming along very well.

Current status:

• I have a complete implementation of the StreamResult API up as a patch for testtools. Thats 2K LOC including comeprehensive tests.
• Similarly, I have an implementation of a StreamResult parser and emitter for subunit. Thats 1K new LOC including comprehensive tests, and another 500 lines of churn where I migrate all the subunit filters to v2.
• pdb debugging works through subunit v2, permitting dropping into a debugger to work. Yay.

Remaining things to do:

• Update the other language bindings – the C library in particular.
• Teach testrepository to expect v2 input (and probably still store v1 for a while)
• Teach testrepository to use pipes for the stdin of test runner backends, and some control mechanism to switch input between different backends.
• Discuss the in-Python API with more folk.
• Get code merged

Most people are probably aware by now that this Tuesday, 5 March starts the first of the new virtual Ubuntu Developer Summit events. In order to handle the changes nicely, we have made some changes to the Summit Scheduler. The changes that we made allows a meeting and/or a summit to be set as ‘virtual.’ When a meeting is set as virtual, the meeting page will render with a new virtual layout. This layout includes the Google Hangout broadcast, the IRC channel via the webchat client, and the Etherpad, all embedded on in the page. The required participants for a meeting will also be given a link to participate in the hangout. Both the embedded broadcast and the hangout link have to manually be added by the track lead prior to each meeting. If the hangout broadcast isn’t available when you visit the page, please be patient and wait for the data to be added. Once the information is added to Summit, the meeting page should automatically load the hangout broadcast.

Please don’t forget to test using hangouts prior to UDS starting so that we can minimize the number of issues we have with the hangouts. A “best practices” guide has been created for use during the Ubuntu On Air events. Please take the time to look at these practices before Tuesday.

UGJ day2 was dedicated to test the Ubuntu normal version (amd64) and the native applications.

Have a nice Jam!

Daily Iso Tests:
1- Ubuntu amd64 (entire disk)
2- Ubuntu amd64 (Manual partitioning)
3- Live Session

Ubuntu Iso testers

Application Tests:
1- Empathy
2- Gnome-Terminal
3- Eye of Gnome
4- Totem
5- Evince

Application Testers

 

Remember, if you want to be part of the UGJ, you will find information about testing procedures in our wiki pages, the official wiki page: https://wiki.ubuntu.com/UbuntuGlobalJam

And the Ubuntu QA team wiki page for UGJ:https://wiki.ubuntu.com/QATeam/Cadence/Raring/Week7UbuntuGlobalJam

 

Due to the data loss I blogged about, I had to reverse engineer the encryption used by git-annex for its encrypted special remotes. The file system on which the content lived has a bullet hole of 8 GB in it, which was helpfully discarded by pvmove. It's pretty unhappy about that fact, parts of the git repository are unusable and directories cannot be accessed anymore. git-annex cannot possibly run anymore.

However, I was still able to access the git-annex branch within said git repository (using porcelain). This branch contains a file called remote.log which contains the keys of the special remotes. There's one per remote, encrypted to a GPG key of your choice and all files within that remote are encrypted with the same symmetric key.

One small detail stopped me from getting the decryption right the first time, though. It seems that git-annex uses randomness generated by GPG and armored into base64. In my naïveté I spotted the base64 and decoded it. Instead it's used verbatim: the first 256 bytes as HMAC key (which reduces randomness to 192 bytes) and the remaining bytes for the symmetric key used by GPG (which will do another key derivation for CAST5 with it). A bug about that just hit the git-annex wiki.

With that knowledge in mind I wrote a little tool that's able to generate encrypted content keys from the plain ones used in the symlinks. That helps you to locate the file in the encrypted remote. Fetch it and then use the tool to decrypt the file in question with the right key.

The lesson: Really backup the git repository used with git-annex and especially remote.log. I'm now missing most of the metadata but for some more important files it's luckily still present. Recovery of the file content does not depend on it if you can deduce the filename from the content. If you have many little files it might be a bit futile without it, though.

I have uploaded part three of my parsing and Haskell video in which I build a parse tree for Brainfuck using Parsec.

Once more, comments, suggestions etc gratefully received.

This week's episode unusually posts early on a Sunday and talks about the recent Rolling Releases proposal as well as the virtual Ubuntu Developer Summit happening later this week. Further episodes are possible during the remainder of the week.

Related links:

• Blueprint: Consider General Contingencies for Xubuntu

• Blueprint: LoCo Community - what's next?

• Rick Spencer: Let's Discuss Interim Releases (and a Rolling Release)

• UbuntuOnAir: New Release Process Proposal

Download here (MP3) (ogg), or subscribe to the podcast (MP3) to have episodes delivered to your media player. We suggest subscribing by way of a service like gpodder.net. Materials to support the work of the Air Staff of Erie Looking Productions can be purchased via their Amazon wish list.

This work is licensed under the Creative Commons Attribution-ShareAlike 3.0 United States License. To view a copy of this license, visit http://creativecommons.org/licenses/by-sa/3.0/us/.