At openSUSE Conference in Prague last month, we had a BoF about Secure Boot, where I describe the various tasks which are needed to ensure openSUSE can support Secure Boot. They are listed on my slides, but I thought it would be more useful to describe them here.

Before we begin, if you need some refresh about Secure Boot, I suggest the blog posts from Olaf Kirch and Vojtěch Pavlík on SUSE Blog (overview, details and approach to it) and of course, all the war stories of Matthew Garrett on this topic ;)

To have openSUSE installable (and runnable) on a Secure Boot enabled system, without any additional user intervention (like adding your own key in UEFI firmware or disabling Secure Boot), we need to do the following to the distribution :

• to the kernel (many of those features are in 3.7 or in upcoming 3.8):

• convert the kernel as a EFI executable (it will be used to store kernel signature)
• UEFI variable access
• UEFI clock support (nice to have)
• UEFI getvideomode (if we want flicker-free boot)
• UEFI reboot (we already have 4 other way to reboot a system, why not add yet another one ;)
• KMS drivers (for old chipsets like Matrox, AST).
• sign main kernel
• sign all in-tree kernel modules
• generate a private/public key pair to be used out of tree modules
• add Secure Boot support in KExec / KDump and Xen (optional)
• disable hibernation in Secure Boot mode (or have a secure way to save / restore suspended system)
• add signature check in kernel
• to bootloader:
• package shim loader
• modify grub2 so it uses shim loader to check kernel signature at boot
• to Build Service:
• to be able to build external kernel modules (think KMP) using the private/public key generated at kernel build
• but do not allow this key to be used for any random KMP build (otherwise, you defeat the purpose of signing the module)
• to userspace tools:
• package xf86-video-modesettings, for graphics chipset with non-accelerated KMS drivers
• add support for signature check in modutils / kmod
• package tools to sign kernel / modules
• package tools to manage UEFI variables and keys
• to the installer / DVD image
• maybe display some warnings about installing a system in Secure Boot mode (not 100% sure we should do this)
• maybe signing the initial installer (and make sure it can't load non-signed modules)
• ensure the DVD image has shim + grub2 as bootloader when booting on UEFI system
• and we also need to do the signing part:
• if we want Secure Boot to be transparent to users, we need our shim loader to be signed by the authority handling UEFI key, ie Microsoft
• this requires some legal paperwork (getting MS developer account, getting a Authenticode certificate, etc..), some obligation (making sure you can't circumvent Secure Boot once Linux is booted) and once it is done, sending shim loader to be signed by MS and package the result.

As you can see, this is a lot of work but I think we will be able to have everything in order for next openSUSE release !

What about creating  an airline company called “Geeko Air”? Is an awesome idea , isn’t it?

Well , this post is neither a thought about creating a new company nor a new way to make money.

So let’s see what it is. Before 10 days i had to travel from Madrid to Paris for my Practicum. At this case casual dress is a mandatory , so i wore a Geeko shirt (thanks Bruno :)). While passing the security control , the security guy (named Josue) saw the openSUSE badge (the front one) on my shirt and asked me ” Do you work for openSUSE?” my response was “No i contribute to the openSUSE Project”. The security control stopped and an interesting conversation begun. Josue told me that he was an Ubuntu user , but now  uses openSUSE and he is very satisfied. Without any thought i gave him the only openSUSE Promo DVD i had.

So Geekos , we have to know that our Project is great and also please make the Geeko Shirt available at openSUSE Shop (for more info ask Bruno)

 

No fallback mode in GNOME 3.8

As announced by the release team two weeks ago, the fallback mode will be gone in GNOME 3.8. The decision was taken after some discussion on the mailing list back in June and in October, as well as some discussion during Boston Summit 2012. We also have a wiki page detailing the discussion arguments.

In my opinion, the biggest issue we had with the fallback mode is that, with only a few cycles, it quickly became clearly not tested enough, and lacked manpower for proper evolution along with other GNOME 3 changes. This resulted in a much lower quality than what we expect from GNOME. Moreover, several applications actually started requiring Clutter, and therefore didn't work anymore in a real fallback manner (ie, where you have no proper 3D acceleration); this means the fallback mode, when really used as a fallback, was not offering a fully usable desktop, and would be considered more like an alternative shell than a fallback mode.

Where does this leave us?, you might ask.

Well, for a start, GNOME 3.x had several iterative cycles to bring tons of improvements. Many users who were using the fallback mode because they didn't like the GNOME Shell experience are now happy with 3.6. But we're going an extra step starting with the next version: there is an explicit goal of having the project provide a set of extensions to help even more people preferring the fallback mode experience. The tentative list of what the extensions would provide is classic alt-tab, task bar, minimize/maximize buttons, and a main menu. This effort is being publicly tracked, so everyone can participate: if you're interested in contributing to these extensions, don't hesitate, I have no doubt help will be welcomed! Update: this topic is being discussed on desktop-devel-list right now!

There will also be work on improving GNOME 3 when running with software rendering. Of course, llvmpipe was a good start, and llvmpipe itself is getting better and better. But in addition, there are plans to offer a reduced resources mode, with fewer animations, that would be used in different circumstances, including when using software rendering. This should really improve the performances under llvmpipe.

There might be cases where these improvements will not be good enough in 3.8 (or with the Mesa and llvmpipe versions available at that time), resulting in a GNOME version that people might not consider acceptable in terms of performance or hardware support. Things will improve with time, obviously, and 3.10 will solve more and more issues; hence I would recommend to people hitting such issues to stay with 3.6 for a few more months.

All in all, the community is working on having future versions of GNOME, starting with GNOME 3.8, offer an improved alternative to the fallback mode.

Future of gnome-panel (and other fallback components)

Of course, this raises the question of what happens to the components of the fallback mode: gnome-applets, gnome-panel, gnome-screensaver, metacity, notification-daemon, polkit-gnome, etc. These components don't necessarily have to go away: they're just not part of what the GNOME project officially releases, and people are welcome to keep working on them. It's really up to each maintainer.

As for myself, I do not intend to keep maintaining gnome-panel after 3.6.x. I did a 3.6.2 release a few days ago, and it might well be what I consider my final release. If there's a strong push for some patches, there could be a 3.6.3 tarball... So, if you want to keep gnome-panel alive, contact me and you can become maintainer. As long as I either know you, or I can see that you have some minimal coding abilities, you'll get the maintainer hat for free :-)

