I’m sorry to miss FOSDEM, but huge events during a pandemic should be avoided, and given others do not mask, attending involves some danger. I’m sitting this out; maybe another time? I do miss it…

So, apparently, DNS names can only be up to 253 octets long in ASCII form. The label length octets need accounting. Thanks jschauma!
Consequently, my rfc822 library and tool version 0.7 was released.

Debian 11 “bullseye” was released today (it’s still the 14ᵗʰ for me…) as well. I switched all my unstable “sid” systems to bullseye to avoid systemd’s UsrMove, which (per Technical Committee) is mandatory to be supported in any subsequent release (gah!). Still, congratulations!

Due to RT’s porting efforts, I’m still not finished with the mksh things I wanted to do, but am continuing with others. I’ll release a new sleep(1) soon (but, maybe, we can test it on many platforms first?) and guess I’ll switch ed and jupp to mirtoconf as well when I find the time.

I also had fun with… ISO 3166, ccTLDs, etc. and wtf(1). Added lots, and also deduplicated, in the acronyms database. Not the 1300+ gTLDs though. They’re insane, ICAN’t doesn’t publish either which ones are still active or their meaning (corresponding to those already present). Anyway please enjoy! Submissions, as usual, welcome ☺

My contribution to Free Sheet Music is also growing. I slightly reorganised the index (left side) of the main website, only select subprojects are now shown, but all, including musical things, the Foundry etc. are listed in the page about subprojects, some just with a small link or placeholder, others with much more. I think there may be more to add… but this, and some hyperlinking (in all directions), could help.

Now off to sleep. Our cat is already sleeping again. Thankfully, this is (probably) the last really warm day.

After Garmin’s proprietary “opencaching.com” platform, which virtually nobody pined after, and ignoring that Navicache has not been more than a zombie for quite a while, I am regretting GPSgames.org (who offered just so much more than just geocaching — GeoDashing, GeoVexilla (I partook in both), Shutterspot (not for me), MinuteWar, GeoGolf and GeoPoker (which I never really got) — although I guess GeoHashing is the closest thing to, at least, GeoDashing) is no more. A month later, it doesn’t look it will ever be resurrected, even though this outage is unplanned; an archival was scheduled for later, which is quite a pity — I had renewed my interest in them due to the pandemic, but that was to be planned and keeping historic data intact.

This was the only platform which used a Free licence for its content (CC-BY-SA), even if, like all others, it required a more broad grant from contributors. Now, only nōn-free platforms (like the OpenCaching network) are left; only commercialising seems to save most. Pity.

Update 2022-10-22: navicache.com, having been mostly unusable due to bugs already for years, is now also gone: whoever operated this let the domain expire. The log and cache database is most likely also gone forever.

The server became unresponsible because the load went up due to idiotic web crawlers, not respecting robots.txt or ignoring CGIs, hammering httpd(8). After reboot and fsck(8) I’ve configured CGIs to use a rather harsh setrlimit(2) RLIMIT_TIME, a MirBSD speciality. This should prevent repeating this issue.

As a consequence, some requests, for example annotating in CVSweb on large files (acronyms DB for wtf(1)) will now fail or (diffing between revisions on that file) return incomplete results. SOL.

This is why we can’t have nice things.

