Planet Ergo

As I'm addicted to using Alt+Tab to switch between open application windows, you can imagine that in GNOME 3, where Alt+Tab only switches between grouped applications (read: two open terminal windows are grouped) is... a little different. You would go to that terminal application icon, and then a little downward arrow would indicate multiple windows had been grouped.

If you were to release Alt at that point, you would be presented with the window from that group you last opened.

I had been using the arrow keys to navigate to the window I actually wanted (down to expand group, left-and-right to select window), but now I have a new thing to get addicted to.

I just discovered this magic key-combo, so I'm pleasantly surprised and I didn't want to withhold all that positive energy from you; Alt+`

Go fetch!

Lydia and I have decided on a mechanism to learn Spanish. First things first, it's crucial we vastly increase our vocabulary.

Every week, starting this week (#2, 2012), we point at objects, think of activities, just tell eachother the time, every day life if you will, up and until we collect 50 or so, and find the Spanish translation.

Then, at the end of the week (this is going to be the exercise over the weekend) we learn those ~50 translations and start talking jibberish - It'll be a mixture between Spanish, Dutch and English, I imagine.

The more words we learn, as our vocabulary grows, the more we are (going to attempt) to actually speak Spanish. We should thus be able to learn about ~2.600 translations a year, and while our pocketsize translation dictionary holds about 37.000, we should be OK for the next decade and beyond :P

I recently, very recently, purchased a Lenovo X220, fully beefed up with an i7 processor, 8GB of RAM, and the largest SSD (Intel 160GB), amongst other things.

Installing Fedora 16 (of course) went smooth (as was to be expected, as I know other people with Lenovo X220's). It's nicely locked down now, with startup, BIOS, GRUB passphrases, limited boot devices (SSD only) and an encrypted VG -which I can afford doing now without slowing down the entire system too much.

As a Kolab Systems employee, running multiple Kolab servers, naturally I install Kontact, the Kolab client, and I tend to do this using a fresh install (i.e. no copying data from the old laptop, no upgrading).

Fedora 16 includes a 4.7.4 KDE PIM stack, which turns out to not work for me. Having configured the Kolab accounts, it seems I cannot get to the messages in my Kolab INBOX -other folders work just fine.

In any case, I decided to try rawhide; the version of the KDE PIM stack included in rawhide at this moment is 4.7.95, KDE's latest release en route to 4.8 - this too, however, did not work for me.

So, I decided to try and build from GIT - my first time ever. KDE has a utility for this, called kdesrc-build. It's use is pretty straight-forward, but I had to install some build requirements on my system. This is what I have installed now:

# yum -y install \
    alsa-lib-devel attica-devel avahi-devel boost-devel bzip2-devel check-devel cups-devel \
    cyrus-sasl-devel dbus-devel dbusmenu-qt-devel enchant-devel fontconfig-devel \
    freetype-devel gamin-devel gettext-common-devel gettext-devel giflib-devel \
    glib2-devel glibc-devel glib-devel gnutls-devel gpgme-devel grantlee-devel \
    gstreamer-devel gstreamer-plugins-base-devel herqq-devel ilmbase-devel jasper-devel \
    kdebase-workspace-devel kdelibs-devel kdepimlibs-devel keyutils-libs-devel krb5-devel \
    libacl-devel libattr-devel libcom_err-devel libdrm-devel libgcrypt-devel \
    libgpg-error-devel libical-devel libICE-devel libjpeg-turbo-devel libpng-devel \
    libselinux-devel libsepol-devel libSM-devel libstdc++-devel libtasn1-devel \
    libudev-devel libutempter-devel libX11-devel libXau-devel libxcb-devel \
    libXcomposite-devel libXcursor-devel libXdamage-devel libXext-devel libXfixes-devel \
    libXft-devel libXi-devel libXinerama-devel libxkbfile-devel libxml2-devel libXpm-devel \
    libXrandr-devel libXrender-devel libXScrnSaver-devel libxslt-devel libXt-devel \
    libXtst-devel libXv-devel libXxf86misc-devel libXxf86vm-devel mesa-libGL-devel \
    mesa-libGLU-devel mysql-devel OpenEXR-devel openldap-devel openssl-devel \
    pcre-devel phonon-devel polkit-devel polkit-qt-devel PyKDE4-devel PyQt4-devel \
    python-devel qca2-devel qt-devel qt-gstreamer-devel qtwebkit-devel raptor2-devel \
    shared-desktop-ontologies-devel sip-devel soprano-devel sqlite-devel strigi-devel \
    xorg-x11-proto-devel xz-devel zlib-devel

Consider installing the "Fedora Packager" group as well;

# yum -y install @fedora-packager

After following the setup instructions, you should first initialize your copy of the various sources (otherwise failures would cause you to need to manually cleanup subversion repositories, for example):

$ kdesrc-build --src-only

This, when you run it for the first time, can take quite a while.

Once it's done, you can start building stuff:

$ kdesrc-build

This, too, can take quite a while. Furthermore, it requires a lot of energy, and drains my 7.5 hour battery life in about 90 minutes ;-)

UPDATE^1: The build dependencies for gwenview need to be added to the list of build requirements; exiv2-devel.

I was watching this documentary I don't recall the name of. I remember recognizing Stephen Hawking though, which is one of the reasons one of the statements made in the documentary caused me to raise my eyebrow and question the rationale put forth.

Summarizing, the narrator said that in essence, no time exists inside (close to?) a black hole. A clock that would travel into a black hole would stop ticking, or so the audience were told. I suppose it's fair enough to reason time no longer exists inside a black hole, though from where I am sitting -no astrophysics background whatsoever- it sounds like quite the assumption.

Anyways, it was argued that the Big Bang itself, the event that supposedly caused the universe to exist as we know it (even though we know very little of it), was some sort of black hole imploding on itself.

It was then argued, that, therefore, no time existed before the Big Bang. The documentary further argued, that since no time existed before the Big Bang, it was therefore impossible for some sort of grand designer to have existed, let alone create the universe.

Now, I'm not exactly in favor of pointing to a grand designer that created it all, but this documentary narrates flawed reasoning for such grand designer to not have existed.

The link that is being drawn between one type of black hole (the ones we think we have in our universe, that exist with surroundings, in which time exists) and another type of "black hole" (the one we can only speculate about, for which it is assumed no surroundings existed, in which time could have existed), in that in each type of black hole, no time exists nor existed, neglects the fact that outside of such black hole, surroundings may exist or may have existed, other localities if you will, in which thus also time may have existed. It's not like current black holes cause time to not exist anywhere outside of it, right?

What is referred to as 'condstore' is actually the feature-set that IMAP4Rev1 extension added in RFC 4551. It enables the quick synchronization of flags on messages as well as other conditional STORE operations.

I'm going to have to refer you to the RFC for the full details, but suffice it to say your Kolab 2.3 deployment could greatly benefit from enabling said extension on your mailboxes - it is not enabled by default as part of Cyrus IMAP 2.3, only with Cyrus IMAP 2.4 is the 'condstore' annotation set to 'true' by default.

You will have to execute two separate actions on your Kolab server:

1. Configure new mailboxes to have 'condstore' enabled by default,
2. Configure current mailboxes with 'condstore' enabled.

You would preferrably execute these actions in this order, to reduce the chance new mailboxes are being created while you have not yet switched on 'condstore' to be enabled by default.

Enable 'condstore' by default

To enable condstore by default, in your favorite editor, add the following line to /kolab/etc/kolab/templates/imapd.conf.template:

mailbox_default_options: 2

Afterwards, write out new templates and reload Kolab with the new configuration;

/kolab/sbin/kolabconf

Enabling 'condstore' on existing mailboxes

To enable 'condstore' on existing mailboxes, login to Cyrus IMAP using the cyradm utility:

cyradm -t "" -u manager localhost

From there, you can examine one of the existing mailboxes;

localhost> info user/john.doe@example.org
{user/john.doe@example.org}:
  condstore: false
  duplicatedeliver: false
  lastpop:  
  lastupdate: 12-Sep-2011 17:56:54 +0200
  partition: default
  pop3newuidl: true
  sharedseen: false
  size: 105382261
  folder-test: true

As you can see in the example, condstore has not yet been enabled for this mailbox. To enable condstore for a particular mailbox:

localhost> mboxcfg user/john.doe@example.org condstore true

You will not want to repeat this command for all mailboxes, but instead use wildcard matching:

localhost> mboxcfg user/*@example.org condstore true

NOTE: The two commands do not return any output.

NOTE^2: Don't forget to, at your option, also enable condstore for mailboxes in the shared namespace, in other authentication realms, and perhaps even for those mailboxes that reside in the DELETED namespace (just in case they are restored to a visible namespace later on in life).

First of all, Bron Gondwana has done a great job over the course of a number of releases, to resolve some of the bugs in Cyrus IMAP that may have been around for quite a while -though most of them you may not have noticed.

Since Cyrus IMAP has been around since 1993 (give or take), it inherently contains legacy implementations of features or required functionality, sometimes to the tune of "good enough". Seeking further compliance with IETF approved RFCs and allowing for further development has spawned a 2.4 software series, with large amounts of code refactoring and cleanup, and the addition of some interesting features -more on those later.

Just this week, the Cyrus IMAP team has released cyrus-imapd-2.4.10.tar.gz. One day later, I've submitted the build to Fedora rawhide, so it should be hitting your doorstep soon enough. I plan to follow up on releases upstream with packaging more quickly and more agile in the future. Yours truly being the Release Engineer for Cyrus IMAP & SASL, as part of my work for Kolab Systems, I like how we have established a culture of release early, release often within the Cyrus IMAP project, and how core developers like Bron can make releases happen almost autonomously, while in between the last version in the 2.3 product series and the first version of the 2.4 series, a good couple of years had past.

Further endeavors include our 2.5 roadmap (which I admit could use some love), documentation (which I work on) and of course testers and developers are always welcome!

In the Cyrus SASL realm, we're working to convert the CVS repository to GIT. This takes a long time, since like Cyrus IMAP, Cyrus SASL has been around for quite a while. I must say we have done our due dilligance over the past few months on this one though, so I expect the repository conversions to GIT I've been doing to be approved soon enough.

Using GIT for the Cyrus IMAP codebase has proven to be a lot more attractive to a lot more contributors (since they can now create their own working copies and collaborate on those), and I hope we achieve the same level of success for Cyrus SASL.

I'm having a great time at FUDCon in Panama. For one, the weather is much better then back in Wales... :P Parties are at the villa of les Chiles Loco (the crazy Chileans), and last untill about 3am in the morning. Plenty of beer and plenty of barbeque steak usually do the trick for me :)

My first session on Thursday, titled "Why You Are All Idiots", was post-poned because someone from Dell needed to have his session on what seems to have been the busiest FUDCon day so far. Irony has it, the talk was on "Virtualization with KVM", and while my schedule was freed up, I went to assist Dell Panama with their KVM / Live-migration demonstration setup they were going to show on Friday :)

So, after all, my first session was on Friday, and on "Cloud", following two other presentations on virtualization, and the second was on "Software, RPM, Packaging, Guidelines and Build Systems... but why?", starting off in a small series of talks on packaging and the koji build system.

Other people are having many interesting talks as well -but in Spanish. Since I only hablo pocitto espanol (and that's about it), it is sometimes hard to follow. For most of today -outside of my "Why You Are All Idiots" and two lightning talks, I've been working to get a working GNOME3 desktop environment on my laptop.

Looking forward to FUDPub.

Please allow me to describe my day of travelling yesterday;

Having woken up at 05:30am ET, I started at Detroit airport, as I just so happened to be in the area already. From Detroit, a Continental (now United) flight to Newark (oops, high building, zig, oops, high building, zag, touch-down). Short layover, continued my trip to Miami -from the air it looks much like in the CSI series.

Note to self: do not wear black shoes, black trousers and a black T-shirt when travelling through Miami as you have to go outside to the designated smoking area which has no shaded area anywhere near it.

From Miami, I had an endurable Copa flight to Panama City, where immigration lines are as bad as they are in the U.S. Alejandro picked me up, dropped me off at the hotel, and took me back to Cuidad del Saber, where I met up with the rest of the guys -about 18 hours after I started.

One too many beers and a barbeque later, Alejandro drove me back to the hotel for some well-deserved, long-needed rest.

Today, I've been preparing some of the sessions I'm going to pitch or try and squeeze in the schedule, including but not limited to the following titles;

• Cloud
• Why You Are All Idiots
• Software, Packaging, RPM, Guidelines, Build Systems... but why?

I suppose other sessions I could/should also be doing are on Spins, Fedora Trademark / EMEA / NPO, Extended Life-cycle Support, Configuration Management with Puppet and Fedora in the Enterprise. I can pitch'em all, but I'll have to see which ones actually make it on the rather tight schedule ;-)

Applications that we integrate with Kolab Groupware have a genuine need for caching. But what is it exactly that causes this need for caching?

Why Does One Cache?

Let's first think about why one caches in the first place. Caching is usually implemented to eliminate a bottleneck and boost performance. Data can then be obtained from the relatively quick cache -it is "close by", and it usually understands and is optimized for some form of querying- as opposed from the relatively slow original source of the data.

With Kolab, using Cyrus IMAP as the backend storage for all groupware related information like Email, Events and Contacts, it can hardly be argued the IMAP server does not perform up to specifications. Cyrus IMAP is extremely fast and scalable; it is, arguably, just as lean and mean as a cache would be.

So, Where's the Bottleneck?

Yet, the following topology does introduce and work around a bottleneck, seriously impacting and later improving performance. I'm off to explore what exactly is the bottleneck, and how to work around it.

We'll use Z-Push (Free Software ActiveSync implementation) in a regular, current scenario workflow as an example. The following happens, justifying caching, when a mobile device requests synchronization;

1. The 3rd party application connects to Cyrus IMAP to retrieve "the information". Since not all folders may need syncing, and some folders contain Email while others contain Events or Contacts, a list of IMAP folders needs to be obtained.
2. Cyrus IMAP, its efficiency in this matter aside, interacts with the mailbox storage to retrieve certain information from its mailbox database, its annotations database, the message files, etc.

Using the IMAP protocol, this means;

• Listing the folders the user is authorized for.
• Iterate over the list of folders and retrieve the following annotations for each folder:
  • "Should this folder be synchronized with the mobile device at all?"
  • "What type of groupware items does the folder contain?"
• Then, excuse my paraphrasing, on a per IMAP folder target basis, the changes that may or may not have been applied on the mobile device, need to be compared with the changes that may or may not have been applied in the IMAP folder, and vice-versa. Retrieving changes, messages, parsing them, and comparing them, and applying the changes on either end, while tracking which changes have already been communicated to one or the other end of the synchronization exercise.

Naturally, the last step is what Z-Push is in charge of, in this example. and It does have certain characteristics and interactions with Cyrus IMAP as well as with its own caches to optimize the performance, scalability and user experience.

The former notwithstanding, this is just one application integrated with Kolab responsible of maintaining its own cache. In current generations of Kolab, Horde Webmail does the exact same but using a different cache, and future generations of Kolab will include RoundCube, which again also maintains its own cache.

One Cache per Application?

Maintaining a cache per 3rd party application integrated with Kolab isn't necessarily the most sustainable route to go. Feasible? Yes. Sustainable? Perhaps not. Let's take one step back and look at the bigger picture again;

Presumably, the interaction between Cyrus IMAP and its storage can not be optimized further (which the dotted double arrow is supposed to indicate). Not without intrusive changes at the very least, that is to say, while admittedly I'm unaware of our options to further increase performance in this part of the flow of information. If you have ideas and the necessary experience, let me know and I can get you hooked up.

It is, perhaps, the IMAP protocol used in between the Cyrus IMAP server and the 3rd party application that is the bottleneck. For example, Z-Push cannot do the following over IMAP, eliminating a number of iterations and sequences issuing IMAP commands;

SELECT folder FROM folders
    INNER JOIN annotations ON folders.id = annotations.folder_id
    WHERE annotations.key = '/vendor/kolab/activesync' AND annotations.value = 'true';

Hey, this does somewhat represent what it does against the cache it maintains, having obtained the information over IMAP once (slow) it uses its cache to obtain the information (fast) in a number of subsequent synchronizations -limited to an expiry interval, expiring and updating cache, of course. This builds us the following picture, where IMAP is "slow" for the task at hand, and SQL is fast;

Ignoring the interaction that Cyrus IMAP requires with the filesystem as being a negligible performance penalty, and focussing on how the 3rd party application wishes to optimize performance, apparently it would rather perform caching (cheap), then it would want to interact over the IMAP protocol (expensive).

Suggestion #1: One Cache To Rule Them ALL

It has been suggested, since most if not all of the 3rd party applications integrated with Kolab would require some form of caching, we create "one cache to rule them all";

Although probably this is in fact entirely feasible, the following constraints to such architecture come to mind;

• Session reliability and personal information security, complex to implement but even more complex to audit, and implemented up to specifications with IMAP ACLs already,
• Duplication of ((a significant) part of) the data,
• Abstraction from caching required in all 3rd party applications, each of which has their own already (i.e. significant development effort right from the start, and continuous development effort for more 3rd party applications to integrate with Kolab Groupware), and one uniform caching specification across all of the 3rd party applications (i.e. significant design complexity).

We (within the Kolab community) regularly refer to the "one cache to rule them all" as "server-side akonadi" - currently the very efficient client-side (offline) caching in our primary smart client, Kontact.

Suggestion #2: Maintain Cyrus IMAP Databases in Networked SQL

It has also been suggested (by me, in fact), to have Cyrus IMAP use database formats other applications within a Kolab Groupware deployment could read from. By having Cyrus IMAP maintain its mailbox, annotations and perhaps even mail folder indexes and caches in a database format like SQL (instead of Berkely or skiplist), these would become available to the 3rd party applications without them having to populate the cache first, and the cache would be updated "automagically"; as a result, the level of interactions with Cyrus IMAP over the "inefficient" IMAP protocol would be further reduced -"inefficient" for the task at hand, that is.

However, this would greatly impact the scalability of Cyrus IMAP. It would, in fact, greatly impact the overall performance of Cyrus IMAP as an IMAP server. It's a valid option, but not considered feasible targetting for because of the projected performance penalties.

Suggestion #3: Use Cyrus IMAP

If you agree it's fair to label having to use the IMAP protocol to get to the data required as the bottleneck, here's the suggestion I have in mind; Add a thin, lean and mean, network-enabled, read-only C application to interface between the 3rd party applications and the Cyrus IMAP databases (on the filesystem), thus enabling the 3rd party applications to use a different protocol or querying language to obtain the data in a more efficient manner. Perhaps this would look as follows:

Benefits would include many requirements have already been implemented; Locking, networking, database maintenance, threading, thread safety, TLS/SSL, access control though IMAP ACLs and its handling and more of that stuff. The new application could, presumably, also maintain its own caching capabilities to be even quicker.

Just some early Saturday morning thoughts... let's see what the rest of the weekend brings.

Turns out the LDAP module for Python breaks the API while developing version 2.4 -with no backwards compability, but a workaround is relatively easy. If, like me, you need to be able to run code on platforms traditionally "slow" in adopting the latest and greatest, as well as those that are traditionally, relatively "fast", here's an idea:

# Catch python-ldap-2.4 changes
from distutils import version
if version.StrictVersion('2.4.0') <= version.StrictVersion(ldap.__version__):
    LDAP_CONTROL_PAGED_RESULTS = ldap.CONTROL_PAGEDRESULTS
else:
    LDAP_CONTROL_PAGED_RESULTS = ldap.LDAP_CONTROL_PAGE_OID

class SimplePagedResultsControl(ldap.controls.SimplePagedResultsControl):
    """

        Python LDAP 2.4 and later breaks the API. This is an abstraction class
        so that we can handle either.
    """

    def __init__(self, page_size=0, cookie=''):
        if version.StrictVersion('2.4.0') <= version.StrictVersion(ldap.__version__):
            ldap.controls.SimplePagedResultsControl.__init__(
                    self,
                    size=page_size,
                    cookie=cookie
                )
        else:
            ldap.controls.SimplePagedResultsControl.__init__(
                    self,
                    LDAP_CONTROL_PAGED_RESULTS,
                    critical,
                    (page_size, '')
                )

    def cookie(self):
        if version.StrictVersion('2.4.0') <= version.StrictVersion(ldap.__version__):
            return self.cookie
        else:
            return self.controlValue[1]

    def size(self):
        if version.StrictVersion('2.4.0') <= version.StrictVersion(ldap.__version__):
            return self.size
        else:
            return self.controlValue[0]

Example Usage

Where 'self.ldap' is the LDAP object;

    def _search(self,
            base_dn,
            scope=ldap.SCOPE_SUBTREE,
            filterstr="(objectClass=*)",
            attrlist=None,
            attrsonly=0,
            timeout=-1
        ):

        _results = []

        page_size = 500
        critical = True

        server_page_control = SimplePagedResultsControl(page_size=page_size)

        _search = self.ldap.search_ext(
                base_dn,
                scope=scope,
                filterstr=filterstr,
                attrlist=attrlist,
                attrsonly=attrsonly,
                serverctrls=[server_page_control]
            )

        pages = 0
        while True:
            pages += 1
            try:
                (
                        _result_type,
                        _result_data,
                        _result_msgid,
                        _result_controls
                    ) = self.ldap.result3(_search)

            except ldap.NO_SUCH_OBJECT, e:
                log.warning(_("Object %s searched no longer exists") %(base_dn))
                break
            _results.extend(_result_data)
            if (pages % 2) == 0:
                log.debug(_("%d results...") %(len(_results)))

            pctrls = [
                    c for c in _result_controls
                        if c.controlType == LDAP_CONTROL_PAGED_RESULTS
                ]

            if pctrls:
                size = pctrls[0].size()
                cookie = pctrls[0].cookie()
                if cookie:
                    server_page_control.cookie = cookie
                    _search = self.ldap.search_ext(
                            base_dn,
                            scope=scope,
                            filterstr=filterstr,
                            attrlist=attrlist,
                            attrsonly=attrsonly,
                            serverctrls=[server_page_control]
                        )
                else:
                    # TODO: Error out more verbose
                    break
            else:
                # TODO: Error out more verbose
                print "Warning:  Server ignores RFC 2696 control."
                break

        return _results

Or something like that ;-)

I recently purchased a SIP phone, one of those hardware devices, so I'm now online on Fedora Talk as well. It's not that softphones such as Ekiga or Twinkle wouldn't work, they just wouldn't work as well while I'm connected to a VPN (with my laptop). A Siemens C475 IP DECT solves the problem of lag for me ;-)

I'm on extension 5100680, so if you need me, and you have Fedora Talk, give me a quick call!

To the people failing to see a point, whether they value a point as much as the originator does or not, whether they agree with a point in part or in full or not at all;

• A feed is created, with filtered content
• People will subscribe to this new feed instead of the all-inclusive one, if not just for the fact there's plenty of people
• To get your message out to these people, one must have their message included in this new feed

Whether the originator chooses words such as "having a voice" or "censored" or "justfedora" is utterly m00t, as the choice of words illustrates a point, but do not by themselves make a point.

For example, I see what Seth and Andrea intended with Planet "Just Fedora" Edited, and I applaud the initiative as well as the fact that somebody with a FAS account not even a month old today is enabled to make this big a dent.

That said, the point remains to be the same; people who think they have something to say will need to be included on Planet Edited or are, as part of the audience only reads what is on Planet Edited, silenced in part.

In response to Mairin Duffy, whom, by the way, I respect very much, and I think deserves your respect as well.

Mo does an awesome job engaging an audience in Free Software that would have otherwise be left to their own fate wading through a hell for the rest of their lives, an audience that would never have been moved by us mortals focused on the technical side of things. I can't wait to hear of the results on SXSW, honestly. Note I know I'm leaving out an awful lot appreciation for other work she's done [for all of us] over many, many years of passionate engagement in what you probably care just as passionately about, as does the rest of us.

That said, however, on the subject of ownership... yes indeed we do make it. That doesn't say anything about the ownership though. I think every single one of us community members have given the Fedora brand the value it has today. Though I'm doubtful it requires the level of, or means through which it is getting such, protection to date, I do realize how something as valuable to so many of us must have someone be the owner in order to protect it.

However, history shows us that the people giving something value, and as such own that something, are not necessarily the ones deciding what to do with it. This, I think, is the underlying thought behind the recent protests - not whether we make it, but to what extent we actually own what we make.

My blog is now included on Fedora's "Planet Edited" - mind you various people won't like me for calling it censored. Originally, I thought the censored version of planet was going to filter out the 'I had this-and-that for breakfast' type of blog posts, which, usually anyway, have nothing to do with Fedora at all. However, after some clarification from Andrea Veri, it seems a relation between the posts content and Fedora isn't sufficient - the blog post must be specifically about Fedora.

I suppose what this will result in is a series of blog posts from team leaders and whatever other semi-official titles you can attach to the wide variety of Ninjas within the Fedora Project. Speculating about content, I can think of announcements, progress reports, invititations to attend meetings either in person or virtually, but also; event reports from our Ambassadors, speculation on pre-mature ideas and concepts, and blog posts like this one, from... let's call'em "opinion-makers" shall we?

I think that's great. It's censored, as technical posts like my post on noop I/O schedulers in KVM environments through Puppet and Augeas apparently do not seem to fit the filter "about Fedora" though I think they are related to Fedora or at the very least interesting to some small amount of Fedora people. However, as I've said, my misunderstanding of what the censored version of planet was about was clarified.

Ultimately, Planet Edited is what our dear self-regulating community should want from the original planet - but without the censorship. Somehow people on the original planet are unable to, forget or refuse to show constraint in what they'll make end up on the Fedora Planet... they omit the appropriate tagging or include an all inclusive feed on Planet. I'm one of those people including their entire blog on planet, but then again bits and bytes in Free Software is about all I live and breath for.

Let's not forget it is planet.fedoraproject.org that now has a moderated version to achieve the exact same measure of control over content, but top-down. It's supposed to work the other way around... anyone of us should show constraint pushing something out to planet, asking "Is this what I would like to see others post to planet?" - bearing in mind I lose it every once in a while, too. Now though, Planet Edited is going to make people feel excluded, not necessarily a positive influence on anyone's gut feeling. The people with their blog included in the edited version of Planet -like me- are now on some sort of virtual pedestal, with more exposure to the general audience - also the electorate. I think the moderated version of our planet is restrictive, divisive and exclusive, whereas I would want our community to be more inclusive - and yes that includes girl scouts.

For a virtualization environment, it often makes sense to use a kernel I/O scheduler that does not take into account whether and/or which hardware seek time penalty may or may not be applicable for the disks used. Hence, where in my case I use a storage device over iSCSI, I want to set the noop scheduler for the hypervisors (which use iSCSI), and all guests on it (which use logical volumes). Neither the hypervisors nor the guests will experience a seek time penalty, so I thought, and so scheduling their I/O does not need to be optimized for such. The noop scheduler does exactly that.

On a side-note: Luckily, all guests run Linux ;-)

Using Puppet and Augeas, it's particularly easy to just manage the kernel cmdline options. In the Puppet manifest:

    # If the system is virtualized, just use the noop I/O scheduler
    # for all block devices
    if ( $is_virtual ) {
        augeas { "kernel_elevator_noop":
            context => "/files/etc/grub.conf",
            changes => "setm title kernel/elevator noop",
            onlyif => "get title/kernel/elevator != noop"
        }
    }

To change the I/O scheduler during runtime, just use:

# echo noop > /sys/block/<device>/queue/scheduler

For a full, more verbose description of what to do (including loading the necessary kernel module, etc.), check out this awesome, short walk-through.

Now that Nokia has sold it's soul to Microsoft (Remember Caldera? Remember Novell?) letting the 1.3% market share operating system be deployed on the 33% market share phone hardware... and while (or so I assume) a lot of the people that I know are going to never ever again buy a Nokia smartphone... simply because of the operating system... let us remain fair...

I will take one look at the N9 which is supposed to be launched later this year, with MeeGo. If it's great, I'll take it. If it sucks, that'll be the end of it, and I'll have to go with a new not-so-free Android.

Reading yesterday's Financial Times or rather, still reading the Financial Times issued yesterday since yesterday, my eyes fall on an article titled "Data out of the door" (page 13, by Peter Marsh and Jamil Anderlini, a.o.). The article is about industrial, economic, commercial espionage, a great concern to many advanced enterprises in the developed world, and how it impacts the industry (leaders) to lose "billions" worth of "intellectual property" (read: future, speculative patent licensing fee revenue and competitiveness).

Businesses are said to increase their efforts to protect their property against theft in an attempt to minimize the threat partly through elaborate information technology. Herein, I think, lays the culprit.

Then, I read Dieter Zetsche, chief executive of Daimler (the German automotive group) reportedly having said, expressing "no concern" about theft of his company's secrets - and I quote:

"We shouldn't waste our time trying to protect our intellectual property but try to be innovative and faster then the other guys."

A sigh of relief. To me, it shows at least some industry leaders understand that the fear of theft of proprietary information has two possible outcomes;

A business focuses on the protection thereof, and invests its resources in protecting against the inevitable. This, admittedly, seems to be feasible as a short-term, stop-gap solution. However, and call it Murphey if you will, air-tight security is virtually impossible -no pun intended. Somebody has access, and humans are humans, as shown in the affair of three top executives at Renault being sacked over allegedly having leaked information. Aside from incidents like the former, when somebody has or controls access to something, and if you can't circumvent the technology, put sufficient pressure on the person. On a more philosophical level, restricting access to information that may or may not be crucial to one's actions -you'd never know- in a post-Cablegate world is often considered conspiracy and conspiracies are unstable - not to bluntly say unsustainable.

As a result, businesses would have to further invest in the protection of their data for a very, very long time to come -indefinitely, one would hope. The results may include a decrease in user productivity, will most probably include further restriction of the user's freedoms, and possibly further boosts the implementation technologies of North-America based proprietary software companies that do have the level of technology integration required to achieve the desired goals, Free Software seems to be lacking up and until now.

Alternatively, a business can invest to continue to outsmart its competitors not by vigorously protecting its commercially valuable or relevant information from leaking, but instead increase innovations at such a pace espionage in whatever covert form or shape can no longer catch up sustainably. You gain some (fast-pace R&D), you lose some (the information that might leak).

The latter seems -just a tiny little bit- closer to the effects Free Software philosophy has with regards to a morally and ethically correct business model, focusing more on the innovation then on the protection of the outcome of such innovation. Still a long way to go, of course, as Free Software innovations usually are available to all, in all liberty, almost instantly -not to say without cost. I applaud Mr. Zetsche for his renewed insight.

Obviously, the former notwithstanding, a minimum level of information technology as well as physical security is required -even if and when incidents such as the temporary re-routing of Internet traffic through Chinese routers trigger the formation of a God-like authoritarian Internet oversight committee or worse. I am not arguing business information systems should become a Free-For-All, not at all. Please allow me to simply refer to common sense and best security practices available and implemented today (and tomorrow), where security essentially -certainly business-wise- is risk management.

For some reason, the audience at Barcamp today decided to not vote en-mass for my session on Fedora Extended Life-cycle Support, so I only got 21 votes. 21 votes by the way is an awful lot in comparison to previous FUDCons I've been at, I suppose the sessions that did make it must have had 30+ votes each! My session on Packaging for ISVs didn't make it either, FWIW.

Whenever you see Max Spevack wearing his birthday present T-shirt today or tomorrow, please do bet him one american dollar on something ;-)

It's the start of day -2 of FUDCon Tempe, good morning!

On today's schedule: preparing sessions on ISV packaging, with a real-life scenario revolving Kolab Groupware, a session on Fedora Spins and the Fedora Spins SIG, and perhaps I get around to preparing a talk on Ruby today as well.

Max again is tied up in meetings, as are his companions, however I'm no longer all alone here in the main hotel; Ben "Southern Gentleman" Williams has arrived, and so has Ian "ianweller" Weller.

I start this post with a little story-telling on some "horrible" traveling; Arriving at Cardiff International Airport, it appeared my flight to Amsterdam was cancelled. It's a regular service, but the delay was still 4 hours. I was planning on an overnight stay with friends in the south of the Netherlands, a good 2 hours of travelling by train away from the airport, so obviously I arrived there a little late; 22:00 or something like that.

The following morning, I had to catch a plane at 10:25 in the morning, so my departure from my overnight stay was a good 6:00 in the morning (boarding time on US flights starts 2 hours in advance, and they have strict rules on accepting check-in luggage, too). 22 and a half hours later, I'm sitting in the Marriott Courtyard Hotel, FUDCon's primary lodging location, sipping a beer with Max Spevack. 22 and a half hours... it's not fun. I can confidently state, endangering repetition; I love to go places but I hate to travel.

Anyway, Ryan Rix and Robyn Bergeron met up with us, and I just have to quote Robyn saying:

"No, Ryan, she was all over your buttons."

'nuff said. After picking up Harish Pillay from FUDCon's secondary lodging location, we had dinner at what is called a Tavern right across the street.

Long story short, today Max and his companions are in meetings all day, so I'm all alone in the hotel lobby bogging the free wifi.

Preparing my slide deck for a session on Fedora's Extended Life-cycle Support (ELS) initiative, sub-titled "the why, the what,  the how and the who", I figured I might as well publish them here -since so many people can simply not make it to FUDCon, however regrettable.

So, attached to this post is a bunch of slides on the subject. I hope you enjoy!

I've moved to Wales proper. It was a bit of a hassle to move all my stuff over, costly as well, but it's been done. Thanks to help from my great friend Berrie, who does have a driver's license, I rented a truck and stuffed it with all my personal stuff, some servers, some furtniture, and made the trip across the Northsea, all the way across the UK, to Wales.

Now, I'm sorta settling. First, I have to catch up with work I wasn't able to do during my downtime, of course I have to unpack lots of stuff, and having performance problems at a customer doesn't help much either.

For those interested in all kinds of new phonenumbers and stuff, I propose that if you have the old phonenumber, you ring it and I'll answer and we can have some chit-chat and I'll give you the new phonenumbers.

You are somewhere in a Sun Belt state in the U.S., and it's nearing the and of January. For some, this sounds like a hopeless situation. For others, it is the opportunity of a lifetime!

Here's 10 things to do in Tempe, Arizona, nearing the end of January, 2011, while FUDCon is taking place.

1. Bacula Backup and Recovery; Get some insight on the subject and engage a Bacula Systems Certified Trainer on the subject. I'd love to insert a "Tuesdays at noon" type of thing, but we're just not sure when exactly such sessions would be taking place. It's not important either, there's at least 9 other things to do!
2. Koji Build Systems. Do you use it? Do you use it because you need something happening downstream? Are you a third-party repository enthusiast? Let's get to it, and have at least one session on the build system suite.
3. Long Term Support (LTS), Extended Lifecycle Support (ELS), or whatever you may want to call an extention on the regularly supported time period of updates coming to a stable Fedora release. I like the latter terminology better. If you're interested in stopping it though, please stay away?
4. Spins. Custom spins, localized spins, remixes or bluntly put, dwarf forks. How can we make sure all this momentum is harnassed and nurtured up and until the point little projects become proud masters of the universe with our help.
5. Packaging Guidelines and the Package Review Process. I've had my share, how about you?
6. Cyrus IMAP; first-hand experience of a) How Fedora Rules the Universe, b) What Upstreams Expect From Distributors and c) How To NOT Behave As A Distributor.
7. The Ever So Awesome Fedora Cloud. I'm not sure where it's at, but I do think I know a little something about what cloud is all about. It's time to get that first concept implementation for Metadata DNS going, while showing off a complete Open Source stack for Any Company(TM) in a demo-environment with public access of sorts.
8. Fedora Hosted Groupware. I know Fedora Infrastructure to have looked at Zarafa, not to say I have shamelessly plugged it back in the day. In the interest of full disclosure, I now work for Kolab Systems -another Groupware ISV, this time fully open source and free software.
9. Puppet. Modules. Modules. Modules. Cross-platform consistency. Approaches. Packaging. Writing modules (why and how)
10. Beer, meat (that's me), friends, laughs (that's me too!). I can think of very little more I need in life.

I'm sorry, I have been reading too much crap on the net lately. Including, but not limited to, articles arguing the Linux  Desktop is dead, and most recently Improving the Linux Desktop: 20 Needed Fixes.

All I can think when reading these articles... in this blog post;

1. If the author cares about it enough to write about it, it has value to the author. Hence, the glass is half-full, not half-empty, even from where the author is sitting.
2. If the readers read the articles (d'oh!) this topic must be hot-hot-hot. The author, though, has most probably NOT been one of the people who got what he/she/it is writing about as far as to be a hot-hot-hot topic.
3. The more one writes about Linux, no matter in what negative -slash ignorant- terminology, the more one makes "most of us", as Matt Hartley puts it, realize what we've done is probably the best that could ever have happened to the world we live in - in terms of what *we* could actually make a small difference in.

   "We" is a registered trademark of "Us". You are Free to (ab)use "we" and "us" in any way (im)possible.

4. All these articles are being tweeted. Guess what Twitter runs.
5. Understandibly, articles refer to "the ability to Google", but as lacking amongst users. Well, this statement is just expressing a certain level of ignorance amongst the authors, because it would simply be near to impossible to have or develop an ability to Google without Google running the product of our labour.
6. I'm still set on December 12, 2012 ;-)

When you run Kolab, or Postfix and Cyrus IMAP, you may have any number of your users subscribed to a mailing list.

As such, many mailing list posts may delivered to a large number of users separately, increasing the data footprint on disk, and processing, while only including some of your users in the loop on what may be interesting content for everyone.

You may want to have one shared folder to deliver new mailing list messages to, to which individual users can then subscribe. Here's how (in a nutshell):

• Create a Cyrus IMAP user that is called 'shared',
• Set the postuser to 'shared' in /etc/imapd.conf
• Set the sharedprefix to 'shared' in /etc/imapd.conf
• Create a shared/lists mailbox (cm shared/lists@kolabsys.com in my case),
• Create some subfolders you want mailing list posts be delivered to, like shared/lists/kolab.org/devel@kolabsys.com,
• Make sure that at the very least 'anyone' as the 'lrsip' permissions on the mailbox,
• Give yourself 'all' privileges on the mailbox,
• Make sure the recipient_delimiter is set to '+' in /etc/postfix/main.cf,
• Make sure shared@kolabsys.com is listed in /etc/postfix/transport with transport lmtp:unix:/var/lib/imap/socket/lmtp
• Reload what you need to reload,
• Send a test message to shared+shared/lists/kolab.org/devel@kolabsys.com,
• It should end up in the correct folder.

Note, for those of you not using virtual domain support in Cyrus, skip the @kolabsys.com at the end of folder names to be created and you should be good to go.

Also note that for each individual user that wants to post messages to the mailing list, they still need to be subscribed to the mailing list themselves; they can then disable delivery through the mailing list preferences pages if available, reading the list through the shared folder.

Paul Adams asked me to install Web Analytics for Kolab Systems, his preference being Piwik, which he had used before.

Now, when some request like that hits me, I'm usually like "Oh yeah? Web analytics is it? What is it you actually want? Number of hits?" just because I would like to go from the functional requirements as opposed to being the monkey to implement whatever and then having to maintain/modify/develop whatever because it isn't quite all what was expected.

However, in this case, and those kudos go to Piwik, I looked at it, I tried it once and then decided to put it in production -normally I deploy something to testing first, then have someone make up their mind and make absolutely sure it's good and ready.

However, in this case, the case of Piwik, the installation procedure was like next-next-finish, it got me what I needed right-away, and it runs exactly the way I expect it to run -that's unique compared to how I needed to run in circles for many, many other web-based applications.

Either way, long story short, if you need Web Analytics do take a look at Piwik. It's awesome, even though it's not as extensive in admin features such as delegating a per-profile per-user set-of-privileges (to view or admin such profile). You would most commonly deploy Piwik within one organisation or multiple organisations that trust one another to some or the other extent, specifically for a limited set of websites anyway (e.g. not the multi-multi user deployment that is Google Analytics), and there's very valid reasons to not want to use Google Analytics.

I've always been a fan of the "step up or shut up" line of thought... it Gets Shit Done(TM). Hence, please allow me to share the following conversation over IRC, with a very good friend of mine (Martijn):

Martijn: "I feel like Fedora Project's home page has been translated through Google translate or something"

I: "To Dutch, you mean?"
I: "Step up or shut up"

Martijn: "Yeah, good point. Where can I contribute?"

I: "fedoraproject.org/wiki/Join or join.fedoraproject.org oder so etwas"

Martijn: "Alright... apparently it's been translated by Google translate:"
Martijn (quoting): "Make sure all webpages are translated for the F13 release."
Martijn (quoting): "Team: Nobody yet! Please help!"
Martijn (quoting): "(We aren't actually worrying about this until the end of July, but if you are interested in picking this up and keeping us from panicking then, that would be awesome. Please email the list if you are keen on this, and someone will respond to you.)"

Case closed.

Unhelp! My broadcom wireless, which I reported to have been broken, miraculously started working again!

It must have been something I did... but I don't remember :( I know I kept the notebook upside down for a while... maybe that's it!

Help!

My broadcom wl stopped working!

Since I just use the Acer Aspire One as sort of like a radio station (BBC 1Xtra is available through iPlayer only from within the UK), while my main workstation is connected to a VPN making it appear as if I'm in Switzerland... it's not that great a priority.

Thought I'd share ;-)

If you ever run into a situation where OTRS 2.4.7 on your CentOS system (for which packages live here BTW) bails out retrieving new email from a mailbox, it might actually fail sending out notifications to agents:

[otrs@app01 ~]$ perl -d /var/www/otrs/bin/PostMasterMailbox.pl -d 9 -f 1
Loading DB routines from perl5db.pl version 1.28
Editor support available.

Enter h or `h h' for help, or `man perldebug' for more help.

