![[Valid RSS]](images/valid-rss-rogers.png "Valid RSS")
This is a valid RSS feed.
This feed is valid, but interoperability with the widest range of feed readers could be improved by implementing the following recommendations.
<rss xmlns:atom="http://www.w3.org/2005/Atom" xmlns:dc="http://purl.org/dc/elements/1.1/" version="2.0"><channel xml:lang="en"> <title>Developers’ Weblog</title> <description>MirOS ξ — MirBSD</description> <atom:link href="http://www.mirbsd.org/wlog-10.rss" rel="self" type="application/rss+xml" /> <lastBuildDate>Wed, 03 Jan 2024 23:44:18 +0000</lastBuildDate> <link>http://www.mirbsd.org/</link> <copyright>All content Copyright © MirBSD and its respective writers. ⚠ Some content may be outdated, obsolete, old or WIP, no warranties! Permission to reproduce news and wlog entries and other RSS feed content in unmodified form without notice is granted provided they are not used to endorse or promote any products or opinions (other than what was expressed by the author) and without taking them out of context. Written permission from the copyright owner must be obtained for everything else. Impressum: http://www.mirbsd.org/imprint.htm</copyright> <dc:language>en</dc:language> <ttl>14400</ttl> <generator>MirBSD Website, written in mksh; RCS IDs: $MirOS: www/mk/parser,v 1.33 2018/05/06 13:23:36 tg Exp $ $MirOS: www/mk/common,v 1.12 2021/12/11 20:10:49 tg Exp $ $MirOS: www/mk/htsconv,v 1.117 2023/12/04 23:08:14 tg Exp $ $MirOS: www/mk/inc2rss,v 1.51 2023/09/22 01:49:52 tg Exp $ RCS IDs of the content database: $MirOS: www/data/wlog-10.cfg,v 1.13 2021/05/26 22:08:01 tg Exp $ $MirOS: www/data/wlog-10.inc,v 1.509 2023/01/03 17:28:34 tg Exp $ $MirOS: www/data/wlog-10-tg.inc,v 1.9 2023/01/03 17:28:33 tg Exp $ $MirOS: www/data/wlog2018.inc,v 1.8 2023/01/03 17:28:38 tg Exp $ $MirOS: www/data/wlog2019.inc,v 1.12 2022/05/13 21:52:30 tg Exp $ $MirOS: www/data/wlog2020.inc,v 1.22 2024/01/03 23:26:46 tg Exp $ $MirOS: www/data/wlog2021.inc,v 1.8 2023/09/06 03:10:53 tg Exp $ </generator><item><title>TLSv1.2+-capable mirror</title><pubDate>Tue, 05 Sep 2023 00:00:00 +0000</pubDate><link>http://www.mirbsd.org/permalinks/wlog2021_e20230905.htm#e20230905_wlog2021</link><guid isPermaLink="true">http://www.mirbsd.org/permalinks/wlog2021_e20230905.htm</guid><description xml:space="preserve"><p>Due to high demand, I’ve set up a Debian GNU/Linux VM that I already operate for multiple other purposes, and which already carried a mirror of MirBSD CVS and downloads, to also mirror (per rsync-over-ssh) the website and expose all that as a publicly accessible web mirror complete with SSL certificate and all that. The server supports TLSv1.2 and TLSv1.3 but should also still work with TLSv1.0 and without SNI, and, of course, plain <tt>http</tt> also continues to work.</p><p>tl;dr: <tt>https://mbsd.evolvis.org/</tt> with the usual URL paths.</p><p>Given that it’s not running on native MirBSD, there may be a few caveats; I’ve proxied the “give me entropy” CGIs to the main machine via <tt>https</tt> and made everything else work, but at least the diffs generated from CVSweb have slightly different hunk distribution. The static content (i.e. all those <tt>*.htm</tt> files as well as the <tt>/MirOS/**</tt> downloads) are of course bitwise identical, and, as I’ve patched <tt>rsync</tt> on MirBSD to account for leap seconds but convert to POSIX <tt>time_t</tt> on the wire as expected, the timestamps should also be identical (unless I do manage to release some software during a leap second, which so far I haven’t, but the Time::Local tests managed to hit one precisely *sigh…*).</p><p>I expect that URL to stay stable even across future planned migrations of the machine to a different setup and, possibly, provider; this is why this got a separate, specific hostname.</p><p>TLSv1.2 support in MirBSD, I’m afraid, still has no ETA, given that I have other construction sites open and do dayjob and stuff.</p></description></item><item><title>Missing FOSDEM</title><pubDate>Sat, 04 Feb 2023 00:00:00 +0000</pubDate><link>http://www.mirbsd.org/permalinks/wlog2021_e20230204.htm#e20230204_wlog2021</link><guid isPermaLink="true">http://www.mirbsd.org/permalinks/wlog2021_e20230204.htm</guid><category>event</category><description xml:space="preserve"><p>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…</p></description></item><item><title>Releases, releases…</title><pubDate>Sun, 15 Aug 2021 00:00:00 +0000</pubDate><link>http://www.mirbsd.org/permalinks/wlog2021_e20210815.htm#e20210815_wlog2021</link><guid isPermaLink="true">http://www.mirbsd.org/permalinks/wlog2021_e20210815.htm</guid><description xml:space="preserve"><p>So, apparently, DNS names can only be up to 253 octets long in ASCII form. The label length octets need accounting. Thanks jschauma!<br />Consequently, <a href="https://search.maven.org/artifact/org.evolvis.tartools/rfc822">my <tt>rfc822</tt> library and tool</a> version 0.7 was released.</p><p>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!</p><p>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 <a href="http://www.mirbsd.org/htman/i386/man1/sleep.htm" class="manlink">sleep(1)</a> 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.</p><p>I also had fun with… ISO 3166, ccTLDs, etc. and <a href="http://www.mirbsd.org/htman/i386/man1/wtf.htm" class="manlink">wtf(1)</a>. 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 <a href="http://www.mirbsd.org/wtf.htm">enjoy</a>! Submissions, as usual, welcome ☺</p><p><a href="http://www.mirbsd.org/music/free/">My contribution to Free Sheet Music</a> 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 <a href="http://www.mirbsd.org/subprj.htm">the page about subprojects</a>, some just with a small link or placeholder, others with much more. I <em>think</em> there may be more to add… but this, and some hyperlinking (in all directions), could help.</p><p>Now off to sleep. Our cat is already sleeping again. Thankfully, this is (probably) the last really warm day.</p></description></item><item><title>Farewell, GPSgames.org and navicache.com</title><pubDate>Wed, 21 Jul 2021 00:00:00 +0000</pubDate><link>http://www.mirbsd.org/permalinks/wlog2021_e20210721.htm#e20210721_wlog2021</link><guid isPermaLink="true">http://www.mirbsd.org/permalinks/wlog2021_e20210721.htm</guid><category>geocache</category><description xml:space="preserve"><p>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 <em>was</em> 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.</p><p>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.</p><p><strong>Update 2022-10-22:</strong> <tt>navicache.com</tt>, 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.</p></description></item><item><title>Harsh resource limits on CGIs set for the MirBSD server</title><pubDate>Mon, 31 May 2021 00:00:00 +0000</pubDate><link>http://www.mirbsd.org/permalinks/wlog2021_e20210531.htm#e20210531_wlog2021</link><guid isPermaLink="true">http://www.mirbsd.org/permalinks/wlog2021_e20210531.htm</guid><description xml:space="preserve"><p>The server became unresponsible because the load went up due to idiotic web crawlers, not respecting <tt>robots.txt</tt> or ignoring CGIs, hammering <a href="http://www.mirbsd.org/htman/i386/man8/httpd.htm" class="manlink">httpd(8)</a>. After reboot and <a href="http://www.mirbsd.org/htman/i386/man8/fsck.htm" class="manlink">fsck(8)</a> I’ve configured CGIs to use a rather harsh <a href="http://www.mirbsd.org/htman/i386/man2/setrlimit.htm" class="manlink">setrlimit(2)</a> <tt>RLIMIT_TIME</tt>, a MirBSD speciality. This should prevent repeating this issue.</p><p>As a consequence, some requests, for example annotating in CVSweb on large files (<tt>acronyms</tt> DB for <a href="http://www.mirbsd.org/htman/i386/man1/wtf.htm" class="manlink">wtf(1)</a>) will now fail or (diffing between revisions on that file) return incomplete results. SOL.</p><p>This is why we can’t have nice things.</p><p><a href="http://www.mirbsd.org/permalinks/wlog2021_e20210531.htm">(read more…)</a></p></description></item><item><title>What I’m working on at the moment</title><pubDate>Wed, 26 May 2021 00:00:00 +0000</pubDate><link>http://www.mirbsd.org/permalinks/wlog2021_e20210526.htm#e20210526_wlog2021</link><guid isPermaLink="true">http://www.mirbsd.org/permalinks/wlog2021_e20210526.htm</guid><description xml:space="preserve"><p>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:</p><ul><li>mksh for bullseye: escape C0/C1 properly (+klibc/s390x)</li><li>MuseScore* for bullseye: fix Debian #985129</li><li>MirBSD libc: add proper "C" locale in addition to our "C.UTF-8"</li><li>(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.</li><li>mksh: full locale tracking with BOM processing removal</li><li>MirBSD: port newer OpenSSH</li><li>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)</li><li>MirBSD: same switching <tt>wchar_t</tt> to <tt>uint32_t</tt> (flag day)</li><li>(Update 2021-08-15) switch sparc <tt>time_t</tt> to 64 bit like i386, since we’re doing a flag day already anyway (sparc assembly experts for <tt>locore.s</tt> and other changes and OpenBSD 3.x-era kernel experts contributions welcome…)</li></ul><p>That, and a few small things (such as implement things like pre-exec hooks and vared for mksh). Oh and port a new <tt>libcrypto</tt>/<tt>libssl</tt> 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.</p><p>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” (<tt>struct foo bar = {0};</tt>) which to use is more correct than <a href="http://www.mirbsd.org/htman/i386/man3/memset.htm" class="manlink">memset(3)</a>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).</p><p>I’m also collecting new glyphs to be done for <tt>FixedMisc [MirOS]</tt> and plan on working on a second-generation Inconsolata fork under OFL.</p></description></item><item><title>Ardour/MusE/MuseScore metronome as SoundFont</title><pubDate>Sat, 24 Apr 2021 01:22:00 +0000</pubDate><link>http://www.mirbsd.org/permalinks/wlog2020_e20210424.htm#e20210424_wlog2020</link><guid isPermaLink="true">http://www.mirbsd.org/permalinks/wlog2020_e20210424.htm</guid><category>music</category><description xml:space="preserve"><p>I’ve created another <a href="http://www.mirbsd.org/~tg/soundfont/">SF2 format SoundFont</a>, 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.</p><p>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.</p><p>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:</p><ul><li>Add the soundfont to the synthesiser. If loading in MuseScore ensure it’s listed <em>below</em> any other soundfont(s).</li><li>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.)</li><li>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.</li><li>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.</li></ul><p>Users of DAWs and other synthesisers may benefit from the following short representation (velocity is absolute):</p><table border="1"> <tr><th>beat type</th><th>note</th><th>velocity</th> <th>colour (in the picture below)</th></tr> <tr><td>downbeat</td><td>76 (E₅)</td><td>127</td> <td style="color:#00AA00;">green</td></tr> <tr><td>stressed</td><td>77 (F₅)</td><td>127</td> <td style="color:#FF0000;">red</td></tr> <tr><td>unstressed</td><td>77 (F₅)</td><td>80</td> <td style="color:#3300FF;">blue</td></tr> <tr><td>compound subbeat</td><td>77 (F₅)</td><td>25</td> <td>(not present)</td></tr> <tr><td>other subbeat</td><td>77 (F₅)</td><td>15</td> <td>(not present)</td></tr></table><p><img alt="Soprano stave temporarily acting as metronome (mind the key signature), repurposed Wood Blocks stave doing the same; notes colourised per function (downbeat, unstressed beat, stressed beat, unstressed beat)" src="http://www.mirbsd.org/pics/Metronom.png" /></p><p>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.</p><p>The SoundFont is published under CC0 (whose § 2 does not apply because I cannot legally waive/abandon copyright in my legislation), or alternatively (dual-licenced) under <a href="http://www.mirbsd.org/MirOS-Licence.htm">The MirOS Licence (“MirBSD”)</a>, or under the MIT licence as in Fluid (R3) Mono. <a href="https://musescore.org/en/node/320431">Discussion</a> on the MuseScore forum for soundfonts, please.</p><p>① The Woodblock preset in the standard MuseScore_General soundfont has only one sample though so it’s not really comparable to this.</p><hr /><p><strong>Update</strong> 2021-10-04: MS_General 0.2.1 added them as 010:115 “Metronome” (ordinary instrument), 128:055 “Metronome” (drumset).</p></description></item><item xml:lang="de-DE-1901"><title>Corona und ich kann nicht mehr</title><pubDate>Sun, 11 Apr 2021 00:00:00 +0000</pubDate><link>http://www.mirbsd.org/permalinks/wlog2020_e20210411.htm#e20210411_wlog2020</link><guid isPermaLink="true">http://www.mirbsd.org/permalinks/wlog2020_e20210411.htm</guid><category>personal</category><category>rant</category><category>security</category><description xml:space="preserve"><p>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ß.</p><p>Und heute lese ich, daß Bayern das wohl schon seit längerem habe <strong>und es genau NICHTS bringt</strong>, 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.&lt;/sarkasmus&gt;</p><p>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.</p><p><strong>Fickt euch, drecks Politiker=Verbrecher!</strong></p><p>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 <em>mehr</em>, nicht weniger, Bewegung angebracht. Ich mache nachts Spaziergänge, gerade <em>weil</em> da kaum noch Idioten draußen sind, und nun soll mir das genommen werden.</p></description></item><item><title>POSIX locale tracking coming soon</title><pubDate>Sun, 07 Feb 2021 00:00:00 +0000</pubDate><link>http://www.mirbsd.org/permalinks/wlog2020_e20210207.htm#e20210207_wlog2020</link><guid isPermaLink="true">http://www.mirbsd.org/permalinks/wlog2020_e20210207.htm</guid><category>mksh</category><category>plan</category><category>snapshot</category><description xml:space="preserve"><p>I’ve just committed a change to <tt>/etc/profile</tt> that sets <tt>LC_ALL=C.UTF-8</tt> as the default locale. We used to set <tt>LC_CTYPE=en_US.UTF-8</tt> which was a little friendlier when forwarded over ssh, but that 2009 proposal of mine is spreading and we standardise on it now. <tt>cleanenv</tt> now also sets it in “clean fully” modes (i.e. without dash or slash as first argument) and I expect more to follow.</p><p>In a next step libc will have a binary toggle between <tt>C</tt> and <tt>C.UTF-8</tt> (somewhat again), <a href="http://www.mirbsd.org/htman/i386/man1/locale.htm" class="manlink">locale(1)</a> and <a href="http://www.mirbsd.org/htman/i386/man3/setlocale.htm" class="manlink">setlocale(3)</a> corresponding. <a href="http://www.mirbsd.org/mksh.htm">mksh</a> will implement full locale tracking (for systems without setlocale, <tt>C</tt> 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 <tt>C.UTF-8</tt> but AFAIK that’s not been tested yet, and the locale upon entering <tt>main</tt> is mandated to be <tt>C</tt> anyway so we won’t really gain much except, perhaps, confusion).</p><p>I may add a double build where processes that would now be run under <tt>C</tt> locale warn (per syslog or so) to detect that since as of currently MirBSD has <em>only</em> the <tt>C.UTF-8</tt> locale. (This is a problem, but which has been proven to be one only recently.)</p><p><a href="http://www.mirbsd.org/htman/i386/man1/lksh.htm" class="manlink">lksh(1)</a> will still consider POSIX compliance only for the <tt>C</tt> 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 <tt>set ±U</tt> will of course still work.) In the same vain presence of the BOM may not affect the UTF-8 mode flag any longer either.</p><p>It’ll be a bumpy ride, especially for MirBSD itself, but we’ll sure manage. For <a href="http://www.mirbsd.org/htman/i386/man1/mksh.htm" class="manlink">mksh(1)</a>, it’ll be R60, which will be a real major release, carrying more deep changes. Removal of the <a href="http://www.mirbsd.org/htman/i386/man1/cat.htm" class="manlink">cat(1)</a> and <a href="http://www.mirbsd.org/htman/i386/man1/sleep.htm" class="manlink">sleep(1)</a> 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.</p><p><strong>Update</strong> 2021-04-08: <a href="http://www.mirbsd.org/htman/i386/man1/mksh.htm" class="manlink">mksh(1)</a> 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).</p><p><a href="http://www.mirbsd.org/permalinks/wlog2020_e20210207.htm">(read more…)</a></p></description></item><item><title>MirBSD “announce” RSS feed</title><pubDate>Sun, 10 Jan 2021 18:27:00 +0000</pubDate><link>http://www.mirbsd.org/permalinks/wlog2020_e20210110.htm#e20210110_wlog2020</link><guid isPermaLink="true">http://www.mirbsd.org/permalinks/wlog2020_e20210110.htm</guid><category>jupp</category><category>mksh</category><category>news</category><category>pcli</category><description xml:space="preserve"><p>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 <tt>mksh-announce@</tt> mailing list was stated.</p><p>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 <em>do</em> have RSS feeds; e.g. for <a href="http://www.mirbsd.org/~tg/Debs/NEWS.rss">my APT repo</a> 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.</p><p>Enter the MirBSD “announce” (<a href="https://validator.w3.org/feed/" >valid</a> 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.</p><p><tt><a href="http://www.mirbsd.org/announce.rss" type="application/rss+xml; charset=utf-8" hreflang="en">http://www.mirbsd.org/announce.rss</a></tt></p><p>In the hope of being able to help, I wish my downstreams a blessed time, with most calendaries just having entered a new year.</p></description></item><item><title>FS — field separator?</title><pubDate>Sat, 20 Jun 2020 20:56:00 +0000</pubDate><link>http://www.mirbsd.org/permalinks/wlog2020_e20200620.htm#e20200620_wlog2020</link><guid isPermaLink="true">http://www.mirbsd.org/permalinks/wlog2020_e20200620.htm</guid><category>bug</category><description xml:space="preserve"><p>I’ve been using “a Unicode (and ASCII) field separator” for my <a href="https://evolvis.org/plugins/scmgit/cgi-bin/gitweb.cgi?p=shellsnippets/shellsnippets.git;a=tree;f=mksh/ssv;hb=HEAD">SSV</a> flavour of CSV. I thought I should be using the <tt>FS</tt> control character (considering “FS”, according to much documentation, is a field separator).</p><p>Turns out most Unicode control characters have shitty <em>official</em> names and/or acronyms/abbreviations… such as…</p><ul><li>PLD: partial line forward (not: partial line down)</li><li>SPA: start of guarded area (not: start of protected area)</li><li>VTS: line tabulation set (not: vertical tabulation set)</li><li>DC1: device control one (not: XON)</li><li>RI: reverse line feed (not: reverse index)</li><li>NP: form feed (probably for “new page”)</li><li>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)…)</li><li>Adding insult to injury, U+0080, U+0081, U+0084 and U+0099 do not even <em>have</em> a name (but Unicode “name aliases” which include an acronym (which (of course) <a href="http://www.mirbsd.org/wtf.htm">WTF</a> knows about) and at least a longer name).</li></ul><p>… and so forth. There’s separators, too!</p><ul><li>FS: [U+001C] [␜] INFORMATION SEPARATOR FOUR [file separator]</li><li>GS: [U+001D] [␝] INFORMATION SEPARATOR THREE [group separator]</li><li>RS: [U+001E] [␞] INFORMATION SEPARATOR TWO [record separator]</li><li>US: [U+001F] [␟] INFORMATION SEPARATOR ONE [unit separator]</li></ul><p>And guess what… ASCII and Unicode <tt>FS</tt> is <em>file</em> separator (<tt>US</tt> is field separator). Oops. Sorry.</p><p>So… I guess when I use SSV next I’ll update (change in an incompatible way) the spec. Again, sorry about that.</p><p>It’s only in another 48 minutes but enjoy the Solstice! Blessed be!</p></description></item><item><title>Reduced SountFont for RAM-constrained devices</title><pubDate>Mon, 01 Jun 2020 00:57:00 +0000</pubDate><link>http://www.mirbsd.org/permalinks/wlog2020_e20200601.htm#e20200601_wlog2020</link><guid isPermaLink="true">http://www.mirbsd.org/permalinks/wlog2020_e20200601.htm</guid><category>music</category><description xml:space="preserve"><p>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:</p><ul><li>the piano from <tt>Fluid (R3) Mono 2.315</tt> (which is very slim, one twenty-fifth the size of a wonderful new piano in MS_General)</li><li>monoified (left channel, panned to centre) Choir Aahs (to save another 2½ MB) from <tt>MuseScore_General 0.2</tt> (expressive and regular, for SND support)</li><li>the harpsichord from <tt>MuseScore_General 0.2</tt></li></ul><p>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.</p><p><a href="http://www.mirbsd.org/~tg/soundfont/">Download</a> 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. <a href="https://musescore.org/en/node/306161">Discussion</a> 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.</p><p>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).</p></description></item><item><title>How to handle XHTML properly</title><pubDate>Thu, 30 Apr 2020 00:00:00 +0000</pubDate><link>http://www.mirbsd.org/permalinks/wlog2020_e20200430.htm#e20200430_wlog2020</link><guid isPermaLink="true">http://www.mirbsd.org/permalinks/wlog2020_e20200430.htm</guid><category>bug</category><category>rant</category><description xml:space="preserve"><p>OK, toned down on the rant, I already did enough in the commit messages…</p><p>My webpages are valid XHTML/1.1. But what does that mean?</p><p>I write them conforming to XHTML/1.1, with spaces before the “<tt>/&gt;</tt>” 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 <tt>application/xhtml+xml</tt> content type — two questions: why does the XHTML spec say anything about HTTP, and, why doesn’t another spec agree with it?</p><p>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 <tt>pre</tt> tag). Fucktards.</p><p>I’ll just serve my XHTML/1.1 files only as <tt>text/html</tt> 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 &lt;svg&gt; 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…)</p><p>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…).</p></description></item><item><title>Free Music, now with MP3 export</title><pubDate>Thu, 23 Apr 2020 00:00:00 +0000</pubDate><link>http://www.mirbsd.org/permalinks/wlog2020_e20200423.htm#e20200423_wlog2020</link><guid isPermaLink="true">http://www.mirbsd.org/permalinks/wlog2020_e20200423.htm</guid><category>fun</category><category>music</category><description xml:space="preserve"><p>I’ve concocted a workaround for the issue that MuseScore cannot <a href="https://musescore.org/en/node/270099#comment-995806">reproduce the soundfont copyright in exported files</a> yet, by placing it and (also necessary, not present in every export format) score metadata in the “associated documentation files”, which fulfills the licence. For now, <a href="http://www.mirbsd.org/music/free/">Free Music repository</a> directory listings show a hint requesting the user acknowledge them; I also plan a fancy thingy in ECMAscript to offer downloads and play the sheet music in the browser, if modern enough (lynx, of course, I will handle properly, you know me).</p><p>Enjoy!</p></description></item><item><title>mksh R59 released</title><pubDate>Wed, 15 Apr 2020 00:00:00 +0000</pubDate><link>http://www.mirbsd.org/permalinks/wlog2020_e20200415.htm#e20200415_wlog2020</link><guid isPermaLink="true">http://www.mirbsd.org/permalinks/wlog2020_e20200415.htm</guid><category>mksh</category><category>news</category><category>pcli</category><description xml:space="preserve"><p>With <a href="http://www.mirbsd.org/mksh.htm#r59">a mixed bag of changes</a>, I’ve released <a href="http://www.mirbsd.org/htman/i386/man1/mksh.htm" class="manlink">mksh(1)</a> R59 yesterday. Some of those changes are breaking to the shell language:</p><ul><li>When <a href="http://www.mirbsd.org/htman/i386/man1/printf.htm" class="manlink">printf(1)</a> was compiled as builtin, and a matching external utility (i.e. <tt>$(which printf)</tt>) didn’t exist, and <tt>builtin printf</tt> was not used to specifically invoke the built-in utility, it could not be found. This is critical but only for a very small area: mostly when mksh (or more specifically <tt>lksh</tt>), with <tt>printf</tt> as builtin, is used as <tt>/bin/sh</tt> and the <tt>udev</tt> SYSVinit script uses printf while insisting on setting PATH to just <tt>/bin</tt> while <a href="http://www.mirbsd.org/htman/i386/man1/printf.htm" class="manlink">printf(1)</a> sits in <tt>/usr/bin</tt>. If this affects you, you <em>want</em> this fix.</li><li>OS/2 only: the <a href="http://www.mirbsd.org/htman/i386/man1/test.htm" class="manlink">test(1)</a> builtin already sometimes automatically added the suffixes <tt>.ksh</tt>, <tt>.exe</tt>, <tt>.sh</tt>, <tt>.cmd</tt>, <tt>.com</tt>, <tt>.bat</tt> to a <span class="u">file</span> argument if one without these sufficēs was not found. This was extended to cover more cases to improve the user experience. (Thanks to KO Myung-Hun for this!)</li><li>The output from some builtins is now formatted differently. This mostly affects how alias names, and in some cases their definitions, are printed (by <tt>alias</tt>, <tt>command</tt>, <tt>whence</tt>, etc.) and the output from the <tt>bind</tt> builtin was also made safe for re-entry into the shell. These are desirable from a security PoV but change formats.</li><li>In the manpage, some documentation was wrong: the example command given for how tab completion escapes, and the right-hand side of string comparisons only globs in <tt>[[</tt>, not in <tt>[</tt> and <tt>test</tt>.</li><li>The shell <tt>argv[0]</tt> (after removing a leading dash to indicate a login shell and using the <a href="http://www.mirbsd.org/htman/i386/man1/basename.htm" class="manlink">basename(1)</a> of the rest) is now checked whether it begins with an ‘r’, and if yes, <tt>restricted</tt> mode is enabled.</li><li>In [[ x = $y ]] we now parse the right operand $y as full extglob.</li><li>Since we already have breaking changes, the former <tt>global</tt> builtin introduced in R40b and deprecated, in favour of <tt>typeset -g</tt> in R55, was removed.</li><li><tt>^[Q</tt> (Esc+<tt>Q</tt>) was added as new editing command, quoting (for use as shell parameter, i.e. with <tt>'…'</tt> or <tt>$'…'</tt> like <tt>typeset</tt> does) the area between the mark and the cursor.</li><li>The manual page, besides featuring properly spaced “em” dashes, was completely overhauled in documenting reserved words and built-in utilities and now also documents built-in aliases and even those aliases and functions <tt>dot.mkshrc</tt> offers, more or less verbosely, and indicating, with every entry, which is which, including specialness and keeping assignments, deferring (with flags, like <tt>cat</tt>, or always, i.e. <tt>rename</tt> and the optional <tt>printf</tt>), being a declaration utility (where ‘b’ in <tt>export a=b</tt> is not IFS-splitted) or declaration utility forwarder (like <tt>command export a=b</tt> also skips the field splitting) and requirements (such as job control, or the presence of <a href="http://www.mirbsd.org/htman/i386/man2/select.htm" class="manlink">select(2)</a> etc.)</li><li>The testsuite works again with OS/2 and pre-glibc_2.30-5 GNU/Hurd.</li></ul><p>Now some of these changes are desirable and indicate you ought to upgrade. If you can’t (due to the breaking changes), talk with me, and I may release an R58b with only some of the changes. But please do consider whether R59 might work just as well. TIA!</p></description></item><item><title>jupp 39, mksh R58 released</title><pubDate>Fri, 27 Mar 2020 00:00:00 +0000</pubDate><link>http://www.mirbsd.org/permalinks/wlog2020_e20200327.htm#e20200327_wlog2020</link><guid isPermaLink="true">http://www.mirbsd.org/permalinks/wlog2020_e20200327.htm</guid><category>mksh</category><category>news</category><category>pcli</category><description xml:space="preserve"><p>Continuing with the idea of “let’s get releases out”, hopefully with no regressions introduced, and all updated to the latest UCS, find infos for <a href="http://www.mirbsd.org/jupp.htm">jupp</a> &amp; <a href="http://www.mirbsd.org/mksh.htm">mksh</a> updated on their respective pages.</p><p>There are still some known unfixed issues, but time will see to them. It’s best to occasionally get the more stable codebasēs out, so users can test (and break ☺) them.</p></description></item><item><title>rs 20200313 released, more to follow</title><pubDate>Fri, 13 Mar 2020 00:00:00 +0000</pubDate><link>http://www.mirbsd.org/permalinks/wlog2020_e20200313.htm#e20200313_wlog2020</link><guid isPermaLink="true">http://www.mirbsd.org/permalinks/wlog2020_e20200313.htm</guid><category>news</category><category>pcli</category><description xml:space="preserve"><p><a href="http://www.mirbsd.org/htman/i386/man1/rs.htm" class="manlink">rs(1)</a> is a classical BSD tool I noticed was missing under Debian. So I made the MirBSD one portable, some long time ago, and, because grml’s mikap wanted it as well, uploaded it to Debian. Turns out this invites actual users to report bugs ☺</p><p>So <a href="http://www.mirbsd.org/MirOS/dist/mir/rs/">here</a> we are, rebased to include latest OpenBSD changes, bugfixed, made portable, and even with a convenience strtonum implementation:</p><ul><!-- mksh /usr/src/scripts/webhash /MirOS/dist/mir/rs #--> <li>SHA256 (rs-20200313.tar.gz) = 919215dc9fe85a27a30bf63d56406cfb503f9fc9820323c4bd3bfe75a6a3bc3f</li> <li>RMD160 (rs-20200313.tar.gz) = a8dfa5bb7ef63c66e011ec81bf20e089fdd827f5</li> <li>TIGER (rs-20200313.tar.gz) = 42135e4d75e7865b817f1b4027d383416d326c305e6553ce</li> <li>1362219422 12571 /MirOS/dist/mir/rs/rs-20200313.tar.gz</li> <li>MD5 (rs-20200313.tar.gz) = cc6a310b7f3bae98ea6296fbee0f85b4</li></ul><p>If you really need build instructions, look at the Debian package.</p><p>Development on other fronts is also continuing. See you in IRC only, I guess… (what with the current situations, the last newspost also had conference presence). Due to the sheer amount of changes, a release of mksh is somewhat imminent, if only to get my users to find regressions caused by me attempting bugfixing ☻</p></description></item><item><title>FixedMisc [MirOS] 20200214 released, for “I ❦ Free Software” day</title><pubDate>Fri, 14 Feb 2020 00:00:00 +0000</pubDate><link>http://www.mirbsd.org/permalinks/wlog2020_e20200214.htm#e20200214_wlog2020</link><guid isPermaLink="true">http://www.mirbsd.org/permalinks/wlog2020_e20200214.htm</guid><category>news</category><category>pcli</category><description xml:space="preserve"><p>Another release of one of MirBSD’s subprojects. Now, both the 8x16 VGA (cp437-encoded) and the full Basic Multilingual Plane 8x16/16x16 proper font are also available, on all possible platforms, as “doubled”, that is, 16x32 and 18x36/36x36, version suited for e.g. hiDPI displays. (This was mostly done with simple pixel doubling for each axis, with only few glyphs fixed up afterwards to achieve a slighly improved, but still FixedMisc bitmap font, look. Thanks to apotheon for the suggestion (even if it ended up being a tad <em>too</em> large in his eyes) and to cnuke@ for testing and to both plus Sarah for feedback.)</p><p>The <a href="https://www.mirbsd.org/~tg/Debs/debidx.htm">APT repository</a> was, of course, updated with <tt>xfonts-base</tt>/<tt>consolefonts-base</tt> and <tt>console-setup</tt> to match. It also, in <tt>mirabilos-support</tt>, ships an updated version of the Linux text/framebuffer console keymap.</p><p><a href="http://www.mirbsd.org/MirOS/dist/mir/Foundry/">Download</a> and check:</p><ul><!-- mksh /usr/src/scripts/webhash /MirOS/dist/mir/Foundry #--> <li>SHA256 (FixedMisc-20200214.tgz) = 92cd16d302741be9314014960f2c57866b7e31f720b47df8efebfec7c6c35319</li> <li>RMD160 (FixedMisc-20200214.tgz) = 9bbf24131664d201411294b633e265fc3d940fb1</li> <li>TIGER (FixedMisc-20200214.tgz) = 92099b2a989d7a66b22aacf93836345581f8ba27aab0cab5</li> <li>758244556 5955999 /MirOS/dist/mir/Foundry/FixedMisc-20200214.tgz</li> <li>MD5 (FixedMisc-20200214.tgz) = 546f492a4b0459cbf2689306560070a2</li></ul><p>Mind this is slightly larger (6/46 MB download/decompressed) than the previous releases (1¼/10½ MB) because it now ships the fonts not only in regular and doubled versions but also the HW-only versions expanded and the full font (normal and doubled) for GRUB and the cp437 font in PSF and PSFU format (version 1 for 8x16, version 2 for 16x32). Enjoy!</p><p>I also wanted to give you a new release of the another MirBSD subproject, <a href="http://www.mirbsd.org/jupp.htm">jupp</a>, but I haven’t managed to finish my work on it in time. After that will, most likely, lead me to more <a href="http://www.mirbsd.org/mksh.htm">mksh</a> bugfixing, followed by the long-expected next regular release (it’s already cooking in Debian unstable).</p><p>And then, I hope I’ll manage to get a bit of time to get back to the BSD base and manage a rollup rolling release snapshot for those updating from binary, not from source themselves. (Rumours about being discontinued are just that, rumours; they originate (hah!) from Wikipedia, whose page about MirBSD has, incidentally, never been fully right.)</p><p>See you in IRC or around on conferences!</p></description></item><item><title>FixedMisc [MirOS] 20200202 and MirKeyboardLayout 9x released!</title><pubDate>Sun, 02 Feb 2020 00:00:00 +0000</pubDate><link>http://www.mirbsd.org/permalinks/wlog2020_e20200202.htm#e20200202_wlog2020</link><guid isPermaLink="true">http://www.mirbsd.org/permalinks/wlog2020_e20200202.htm</guid><category>news</category><category>pcli</category><description xml:space="preserve"><p>I’ve managed to miss FOSDEM this year, unfortunately, because I’ve got a beginning sinusitis (this time <em>before</em> the conference) staying home cautiously. But fear not, I’m working on porting the MirKeyboardLayout™ to Windows® 95, and, during that, I noticed that I need another glyph in the documentation comments. Cue FixedMisc.</p><p>As <a href="http://www.mirbsd.org/permalinks/wlog2019_e20190911.htm">usual</a>, <a href="http://www.mirbsd.org/MirOS/dist/mir/Foundry/">download FixedMisc</a> and check the integrity before installing:</p><ul><!-- mksh /usr/src/scripts/webhash /MirOS/dist/mir/Foundry #--> <li>SHA256 (FixedMisc-20200202.tgz) = 91396414e169b37bc906746ae34188ad360be271865ac44271d9b7d9746c97f1</li> <li>RMD160 (FixedMisc-20200202.tgz) = 8f672de47df8bc67df52f5f48ac49105953d19e9</li> <li>TIGER (FixedMisc-20200202.tgz) = d875a4835c053e21914ead312a6ec9afc40b347ee1d04fa5</li> <li>3480714773 1275833 /MirOS/dist/mir/Foundry/FixedMisc-20200202.tgz</li> <li>MD5 (FixedMisc-20200202.tgz) = eb494f7f71b2c610346d58e3ac6c46ce</li></ul><p>I’ll update my APT repository later. The separate Powerline font has been merged considering we don’t even ship glyphs for “Cirth” in CSUR and it’s being considered for inclusion into the SMP anyway.</p><p><strong>Update:</strong> The APT repository is updated, and the <a href="http://www.mirbsd.org/MirOS/dist/mir/Keyboard/KBDmir2A_5.EXE">MirKeyboardLayout for Windows® 95/98/9x</a> (self-extracting LHarc archive) is also done, as far as I can make it anyway: the 102nd key (“&lt;&gt;|”) operates as “…€„™”, as in the NT/2k/XP/… layout, but it produces wrong results (at least on 950 B) if Shift and/or AltGr are pressed, and I couldn’t test AltGr-Tab and AltGr-Shift-Tab ‘“”’ because my window manager caught them before they could be passed into the VM… and since it uses cp1252, I used the florin ‘ƒ’ for AltGr-- instead of U+2010, randomly. The full <a href="http://www.mirbsd.org/cvs.cgi/contrib/code/Snippets/KBDmir2A.S">source</a> is also available. Test results, fixes and improvements welcome. Next: xkb</p><p><strong>Update:</strong> I’ll be doing a script for customisation of the xmodmap and Linux layout (unswap unshifted Esc and <tt>`</tt>, move Mode_switch to Alt_R/AltGr keeping Alt on Alt_L and Meta on Win_L, and a tristate one: CapsLock as <tt>…€„™</tt> and the <tt>&lt;&gt;|</tt> (102ⁿᵈ) key as Compose, vs. the 102ⁿᵈ key as <tt>…€„™</tt> and CapsLock being either Compose or Ctrl) soon. Stay tuned!</p></description></item><item><title>FixedMisc [MirOS] 20190911 released!</title><pubDate>Wed, 11 Sep 2019 00:00:00 +0000</pubDate><link>http://www.mirbsd.org/permalinks/wlog2019_e20190911.htm#e20190911_wlog2019</link><guid isPermaLink="true">http://www.mirbsd.org/permalinks/wlog2019_e20190911.htm</guid><category>news</category><category>pcli</category><description xml:space="preserve"><p>Today I’ve released another new CVS snapshot of the <a href="http://www.mirbsd.org/MirOS/dist/mir/Foundry/"><tt>FixedMisc [MirOS]</tt> font</a>; as usual, the tarball contains the font in BDF form, with no conflict with the system <tt>Fixed [Misc]</tt> font; <a href="http://www.mirbsd.org/cvs.cgi/contrib/fonts/fixed/">sources</a> for use (compilation, editing) with <a href="http://www.mirbsd.org/htman/i386/man1/bdfctool.htm" class="manlink">bdfctool(1)</a> are in CVS.</p><p>New: a Powerline variant of the halfwidth font, and massively more alternative UCS mapping for the cp437 font.</p><ul><!-- mksh /usr/src/scripts/webhash /MirOS/dist/mir/Foundry #--> <li>SHA256 (FixedMisc-20190911.tgz) = 1aa35a3128b3e5ca452467fca8150ad394054f60f847eca7296480bd23039dd7</li> <li>RMD160 (FixedMisc-20190911.tgz) = fc2a61166ea4c955d5c34e03f5da0c00df132a00</li> <li>TIGER (FixedMisc-20190911.tgz) = f3b087c819c8fdc2c319feca5d11f1ad25f89d7ce17e2907</li> <li>830148610 1378344 /MirOS/dist/mir/Foundry/FixedMisc-20190911.tgz</li> <li>MD5 (FixedMisc-20190911.tgz) = 87ef903a45e5a6e1c9dfa86b172b24d3</li></ul><p>My <a href="https://www.mirbsd.org/~tg/Debs/debidx.htm">“WTF” APT repository</a> contains the updated <tt>consolefonts-base</tt> and <tt>xfonts-base</tt> packages, as usual.</p></description></item><item><title>Accessing laptop hard discs elsehow</title><pubDate>Tue, 10 Sep 2019 00:00:00 +0000</pubDate><link>http://www.mirbsd.org/permalinks/wlog2019_e20190910.htm#e20190910_wlog2019</link><guid isPermaLink="true">http://www.mirbsd.org/permalinks/wlog2019_e20190910.htm</guid><category>debian</category><category>hardware</category><category>pcli</category><category>tip</category><description xml:space="preserve"><p class="boxhead">Today, I realised that, to use a laptop hard disc outside of a laptop, no matter whether via converters or in a regular (nōn-laptop PC), most likely…</p><div class="boxtext"> <pre><span style="display:none;"> </span>hdparm --security-unlock <i>password</i> /dev/hda</pre></div><p class="boxfoot">… is needed. (No, I don’t currently know how to do this in MirBSD.)</p><p class="boxhead"><strong>Update:</strong></p><div class="boxtext"> <pre><span style="display:none;"> </span> SG_IO: bad/missing sense data, sb[]: 70 00<span style="display:none;"> </span>05 00 00 00 00 0a 04 51 40 01 21 04 00 00 00<span style="display:none;"> </span>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00</pre></div><p class="boxfoot">… maybe not ☹<br />Send help.</p></description></item><item><title>The fate of MirOS Linux, and a birthday post</title><pubDate>Sun, 01 Sep 2019 00:00:00 +0000</pubDate><link>http://www.mirbsd.org/permalinks/wlog2019_e20190901.htm#e20190901_wlog2019</link><guid isPermaLink="true">http://www.mirbsd.org/permalinks/wlog2019_e20190901.htm</guid><category>archaeology</category><category>fun</category><category>plan</category><description xml:space="preserve"><p>MirBSD has just <a href="https://twitter.com/Knoblauchkeks/status/1167119275800350720">recently become 17 years old</a>, and I wrote (in German, sorry ☺) a <a href="https://chat.teckids.org/?blog/tglaser%40mercurius.teckids.org/mirbsd-ist-heute-17-jahre-alt-geworden-62Hv9C">reminiscing piece about that and thanking everyone involved</a>.</p><p>Today my <a href="http://www.mirbsd.org/htman/i386/man1/calendar.htm" class="manlink">calendar(1)</a> reminded me of the first steps towards “MirLinux”, a.k.a. “MirOS Linux”, 16 years ago and given this pops up regularily, especially due to Wikipedia spreading it, I feel I have to clarify: cnuke (the original Jupp) really likes the BSD userspace but wants to play Quake Ⅲ with accelerated 3D, so the idea was to maybe build everything for Linux, add a glibc and other dependent libraries (and we’d use different paths, so linking is unaffected and we’d have nicer linking semantics than those GNU people), and maybe things would just work.</p><p>It was a woozy idea right from the start, and there might have been beer involved, and nobody ever got around to actually doing so, and it clearly was never a/the project goal. Yes, we probably could have done it, back then, up to 90% satisfaction, and with some more binaries thrown in from GNU/Linux (e.g. for the packet filter, as — sadly… ― <a href="http://www.mirbsd.org/htman/i386/man4/pf.htm" class="manlink">pf(4)</a> for Linux has never materialised) it could have become usable, and there was ecce!GNU/Linux precedent, but BSD’s the focus. Perhaps if a certain few people had been less <i xml:lang="de">Verpeiler</i>… oh well — no big loss.</p><p>I <em>did</em> turn out fixing stuff in GNU/Linux and porting stuff over in the end, but we never merged them, which perhaps turned out, looking back, to be a good thing.</p><p><strong>Tomorrow</strong> 16 years ago, <a href="http://www.mirbsd.org/htman/i386/man4/plip.htm" class="manlink">plip(4)</a> support was added… I need to dig out the cable and run some interoperability tests some time to see if it’s still working, with both Crynwr and Linux on the remote end, and FreeBSD (if they still have it).</p><p><a href="http://www.mirbsd.org/permalinks/wlog2019_e20190901.htm">(read more…)</a></p></description></item><item><title>So… edugit? gitlab? ruby? maintainer scripts? RoDD/QA?</title><pubDate>Wed, 28 Aug 2019 00:00:00 +0000</pubDate><link>http://www.mirbsd.org/permalinks/wlog2019_e20190828.htm#e20190828_wlog2019</link><guid isPermaLink="true">http://www.mirbsd.org/permalinks/wlog2019_e20190828.htm</guid><category>bug</category><category>debian</category><category>personal</category><category>rant</category><category>work</category><description xml:space="preserve"><p>So… the Debian package of gitlab is too buggy to be used (was built against ruby-asciidoc version X.Y while sid carries X.(Y+1) now, which causes it to bug around, of course, as proper for an immature language like that. So, someone decided to switch to the GitLab CE *.deb format packages (not Debian packages — not Free; just Open Core but Debian itself uses those for its “Salsa” instance as well (<a href="https://mako.cc/writing/hill-free_tools.html">which</a> is, incidentally, why I refuse use of that whenever possible) and, for that, removed the Debian packages. The gitlab binary package helpfully offered to not delete the repositories, but gitlab-common’s postrm not only removed the user account (a <em>big</em> no-no!) but used the option to delete its home directory… which is where the git repositories and project icons and the likes are stored under. (Note that undeleting from ext3/4 is hard, unlike ext2, and if fsck and/or a journal replay is run, chances get worse… the ext4undelete tool “helpfully” requires an fsck run… ’nuff said… if you ever accidentally delete something, immediately unplug power and destroy VMs hard, then <em>snapshot the filesystem</em> so multiple rescue approaches aren’t made impossible.)</p><p class="boxhead">Anyway, it’s apparently running GitLab CE now, which means that all the remotes have changed. I used this…</p><div class="boxtext"> <pre><span style="display:none;"> </span>sudo find / -xdev -name config | grep '/\.git/config$' &gt;~/xgc<span style="display:none;"> </span>sudo fgrep -li gitlab@edugit.org $(&lt;~/xgc) &gt;~/xgc2<span style="display:none;"> </span>&lt;~/xgc2 sudo xargs perl -pi -e 's/gitlab\@edugit.org/git\@edugit.org/gi'</pre></div><p class="boxfoot">… for fixing up mine (inspect the temporary files and check <a href="http://www.mirbsd.org/htman/i386/man1/find.htm" class="manlink">find(1)</a> and <a href="http://www.mirbsd.org/htman/i386/man8/mount.htm" class="manlink">mount(8)</a> for <tt>-xdev</tt> to get the right files found).</p><p>Also, <tt>~/.gitconfig</tt> <tt>insteadOf</tt> / <tt>pushInsteadOf</tt> need fixing. Let me plug an undercover avertisement for my <a href="http://www.mirbsd.org/cvs.cgi/contrib/hosted/tg/.gitconfig?rev=HEAD">.gitconfig</a> here, which contains examples for <tt>insteadOf</tt> as well as commands to download GitLab merge and GitHub pull requests.</p><p class="boxhead">After having fixed those up, go to the web UI and click on “Create empty repository”, then push all remote branches recorded in your hopefully up-to-date clone and (all) tags to the instance:</p><div class="boxtext"> <pre><span style="display:none;"> </span>remote=<span class="u">origin</span><span style="display:none;"> </span>git branch -r | sed -n "/^ $remote\\//s///p" | \<span style="display:none;"> </span> while read branchname rest; do<span style="display:none;"> </span> test x"$branchname" = x"HEAD" &amp;&amp; continue<span style="display:none;"> </span> echo "pushing $remote/$branchname"<span style="display:none;"> </span> git push "$remote" "$remote/$branchname:refs/heads/$branchname"<span style="display:none;"> </span>done<span style="display:none;"> </span>git push "$remote" --tags</pre></div><p class="boxfoot">Adjust the <tt>remote</tt> variable if necessary. Run this in all clones you have access to; not using force pushes makes only those pushes which actually add commits succeed. All repositories hosted on the edugit instance are affected and need(ed) restoring, which, thankfully, appears to make everything else, like stored merge requests, work again (although the project and group logos are gone, which need re-uploading). That being said, unapplied merge requests are stored in special refs which are not normally cloned… so they’re gone now.</p></description></item><item><title>MirCPIO (paxmirabilis) 20190825 released</title><pubDate>Sun, 25 Aug 2019 00:00:00 +0000</pubDate><link>http://www.mirbsd.org/permalinks/wlog2019_e20190825.htm#e20190825_wlog2019</link><guid isPermaLink="true">http://www.mirbsd.org/permalinks/wlog2019_e20190825.htm</guid><category>bug</category><category>geocache</category><category>rant</category><category>archaeology</category><description xml:space="preserve"><p>There’s a new <a href="http://www.mirbsd.org/pax.htm">MirCPIO (paxmirabilis; tar, ar)</a> release. Difference is, some operating systems don’t yet support passing <i>nil</i> as second argument to <a href="http://www.mirbsd.org/htman/i386/man3/realpath.htm" class="manlink">realpath(3)</a> which incidentally included (note: past tense) a certain BSD whose installer segfaulted in <a href="http://www.mirbsd.org/htman/i386/man1/tar.htm" class="manlink">tar(1)</a>…</p><p>Debian GNU/Hurd was, btw, not affected.</p><p>In other news, it’s way too hot and other IRL things take up tuits.</p><p>And in completely (I’m sure) unrelated news, my waypoint statistics are not getting updated for now, and <a href="http://www.mirbsd.org/wtf.htm">acronym</a> submissions pile up in the queue. (The broken iOS Äpp link has been forwarded to the author. Techniker ist informiert. YMMV)</p></description></item><item><title>Updating IBM X40 with CompactFlash card</title><pubDate>Sun, 18 Aug 2019 00:00:00 +0000</pubDate><link>http://www.mirbsd.org/permalinks/wlog2019_e20190818.htm#e20190818_wlog2019</link><guid isPermaLink="true">http://www.mirbsd.org/permalinks/wlog2019_e20190818.htm</guid><category>hardware</category><category>personal</category><description xml:space="preserve"><p>So, I’ll be updating my IBM Thinkpad X40 from an almost broken 40 GB 1.6″ IDE HDD (with 2.5″ connector) to a dual (IDE master/slave) CF card adapter with… two (but I cannot find one of them right now) cards with a whopping 64 GiB, each ☺</p><p>I’ll take the added space to install it as a dual boot system so I can play some games… Diablo, Hellfire, StarCraft, BroodWar, Diablo Ⅱ, LoD… again (and perhaps create more binaries of MirSoftware for those sad OS users). It’ll be frustrating.</p><p>I’m also taking the chance to reinstall MirBSD on the laptop “fresh” and build binary packages for MirPorts and publish it as a half-snapshot (sparc needs more tuits) which is likely going to take time, during which I’ll be on other laptops, limited in agility.</p></description></item></channel></rss> If you would like to create a banner that links to this page (i.e. this validation result), do the following:
Download the "valid RSS" banner.
Upload the image to your own server. (This step is important. Please do not link directly to the image on this server.)
Add this HTML to your page (change the image src attribute if necessary):
If you would like to create a text link instead, here is the URL you can use:
http://www.feedvalidator.org/check.cgi?url=https%3A//www.mirbsd.org/wlog-10.rss
