I spent the last 4 days in Bristol to attend to "Parallel Programming with MPI" course, provided by HECToR which is the UK's high-end computing resource, funded by the Research Councils and available for researchers at UK universities, and by NAG - The Numerical Algorithms Group specialized in the provision of software for the solution of mathematical, statistical and data mining problems.

The course covered the Introduction to MPI and Advanced MPI.  MPI (Message Passing Interface) is the de facto standard for parallel programming. I have also some experience with PVM (Parallel Virtual Machine) my Master Thesis was based on that, and I learnt a lot about OpenMP, so I wanted to extend my knowledge for Parallel Programming with MPI.

The course introduced the concepts and terminology of High Performance Computing (HPC).  After an detailed look at point-to-point and collective communication, we learnt some more advanced topics: Cartesian topologies, MPI derived data types, user-defined binary operators, groups and communicators. We also had a lot of practical exercises to solve.  It was a great course.

As you might know, the Shuttle Discovery is currently in space, docked to the International Space Station and delivering the last large solarpanel+battery set.

NASA is streaming most of the time live from the station / outside / shuttle via its webcast
engine on www.nasa.gov.

So, how to watch with openSUSE 11.0?

- Realplayer plugin - does not work on x86_64
- no windows media player
- no quicktime player

After several more tries to get Opera, Konqueror or Firefox to work and display video, I found the best solution.

as root (if wine is not yet installed):
zypper in wine
as user:
winetricks firefox3
... follow the dialogs for installation
winetricks quicktime72
... follow the dialogs for installation

there will be a now be new Firefox icon on the desktop and in the Programs menu, start it.
open http://www.nasa.gov/multimedia/nasatv/index.html?param=public.


=> Voila, instant space goodness.

(and yes, it is very sad that while it offers _3_ ways of video, _none_ work by default.)

Hello,  I just released a update to evolution-mapi. 0.26.0.1 has fix for Bug 574784 without which the package is totally unusable.

Thanks !

I just commited:

2009-03-14 Luis Medinas <lmedinas@gnome.org>

* NEWS:
* configure.in:

Update NEWS file and bump to 2.26.0.
This marks the first Brasero stable release into
the official GNOME Desktop platform.
Thanks to everyone who belived and contributed.

OOP in YaST GUI: Event handling
------------------------------

Hello, here I am again ...

I played with idea of event handling, but if possible better way than we do in ycp now.
Also using inheritance: when you define some behavior, you can inherit class and override handling method or just use objects and handling will be done automatically (using composition).
So the basic idea is that event loop is done automatically and it executes handle function of object that is responsible for such event or which is listening.

Event loop is implemented in parent object (root object in hierarchy - CDialog). Because of this, all inherited objects (MainDialog, PopupDialog) will have this functionality automatically.

class CDialog:
    def __init__(self):
       self.factory = yui.YUI.widgetFactory()

    def listen(self, newList):
       self.listeners = newList
       etype=-1
       while etype!=5:
           event = self.dialog.waitForEvent()
           etype = event.eventType()
           for item in self.listeners:
                if (item.getInstance()==event.widget()): item.handle(event)

class CButton:
  def __init__(self, factory, parent, label):
    self.button = factory.createPushButton( parent, label )
  def getInstance(self):
    return self.button

...
self.pbAdd = CButton(self.f, hbox2, "&Add")
self.pbEdit = CButton(self.f, hbox2, "&Edit")
self.pbDel = CButton(self.f, hbox2, "&Delete")
...
d.listen([self.pbAdd, self.pbEdit, self.pbDel])
...

When you want to handle something (button click for example), you need to:
- define function that will executed
- connect function to the object
- start event loop with list of "listeners" (objects with connected functions)

There are 3 kinds of functons:
1 - function without any connection to object

self.pbAdd.handle = self.handleAdd

2 - function with connection just to object

self.pbAdd.handle = new.instancemethod(mujhandler, self.pbAdd, self.pbAdd.__class__)

