Stephan Kulow asked on the Factory mailinglist if anyone was dual-booting Windows Vista and openSUSE 11.0:

Both me and the reporter of bug 396444 have a broken vista
boot after RC1 instalation (I ignored the problem as I did
not boot vista since quite some time, so it could just as well
be broken with alpha0).

So I wonder if other's vista is still functional? Unless I
know what's causing this, this bug is one of those that will
delay 11.0, so please help me.

Since there weren’t many people on the mailinglist who were, if you do boot Vista and SUSE 11.0, with success or otherwise, please let us know on the opensuse-factory@opensuse.org mailinglist

I recently have come across two quite different ugly gotchas in Windows. Oh well, so what else can one expect you might say... but in these cases I really wonder what on Earth the designers were thinking.

SO_RCVTIMEO and SO_SNDTIMEO

Winsock (the implementation of the Unix ("BSD") socket API on Windows) is mostly quite source compatible with the normal socket API as present on all Unixes. There are some well-known differences that most people who port Unix network code to Windows (or the other way around, although I guess that is less common) know about, like:

• Sockets are not known to the C library, i.e. they are not file descriptors: use recv() and send() instead of read() and write(), use closesocket() instead of close(). Winsock calls don't set errno. The error code is returned by WSAGetLastError()
• Include <winsock2.h> and <ws2tcpip.h> instead of <netinet/in.h>, <netinet/tcp.h> <arpa/inet.h> <sys/socket.h> and <nedb.h>.
• Initialise Winsock before use with WSAStartup().
• select() works only for sockets (bummer!)
  

Failing to handle these differences (by using some simple wrapper macros, for instance) will lead to obvious run-time errors and misbehaviour, so they should be easy to notice.

One apparently not very well known, and easy to miss, issue is that the SO_RCVTIMEO and SO_SNDTIME options to setsockopt() and getsockopt() take option values that are int, not struct timeval. Winsock apparently ignores the option value size parameter. The compiler can't warn either as the third parameter to setsockopt() is a generic pointer anyway.

So, if you keep Unix code that passes a pointer to a struct timeval, setsockopt() gladly uses the first int in the struct, the tv_sec field, as the option value, interpreting it as milliseconds. Your code thinks it sets a socket timeout to 10 seconds, for instance, and actually sets it to 10 milliseconds.

As you might imagine, this can lead to interesting problems. Attempting to set a longish timeout like 30 seconds, actually then means 30 milliseconds. But that is still long enough that many things work, at least in a local network or locally on one machine. So you won't necessarily notice anything fundamentally broken or strange right away.

Windows Installer internal error 2716

Windows Installer is an endless source of enjoyment. I ran into an unexpected problem when testing a Windows Installer patch (.msp file) I had built: msiexec bluntly reported

Internal error 2716: Could not create a random subcomponent name for component 'g_f_share_c_sc_uiconfig_zip__share_c_soffice_cfg_modules_schart_accelerator_en_us'

Googling turned up an interesting blog post from the Windows Installer team. There you will find this gem:

A careful reader will notice a problem with the subcomponent generation algorithm. See it? It's the component name is based off the first 40 characters of the component. What happens if the the first 40 characters of all the components in a package are identical? The Windows Installer has code to look for collisions and increment an index until one is not found. Turns out there's a arbitrary limit of 100 iterations of that loop.

So, in other words, in some situations (namely, when applying patches, and some other cases, see
another blog post) Windows Installer uses just the first 40 characters of a component name as the name for some "temporary component" thingie. It does, cleverly enough, realize that this might not be unique, so it uses a workaround: it appends a number to make the temporary component name unique. But for some reason it only does this up to the number 100. If there are more than 100 components whose names are not unique in the first 40 characters, it will fail.

I fail to see any sense in this... First, why this arbitrary truncation at 40, why not use the whole component name and suffix that with a running counter? And why use the arbitrary limit of 100 when suffixing a number to the truncated component name? "Fixing" the silly use of one arbitrary limit by using another arbitrary limit?

Of course, there is no mention of this in the Windows SDK documentation for the Component table. As far as I can see the only mention of this 40 character limit is on the "Windows Installer Error Messages" page, where for error 2716 it says:

May occur if the first 40 characters of two or more component names are identical. Ensure that the first 40 characters of component names are unique to the component.

Oh well...

I’ve got the openSUSE 11.0 installation walk-throughs mostly done! I say mostly, I did get the DVD installation tutorial completely done and published, but since we have a little over two weeks, if anyone has anything to add or correct to it, there’s plenty of time to do so. I also mostly finished a walk-through of the Live CD installation, but I’ve still got a few screenshots to add and corrections to make, so if you’ve got time take a look at both and help out, help us make them awesome easy to follow by release day!

I thought about just copying the instructions from the 10.3 Installation tutoral and adjusting them to 11.0, but since there were so many changes in the installation it would be more trouble than it would be worth.

So let’s raise a toast to the YaST developers for making the new installers really nice and spiffy! And thanks to Jonathon Arnold, hieronymus on Twitter, for providing me with the screenshots for the DVD installation!

Also, since I think this is my first post on Planet SUSE, hey everybody! I’ll just link to my bio.

Today, well actually yesterday, was the last day of Linuxtag in Berlin. I was a little bit worried because i had to make sure the openSUSE day and the booth running smooth. So sorry if i had kind of bad temper in the morning … Thanks to everbody who helped at the booth, when i went down from the conference room to look at it it ran perfectly!

We had again a mixed count at the talks … I’m not sure which talk was visited the most, probably the Laptop 2.0 talk from Timo, Holger and Helmut (yes, i got your papers …), or the Talk from Marcus about Wine. Very close follower was Henne with his Freevo talk. I taped all the talks, but to be honest i’m not sure if the recordings are that good … quite hard for me to tune the picture on a tiny display. We will see it on Monday …

