MirBSD Weblog

Sponsored by
HostEurope Logo

MirBSD Weblog

All 1 2 3 4 5 6 7 8 9 10 11

Today, not only Teaching the younguns: fun in the outdoorsme, but also weird nick, eh?gecko2 found another two caches. And: I think I hooked up Benny, as I found a couple in the vicinity of his hometown at his parents’ place.

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. ☹

The remainder of my new server is looking good, though.

Besides bumping the number of A cachetour and nice weather 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.)

mksh(1) still doesn’t correctly work (continue is broken) with the promising portable C compiler though. It really is a pity, but I don’t have a clue (yet).

(Damn, now I coded a whole lot of crap, even added C7 RNG/AES support despite planning to not hack. I guess I should get a life. On the other hand, the weather isn’t promising enough for that.)

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 Virtual Geocacheing is fun too 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…

Woo-hoo! Even homsn got his arse moved, Arch GNU/Linux now has mksh R31c, like Fedora, Gentoo, soon Fink. World domination, anyone?

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 Porter Das fruchtige Schwarze, Neuzeller Kloster-Bräu Schwarzer Abt Schwarzbier, 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.

mksh R31 is out, grab it while it’s hot ☻

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:

ACLOCAL_AMFLAGS = -I .

bin_PROGRAMS = hw
hw_SOURCES = src/main.c src/hello.h
hw_LDADD = libhello.la

lib_LTLIBRARIES = libhello.la
libhello_la_SOURCES = src/hello.c src/hello.h
libhello_la_LDFLAGS = -version-info ${LIBHELLO_VER}

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.

References

  1. Miller, P. A., Recursive Make Considered Harmful, AUUGN Journal of AUUG Inc., 19 (1), 14–25 (1998).

    URL: http://miller.emu.id.au/pmiller/books/rmch/

All 1 2 3 4 5 6 7 8 9 10 11

MirOS Logo