ObOTRant: The W3C specification requires the XMLSerializer[sic!] shipped in ECMAscript-capable web browsers to produce invalid XML. (The underlying algorithm is permitted elsewhere to instead raise an exception but even though a (pretty bad, e.g. it suggests dropping instead of entity-escaping -- inside a comment node) specification for fixing up such DOM trees preparing for XML serialisation exists, the spec prevents using it. The whole “web world” is just a steaming PoS really…

Maybe someone wonders about this, maybe I just want to get back to this for ordering or so… but here is my current list of things, as much as I’m recalling at the moment anyway:

• mksh for bullseye: escape C0/C1 properly (+klibc/s390x)
• MuseScore* for bullseye: fix Debian #985129
• MirBSD libc: add proper "C" locale in addition to our "C.UTF-8"
• (Update 2021-12-26) maybe three… "C" for POSIX, "" for OPTU-* stuff, and "C.UTF-8" which would reject raw octets. Or "C.UTF-8@optu" and "C.UTF-8@strict". Unsure. Working on these things now.
• mksh: full locale tracking with BOM processing removal
• MirBSD: port newer OpenSSH
• mksh: full 21-bit UCS support (replace OPTU-8/OPTU-16 with UTF-8 and a scheme that maps raw octets to somewhere above U-0010FFFF)
• MirBSD: same switching wchar_t to uint32_t (flag day)
• (Update 2021-08-15) switch sparc time_t to 64 bit like i386, since we’re doing a flag day already anyway (sparc assembly experts for locore.s and other changes and OpenBSD 3.x-era kernel experts contributions welcome…)

That, and a few small things (such as implement things like pre-exec hooks and vared for mksh). Oh and port a new libcrypto/libssl for TLS 1.2+ support… out of the many bad alternatives, LibreSSL looks to be the least bad contender. Licence analysis as necessary, ripping out code not under Free licences as per MirBSD’s FOSS charter.

If someone is interested in helping out with GCC: there’s work begun around https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53119 to make it not warn for the “universal zero initialiser” (struct foo bar = {0};) which to use is more correct than memset(3)ting everything to NUL. The git history of GCC is insufficient to figure out all related changes so diving in its SVN repository is necessary. Fix that for our system compiler (in-tree GCC 3.4).

I’m also collecting new glyphs to be done for FixedMisc [MirOS] and plan on working on a second-generation Inconsolata fork under OFL.

I’ve created another SF2 format SoundFont, at a whopping 12¾ KiB in size, which contains the two samples used by MuseScore’s metronome, e.g. to “count in” before the players begin. Turns out MuseScore cannot export the “count in” to audio, and users who need e.g. a click track or even just “giving the pitches” to singers before counting in will need to add it manually, anyway.

MuseScore uses two hard-coded samples, copied from MusE which in turn copied these from Ardour whose lead developer Paul Davis was very helpful in discovering the provenance of these samples (turns out they were generated mathematically, so they are not copyrightable) and reviewing the soundfont metadata cum instructions.

This soundfont can be used with any SF2-compatible synthesiser; the following instructions can be used with MuseScore, as well as anything that throws MIDI note events to e.g. timidity or fluidsynth:

• Add the soundfont to the synthesiser. If loading in MuseScore ensure it’s listed below any other soundfont(s).
• Assign the patch “Metronom”, available as drumset (bank 128, preset 48, matching MuseScore Orchestra Kit) or ordinary (bank 0, preset 115, matching MuseScore Woodblock¹), to either a pitched instrument (e.g. temporarily via a mid-stave/‑staff instrument change) or percussion stave (e.g. MuseScore Wood Blocks). (Keep the volume at or near 100, which is close to what mu͒ itself uses, even though the beats are slightly easier to distinguish.)
• Enter notes for each beat: a tick (E₅, MIDI note 76, mu͒ High Woodblock) on the downbeat (first beat in a measure), a tack (F₅, MIDI note 77, mu͒ Low Woodblock) for all others. In 4/4 time, for example, this means a tick and three tacks.
• Select all Metronom notes and open mu͒ Inspector (F8 key). Change Velocity type to “User”, then set Velocity, for all notes at first, to 127. Next, select the unstressed beats only (in 4/4 time again, the second and fourth note) and change their Velocity to 80.

Users of DAWs and other synthesisers may benefit from the following short representation (velocity is absolute):

As can be seen in the above picture, a vocal (or instrumental) stave can, temporarily, be repurposed (e.g. for counting in) as metronome, or a separate percussion track can yield a click track. The MIDI notes were chosen so that the mu͒ Wood Blocks (unpitched percussion) instrument can be used for this out of the box — and because Wood Blocks used to be the common alternative for metronome tracks before the existence of this soundfont). Note also the accidental ♮ to nullify the key signature’s F♯ on the vocal stave to obtain the correct F₅ note. Not shown: ensure the tempo text is placed on (or before) the first click track note when counting in.

The SoundFont is published under CC0 (whose § 2 does not apply because I cannot legally waive/abandon copyright in my legislation). Discussion on the MuseScore forum for soundfonts, please.

① The Woodblock preset in the standard MuseScore_General soundfont has only one sample though so it’s not really comparable to this.

Ich habe gestern Nacht von den neuesten Plänen der Bundesregierung mitbekommen. Das überschreitet jetzt meine persönliche Grenzlinie. Bisher habe ich alles mitgemacht, vieles unterstützt, weil es sinnvoll ist, auch wenn mir das nicht paßt, aber das geht jetzt zu weit. Das Vertrauen, soweit man bei Politikern davon sprechen kann, hatte ich ohnehin schon verloren, aber jetzt ist auch der Boden raus vom Faß.

