Christian Hofstaedtler «ch:#grml» pointed me to an article about netboot.me, a service providing bootable Live and Install variants of some OSes over the Internet (via gPXE and HTTP transport, mostly). They offer a bootable floppy/disc, USB stick, and El Torito ISO image. One gets a graphical menu if not careful, out of which there is no escape, and which isn’t compatible with most graphics cards, but if ^B is pressed quickly enough, there will be a usable command line.

An experimental MirOS bsd4me bootable image is available as well:

gPXE> autoboot
gPXE> chain http://netboot.me/2032

This will be loaded via plain, unencrypted HTTP from our main webserver. It’s the usual <5 MiB Mini-ISO for the i386 architecture and contains a full installer, as well as e3 and tinyirc known from MirOS bsd4grml. Source code of the GPL’d parts and overall licencing information is also included inside the ISO image. Please remember this is for beta testing only. We do not support MEMDISK boot methods with our second stage boot(8/i386) loader, as these are not reliable.

On an unrelated side note: dutch Windows XP Professional is weird. Translations were laughed at by several dutch-speaking people in the mksh IRC channel, but I was able to disable Blåtand on “blau” (the new IBM X40, successor of “bleu”). And it works!

A more related side note: when virtualising MirBSD, do not use VirtualBox. If you do have Vanderpool/Pacifica available and enabled, both the OSE and the full edition may be viable, but kvm is the better option. If VT-x/HVM is not used, it does not emulate the i386 architecture properly. Use qemu, kqemu, kvm, bochs, VMware Server 2 (not 1 — timekeeping is broken in there), Microsoft® VirtualPC 2004, Parallels Desktop, VMware Fusion for Macintosh, … instead.

Tonight and the last few days have seen several releases of things like MirMake, the package tools, etc. You might want to upgrade your MirPorts Framework checkout. (We now have enough Lua tools to access the Simtec eKey, I just need to order one. We’re currently at 2¾ interested people, not quite enough to make sense.)

It’s hot! The weather forecast said 35°C, one of the apothecaries’ thermometres says 40°C, and my body says I’m ill. I also nurse quite some headaches again. So I won’t do/write much. It was hard enough to go outside to buy breakfast.

