Last week was SUSE's Hackweek 12.
Hackweeks are special weeks at SUSE where all of SUSE Engineering get to work on whatever they'd like, to try cool things and learn new stuff.

This Hackweek was my first at SUSE's Nuremberg office, and it was quite an experience. The whole place had a 'buzz' about it all week. Every day the company sponsored Lunch or Breakfast, which got everyone together and triggered many interesting conversations. Some times we were serenaded by the 'SUSE Band' who were working on their musical abilities and technology for hackweek.

I had lots of conversations about the upcoming openSUSE conference, some of SUSE's planned projects around openSUSE, and of course openQA, which was a big part of lots of peoples Hackweek.

Bernhard Wiedemann worked on adding subtitles to openQA's video recordings so users can see what openQA is doing when it produces the recorded screen output.

Max Lin worked on a chrome extension to provide live status monitoring of an openQA instance and its workers.

Bernhard, Stephan Kulow, and Klaus Kämpf looked at getting openQA to test bare metal hardware.
While openQA already has support for IPMI for bare metal testing of servers, pushing the already established limits is exactly the spirit of Hackweek :)
Bernhard started experimenting with the idea of using ARM development boards to emulate a keyboard and relay openQAs keyboard commands. Next Hackweek he hopes to have a HDMI grabber so it will be able to see the video output also.
Klaus and Coolo were successful in getting openQA to control hardware with Intel vPro/AMT (as found in Thinkpads and other common laptop/desktop hardware). This demonstration video shows it working on my very own X220 Thinkpad.

And Xudong Zhang from Beijing and myself worked on testing openQA by using openQA

Testing openQA on openQA, are you crazy?

Actually, only a little crazy.
We made life easy for ourselves by creating two disk images (one for SLES 12 and another for openSUSE 13.2) to represent the same production environments we have for http://openqa.opensuse.org and the internal SUSE openQA instance.

These images were created following the regular openQA Documentation and setup to test a 'known good' Distribution with a static set of tests (openSUSE 13.2 with the tests and needles from our GitHub project)

We then configured openQA to treat this disk image as a different 'distribution', and we wrote new tests for testing openQA (See the source code HERE)

A little bit of 'needling' later (Capturing the reference screenshots and defining the areas of interest to openQA, which can be found HERE) we had a working test run which was able to test openQA running on openSUSE 13.2

and also for testing openQA on SLES 12

These tests successfully test all the core functionality of openQA, including Upgrading from the official OBS repository, Confirming the Worker is running, Scheduling an openQA job from the shell, Confirming a Job is running from the shell, and checking the functionality of each of the UI Screens by loading up Firefox and clicking on all of the links just like a user would.

With this development, we now have a way of confirming that new builds of openQA are safe for deployment in production, which should help us be a little more fearless and rapid updating the openQA versions in use for testing openSUSE and SUSE Linux Enterprise, even when during heavy testing periods.

Expect to see these tests running on the public http://openqa.opensuse.org soon.. I just need to figure out an elegant way of triggering them automatically as soon as OBS has new RPMs for testing.

Thanks to all who made this Hackweek awesome!

This week is Hackweek 12 at SUSE

My hackweek project is improving GNOME password management, by investigating password manager integration in GNOME.

Currently, I'm using LastPass which is a cloud-based password management system.

It has a lot of very nice features, such as:

• 2 factor authentication
• Firefox and Chrome integration
• Linux support
• JS web client with no install required, when logging from a unknown system (I never needed it myself)
• Android integration (including automatic password selection for applications)
• cli open-source client (lastpass-cli), allowing to extract account specific information
• encrypted data (nothing is stored unencrypted server side)
• strong-password generator
• support encrypted notes (not only password)
• server based (clients sync) with offline operations supported
   

However, it also has several drawbacks:

• closed-source
• subscription based (required for Android support)
• can't be hosted on my own server
• doesn't integrate at all with GNOME desktop

I don't want to reinvent the wheel (unless it is really needed), which is why I spend my first day at searching the various password managers available on Linux and compare their features (and test them a bit).

So far, I found the following programs:

• KeePass (GPL):
• version 1.x written in Java, still supported, not actively developed
• version 2.x written in C# (Windows oriented), works with Mono under Linux
• UI feels really Windows-like
• DB format change between v1 and v2
• supports encrypted notes
• password generator
• supports plugins ( a lot are available)
• support OTP (keeotp plugin, provide 2factor auth through TOTP, HTOP built-in)
• shared db editing
• support yubikey (static or hotp)
• 2 Firefox extension available(keefox, passifox)
• 3 android applications available (one application KeePass2Android supports alternative keyboard, KeepShare supports alternative keyboard + a11y framework to fill android application forms, like LastPass)
• Chrome extension available
• JS application available
• CLI available
• big ecosystem of plugins and other applications able to process file format


