Karolina Lesińska writes: “We have placed the first 3 issue of BSDmagazine on our website as free downloads. The issues are:
- FreeBSD Ins & Outs
- OpenBSD in the Limelight
- 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 email@example.com:/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.
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.
(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
- 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…
My play *.deb repository no longer carries binaries for iPhoneOS 2.2, or any other version for that matter. Apple prides themselves in DRM (Digital Restrictions Management) in a way that makes them look totally ridiculous to anyone with only the tiniest amount of technical knowledge or political empathy. Gah. I don't see why I should support that with free software. Besides, it's not a good tool for geocaching, either.
Some years ago, this would not have surprised me, but these days it's rare to find a company doing similar stunts. While the iPhone may help them through the current economical crisis, I dare suggest they build more variants of the iMer instead :þ At least these have hack value.
jupp development has been split into two active development lines: jupp for DOS (based on joe 2.8) and jupp for Unix (based on joe 3.x).
There are binaries for both DOS (jupp for DOS) and Win32 (jupp for Unix, via Cygwin) available.
The jupp for DOS development line incorporates only minor patches relative to the original source code (it wasn’t that buggy as the sourceforge development made the code later…) and a jupprc file tuned for it but feature-complete with joe-3.1jupp10’s one.
The jupp for Unix development line incorporates all of the very extensive patches to the binary, and an enriched jupprc with, due to popular demand, syntax highlighting enabled by default – even though I still loathe it personally, and feel with Rob Pike when he questions the use of pretty printers. It will also try to correctly guess CR-LF vs LF-only line endings, indentation, and terminal colour. Furthermore, the language selection of the jupp flavour is now en par with that of the joe flavour, and the Python variants honour the standard coding style of theirs (needed that by the third quarter of last year, remember?). Autoindent is still off, by default, though – with reason.
Now give it a try. Hint: ^J (Ctrl-J) invokes the help.