Today I was mainly relaxing and preparing exercises for our students.
An interesting thing I noticed is that the Bavarian TV will show the first three films of "Der Bockerer" this night. I immediately instructed vdr to record them because those are really good Austrian films.
Ok, today I was all day occupied visiting Cologne. When I reached the conference building there was this concierge, an original native of Cologne. He was most likely the only one in the building with hundreds of signs that smoking is not allowed that was tolerated to smoke some strange cigars all day. Apart from smoking his primary job seemed to be asking everybody whether he has arrived by train and explaining that they offered a free parking space for his car. Actually he explained this to all people, whether they arrived by car or not. Then there was this Indian guy that asked him whether he speaks English. He claimed that he did so. So the Indian guy asked him whether he needs his passport. The concierge explained in clear English sentences that they have a garage and that he could use a free parking space. Obviously the concierge _could_ speak English --- and he never claimed that he could answer English questions.
After we had all work done, we did what would have been typical for an excursion of our department: We visited the cathedral and some cafes. What would have been not typical for an excursion of our department is that we walked more than 500 meters at once.
Finally I noticed that Cologne has more of everything than Mannheim: The church is bigger, there is more traffic and more nice girls although I have not checked whether the majority of them are natives but due to the fact that we were mostly in the inner city I suspect most of them have been tourists.
Today we did our yearly graduation ceremony of our faculty. I was responsible for taking photos of all people that were involved in the event. One former student first talked about why it is great to work at IBM. A professor from an other university was telling about how efficiency of solving 3-SAT problems were improved in recent years, although I suppose most people where just impressed and confused but did not understand anything. Then there was a talker from the alumni network that was a really good talker. Finally the certificates were issued to the students and then the most important part of the event took place: the buffet. Apart from eating this was the place to meet old friends and to backbite other persons.
Today I was made aware that some people from our institute managed to win the foolish act of the week contest. Two of them attended a meeting of the university data processing center where they were offered an old 19" rack from the old local district court building that was no longer needed there. Immediately a group of happy campers went to the old local district court building and moved a 250 kilogram dusty and muddy rack first to the underground parking area, from there with a transporter to the institute building and up to the second floor where they finally found that the rack does not fit into the room where it was intended to be placed. Now the rack is blocking a door and the group of happy campers have heavy pain in arms, shoulders, and in the back.
A pocket rule could have saved much effort in this situation...
I for myself now completed the preparations for my trip to Cologne on Saturday which was much less painful.
My colleague did a PDF puzzle today. It was not really his intention to do so but he just created this PDF file. On most systems this PDF looks as expected but on some (Windows?) systems when watching it with the Adobe browser plugin it looks like this. I have created the same document as PDF with my tool chain that does not seem to have this problem. Anyone here with an idea what is happening here exactly? Is this a bug in the document or in the Adobe plugin?
What's the reason for the inflationary increase in the number of students visiting our university courses this semester? All courses I am aware of have a much higher number of students than was predicted by past experience. For some courses even the scheduled rooms are quite small.
To support an inflationary increase in my package repository I started to populate the repository for SUSE Linux 10.1 with the first two packages. Only two packages so far but it is a start. Note that you should _never_ install the package build-ccache on your system because it is intended to be used by morebuild only. Installing this package on a normal SUSE system might result in strange behavior. Maybe I should finally implement some ideas to morebuild that would obsolete this package completely.
Another point that results from latest SUSE releases and especially from the shipment of gcc 4.0.x is that I had to read the detailed rules for C++ lookup rules with templates to understand the details of why _exactly_ gcc rejected some specific code. I was aware about the basic facts but the specific case required the details. Funny thing was that this was the first case where gcc even provided a more detailed error message than compilers with the EDG front end. Typically it is the other way around. I use to run critical code through compilers with the EDG front end to get additional hints about problems but for this specific case one of the EDG based compilers that rightfully rejected the code like gcc did give much less detailed information about the problem and another one even accepted the illegal code like older gcc releases did. Seems the second one either uses a broken version of the EDG front end or just wants to be "compatible" to all the other broken compilers.
Ok, ok, I must confess that I actually didn't give up with drpmsync. When I came home last night I had another idea how to sync to the current state and at 6:30am it was actually complete. Now I am the proud owner of a current repository.
But the meeting density today was definitely too high. There was a meeting for the organization of the graduation ceremony of our students. Then an even more important meeting was scheduled spontaneously. It was scheduled that spontaneously that I completely missed to cancel my participation in the other meeting. Some minutes after this meeting has completed I noticed by accident that another meeting on that topic was scheduled some minutes later and nobody noticed me about it. Finally I could even manage to participate this meeting. Will see what will happen during the rest of the week...
Seems that SUSE has ways too less resources to handle a continuous access to the current set of RPM packages. As I told already yesterday I was in charge of evaluating the drpmsync service. Now I have detailed measurements and found that the drpmsync server was so much overloaded that he managed to stream out within 24 hours only the production of new packages that were made within 2 hours, i.e. less than 10%. Most likely it is not the drpmsync service that kills the machine it is running on but the fact that ftp and rsync run on the very same machine and this machine cannot handle this load.
Let's hope that they will get some public mirrors for this server or have the money to buy some additional machines. Until one of these situations happens to occur I am giving up syncing the data because in the current situation the service unfortunately is unusable.
After debugging all problems that were invented by securing the server with Adrian this morning I finally could start to sync the current SL-OSS-edge directory from the drpmsync server. I already had a local image of the full tree from the time when alpha 2 was released and thus expected to have a fast sync to the current state but there still are problems. The first one was that the delta set was quite incomplete in the beginning and thus instead of deltas often the full RPMs got transfered. Fortunately this seems to have been only a startup problem because later files show this problem more seldom. Now the current problem is that drpmsync.opensuse.org serves the deltas such extremely slow that I can sync less deltas than get added on a daily basis. The server sends data at a rate between 0KB/s and about 40KB/s, most of the time being less than 2KB/s. This leads to the result that people are drifting slowly away from the "edge" distribution. My current backlog is 58 hours and slowly increasing. There are only three solutions to fix this problem. Either the SUSE stuff slows down their work or they make the clock run slower or the drpmsync service gets faster. Let's hope they add some more machines in the near future to balance the load.
Today the drpmsync server again gave me a hint that it is quite useful to backup everything before working with a new tool. After long time syncing the repository the server was stopped and thus my client as well. After the client was restarted, it started to remove all files in my repository. Fortunately I have a policy manager running that stopped the client after some hundred deleted files. I found that the server was misconfigured and did not allow access to the data directory which made the client think that there is an empty repository on the server side and thus started to delete everything on the client side instead of doing nothing because of the error message received from the server. After learning about this annoying behaviour I added another rule to the policy manager to backup the whole destination directory before each drpmsync call.
Many students seem to be rather confused when searching for course rooms because it happens quite often during the last days that they appear at our department searching for a course room that is located in a completely different building. It seems that we should invent a course in the first semester on how to read street signs that announce the name of a street. Today a group appeard again that claimed that their seminar will take place at our building in the room C0.14. After some effort I managed to convince them that although there is always a shortage in course rooms it is quite unlikely that they do seminars nowadays in the ladies' toilet.
My colleague completed the gcc 4.0 port of our database system today with my special version of the compiler. No more really interesting bugs found in the code that were not already seen yesterday but I had to explain again why a template instantiation is not allowed when the template definition is not yet complete.
Another thing I waited for was the public drpmsync server that was planned for some time now for the openSUSE project. In time with 10.1 Alpha 2 release it is up and running now. Unfortunately it currently does not hold any delta RPMs to public available packages thus it is currently not yet really useful but will hopefully become so within the next days.
One of my colleagues started today to fix all broken code in our database system that prevents gcc 4.0 from building it because he wants to have his workstation updated to SUSE Linux 10.0. He also requested to appear in this blog for this heroic action and thus I am reporting here what I have seen during the day while being the local C++ coding consultant for this project.
Most bugs where quite simple stuff like not including include files for interfaces that were used, funny (but unfortunately wrong) syntax variants for template specification or instantiation, broken namespace usage, encapsulation of an interface part, type conversion errors, and stuff like that.
But then after the boring stuff we discovered a bug that made the project stop for some hours. First we did only see gcc crash with an internal compiler error. I was immediately alarmed because this happened with a file that was generated by the compiler construction toolkit we use. This toolkit is famous for being quite unreadable and unportable code and randomly odd behavior. I tracked down the gcc bug and found that it was a bug fixed some days after the SUSE gcc for 10.0 was branched. At the same time I found that the generated parser code is non-valid and definitely silently produces incorrect binaries independent of the compiler used. A stripped down version of the broken code is "int a[1]; int* b = &a[-1]; int* c = b;", just for the case you want to crash the SUSE Linux 10.0 gcc. To enable my colleague continuing his heroic project I have built a replacement cc1plus binary for the system compiler. It seems quite unlikely to be able to fix the used parser generator thus the only solution here seems to be migrating to a different toolkit, especially because the current toolkit doesn't run on x86_64 anyway.
I have done new Xerces-c and Xalan-c builds for SUSE Linux 10.0 to replace the earlier builds built with an early beta of 10.0.
The discussions on the main openSUSE mailing list seem to become more and more obscure. Actually I have expected that because the members of the list are just too inhomogeneous ranging from qualified developers and packagers to users that seemingly can't even read the messages on the screen. Currently I can see three directions where this list might go:
1. The lazy users scare away most of the qualified people by repeating the same stupid questions that where discussed or explained even multiple times.
2. The qualified people stop answering simple questions and thus scare away the user community.
3. The list becomes a noise-only list containing only flame wars with no content at all.
Let's hope that some groups of people move to more specialized sublists before the main list gets too crappy.
Did some detailed tests with deltarpm.
It seems that it works pretty good when making deltas of RPMs that contain mostly text files. This seems logical because text files tend not to change much and thus deltas can be created in an efficient way.
When analyzing binary files I found that it works only well when between both versions of the RPM only minor patches where applied. If you have changes that touch many parts of the source files creating a delta RPM for a package containing mainly binaries is no longer worth to do.
There is a similar result for source RPMs. If only a patch was added or removed to the source RPM package the delta RPM package is pretty small but even when only small parts of the source archive changed, the delta RPM does no longer save anything valuable because the compression for the archive completely breaks the delta algorithm.
Today really wasn't my day. My intention was to run again 30km, this time to Ladenburg and back.
The first problem occurred already one minute after I have left my flat. I noticed that I had forgotten something in my flat and thus hat to run up the stairs to the 5th floor again to fetch it.
The second problem was that my fitness level was quite low today for some unknown reason.
The third problem was that I noticed after about 5km of running that there was some strange pain at a specific point of my leg. After shortly inspecting the problematic area by touching there I found that my trousers that were specially designed to protect your skin from getting injured by long distance runs had a small hole. At that point I didn't have an idea what the results of such a small hole could be.
Then after about 20km I felt abnormally fatigue and the pain in my leg got stronger and stronger thus I decided to cancel the run at that point. I started to inspect the area with the pain and found that everything was full of blood. Seems that I definitely should not use this pair of trousers any longer.
Today I started with recovering from yesterday. After having completed this step I tried to catch up (no tomato sauce!) with some mailing lists and some other stuff that was (and partially still is) pending.
Finally I managed to do some preparation for my trip to Cologne in two weeks.
Today I was improving the world a bit more by educating another person in building RPM packages for required software instead of just copying everything into a random directory and forgetting about all the security flaws that where installed that way.
Some of you might have noticed that they got this important information much later than they were used to. You could blame the time zones for this because Szann, Joanna, and me were visiting some friends talking about the good old times, the good new times, and times in general. Szann was still used to PDT and thus did not show any interest in leaving within the near future but as Joanna and me decided to maintain the friendship to the people we were visiting we finally decided to leave what enabled me now to write this message.
Today I was again told that it is vitally important to subscribe to a special list containing all persons at a faculty that intend to do their doctorate. Actually you need this when you finally want to submit your work and because of that most of my colleagues do this extra bureaucratic work when they have to do bureaucratic work for the final submission of the work anyway. Up to this day I am not aware of any advantage I get when I do subscribe now. Actually I even don't know why this list is required anyway.
But administration insists on their thesis that it is vitally important to do so. As a scientist I am used to ask people that claim something for a reason thus I always asked those people why this is assumed to be so important. Until now no of them ever could tell me the reason. Instead they repeat their claim that it is _really_ vitally important.
My current thesis is that there is a secret club somewhere trying to assure that there are always at least 23 persons on this list. Most likely they are just not allowed to tell you why it is so important to have 23 persons on that list because it is important that you do not know about that fact to protect their world domination.
Hmm, I think I should watch this video DVD again I received yesterday to ease the pain...
Today as a member of the faculty council I got the new video DVD about our university for reference. The DVD contains about 4.2GB of high quality video about how great our university is. After having taken a look into the videos I am confident again to have studied and being working at the greatest university of the world. I will keep this DVD at hand for the case I will get frustrated about something at our university to prove myself that I _must_ be completely wrong with my frustration.
The SUSE mirrors where slowly recovering from the release DoS event but then they decided to keep up the situation for some longer time by releasing a new 4.5GB source DVD containing again only files that were already on the ftp server. I was told that this was on big public request. I still wonder how long they continue to make mirror infrastructure unusable by public request...
I wonder whether it would be appropriate to package all mails from the openSUSE mailing lists into an ISO image and post this image to the list once a month, just to please all those I-want-everything-in-an-ISO-image-...uhm...-people...
Then I tried to package a ruby module into a RPM package and found that those modules suffer from the same problems almost every script language seems to suffer nowadays: Their communities have no knowledge (or completely ignore) well established tools and ways to reproducibly install a module into a desired directory. Instead they implement a extremely bloated install system that is mostly undocumented and definitely invents a new user interface you never have seen anywhere before. You typically even can't use knowledge from other packages of the same flavor because all modules seem to use special variants of the install system that support partially different sets of options. Will have a deeper look into this tomorrow...
Today the new head of our chair arrived for his first day at our university. He was accompanied by four other persons from his research group. It was my job now to introduce them to the most important affairs of our university including some bureaucratic stuff they had to do in their new offices, the refectory building, some bureaucratic stuff they had to do at the data processing service center and some bureaucratic stuff they had to do at the administration building. Will continue all that stuff during the next day. At least it is assured now that they can survive now autonomously in our university's bureaucratic world.
According to my statistics collected here the mirror infrastructure is slowly recovering from the DoS attack triggered by the SUSE Linux 10.0 release.
I have neither upgraded the build images for 10.0 on the build cluster to the final release, neither have I created those for the edge tree yet. This was not because of the defunctional mirror infrastructure but just because I was too lazy until now and there was no real need.
Well, I'm back from Nuremberg now where I collected some findings about current SUSE projects at the meeting, SUSE gossip at the party, and non-SUSE facts in town today. Because of the fact that I learned most SUSE related facts yesterday and this is todays rant I will only tell non-SUSE ones.
The first thing I noticed when walking from Langwasser to the city early in the morning was that Nuremberg obviously wants to make their city more interesting by placing trees across public forest tracks.
The next thing I found was that the place and the buildings (at least they that still exist) where the Nazis have held their Reichsparteitag are even larger than you would expect even if you have seen them on a map or in films from or about the Third Reich before.
Then we added some general facts about historic sites within the city to our knowledge by Andreas and Christoph reading from a tour guide they found somewhere in the Internet and Rasmus countered with knowledge he read from some plates at the sites.
After learning so much stuff I was too tired to do my regular 30km run when I reached Mannheim again. Thus this job is still pending, maybe for tomorrow, we'll see...
Today it happened. After releasing the final release of SUSE Linux 10.0 the mirror system broke down and is still not reliably functional again. Most of the mirrors either did not manage to get a complete set of files or they became completely overloaded and thus were no longer reliably available.
Why did this happen? The reason is quite simple: The size of synced out files was much to high to be handled by network bandwidth and mirror's disk hardware. The ironic point here is that it was not the size of the distribution alone that killed the mirror system but the fact that every mirror had to sync the same files multiple times. If a mirror mirrored both, suse.com and opensuse.org, it mirrored parts of the 10.0 release 4 times.
This leads into a fatal vicious circle: Most of the mirrors get their files from a GWDG server. When the mirrors don't manage to get an almost complete set of files before the official announcement they are considered unreliable by most users and all users go to the GWDG servers resulting in more and more load there which itself leads to other mirrors receiving files slower and slower.
The redundancy of files on the mirrors results from the fact that SUSE started to provide apart from the FTP tree various sets of ISO files all containing mostly the same files. Optimal solution from a technical point of view would be to remove these files from mirrors completely and to provide a tool that can create these ISOs from the normal FTP tree on the client machine. Because of the fact that most users are considered incapable using such a tool this is currently a no-go.
So we can conclude that the current FTP/rsync based mirror approach is not feasible for the way SUSE Linux is distributed by the mirrors. Instead mirrors should be provided by a tool (e.g. a script) that automatically syncs a minimal set of files and automatically builds all other files that contain redundant information. That way they could sync up with the GWDG server earlier thus being considered more reliable by the users which would remove load from the GWDG servers keeping them fully operational.
First ideas were already considered about that topic. Let's hope that the ideas evolve before the problems evolve.
Was talking to some colleagues today about the new university constitution currently under development because the university head expects me to give an official statement about the current draft for the convent of research and teaching assistants in two weeks.
To fix my brain up from all this legal stuff I uploaded map data for Nuremberg to my GPS receiver to be able to stay in geek mode while traveling there during the weekend.
On some days you just wonder why people create their own build system when they have no experience in doing so at all. Today is such a day. I have seen released source code for a project that is built about the following way:
1. Copy some template config file and manually change settings as you whish. --- Ok, this is not state of the art but acceptable.
2. Fix some Perl script needed in the next step by replacing hard coded paths with the ones appropriate for your system.
3. Use the Perl script to build an executable required for the build system.
4. Fix some other Perl script by again replacing hard coded paths with the ones appropriate for your system.
6. Run this Perl script to build the actual build system.
7. Build the software with the build system built in former steps.
Easy, isn't it?
Some of you might have noticed already that there is step 5 missing. This is intentional because in step 6 you notice that the Perl script does still fail because the executable from step 3 cannot find a specific file. I'm not sure yet who is responsible to provide this file but obviously there must be a magic undocumented step 5 which either provides the missing file or fixes the broken Perl script.
I have seen similar build system adventures at some commercial software vendors but they at least assure that it works if you perform all steps as required, i.e. there typically is no missing step 5. The maximum of build-system-uses-another-build-system-uses-another-build-system recursions I have seen in real world productive development environments for applications written in C so far is 7 recursion steps. Anyone here that has seen more?
How hard must an average developer be penalized by his own build system before he accustoms himself to well established build tools instead of trying to reinvent the wheel?
Today we had a national holiday here in Germany but apart from the fact that almost nobody went to work you didn't notice that very much here in Mannheim. There also was a penumbral solar eclipse today but you even didn't notice this because it was too cloudy. --- All in all it was a quite unspectacular day.
Novell again managed it to Slashdot. --- But most likely they are not _that_ happy about that as it happened because some of their web servers were hacked. Fortunately the SUSE distribution servers were protected in a better way and thus they did not suffer from the hack and the current distribution files are still sane.
From my daily experience there are _very_ many systems at companies and other facilities that have numerous security flaws although fixing them would be an easy job. Most times this is because the system administrators have no clue when security is concerned. Many of them even believe that they _have_ a clue and are doing many things they believe will improve security of their system but miss the vital parts that make up the required basis for a secure platform, like for instance installing security fixes for known flaws. The management often does not have the budget to hire people that actually have a clue but more often the management even does not have a clue that their system administrators also don't have one.
As a 30km run was again due according to my workout schedule I decided to find a nice path from Mannheim via Ludwigshafen to Frankenthal. Actually I did find one that does not require to cross high traffic roads. Due to the fact that I found the path was shorter than 15km one way to Frankenthal city I continued to run eastwards to the autobahn A61 and then the same path back to Mannheim. If you were interested in my findings drop me a note but most likely most of you won't even know Frankenthal.
Today I again did something for my save-the-bandwidth campaign and updated the information page about Jigsaw Download on openSUSE.org with the numbers for the current version.
A tool I also coded for this campaign some days ago is linkdup which replaces duplicate files in a specified directory by hard links and thus saves a lot of bandwidth if you serve duplicate files via rsync. If you serve via ftp you at least save some disk space and thus buffer space. If you are interested in the tool, you can find it in bug #118717 on Novell's Bugzilla.
I found that my uplink router now supports WPA2 for the WLAN interface with the new firmware I successfully installed yesterday. And even the clients seem to support it. --- At least they are still talking to the router.
Another thing I found with KDE in SUSE Linux 10.1 alpha1 is that Konqueror now has a "Speech Toolbar" with exactly one button "Speak Text". I decided to test this with the Slashdot page. It worked and even was understandable. But as you might know the Slashdot page has rather much text thus I decided to stop it again. Unfortunately it seems that there is no option to stop this talking parrot again. Fortunately my ThinkPad has a button to mute sound. Ok, I could have just killed the speech process but I think an option to do that with the user interface should be accessible as easily as the start option is available.
