Dear friends!

From the bottom of my heart I would like to thank you for your support during the past elections for The Document Foundation Board of Directors. Without you my election would be never possible and I never took it for granted. I am thankful for your trust. You cannot even immagine how happy and grateful I am for your support. Especially in a moment where my relationship with our project undergoes major changes.

I pray to be always up to the task to co-guide our project with wisdom and integrity.

I love you

Fridrich

I now have Skype working, more or less, on one machine with openSUSE 13.1. I used the instructions at the openSUSE Support Database. The important things to realize here are: (1) Skype does not work out-of-the-box in openSUSE 13.1, but (2) it may start "working" (in a manner of speaking), if you install the right packages and run the Skype binary in the right way.

Update

On another machine where Skype was running fine on openSUSE 12.3, it stopped working (predictably) after I upgraded the machine to 13.1 using zypper dup. I reinstalled Skype, but the behavior was different than on the machine mentioned above. Skype would run, but after successful login it would crash with the following:

*** Error in `/usr/lib/skype/skype': double free or corruption (!prev): 0xec14e1e0 ***
======= Backtrace: =========
/lib/libc.so.6(+0x6dfd3)[0xf29a5fd3]
/lib/libc.so.6(+0x7418a)[0xf29ac18a]
/lib/libc.so.6(+0x74dcc)[0xf29acdcc]
/usr/lib/skype/skype(+0xbfaeba)[0xf6863eba]
[0x61776574]
======= Memory map: ========
de1ff000-de200000 ---p 00000000 00:00 0
...
... on and on, page after page of similar lines
...

Adding MALLOC_CHECK_=0 to the Skype command-line was enough to get it to run. However, I was no longer able to "Allow Skype to automatically adjust my mixer levels", because it would automatically set the microphone level to 100%, causing lots of noise and distortion. So I had to uncheck this option and set my microphone level manually. Sigh.

Overall conclusion

Avoid using Skype under Linux, if at all possible.

I had the pleasure of meeting Russell Pavlicek, who shares Xen community management responsibilities with Lars Kurth, at SUSECon last November and he, along with Dario Faggioli of the Xen community, poked me about writing a blog post describing the state of Xen support in libvirt.  I found this to be an excellent idea and good reason to get off my butt and write!  Far too much time passes between my musings.

Xen has had a long history in libvirt.  In fact, it was the first hypervisor supported by libvirt.  I’ve witnessed an incredible evolution of libvirt over the years and now not only does it support managing many hypervisors such as Xen, KVM/QEMU, LXC, VirtualBox, hyper-v, ESX, etc., but it also supports managing a wide range of host subsystems used in a virtualized environment such as storage pools and volumes, networks, network interfaces, etc.  It has really become the swiss army knife of virtualization management on Linux, and Xen has been along for the entire ride.

libvirt supports multiple hypervisors via a hypervisor driver interface, which is defined in $libvirt_root/src/drvier.h – see struct _virDriver.  libvirt’s virDomain* APIs map to functions in the hypervisor driver interface, which are implemented by the various hypervisor drivers.  The drivers are located under $libvirt_root/src/<hypervisor-name>.  Typically, each driver has a $libvirt_root/src/<hypervisor-name>/<hypervisor-name>_driver.c file which defines a static instance of virDriver and fills in the functions it implements.  As an example, see the definition of libxlDriver in $libvirt_root/src/libxl/libxl_driver.c, the firsh few lines of which are

static virDriver libxlDriver = {
.no = VIR_DRV_LIBXL,
.name = “xenlight”,
.connectOpen = libxlConnectOpen, /* 0.9.0 */
.connectClose = libxlConnectClose, /* 0.9.0 */
.connectGetType = libxlConnectGetType, /* 0.9.0 */
….
}

The original Xen hypervisor driver is implemented using a variety of Xen tools: xend, xm, xenstore, and the hypervisor domctrl and sysctrl interfaces.  All of these “sub-drivers” are controlled by an “uber driver” known simply as the “xen driver”, which resides in $libvirt_root/src/xen/.  When an API in the hypervisor driver is called on a Xen system, e.g. virDomainCreateXML, it makes its way to the xen driver, which funnels the request to the most appropriate sub-driver.  In most cases, this is the xend sub-driver, although the other sub-drivers are used for some APIs.  And IIRC, there are a few APIs for which the xen driver will iterate over the sub-drivers until the function succeeds.  I like to refer to this xen driver, and its collection of sub-drivers, as the “legacy Xen driver”.  Due to its heavy reliance on xend, and xend’s deprecation in the Xen community, the legacy driver became just that – legacy.  With the introduction of libxenlight (aka libxl), libvirt needed a new driver for Xen.

In 2011 I had a bit of free time to work on a hypervisor driver for libxl, committing the initial driver in 2b84e445.  As mentioned above, this driver resides in $libvirt_root/src/libxl/.  Subsequent work by SUSE, Univention, Redhat, Citrix, Ubuntu, and other community contributors has resulted in a quite functional libvirt driver for the libxl toolstack.

The libxl driver only supports Xen >= 4.2.  The legacy Xen driver should be used on earlier versions of Xen, or installations where the xend toolstack is used.  In fact, if xend is running, the libxl driver won’t even load.  So if you want to use the libxl driver but have xend running, xend must be shutdown followed by a restart of libvirtd to load the libxl driver.  Note that if xend is not running, the legacy Xen driver will not load.

Currently, there are a few differences between the libxl driver and the legacy Xen driver.  First, the libxl driver is clueless about domains created by other libxl applications such as xl.  ‘virsh list’ will not show domains created with ‘xl create …’.  This is not the case with the legacy Xen driver, which is just a broker to xend.  Any domains managed by xend are also manageable with the legacy Xen driver.  Users of the legacy Xen driver in libvirt are probably well aware that ‘virsh list’ will show domains defined with ‘xm new …’ or created with ‘xm create …’, and might be a bit surprised to find this in not the case with the libxl driver.  But this could be addressed by implementing functionality similar to the ‘qemu-attach’ capability supported by the QEMU driver, which allows “importing” a QEMU instance created directly with e.g. ‘qemu -m 1024 -smp …’.  Contributions are warmly welcomed if this functionality is important to you :-).

A second difference between the libxl and legacy Xen drivers is related to the first one.  xend is the stateful service in the legacy stack, maintaining state of defined and running domains.  As a result, the legacy libvirt Xen driver is stateless, generally forwarding requests to xend and allowing xend to maintain state.  In the new stack, however, libxl is stateless.  Thererfore, the libvirt libxl driver itself must now maintain the state of all domains.  An interesting side affect of this is losing all your domains when upgrading from libvirt+xend to libvirt+libxl.  For a smooth upgrade, all running domains should be shutdown and their libvirt domXML configuration exported for post-upgrade import into the libvirt libxl driver.  For example, in psuedo-code

for each domain
virsh shutdown domain
virsh dumpxml > domain-name.xml
perform xend -> libxl upgrade
restart libvirtd
for each domain
virsh define domain-name.xml

It may also be possible to import xend managed domains after upgrading to libxl.  On most installations, the configuration of xend managed domains is stored in /var/lib/xend/domains/<dom-uuid>/config.sxp.  Since the legacy Xen driver already supports parsing SXP, this code could be used read any existing xend managed domains and import those into libvirt.  I will need to investigate the feasibility of this approach, and report any findings in a future blog post.

The last (known) difference between the drivers is the handling of domain0.  The legacy xen driver handles domain0 as any other domain.  The libxl driver currently treats domain0 as part of the host, thus e.g. it is not shown in ‘virsh list’.  This behavior is similar to the QEMU driver, but is not necessarily correct.  Afterall, domain0 is just another domain in Xen, which can have devices attached and detached, memory ballooned, etc., and should probably be handled as such by the libvirt libxl driver.  Contributions welcomed!

Otherwise, the libxl driver should behave the same as the legacy Xen driver, making xend to libxl upgrades quite painless, outside of the statefullness issue discussed above. Any other differences between the legacy Xen driver and the libxl driver are bugs – or missing features.  Afterall, the goal of libvirt is to insulate users from underlying churn in hypervisor-specific tools.

At the time of this writing, the important missing features in the libxl driver relative to the legacy Xen driver are PCI passthrough and migration.  Chunyan Liu has provided patches for both of these features, the first of which is close to committing upstream IMO

https://www.redhat.com/archives/libvir-list/2014-January/msg00400.html
https://www.redhat.com/archives/libvir-list/2013-September/msg00667.html

The libxl driver is also in need of improved parallelization.  Currently, long running operations such as create, save, restore, core dump, etc. lock the driver, blocking other operations, even those that simply get state.  I have some initial patches that introduce job support in the libxl driver, similar to the QEMU driver.  These patches allow classifying driver operations into jobs that modify state, and thus block any other operations on the domain, and jobs that can run concurrently.  Bamvor Jian Zhang is working on a patch series to make use of libxl’s asynchronous variants of these long running operations.  Together, these patch sets will greatly improve parallelism in the libxl driver, which is certainly important in for example cloud environments where many virtual machine instances can be started in parallel.

Beyond these sorely needed features and improvements, there is quite a bit of work required to reach feature parity with the QEMU driver, where it makes sense.  The hypervisor driver interface currently supports 193 functions, 186 of which are implemented in the QEMU driver.  By contrast, only 86 functions are implemented in the the libxl driver.  To be fair, quite a few of the unimplemented functions don’t apply to Xen and will never be implemented.  Nonetheless, for any enthusiastic volunteers, there is quite a bit of work to be done in the libvirt libxl driver.

Although I thoroughly enjoy working on libvirt and have healthy respect for the upstream community, my available time to work on upstream libvirt is limited.  Currently, I’m the primary maintainer of the Xen drivers, so my limited availability is a bottleneck.  Other libvirt maintainers review and commit Xen stuff, but their primary focus is on the rapid development of other hypervisor drivers and host subsystems.  I’m always looking for help in not only implementation of new features, but also reviewing and testing patches from other contributors.  If you are part of the greater Xen ecosystem, consider lending a hand with improving Xen support in libvirt!

If you are not a programmer, and still want to help LibreOffice, there are many ways; one of them is submitting good bug reports. And a good bug report means a report with as much information as possible - one that contains the exact version, file(s) that caused the issue, description of the steps that lead to the problem.

In case LibreOffice crashes for you (sorry for that! - we are trying hard to avoid such situations, but it still may happen), and you are on Windows, description of the problem used to be all you were able to do - but now you can do more: you can attach a backtrace, and help the developers tremendously.

What is a backtrace? It is a log describing where exactly the program failed. It used to be very hard to get one on Windows, as you had to build your own LibreOffice.

Now it is much easier - you can provide such backtraces either using the official builds starting with LibreOffice 4.2.0rc1, or using the daily builds, without the need to build anything - you can just connect to a so called symbols server, and that's it.

Official releases

Just install LibreOffice 4.2.0rc1 (or later when available), and follow the information on the How to get a backtrace wiki page, it will lead you through the process. Thank you +Christian Lohmaier so much for setting that up!

Daily builds

I have updated my tinderbox to produce daily builds that are ready for debugging too. If you see a crash, it is worth checking if it happens in the most recent daily builds too - so installing this will allow you to check it, and directly provide a backtrace too.

Please try it out - I am looking forward to seeing backtraces in the your bugreports. In case you have trouble with the How to get a backtrace description, or the process itself, please let me know - or improve the page yourself; it is wiki, after all :-)

Oh, and all this wouldn't be possible without Luboš Luňák, +Fridrich Strba and others who have helped to connect various pieces together - thank you!

Poor man's deduplication: scan directories to find duplicate files and remove all but one. This blog entry looks at two tools: fdupes and fslint
Read more »

There is a Perl module that I have been developing. It is now finding its way onto CPAN and the openSUSE Build Service; the process of reaching that goal, however, was a bit tedious -- hence this blog entry which will describe the workflow so I won't have to reinvent the wheel each time I want to do this again.
Read more »

Recently I decided to update my blog to something that will be less awkward than NanoBlogger I have been using until now. I mean, writing the entries in vim is great, running the nb script is easy, but the turnover to preview it, fix, run the script again etc. is just annoying.

Now I moved my old blog to holesovsky.blogspot.com, which will be much easier for me to handle. With some Perl scripting, I even converted all the old entries here, so that the old blog can really RIP.

Small note to the conversion

When you are using the blogger.com's Import XML feature, and it looks like the import is taking too long (minutes or so), the answer is simple: Your XML was not accepted by blogger.com. I have seen reports of people waiting several hours to import the blog.

Don't wait in such cases - it was just that an error occurred, and the UI has not reported that. Just try to find out what is in the XML that could have caused the import to get stuck - usual suspects are &'s instead of &quot; or OTOH things like &Acaron;, or other less common escapes.

1. I think some people from the openSUSE community has perceived this first mail as a negative criticism to the project and their contributors. Cold analysis based on numbers do not provide a complete picture of the project... but provides a good one, in my opinion. I wrote the below mail/article thinking about a better future, not to revisit a past I am part of. 
2. A summary of the proposals was published in an openSUSE Team blog post. Please read it to get in context. As stated in that article, this first mail/article has as goal to share the motivations behind the later published proposals, trying to open a discussion about our current state that can lead us to agree on a picture we can use as starting point.
3. At the end of the article/mail, I proposed some questions. If you are interested in answering them (I would appreciate it), please:

• Subscribe to the openSUSE-project mailing list. Check how to do it first. 
• Make your comments as a reply of this thread.

Otherwise, in order to keep the debate centralized (for record purposes also), I will post/summarize your answers and comments also in that mailing list.

----------
 


INTRODUCTION/GOALS

• Share a picture as a starting point of discussion.
• Use the discussed picture as a reference to agree on actions we all can/want to execute. 

FIRST STEP: PIECES OF THE PUZZLE

One of the first things we did was digging into numbers that provided us information about the status of the project. Data cannot be the only source to create a complete picture, but it is helpful as first step.

• Alberto Planas talk at oSC13: openSUSE in Numbers[1]
• Alberto Planas' slides from the above talk[2]
• First openSUSE Team blog post: Numbers in openSUSE[3]
• Second openSUSE Team blog post: More on statistics[4]
• Jos post about numbers[5] 

1.- Downloads



2.- UUIDs (installations that update regularly)

• Looking at the number of machines that regularly update against openSUSE repositories (daily, weekly and monthly), we can easily conclude that the situation is very stable. The speed of growth (daily and weekly stats) or decline (monthly) is low.
• What the graph do not show is the acceleration. It has been negative (small in value) for quiet some time now.
• When looking at the architectures, we see that x86_64 is more popular than i586. This behavior is accelerating, as confirmed in the download numbers collected for 12.3
• When looking at the mediums where those installations come from, we clearly see three dominant ones: .iso (dvd version), ftp (net installs) and Live CD.
• There is a relevant detail that Alberto mentioned in his talk. More than half, almost 2/3, of openSUSE installations are not using the last version many weeks after Release date. There is also a significant amount of installations using unmaintained or Evergreen versions.

3.- Factory and Tumbleweed installations/"users"

4.- Contributors to factory and devel projects


5.- Social media and comparison with Fedora


SOLVING THE PUZZLE


ADDING CONTEXT TO THE PICTURE

YaST switched to the GPL license back in 2004, but there were still a lot of obstacles to easy contributions to the project. There was a bunch of changes in the past to improve contribution to the project, like switching from the openSUSE subversion server to GitHub, generating documentation to doc.opensuse.org or having public IRC. But we are not satisfied and do even more steps to make it easy to contribute to YaST.

The most visible action in the last year was the conversion from YCP to Ruby. We found that having a special language just for YaST made some sense in the past, but now becomes useless and makes obstacles for newcomers which must at first learn a language before they can change anything. Ruby is a well known language with a nice ecosystem around including benchmarking, profiling, debugging or testing frameworks. The latest mentioned testing framework is quite important, because good test coverage allows reducing of fear from changes. For tests we chose the well known framework RSpec, so people coming from the Ruby world know it and others find it intuitive.

Related to tests are also continuous integration that tests code after each code change and automatically sends new packages to the devel project and to Factory if needed. We make our CI node publicly visible on the openSUSE CI server, so everyone can see if build succeeded and what is the reason if it failed.

We also decided to help newcomers with a quick introductory documentation. One page recently updated to reflect the current state is about code organization which helps newcomers to orient in current YaST modules. The content is a bit terse and a minority of pages links to some old tutorials and documentation, but we take care to quickly react to questions and suggestions.

Another change is deletion of the internal YaST IRC channel and now all communication happens on the #yast Freenode channel. This change really increases the chance that you catch YaST developers on IRC. Others ways are the YaST mailing list, Bugzilla, GitHub or openSUSE feature tracker.

So let’s start hacking YaST and if you find any obstacle, contact us, so we can remove it.