Why does it always have to be us BSDers that have to find the bugs in
crappy GNU saftware? Today’s thanks go to Peter Valchev for being truly
helpful in tracking down something that I first thought of as an endian
difference issue in UMAC-64 (the new one in ssh(1), you know). It turns
out this was a bug in libgcc, and while libc contains “better” code, it
wasn’t used due to the linkage order. Fixed. Thanks, pvalchev!

We’re a lot closer to release, despite the recent fluctuation, as I’m
done with preparing the manifold-boot CD stuff and could quite simplify
sparc support overall, as a side result. Now, just minor stuff is still
to be done (especially my new server and the SCSI cabling), and we need
a few full OS rebuilds… *sigh* so much for sleeping quietly, subsequent
nights I will enjoy the sounds of a SPARCstation again.

I wonder where Benny is, he hasn’t been contactable for a while. Last
thing I remember is he tried moving to France again. There you go…

The guy from the company where I bought my new server called today. A
service to the customer… they always call and see if one is happy. That
is new to me (as is that weird chassis) but not bad.

pkgsrc® is hereby officially dead. I cannot write an eMail (or rather
I get bounces) to the official MAINTAINER address of mksh, and nobody’s
caring. Hey, even Debian does get it! (And others…
you should be ashamed of yourself.) Coverity mostly relies on pkgsrc® –
otherwise I’d have posted results of their latest scans already.

We’re actually very very close to release. I’m helf off by the issues
with the SCSI cabling (see my earlier posting), my laziness (or rather,
I’d like to call it being unable to enter deep hacking mode for a while
☺ honestly!), and a few missing things.

Well, I went and did some of the things. I read much source of kernel
random(4) and random(9) stuff as well as OpenSSL, fixed a lot of things
I found (oO ☻) and wrote a script (mircvs://contrib/code/Snippets/ is a
good place for them…) to create a seed file for “openssl genrsa -rand”.
This can be used to generate a large (4 Kib or so) secret key;
since I still have the sparc and nwt (80486DX-33) around, I’ll just use
two keys on tear: this one publically and an 1024 bit key bound only to
the LAN (might even make it IPv6 only to annoy my visitors even more…).
I also made arandom(4) reseed much more often if we have a hardware RNG
(every 64 seconds instead of 10 minutes; I hope that’s okay, but we get
64 Bytes of new entropy every 10 ms, so I guess…).

syslog(3) and friends are stupid, they truncate waay too often; I did
a würgaround in logger(1) for now, letting it split up conservatively –
at 512 bytes already; doesn’t catch all-binaries but what the hey…

There’s a new src/distrib/tools directory now, with releng’s
playground. Like MirOS #7ter, we want to make the release CD dual-arch,
bootable. But since #7, things have changed – you can use our ISOs as a
kind of Live-HDD, Live-CompactFlash, etc. so this functionality must be
retained (I know how now, I just have to code it… and get my sparc PROM
to boot off a burned CD-RW). And I could even do this to the #10 series
mini-ISO (cdrom10.iso). Having an ISO of approximately 8 MiB size, boot
both architectures off it. Yay! (as benz would say)

pcc’s in the works, I like the activity but not the split and some of
the directions… but at the moment I’ll only monitor (and contribute the
needed MirOS support bits, of course) since we’re busy with other – and
much more important – things, the impending release for instance.

herc is in the NTP server
pool… so will tear be, but I wonder if we should do a same
for entropy distribution (like randomnumbers.info et al. do)? Since the
box has a hardware RNG and a pretty good in-kernel mixer, I’m having it
exported to the public anyway (but not too well-known since my internet
connection cannot handle much load).

Speaking of entropy… ICQ logs conversations proactively, according to
ciruZ, so we sort of decided to just send random data to each other. We
didn’t set it up yet, but is anyone else interested? Does ICQ close the
accounts when they just send to random other accounts? I have some very
evil ideas for mksh scripts… *grins*

Why does every friggin’ SPARCstation 20 from the last millennium make
it easier to build a SCSI-based system with the modernst SCA hard discs
(U-320 LVD) than a brand-new not-even-off-the-shelf server system?

The good part is I learned much more about SCSI today again.
The bad part is: I gave out 1 € (plus 10 € shipping…) on ePray to
gain a bunch of 68-pin ./. 80-pin connectors. ☹

Besides bumping the number of geocaches up, to
18 caches found, three geocoins found, and only one DNF, I admit having
been a tad lazy lately.

At the moment, we’re testing the current HEAD code intensively, and I
think that, despite theoretically being able to release any time now, a
good chance to find bugs (like these which led to mksh R31b, or that my
vnd(4) encrypted home works more reliably now) shouldn’t pass unnoticed
(and Benny is still fixing ports).

I will probably get my new server tomorrow. It will replace herc, and
– sadly – its hostname too, since a Micro-ATX board only comes with two
PCI slots (at least one too few for me anyway) and no ISA slots. But it
is a fast machine, I already got the dmesg, has one Gig RAM, and at the
moment, the Padlock AES/RNG stuff isn’t yet recognised (some hacking to
do – but solidly setting it up is what counts now). Well, this opens an
opportunity to use some spare Pentium Ⅰ board to write a framebuffer in
the kernel for the Hercules card (and compatibles). If I get time.