main::(/var/www/otrs/bin/PostMasterMailbox.pl:34):
34:	$VERSION = qw($Revision: 1.10 $) [1];
  DB<1> step

  DB<2> [...System/MailAccount/IMAPS.pm line 82 in sub new] looking for greeting
[...System/MailAccount/IMAPS.pm line 82 in sub new] got a greeting: * OK [CAPABILITY IMAP4 (...snip...)
[...rl/5.8.8/Net/IMAP/Simple.pm line 931 in sub _send_cmd] 0 LOGIN (...snip...)
[...rl/5.8.8/Net/IMAP/Simple.pm line 196 in sub _process_cmd] 0 OK [CAPA(...snip...)
(...snip...)
[...rl/5.8.8/Net/IMAP/Simple.pm line 509 in sub _process_cmd] )\r\n
[...rl/5.8.8/Net/IMAP/Simple.pm line 942 in sub _cmd_ok] )\r\n
[...rl/5.8.8/Net/IMAP/Simple.pm line 903 in sub _seterrstr] warning unknown return string (id=3): )\r\n
[...rl/5.8.8/Net/IMAP/Simple.pm line 509 in sub _process_cmd] 3 OK Completed (0.000 sec)\r\n
[...rl/5.8.8/Net/IMAP/Simple.pm line 942 in sub _cmd_ok] 3 OK Completed (0.000 sec)\r\n
Wide character in subroutine entry at (eval 72)[/usr/lib/perl5/vendor_perl/5.8.8 (...snip...)
 at (eval 72)[/usr/lib/perl5/vendor_perl/5.8.8/MIME/Decoder/QuotedPrint.pm:78] line 1
	MIME::Decoder::QuotedPrint::encode_qp_threearg('> > > ��Buil(...snip...)
', 'undef', '') called at /usr/lib/perl5/vendor_perl/5.8.8/MIME/Decoder/QuotedPrint.pm line 95
	MIME::Decoder::QuotedPrint::encode_qp_really('> > > ��Build OS:���(...snip...)
', 1) called at /usr/lib/perl5/vendor_perl/5.8.8/MIME/Decoder/QuotedPrint.pm line 154
	MIME::Decoder::QuotedPrint::encode_it('MIME::Decoder::QuotedPrint=HASH(0x7811330)', (...snip...)
	MIME::Decoder::encode('MIME::Decoder::QuotedPrint=HASH(0x7811330)', 'IO::ScalarArray (...snip...)
	MIME::Entity::print_bodyhandle('MIME::Entity=HASH(0x78c07a0)', 'IO::ScalarArray=GLOB(0 (...snip...)
	MIME::Entity::print_body('MIME::Entity=HASH(0x78c07a0)', 'IO::ScalarArray=GLOB(0x78c09 (...snip...)
	MIME::Entity::print('MIME::Entity=HASH(0x78c07a0)', 'IO::ScalarArray=GLOB(0x78c0980)') called (...snip...)
	MIME::Entity::print_body('MIME::Entity=HASH(0x782b520)', 'IO::ScalarArray=GLOB(0x78c0980)') (...snip...)
	MIME::Entity::stringify_body('MIME::Entity=HASH(0x782b520)') called at /usr/lib/perl5/vendor_perl/ (...snip...)
	MIME::Entity::body_as_string('MIME::Entity=HASH(0x782b520)') called at /var/www/otrs/Kernel/Sys (...snip...)
	Kernel::System::Email::Send('Kernel::System::Email=HASH(0x76199f0)', 'From', (...snip...)
	Kernel::System::Ticket::Article::SendAgentNotification('Kernel::System::Ticket=(...snip...)
	Kernel::System::Ticket::Article::ArticleCreate('Kernel::System::Ticket=HASH(0x(...snip...)
	Kernel::System::PostMaster::FollowUp::Run('Kernel::System::PostMaster::Foll(...snip...)
	Kernel::System::PostMaster::Run('Kernel::System::PostMaster=HASH(0x7232(...snip...)
	Kernel::System::MailAccount::IMAPS::_Fetch('Kernel::System::MailAccount::I(...snip...)
	Kernel::System::MailAccount::IMAPS::Fetch('Kernel::System::MailAccount::IM(...snip...)
	Kernel::System::MailAccount::MailAccountFetch('Kernel::System::MailAccount(...snip...)
	main::Fetch('EncodeObject', 'Kernel::System::Encode=HASH(0x6bf86e0)', 'C(...snip...)
[otrs@app01 ~]$ 

Note that the error in the web interface or from a normal regular run may look like:

Wide character in subroutine entry at (...something...) at 1

This is actually caused by the default OTRS setting for SendmailEncodingForce which is set to 'base64'. Hence, in /var/www/otrs/Kernel/Config.pm, add the following line:

$Self->{'SendmailEncodingForce'} = '7bit';

Thanks to Paul Adams for some ingenious Googling ;-)

I attended my first Open Foundry meeting today, earlier this evening. I regret not having attended before, but then again, I'm away every once in a while, otherwise occupied some other time, or physically incapable of showing up ;-)

Anyway, let me first introduce you to what we refer to as Open Foundry...

While this meeting specifically focussed on the website that is going to run on openfoundry.nl, the greater goal of the Open Foundry is to further enable and increase community participation through a concept that we know as local user groups.

So, in this instance, we have a bunch of people already, that are very much interested in web technology developments. While the first version of the site will be in static HTML, it will be HTML 5 and CSS 3. That is, or so I'm told, funky business -and yes, even with the limited knowledge that I have in this specific area, both funky and business are accurate terms to use here.

The next step for this web-team is to get some communication platform going, as well as designing a web application (or rather, platform) in Rails 3. OOPS!

Several problems arise. There's no excellent IDE in Free Software, currently, capable of handling Rails 3 just right. Hell, even Rails 3 itself has some compatibility issues with Ruby 1.8.7 as well as Ruby 1.9.1, so it should be implemented using Phusion's Ruby 1.8.7 Enterprise Edition or Ruby 1.9.2. Nice one!

Long story short, the release engineers and system administrators kick in. Some source code management is going to need to be able to facilitate some sort of pragmatic source code management, it must be a collaborative effort, and it must be deployed across various stacks on various platforms using sustainable management and deployment methodologies (e.g. RPM and not Ruby's integrated gem package management or user-space bash-scripts under the RVM category).

This is exactly the area that I've been working on for a number of years. Hence, while not a RoR developer myself, I think I can be of value to the Open Foundry web development team. I hope they can be of help to Ergo Project as well ;-))