Home Home > Uncategorized
Sign up | Login

Archive for the ‘Uncategorized’ Category

Ruby: Do not use += in loops

October 8th, 2014 by

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

LSB Best Effort

August 25th, 2014 by

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.

Using docker 1.0 on openSUSE 13.1

June 16th, 2014 by

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/

openSUSE 13.2 Artwork Proposal

June 13th, 2014 by

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

openSUSE_13_2_proposal

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.

openSUSE Edu Li-f-e MATE

May 19th, 2014 by

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

MATE desktop environment

More screenshots.
(more…)

LXQT is ready for testing

May 15th, 2014 by

The stable branch of LXQT, the QT branch of LXDE is now available for openSUSE:13.1 and openSUSE:Factory.
Following are a few screenshots of lxqt, which will be quite familiar to any of you that dabbled with Razor-qt in the past.

Here is the Main Desktop (note, this is using the “flat” theme, and the default openbox windowmanager)
lxqt-main-desktop

LXQT can offer a fully composited desktop, through the compton compositor, and includes a GUI tool for configuring.
compton-conf

Resulting in a highly configurable composited desktop:
lxqt-qterm-dropdown

LXQT also provides a powerful configuration tool, which allows you to tweak things the way you like…
lxqt-config-center

So if you’re looking for something to try out, please, give it a shot.

Please keep in mind, we are considering this a “Beta” quality release, so there are still some rough edges.

Additionally, lxqt is currently un-branded for openSUSE, so I certainly wouldn’t turn down help from folks that are into helping out with that sort of thing.

Stable packages are available for openSUSE:13.1(i586, x86_64, armv6l and armv7l) and openSUSE:Factory (i586 and x86_64) at:
X11:lxde:lxqt

Unstable Packages (latest git pulls), are available for 13.1 and Factory, i586 at:
devel:cloverleaf:lxqt:UNSTABLE

And if you happen to be running Fedora, i586 and x86_64 packages are available at:
devel:cloverleaf:lxqt:fedora

Echoes from oSC’14: state of Factory and openQA

May 8th, 2014 by

No tests, no feature

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.

How to filter a certain class of hardware in dhcpd.conf

March 19th, 2014 by

To prepare the end of the XP world

Atfer 8th April 2014, Windows XP system will be Like children in the lions’ den, if connected to internet

In a network around, all the still running XP are all vmware virtual machine, and none of the end-users are the right to modify the settings of the virtual machine, nor has administrative right under XP

The idea is the simply to just suppress the gateway of the network.

Playing with dhcpd.conf

There’s lot of way to handle this classification, but I discover that you need to find the right syntax, and understand how the binary-to-ascii function of dhcpd work.

First binary-to-ascii remove any leading 0, then we will just readd them :-)

Extract of the dhcpd.conf

# binary-to-ascii remove leading 0 rebuild the complete MAC
set testmac = concat ( suffix (concat ("0", binary-to-ascii (16, 8, "", substring(hardware,1,1))),2), ":", suffix (concat ("0", binary-to-ascii (16, 8, "", substring(hardware,2,1))),2), ":", suffix (concat ("0", binary-to-ascii (16, 8, "", substring(hardware,3,1))),2), ":", suffix (concat ("0", binary-to-ascii (16, 8, "", substring(hardware,4,1))),2), ":",  suffix (concat ("0", binary-to-ascii (16, 8, "", substring(hardware,5,1))),2), ":", suffix (concat ("0", binary-to-ascii (16, 8, "", substring(hardware,6,1))),2) );

# Extract the only first 8 chars 
set testclass = substring(testmac, 0, 8);
# You will find a lot of this on internet but doesn't work
# set testmac = binary-to-ascii(16, 8, ":", substring(hardware, 1, 6));

# All our VMware VM use the same prefix
if ( testclass = "00:0c:29" ){
  # put dummy router
  option routers 127.0.0.1;
  # useful debug log
  log (info, "xp32 lease");
}else{
  # Default gateway for anyone else
  option routers 192.168.1.254;
  log (info, "standard lease");
}

That’s all for today

osc build with kvm on an encrypted volume group

March 15th, 2014 by

How-to build a initrd-virtio on a fully encrypted volume group

If like me you care about your data stored on your laptop, you certainly use a fully encrypted (excepted /boot) configuration based on lvm.

In my case I also like to create, build, fix packages locally with our tool osc. I’ve plenty of power, beefy ssd, so I dedicate a logical lvm for building cleanly package with qemu-kvm configuration, like obs does

Prepare the kvm building system

As root you create 2 lvm volume with lvcreate, one will be the build root, the other one will be the additional swap

In ~/.oscrc I enable the following parameters

build-type = kvm
build-device = /dev/mapper/vg0-lvobsbuild
build-swap = /dev/mapper/vg1-lvobsswap
build-memory = 4096
build-vmdisk-rootsize = 16000
build-vmdisk-swapsize = 4000
build-vmdisk-filesystem = ext4

You just have to adjust the Memory quantity and the device to what you create for your own environment.

(more…)

Trying to add some light

February 3rd, 2014 by

Lately there was some confusion regarding our communication. We, at the openSUSE Team@SUSE are deeply aware that our communication needs to be improved. So in the hope to make everything clear again, here is the summary to clear up what is really going on and what was not happening.

Long story short:

  • There WILL be openSUSE 13.2 in November 2014
  • 13.2 WILL have security and maintenance support provided by SUSE
  • We WILL have coolo as release manager for 13.2
  • SUSE is NOT decreasing manpower put into openSUSE
  • Everybody from the community is welcome and encouraged to be involved with, and if they want to, take over some parts of the release process and we will support you the best we can in doing that

Now for the long story.

Our team and only our team – openSUSE@SUSE – is going to work on improving ‘tooling’ side of the openSUSE project until August. These changes will benefit openSUSE by making it easier to produce better releases in the future.

Nothing changes for the rest of SUSE. SUSE is not abandoning openSUSE. The rest of SUSE will still do the same things they were doing until now and continue to keep openSUSE awesome. This includes Maintenance, Security, Infrastructure, and many other teams besides the openSUSE Team at SUSE who actively support the openSUSE project.

What is our plan?

Our plan is to make sure that future openSUSE releases are easier for everyone to produce. As we grow we could keep putting in more and more full-time release managers (if we find them somewhere), but this approach is probably unsustainable and, more importantly, goes against our desire to empower the community to do more as part of openSUSE.

Therefore, we decided to improve our tools to ensure that making a release is much more straightforward and reliable and we can reduce and distribute the workload needed for integration and release. To make this happen we need time and everyone from the team to work on adapting the tooling side. We also would welcome volunteers to help us with tools and with the following release(s).

With the release date now set in November (mirroring roadmap for 13.1), first milestone should be released in May. That is a perfect oportunity to go to openSUSE Conference in Croatia where we can meet up, gather volunteers to help and discuss how to work. Remember that openSUSE Travel Support is in place to sponsor everyone who needs financial help to get to the event.

Hopefully now we cleared things up a little and we are really sorry again for our poor communication – We’re going to work on it.

Your truely confused openSUSE Team