As previously announced, the FreeWRT Project has been archived. You can access the content at the FreeWRT Archive Site on the MirWebseite.

ObRant: DST (Sommerzeit) sucks!

Just saw this in my INBOX:

    B. The default init system for jessie will be a single /etc/rc script

I’d certainly vote that❣

In unrelated news, jupp 2.8 for DOS runs on cable3, which means it’ll still run on an original 8088/8086 ☻

Update 10.02.2014: The unobfuscated version of cable3 is called 8086tiny under the MIT licence. Thanks to the author for doing that (and not just dumping the IOCCC code) and to RT from the mksh(1) IRC channel for finding it on the ’net!

As a workaround to the build problem of mksh R49 with some host shells, you can try removing every sequence of backslash + newline in rlimits.opt and sh_flags.opt, for example with the following sequence:

	cd /path/to/mksh
	for f in *.opt; do
		tr '\n' '`' <"$f" | \
		    sed 's/\\`//g' | \
		    tr '`' '\n' >"$f.out"
		mv "$f.out" "$f"
	done

This will apply to every upcoming mksh(1) release until such time as this code has been rewritten in (host) C. Another thing that could be done is to add -r to both IFS= read line occurences in Build.sh, function do_genopt.

Meh. I announced a tree breaker. Would be nice if I actually found enough spare time to hack on it before, I think, end of March (which is roughly when I’m planning to decommission both eurynome and, for monetary reasons (not going to do an OpenBSD here and cry about needing funds, as those who know me know this is a constant), the manitu server).

Took me 62 minutes to write a functioning OSIAM installer in mksh(1) after getting annoyed that the Puppet-lovers are either ill, not able to work on the project I have to finish by Friday, or not yet skilled enough to help. Got the entire thing working (but this week sees way too many overlong days at the workplace), estimate finishing with full success by tomorrow afternoon, with zero puppet but lots of mksh. Maintainable, too.

I’ve produced several pin-on buttons to take with me to FOSDEM for giving away (as long as there are any left):

First row (nice projects), from left to right: MidnightBSD; Glenda, the Plan 9 bunny; Teckids e.V.

Second row (The MirOS Project): mksh; the Shilouette Dæmon; the “Triforce” (Live+Install CDs for i386 and sparc, with MirGrml); “the m” (alternative logo, vector)

Third row (things originating from tarent): Freedroidz (now a Teckids project); OSIAM (Identity and Access Management); tarent (tarent AG, tarent GmbH), who sponsored production of these buttons

Hm… jupp needs a button’able logo!

FOSDEM meetup

Thanks to Robert Scheck, jupp — the Editor which sucks less (a WordStar™-compatible Unix editor with lots of features, including a hex editor) is currently on its way to Fedora and EPEL (RHEL/CentOS 5 and 6).

Depending on your distribution, you will have it available within one to two weeks, I’m being told.

This adds another distribution to the list; jupp has been available in Debian and its derivates (some of which may not be named) for some time (due to user request), and the webpage contains Win32 binaries (made with Cygwin, an oldish version to be compatible to Win9x).

jupp is especially useful as programmers’ editor, but also used in teaching school-aged kids the joys of IT; Natureshadow has prepared a cheat sheet, which we will internationalise and localise, then link from the jupp homepage — so stay tuned! (I guess we’ll also need a concise list of jupp features, in lieu of advertising.)

There has been an ongoing discussion in the NetBSD community about migrating away from CVS (something that is not in question here, I know I know)—to the point that the tech-repository mailing list has been set up specifically for this discussion.

Eric S. Raymond recently posted an article titled "bzr is dying; Emacs needs to move" on emacs-devel. Thomas Klausner remarked that if you apply sed -e "s/emacs/NetBSD/g" -e "s/bzr/CVS/g" to the post, then the same applies, frighteningly accurate in fact:

In practice, I judge that sticking with CVS would have social and signaling effects damaging to NetBSD's prospects. Sticking to a moribund version-control system will compound and exacerbate the project's difficulty in attracting new talent.

The uncomfortable truth is that many younger hackers already think CVS is a dinosaur – difficult, bulky, armor-plated, and generally stuck in the last century. If we're going to fight off that image, we cannot afford to make or adhere to choices that further cast the project as crusty, insular, and backward-looking.

This is what I wrote in reply:

Scary how spot-on this is after the above substitution. I fully agree.