Now, I believe a group of people could well adopt all the fallback components and keep building a great desktop, on top of other GNOME 3 bricks. They wouldn't even have to restrict themselves to what the GNOME 3 vision is (which is something that blocked some people from seriously contributing to gnome-panel). I don't think it'd be actually too much work: the code is already there! Of course, there would be some compatibility bits removed from other GNOME modules that would need to be moved elsewhere, but in most cases, it's really just about moving the code, not re-implementing things.

To be honest, I would really have loved if the MATE people had taken such an approach (maybe it's not too late?). I think it's a more reasonable effort than effectively forking all of GNOME 2, including obsolete technologies, as the amount of work is much more reasonable.

I'm eager to see if a group will step up to keep alive this old code, which represents thousands of hours from many of us! I wouldn't use it, but it would still make me happy :-)

Almost three years passed since latest release of QJson. A lot of stuff happened in my life and QJson definitely paid for that. I have to admit I’m a bit ashamed.

So here we go, QJson 0.8.0 is out!

What changed

A lot of bugs has been smashed during this time, this new release will fix issues like this one and this in a nicer way.

QJson’s API is still backward compatible, while the ABI changed.

Symbian support

Some work has also been done to get QJson work on the Symbian platform. The development happened a long time before Symbian was declared dead.

Currently I do not offer any kind of support for the Symbian platform because IMHO Symbian development is a mess and given the current situation in the mobile world I don’t see any point in investing more efforts on that.

Obviously Symbian patches and documentation are still accepted, as long as they don’t cause issues to the other target platforms.

QMake support

QJson always used cmake as build system but since some Windows developers had problems with it I decided to add some .pro files. That proved to be a bad choice for me since I had to support two build systems. I prefer to invest my time fixing bugs in the code and adding interesting features rather then triaging qmake issues on Windows. Hence I decided to remove them from git.

