• Accountsservice, where the changes are in gitorious for now.
  Status — everything seems to be working, except role path validation.
• Gnome control center (code tarball), where I did the work on the older version that ships with Ubuntu 12.04.
  Status — as of this moment unusable. Setting and getting lockdown profiles for existing users is there, but creating a new user with profile is not functional and some polish is needed for smooth UX.
• The lockdown editor itself (code tarball).
  Status — Totally unusable. Very early prototype.

As a GSoC project it would be hard to call it a success. The main item — the lockdown editor itself — did not materialize.

Pitfalls during the project

• Knowing  a programming language doesn’t help much if you don’t know the libraries. I thought I knew data structures in C, but glibc has its own ideas about everything and this was a new thing to learn.
  Solution — get to know the environment before taking up the task.
• Moving targets. At the beginning of this project, there was just the lockdown editor, now it is a lockdown delivery system, where the editor itself is not really that important. It is hard to stick with a floating schedule.
  Solution — before making a proposal, talk with interested parties and find out what they want.
• Exams and GSoC don’t blend well. One month of the GSoC period was wasted in exams.
  Solution — start working on the project before the GSoC even starts to get some breathing space.
• Working with the cutting edge cuts badly. During the project several times I tried to get gnome-control-center to compile with jhbuild. Most of the time it failed to compile (to get to g-c-c, about 100 modules must be compiled beforehand). The only time it did compile, it crashed and burned.
  Solution — if you are not an expert in the environment, don’t work with master.

In short — don’t just jump in with proposal in the last minute. It will hurt.

Interesting things I learned

• GOTO statements are OK in some situations.
• Code comments are not really necessary. Just read the code and an epiphany will hit you. </sarcasm>
• Sometimes pre-existing code is like math — you don’t understand it, you just get used to it.

Future perspective

For this all to have any meaning at all, these things have to happen:

• distributions must ship with the new accountsservice, which is not even merged upstream (quite likely to happen);
• changes made in g-c-c must be merged in master (should be possible with some pain);
• gdm should support all this lockdown sorcery  (yes, I didn’t mention gdm before, but someone will have to code the support for all this);
• distributions should have the these packages included (like Ubuntu, which just loves to ship the latest gdm. Or was it lightdm? Oh my!</sarcasm>).

In short, these changes will most likely not see daylight in the next round of distribution releases.

Conclusion

By normal project criteria, my project has failed, but in its new form it seems more useful than at the beginning. It is behind schedule, but I expect this to be working as intended in the 3.8 GNOME release.

1. The information about which user has which profile is stored in AccountsService. The newest changes are found in forked repository. It allows basic reading and writing of profile information.
2. I previously hacked gnome-control-center to support different user roles. At the time the back-end wasn’t decided yet, so I now I will update it to get data from AccountsService. This time I hope to get g-c-c to compile with jhbuild.
3. The profiles themselves will be in keyfile format, so they should be easily editable by hand. This should make the lockdown usable even before the lockdown editor itself is made.

A quick overview of things to be done:

• Make a release calendar, to keep translators in the flow of  the software release cycle.
• Give priorities to modules to help new/small teams make the best use of their time and effort.
• Make a policy of deprecating modules and asking maintainers to make a new release when new translations are added to an otherwise inactive project.
• Statistics should be based on words, not strings (still being discussed).
• Increase required string percentage from 80% to 90% for supported languages, but limit the modules which have to be translated.
• Increase participation in outreach programs.

Hi all,
in two weeks the next version of  next-best-thing will be released. This is a great time to update translations.
Cheers!

While most GNOME programs follow the 6 month cycle, the rest of them need to notify us. Many developers already do this (banshee, rhythmbox, gbrainy), but some don’t. The most noticeable example was the release of GIMP 2.8. I waited for years for it, and prepared for the string freeze, and then — out of the blue — it is released!

For those who think that translators should follow Damn Lies, this is not an answer, because:

1. not all of the GNOME stuff is there (getting-things-gnome, inkscape);
2. there is no point in translating active development branch where the strings come and go;
3. it is far easier to translate 100 strings once than 10 strings 10 times.

After the speech “Every detail matter”, I wanted to share some anecdotal experience on quality of software.

When I have to determine quality of software, I don’t have a lot of criteria on which to judge it. List of features and number of crashes plays part in decision, but if basics are covered and it is stable, then how do I choose? A quick list of things, that I believe matter:

• indicator of activities on longer operations;
• polished, consistent UI;
• proper spelling and grammar;
• if translated, translated fully.

Most of these things are covered in HIGs anyway, but my point essentially is — even if software is solid but looks flimsy, it will seem flimsy.

During the previous week I did some gnome-control-center poking, and Ryan (desrt) is pushing to extend account services to support mandatory dconf profiles, group management and such things. The discussions of how [if] this should be implemented are still ongoing. I coded a prototype that gives some idea how it would look to an administrator:
In addition to the Standard and Administrator, there are custom account types in system, and  choosing “Manage” opens a new application that can create/delete/modify types of accounts.

Meanwhile, I am working on the “Manage” part. After talking to my mentor about the most appropriate language for this, I figured I’d write it in Vala. So far all problems I’ve had with it were solved either by reading documentation, or just by assuming it is very closely modelled to C (well, at least when it comes to functions). Alas, right now I have no pretty screenshots to show — only ugly ones — since I am writing backend functions, but I should have something pretty to show this weekend.

While this sounds rather easy, I found out, that jhbuild on Ubuntu system is an uphill battle, so after a some advice form fellow gnome developer, I installed Fedora 17 on my laptop and will see how it will turn out. Right now I am in step 18 of 94 and have no idea, why some sqlite patch is missing.

This is it for now.

I will take my three GNOME hats:

• GSoC student — to meet all those involved in making the lockdown editor;
• translator from the Latvian team — to meet fellow translators and exchange best practices;
• local free software community builder — since I am just starting to do anything in this field, any experience gained will be helpful.

Considering this, I have no idea where will I find a time slot to blog about the event

On a related note, I will visit Akademy (since it is just a few hours’ drive from Riga) and try to find out how the Estonians convinced their government to actively help free software and maybe peek into some KDE stuff, like Lokalize.

As you can see, it is very closely modelled on the old user interface. The basic idea is that the administrator selects a lockdown profile on the left pane and reviews the options on the right pane. I am still reading the HIG and so far the only true problem is that the options are quite negative Also, it does not show dconf profile usage, mainly because I haven’t figured it out yet.

Right now most of the work is  planning — so far pessulus was basically a specialized front end  to gconf, but now we (I and my mentor Ryan) are looking into using  policy-kit for some of the  lockdown options.

My next few weeks will be spent deciding the proper implementation of lockdown and taking the last exams at the university (so my work on Pessulus will go more slowly till the end of June).

So long for now.

• single purpose kiosk — users can see only pages of a particular site;
• Internet access point — users can browse web, save and view downloaded files;
• Classroom — users must be restricted from accessing unneeded material and protected form ruining their configuration;
• Workstation — less restrictive, but something like classroom;
• Home computer for children — similar to classroom.

The features and their default settings for now are organized in feature matrix [PDF]. The list is only a draft and all ideas are welcomed.

I am not sure what to do with non-gnome software, that is using dconf, like Unity. Should it be supported? Also, should other features, that come with lockdown, be implemented? For example:

• quotas;
• resetting home directories;
• resetting configuration;
• lockdown of non-dconf settings like FireFox, LibreOffice.

To me this seems like a feature creep, but maybe this is worth it.