The problem

Solution by Physics system

Implementation

What next

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.