During the discussions for the release of openSUSE 12.3, the topic of update notifications and applets was brought up again. Originally openSUSE shipped with a custom update applet, but since it was basically unmaintained, the decision was made to switch to Apper for openSUSE 12.2

The original Apper used in that version had a number of issues, which the upstream developer (Daniel Nicoletti) fixed in a newer version, which also had a lot of other improvments. However we originally couldn’t switch because it depended on a newer, API-incompatible version of PackageKit, meaning that the PK bindings for libzypp (the heart of openSUSE’s package management) needed to be adjusted and ported.

So, for a while it was not clear on how to proceed, until at the recent hackathon, Stephan “coolo” Kulow ported the PK zypp backend to the newer PackageKit version. Once that issue was solved, the KDE team was able to update Apper to the latest version (0.8) and push it to the distribution. So openSUSE 12.3 (KDE) will make use of Apper as main method of notification for updates.

I would like to stress that Apper is not meant as a full blown replacement of YaST or zypper, but mainly as a way to handle distro and maintenance updates, integrated with the KDE Workspaces.

The Apper program is actually divided into two pieces: the main application itself and a plasmoid. We’ve been testing the plasmoid the past weeks and consensus is that it’s not yet ready to be pushed to users, so only the main application will get installed by default. When you have new updates, an icon will pop in the system tray informing you:

[]({{ site.url }}/images/2013/02/apper-notification.png)

Clicking on it will bring up the main interface, where you can review and select the updates:

[]({{ site.url }}/images/2013/02/apper-updates1.png)

Afterwards, the update process will start.

Of course, such an addition means that more testing is required, to ensure that outstanding bugs get fixed before the openSUSE 12.3 release. Therefore, if you are willing to test - jump aboard!

In a couple of hours, I'll be taking the train and heading to Brussels for FOSDEM. I've lost counts of how many FOSDEM I've attended, which is probably a good indication of how great the event is!

As usual, this will be a good place to catch up with friends, but also to talk with tons of different people about so many topics. If you want to chat about OpenStack, SUSE Cloud, openSUSE or GNOME, I'll be glad to join you.

The schedule is quite packed, but from what I can tell so far, I'll be sitting in the cloud devroom on Sunday (don't hesitate to join in order to learn about what's happening in the OpenStack world!). Oh, I'll also give a talk in Janson about challenges that the GNOME project is facing, just before the closing keynote.

And no, I won't have my blue hat, so you'll need to find another way to catch me (hint: I have a SUSE backpack nowadays) ;-)

In a recent discussion among php core developers, Zeev Suraski of Zend Technologies offered to open source their proprietary byte cache “Zend Optimizer+”. The main objective is to get a bytecode cache into the PHP distribution and finally into the core. There is a lot of discussion if the 5.5 release should be delayed by two months to include the open-sourced Optimizer+. Some advocate that PHP 5.5 should stick to its original release schedule and Optimizer should go into the master instead, eventually becoming PHP 5.6 : While there is strong support for getting a byte code cache into PHP Core, some are questioning why the php.net project’s native cache extensions “APC” is not the preferred option. PHP Leader Rasmus Lerdorf says ”

You also have to take into account that most sites can’t actually move
to the next release of PHP until APC is stable with it. So effectively
the PHP 5.4 release didn’t happen until APC 3.1.13 in September 2012
which was a full 6 months after PHP 5.4.0. I don’t foresee this getting
any better for PHP 5.5.

In order for PHP releases to actually mean something this is a problem
we have to fix. I honestly don’t care which opcode cache implementation
we base a core version on, what I care about is developer buy-in. Dmitry
and Stas being familiar with the code already outnumbers the number of
active core devs working on APC today.

I understand some of the skepticism and hurt feelings around this from a
few old-timers, but let’s move on and see if we can finally push out a
release with solid opcode caching right at the release date. From my
perspective anything up to a 6-month delay would beat the current situation.

The APC would then be reduced to a userspace data cache. For Optimizer+ to get into the core, some cleanup and compatibility with ZTS (Thread Safety) needs to be achieved. Traditionally, Zend products only run in PHP’s non-threadsafe mode.

It is no secret I like version control systems(VCS). As most SysAdmins i believe that pretty much everything should be versioned, any file that we tinker with must always be backed up and versioned somewhere.

I am pretty sure that by now you maintain a lot of stuff in modern vcs like Git repos (or whatever floats your boat), the point is you already use version control. However as you might have guessed even though systems like Git sound (and for certain situations ARE awesome) they tend to not work well for a SysAdmin’s purposes, especially when talking about configurations.

Programmers tend to work on things and files that are interrelated thus it makes lots of sense to have everything under a directory versioned under VCS, which is the way it is currently done by “modern VCS”. In systems administration however that is not the case, most of the time the files in a directory have nothing to do with one another, but are there by convention and you rarely want to version and manage ALL of them.