At the booth we gave away approx. 1700 openSUSE 10.3 PromoDVDs if i counted correctly, there was just one box with 60 DVDs left, because it was hidden somewhere. We also gave away a lot of our new openSUSE Laptop stickers. The kind you can put over the one with the four color window/flag

So thanks again to all who helped: Moenk and his friends from Linux-club.de, Christian, Jan-Simon, the SUSE and Novell guys who helped also at the booth and of course the Linuxtag team! (sorry if i forgot somebody, i need sleep).

There will be more verbose mail on opensuse-project next week, stay tuned …

btw: no new photos today, my cam died … i managed somehow to break the display in my pocket. If you made photos at the Linuxtag, please add a link in the comments, thanks!

btw2: i hope everbody who drove home by train is home now. We heard there was a big problem with the trains in germany.

A couple of days ago, I dug out my old laptop, the screen of which had given up the ghost a few months ago, and switched it on. To my surprise, it was working perfectly, which is great, because my work laptop is about to be taken away as they roll out a load of extremely fast desktops. Great for work, not so great for me. But at least my old laptop has decided not to be broken any more.

For the last year or so, since I had my nice new work laptop, I've been running openSUSE on an external USB hard drive (which surprisingly, benchmarked faster than using the internal drive), and I've been using KDE 4.0. I know my last post on this blog said I'd reverted to 3.5, but I tried 4.0.1 when it came out (or possible 4.0.2?), and discovered the actual show stoppers had been fixed, and the irritations were small enough I could live with them.

Anyway, onto the 'wow'. Since my old laptop had a clean install of openSUSE 10.3 on it and I didn't mind about messing it up with an unstable version of KDE, I put the unstable KDE snapshot version on instead of 4.0. And I think the word which best sums it up is 'Wow'. It's really, really good.

There are some bits in particular that I liked: being able to resize the panel; the panel for icons on the desktop; the beautiful highlight for icons; the alt-f2 thingy (I can never remember its proper name) which is brilliant, and looks and works so well I keep pressing alt-f2 and typing stuff in even though I don't need to run any programmes; the way you can style plasma easily; the way plasma styles work so much better than before; the pim programmes being KDE4ified; the sounds; the plus/minus symbols for selecting/deselecting icons (brilliant idea); everything seems more responsive (even on this old laptop); things looking good even without compositing switched on...

So, great job everyone. This beta is fantastic.

"Sage is a huge distribution of free open source mathematical software:

• Algebra and calculus: Maxima, SymPy
• High precision arithmetic: GMP, MPFR, MPFI, quaddouble, Givaro
• Commutative algebra: Singular
• Number theory: PARI, NTL, mwrank, ECM, FLINTQS, GMP-ECM
• Exact linear algebra: LinBox, IML
• Group theory: GAP
• Scientific computation: GSL, SciPy, NumPy, cvxopt
• Statistical computation: R
• Graphics (2d and 3d): Matplotlib, Tachyon3d, Jmol

Sage has a highly developed unified collection of pseudo-tty based interfaces that make it is possible to make extensive use of Maple, Mathematica, Magma, Matlab, GAP, Maxima, Singular, PARI, and many other systems from anywhere within a single Sage program." It is available for Linux, Mac OS X and Windows or you can download the source code.

Check here for a short overview or check Sage webpage for more.

Out of total insanity I promised Adrian a couple of weeks ago to test local installation of the OBS build service and interconnect it with the build.opensuse.org instance. Last night I couldn’t sleep due to the heat, so I finally did. Half an hour later, everything was installed and set up correctly according to the README.SETUP instructions in the obs-server package. I’ve fixed a couple of small issues in the README while doing so.

This morning, Michael Schroeder fixed the remaining bugs in the scheduler so that it actually runs. And now it builds

Source and binary interconnects work fine, so I can e.g. branch a package that is somewhere in the openSUSE buildservice (some KDE:KDE4: package or even openSUSE:Factory) and modify it locally in a test project, and watch the resulting build failures. There are some smaller issues with “osc linkpac” and “osc branch”, but editing the _link  files directly works.This way one can do experimental changes to packaging without actually breaking the repository for all other users, or slow down the build power ressources for everybody else due to unnecessary rebuilds.

As a test case, I’ve imported KDE 4.0.5 packages into a local branch of KDE:KDE4:STABLE:Desktop for testing. More seems possible, like for example doing a daily rebuild of the KDE 4.

Really cool stuff. Buildservice guys, keep rocking!

If you are interested in a short overview about what is Scientific Programming and which are the tools used in general, here is a short but very nice article: A case study on large-scale parallel scientific code development. Just a short summary:

"All codes use the message passing interface (MPI) library to achieve parallelism. In addition, each code uses external libraries for features such as

• I/O (HDF, NetCDF, CGNS, or Panda);
• mesh operations, including adaptive mesh refinement (ParaMesh, Mesquite, Metis, MeshSim, or SAMRAI);
• computational geometry (CGAL);
• linear algebra (BLAS, LAPACK), and tools for solving sparse linear systems and systems modeled by partial differential equations (PETSc, Hypre, or Clawpack).

While these codes use parallel libraries that sit atop MPI, developers still had to write raw MPI code to achieve desired functionality."

Yes, long time has passed since my last post (really strange, isn’t it :D ). It has been a busy period, full of work, dog training and… coding (fortunately!).

During this time I’ve been working on XesamQLib creation. This is a Qt based library for accessing Xesam services. Its API is going to be similar to Xesam-glib one and it will make life easier for developers who want to interact with programs exposing Xesam service (who talked about Strigi? :D )

Right now I’m finishing to clean the code, in order to publish a first version of XesamQLib on KDE repository. I’ll keep you updated.