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).
Michael Langguth and Scalaris AG asked me to publish the mksh/Win32 Beta 14 source and binary archive, and it is with joy I’m doing this.
Checksums and Hashes
- RMD160 (ports/mksh-w32-beta14.zip) = 0dc8ef6e95592bd132f701ca77c4e0a3afe46f24
- TIGER (ports/mksh-w32-beta14.zip) = 966e548f9e9c1d5b137ae3ec48e60db4a57c9a0ed15720fb
- 1181543005 517402 /MirOS/dist/mir/mksh/ports/mksh-w32-beta14.zip
- MD5 (ports/mksh-w32-beta14.zip) = b57367b0710bf76a972b493562e2b6b5
Just a few words on it (more in the README.1st file included): this is a port of The MirBSD Korn Shell R39 to the native WinAPI; it’s not quite got the full Unix feel (especially as it targets the Weihenstephan unxutils instead of a full Interix or Cygwin environment) but doesn’t need a full POSIX emulation layer either. It’s intended to replace MKS ksh and the MKS Toolkit. Source for the compatibility library is also included under The MirOS Licence; we aim at publishing it as OSI Certified Open Source Software like mksh itself. (There is a situation with dlmalloc/nedmalloc being resolved, and the icon is derived from the BSD dæmon which is a protected unregistered trademark, but we’re not Mozilla and allow distro packages to keep using it ☺) Rebasing it on a newer mksh(1) followed by (partial) integration into the main source code is a goal.
Have fun trying it out and hacking on it. It’s currently built with -DMKSH_NOPROSPECTOFWORK (so coprocesses and a few other minor things won’t work), but a SIGCHLD emulation is being worked on – but if you want to help out, I’m sure it’s welcome, just come on IRC or post on the mailing list, and I’ll forward things to Michael as needed. Reports on testing with other toolchain and OS versions are also welcome.
Me envious. Too warm to go to the ice salon (bike’s in repair, car’s hot enough to boil eggs on it, public transport not better).
Just in case someone wonders… I haven’t found any time and “head capacity” to hack recently; $dayjob leaving me sucked dry, with the weather also playing in, etc. but neither did I disappear nor do I intend to drop anything planned.
Sorry for keeping even medium and more severe bugs open for such a long time (several weeks by now, for some); recently I was assured my response time – especially for an Open Source volunteer – is very good still, even if I find it lacking sometimes.
mksh, as one specific thing to mention here, will get an R47 release RSN™ (i.e. as soon as I get around to do it) which could be labelled R46b too (except I like integer version numbers more), it will (that’s a promise) be bugfix-only and ought to be dropped into any place that’s currently shipping R45 or R46, at the very least (and maybe R44 too, and no older versions should be around at all anyway).
Note that me beginning to catch up the TODO list, like today’s cvs(1) upload to Debian, shall not be taken as a sign of me being back (just that I found myself to tackle something). It did take way too long, it’s 22:15 localtime already again, and I had planned to catch up on my leisure reading a bit this evening (damn…) but, well. At least I managed to put in some outdoor fun (to be exact, visiting some more waypoints) too (though I expect this weekend to be scary and it’s definitely underplanned ☹ – but who knows, maybe it’ll be great fun, and wbx@ and my biggest little brother are both a backup plan each.)
Also toying a bit with BOINC again (MirBSD of course, and, this time, some spare CPU capacity at work, which did lead to detecting a hardware/system bug/malconfiguration, even!) prodded by the second (found!) and third (not found… yet) installment of a WCG LC.
I’ve finally gotten around to listing all Waypoints (Geocaches, Opencaches, Closedcaches, Earthcaches, Terracaches including Locationless, Navicaches, etc.) I’ve found a box, enjoyful, educating, a good place to hide one myself, etc. and putting up a list and, of course, generate my own statpic.
I’ll put them up for the other project members, too (already made a picture for gecko2@ but bsiegert@ still needs one; we also need to collect offline lists of found, owned and attended waypoints)…
A bit of background story: I decided, years ago, to have an offline list of cache finds in case something would happen. Just, I had found way too many already, so this was a huge bit of work. Oh well… I of course procrastinated, and then something did happen (Opencaching wanting to force a Restricted Commons licence; me disagreeing and suggesting a change; some trigger-happy person immediately deleting my account without waiting for the discussion or the decision period to end; weeks of forum discussions; Opencaching allowing dual-licencing; them telling me they can’t restore my data – probably never heard of databa…sorry, MySQL backups). And I still didn’t have the list. Now I do; recreated even the OC information from what was still accessible and with help from one OC supporter (“mic@”, thanks); merged caches that are co-listed on several platforms, etc. (still need to put in the FTF/STF/TTF/4TF/LTF and voting/favourites information) and a statpic, all in Open Source and Open Data, in cvs(1) with mksh(1) and… a… frontend for libgd2 I admit, but we had been using that for the MirWebsite for a while already.
I suggest every geocacher keep an offline or local record of all their finds (and hides and attended logs) for things like this, in case some platform decides to… let’s say, “put your data into the cloud… where it is? I don’t know”.
Apparently (hi Zhenech, found on Plänet Debian), a Man does not only need to fork a child, plant a tree, etc. in their life but also write a DynDNS service. Perfect for opening a new tag in the wlog called archæology (pagetable.com – Some Assembly Required is also a nice example for these).
Once upon a time, I used SixXS’ heartbeat protocol client for updating the Legacy IP (known as “IPv4” earlier) endpoint address of my tunnel at home (My ISP offers static v4 for some payment now, luckily). Their client sucked, so I wrote on in ksh, naturally.
And because mksh(1) is such nice a language to program in (although, I only really begun becoming proficient in Korn Shell in 2005-2006 or so, thus please take those scripts with a grain of salt, I’d do them much differently nowadays) I also wrote a heartbeat server implementation. In Shell.
The heartbeat server supports different backends (per client), and to date I’ve run backends providing DynDNS (automatically disabling the RR if the client goes offline), an IP (IPv6) tunnel of my own (basically the same setup SixXS has, without knowing theirs), rdate(8) based time offset monitoring for ntpd(8), and an eMail forwarding service (as one must not run an MTA on dynamic IP) with it; some of these even in parallel.
Not all of it is documented, but I’ve written up most things in CVS. There also were some issues (mostly to do with killing sleep(1)ing subprocesses not working right), so it occasionally hung, but very rarely. Running it under the supervise of DJB dæmontools was nice, as I was already using djbdns, since I do not understand the BIND zone file format and do not consider MySQL a database (and did not even like databases at all, back then). For DynDNS, the heartbeat server’s backend simply updated the zone file (by either adding or updating or deleting the line for the client) then running tinydns-data, then rsync’ing it to the djbdns server primary and secondaries, then running zonenotify so the BIND secondaries get a NOTIFY to update their zones (so I never had to bother much with the SOA values, only allow AXFR). That’s a really KISS setup ☺
Anyway. This is archæology. The scripts are there, feel free to use them, hack on them, take them as examples… even submit back patches if you want. I’ll even answer questions, to some degree, in IRC. But that’s it. I urge people to go use a decent ISP, even if the bandwidth is smaller. To paraphrase a coworker after he cancelled his cable based internet access (I think at Un*tym*dia) before the 2-week trial period was even over: rather have slow but reliable internet at Netc*logne than “that”. People, vote with your purse!
The MirBSD Korn Shell R45 has been released today, and R44 has been named the new stable/bugfix-only series. (That’s version 45.1, not 0.45, dear Homebrew/MacOSX packagers.)
Packagers rejoice: the -DMKSH_GCC55009 dance is no longer needed, and even the run-time check for integer division is gone. Why? Because I realised one cannot use signed integers in C, at all, and rewrote the mksh(1) arithmetics code to use unsigned integers only. Special thanks to the people from musl libc and, to some lesser amount, Natureshadow for providing me with ideas what algorithms to replace some functionality with (signed shell arithmetic is, of course, still usable, it is just emulated using unsigned C integers now).
The following entertainment…
tg@blau:~ $ echo foo >/bar\ baz /bin/mksh: can't create /bar baz: Permission denied 1|tg@blau:~ $ doch tg@blau:~ $ cat /bar\ baz foo
… was provided by Tonnerre Lombard; like Swedish, German has got a number of words that cannot be expressed in English so I feel not up to the task of explaining this to people who don’t know the German word “doch”, just rest assured it calls the last input line (be careful, this is literally a line, so don’t use backslash-newline sequences) using sudo(8).
I uploaded a full bulk build of binary packages for MirBSD/i386 corresponding to the pkgsrc-2013Q1 release. About 7,000 binary packages are available in this build, including the pkgin package manager that makes installing binary packages as easy as apt.
Since a while…
|I am a proud|
On the other hand… I should probably put up my own, local, list of found caches, considering what happened to me on “Open”caching. And maybe write intros for people new to geocaching, since it’d be virtually no work now had I done it initially. (And for fanfiction readers! I wish I’d kept a list of read fics, not just of these I currently read and/or are currently unfinished.)
On Saturday March 23, this year's pkgsrc conference (pkgsrccon 2013) took place in Berlin. Julian Fagir organized it with unending energy, even though pkgsrc is not the primary focus of his NetBSD work. He just took matters in his hands because no one else stepped forward. A big thanks for that!
The flight from Zurich to Berlin was uneventful. It was my first flight to TXL airport (I normally arrive at SXF), and arriving there is incredibly quick and convenient compared to the latter. The terminal is very small, and it takes just five minutes to go from the plane to a bus to the city.
Now for the conference itself: we started at 12pm on Saturday with a program of talks but no fixed schedule. Due to this, the conference took a long time (we finished only at 9pm or so) but on the other hand, it allowed for lots of interesting and fruitful discussion. At no point did we have to cut a question short because of a lack of time. Overall, I think that this was an excellent choice and made the conference more useful and productive.
We were about 21 people – mostly pkgsrc developers (of course) but also a Debian Developer (Ralf Treinen, who presented his work on Mancoosi), a FreeBSD dev and some interested users. I won't give an exhaustive recollection of all talks here but simply comment on a few ones that I found particularly interesting.
The most important theme of the conference was virtualization and cloud computing. Jonathan Perkin and Filip Hajny gave a talk about their company's product, SmartOS, and how it uses pkgsrc. SmartOS is a "cloud OS" based on OpenSolaris. It boots from a read-only medium (such as a CD) into a lean system that only does the administration of all the zones that it runs. All useful work happens in zones, which are a sort of lightweight VM solution specific to OpenSolaris. The zone images include access to a very complete set of pkgsrc packages for things such as a compiler. They can also run other OSes (NetBSD!) by setting up a zone that runs KVM. Joyent runs a large public cloud with SmartOS, where customers purchase virtual machines by the hour. This is similar to Amazon EC2 but with a focus on high performance.
Hubert Feyrer gave another talk about a similar theme. He described the use of Ansible for provisioning and setting up VMs. Ansible can automatically create VMs on EC2, gather the necessary information (such as the IP address) and do various setup tasks without further user interaction. This was all very impressive, even though the live demo failed. This was for two reasons: Somebody deleted the sudo package for amd64 from the NetBSD ftp server (boo), and the i386 VM failed to come up, the kernel paniced on startup. Joerg speculated that this was due to _some_ machines in their DC not having PAE enabled, while the i386 kernel uses PAE. This was interesting, as I had noticed the very same problem when I set up the netbsd-386-bsiegert continuous builder for Go.
Amitai Schlair alias Schmonz came out in a passionate defense of the venerable pkglint. He put the source on github and started refactoring the code and adding tests. He calls this approach TED for "Test Eventually Development" ;) and advocated a similar approach for the pkgsrc infrastructure: Every time a developer takes five minutes to understand a part of the infrastructure (when making a change, for instance), he or she should write a test for it. This is a very pragmatic and doable approach, in my opinion, and we should all do this.
I gave a slightly amended version of the "Go on NetBSD" talk I had given at FOSDEM 2013. There were a lot of valuable questions and discussion, both about the language and about how to package software written in it.
Aleksej Saushev ended the day with a talk that was not in the program about the Google Code-In and the problems that developers and particularly new contributors face. If pkgsrc can get more contributors, it gets more fixes, which in turn makes it more useful to users. More usefulness leads to more users, leading to more contributors. We should do more to get into this virtuous circle. There are about five different mechanisms to build and/or deploy packages in pkgsrc: build directly with "make package", pkg_chk, pkg_comp, the old bulk build scripts and pbulk. The basic frustration that should be overcome is the following: you want to upgrade a set of packages, the old ones are removed, new ones are rebuilt, and the build fails. Rolling back is difficult in general. pbulk could be a valuable solution to this, but its standard config is heavily tailored for a different use case, and its _two_ separate pieces of documentation are contradictory, incomplete and confusing. So the talk contained a call for action to fix those minor annoyances and generally document things better, which makes it easier for everybody.
My take-home message – and my next project idea – is the following: each time that I do a MirBSD bulk build using pbulk, I have to do a lot of painful steps to set up the right build environment on all my machines. This time, I will try to automate this process with Ansible, making up the recipes as I go along, and then (more importantly) publish these recipes for others to use and to share.