The best example illustrating the above is the /etc directory. You rarely want to have it all versioned and many of the files there need special treatment (certain exact permissions etc…) making the use of “modern huge full directory oriented VCS” a real pain.

Enter RCS! Despite it’s many and significant disadvantages RCS is a simple and solid VCS with the great virtue of controlling individual files instead of directories or hierarches of them. Thus, its trivial and mindless to use for a file in some system dir (like /etc) and almost forget about it.

here is a list of common operations, done the RCS way.

#    RCS operation
#    $ Command line

#Initial check-in of file (leaving file active in filesystem)
$ ci -u filename

#Check out with lock
$ co -l filename

#Check in and unlock (leaving file active in filesystem)
$ ci -u filename

#Display version x.y of a file
$ co -px.y filename

#Undo to version x.y (overwrites file active in filesystem with the specified revision)
$ co -rx.y filename

#Diff file active in filesystem and last revision
	
$ rcsdiff filename

#Diff versions x.y and x.z

$ rcsdiff -rx.y -rx.z filename

#View log of check-ins

$ rlog filename

#Break an RCS lock held by another person on a file
$ rcs -u filename

• The openSUSE distribution
• Different artwork needed for the project like merchandising, banners, etc.

Last week-end, just before leaving for some travel, I became aware that gnome-panel was being forked into consort-panel (btw, I commented on that post, but I guess it was a bit too late since it's stuck in the moderation queue).

Now, let me start by stating clearly that I have nothing against forks: people are free to go this way, and that's cool with me. However, I quickly got confused for three reasons: I thought it was clear that volunteers are welcome to maintain gnome-panel, I thought I had explained to Ikey in June 2012 why some changes would be blocked from entering fallback mode but could hopefully happen in a not-too-distant future, and I'm getting explicitly blamed here and there for putting roadblocks.

I usually don't mind being blamed, but I prefer when it's for good reasons ;-) Of course, as a maintainer, I reject patches. There are usually good reasons, including the fact that there's a design philosophy that a module like gnome-panel had to follow since it was fully part of GNOME. Rejecting patches is part of the maintainer job. It doesn't mean that contributions are not welcome, but I guess it can be perceived as such... Another task of a maintainer is to enable people to keep the code alive, and in the case of gnome-panel, it was clear to me that having the fallback mode as part of GNOME 3 was a blocker to do so. It took more time than I would have liked, but this is something that got fixed when the fallback mode got dropped of GNOME 3.

With this in mind, and to clarify why I got confused by the fork announcement, here's a quick timeline of events in 2012, related to the fate of gnome-panel, covering what I was aware of until the blog post from a few days ago:

• June 24th & 25th: I get a mail from Ikey about some patches he wrote to revert changes that were done in gnome-panel 3.x. I answer that this can't get in at the moment, due to the fact that the fallback mode is an official part of GNOME 3 and has to work the GNOME 3 way. I also mention that this direction of gnome-panel could change if the fallback mode is dropped from GNOME (and that I would step down as maintainer if gnome-panel becomes actively developed again). As far as I know, this mail discussion (six mails) is the only time I've interacted with Ikey until I commented on his blog post a few days ago (no other mail, nothing in bugzilla; there might have been some irc chat, but I don't keep irc logs).

• June 25th: I start a thread on desktop-devel-list to see if we still need to keep the fallback mode as part of GNOME 3.6, and I invite Ikey to participate in the thread (in the private mail discussion mentioned above). A decision is taken, and it's to keep the fallback mode for now.

• end of August: I start the DropOrFixFallbackMode feature page for GNOME 3.8, because I feel the fallback mode in GNOME is not getting enough love. This feature page explicitly mentions that some people would like to improve components of the fallback mode to work differently, and that dropping the fallback mode would enable these people to step up and push for what they'd like to do.

• November 9th: the release team announces that the fallback mode is being dropped from 3.8.

• November 21st: I blog about the fallback mode being dropped, and invite people to become maintainers.

• December 5th: I send a mail to a small group of people who I know might be interested in keeping some fallback components maintained, to help them start on their work. Clearly, I failed to include Ikey in the discussion, but only because I had forgotten about our discussion from June.

The ironic point here, at least to me, is that it's Ikey's mail that triggered my push for the fallback mode to be dropped from official GNOME so people could work on gnome-panel with more freedom. Which is what seems to be wanted.

Anyway, let me take this as an opportunity to remind everyone that people are welcome to become maintainers of gnome-panel. It'd be preferable to maintain it in the GNOME infrastructure, but I guess even just forking it with full history on gitorious/github would work. No need to rename, no need to follow the GNOME 3 design, etc. If full forking+renaming is preferred for some reason, in the end, that's fine; I'd be curious to know what good reason exists, though.

And as usual, you're welcome to blame me for X, Y or Z :-)