Hi,
My motivation for writing this blog post is to have one simple place where I can point everybody using += in a loop. I will describe here why it can kill the performance of any application or library and will also show some measurement to demonstrate it. (more…)

As it has taken an extra ordinary amount of time for LSB to move forward a predicament has developed for many distributions, including openSUSE. Many of the requirements for LSB 4.1 can no longer be met and thus while the lsb package still builds it is not installable, see . The technically correct solution would be to drop the lsb package from the distribution, Factory now and thus 13.2 when it is released) as we can no longer be LSB compliant. However, the negative side effect is that some applications we do not and cannot package will no longer install, probably most notably google-chrome. Thus, having no lsb package, or no package that provides “lsb”, is a problem and has negative effects on many users. Therefore, the only way forward is to have an “lsb” package which provides LSB on a best effort basis.

Since LSB 4.1 and previous releases is a monolithic requirement, i.e. if you depend on lsb you depend/get everything that is in the standard, whether you want it or not, it is very likely that many applications depend on lsb while needing only a subset of the features. Thus, while we do not know all of those applications and cannot provide a list of “this will work and that will not“, there is a good chance that many external packages depending on lsb will not only install, but the payload they deliver will work with an lsb best effort approach. For those applications that are broken there is pretty much nothing we can do, sorry.

At a meeting last week at LinuxCon NA the goal was set to have LSB 5.0 released by the end of October. LSB 5.0 is incompatible with LSB 4.1 and prior releases. Thus, even if we provide an lsb 5.0 compliant package in short order after LSB 5.0 is released we still have the same risk as we do with the best effort approach. Basically some application packages that depend on “lsb” will deliver a payload that is broken. Exactly the opposite of what the LSB is trying to achieve, but hey one cannot hang on to Qt3 forever. Therefore, our “lsb best effort” approach to cover the gap does not create any additional pain.

Moving forward the LSB working group decided that the current approach, while providing value, has significant drawbacks. Predominantly there are not enough fingers on the keyboard to continue releases of such extensive “accepted standard” documentation. This is what we presently experience with the non installable lsb package. A for the LSB is being worked out. As this next/new LSB develops we will have to see how application providers deal with this. Without a formal LSB specification in the future, this problem will recur in a few years if application packages depend on a package named “lsb” which at some point may need to seize to exist. We will see how this plays out as the world we create keeps evolving.

There is quite some buzz around docker and no one can avoid to read about it. So I wanted to try it out. Since version 1.0 is now out some things got even smoother it seems.
Here is the short version of the commands:

1. Add the Virtualization repository

   zypper ar http://download.opensuse.org/repositories/Virtualization/openSUSE_13.1 docker
   zypper ref

2. Install docker

   zypper in docker

3. Start the docker service

   systemctl start docker

4. Then for example search for openSUSE based containers in the docker registry

   docker search opensuse

   This should provide the same list as using this web page:

   https://registry.hub.docker.com/

5. For now we are going to download and use Flavio Castelli’s 12.3 container by first pulling it

   docker pull flavio/opensuse-12-3

   Depending on your connection that may take some time or finish quite quickly with output looking like this:

   # docker pull flavio/opensuse-12-3
    Pulling repository flavio/opensuse-12-3
    7b4864b5c142: Download complete
    3ac0450b90b3: Download complete

6. If that worked well, you are ready to use that container. For example check what RPM’s are installed by simply issuing

    docker run flavio/opensuse-12-3 rpm -qa

Now you are ready to pull and use containers. If you want to build your own containers the following blog post by Flavio Castelli might be of interest to you:

http://flavio.castelli.name/2014/05/06/building-docker-containers-with-kiwi/

Dear Geekos,

at the openSUSE Conference 14, Kenneth Wimer presented some new ideas and guidelines about branding. This includes a color set, as well as some new design elements.

You can watch his talk here.

I have taken the chance to prepare a light wallpaper proposal, based on this color set

It is of course a proposal, and you are invited to hack on it, improve it, or create something new. The SVG source is available here.

The openSUSE-Education team is proud to present a special, 64-bit edition of openSUSE Edu Li-f-e with the MATE desktop environment.

More screenshots.
(more…)

There has a been a lot of work going on regarding the stabilization of Factory. It is still ongoing process. We have a lot of submissions, Factory is moving really fast and was hard to keep stable. Over the time, there were more and more checks added to the process to make Factory more stable and usable in everyday life. Last of them being added right now are rings and openQA. You can learn more about that in the talk by our release manager coolo. It will also allow you a quick peek behind the curtain on what future will bring.

In that future, one of the core roles in making Factory stable will be played by openQA. As such it got quite some attention during openSUSE Conference 2014 in Dubrovnik. Stable Factory will not happen by itself, it need quite some work. Currently openQA is under heavy development to match the new needs. You can help improving it! The work is being coordinated in a progress.o.o project, the sources are available in a Github’s organization and there is even a talk to introduce you to the world of openQA development 😉

At some point, when openQA gets integrated well enough, users will be able to enjoy “almost” bug free Factory as a rolling distro. How bugfree it will be will depend on our test coverage of the distribution. What is the current state? We have basics pretty well covered, but still sometimes existing tests break and sometimes we miss more tests. If you want to help with making Factory better tested, you can get openQA running locally and start writing tests for stuff that matters to you! During a nice workshop in openSUSE Conference, Ludwig Nussel trained some geekos on how to get a local openQA running and start writing tests. Luckily, workshop was recorded so even if you missed the conference, you can watch it and start writing tests. New tests are welcome, although due to performance reasons (we want openQA to finish at some point, right?), not everything might get run every time. Even though, you can always run your own openQA instance for testing stuff that you care about and reporting to bugzilla!

Looks like there is a bright future in front of us with stable well tested Factory continually rolling forward. There is plenty of work to be done to achieve this, but progress made so far is starting to show results and we will approach the final goal faster as we get more people involved.