3 - function with visibility outside of the object (example: function can see whole dialog)

self.pbAdd.handle = new.instancemethod(self.handleAdd.im_func, self.pbAdd, self.pbAdd.__class__)

Code is submitted into subversion

How to test this code:
- svn checkout http://svn.opensuse.org/svn/yast/branches/tmp/mzugec/python-yui/
- make sure you have installed packages: python-yui, yast2-libyui, yast2-qt, yast2-ncurses
- run "./main.py" to see Qt version, "unset DISPLAY;./main.py" for ncurses version (unfortunately,in ncurses only way how to terminate application is to kill it, TODO)

As Murphy's law states, if things can go wrong, they certainly will and usually at the most inopportune moment. Not surprisingly, as SLE11 slowly approached to becoming gold, the weirdest bugs, corner cases and users making up the most exotic test scenarios started to pop up from just about everywhere. The pieces of code I maintain were not an exception.

Alors, this time, I'm not going to write about some exciting new stuff I'm hacking in YaST (well, of course I'm currently working on something, but I'm going to make it public when the time comes - in the moment I'll be quite certain that it is not absolute fiasco :)). The final phase of product release is an ideal time for sharing quantum theory of bugs. Take this post as an example of junk literature ;-)

I'm sure every sw engineer knows the situation. A bug 100% reproducible at customer's site, with sufficiently high priority and bunch of important managers in Cc: that mysteriously disappears as soon as you try to reproduce it. It smells the debugger from afar and flees quickly enough ;-) That is so-called Heisenbug. Quoting Wikipedia:

A heisenbug (named after the Heisenberg Uncertainty Principle is a computer bug that disappears or alters its characteristics when an attempt is made to study it. The name heisenbug is a pun on the Heisenberg uncertainty principle quantum physics concept which is commonly (yet inaccurately) used to refer to the fact that in the Copenhagen Interpretation model of quantum mechanical behavior, observers affect what they are observing, by the mere act of observing it alone"

Or look at Schroedingbug - another one of those mysteries. Let's see what Wikipedia says again:

A schroedinbug is a bug that manifests only after someone reading source code or using the program in an unusual way notices that it never should have worked in the first place, at which point the program promptly stops working for everybody until fixed.

SLE11 debugging phase was sufficiently long to come across one of those, too. I was reading the source code (of YaST ncurses packager this time), cursing myself how could I possibly overlook such an obvious usage of NULL pointers, wondering how comes it has never crashed for anybody and suddenly bang! There is was - a critical bug from our Three-Letter-Customer, complaining that "yast -i crashes" . Guess where :-)

If you love quantum physic humour or if you just need some entertainment in the quantum of bugs you're dealing with, point your browsers here and read about bohrbugs, mandelbugs, phase of the moon bugs and other nightmares.

And while the customers are testing bugfixes and another set of packages is being built, I can moan and groan on IRC query with Uwe. It was actually him, who pointed me non-quantum layer 8 bug notion (if you don't get it, review your OSI layer knowledge first ;-)). He told me: "Go ahead and tell these Three-Letter-Customer guys that what they are experiencing is a layer 8 bug. It will make them feel special." So I did. They didn't seem to share the same sense of humour :-) :-D Anyway, we agreed that quantum debugging should be discovered ASAP.

Dear Ladies and Gents,
version “3.0.6” of openSUSE-Enlightenment (SOAD project) is out:

Download page

GWDG mirror will be updated to the version “3.0.6” on Monday (next week).

Changelog from 3.0.5 to 3.0.6 version
* new updated kernel (version 2.6.27.19_3.2)
* updated EFL/E to svn_r39423 (2009-03-09)
* updated OOo (version 3.0.1.3)
* fixed “Del” key operation in “xterm”
* fixed the segfault during the first login to Enlightenment-DR17
* improved “Wicd” init script
* added GTK+ “Unity” theme
* removed “atl1e” driver for “Attansic” LAN cards (found on the eeepc1000* mostly)
* following drivers are added: “rtl8187”, “rt73”, “rt61”, “r8101”, “r8168”
* improved list of a default installed repositories
* overall code/software/packages update to the current openSUSE-11.1 state
* some useful Wi-Fi utilities added along with the advanced documentation (Tutorials…)
* other misc. enhancements

