Weird behavior I just observed. I’m still fighting a hd crash I had last week in my file server and I’m now ready to set up a raid5 array on the machine. So I use this command to set the array up:

mdadm --create --verbose /dev/md1 --level=5 --raid-devices=3 --auto=md /dev/sde1 /dev/sdf1 /dev/sdg1

For some weird reason, /proc/mdstat now tells me this:

md1 : active raid5 sdg1[3] sdf1[1] sde1[0]
626304 blocks level 5, 64k chunk, algorithm 2 [3/2] [UU_]
[=======>.............]  recovery = 39.5% (124680/313152) finish=0.1min speed=31170K/sec

As you can see, one device is marked as a spare, and mdadm --detail /dev/md1 actually says so as well:

State : clean, degraded, recovering
...
Number   Major   Minor   RaidDevice State
   0       8       65        0      active sync   /dev/sde1
   1       8       81        1      active sync   /dev/sdf1
   3       8       97        2      spare rebuilding   /dev/sdg1

The fact that this array is degraded is even reported in syslog (mdadm is running as a monitor) and mailed to root. Hm.

Now, in this example I tried things with three 300M partitions, and after a short while I could see that everything ends up being just fine:

md1 : active raid5 sdg1[2] sdf1[1] sde1[0]
      626304 blocks level 5, 64k chunk, algorithm 2 [3/3] [UUU]

Problem is, my real array was supposed to use three 1.5TB partitions, and I didn’t want to wait for the sync to complete several hours from now just to find out that something was wrong. For some reason, this rather confusing behavior during the first sync phase of a new raid5 array doesn’t seem to be documented anywhere, or at least I couldn’t find anything – so here it is now, for others to find in Google ;-)

I was recently trying to find a solution for a problem with code pages in Zope, in conjunction with Structured Text. The basic problem, which is discussed all over the web, is this: the correct code page has to be configured in the running Zope instance to make STX work correctly with "non-US" ASCII characters. If this is not done, there'll be problems with special formatting, because STX can't find the borders of words correctly.

Example: *zaczęło* should really appear as zaczęło and **Frühstück** as Frühstück, they appear as *zaczęło* and **Frühstück**, respectively. Or one of them would work, but not the other, because these two words need different code pages: zaczęło needs ISO 8859-2 and Frühstück needs ISO 8859-1.

The problem is that STX is dependent on the code page configured for the running Zope instance. As there can obviously be only one code page configured at a time, this is a problem when there are pages that need one code page and others that need another one. Two solutions seemed useful, but didn't prove to really work in the end:

1. Not using STX. There are other variants of the Structured Text concept, which might not have the same problems. I didn't really check no this because it wasn't an option in my situation; too much text had already been written in STX format over the course of several years and it had been hard enough to have users understand that concept the first time.
2. Using Unicode, just like I'm doing in this page, to be able to mix characters from different code pages. I actually tried going this way, but it didn't work. While the Unicode encoding would allow for the characters to be shown correctly by the end users' browsers, the STX implementation still had the same problems as before, parsing the strings when formatting was in use.

In the end, my workaround was simple: I changed the regular expressions in the STX implementation to work with whatever characters there might be between the start and end markers. The original expressions went out of their way to make sure there would only be specific characters, and that was the core of the problem because that character set was the one that would be defined depending on the code page.

For example, the line where the strong marker was searched for looked like this:

expr = re.compile(r'\*\*([%s%s%s\s]+?)\*\*' % (letters, digits, strongem_punc)).search

I used this expression instead:

expr = re.compile(r'\*\*([^*]+?)\*\*').search

I made similar changes in the places where the em and ul markers are checked. Of course, my changes allow a wider range of characters between the markers than would originally be allowed, which may have its own problems. But the workaround seems to work fine for me, as long as no real fix is available (and there probably won't be because I don't think anyone's really still working on the old STX implementations).

Click here to download a patch file with all changes I made to DocumentClass.py.

atsec information security says they have completed an evaluation of Novell/SUSE Linux Enterprise Server 9 (SLES 9) for IBM eServer based on the Common Criteria ISO standard (ISO15408), which will result in a certification for Evaluation Assurance Level 4+ (EAL4+). Read the original announcement here.

I just stumbled upon a very useful free tool that I didn't know yet: Wink. Their own description from the website says:

Wink is a Tutorial and Presentation creation software, primarily aimed at creating tutorials on how to use software (like a tutor for MS-Word/Excel etc). Using Wink you can capture screenshots of your software, use images that you already have, type-in explanations for each step, create a navigation sequence complete with buttons, delays, titles etc and create a highly effective tutorial for your users.

I tried it and found a lot of useful functionality, like automatic capturing of screenshots based on mouse and keyboard actions. It's also possible to customize the look of presentations completely and the author can create his own "Callouts" (those popup windows with attached arrows) with a builtin editor. Have a look at the product page for a complete description, download and everything!

Linux version

Some people may find a recent post in their support forums interesting: apparently a Linux version of Wink is available for beta testing. I haven't tried that one, though.