On the other hand, the SS5 built a mock-snapshot (QUICK_DIST2, so only base+gcc, no X11/ports/htman/…) just fine (with some fixes). Does anybody have any RAM suitable for a SPARCstation 5 for me? I cannot use that from the SS20s because they use different kinds of RAM. I won’t publish this, but instead use it to build another one for real, possibly combined with another i386 snapshot, with all the /etc/* changes after 20090812, and maybe fixing what we will have learned to be broken in the meantime. And Benny’s ports fixes (he got GNOME except nautilus — which has unsafe code in signal handlers — working, part of (or all?) Xfce too, etc).

Luckily, tomorrow is more like 22°C

Karolina Lesińska writes: “We have placed the first 3 issue of BSDmagazine on our website as free downloads. The issues are:

1. FreeBSD Ins & Outs
2. OpenBSD in the Limelight
3. Explore NetBSD

“The link is: http://bsdmag.org/prt/view/pdf-articles.html”

My comment: The BSD magazine is a rather interesting piece of print, which already carried a small article about MirBSD. We have, I admit, been offered to write more which would get published, but, I am ashamed, haven’t quite gotten around to doing so.

Today, it's only been 29°C, and I died. What will I do tomorrow, where it is supposed to climb up to 35°C over today's 32°C?

The subject line says it all…

tg@ss5:~ $ uname -a
MirBSD ss5.mirbsd.org 10 Kv#10uAA-20090810 GENERIC#146 sparc
tg@ss5:~ $ dmesg
MirBSD#10uAA (GENERIC) #146: Mon Aug 10 17:57:16 UTC 2009
        tg@demo.mirbsd.org:/usr/src/distrib/generic/obj/build/GENERIC
real mem = 33165312
avail mem = 24928256
[…]
sd0 at scsibus0 targ 3 lun 0: <IBM, DORS32160SUN2.1G, WA7A> SCSI2 0/direct fixed
sd0: 2063MB, 6703 cyl, 5 head, 126 sec, 512 bytes/sec, 4226725 sec total
[…]
cgsix0 at sbus0 slot 3 offset 0x0: SUNW,501-2325, 1152x900, rev 11
wsdisplay0 at cgsix0: console (std, vt100 emulation), using wskbd0
[…]
tg@ss5:~ $ sysctl hw machdep
hw.machine=sparc
hw.model=SUNW,SPARCstation-5, MB86907 @ 170 MHz, on-chip FPU
[…]
machdep.cputype=2
machdep.v8mul=1
[…]
tg@ss5:~ $ top
[…]
Memory: Real: 17M/26M act/tot  Free: 1444K  Swap: 2640K/133M used/tot
[…]

It may only be a SPARCstation 5, with a rather fast CPU though (the SS20en only have 125 MHz and 150 MHz ROSS CPUs), with a small, slow and lout hard disc and very few RAM, but hey, it installs, the cgsix(4/sparc) scrolls quickly (as the tvtwo(4/sparc) currently is unaccelerated), and builds packages like a charm. Yay! I even have mc (Midnight Commander) now…

You all know that the sparc (demo) freezed on me. Well, the VT420 only emitted “Keyboard Error 4”, I tried the other sparc (ss20/marc). Also equipped with one of these 36G LVD/SE U160 SCA HDDs, it exploded. Literally. Something — I still don’t know what (smells in the area of the tvtwo(4/sparc) and le(4/sparc) but…) as this happened during the installation, which continued as if nothing had happened, except that, a minute after the explosive sound, it begun to smell. *sigh*

Me then go back to demo, even put in the tvtwo(4/sparc) for monitor/keyboard console (sucky German keyboard, but after installing kbd(8) works), use the Stop-N trick (hold it down and power on) to erase the PROM (thanks NetBSD® FAQ, no thanks to the people in #sparc in IRC who suggested Stop-A) to switch from serial to k/m console, then it installed… and froze.

To add insult to injury (luckily not mine), the VT420 works again.

I tried hard to get you at least a minimal set of binary packages — gmake (so it’s self-hosted), lzma (for *.clz binary package support), screen (because people need it), jupp (vi(1) is in base, but no editor other than ed(1)…), rsync (even though it’s now GPLv3, we depend on it heavily) — but just could not, no matter how hard.

On the other front, after re-doing the installer a few times due to some fuckup in install.sub (don’t ask, but I really extracted the image from the symbol-less kernel and put it back afterwards…), a number of core packages for i386 were built, and bsiegert@ is supplying another few hundred. Yay!

I’ll still follow the plan to create the FrOSCon ISO tomorrow, will add a minimal set of i386 packages plus their distfiles where licences require it, and refer people to the online repository. I cannot add any “real” sparc packages, so there will be none. I’m tempted to modify the sparc installer by image extraction too, since the mount_mfs(8) fails when the box has too much RAM (more than about 300 MiB), but don’t want to power on one of these boxen and lose even more time (if not body or possession).

qemu is getting better at emulating a sparc, but we still cannot go to user space. ☹

If someone is really interested in getting MirOS working on boxen compatible to the SheevaPlug (ARM 1.2 GHz), despite our rather old gcc and binutils, please contact us. I’d drop sparc support over it once working.

See you all kissing the blue frog, but remember, don’t kiss a porc. You can read the advertisement or the flyers (German, English or French) meanwhile.

I’m ill. I’ve not kissed a porc though, so I think it’s some kind of the common cold. Today, the headaches are killing me; I guess that when I finished the snapshot for the first time on 2009/08/11 night, my body decided it could relax now and let things out. Damn. Anyway, I’ll be finishing the FrOSCon DuaLive™/Triforce ISO this weekend, and there will be no binary packages on it thusly. Better that than untested or uninstallable ones. Users will, however, be able to get a variety of them from our download area (large variety for i386 built by bsiegert@ and small variety I’ll be baking for sparc). There also won’t be a new MirGRML (but the grml-FrOSCon edition ISO will contain a new MirOS bsd4grml, since that was made at approximately zero cost, since it “fell out” of the snapshot building anyway — and had me discover the manpage bug) this time, due to lack of that.

I’m hoping the headaches and other symptoms will leave me ASAP, so that I can go back to work tomorrow — as today is the second day, I’d need to see a doctor otherwise, which sucks even more (as it involves quite some money and a 1½hr-per-direction bus+tram+train ride), and it’s not that bad. I just cannot concentrate. — Retrospectively, I think I’ve been ill last week already, considering how badly I could concentrate back then (might also had to do with the huge number of small things we has to take care of) and the bodily condition… (The weather also has been killing me, fluctuating between 12°C and 24°C at night, 18°C and 30°C at day, cold/dry, cold/raining, hot/dry and hot/humid (extremely), with a few warm/humid/raining in between.)

Ah, if someone didn’t get it: the netinstall area now contains the i386=20090812 sparc=20090811* (tweaked) snapshot, which is what will be on CD, on /MirOS/current/ and everyone is invited to test that — especially on sparc, the floppies (all five of them), and maybe the separate five arch-specific ISOs too not just the larger combined one. And there will be buttons again. (Sorry if I made nōn sequitur — I do have a rather heavy headache right now, but just could not go back to sleep two hours ago.)

PS: go here

Yeah, a new snapshot. I wanted to update MirOS bsd4grml in the grml-live repository too. Like a good developer, I read my “git diff” before “git commit -a”ing. What do I see, the ‘-’ in the manpage is missing. Search. Search more. Curse. I mean, fuck. The whole 20090811 “David” snapshot has broken manpages because of a faulty merge-from-OpenBSD, who decided, in their infinite wisdom, to use “\(en”, a GNU groff extension. While Kristaps Džonsons (ha, jmc, I can spell that right!) is correct in that an en dash should be used at that position (separating name from short description), nroff(1) only has “\(em” in that place. Luckily, we already define “\*(en” in our compatibility stuff (and mircvs://contrib/samples/portmdoc), so we can use that instead.

The only annoying thing is that I have to rebuild the i386 part of the snapshot again. Anyway, as soon as it’s up (probably tomorrow afternoon, as it has to be uploaded from here first), have fun. I’ll change the channel topic.

NLS, I18N (Internationalisierung), L<Zahl>N (Lokalisierung) und so mögen ja alle schön und gut sein… (gcc verwendet immerhin bei LC_MESSAGES=en_GB.UTF-8 „the Queen’s English“ (so halbwegs) und statt U+0060 (‘`’, muß sterben) typographisch korrekte Anführungszeichen (‘’). Aber… man kann sich bei „tab completion“ leicht auf „Tab-Vervollständigung“ einigen, alles muß man jedoch nicht übersetzen. Auf der Webseite (nicht im RSS) gibt’s ein Bild dazu.

img alt="NLS sucks"
(danke an <teK_:#grml>, der sich zu erinnern meint, daß das SuSE verbrochen habe)

Woohoo, MirOS #10-current (20090811) i386;sparc is out, and with only a glurpzillion problems that arose during its compilation…

While the ext2fs fix is good, we have a new lynx(1) version, and boot(8/i386) has vastly improved, trying to fix boot_sparc(8) didn't help much, I either get esp(4/sparc) problems or panic(9)s in uvm_fork(9). *sigh*

This means that the FrOSCon edition will contain a brand-new i386 snapshot and a merely polished sparc snapshot largely based upon the as-of-now current 20090425 snapshot with hand-tweaking applied.

Thusly no new sparc binary packages for -current will be built.

Even if I did get the hardware issues solved (or move from demo to ss20, I now couldn't get things done in time.

I took the weekend to release a couple of things… MirBSD™ base code stuff and base releases (printf.c for mksh in Debian; arc4random.c for Win32 and other non-BSD OSes, now with a HKCU key used in addition to the HKLM seed key which may not be writable; MirMake; MirPorts Package Tools; mirdate — rdate(8)), jupp, mksh including a new PDF manpage, KWalletCLI, and the RANDEX plugin for XChat (Win32, BSD and *nix). I also prepared for the inclusion of more Debian source packages in my CVS “home subtree” and creation of SRPMs for more software (not in CVS though). I cleaned up the mess that were the X11 dist sets in base, cleaned up compiler warnings on half a dozen or more platforms in several parts of the code, fixed bugs in a lot of subprojects, integrated things better, updated the BSD::arc4random MirPort as well as TinyIRC, MirSirc, the irssi and XChat RANDEX plugins to include better version reporting and, for XChat, seedfile support and better responsibility. Now all I need to do is build more binaries and ports (DEB RPM OpenBSD FreeWRT etc.) of the subprojects, update Lynx in base and ports (there is a new major release out, even), update MirGRML, fix the HDD in my sparc, compile stuff, … you see I’m busy.

Here’s a “checksum and link collection” for today’s finest:

• Simple CVS file drops
• RMD160 (printf.c.1.10) = 8e8b88401a04474db973be07540a79b129919ff5
• TIGER (printf.c.1.10) = 3cec4bc24074e88c7889143d19f7659ced17482115ea5afb
• 3098389975 10575 /MirOS/dist/hosted/other/printf.c.1.10
• MD5 (printf.c.1.10) = d09ae97aebac104f834d3d3ddd1702ca
• RMD160 (arc4random.c.1.16) = b0caa3509d2cade6d86cb2c13e6b8817ced2d9a9
• TIGER (arc4random.c.1.16) = ef6d7a281d451e28434b0e003990eebb47edd0cd4d899fd1
• 2199066621 12558 /MirOS/dist/hosted/other/arc4random.c.1.16
• MD5 (arc4random.c.1.16) = e8376a9b51c0ce08f5ed20722b05cad3
• Simple subproject checkouts
• RMD160 (mirmake-20090801.cpio.gz) = 79e0d15aab4c7a05690e66769c12dbeb3d99daa1
• TIGER (mirmake-20090801.cpio.gz) = 2c6642b9515f38e736386945e72c06f402134ebf898613de
• 788720631 372063 /MirOS/dist/mir/make/mirmake-20090801.cpio.gz
• MD5 (mirmake-20090801.cpio.gz) = 47c63503210054d86db80040474f1f71
• RMD160 (pkgtools-20090801.mcz) = 482dcf4b915a10bb6b76859f0c1755b67d6343bb
• TIGER (pkgtools-20090801.mcz) = 3a622ac3c895c4af9df719dd30cfd3fe45e6d719cc34db5e
• 2864495035 180188 /MirOS/dist/mir/pkgtools/pkgtools-20090801.mcz
• MD5 (pkgtools-20090801.mcz) = 87378c95bde1c219d4a09e6bb8ccb897
• RMD160 (rdate-20090802.tar.gz) = abac9ae8a08ac566d6c0396d39cd5d2cd724f7b0
• TIGER (rdate-20090802.tar.gz) = f38a164e9d77412203349f79e8033c413335dd6f43a5cbf5
• 3840714105 11987 /MirOS/dist/mir/rdate/rdate-20090802.tar.gz
• MD5 (rdate-20090802.tar.gz) = a8fa4550b5a77cff6db1ed0a9d8aa357
• JUPP (including Win32 binary)
• PDF manpage
• HTML manpage
• RMD160 (joe-3.1jupp11.cpio.gz) = 7ade55cb8511600b3a9d77f37bc581b2d09ab2aa
• TIGER (joe-3.1jupp11.cpio.gz) = b7bb4aa464b705e697ab2a52ad75fc8755a5817bfb83e09a
• 805235529 419484 /MirOS/dist/jupp/joe-3.1jupp11.cpio.gz
• MD5 (joe-3.1jupp11.cpio.gz) = 1e2f21a6fdebe678b125e96806267f33
• RMD160 (JWIN31B.EXE) = f9eb9f6b3bd2a1bb5874e36d2dcc6dbdaabf75cc
• TIGER (JWIN31B.EXE) = 771461b752114978ed64f67c01e3ef22a9a9cdf76fda6b11
• 674256238 948176 /MirOS/dist/jupp/JWIN31B.EXE
• MD5 (JWIN31B.EXE) = b2d3f1044221fdea76f15621e94e1ae4
• mksh (including Cygwin package)
• PDF manpage
• RMD160 (mksh-R39.cpio.gz) = 5a5bcbe288e722f9772e27d2fdc36eee174bbb7b
• TIGER (mksh-R39.cpio.gz) = 2a2c08ccf5e27365aa652663629789ade93b3d30c0d1d51f
• 4103085544 278476 /MirOS/dist/mir/mksh/mksh-R39.cpio.gz
• MD5 (mksh-R39.cpio.gz) = b2eeb4fe4ccac2704e1440e53cd2672c
• RMD160 (mksh-39.1-cygwin.tgz) = 0cecd4ffb72f2d51a5c935da58e67350fab10e81
• TIGER (mksh-39.1-cygwin.tgz) = 3157abadc40696bcb8df1d3574df571b728bef3d4d2ac2f2
• 2818578374 144625 mksh R39 for Cygwin
• MD5 (mksh-39.1-cygwin.tgz) = ca949841e39721be666e6a82803e7769
• KWalletCLI
• RMD160 (kwalletcli-1.00.tar.gz) = f04ebd39e9714212a915b6d7d4524c8cc2daaee7
• TIGER (kwalletcli-1.00.tar.gz) = 0fc673c0c813608f0f0d863dfd924a6d62a8507c7bdf361b
• 2355082724 11524 /MirOS/dist/hosted/kwalletcli/kwalletcli-1.00.tar.gz
• MD5 (kwalletcli-1.00.tar.gz) = 76ef3c1d611a11ea13dc805d67d82208
• RANDEX plugin for XChar (including Win32 binary)
• RMD160 (xchat-randex-1.10.tar.gz) = fd61babbf4e5189f69dae8eb664ee2780433bf4b
• TIGER (xchat-randex-1.10.tar.gz) = 6bd888b157fcd931e54b71e9778950cbfa675ae6b784ddd5
• 2651117045 8702 /MirOS/dist/hosted/xchat-randex/xchat-randex-1.10.tar.gz
• MD5 (xchat-randex-1.10.tar.gz) = d1585c5fae3ee531deeffc8314910553
• RMD160 (randex.dll.gz.1.10) = a4aaa67cfdad1f9a1bcdc3eea797aff3a30703c4
• TIGER (randex.dll.gz.1.10) = 55b2dcd7d790d28944d7424121cf5c6d4d386a99751fb556
• 972086546 23998 /MirOS/dist/hosted/xchat-randex/randex.dll.gz.1.10
• MD5 (randex.dll.gz.1.10) = 793ce548256efc6a23f7a37dde9215a2

An observation… mksh “print $RANDOM” on Cygwin is very slow, and the HKCU seed changes each time. This should be debugged, it shan’t unless RANDOM is being written to or 400k calls are done.

Vor ein paar Tagen im IRC…

• KDE4PIM FAQ 5.9 Do I need a running MySQL server? (Nein, wir bringen einen mit, vergessen aber, dessen Sicherheitslücken zu patchen.)
• KDE4PIM FAQ 5.10 Can Akonadi use a normal MySQL server running on my system? (Wer zur Hölle benutzt MySQL, wenn er eine Datenbank (SQLite, MS-SQL, PostgreSQL) haben kann? Außerdem ist es recht diffizil, eine Datenbank oder ein Datengrab aufzusetzen, zu konfigurieren und abzusichern… auch wenn der obige Punkt sagt, sie bringen eine mit.)
• KDE4PIM FAQ 5.6 Which DBMS does Akonadi use? (Ein Wort: Ｗａｒｕｍ？)
• KDE4PIM FAQ 5.7 Why not use sqlite? (Auf Deutsch: wir sind zu blöd, Code zu schreiben, der funktioniert. Daß es mit MySQL tut ist nur Zufall, weil das genau so ein Haufen Scheiße ist, aber das haben wir noch nicht gemerkt.)
• Debian #513382 — akonadi-server: depends on mysql-server (Wir nutzen zwar den Datengrabserver der Distribution, aber ändern trotzdem nix an der Sache. Aber auch wir finden’s „toll“, daß ein MySQL-Server via /etc/init.d ｐｌｕｓ einer pro eingeloggter KDE4-Luser gestartet wird.)

Zu Datenbank vs. Datengrab hatten wir ja:

 “mysql is about as much database as ms access” — “MSSQL at least descends
 from a database” “it's a rebranded SyBase” “MySQL however was born from a
 flatfile and went downhill from there” — “at least jetDB doesn’t claim to
 be a database”	-- myself, Tonnerre and psychoschlumpf in #nosec

Kleine Randbemerkung: mediawiki_*.deb dependet auch auf MySQL… obschon das FusionForge-Paket es für PostgreSQL konfiguriert und das so auch ganz gut tut. Echt ’ne Krankheit…