I know that this may spawn another centithread but: how about we use a "canary" for a VCS migration? For example, moving pkgsrc-wip to git would probably be trivial, considering that it's sourceforge that hosts it. Last time I checked, sourceforge supports hosted git repositories.

As a new data point, I did some hacking on pkgsrc on MirBSD during 30c3 using a clone of github.com/jsonn/pkgsrc. This was in part to work around the freeze, in part to see how git copes with the typical pkgsrc workflows. I was positively surprised, I must say. Some observations:

• you want distfiles/ and packages/ in gitignore.
• not ignoring work directories is actually a convenient way to find stale work directories quickly.
• downgrading a single package (in my case, to get autoconf-2.61 for some configure script) is easy to do, using git checkout $revision devel/autoconf This set the working copy back to the given revision and put the changes to HEAD into the index.
• branch/rebase/merge is a good workflow for upgrading single packages.

Thus, even if the NetBSD project is not prepared to move to git outright, we could do a move for pkgsrc-git, then pkgsrc. src could come later.

I’ve did something I surely will (financially) regret, next year, and designated the Neo900 to be the successor to my PocketPC, due to the latter having only 64 MiB RAM and Geocaching applications being quite hungry. It’s got a lovely hardware keyboard, a “pen” display like the PocketPC (as opposed to the “wishy-washy” displays that Android and iPhone have), not only GPS but also GLONASS, fully free software with mostly free firmware (I’m okay with that, mostly), a Ctrl key (useful in ssh and locally and my text editor; ^I is Tab, so it’s useful in shell, too), WLAN, UMTS (I don’t think I need LTE and would rather it have the more RAM), USB host (OTG), and lots of other nice features.

In short, it’s a tinkerable device: one I can not only hack at, but also hack on.

Since I use a “dumbphone” for mobile phone anyway (pro: separate battery from the “toy” PocketPC/Smartphone — we’re talking two+ weeks of battery time when using it here, and easier use and less bugs, and a reliable fallback when I tinker “too much”), this is perfect for me.

I’m reposting this in the wlog mostly because it’s an interesting technical and OSS project, and because if 1000 people want one it will get less expensive for all of us (while here… shameless plug… any sponsors willing to contribute some EUR so I don’t ruin myself with this, in exchange for services of some kind?). I’ll probably run Debian on it (unless it goes systemd), maybe in a chroot — if the native OS has functionality needed that I can’t simply put into packages; they say Maemo has much better power management, but considering most use will have GPS, GLONASS and backlight on, battery isn’t going to last long anyway… — or maybe even native… I’ve been wanting to know what this “freesmartphone” stuff my m68k (Atari VM) buildd has been happily compiling, anyway… and some sort of Geocaching application (ideally a cross between something online, CacheWolf and an offline OSM (with most of Europe, but uninteresting tags stripped) and possibly access to the GS Live API but nevertheless supporting TC, NC, OC, gpsgames too), and my usual mksh(1), GNU screen, jupp(1), lynx(1), ssh(1) toolchain.)

Delivery is expected for mid to end of 2014, but once it’s there I’ll keep you informed ☺

On that matter… I’ve got my PocketPC (currently in production use) and another WinCE device and wonder about tinkering with them, too. It appears to be a rather open platform (compared to Android, anyway) but most official documentation is tied to Windows® host systems, and most utilities have been taken offline after the abomination called Windows Phone has taken over. Hm I’ve got PocketPython and some sort of cross GCC but nothing to tinker with the core OS / ROM image…

Bochs is not the only emulator. But Fabrice Bellard wrote more than just qemu, either — tonight I did a quick hack and started booting MirBSD in jslinux. Unmodified. Of course, there are still things to change before this goes into userspace, and the bootloader wants to be ported to ECMAscript as well, but… I got some dmesg(8)!

Feel free to call me crazy now. Anyway, more on this as time and legalese permits. This was a can-do test in about 2 hours of work, only.

FrOSCon is approaching, and all MirBSD developers will attend… but why’s there no MirBSD exhibit? The answer to that is a bit complex. First let’s state that of course we will participate in the event as well as the Open Source world. We’ll also be geocaching around the campus with other interested (mostly OSS) people (including those we won for this sport) and helping out other OSS projects we’ve become attached to.

