Almost one year ago, the openSUSE Project launched the openSUSE forums as a merger of former suselinuxsupport.de, suseforums.net and the openSUSE support forums at forums.novell.com. Right from the beginning of this project, I served as the Project Manager and afterwards contributed as a Moderator at the OSF to the openSUSE community. Therefore the happenings at the openSUSE forums are certainly in my personal interest.

Today, Wolfgang Koller, the founder of former suselinuxsupport.de and one of the three Site Admins of the openSUSE forums, announced his immediate resignation from the OSF staff. I myself feel this as a loss, that is both unexpected and severe. From my perspective, he deserves our respect and appreciation for everything he has done for the openSUSE community and thus this post is dedicated to his person and contribution.

Also in answer to his decision, I myself announced my own immediate resignation from the OSF staff as well. Herewith I’d like to make the openSUSE community aware of these recent changes – this shouldn’t happen silently from my perspective.

Let me take the opportunity to wish the remaining OSF staff all the best for upcoming activities. Lead the openSUSE forums community into an even better future!

As said earlier, the Factory Live CDs are using clicfs for compression and write access. This has one performance problem: booting on ext3 accesses many different blocks (4096 bytes each) that are on many different places in the file system. Squashfs has a structure that makes it a better fit to livecds as it compresses metadata independent from file data. This doesn’t give you a huge difference, but it’s there. Especially with CDs that are very slow to seek from track to track. Booting the gnome 64bit live cd loads about 177MB (out of >2200MB in total on the CD) when booting into an autologin session. This comes with around 1700 seeks – and one seek can be as slow as of half a second (even though most don’t take that long).

But what’s worse: as clicfs (and squashfs) create larger blocks for gaining better compression (128KB for both), you will in effect decompress way more data than you need – and while the decompression used isn’t a big problem for nowadays computers (and you don’t necessarly expect the live cd to fly on yesterday’s computers), it adds quite a lot to the boot time of the live cd.

As I talked a lot with real file system developers about the problem, a pretty simple idea came up: reshuffle the blocks in a way that they are just in the right order – both within the larger compression blocks as on CD to avoid seeks as much as possible. That’s the reason clicfs and mkclicfs both take a -l option. If you mount the container with -l, it will output things like this to the logfile:


access 0+11
access 189+4
access 32957+4
access 65536+4
access 98493+4
access 131072+4
access 164029+4
access 196608+4
access 229565+4
access 262144+4
access 295101+4
access 327680+4
access 360448+4
access 393216+4
access 425984+4
access 458752+4
access 491520+4
access 524288+4
access 557056+4
access 589824+4


That’s actually the first couple of accesses on booting said live cd. It’s resize2fs that’s reading 16K here and there on the file system – accessing 20 compression blocks, decompressing 132K for each of these accesses. But the good news: if you pass this log file to mkclicfs -l, it will put all these blocks as first blocks while creating the container. Of course you need to make sure both clicfs and mkclicfs are talking about the same ext3 file system, otherwise it will be nonsense data.

So what I do is abusing the build service in a sense. I let kiwi create a live cd with fast compression as first step – fast compression because I’m only interested in the ext3 file system. Then I download and boot these live cds in kvm and grab the clicfs log. These I upload back into the project and as third step I have a package that will depend on the live cds from step 1 and the logs from step 2 to generate the real live cds with good compression.

This makes up for the initial disadvantage in performance – it’s actually the opposite, the factory live booted 12% faster than the 11.1.

Our icecream scheduler is moved to another room, so I thought I share the statistics
(just telnet <scheduler> 8766)

200-ICECC 0.8.0-make-it-cool: 5261077s uptime, 61 hosts, 0 jobs in queue (53255934 total).

So this is still the pre-0.9 code and it served in 60 days over 10 jobs per second on average.

Ruby has a nice, but very dangerous feature called open classes. That means you can extend any class definition if you want it.

This example shows it

#!/usr/bin/ruby
class Foo
    def do_foo
        return "foo"
    end
end

aFoo = Foo.new()

puts aFoo.do_foo()

class Foo
    def do_bar
        return "bar"
    end
end

puts aFoo.do_bar()

That means you dynamically extend the definition of Foo class, so the last line prints “bar”.

Python behavior is different, because it does not allows this extending. Python just redefines a class Foo, so new instance of Foo will have a do_bar method only. But this not affected an existing ones, like Ruby does.

class Foo:

    def do_foo(self):
        return "foo"

aFoo1 = Foo()

class Bar(Foo):

    def do_nothing(self):
        pass

print issubclass(Bar, Foo)
print isinstance(aFoo1, Foo)

class Foo:
    
    def do_bar(self):
        return "bar"

aFoo2 = Foo()
aBar  = Bar()

print issubclass(Bar, Foo)
print isinstance(aFoo1, Foo)
print isinstance(aFoo2, Foo)

print dir(aFoo1)
print dir(aFoo2)
print dir(aBar)

But what about method injection? My solution is based on ideas of Recipe 81732: Dynamically added methods to a class.

import types

def funcToMethod(func, instance, method_name=None):
    cls = instance.__class__ if type(instance) != types.TypeType else instance
    setattr(cls, \
            method_name or func.__name__, \
            types.MethodType(func, instance, cls))

And that’s all. The funcToMethod bounds func to instances’s class and allows under method_name (default name is a same as a function one). So lets do some testing.

class Foo(object):

    def list(self):

        return [meth for meth in dir(self) if meth[:3] == 'do_' and type(getattr(self, meth)) == types.MethodType]

    def do_bar(self):
        
        return "bar"

def do_foo(inst):

    return "foo"

class Bar(Foo):

    def do_nothing(self):
        pass

aBar = Bar()

aFoo1 = Foo()
print aFoo1.list()
# calling it with class instead of instance is also possible and is equivalent
#funcToMethod(do_foo, Foo, "do_foo")
funcToMethod(do_foo, aFoo1, "do_foo")

aFoo2 = Foo()
print aFoo1.list()
print aFoo2.list()

print aFoo1.do_foo()
print aFoo2.do_foo()

print aBar.list()
print aBar.do_foo()

When you run the code, you will see that funcToMethod adds a new method to Foo class and this changes both existing and new instances as Ruby does too. And subclassing is not a problem, they are be affected too.

Today I discovered Dropbox, an online storage and synchronization tool. It offers 2 GB of free storage to its users and is available for Mac OS X, Windows and Linux. I’ve tested it on Linux and Windows so far and it’s working great. If you’re tired of carrying around USB sticks to share files between different workstations, be sure to check it out. Hint: by clicking on the link above you (and me) will get 250 MB of free online storage as a bonus.

Installation and Setup on openSUSE 11.1 is a breeze

• 1-click install is available in Gnome:Community
• Logout from your GNOME Session and login again
• Run “Dropbox” from the GNOME menu to link your workstation to your Dropbox account

Currently there’s a plugin for nautilus available. Hopefully some KDE coders more experienced than me will come up with a Dolphin plugin soon. Where the Dropbox daemon is proprietary software, the nautilus plugin is released under GPL and its sourcecode should provide the required information about the Dropbox daemon’s API to port it to KDE/Dolphin as well.

Have fun!