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 :-)

Yesterday, ownCloud Client 1.2.0 was released. You can get it from here. We worked on this since end of november last year, you might have seen my other blogs about the beta versions we had for this release.

What is interesting about the release from a more technical point of view? Here are a couple of examples.

One of the things which often was complained about was the performance of the client. Performance is a very broad term, so we have to examine the details: Many people felt like its a performance problem that former clients polled the local file system for changes on the MacOSX and Windows platform. That was recommended from other projects which have experience with going through large file collections. QFileSystemWatcher seemed not to be designed for this usecase.

Polling was ok for desktop computers with up-to-date hardware, but on devices running from batteries this was a energy drain. Good that we could fix that with 1.2.0 using native implementation of change detectors on Windows and MacOSX. They detect changes within a file system tree. If a change is detected, a sync run is started. But note, this is only for local file systems. Detection of changes on the server is a different story which has to be told as well.

Another performance problem was within the file upload which is done by a HTTP PUT request. Month ago (pretty after my start at ownCloud) I implemented it using a tmp file in between. That means, the source file was copied to a tmp file, and from that it was processed to the request body. Improvement was needed and we changed the code to directly read from the file descriptor of the opened source file.

Another thing that was improved with 1.2.0 is the error reporting to the user. Former versions of the client sometimes provided error messages which were not really accurately describing the problem. The reason for that was that csync uses errnos (yes, the ones from errno.h) to name errors as csync maps everything to a POSIX file interface. That surely works as long as you’re on a kind of file system. But it’s hard to map HTTP communication problems onto that. So we decided to add our own “custom” errnos and enhance the whole idea to use these to describe problems. That works more accurate now.

The next things on the list are for example a more convenient setup dialog for the client. Also we will get away from the kind of hard coded target file name on the cloud. A better network recognition will also be next as well as better handling of big files. And more…

Thanks a lot to all who helped to get 1.2.0 finished! It is big fun to work in such a great community :-)