In general – this version just works. The only disadvantage is that “LiveCD” version require 800M media (or a blank DVD-R/RW disk) and cannot be recorded to the standard 700M CD-R/RW. The absence of a “delta” images are due to the huge update of a packages – “delta” has no sense this time.

We’re also recommend you to visit our two new modest wiki pages and read a bit about:
Ecomorph
Wicd

Btw, it looks like “Wicd” have a chance to be a default network configuration tool for KDE-4.3 (Dev. Team are constantly improving the package, that’s great!).

LiveCD: list of installed packages
USB-stick: list of installed packages

Huge thanks to Mikhail Kazakov for a help in preparation of this release version!

Enjoy!

Regards,
sda

P.S. The curious persons are welcome to glimpse at the small “Detailed uncompressed LiveCD packages size” pdf file.

One of the outstanding features of openSUSE is the Sat solver for package dependency resolution.

Somewhat unknown to most developers, Satsolver provides bindings for the three major scripting languages: Perl, Python and Ruby. The bindings provide an easy way to learn about the Satsolver API, to explore package metadata and play what-if scenarios installing, updating and deleting packages.

The bindings are created using SWIG together with an application layer on top of the raw libsatsolver. The focus is on usability and support of the scripting language, while hiding internals of the Satsolver implementation.

The bindings documentation are hosted at http://www.suse.de/~kkaempf/satsolver-bindings-ruby for now. I hope to find a permanent place at opensuse.org in the future.

The documentation is created using rdoc with a SWIG specific parser. rdoc comes with Ruby, just install the ruby package for the rdoc framework. The swig parser is currently hosted inside the Satsolver git repo.

Although based on a Ruby specific tool, the use of SWIG ensures portability across languages. Example uses of the bindings are available for Perl, Python and Ruby If you need Satsolver bindings for other languages, drop the ZYpp developers a mail.

Today i've listen for the first time the new Chris Cornell album called Scream. Right after listening to a few songs i put my hands on the top of my head and said "WTF is this !?". I didn't like the album but the man still has his voice. He was one of the best Rock/Metal voices ever.

Chris i'm sure your fans miss your Soundgarden, Audioslave and Temple of the Dog past. His first two solo albums were ok but still different from the past. I loved his screams on songs like: Beyond the Wheel, My Wave, Hands all over, Jesus Christ Pose, Nothing to say, Cochise, Show me how to live, Mission,  Can't Change Me, Say Hello to Heaven and Hunger Strike.

Why this change ? Because you're feeling old ? Because you're in love ? Because you want to try reaching to new markets ?

Most of the flash devices assume that fat is the only file-system. And there are plenty of electronic devices that run linux on fat. So just to know what it is to run linux on vfat, I tried it myself.

The openSUSE 11.1 installer wont allow you to partition the root as vfat. So I made 2 partitions, one ext3 and one vfat. Installed on ext3. Copied the whole partition to fat. I copied original files in place of symbolic links. Added vfat filesystem module to initrd . Modified grub boot from the fat partition with init=/bin/bash.

FAT's lack of support for posix file-permissions. was easy to overcome by mounting with all permissions to everyone, without users or noexec. It doesn't support symlinks, and special files. mknod will fail. But /dev is a tmpfs and it just copies the persistent files from /dev to the tmpfs on boot, instead of copying I created fresh device files in tmpfs. `mount` failed trying lock the file /etc/mtab. Mounting with -n worked. I guess plenty of things would fail if I try to run a proper desktop on FAT as it is.

I booted only to /bin/bash. When I tried doing a "exec init 1", it complained something like cannot remove /var/run/do_confirm. I didn't proceed further. This was a fun way to kill time while getting some insight of the booting process.