A few days ago, somebody sent me an e-mail with a few questions about the Go programming language, of which I am a coauthor and contributor. The questions concerned my general impression, the experience I had in it, the future and some good areas of application. Here is my reply.

In my experience, when people try Go, there are two phases: On a first glance, it does not seem very special. However, many that do try it quickly become hooked.

I myself was primarily programming in C when I started using Go. I had written some code in Limbo, which an be seen as the antecessor of Go, so trying it seemed natural. I quickly discovered that it is a very well-designed language, whose constructs make perfect sense and are easy to grasp. The standard library is also very well done and makes many common programming jobs easy.

I decided to write a project I did for work in Go. However, the target was a Windows system, so I became involved in the Windows port. My first contributions were to the path package. It is a nice experience working with such bright and professional people as the Go developers. While they can be sometimes a bit terse in code reviews, they are very talented people. I found myself thinking a long time about a single sentence in a review before finally “getting it”.

Speaking of which, the code review process is very efficient for the development of the language.

In the future, I think Go will get a much wider adoption, and be usable also for writing “native” graphical user interface programs. There is a WinAPI port for creating Windows GUIs, and there is a very good Gtk+ adapter for Unix-like systems. I can also see it being used a lot for network servers, such as HTTP application servers and so on.

In these two areas, parallelism is a key point. In a GUI application, you want the interface to remain reactive during calculations and I/O, which is very easy to do with multiple goroutines. In a network application, you also have to process many requests in parallel. Go has the potential to scale significantly better than other languages. Maybe will even be one of the answers to the problem of programming for ever more parallel machines, as almost all new computers have multiple CPU cores.

I also think that there will be more optimization so the language will get much faster in the future. It is already faster than Python in most cases (easy, since it is a compiled language) but just as easy for many.

Since 2011-03-09, I am now a NetBSD developer. My allocated work area is MirBSD support for pkgsrc. This is now much simpler, as I have direct commit access to the repo.

My sponsors are Guillaume Lasmayous (glc) and Alistair G. Crooks (agc). The whole thing would never have happened if Marc Ballmer had not started the new-developer process during FOSDEM 2011. A big “Thank you” goes out to these three persons in particular as well as to all those that warmly welcomed me on the NetBSD developer mailing list.

mksh-current has just gained an experimental recursive parser for command substitutions, fixing RedHat BZ#496791 and decades-old complaints about the pdksh codebase, compared to AT&T ksh93. (GNU bash could also do the example, but not some other things mksh(1) parses fine now.)

This means that things like the following work now.

	# POSIX, should “always” work
	echo $(case 1 in (1) echo yes;; (2) echo no;; esac)
	# POSIX optional, works now in mksh, works in GNU bash
	echo $(case 1 in 1) echo yes;; 2) echo no;; esac)
	# GNU bash seems to choke on comments ending with backslash
	# a comment with " ' \
	x=$(
	echo yes
	# a comment with " ' \
	)
	# No non-recursive COMSUB parser can pass all of the above
	# tests and these below at the same time (some extensions)
	echo $(typeset -i10 x=16#20; echo $x)
	echo $(typeset -Uui16 x=16#$(id -u)
	) .
	echo $(c=1; d=1
	typeset -Uui16 a=36#foo; c=2
	typeset -Uui16 b=36 #foo; d=2
	echo $a $b $c $d)
	# the ‘#’ is especially tricky, that’s why the above cases

Next on my TODO is the complete rewrite of the read built-in command, as well as its documentation. I think that the (reduced) goals for mksh R40 will have been met by then, except porting to LynxOS and MPE, but we’re working on it, and re-testing Syllable and Plan 9). Of course, a release implies testing on a lot of the supposedly supported platforms, so it won’t be out “immediately”. Though, associative arrays have been removed from the R40 goals, so that I can at least get a new release out. Note that Debian and OpenSuSE Buildservice users have been provided with somewhat well-tested mksh-current snapshots for a while already, and Gentoo users can use the “live ebuild”; there’s always compiling from source too…