If you are a nostalgic you can still grab these files from git. They have been removed with commit 66d10c44dd3b21.

Relocating to Github

I decided to move QJson’s code from Gitorious to Github. Github’s issue sysyem is going to replace Sourceforge’s bug tracking system.

I currently use Github a lot, both for personal projects and for work, and I simply love it. I think it offers the best tools in the market and that’s really important to me.

QJson’s website and mailing lists are still going to be hosted on Sourceforge.

---

I think that’s all from now. If you want more details about the changes introduced take a look at the changelog or checkout QJson’s website.

Some weeks ago, I had the pleasure to do a talk at the openSUSE conference in Prague, about systemd (its current state in openSUSE and what we plan for the future) and dracut (mkinitrd replacement).

For those of you who didn't attend the conference, you can watch my talk on YouTube (thanks to openSUSE awesome video team for the recording):

And you can even get my slides ;)

Maybe some people already expected this to happen, but for me it is still a surprise that I actually did it. I put myself up as a candidate for the openSUSE Board. 

I started the XWT project almost one year ago and athough I talked about it at FOSDEM, I never found the time to formally present it. Those are busy days at Xamarin! Anyway, let’s go ahead.

XWT is an open-source cross-platform UI toolkit for Mono and .NET. What’s special about XWT is that it is built on top of the native widget toolkit of each supported platform. So rather than a new widget toolkit implemented from scratch it is an abstraction that wraps the native toolkits using a common API. The end goal of XWT is to allow building applications which look and feel native in each platform. Here are some screenshots of a sample application running with the GTK and Cocoa backends:

GTK backend

Cocoa backend

I initially created XWT with the idea of building MonoDevelop on top of it. Around this time last year we had a discussion about how we could improve the look & feel of MonoDevelop in Mac and Windows. MonoDevelop is built with GTK# 2, which worked very well on Linux, but which had (and still has) some issues on other platforms. Although GTK is a cross platform toolkit, not all backends have the same quality, and not all features are completely implemented. So XWT would allow us to have a native look and still reuse most of the code. However, rebuilding MonoDevelop with XWT is a lot of work and we needed to fix the Mac and Windows issues as soon as possible, so we decided to invest our efforts in fixing the most annoying GTK bugs instead of going the XWT route.

Even though we are not going to immediately migrate all of MonoDevelop to XWT, at Xamarin we have started using it for some UI code that needs run in MonoDevelop and Visual Studio. An example of this is the Android designer. The designer is implemented in XWT, and we use the GTK backend when running MonoDevelop and a WPF backend when running on Visual Studio:

The designer running on GTK in MonoDevelop

The designer running on WPF in Visual Studio

XWT vs Native Toolkits

At Xamarin we have always advocated for using the native toolkit of each platform in order to take advantage of all features offered by the platform and be able to build the most visually rich and performant applications. How does XWT fit on this idea?

XWT has three important design features:

• User interfaces implemented using XWT can be embedded inside a native UI. It means you can build your application using the native toolkit when you need advanced platform features, and you can use XWT for more simple UI that can be shared.
• XWT backends are built on top of native toolkits, so XWT widgets really look and behave like native widgets.
• XWT is a UI toolkit abstraction, so it’s about abstracting common UI idioms as widgets. XWT will have support for the most common widgets such as entries or buttons, but it will also provide higher level widgets which are more “semantic”. It means that XWT applications will be constrained to use those higher level UI idioms, but each of those idioms can have a platform-specific implementation which takes full advantage of the native toolkit features, and which can abide for the platform UI guidelines. 

There is a tradeoff between portability and functionality. XWT is not for everybody. It wont have the richness and the low level features of a native toolkit, so it will not be suitable for applications which require advanced UI features.

Design Principles

XWT looks like GTK#. It uses a similar layout model and class names. That’s basically to make it easier to migrate GTK# code to XWT, not because GTK# is superior to everything else (although maybe it is). However, there are notable differences. The API design has an important focus on simplicity and usability. Here are some important differences with respect to GTK:

