Author: Rainer Gerhards

Rainer Gerhards ist Hauptautor dieser Seite und schreibt die meisten Artikel. Weitere Informationen über Rainer Gerhards können hier über das Hauptmenü abgerufen werden. Die Biografie findet sich z.B. hier.
Posted on

travel preparations

Not only NASA needs to prepare for the space shuttle flight. I, too need to prepare for my journey. Of course, it’s much shorter than Discovery’s, but I’d still like to have all things with me and not go back if I forget something.

Today is a rainy day over here – and also a public holiday. So what day could be better to begin travel preparations? This time, I need to bring quite a lot of technology with me. For example, some of the hotels I have booked have only wired LAN access available (for example the Residence Inn in Orlando). I remember the last time I stayed there, I was tied to the sofa because the Internet cable was only a foot or so long. This time, I’ll bring a nice wireless access point with me – that’ll do the job.

Well … I’ll begin to gather my things now and I’ll see what all I come up with.

Posted on

complex scheduling…

The Expedition 16 crew (to the middle and left) before launch to ISSSpaceflight is complex. Scheduling is complex. I knew that. But it is even more complex than I thought. I am very happy with the apparent good processing flow on shuttle Discovery. But guess what — I looked at far too few places.

Not only space shuttle processing flow is a constraint. The IIS (International Space Station) must also be ready for the shuttle visit. And I nearly missed an important event: there is a crew swap scheduled a few days before Discovery launches. With a Russian rocket, the new expedition 16 crew will ride to the skies. If that launch is delayed, we’ll probably end up with space traffic jam. And, guess what, that would of course affect Discovery’s launch date.

So let’s cross our fingers and hope for the best. Thankfully, the Russian rockets have an excellent track record…

Posted on

no news is good news…

There are currently very few new news from Discovery’s launch pad processing. As far as I know, everything is quite on schedule with only some minor glitches. But I have to admit I was on the road yesterday and could not check as thorough as usual. I’ll try to dig out more today and then update the blog.

Posted on

Space Shuttle Discovery rolls out to the pad

Discovery on the crawlerway - 1 hour into its journey to the pad
Space Shuttle Discovery rolling out from the VAB to the launch pad
Discovery begins rollout from VAB to the launch pad (STS-120 mission)
… Discovery begins rollout at 7am EDT.

This is a major step in space shuttle processing. Discovery has been mated to the tank and external rocket boosters inside the Vehicle Assembly Building, or VAB for short. Now it is time to go the launch pad, where further work will be conducted. Most importantly, the payload will be integrated. Ffor STS-120, this is the International Space Station’s (ISS) Harmony module.

The rollout is performed by a gigantic “crawler” which moves the Space Shuttle stack (tank, boosters, orbiter) at a very slow speed to the pad. It is a 3 mile journey and takes around six hours.

The move can not be done if there is bad weather predicted. This is the reason why the rollout had been delayed for some hours. However, the rollout was move ahead of schedule, the current rollout is even a bit before the actual schedule. So far, the target launch date of October, 23rd is still very possible. There is even a day of contingency (spare time) left in the “processing flow” (aka “launch preparations” or “getting it ready” in less technical terms;)).

I will update my blog with additional pictures during the rollout. I also plan to create a short animation of the rollout once it is over (depending on my ability to capture enough images).
Picture Sources: NASA TV, NASA Webcams

Posted on

Payload Canister delivered to Launch Pad…

The STS-120 payload canister is being delivered to the launch pad
Yesterday, the Payload canister has been delivered to the launch pad. What can be seen is the “protective cover” of the canister. It is now being stored at the pad. After Discovery has been moved over to the pad (starting on Saturday evening), the payload will be integrated into it (at least this is what I think will happen – remember, I am still learning…).

I’ve also heard that the weather forecast looks good for the rollout. Processing flow in the VAB still seems to be great, so the rollout as scheduled is very likely. However, this seems not to bring in extra contingency, as some work usually done in the VAB seems to have moved over to the pad. The reason was weather, where the favorable weather on Saturday shall be used. In any case, the NASA guys are doing an excellent job.

So far, everything still looks like an October, 23rd launch is still quite probable.

Posted on

on ommysql packaging

I thought I share an interesting conversation that went over the rsyslog mailing list. Even though it buried in the mailing list archive, I think here is a better place to be displayed. Feedback is much appreciated.

> —–Original Message—–
> From: Michael Biebl
> Sent: Friday, September 28, 2007 10:23 AM
> To: rsyslog-users; Rainer Gerhards
> Subject: Re: [rsyslog] rsyslog 1.19.8 released
>
> 2007/9/27, Rainer Gerhards :
> > repeat message processing. The MySQL functionality is now taken out
> of
> > the core package, but its tarball is still contained in the main
> tarball
> > (so it is still a single download for everything). This is part of
> the
> > effort to fully support third-party plugins. Rsyslog 1.19.8 is a
>
>
> To be honest, I don’t particularly like this change. It increases the
> work for package maintainers (like me). You now have to maintain two
> source packages. Having a non-standard tarball inside a tarball
> doesn’t help there. It even worsens things, as stuff like “make dist”
> or “make distcheck” doesn’t work anymore for a cvs checkout.
> There’s also the problem of which version of the plugins will be
> compatible with the core version (upgrade scenarios, keeping them in
> sync, etc.)
> It also adds complexity for the developer (as he has to maintain an
> additonal set of build files).
> As you were talking about 3rd party plugins (with the emphasis on 3rd
> party) I don’t understand the benefit of splitting out the mysql
> plugin as it is you who develops the mysql plugin, not a third party.
> Do you actually intend to create a separate tarball for each plugin in
> the future?
>
> What was wrong with the –enable-mysql configure switch? I don’t see
> any benefits, only disadvantages. You know, if it ain’t broken, why
> fix it ;-)
>
> Cheers,
> Michael

Hi Michael,

as I have blogged, I am not yet sure about how to handle the situation. I am also consulting with Autotools experts, any advise is appreciated.

Two packages seem useful, especially when more plugins become available (I myself think about email and a couple of other databases). Many folks also do not like the idea of having to have libmysql present on the system just to install rsyslog – with a core package and the plugin, those can only install the core (and that will probably the majority of cases).

What I have not yet found – and I have very limited expertise in this area – is how to do that in the best possible way.

Oh, and some more background: ones the plugin interace has matured (I expect this in 3 to 6 month), I intend to actually use ommysql with its own version number. Versioning will be handled by the interface (that part is already present, but no code for it yet as there is only a release 1 of it). So, in the medium to long term, ommysql *will* be a separate project – maybe one with a different maintainer, as I am no mysql guy.

Does this make sense? As I said, comments are much appreciated…

Rainer

Posted on

It was not a MLP…

Look at the red circle and you will see it can't be a MLP
In my last posting I thought I had spotted a mobile launcher platform. But I was wrong. As a friend pointed out, it can not be. Look at the red circle – this is a table. It would be a real gigantic table, if it were a MLP. So it can’t be…