Warning: this is a rant against BSD (specifically FreeBSD®, but don’t let me get started on DragonFly, who think it’s wise to drop all shells except ash from the base system and rely on pkgsrc® — yay let’s compile a dozen packages just to get a shell with tab completion, not to mention boxen with no network access — for the task — although others seem to go into that direction too…; you know, there’s BSD, and then there’s FreeBSD…) — don’t like, don’t read.

If you want to change something in the BSD world, you gotta fork your own BSD — no other way around the thickheads. Ok, back then, I ran into a particularily thick one, but others tend to not be much better. Users share the thickness. If you want to change something in the GNU/Linux world, just make a package, have someone upload it, prod (or pay, Hanno got a Radler) people to do it, or just upload it yourself.

At the BSD booth at FOSDEM, despite me bringing the Windows® Mobile 6 Professional devive, strictly for Geocaching mind you, Macintosh boxen had a share of more than 50% — I didn’t manage to tip the scale. At the Debian booth, almost everyone had a “I want to buy a new laptop some day, but it just keeps on working and doesn’t break” pre-Lenovo IBM laptop. No hyping of Google either. (Last year’s CLT saw BSD people advocating pro-Schily — the guy with the broken encoding in his name — shockingly.)

Honestly, tcsh, FreeBSD® people? Sorry. While I agree that there is merit on having the same script and interactive shell, as someone has pointed out (copy-paste examples into the command line), there’s those zsh users who use mksh or GNU bash for scripting. Or just POSIX shell. And that’s with an interactive shell which can be used for scripting. On the other hand, the C shell (both csh and tcsh) cannot.