MirOS BSD, the operating system, is a niche system. The conference on the other hand got “younger” and more mainstream. This means that almost all conference visitors do not belong to the target group of MirOS BSD which somewhat is an “ancient solution”: the most classical BSD around (NetBSD® loses because they have rc.d and PAM and lack sendmail(8), sorry guys, your attempt at being not reformable doesn’t count) and running on restricted hardware (such as my 486SLC with 12 MiB RAM) and exots (SPARCstation). It’s viable even as developer workstation (if your hardware is supported… otherwise just virtualise it) but its strength lies with SPARC support and “embedded x86”. And being run as virtual machine: we’re reportedly more stable and more performant than OpenBSD. MirBSD is not cut off from modern development and occasionally takes a questionable but justified choice (such as using 16-bit Unicode internally) or a weird-looking but beneficial one (such as OPTU encoding saving us locale(1) hassles) or even acts as technological pioneer (64-bit time_t on ILP32 platforms) or, at least, is faster than OpenBSD (newer GNU toolchain, things like that), but usually more conservatively, and yes, this is by design, not by lack of manpower, most of the time.

The MirPorts Framework, while technically superiour in enough places, is something that just cannot happen without manpower. I (tg@) am still using it exclusively, continuing to update ports I use and occasionally creating new ones (mupdf is in the works!), but it’s not something I’d recommend someone (other than an Mac OSX user) to use on a nōn-MirBSD system (Interix is not exactly thriving either, and the Interix support was only begun; other OSes are not widely tested).

The MirBSD Korn Shell is probably the one thing I will be remembered for. But I have absolutely no idea how one would present it on a booth at such an exhibition. A talk is much more likely. So no on that front too.

jupp, the editor which sucks less, is probably something that does deserve mainstream interest (especially considering Natureshadow is using it while teaching computing to kids) but probably more in a workshop setting. And booth space is precious enough in the FH so I think that’d be unfair.

All the other subprojects and side projects Benny and I have, such as mirₘᵢₙcⒺ, josef stalin, FreeWRT, Lunix Ewe, Shellsnippets, the fonts, etc. are interesting but share few, if any, common ground. Again, this does not match the vast majority of visitors. While we probably should push a number of these more, but a booth isn’t “it” here, either.

MirOS Linux (“MirLinux”) and MirOS Windows are, despite otherwise-saying rumours called W*k*p*d*a, only premature ideas that will not really be worked on (though MirLinux concepts are found in mirₘᵢₙcⒺ and stalin).

As you can see, despite all developers having full-time dayjobs, The MirOS Project is far from being obsolete. We hope that our website visitors understand our reasons to not have an exhibition booth of our own (even if the SPARCstation makes for a way cool one, it’s too heavy to lift all the time), and would like to point out that there are several other booths (commercial ones, as well as OSS ones such as AllBSD, Debian and (talking to) others) and other itineries we participate in. This year both Benny and I have been roped into helping out the conference itself, too (not exactly unvoluntarily though).

The best way to talk to us is IRC during regular European “geek” hours (i.e. until way too late into the night — which Americans should benefit from), semi-synchronously, or mailing lists. We sort of expect you to not be afraid to RTFM and look up acronyms you don’t understand; The MirOS Project is not unfriendly but definitely not suited for your proverbial Aunt Tilly, newbies, “desktop” users, and people who aren’t at least somewhat capable of using written English (this is by design).

TANSTA “softlink”. ITYM: symlink(7)

Actually, there’s “link” (also “hardlink”) and “symbolic link” (short “symlink”). (Oh, and reparse points, but let’s not get there, lest we mention *.lnk files…)

Inspired by a posting on the klibc mailing list.

Following the Wiki I put “discard” entries into my fstab(5) for swap (but not / as it’s suggested to use fstrim instead, and I had noatime for /boot and relatime for / already) and changed the scheduler. What wasn’t written there was to set vm.swappiness=0 in sysctl.d/local.conf *shrug* but it helps.

What they also didn't mention:

mount -t tmpfs swap /var/cache/apt/archives

And in sid, which my dayjob-laptop is running, APT _finally_ creates the missing “partial/” subdirectory itself. Thanks!

I had the filesystems already created, so I changed the ext options with tune2fs:

tune2fs -E stride=1024,stripe_width=1024 /dev/sda2 # 1 KiB blocks: /boot
tune2fs -E stride=256,stripe_width=256 /dev/sda4   # 4 KiB blocks: /

I wonder how well that works. I also did _not_ manage to find out my device’s flash block size (search engine fodder: erase block size), so I assumed 1 MiB (also used for partition alignment already) as worst-case scenario. Input welcome on how to find *that* out.