While I didn't have much time today during work due to some lecture, my SPARCstation 20 was busy building a snapshot (and still is, and even will still be the next day or more), Dr. Pfeffer improved CacheWolf further, I bought a GPS mouse at ePray (together with Addy, the “& friends” part from the last try, and an intern who seems to like the idea), read raw NMEA 0183 output from wbx@’s device and conjured nmeadecode(8) which, until we get nmea(4) and friends, will just read the serial stuff from userland, timestamp it, act as simple NTP server (to use with serverloop in ntpd.conf(5) and bound on a different port), and display position data to stdout.

There are interesting things to be found in anybody's source tree. This time, it is Schily again. Well, it could be cleaned up, and arc4random(3) got improved as well, except I still think it should have a kind of timer for smaller entropy adds (⅛ of the arc4 key size).

On the other hand SPARC looks rock solid now, I could even build a gnat (GCC's Ada part) today. Let's hope we'll have a snapshot in 2-3 days, and maybe MirOS #10/sparc will be in #10semel this time.

The website… some things are difficult to do until you go to the toilet and come back with a great idea. Put back mtimes on the pages.

At work, I hacked some major C code for FreeWRT today, namely in the nfotiser (and here[link removed]). That's a complicated program, difficult to do even for me (mostly since it grows high-level stuff, data structures, and not only close-to-machine stuff, especially the SQL stuff), but it turns out to become fun once you get into “hacking mode”.

Tonight's after-work event is LUUSA (at the Netzladen) again.

Waldemar brought his Zaurus, but there's no Ewe VM. On the other hand — after some kernel patches and downloading Ewe149-Linux-x86.zip as well as cachewolf_linux_0.9n_patch_4.zip — the first from ewesoft.com, the second from cachewolf.de — and unpacking, it worked out of the box; remember the device name is relative to /dev (I had to use “cuaU0” and “9600” as baud rate, add myself to group dialer too). I did need some shared lib from Debian GNU/Linux for that (libgcc_s.so.1) though. Compiling Ewe is — at the moment — apparently impossible, it always segfaults both on MirBSD (i386) and Ångström Linux (armv5tel/Zaurus). I'm importing caches from my site (opencaching.de) now, after recentering to my current location (as I am too lazy to figure out the GPS position of my home right now). Now, if I had a huge battery on this laptop (the current one can hold an hour or so only), I could use it for geocacheing.

UPDATE: This even led to spotting bugs in MirPorts and CacheWolf.

It looks as if I finally have found a few cases of bad programming that caused the segfaults and other misbehaviour on sparc. Now let's just come all the former Debian GNU/Linux/sparc users. Okay, I've got to compile it a few times more, and pre-#10 I'd like to do one more code change, namely the switch from suncons to vt100, but… what the hey ☺ I'm happy.

I'm currently building on a 75 MHz SuperSPARC and would be glad if some nice person would send me one of these 233 MHz HyperSPARC modules that've been made by ROSS (I think), and some more RAM for a SPARCstation 20 UP — we don't support SMP on sparc either. And I desparately need 1-2 testers, since I don't use a monitor/keyboard/mouse zs console but “merely” a real DEC VT420 on ttya.

On HTML: see my rants about standards.

Anyway, despite the bugs found during the sparc compiling progress, our tree is in a pretty sane state and ready for release every day or so. I'm postponing it a bit in the hope less bugs will be found post-release, and Benny is still continuing his ports work, despite having to create slides for that talk at FrOSCon and doing his diploma stuff all day. Thanks Benny what would MirOS be without you.

I've still got my dayjob, and working with parsing, databases, SQL, and C string operations at the same time isn't really fun. But it's me who is able to make FreeWRT 1.1 shine, so I've got to do it. I bet it'll have been a lot of fun once I'm done. Just the way there is hard. So be it. On the contrary, my boss's got a Zaurus, and Dr. Pfeffer's geocacheing software (in Java™) runs on it. And he will not only make these trips with us but also lend it to one of us if he has no time but we want to go. That's the benefit of a small company.

The BOSng Duo has found another cache, although with minor injuries, we hooked up a friend to the fun and had a definitively nice view.

Yesterday, I talked some with the MidnightBSD people. I think that they are quite okay and invited them over for FrOSCon. Maybe at least one from that bunch comes, then we'll finally have all BSDs at once.

My dayjob is really keeping me busy, I'm almost only home for sleeping; but that's okay, I even get to do mksh stuff at work since it's the shell of choice in FreeWRT Trunk (to be 1.1), which is what we use and develop. Speaking of mksh, I'd like to release R30 rather sooner than later.

Benny's busy coding WinAPI at work, poor lad, but it could be worse, as STL or MFC or so. On the other hand, he does still fix ports and package tools (we have a security updated BIND now, for instance). Thanks Benny, we really appreciate that.

Speaking of MirPorts — the MidnightBSD people have “mports”, which seem to be FreeBSD ports based (*grins* I wonder why they didn't use pkgsrc®…) and I suggested them to use MirPorts as a second choice (like pkgsrc® for us), after Archite (coming from OgreBSD) couldn't persuade them to choose only MirPorts he'll probably look into that now. We'll help, but we can't maintain it. I just wish dfjoerg would commit the MirBSD bits in pkgsrc®, since otherwise I wonder why I did all that work if nobody's going to use it due to missing upstream inclusion. Lazy git. mksh's still at R29f.

From time to time, I'm uploading a new snapshot to the netinstall dir — it pays off to look there. Today's one was tested on a WRAP board.

I think one of the two HDDs in herc which compose the RAID 1 (software, using raid(4) — RAIDframe) is definitively failing. I need a replacement; maybe I'll do as few activity as possible on /MirOS/ and the CVS repository in the meantime to extend its life span. This sucks, and I see I won't be able to relax next weekend either.

We have a new snapshot — MirOS #10 RC2 — yet not announced on the front page because I need to rsync it to the mirrors first (RAID issue) and put up a torrent (time issue, I do have a dayjob now). But it should appear @ the http mirrors (heph and allbsd.org) soon, in /MirOS/current/, as usual.

Not the best day for fate… herc had an almost-panic in the UFS code, my bedside lamp got crashed by the telephone receiver when gecko2 called me, I had to nuke tcpdump(8) due to §202c StGB, and mksh R29g was only almost tested before release (it defines _LARGEFILE_SOURCE=1 even if it is unnecessary). I am even thinking of removing all pre-R30 stuff off the mksh page once R30 is out (which might, I must admit, not happen before MirOS #10, but it will rock). At least MirOS #10RC2 is going to happen soon, despite some bugs in the pak- kage tools bsiegert@ is trying to hunt down right now.

À propos gecko2: as he (and zeno) are booth staff, bsiegert@ and I have agreed to enable them to post wlogs here, so don't be shocked. kimnotyze, probably hoping to get an entry ticket from me, said he'll help out staff at FrOSCon as well, but doesn't wlog as of now (this may change if he's involved more).

I added cprng to the base system, a daemon tjat tries to gather entropy from measuring the difference between the CPU clock and timer interrupt — an interesting idea, yet it doesn't work on all hardware. Still better to have it than to not have good local entropy, besides it's fed to the kernel random(9) subsystem alongside with tty(4), disc and network IO (and possibly truly random stuff from the VIA C3/C7 RNG, hifn(4) cards or even from hotbits/fourmilab/randomnumbers.info). The mix is what makes it good, but arc4random(3) with multiple concurrent accesses is a difference to more popular OSes ☺ which makes it truly great. So just use one source of entropy — /dev/arandom — which is rather high-quality even if its absolute entropy count is less than the one from urandom.

Somehow, I also managed to wreck something in my other pet project — FreeWRT. It is often annoying to work with Linux, and this shows it one more time: module loading doesn't work, and we have issues with binary-only stuff (BLOBs) too. Still it is slowly being undermined by addition of mir-tools to the system ☻ and — while a̲l̲l̲ embedded system development kits suck, this one sucks the least.

A few days ago, I had access to a Soekris vpn1411 card — hifn(4) — that just worked™ out of the box on a bsd.rd kernel. Nice. I noted that rdate, as well as uuencode(1) and uudecode(1) and their base64 variants were not available, so I added them; rdate(8) even fits on the small floppy (8KiB) and is now The Official ping6(8) Replacement™ on floppy, since the latter is about 28K.

Today I officially declare that gdb(1) isn't usable on MirOS. I tracked down an GCC bug but was confused because a “load register with immediate” opcode appeared to change memory (the stack frame — the print command did not seem to be affected). But hey, I eventually found the bug. Now, all I wait for is Sun to release their compiler under MIT licence… as if.

As part of the GNOME update to 2.18, I added a python flavour to libxml2. This seems to confuse pkg_add and triggers a bug (one more) in the dependency handling code. Incidentally, the code in question is written in Perl by Marc Espie.

To completely fix the bug requires removing pkg(1) completely, which I will not be able to do before MirOS #10. As a first step, the verbose output of pkg is now more meaningful, allowing (hopefully) to debug the issue.

The way dependencies are handled is deeply flawed and is one of the biggest weaknesses in the current MirPorts framework. pkg(1) converts the dependencies into static @pkgdep lines of the form "@pkgdep libxml-2.6.14-2". If a libspec cannot be resolved, the adding almost certainly fails *sigh*.

It's mksh-bash compatibility week, apparently. Now, ${foo:2:3} works, but these must be numbers, not arithmetic expressions, as of yet — this should be fixed soon though. Also, ${foo/bar/baz} (regexp), as well as its companion ${foo//bar/baz} (like g appended) won't be much of a problem but I'll implement ${foo:S/bar/baz/g} first followed by ${foo:C/bar/baz/gx}, make(1)-style (x = to use POSIX extended regexps instead of basic). Of course, this'll only work if a few functions like regcomp(3) are in libc and functional and MKSH_SMALL isn't defined ☺

MirBSD Secure Shell (sshd) is now built as position-independent code to make it even more than OpenBSD's OpenSSH. Yay! (bsiegert@ thinks so too.) Eat this ☻

Before I forget to write this down… today, I released a piece of code I call libnointl. This was an original idea (and implementation¹) of mine, but I only got it because of swishy (Dale Anderson) who complained about his cross-compiling issues and troubles to me in IRC (I'm feeling the same when working for and with FreeWRT; he's also using µClibc, but non-POSIX FSH paths). Thanks for the intuition; if I get famous (FreeWRT and OpenWrt are already adopting it), you shall become it too.

¹) The API is part from gettext's libintl.h header — only from the non-copyrightable interface part only — and the ABI is re-engineered, using nm(1). There is one function actually doing something inside, whose implementation is from Dr. Dobb's Journal (but easily doable within a few minutes, and found at many other places on the net), optimised by me, and adjusted to match GNU gettext libintl's behavious, of course.

Han Boetes suggested to feed it back to the GNU gettext people… I guess they won't like the licence (MirBSD licence + advertising clause, but GPL compatible), as it's a GNU project they probably want the paperwork.

We now have an uppercase Eszett (ſz ligature) ẞ in the fixed-misc fonts and my keymap; it maps towlower(L'ẞ' == 0x1E9E) = L'ß' == 0x00DF, whose upper-case mapping stays at L"SS" though. I sent the changes in the font to Markus Kuhn, hoping he will integrate them in the next stock XFree86® (and that x.org crap too…) version.

mksh is now a better /bin/sh for some people in Debilian who don't know of Korn Shell tradition. Also, it won't try to execute ELF, a.out, COFF, gzip and NE any longer.

Been working on FreeWRT all the time (even during the dayjob), so I didn't have the energy left to do more on the SPARC issues.

Okay, since this thing is here anyway, let's use it to update you people on the progress of the sparc port.

The kernel boots and runs fine. The hardware seems to be okay, the new HDD (sd0) gets a little warm at times, but that doesn't seem to cause any problems.

I reliably get segmentation faults for a lot of things — usually things that access the network, more rarely during compiling. Can't get stack traces as the stack is corrupt.

Just to be safe, I'll try out the other 9 GB HDD tyler got me. Maybe this one is the cause of the troubles, but I don't think so. On the other hand, I might just try to upgrade the existing #9 snapshot to #10 via source and with NO_ADA=Yes set. If that works…

As I said, having sparc support is not a release criterium for #10, but it'd still be nice to have. I already spotted bugs… but don't expect me to hack much on it, I've got a dayjob requiring full attention and hacking skills (mostly embedded GNU/Linux for mips, though, but luckily most shell scripting I do is in mksh, and I can use jupp; no BSD make there though).