• The widget hierarchy is mostly flat. There is a Widget class and most of other classes directly subclass it. There are no unnecessary infrastructure classes. For example, there is no Container class, any widget can have children if they need to.
• Widgets are visible by default (I still haven’t figured out the reason why they are hidden by default in GTK).
• No concept of GdkWindow. You have a widget, that’s all.

I’m a firm believer of usability-oriented API design. Many libraries are designed using complex class hierarchies and abstractions whose purpose is to make the library code easier to reuse and maintain. That is, the code is designed to facilitate the work of the library developer, not the work of the library consumer. That’s a bad approach since the library will be implemented by only few developers, but potentially consumed by thousands of developers.

Features

Here are some details about what’s currently supported by XWT:

• XWT currently supports 3 backends with different level of development: GTK, Cocoa (Mac) and WPF (Windows).
• XWT can instantiate more than one backend at a time, and run those side by side (with some limitations). For example, you can have XWT use Gtk and Cocoa in the same application, depending on what is hosting your code.
• The basic widget library is mostly complete.
• It has a drawing API, very similar to Cairo.
• There is no visual designer yet, nor any markup language for representing windows. My plan is to use XAML or a simplified version of it.
• XWT can be extended in different ways.
• Applications can create subclasses of XWT widgets, or create new widgets.
• New backends can be plugged into XWT
• Existing backends can be extended
• The API is not yet stable and can change at any time.

Future

The work on XWT will continue, there is still a lot to do. XWT is already already included in the MonoDevelop core. Although we don’t plan to do a big migration effort, we plan to gradually use XWT in the implementation of new features.

If you are interested in XWT, you can get the source code from here:
https://github.com/mono/xwt

There is also a mailing list:
http://groups.google.com/group/xwt-list

And an IRC channel:
irc://irc.gimp.org/xwt

Contributions are welcome!

Like everything, openSUSE is not perfect. Bugs crop here and there, or there is missing / quirky functionality that users may run into. Being a distribution of heterogeneous software, this means that bugs fall into these categories:

• Upstream bugs in the software shipped by openSUSE

• Bugs in the packaging

• Bugs in distribution-specific setups or that derive from interactions with these setups (e.g. kernel, low level software stack, etc.)

To improve the distribution and to act like good FOSS citizens, distribution bugs need to be divided from upstream bugs: the former need to be properly fixed by openSUSE, the latter need to be communicated upstream so that everyone would benefit when they are fixed, including our favorite green distro.

Also, when dealing with bugs, one also runs into bugs that are invalid (local errors, for example), duplicated reports, or already fixed in newer versions.

So, how do we start improving openSUSE, and in particular the KDE part of openSUSE (since that’s what we’re talking about), from the current situation? An effective method is to triage open bug reports, verifying if they can be reproduced, reporting upstream bugs in the appropriate place, and closing off duplicate reports.

And to this aim, we will have a bug squashing session on 15th and 16th November, where you can help with reducing the number of KDE bugreports reported for openSUSE (and we for sure have more than enough of those). If you would like to help KDE in openSUSE, feel free to join.

There are no special technical knowledge requirements except for basics like being able to use the Bugzilla interface at http://bugzilla.novell.com. Having a recent KDE version installed is recommended (use either KDE:Release:49, KDE:Distro:Factory or KDE:Unstable:SC).

On the wiki page at http://en.opensuse.org/openSUSE:Bug_Squashing_KDE we tried to sum up everything relevant (comment and corrections welcome). Please make sure you read the bug screening guidelines at http://en.opensuse.org/openSUSE:Bug_Screening_KDE too.

If you want to help, hop during those days on the #opensuse-kde IRC channel on the Freenode network.

Happy bug hunting!

As announced on the opensuse-kde mailinglist, KDE SC 4.9.3 packages are available from the KR49 repo.

With those packages comes akonadi 1.8.1 which includes a lot of fixes from the recent KDEPIM coding sprint. It should improve performance and more importantly, KDE SC 4.9.3 and akonadi 1.8.1 should solve all known data loss bugs. A special thanks to all the PIM developers putting a lot of effort into improving KDE’s PIM stack!

You can find instructions on how to update on the openSUSE wiki.