And what’s with pretending the accent gravis is non-combining, called “backtick” (such a thing does not exist); and advocating it? Sorry, if your csh/tcsh doesn’t handle the POSIX $(…) you should just drop it. (By the way, there is a convention that example command lines are prefixed with %  for csh and $  for sh (or #  but we write $ sudo  instead, these days). Use it. Or leave it. If you have examples that substitute another process’ output, be specific.) It’s funny to see how one person tries to defuse my arguments against csh by telling me “it’s just an interactive shell”, while the other argues that people copy-paste between them, to which that was my response. Read the thread!

And please, get your facts right. “I would prefer that the standard shell be at least Bourne-compatible.” You don’t want Bourne (“^” instead of “|” for pipes), you want POSIX. That GNU bash is called the Bourne-Again Shell in one of their usual semi-bad puns doesn’t help the global perception of such things any. Also, the root shell and /bin/sh are disjunct.

(Plus, why change the root shell, use sudo(8), plain and simple.)

ObNote: in jupp (should I package that for Debian, btw? rather upload, packages are ready…) the ‘`’ key is used as præfix for Ctrl-X (`X) or to directly enter numerical (decimal, octal, sedecimal/hexadecadic) ASCII, 8-bit or Unicode codepoints. Yay!
And even the FSF has seen the light; for a few releases already, GCC uses “'…'” instead of “`…'” for quoting in messages, even without locales. Great job there! (LC_MESSAGES=en_GB.UTF-8 usually works, too, though.)

ObDisclaimer: I have an (yes, Google…) Alert on the word “mksh”, so I know when it’s being discussed. This obviously includes certain fora. Also, I’m a shell implementer and bound to know a certain amount of details. Plus, mksh’s build script runs with pretty much any Bourne/POSIX/Z Shell which has functions and not too many bugs. I wrote it. Go figure. No lowly trolling.

FWIW, mksh(1) has the cat(1) builtin both because Android has no cat(1), and as speed hack. Almost all other shells have worse speed hacks, like a printf(1) builtin. And recently, builtins have become direct-callable, so this actually reduces the overall system footprint. (Its inclusion also provides for some other possibilities, internally.) And as two final side notes, if you haven’t seen this: determine which shell we are run under (CVS) and I still offer a prompt conversion service (send me any GNU bash or oksh $PS1 and I’ll send that to you in mksh(1) syntax — optionally with adjustments/improvements, like cwd uses only up to 1/3 of screen width).

Eh. Why does mksh built with (a patched: mkstemp(3) added) klibc work suddenly, unexpectedly?

To reproduce, I just uploaded mksh_39.3.20110218-1.dsc and you can run DEB_BUILD_OPTIONS=mksh-static=klibc,dietlibc,eglibc dpkg-buildpackage -rfakeroot to verify it, once you have mkstemp(3). (I will probably send a smaller implementation of that in, later.) I have that and the open fix and the m68k patch applied, nothing else… where did my bug go?

ObQuestion: what’s the legal (copyright/trademark) status of the Atari logo (the one in rainbow colours, with three things going up, right and left “leg” looking like an umbrella stand’s)?

I just need to work more on bilocality. While I did find two geocaches, one at the South/Noon Train Station (taalverwarringen…), one in the buurt of the University, I did manage to miss the AW building completely and utterly. Wow. Except, that Haiku guy came over to talk for a bit (nice). And I drew. An Atari logo with swirl, for that weird stuff I recently have been found doing.

More mksh-current news coming soon, stay tuned. In the meanwhile, I met bonsaikitten IRL (at FOSDEM, yes, too) who kindly made a “live ebuild”, i.e. a source package building -current.

Finally let’s say a big thank you to the person mostly manning our booth, gecko2, and to Benny for talking to people, getting That Other Packaging Thingy working, and pimping the website a bit.

Dear Opera Software A.S.A.

It’s nice that you employ SecureAPT for your package repository, however, the effect is slightly lost by you replacing the key each year, never signing any of them, and putting them up on an http but not https site.

Update 18.08.2011 — please refrain from putting a file /etc/apt/sources.d/opera.list inside your binary DEB packages, as well. As a system administrator, we may very well have mirrored the binary packages, and do not want accesses to external APT repos, for a shitload of reasons. Honestly. (Lintian could warn about it…)

If you don’t get the message, please contact me. Or any of my fellow Debian Developers. Thank you very much.

I’ve just prepared an ISO for FOSDEM Ⅺ which we might export on BitTorrent soon. Benny has provided an upgraded desktop background image, thanks.

The next mksh release… well I’ll bite the sour apple and will release it without associative arrays but hope I get around to hack a few things (especially the read and sleep builtins) before releasing. One lession learned, don’t brag with oh-so-big plans when you haven’t got a deliverable yet. Real Life will interfere. Oh, and Murphy, of course. (mksh R41 might have the associative arrays then. But mksh-current has ${foo@#} which is hash($foo).

tl;dr: New Evolvis release, scmgit plugin, bidirectional merge with FusionForge 5.1; committing tarent features back to Mediawiki and Mailman packaging in Debian; Fairtrade Software

tarent GmbH now offers both git and Subversion as Source Code Management systems in their Evolvis platform.

The scmsvn plugin of EvolvisForge was amended with the scmgit plugin, backported from a newer FusionForge release, while work to upgrade the main forge code to the soon-to-be-released FusionForge is ongoing in parallel. Of course, most features, such as commit mails (in git, they’re really sent out after a “git push” from the developer), are already available for both; others will follow after the code base upgrade for simplicity. Already, git repositories can be used for all regular tasks — although it’s currently not possible to have both git and svn repositories in a project.

During the migration (as well as regular development), many features of Evolvis will show up in regular FusionForge to benefit the broad community of Forge users, courtesy of the Open Source policy of tarent GmbH, who has contracted the FusionForge project leader to improve both projects, following the mantra of “Fairtrade Software”.

Among other changes, the SOAP WSDL has been corrected and is now versioned, and other areas (especially the Tasks and Tracker) have been improved.

There’s a release announcement of the new version at Evolvis, in case you want to know the details.

Finally, an Evolvis developer has set foot not only in the Mediawiki packaging team at Debian but also the Mailman packaging team. Expect many, if not all, improvements to show up there within some time.

Did you know that Hudson is now called Jenkins? This is a change in name only, due to trademark concerns, but rest assured the Evolvis platform will continue to offer Continuous Integration in a usable fashion, no matter the technology behind (there was Continuum, now Hudson, soon Jenkins).

In our evergoing quest to improve the Evolvis platform, we wish you a pleasant user and developer experience!
//The Evolvis team

❧ Who’s not? ☺ Same procedure as every year.

(okay, lolando prefers skiïng but…)

Anyway. A cow‐orker told me that Belgium again/still has no gouvernment, and they have been asked to grow out their beards until they do. I found “evidence” on the ’net but won’t link it here, also it’s on German… anyway. Let’s all join in. (Besides, I now have an excuse to not shave, maybe even my grandmother will accept this one…)

RT said on IRC that mksh will probably work on MSYS.

My Debian/m68k stuff is coming around nicely, but I still haven’t gotten around to do everything planned, plus I need to grow a new kernel and eglibc, after the latest uploads, and the 2.6.37 based one panics. Also I’ve got to take care to not overwork myself. (And make a MirBSD ISO for FOSDEM.) But hey, it’s been not working for some time and better now. And slow anyway ☺ yet we’re progressing. Does anyone know how to debug that a C program only calling res_init(3) segfaults?

Benny is apparently not just working on making NetBSD® pkgsrc® available on MirOS BSD (picking up my work from 4+ years ago) but also replacing The MirPorts Framework with it. Sad, as I got a request for a gajim MirPort over a cocktail just this evening…

27C3 brought significant advancements in pkgsrc support for MirOS BSD. I am in contact with a NetBSD developer, who is favourable to including the patch upstream in pkgsrc. For them, there are two parts for this: (a) the mere addition of a "MirBSD" stanza, which is unproblematic, and (b) other code changes, which need more review. Note that pkgsrc is currently frozen before the 2010Q4 release, so our patches will likely be deferred until after the freeze.

If you would like the current patches, which are still in a bit of a rough shape, here is how to use it:

1. Make sure there are no mentions of MirPorts in your current environment. Most importantly, remove /usr/mpkg/bin and /usr/mpkg/sbin from your PATH. This is needed when building or installing packages; the reason is that the package tools from MirPorts and pkgsrc have the same name but are incompatible with each other.
2. Check out pkgsrc, for example to /usr/pkgsrc:
   cvs -qd anoncvs@anoncvs.netbsd.org:/cvsroot co -P pkgsrc
3. To be sure that the patches will apply, downgrade the patched directories:
   cd pkgsrc
   cvs -q up -Pd -D2010-12-27 bootstrap devel/{bmake,libtool*} lang/perl5 mk
4. Apply pkgsrc-bootstrap.diff, then pkgsrc-libtool-miros.diff:
   cat pkgsrc-bootstrap.diff pkgsrc-libtool-miros.diff | patch -p0
5. Check that there are no rejected patches:
   find . -name "*.rej"
   should give no results.
6. Bootstrap pkgsrc. In this example, we install (using sudo) into /usr/pkg. The dbdir should be inside the prefix to avoid conflicts with MirPorts.
   cd bootstrap
   ./bootstrap --prefix /usr/pkg --pkgdbdir /usr/pkg/db
7. Add /usr/pkg/bin and /usr/pkg/sbin to your path:
   export PATH=/usr/pkg/bin:${PATH}:/usr/pkg/sbin
8. I recommend to install perl first because it is needed by many other packages and because it needs a workaround at the moment:
   cd ../lang/perl5
   bmake install && cd /usr/pkg/lib && ln perl5/5.12.0/*/CORE/libperl.so.* .

You can now use pkgsrc to build whatever you like. Please test this procedure and report whether it works for you.

Like we decided on FrOSCon this august, I restarted work on getting pkgsrc working again and then, on adding support for MirOS BSD to pkgsrc upstream. The thing is, while our MirPorts infrastructure is, in my opinion, outstanding, many of the ports themselves are highly out of date. Having pkgsrc would free us from the burden of maintaining thousands of ports ourselves. Many of the technical arguments that had originally been brought up against pkgsrc (such as missing support for "faking") have been addressed in the last few years.

As a first step, I applied Thorsten's old diff against the pkgsrc-2006Q4 stable branch, which was created shortly after the diff had been made. Next, I am porting these changes to a current pkgsrc branch in order to get them integrated. However, this will involve porting libtool 2 to MirOS, as newer pkgsrc versions only use this version. Wish me luck :).

I will be on 27C3 in Berlin from December 27 to 30, even though tg@ will not.