• KeePassX (GPL)
• Qt4 "port" of KeePass (feels more a Linux application than KeePass)
• alpha version for DB v2 support
• missing support for OTP
• missing support for keypasshttp (required by firefox extensions to discuss with main application), support is being done in a separate branch by a contributor, not merged
• release are very scarse (latest release is April 2014, despite commits on git, very few people are contributing, according to git)
• libsecret dbus support is being started by a contributor


• Mitro:
• company developped it was bought by Twitter last year, project released under GPL, no development since January.


• Password Safe (Artistic license):
• initially written by Bruce Schneier 
• beta version available on Linux
• written in wxWidgets 3.0 / C++
• yubikey supported
• android application available, no keyboard nor a11y framework usage, only use copy/paste (but allows sync of db with owncloud and other cloud platforms)
• CLI available
• 3 different DB formats (pre-2.0, 2.0, 3.0)
• password history
• no firefox extension and the "auto-type" built-in function is all but intuitive
• support merge of various db


• Encrypt:
• same 0 knowledge framework as SpiderOak
• node-js based


• Pass:
• simple script on top of text files / gnupg and optionnally git (used for history and can also be used to manage hosting the file)
• not easy learning curve (CLI mostly), need gnupg to be setup before usage
• one file per password entry, should make 
• very basic Qt GUI available
• basic FF extension available
• basic android application available

Unfortunately, none of those applications properly integrates (yet) in GNOME (master password prompt, locking keyring when desktop is locked, etc..).

I've also looked at gnome-keyring integration with the various browsers:

• Several extensions already exist, one is fully written in Javascript and is working nicely (port to libsecret is being investigated)
• Chrome has already gnome-keyring and libsecret integration
• Epiphany already works nicely with gnome-keyring
• No password generator is available in Firefox / Chrome / Epiphany (nor GTK+ on a more generic basis)

Unfortunately, each browser is storing metadata in gnome-keyring for password entries in a slightly different format (fields name), causing password entries duplication and not allowing sharing keyring data across browsers.

Conclusions for this first day of hackweek:

• Keepass file format seems to be the format of choice for password manager (a lot of applications written around it)
• Password manager which would fit my requirement is KeePass but is written in Mono (I don't want Mono stack to come back on my desktops) and too Windows oriented, so not an option.
• KeePassX seems to be the way to go (even if it is Qt based) but it lacks a lot of features and I'm not sure if it worth spending effort in adding those missing features there.
• Pass is extremely simple (which would make hacking around it pretty straightforward) but requires a lot of work around it (android, GUI) to make it nicely integrated in GNOME.

I haven't yet made up my mind which solution is the best, but I'll probably spend the following days hacking around KeePassX (or a new program to wrap KP db into libsecret) and Firefox gnome-keyring integration.

Comments welcome, of course.

So, I just reinstalled openSUSE (because the new DEFAULT btrfs borked my system, wont go into that today), and my wifi isn’t working.

Sounds similar to issues described here:
https://forums.opensuse.org/showthread.php/471983-Unable-to-get-wireless-Broadcom-BCM4313-up-and-running
http://lists.opensuse.org/opensuse/2014-12/msg00124.html

Just thought I’d share how I got things up and running.

First off, here were the symptoms:
1. Gnome network manager indicated that the firmware was not installed (even though this is supposed to be included with the kernel now).
2. # dmesg | grep firmware
[ 19.764863] ieee80211 phy0: brcmsmac: fail to load firmware brcm/bcm43xx-0.fw
3. l /lib/firmware/ # (the brcm directory is completely MISSING)
total 28
drwxr-xr-x 6 root root 4096 Apr 7 09:54 ./
drwxr-xr-x 13 root root 4096 Apr 7 09:53 ../
drwxr-xr-x 31 root root 4096 Apr 6 16:52 3.16.6-2-desktop/
drwxr-xr-x 31 root root 4096 Apr 7 09:54 3.16.7-7-desktop/
-rw-r–r– 1 root root 53 Sep 25 2014 E-CARD.cis
drwxr-xr-x 2 root root 4096 Apr 7 09:52 amd-ucode/
drwxr-xr-x 2 root root 4096 Apr 7 09:53 intel-ucode/

To get it working…
1. Download the kernel-firmware package:
http://download.opensuse.org/repositories/openSUSE:/13.2:/Update/standard/noarch/kernel-firmware-20141122git-5.1.noarch.rpm
2. Extract the firmware (installing the package would probably work too).
3. cp -r /home/dmulder/Downloads/kernel-firmware-20141122git-5.1.noarch/lib/firmware/brcm /lib/firmware/
4. modprobe bcma

Now that I stop and think about it…
sudo zypper in kernel-firmware
probably would have fixed it.

The local open source community is bigger now and the next step for you is to organize (or join) global conferences. One part of the organization is the promotion of the conference. You want to have as many visitors as you can.

I will try to write down what I did during openSUSE global conferences and some local events.

BEFORE THE EVENT
0. Web page

There MUST be a web page and a system that accepts registration, paper submission, information etc. Write everything that visitors should know about the conference.
We use OSEM in openSUSE. Check out https://events.opensuse.org

1. Blog blog blog.

You'll have some announcements for the conference. Dates, the place, new website, call for papers announcement, hotels that visitors can stay, schedule, keynote speakers etc. Usually, every open source project has a central blog or news site. You can write the articles there. Try to make fuzz by publishing your articles often.
Global communities can translate the announcements to their language and promote the conference locally.

Local communities are formed by members with blogs who publish on different planet sites. You can make a schedule so everyone can publish the announcement every other day. More eyes will see the announcement and will apply either as speaker or visitor.

Two things you want to have are contributors+visitors and sponsors. If your project is famous, then it's easy. If not, then you better publish the initial announcement to magazines, newspapers, technical blogs-sites. If you don't have access, then you better send it by e-mail or fax and then call them and ask them if they got the text. If they publish it, you're lucky.

Translate those announcements and publish them, so the local population will see that there's a conference coming.


2. Promote to other FOSS conferences

There are plenty of FOSS conferences around the world.
* Community (local or global) has to apply for a booth and/or, if it's possible, present why someone should attend.
* At the booth, you should have promo materials for your conference and give them away to local LUGs or hackerspaces to hang posters at their places.
* Another cool thing is to have free coupons for beer at the conference. If beer isn't the solution, then find another thing that can be found only at your conference and give free coupons.
* Wear special T-Shirts with the logo or #oSC or "Ask me for the conference". You show people that you're organizing something and can ask you questions.
* Finally, go to the other project's booth and invite them. You can ask them if they want to have a booth at your conference or apply for a presentation.


3. Messages to post

Create a list of messages you'll post to social media.
First of all, you should post the announcements.
Then create a list of general messages that you should post before the conference. Content will be related to the subject of the conference or the country etc.
When you have the schedule ready, create a post with the name of the person (mention him/her on social media), the title of the presentation (mention if it's a famous project).
The messages can be 2-3 per day but not at the same time. Try to have a 4-5 hours time delay between tweets.


4. Twitter

Create a twitter account that will be used for the conference. Everyone can use it as a hashtag (#) and also can communicate with you before and during the conference. For openSUSE, we had #opensuseconf as a hashtag. The account was @opensuseconf
The same account can create the Lanyard event (you'll see next).

5. Facebook event page

Create a Facebook event page under the official account of the project. Post the tweets here as well. Post the messages (no 2). If you have some cool documentation of the subject that will be presented, just post it.

Since the address will be difficult to remember, create a subdomain under your project's name (eg facebook.conference.opensuse.org) that will forward it to the event page.

6. Google Plus event page

Do the same as facebook. Some people hate to use facebook, so google plus is the solution. Do the same also with the URL.
Google Plus event notifies to e-mail every user about changes. So if you post, they'll get a notification.

7. Lanyard event page

This isn't very famous but it's very cool. It uses twitter accounts. You setup the event and when you have the schedule, you can add the subject and mention the speaker. You can also use it to post announcements.
Here is the lanyard of openSUSE conference 2014

8. Meetup.com event

If money is not an issue for your project, you can create an event at http://www.meetup.com

9. IRC, mailing lists, forums

You have to create an IRC channel where you reply to all possible questions. There's also a mailing list for that.
To promote the conference, you should post the announcement to mailing lists, forum of all possible projects (eg if we're openSUSE, then post to GNOME, KDE, ownCloud etc). And try to inform the posts with the new announcements.


10. Flickr

Create a group where people can upload their pictures, so everyone who blogs can use those pictures. You can create it before the event starts and post pictures from the venue before you set it up.


DURING THE EVENT
1. Messages to post

Create a document with messages to post with all the presentations. The message has to be:

Presentation title (with mention) @ #Room_name. Not @ #oSC15 #openSUSE? Live @ Stream_URL

Create a table. Columns will be the rooms, rows will be the timetable. So you'll check the time and post the right one.

WARNING: Check with the program team if there was a daily change of the program. Also, check the right Stream URL.


2. Twitter

Here you start posting the messages per time. Don't forget the mentions to people, projects, and the #. Here you mention someone by using @username.


3. Facebook event page

Same as Twitter, don't forget to mention. Here mention is with @Project name. Here you can use more characters than twitter. So here you can also add the hashtag of your project (eg #opensuse, #opensuseconf)
Ask people to upload pictures here. Also ask people to post their reports.


4. Google plus event page

Same as Twitter, don't forget to mention. Here mention is with +Project name. Here you can use more characters than twitter. So here you can also add the hashtag of your project (eg #opensuse, #opensuseconf).
Again, ask people to upload pictures here. Also ask people to post their reports.


5. IRC

You can post here as well. Some people didn't join you or they just see live streaming and use IRC to ask the speaker. So it'll be nice if there’s a program of what's in every room with the streaming URL.


6. Streaming

The social media guy is responsible to handle all the above. He checks if the streaming is working and if not, then warns the video team. It's good for him because he can see all presentations but it's kind of "I'm locked somewhere and I don't mingle with people".
Users who didn't make it can see the conference over the Internet.


7. Flickr

Try to gather all pictures and upload them in the afternoon, so everyone who wants to blog can use the pictures from there (there are Google Plus and Facebook events as alternatives). It's very cool if the pictures are up very soon, so everyone can view them.

Recently I passed a magic number with my ownCloud in a box appliance. It hit the five fives, 55.555 total downloads, on SUSE Studio. It is the most popular download there. I would never have imagined that so many people would be interested in it and use it when I started with this. Amazing.


When Frank started to discuss the idea of ownCloud and announced it at Camp KDE five years ago (another five, hooray) I was immediately intrigued. The idea of giving people control about their data in the cloud was powerful. Over the years it actually has gained even more power and relevance, as not only the cloud has become ubiquitous but also the threats to abuse it.

With SUSE Studio it became so easy to build easily deployable images for a broad variety of targets, such as a live CD, a VMware image, or an installation disk for a physical machine, that I just had to do it. It follows along the philosophy of ownCloud to make it as easy as possible to run it, so many people can do it on their own. ownCloud in a box is an easy way to try it and get started.

I'm looking forward to the next fives, whatever they will be. ownCloud has great success, and its development is coming along nicely, but I would still like to see some more things.

From a technical point of view, client-side encryption would allow to use a hosted ownCloud without having to trust who is hosting the server. That would extend the benefit of controlling your data in the cloud to a whole new group of people, who can't or don't want to run their own server. There is some work going on in this area. Let's see where this goes.

From a community point of view it would be great, if the contributor agreement would be a bit more fair towards contributors. It's quite asymmetric. You broadly give all rights on contributions to ownCloud Inc. but only get back what you would get anyway by publishing your code under the AGPL. I understand that this enables the ownCloud Inc. business model, and that a successful company is good for the community. I also have no doubt that the company is operating with the best intentions for the community. But if there needs to be a formal agreement, it would be nice if it would better take into account the interests of both sides. I'm sure there would be ways how to do that without jeopardizing the business model.

In general I'm very impressed with how far ownCloud has come, and I'm happy that I could contribute my little part in it.

Today I have two announcements to make.

First, the version 0.9.1 of the Ixion library is now available. You can download the 0.9.1 source package from the project’s main page.

This is purely a maintenance release to address portability problems in the python bindings as well as other minor build and packaging issues. Many thanks to David Tardon for single-handedly addressing these issues.

Now, here is the second announcement. We are officially moving the project’s home from the previous Gitorious one to the GitLab’s, following the announcement of the acquisition of Gitorious by GitLab and the imminent shutdown of the Gitorious hosting site resulted from the acquisition. The new official URL for the Ixion project will be https://gitlab.com/ixion/ixion. If you need to include an URL to the project, please use the new one from this point forward.

Thank you, ladies and gentlemen.

A lot has been happening on the KDE side of openSUSE… this post summarizes what’s been going on so far.

Live media for Plasma 5

One of the most-often requested ways to test Plasma 5, given it can’t be coinstalled with the 4.x Workspace, is the availability of live images to test either in VM or bare metal without touching existing systems.

Given that other distributions started doing so since a while, naturally openSUSE couldn’t stay still. ;) Thanks to the efforts of Hrvoje “shumski” Senjan, we have now live media available for testing out Plasma 5!

• Download location: the ISO file you’re looking for is called openSUSE-Plasma5 (currently x86_64 only)

The image is based on the current Tumbleweed and takes the latest code from git. If you test this in a virtual machine, bear in mind that there are some issues with VirtualBox and Plasma 5, and that QtQuick’s reliance on openGL can cause problems in general with virtual machines.

And if you find a bug… if it’s in the core distribution, or in the KDE packaging, head over to openSUSE’s Bugzilla. If it’s instead in the software, the KDE bug tracker is your friend.

Questions? Head over to the opensuse-kde ML, or the #opensuse-kde channel on Freenode.

Plasma 5 as default in openSUSE

You may have read on a recent Softpedia article that Plasma 5 is going to become the default in openSUSE. That’s correct (what did you expect, a retraction? ;): I and the others of the team (Raymond and Hrvoje) have been using Plasma 5 for a long time, not only because we like to stay on the bleeding edge ;) but also to see how it would fare for openSUSE. In the mean time, we reported bugs, sometimes fixed them, and occasionally landed one or two features in.

With the upcoming Plasma 5.3, we feel that it is of the level of quality expected from the default openSUSE desktop, and therefore we have set up preparations for the switch. As Rome wasn’t built in a day, it won’t happen straight away ;) but it will involve changes in the repositories and in the packaging, which are summarized below:

• We will start the migration around the end of April, as long as the basic openQA tests are ready;

• We will release KDE Applications 15.04 in Tumbleweed at the same time;

• The KF5 ports of the applications present in KDE Applications 15.04 will obsolete their existing counterparts (hence the KF5 version will replace the 4.x version).  The same will happen for the kdebase4-workspace and Workspace 4.x packages;

• Afterwards, the 4.x Workspace will not be supported or maintained for Tumbleweed. Help from the community is welcome in case anyone wants to step up and maintain the packages.

• The default menu applet will be Kicker (as opposed to Kickoff used in the 4.x tiems;

• The default theme for Plasma 5 will be Breeze (the upstream default), and we will use the menu structure provided by upstream KDE (as opposed to the custom structure we use today);

• The repository layout will change. We will have three repositories holding KDE software:

  • KDE:Frameworks - the KF5 libraries and Plasma 5;
  • KDE:Applications - KDE Applications releases
  • KDE:Extra - Other KDE/Qt related community packages.

• For each of these repositories, there will be also an “unstable” variant, tracking the current git master state.

(The full IRC log of the last meeting outlines these points in detail)

There are still some points open for discussion, in particularly for the update applet: should we keep Apper? Would Muon be a drop-in replacement? Or are we better off without an applet at all?

Of course, input  and help from the community is welcome. Hop on IRC or on the ML (see above for where to look)  if you want to help and participate in this large transition.

Heute habe ich Kraft Version 0.58 freigegeben. Download.

0.58 ist ein weiteres Release, das Fehler in der Kraft 0.5x Reihe behebt. Es wurde ein Fehler bei der Berechnung der Mehrwertsteuer auf den PDF-gerenderten Dokumenten behoben. Ausserdem kann jetzt der Schrägstrich (‚/‘) in Nummernkreis-Vorlagen verwendet werden, was vorher zu einem Fehler geführt hat.

Ausserdem habe ich den Build-Prozess etwas aufgeräumt und die kraftcat Bibliothek entfernt. Die Dateeien werden jetzt auch direkt mit Kraft gebaut.

Die Bibliothek hatte nie eine öffentliche API und war nie stabil, so dass sie auch nicht ausserhalb von Kraft verwendet wurde. Paketieren von Kraft ist damit einfacher und standardkonformer.

Ein Update auf Version 0.58 wird für Produktionssysteme empfohlen.

This is not about KDE e.V.'s new time travel program. This is about Plasma and its concept of Activities. They have been a topic of hot debates. Some people love them, some don't care. Björn called for finding a new metaphor which better fits the mental model of the user, so that Plasma's activities can appeal to a larger group of people. Here are my thoughts.

Orthogonal or hierarchical?

The premise of Björn's quest for a new metaphor is that the current one doesn't fit the mental model of the people using activities, especially how activities are related to virtual desktops. He sees activities not as an orthogonal concept to virtual desktops, but as an hierarchical one.

Matching the mental model of the user is crucial, because this defines how natural and easy it is to use them. You can learn abstract concepts and be trained in creating new mental models or in using rules to work with concepts without having a good deeper understanding. But this needs time and effort, which especially casual users are rightfully not willing to spend. And it's not fun.

Orthogonal concepts are independent of each other, they live in different dimensions, you can use one without affecting the other. Hierarchical concepts use the same dimension, but there is an order, one concept is above the other, such as one providing a grouping for another.

You could see activities as independent of virtual desktops, and that's how they are implemented. But there is one issue with that. The presentation we use addresses the same mental model, that of areas arranged in space.


That makes it hard for the user to know where things are. Does the screen present an activity or a desktop? Do I have to change the activity to go to my email client or do I have to switch desktops? When I go to the left or right, do I change activities or desktops? You can learn the concept of activities to be able to answer these questions, but if you use the same mental model for activities and desktops it can appear confusing and inconsistent.

I think there are two ways to address this issue. One is to clearly express that the concepts are orthogonal in the user interface and the naming. The other is to make activities and virtual desktops fit into the same mental model by clearly separating their responsibilities, and eliminate the metaphors which use the same mental model for different parts of functionality.

Time

One powerful way of expressing the orthogonality of activities and virtual desktops would be to represent virtual desktops in space and activities in time. These are two different dimensions, and it actually would go quite naturally with what the two concepts represent.

Virtual desktops are different segments of the space of your desktop. They are usually arranged in a plane and there is a relation of left/right and above/below. Desktop effects support this model by providing spacial transitions when switching desktops.

Activities are less about where you do something but about when you do it. They represent projects or different times of your usage of a computer. You program as part of your job in your IDE in the morning, browse the web and watch YouTube movies in the evening, and once everybody else is sleeping you play a game. You use different applications at different times, need different configurations of your desktop, and there is a relation of before/after between these.

To express this in the UI the activity switcher and configuration should not use concepts of space which overlap with how virtual desktops are presented. The closest idea I have seen is the activity switcher in Plasma Active. This uses a different and specific mechanism to switch activities. It even vaguely resembles a clock with its circular movement of activities when browsing through available activities, expressing the concept of time.

Screenshot from contourproject

When going with this mental model and the corresponding metaphors, suitable names for activities and virtual desktops could be "times" and "spaces".

Space

Following the idea of a hierarchical relationship of activities and virtual desktops we could represent them using the same dimension, but express activities in groups of virtual desktops.

Here is a mockup illustrating this idea:


Activities would control how groups of virtual desktops would behave. They would be used to define what wallpaper and which desktop widgets to show, what applications to start or stop, what settings for notifications or power saving to use, etc. All this would be tied to on what virtual desktop the user is. But there wouldn't be two different ways how to switch between desktops and activities, but there would only be one. Activities would implicitly be switched by switching between virtual desktops.

So when you are at work you would be on the left side of your desktop with your corporate wallpaper, running IDE, web browser, what you need for work. The right side of your desktop with the games would be shut off. For a presentation you would go to the desktop which switches off notifications and power saving. Email would be there as a shared resource all the time. In your free time you would be on the right of your desktop, with nude pictures of your cat as background, running inappropriate videos in your web browser, and switching off everything else than your games for maximum frame rates. Or something like that...

In some way activities would be a subset of virtual desktops and in some other way they would be a configuration for a virtual desktop. This follows along the lines of the "Different widgets for each desktop" configuration option, where each virtual desktop more or less gets its own activity.

The hierarchy would not strictly be activities above and desktops below, but there would be two concepts, the group above the desktop, and the configuration below the desktop.

This would need a few changes in representation of activities and virtual desktops, but it could better match the mental models of users, because concepts are clearly separated and existing understanding of controls can be used.

When going with this mental model and the corresponding metaphors, suitable names for activities could be "desktop groups" and "desktop configuration", and virtual desktops would just remain "desktops".

Conclusion

Naming is important, but even more important is expressing concepts clearly and unambiguously. In the user interface behavior and visual representation trumps names. That said, for talking about the concepts, especially in code and documentation, good names are essential.

To me seeing activities as configuration of groups of desktops is most natural. That matches my mental model.