Und heute lese ich, daß Bayern das wohl schon seit längerem habe und es genau NICHTS bringt, ebenso Rumänien (wo nur die Läden pleite gehen und sich die, die es in der Arbeitszeit nicht schaffen einzukaufen, in den Tankstellen die Türklinke in die Hand geben. Wie unerwartet.</sarkasmus>

Stattdessen wird das doch nur dazu führen, daß die Idioten, deren private Treffen man unterbinden will, das einfach zu 100% oder sogar mehr (weil das Wetter ja besser wird) tagsüber machen, und uns, den… mittlerweile muß man ja leider sagen Deppen, die einfach alles mit sich machen lassen, benachteiligt das noch mehr. Aber die Schulen auflassen… aber da geht’s ja auch ausschließlich drum, daß Eltern auch im Homeoffice arbeiten können und nicht durch ihre Kinder daran gestört werden.

Fickt euch, drecks Politiker=Verbrecher!

Jedenfalls komme ich kaum noch mit Arbeit und Leben hinterher, leide unter den Folgen von z.B. reduzierten Arztbesuchen und Massagen, und eigentlich wäre mehr, nicht weniger, Bewegung angebracht. Ich mache nachts Spaziergänge, gerade weil da kaum noch Idioten draußen sind, und nun soll mir das genommen werden.

I’ve just committed a change to /etc/profile that sets LC_ALL=C.UTF-8 as the default locale. We used to set LC_CTYPE=en_US.UTF-8 which was a little friendlier when forwarded over ssh, but that 2009 proposal of mine is spreading and we standardise on it now. cleanenv now also sets it in “clean fully” modes (i.e. without dash or slash as first argument) and I expect more to follow.

In a next step libc will have a binary toggle between C and C.UTF-8 (somewhat again), locale(1) and setlocale(3) corresponding. mksh will implement full locale tracking (for systems without setlocale, C will be the “implementation-specified default locale”, and I think we’ll have the same for MirBSD libc; there’s talk in… Debian or glibc? to switch it to C.UTF-8 but AFAIK that’s not been tested yet, and the locale upon entering main is mandated to be C anyway so we won’t really gain much except, perhaps, confusion).

I may add a double build where processes that would now be run under C locale warn (per syslog or so) to detect that since as of currently MirBSD has only the C.UTF-8 locale. (This is a problem, but which has been proven to be one only recently.)

lksh(1) will still consider POSIX compliance only for the C locale, but turning on POSIX mode may no longer turn off UTF-8 mode as the locale environment variables are the then-only determining factor. (Manually toggling set ±U will of course still work.) In the same vain presence of the BOM may not affect the UTF-8 mode flag any longer either.

It’ll be a bumpy ride, especially for MirBSD itself, but we’ll sure manage. For mksh(1), it’ll be R60, which will be a real major release, carrying more deep changes. Removal of the cat(1) and sleep(1) builtins is already done, Debian bullseye already carries the early (originally done for SuSE) locale tracking, and users request full 21-bit UCS which R60 is certainly a very good poing in time to implement it.

Update 2021-04-08: mksh(1) as shipped in Debian 11 “bullseye” will already implement locale tracking, even though some more changes, such as the BOM handling removal, have not made the cut yet (mostly because I’m testing the changes excessively first).

Some upheaval continues: I’m still working (in the background) on porting latest OpenSSH, and we’ll direly need a newer SSL library. It will probably turn out to be LibreSSL, despite all the trouble with LibreSSL OpenSSL is dead (the illegal licence change for 3.0 isn’t acceptable as the chosen new licence not only is less free, it’s also incompatible with the GPLv2 just as the old licence!), and the other forks are even more questionable, fragile, whether workable with a BSD at all. Time will tell.

Thankfully at least the recent sudo(8) issue did not hit. But given sudo was already at version 1.4 in 1996(!), and after having backported the fixes to some old Debian releases and derivatives, I understand why OpenBSD threw it all away and wrote doas.

Downstreams don’t have it easy. They need to be informed about new upstream releases but there’s no uniform way to do that. Debian has uscan and the DEHS (Debian External Health Status), rsc is monitoring me using Fedora infrastructure, etc. but other projects, such as the AOSP (Android Open Source Project) seemingly don’t have such a resource set up. Recently, the desire for an mksh-announce@ mailing list was stated.

Mailing list spam is a thing (sorry about that), and I currently do not have anything set up that would allow me to make it possible for only me to post to a list. But we do have RSS feeds; e.g. for my APT repo I use a script creating one easily from a plaintext file, and the MirBSD wlog infrastructure has a (complex) setup, creating RSS and HTML, paginated and permalinks, off a data file.

Enter the MirBSD “announce” (valid RSS 2.0) feed, which will provide information relevant for downstreams (especially subproject releases), and the occasional MirBSD snapshot, ISO or release. I chose the former (easy script from plaintext) for this and will occasionally prune older entries.

http://www.mirbsd.org/announce.rss

In the hope of being able to help, I wish my downstreams a blessed time, with most calendaries just having entered a new year.

I’ve been using “a Unicode (and ASCII) field separator” for my SSV flavour of CSV. I thought I should be using the FS control character (considering “FS”, according to much documentation, is a field separator).

Turns out most Unicode control characters have shitty official names and/or acronyms/abbreviations… such as…

• PLD: partial line forward (not: partial line down)
• SPA: start of guarded area (not: start of protected area)
• VTS: line tabulation set (not: vertical tabulation set)
• DC1: device control one (not: XON)
• RI: reverse line feed (not: reverse index)
• NP: form feed (probably for “new page”)
• NL: line feed (not newline, but we weren’t expecting that either, as an ASCII newline is CR+LF plus Unicode C1 has NEL (next line)…)
• Adding insult to injury, U+0080, U+0081, U+0084 and U+0099 do not even have a name (but Unicode “name aliases” which include an acronym (which (of course) WTF knows about) and at least a longer name).

… and so forth. There’s separators, too!

• FS: [U+001C] [␜] INFORMATION SEPARATOR FOUR [file separator]
• GS: [U+001D] [␝] INFORMATION SEPARATOR THREE [group separator]
• RS: [U+001E] [␞] INFORMATION SEPARATOR TWO [record separator]
• US: [U+001F] [␟] INFORMATION SEPARATOR ONE [unit separator]

And guess what… ASCII and Unicode FS is file separator (US is field separator). Oops. Sorry.

So… I guess when I use SSV next I’ll update (change in an incompatible way) the spec. Again, sorry about that.

It’s only in another 48 minutes but enjoy the Solstice! Blessed be!

I’ve created an SF2 format SoundFont (compressing to SF3 is not worth it really) for use on RAM-constrained devices, such as the Raspberry Pi. It’s comprised of:

• the piano from Fluid (R3) Mono 2.315 (which is very slim, one twenty-fifth the size of a wonderful new piano in MS_General)
• monoified (left channel, panned to centre) Choir Aahs (to save another 2½ MB) from MuseScore_General 0.2 (expressive and regular, for SND support)
• the harpsichord from MuseScore_General 0.2

The result, a whopping 7.3 MiB, is enough for accompanied voice, therefore called “SATBkc” — SATB, Klavier (Pianoforte), Cembalo (Harpsichord). It’s published under the same MIT licence as its two constituent soundfonts.

Download the soundfont (not going to package it, it has limited use) as well as a test score (in v3 format, it tests Single Note Dynamics too) if desired. Discussion on the MuseScore forum for soundfonts, please. Also remember that the waveforms generated from the soundfonts are, most likely, derivative works, requiring reproduction of legal notices.

Combined with TimGM6mb, this gives you full GM but better sounds for some instruments in just 13 MiB HDD and RAM (both are uncompressed SF2). “Choir Aahs” still could be better, but they are not “Choir Aarghs” any more at least ☺ TimGM6mb is GPLv2-only though so not universally usable (YMMV).

OK, toned down on the rant, I already did enough in the commit messages…

My webpages are valid XHTML/1.1. But what does that mean?

I write them conforming to XHTML/1.1, with spaces before the “/>” sequence. This allows me use of tools such as xmlstarlet to operate on them as XML files, and even validation against the DTD, offline. That “extra” space allows HTML browsers to process them as HTML. I’m now, as per some part of the spec, supposed to serve them over HTTP as application/xhtml+xml content type — two questions: why does the XHTML spec say anything about HTTP, and, why doesn’t another spec agree with it?

Turns out, much later, it has a reason — the XHTML/1.1 spec is mostly just a diff against XHTML/1.0 Strict, which is just a diff against HTML 4.01 Strict. The HTML5 spec (both concurrents, W3C and WHATWG) is however standalone and merges the XHTML parts. It, now, in contrast to the three older specs I mentioned above, has a side note, in a tag-specific chapter (with nothing mentioned in the XML part), explaining a parsing difference (basically, in XML mode, it doesn’t skip a leading newline immediately after an opening pre tag). Fucktards.

I’ll just serve my XHTML/1.1 files only as text/html now, even if I get an Accepts for XHTML+XML from the request. (The HTML5 spec, at least one, now forbids me to use XML namespaces, both for things like embedded SVG (I am supposed to just use an <svg> tag) and custom ones, e.g. to embed DC in SVG… but we all know just how binding this is for browsers, and that browsers will handle all kinds of things under the sun, and then some, so I’m ignoring this, ’sides, I even don’t write XHTML5 at all…)

Anyway the too-large space around section and subsection headers in our HTML manpages is now “fixed”, for some very low value thereof (but with HTML and CSS the expectation is extremely low anyway…).