You wouldn’t believe it: at work, I’m writing a user-friendly (woah!)
front-end using dialog (yes, me!) for BIND (me the djbdns user)… and it
is still sort of fun (sure, I’m using mksh for both the main programme,
input loop and all, and parsing the zone file (slightly more restricted
format than default, but good enough for us). It runs ssh as coroutine.
(That’s why MirPorts’ misc/dialog is more recent than Debian sid…) When
my boss sees it, I want to see his face. I bet it’ll be not unlike that
of Benny when he first saw the Baselive-CD preboot selection menu.

Is this called summer laziness? I’m actually not really interested in
hacking at the moment, even though we could use a release, and I could,
as well, make use of my nmeadecode(8) project, since herc is now a pool
server for Germany and Europe at the NTP Pool project. Quite a good one
with a score of 20.0 at the moment, and an average offset of -53 ms (to
the pool tester, which is an SNTP client), with a consistent and rather
low standard deviation (0‥-100 ms), in contrast to Hephaistos, whose is
pretty unpredictable. And nobody bitched for me using OpenNTPD.

Ah, yes, the dual-arch boot CD issue. I have plans. Stay tuned. Is is
possible after all, I just need to get my SPARCstation 20 to boot off a
CD-RW to test it…

Spam to the company mail account sucks.

Ah yes, and I better not respond to Benny’s above posting. But I will
see if svk can be of use to access svn repositories, since I’m bound to
use them in a couple of projects of mine. Well, not my projects, since,
obviously, they would be using CVS then, but which I work on.

Benny and XTaran have won, mksh (or
rather, dot.mkshrc) now has dirs, pushd, and
popd (exactly as csh(1) had them). The hooks chpwd as
well as precmd were added to please some zsh freaks. (The dirs
stuff uses chpwd now, for simplicity.)

Writing a diploma thesis is really a job where you can see how the
UNIX style is superior to what Windows users are used to. Using (in my
case) LaTeX and a Revision Control System (Subversion here), you enjoy
lots of benefits: I can give the source code to someone for revision,
tag the version I gave out, check in what I get back and merge. Compare
this to using Word (eek) or OpenOffice.org: you can track changes, but
if you work on the document in the meantime, it is not so easy to merge
changes from two sources.

Add the fact that the result so far looks absolutely gorgeous, with
nice margins, well-placed images and a great text font (I love
Palatino). And the LaTeX way of doing automatic numbering and links
worked perfectly when I decided in the middle to restructure what I
already had. Managing my references with BibTeX, especially with BibDesk as a Mac OS
front-end, is also a pleasure.

We had a discussion on IRC (#mirbsd, of course) about Revision
Control Systems, triggered by tg@ whining about Subversion again. Let
me just say that we have different opinions on this topic.

Apparently, GNU arch is more or less dead, many people are jumping on
the git bandwagon. bzr (sp?) and Mercurial (hg) are also popular
choices but seen less usable. I will definitely port svk though. They
promise the good parts from Subversion without the overhead of
libsvn_wc. "In fact, one of the motivations for writing svk was to get
rid of that Spaghetti code." Sounds interesting. Working copies are
smaller, checkouts are faster, mirroring is easier, they claim. Let's
see.

I’ve just put the last polishing steps for some in-tree software into
cvs, and I suppose the release is imminent. If but XTaran would deliver
some more sparc test results… I have no idea if XFree86® works there, nor
if the ISO is bootable, I can just hope.

Since I’m fairly busy with my dayjob and have increased duties
and responsibilities at FreeWRT, and Benny is working on his diploma, and
we’re okay with the current code quality, I assume that what we have in
the tree right now will be the final release.

Oh damn. I still need to work on the dual-arch bootable CD stuff. Crap.
That means some more coding (where the assembly part is the easier half…)
and possibly testing. But it’ll rock.

Just to not strain the poor packagers, there will be no mksh minor
release tomorrow ☺ At least, I hope there’ll be no more late real life
bug reports for problems I deem important enough.

I “found” my 10th Geocache, which
means that, on OpenCaching.de, the website I prefer for being devoid of
the capitalistic attitude which prevails on GeoCaching.com, despite most
other CacheWolf involved seem to not like, use or even know it, I can
mark one cache as favoured. I did. Nice view from there…

I am doing pretty much nothing for MirOS these days as I have only
three weeks left for my diploma thesis. Hopefully, in a month or so, I
will be a real Diplom-Chemiker. We will see what happens
then.

I spent a very relaxing weekend at my girlfriend's place. On the way
there, I got so bored that I almost finished a research paper ;).
Writing a paper is nicer than writing a thesis because you pick one
specific subject and try to make a concise statement. It also makes you
realise which experiments are still missing ;).

And the paper is in English. I discovered that writing scientific
texts in English is easier for me than in German because the majority
of existing literature is also in English. After a while, you get used
to the typical style, and it sucks when you cannot reproduce that in
German. I also have some problems with terms for which I do not know
the correct German expression :/.

Question to the interested reader: it seems that if you encounter
some totally bogus paper, it is almost always published by Elsevier.
Why is that? Discuss.

I have been in Berlin for some kind of business trip, and I finally
could get a hold of a beer called “Krusovice”, it’s a black beer, and
I really like it. Benny does, too. I drank it in a restaurant called
“Ranke 2”, which was recommended to me by Przemysław, thanks a lot!
We managed to buy some bottles in a beverage store (alongside with a
lot of bottles of “Berliner Faßbrause” – the local speciality, some
kind of herb lemonad – as well as a few interesting beers, such as
Neuzeller Kloster-Bräu Kirsch
Bier, Kirsch PorterDas fruchtige Schwarze,
Neuzeller Kloster-Bräu Schwarzer
AbtSchwarzbier,
Duckstein (Rotblondes Original – Auf Buchenholz gereift). Beats my
usual Schlösser Alt with Cola and optionally cherry juice ☺At
Ranke 2, I also drank a “Danziger Goldwasser” to close the stomach
after the good diner, which was something new for me as well; I must
admit I liked it, but not as much as croatian Julishka.

The SPARCstation is almost done building just another snapshot,
with the bootloader vs bsd.rd bug fixed. I suppose this means that
the release is imminent, despite XFree86® (4.5 → 4.7), ncurses (5.5
→ 5.6 or even CVS version) and maybe more waiting for updates. Ce
la vieh. We’ll do that afterwards, and of course we ensure that #10
users can use later MirPorts snapshots.

Oeps. I had to re-roll the mksh-R31.cpio.gz distfile. Damn. But
the Debian upgrade was already done. On the other hand, lintian did
bitch a little, so Debian accumulates two “nice to have” fixes now.

I wonder why companies produce such crap. No, really. And I wonder
even more why the previous owner (a colleague who went off looking for
a better paid job, probably with less good working climate) asked for
exactly this laptop, as it doesn’t even work without any troubles on
his beloved Deb*an G*U/L*n*x (all product names are changed because
I don’t want to be sued). It's a S*ny V*io, a brand which never had
any good reputation in our circles. MirOS won’t run natively on it our
of the box (okay, I could build a custom kernel, but hey, maybe these
dual cores can better be used with VirtualB*x or something like that,
even be running in parallel with W*nd*ws). But still, I had my fair
share of fight with the D*b*an-Inst*ller, which doesn’t even come with
fdisk. I managed to wreck it, expect this wlog entry to be amended by
a photo of that (which, at the moment, is located on the mobile phone
of my intern, which has a camera built in).

At least I have a use for these G**gle “Go Code!” stickers now – to
cover the built-in “webcam”… Who the fuck produces or buys such
kind of crap? Sorry for the emphasis, but I just do not
fucking get it. And of course, w*ldi and b*nz tell me that there
are no such bugs in the Inst*ller mentioned above. (There are a lot more,
for instance I cannot choose UTC as timezone, neither grub2 nor grub nor
lilo worked – but I got the latter installed manually now, etc.)

This new orking device still has more hours of “fun” for me, but as
for tomorrow, I’ll be driving to Berlin. I left that craptop at work.
I’ve got better things to do in the evenings.

Diego Biurrun, who was both actually present and interested in my
FrOSCon talk, pointed me to a paper called "Recursive Make Considered
Harmful" [1]. (Thank you!) In
response to the question he asked about this during the Q&A
session, I said that recursive Make is automake's default and only
behavior. This is not true.

The author of the paper starts with an example project very much like
mine (two .c files, one header) and creates an artificial module
boundary. Unsurprisingly, dependencies do not work as they should any
more. I have witnessed this phenomenon and have seen large recursive
build systems fall apart. Continuing a mozilla build for example takes
unacceptably long, and you see many IDL files unnecessarily being
regenerated.

However, implementing the one-Makefile-per-project technique outlined
by Miller is actually very easy to do in automake. Older automake
versions did not have good support for source files in other
directories but this has not been a problem at least since automake
1.8.

If you paid close attention, the Makefile.am I created in the talk
was not really recursive because only one Makefile actually did some
compiling. In fact, you can merge Makefile.am and src/Makefile.am into
one file, like this:

If you insert all your targets into one Makefile.am, the
automatically inserted stuff from automake only needs to be inserted
once, thus you get a lower overhead. Dependency tracking should be even
more efficient, and build times should decrease. One technique proposed
by Miller is to use per-project Makefile fragments which are included
by the main Makefile. Automake supports an include directive,
which is directly evaluated during the automake run and thus fully
portable.

One problem I see with this approach is that all objects are put into
one directory. Thus, you will have problems if different files in
different directories have the same name. For example, compiling both
foo/main.c and bar/main.c inside the same Makefile.am
will not work. I do not know if there is an easy solution to this
problem—perhaps an automake option to put the object files in
subdirectories. Any automake expert reading this, please contact me if
you know of something.