Light

Top 5 systemd troubles - a strategic view for distros

systemd is a new way to start a Linux-system with the expressed goal of rethinking all of init. These are my top 5 gripes with it. (»skip the updates«)

Update (2016-09-28): Systemd is an exploit kit just waiting to be activated. And once it is active, only those who wrote it will be able to defuse it — and check whether it is defused. And it is starting: How to crash systemd in one tweet? Alternatives? Use OpenRC for system services. That’s simple and fast and full-featured with minimal fuss. Use runit for process supervision of user-services and system-services alike.

Update (2014-12-11): One more deconstruction of the strategies around systemd: systemd: Assumptions, Bullying, Consent. It shows that the attitude which forms the root of the dangers of systemd is even visible in its very source code.

Update (2014-11-19): The Debian General Resolution resulted in “We do not need a general resolution to decide systemd”. The vote page provides detailed results and statistics. Ian Jackson resigned from the Technical Committee: “And, speaking personally, I am exhausted.”

Update (2014-10-16): There is now a vote on a General Resolution in Debian for preserving the ability to switch init systems. It is linked under “Are there better solutions […]?” on the site Shall we fork Debian™? :^|.

Update (2014-10-07): Lennart hetzt (german) describes the rhetoric tricks used by Lennart Poettering to make people forget that he is a major part of the communication problems we’re facing at times - and to hide valid technical, practical, pragmatical, political und strategical criticism of Systemd.

Update (2014-09-24): boycott systemd calls for action with 12 reasons against systemd: “We do recognize the need for a new init system in the 21st century, but systemd is not it.”

Update (2014-04-03): And now we have Julian Assange warning about NSA control over Debian, Theodore Ts’o, maintainer of ext4, complaining about incomprehensible systemd, and Linus Torvalds (you know him, right?) rant against disrupting behavior from systemd developers, going as far as refusing to merge anything from the developers in question into Linux. Should I say “I said so”? Maybe not. After all, I came pretty late. Others saw this trend 2 years before I even knew about systemd. Can we really assume that there won’t be intentional disruption? Maybe I should look for solutions. It could be a good idea to start having community-paid developers.

Update (2014-02-18): An email to the mailing list of the technical committee of debian summarized the strategic implications of systemd-adoption for Debian and RedHat. It was called conspiracy theory right away, but the gains for RedHat are obvious: RedHat would be dumb not to try this. And only a fool trusts a company. Even the best company has to put money before ethics.

Update (2013-11-20): Further reading shows that people have been giving arguments from my list since 2011, and they got answers in the range of “anything short of systemd is dumb”, “this cannot work” (while OpenRC clearly shows that it works well), requests for implementation details without justification and insults and further insults; but the arguments stayed valid for the last 2 years. That does not look like systemd has a friendly community - or is healthy for distributions adopting it. Also an OpenRC developer wrote the best rebuttal of systemd propaganda I read so far: “Alternativlos”: Systemd propaganda (note, though, that I am biased against systemd due to problems I had in the past with udev kernel-dependencies)

Phoronix conclusions distort their results, shown with the example of GCC vs. LLVM/Clang On AMD's FX-8350 Vishera

Phoronix recently did a benchmark of GCC vs. LLVM on AMD hardware. Sadly their conclusion did not fit the data they showed. Actually it misrepresented the data so strongly, that I decided to speak up here instead of having my comments disappear in their forums. This post was started on 2013-05-14 and got updates when things changed - first for the better, then for the worse.

Update 3 (the last straw, 2013-11-09): In the recent most blatant attack by Phoronix on copyleft programs - this time openly targeted at GNU - Michael Larabel directly misrepresented a post from Josh Klint to badmouth GDB (Josh confirmed this1). Josh gave a report of his initial experience with GDB in a Kickstarter Update in which he reported some shortcomings he saw in GDB (of which the major gripe is easily resolved with better documentation2) and concluded with “the limitations of GDB are annoying, but I can deal with it. It's very nice to be able to run and debug our editor on Linux”. Michael Larabel only quoted the conclusion up to “annoying” and abused that to support the claim that game developers (in general) call GDB “crap” and for further badmouthing of GDB. With this he provided the straw which I needed to stop reading Phoronix: Michael Larabel is hostile to copyleft and in particular to GNU and he goes as far as rigging test results3 and misrepresenting words of others to further his agenda. I even donated to Phoronix a few times in the past. I guess I won’t do that again, either. I should have learned from the error of the german pirates and should have avoided reading media which is controlled by people who want to destroy what I fight for (sustainable free software).
Update 2 (2013-07-06): But the next went down the drain again… “Of course, LLVM/Clang 3.3 still lacks OpenMP support, so those tests are obviously in favor of GCC.” — I couldn’t find a better way to say that those tests are completely useless while at the same time devaluing OpenMP support as “ignore this result along with all others where GCC wins”…
Update (2013-06-21): The recent report of GCC 4.8 vs. LLVM 3.3 looks much better. Not perfect, but much better.

1. Josh Klint from Leadwerks confirmed that Phoronix misrepresented his post and wrote a followup-post: » @ArneBab That really wasn't meant to be controversial. I was hoping to provide constructive feedback from the view of an Xcode / VS user.« » Slightly surprised my complaints about GDB are a hot topic. I can make just as many criticisms of other compilers and IDEs.« » The first 24 hours are the best for usability feedback. I figure if they notice a pattern some of those things will be improved.« » GDB Follwup «@Leadwerks, 2:04 AM - 11 Nov 13, 2:10 AM - 11 Nov 13 and @JoshKlint, 2:07 AM - 11 Nov 13, 8:48 PM - 11 Nov 13

2. The first-impression criticism from Josh Klint was addressed by a Phoronix reader by pointing to the frame command. I do not blame Josh for not knowing all tricks: He wrote a fair account of his initial experience with GDB (and he said later that he wrote the post after less than 24 hours of using GDB, because he considers that the best time to provide feedback) and his experience can serve as constructive criticism to improve tutorials, documentation and the UI of GDB. Sadly his visibility and the possible impact of his work on free software made it possible for Phoronix to abuse a personal report as support for a general badmouthing of the tool. In contrast the full message of Josh Klint ended really positive: Although some annoyances and limitations have been discovered, overall I have found Linux to be a completely viable platform for application development. — Josh Klint, Leadwerks

3. I know that rigging of tests is a strong claim. The actions of Michael Larabel deserve being called rigging for three main reasons: (1) Including compile-time data along with runtime performance without clear distinction between both, even though compile-time of the full code is mostly irrelevant when you use a proper build system and compile time and runtime are completely different classes of results, (2) including pointless tests between incomparable setups whose only use is to relativate any weakness of his favorite system and (3) blatantly lying in the summaries (as I show in this article).

Making websafe colors safe for colorblind people

I just made the colors of my plotting framework safe for colorblind people (thanks to Paul Tol’s notes) and I want to share a very nice result I got: How to make the really websafe colors safe for colorblind people with minimal changes.

(the colorblind-safe colors are on the left, the original websafe colors on the right)

To do so, I turned to Color Oracle (for simulation of colorblindness directly on my screen) and Emacs rainbow-mode (for seeing the colors while editing the hex-codes - as shown in the screenshots above) and tweaked the color codes bit by bit, until they were distinguishable in the simulation of Deuteranopia, Protanopia and Tritanopia.

Installing Scipy and PyNIO on a Bare Cluster with the Intel Compiler

2 years ago I had the task of running a python-program using scipy on our university cluster, using the Intel Compiler. I needed all those (as well as PyNIO and some other stuff) for running TM5 with the python shell on the HC3 of KIT.

This proved to be quite a bit more challenging than I had expected - but it was very interesting, too (and there I learned the basics of GNU autotools which still help me a lot).

But no one should have to go to the same effort with as little guidance as I had, so I decided to publish the script and the patches I created for installing everything we needed.1

The script worked 2 years ago, so you might have to fix some bits. I won’t promise that this contains everything you need to run the script - or that it won’t be broken when you install it. Actually I won’t promise anything at all, except that if the stuff here had been available 2 years ago, that could have saved me about 2 months of time (each of the patches here required quite some tracking of problems, experimenting and fixing, until it provided basic functionality - but actually I enjoyed doing that - I learned a lot - I just don’t want to be forced to do it again). Still, this stuff contains quite some hacks - even a few ugly ones. But it worked.

Installing GNU Guix 0.6, easily

Org-Source (for editing)

PDF (for printing)

“Got a power-outage while updating?
No problem: Everything still works”

GNU Guix is the new functional package manager from the GNU Project which complements the Nix-Store with a nice Guile Scheme based package definition format.

What sold it to me was “Got a power-outage while updating? No problem: Everything still works” from the Guix talk of Ludovico at the GNU Hacker Meeting 2013. My son once found the on-off-button of our power-connector while I was updating my Gentoo box. It took me 3 evenings to get it completely functional again. This would not have happened with Guix.

Update (2014-05-17): Thanks to zerwas from IRC @ freenode for the patch to guix 0.6 and nice cleanup!

Intro

Installation of GNU Guix is straightforward, except if you follow the docs, but it’s not as if we’re not used to that from other GNU utilities, which often terribly short-sell their quality with overly general documentation ☺

So I want to provide a short guide how to setup and run GNU Guix with ease. My system natively runs Gentoo, My system natively runs Gentoo, so some details might vary for you. If you use Gentoo, you can simply copy the commands here into the shell, but better copy them to a text-file first to ensure that I do not try to trick you into doing evil things with the root access you need.

In short: This guide provides the First Contact and Black Triangle for GNU Guix.

Communicating your project is an essential step for getting the users you want. Here I summarize my experience from working on several different projects including KDE (where I learned the basics of PR - yay, sebas!), the Hurd (where I could really make a difference by improving the frontpage and writing the Month of the Hurd), Mercurial (where I practiced the minimally invasive PR) and 1d6 (my own free RPG where I see how much harder it is to do PR, if the project to communicate is your own).

Since voicing the claim that marketing is important often leads to discussions with people who hate marketing of any kind, I added an appendix with an example which illustrates nicely what happens when you don’t do any PR - and what happens if you do PR of the wrong kind.

If you’re pressed for time and want the really short form, just jump to the questionnaire.

Use the source, Luke! — Emacs org-mode beamer export with images in figure

I just needed to tweak my Emacs org-mode to beamer-latex export to embed images into a figure environment (not wrapfigure!). After lots of googling and documentation reading I decided to bite the bullet and just read the source. Which proved to be much easier than I had expected.

This tutorial requires at least org-mode 8.0 (before that you had to use hacks to get figure without a caption). It is only tested for org-mode 8.0.2: The code you see when you read the source might look different in other versions.

default answer to “I want to connect with you on [hip unfree service]”

I just decided to give a default answer when I get some email from people asking me to connect to them on some new unfree service:

Hello [Person],

You asked me to connect with you on some unfree service. If you still want that, just use a status.net-server. Those are federated, so you can use a number of different providers and still be connected to everyone on any other server.

1 Introduction

I recently started really learning Fortran (as opposed to just dabbling with existing code until it did what I wanted it to).

Here I document the surprises I found along the way.

If you want a quick start into Fortran, I’d suggest to begin with the tutorial Writing a commandline tool in Fortran and then to come back here to get the corner cases right.

As reference: I come from Python, C++ and Lisp, and I actually started to like Fortran while learning it. So the horror-stories I heard while studying were mostly proven wrong. I uploaded the complete code as base60.f90.

timezones of tccon stations

Timezones of most active TCCON stations in UTC+x (without daylight saving time (DST). Because I needed it and could not find a simple list quickly.

anmyondo: +9,
ascension: 0,
bialystok: +1,
bremen: +1,
caltech: -8,
darwin: 9, # Timezones2008 says 9 1/2???

Equal-Area Map Projections with Basemap and matplotlib/pylab

Org (reproduce)

Plotting global equal area maps with python, matplotlib/pylab and Basemap.

information-disbalance creates a power-disbalance

→ a comment to You call it privacy invasion, I don't from Flameeyes.

What you state is a strong version of the “I’ve got nothing to hide” argument. If you’re interested in a thorough debunking, there is a very good article in the chronicle about that: Why Privacy Matters even if you have nothing to hide.

Thank you for your Flattr’s! | Danke für eure Flattr! | Dankon por vian Flattrn!

It’s always a great feeling to see a flattr - Thank you for your support!
You can find new free works for you enjoyment on draketo.de (infrequent and bursty) and 1w6.org (currently weekly but mostly in German).

Es ist ein tolles Gefühl, geflattrd zu werden - Danke für eure Unterstützung!

Basic usecases for DVCS: Workflow Failures

If you came here searching for a way to set the username in Mercurial: just run hg config --edit and add
[ui]
username = YOURNAME <EMAIL>
to the file which gets opened. If you have a very old version of Mercurial (<3.0), open $HOME/.hgrc manually. Update (2015-02-05): For the Git breakage there is now a partial solution in Git v2.3.0: You can push into a checked out branch when you prepare the target repo via git config receive.denyCurrentBranch updateInstead, but only if nothing was changed there. This does not fully address the workflow breakage (the success of the operation is still state-dependent), but at least it makes it work. With Git providing a partial solution for the breakage I reported and Mercurial providing a full solution since 2014-05-01, I call this blog post a success. Thank you Git and Mercurial devs! Update (2014-05-01): The Mercurial breakage is fixed in Mercurial 3.0: When you commit without username it now says “Abort: no username supplied (use "hg config --edit" to set your username)”. The editor shows a template with a commented-out field for the username. Just put your name and email after the pre-filled username = and save the file. The Git breakage still exists. Update (2013-04-18): In #mercurial @ irc.freenode.net there were discussions yesterday for improving the help output if you do not have your username setup, yet. 1 Intro I recently tried contributing to a new project again, and I was quite surprised which hurdles can be in your way, when you did not setup your environment, yet. So I decided to put together a small test for the basic workflow: Cloning a project, doing and testing a change and pushing it back. I did that for Git and Mercurial, because both break at different points. I’ll express the basic usecase in Subversion: • svn checkout [project] • (hack, test, repeat) • (request commit rights) • svn commit -m "added X" You can also replace the request for commit rights with creating a patch and sending it to a mailing list. But let’s take the easiest case of a new contributor who is directly welcomed into the project as trusted committer. A slightly more advanced workflow adds testing in a clean tree. In Subversion it looks almost like the simple commit: Babcore: Emacs Customizations everyone should have Update (2017-05): babcore is at 0.2, but I cannot currently update the marmalade package. See lisplets/babcore.el 1 Intro PDF-version (for printing) Package (to install) orgmode-version (for editing) repository (for forking) project page (for fun ☺) Emacs Lisp (to use) I have been tweaking my emacs configuration for years, now, and I added quite some cruft. But while searching for the right way to work, I also found some gems which I direly miss in pristine emacs. This file is about those gems. Babcore is strongly related to Prelude. Actually it is just like prelude, but with the stuff I consider essential. And staying close to pristine Emacs, so you can still work at a coworkers desk. But before we start, there is one crucial piece of advice which everyone who uses Emacs should know: C-g: abort  Hold control and hit g. That gets you out of almost any situation. If anything goes wrong, just hit C-g repeatedly till the problem is gone - or you cooled off far enough to realize that a no-op is the best way to react. To repeat: If anything goes wrong, just hit C-g. wisp: Whitespace to Lisp » I love the syntax of Python, but crave the simplicity and power of Lisp.« display "Hello World!" ↦ (display "Hello World!")  define : factorial n (define (factorial n) if : zero? n ↦ (if (zero? n) . 1 1 * n : factorial {n - 1} (* n (factorial {n - 1}))))  Wisp basics • Wisp turns indentation into lisp expressions. • Why Wisp? • Get it • from its Mercurial repository: hg clone http://bitbucket.org/ArneBab/wisp • Or via GNU Guix: guix package -i guile guile-wisp • Or via the package guile-wisp-hg for Arch Linux. • Or via ./configure; make install from the releases: bitbucket.org/ArneBab/wisp/downloads/ • See more examples and tests. »ArneBab's alternate sexp syntax is best I've seen; pythonesque, hides parens but keeps power« — Christopher Webber in twitter, in identi.ca and in his blog: Wisp: Lisp, minus the parentheses ☺ Yay! ☺ with (open-file "with.w" "r") as port format #t "~a\n" : read port Familiar with-statement in 25 lines. Update (2018-06-26): There is now a wisp tutorial for beginning programmers: “In this tutorial you will learn to write programs with wisp. It requires no prior knowledge of programming.”Learn to program with Wisp, published in With Guise and Guile Update (2017-11-10): wisp v0.9.8 released with installation fixes (thanks to benq!). To start your own wisp-project, see the tutorial Starting a wisp project. For more info, see the NEWS file. To test wisp v0.9.8, install Guile 2.0.11 or later and bootstrap wisp: wget https://bitbucket.org/ArneBab/wisp/downloads/wisp-0.9.8.tar.gz; tar xf wisp-0.9.8.tar.gz ; cd wisp-0.9.8/; ./configure; make check; examples/newbase60.w 123 If it prints 23 (123 in NewBase60), your wisp is fully operational. That’s it - have fun with wisp syntax! Update (2017-10-17): wisp v0.9.7 released with bugfixes. To start your own wisp-project, see the tutorial Starting a wisp project. For more info, see the NEWS file. To test wisp v0.9.7, install Guile 2.0.11 or later and bootstrap wisp: wget https://bitbucket.org/ArneBab/wisp/downloads/wisp-0.9.7.tar.gz; tar xf wisp-0.9.7.tar.gz ; cd wisp-0.9.7/; ./configure; make check; examples/newbase60.w 123 If it prints 23 (123 in NewBase60), your wisp is fully operational. That’s it - have fun with wisp syntax! Update (2017-10-08): wisp v0.9.6 released with compatibility for tests on OSX and old autotools, installation to guile/site/(guile version)/language/wisp for cleaner installation, debugging and warning when using not yet defined lower indentation levels, and with wisp-scheme.scm moved to language/wisp.scm. This allows creating a wisp project by simply copying language/. A short tutorial for creating a wisp project is available at Starting a wisp project as part of With Guise and Guile. For more info, see the NEWS file. To test wisp v0.9.6, install Guile 2.0.11 or later and bootstrap wisp: wget https://bitbucket.org/ArneBab/wisp/downloads/wisp-0.9.6.tar.gz; tar xf wisp-0.9.6.tar.gz ; cd wisp-0.9.6/; ./configure; make check; examples/newbase60.w 123 If it prints 23 (123 in NewBase60), your wisp is fully operational. That’s it - have fun with wisp syntax! Update (2017-08-19): Thanks to tantalum, wisp is now available as package for Arch Linux: from the Arch User Repository (AUR) as guile-wisp-hg! Instructions for installing the package are provided on the AUR page in the Arch Linux wiki. Thank you, tantalum! Update (2017-08-20): wisp v0.9.2 released with many additional examples including the proof-of-concept for a minimum ceremony dialog-based game duel.w and the datatype benchmarks in benchmark.w. For more info, see the NEWS file. To test it, install Guile 2.0.11 or later and bootstrap wisp: wget https://bitbucket.org/ArneBab/wisp/downloads/wisp-0.9.2.tar.gz; tar xf wisp-0.9.2.tar.gz ; cd wisp-0.9.2/; ./configure; make check; examples/newbase60.w 123 If it prints 23 (123 in NewBase60), your wisp is fully operational. That’s it - have fun with wisp syntax! Update (2017-03-18): I removed the link to Gozala’s wisp, because it was put in maintenance mode. Quite the opposite of Guile which is taking up speed and just released Guile version 2.2.0, fully compatible with wisp (though wisp helped to find and fix one compiler bug, which is something I’m really happy about ☺). Update (2017-02-05): Allan C. Webber presented my talk Natural script writing with Guile in the Guile devroom at FOSDEM. The talk was awesome — and recorded! Enjoy Natural script writing with Guile by "pretend Arne" ☺ presentation (pdf, 16 slides) and its source (org). Have fun with wisp syntax! Update (2016-07-12): wisp v0.9.1 released with a fix for multiline strings and many additional examples. For more info, see the NEWS file. To test it, install Guile 2.0.11 or later and bootstrap wisp: wget https://bitbucket.org/ArneBab/wisp/downloads/wisp-0.9.1.tar.gz; tar xf wisp-0.9.1.tar.gz ; cd wisp-0.9.1/; ./configure; make check; examples/newbase60.w 123 If it prints 23 (123 in NewBase60), your wisp is fully operational. That’s it - have fun with wisp syntax! Update (2016-01-30): I presented Wisp in the Guile devroom at FOSDEM. The reception was unexpectedly positive — given some of the backlash the readable project got I expected an exceptionally sceptical audience, but people rather asked about ways to put Wisp to good use, for example in templates, whether it works in the REPL (yes, it does) and whether it could help people start into Scheme. The atmosphere in the Guile devroom was very constructive and friendly during all talks, and I’m happy I could meet the Hackers there in person. I’m definitely taking good memories with me. Sadly the video did not make it, but the schedule-page includes the presentation (pdf, 10 slides) and its source (org). Have fun with wisp syntax! Update (2016-01-04): Wisp is available in GNU Guix! Thanks to the package from Christopher Webber you can try Wisp easily on top of any distribution: guix package -i guile guile-wispguile --language=wisp This already gives you Wisp at the REPL (take care to follow all instructions for installing Guix on top of another distro, especially the locales). Have fun with wisp syntax! Update (2015-10-01): wisp v0.9.0 released which no longer depends on Python for bootstrapping releases (but ./configure still asks for it — a fix for another day). And thanks to Christopher Webber there is now a patch to install wisp within GNU Guix. For more info, see the NEWS file. To test it, install Guile 2.0.11 or later and bootstrap wisp: wget https://bitbucket.org/ArneBab/wisp/downloads/wisp-0.9.0.tar.gz; tar xf wisp-0.9.0.tar.gz ; cd wisp-0.9.0/; ./configure; make check; examples/newbase60.w 123 If it prints 23 (123 in NewBase60), your wisp is fully operational. That’s it - have fun with wisp syntax! Update (2015-09-12): wisp v0.8.6 released with fixed macros in interpreted code, chunking by top-level forms, : . parsed as nothing, ending chunks with a trailing period, updated example evolve and added examples newbase60, cli, cholesky decomposition, closure and hoist in loop. For more info, see the NEWS file.To test it, install Guile 2.0.x or 2.2.x and Python 3 and bootstrap wisp: wget https://bitbucket.org/ArneBab/wisp/downloads/wisp-0.8.6.tar.gz; tar xf wisp-0.8.6.tar.gz ; cd wisp-0.8.6/; ./configure; make check; examples/newbase60.w 123 If it prints 23 (123 in NewBase60), your wisp is fully operational. That’s it - have fun with wisp syntax! And a happy time together for the ones who merge their paths today ☺ Update (2015-04-10): wisp v0.8.3 released with line information in backtraces. For more info, see the NEWS file.To test it, install Guile 2.0.x or 2.2.x and Python 3 and bootstrap wisp: wget https://bitbucket.org/ArneBab/wisp/downloads/wisp-0.8.3.tar.gz; tar xf wisp-0.8.3.tar.gz ; cd wisp-0.8.3/; ./configure; make check; guile -L . --language=wisp tests/factorial.w; echo If it prints 120120 (two times 120, the factorial of 5), your wisp is fully operational. That’s it - have fun with wisp syntax! Update (2015-03-18): wisp v0.8.2 released with reader bugfixes, new examples and an updated draft for SRFI 119 (wisp). For more info, see the NEWS file.To test it, install Guile 2.0.x or 2.2.x and Python 3 and bootstrap wisp: wget https://bitbucket.org/ArneBab/wisp/downloads/wisp-0.8.2.tar.gz; tar xf wisp-0.8.2.tar.gz ; cd wisp-0.8.2/; ./configure; make check; guile -L . --language=wisp tests/factorial.w; echo If it prints 120120 (two times 120, the factorial of 5), your wisp is fully operational. That’s it - have fun with wisp syntax! Update (2015-02-03): The wisp SRFI just got into draft state: SRFI-119 — on its way to an official Scheme Request For Implementation! Update (2014-11-19): wisp v0.8.1 released with reader bugfixes. To test it, install Guile 2.0.x and Python 3 and bootstrap wisp: wget https://bitbucket.org/ArneBab/wisp/downloads/wisp-0.8.1.tar.gz; tar xf wisp-0.8.1.tar.gz ; cd wisp-0.8.1/; ./configure; make check; guile -L . --language=wisp tests/factorial.w; echo If it prints 120120 (two times 120, the factorial of 5), your wisp is fully operational. That’s it - have fun with wisp syntax! Update (2014-11-06): wisp v0.8.0 released! The new parser now passes the testsuite and wisp files can be executed directly. For more details, see the NEWS file. To test it, install Guile 2.0.x and bootstrap wisp: wget https://bitbucket.org/ArneBab/wisp/downloads/wisp-0.8.0.tar.gz; tar xf wisp-0.8.0.tar.gz ; cd wisp-0.8.0/; ./configure; make check; guile -L . --language=wisp tests/factorial.w; echo If it prints 120120 (two times 120, the factorial of 5), your wisp is fully operational. That’s it - have fun with wisp syntax! On a personal note: It’s mindboggling that I could get this far! This is actually a fully bootstrapped indentation sensitive programming language with all the power of Scheme underneath, and it’s a one-person when-my-wife-and-children-sleep sideproject. The extensibility of Guile is awesome! Update (2014-10-17): wisp v0.6.6 has a new implementation of the parser which now uses the scheme read function. wisp-scheme.w parses directly to a scheme syntax-tree instead of a scheme file to be more suitable to an SRFI. For more details, see the NEWS file. To test it, install Guile 2.0.x and bootstrap wisp: wget https://bitbucket.org/ArneBab/wisp/downloads/wisp-0.6.6.tar.gz; tar xf wisp-0.6.6.tar.gz; cd wisp-0.6.6; ./configure; make; guile -L . --language=wisp That’s it - have fun with wisp syntax at the REPL! Caveat: It does not support the ' prefix yet (syntax point 4). Update (2014-01-04): Resolved the name-clash together with Steve Purcell und Kris Jenkins: the javascript wisp-mode was renamed to wispjs-mode and wisp.el is called wisp-mode 0.1.5 again. It provides syntax highlighting for Emacs and minimal indentation support via tab. You can install it with M-x package-install wisp-mode Update (2014-01-03): wisp-mode.el was renamed to wisp 0.1.4 to avoid a name clash with wisp-mode for the javascript-based wisp. Update (2013-09-13): Wisp now has a REPL! Thanks go to GNU Guile and especially Mark Weaver, who guided me through the process (along with nalaginrut who answered my first clueless questions…). To test the REPL, get the current code snapshot, unpack it, run ./bootstrap.sh, start guile with $ guile -L . (requires guile 2.x) and enter ,language wisp.
Example usage:
display "Hello World!\n"
then hit enter thrice.
Voilà, you have wisp at the REPL!
Caveeat: the wisp-parser is still experimental and contains known bugs. Use it for testing, but please do not rely on it for important stuff, yet.
Update (2013-09-10): wisp-guile.w can now parse itself! Bootstrapping: The magical feeling of seeing a language (dialect) grow up to live by itself: python3 wisp.py wisp-guile.w > 1 && guile 1 wisp-guile.w > 2 && guile 2 wisp-guile.w > 3 && diff 2 3. Starting today, wisp is implemented in wisp.
Update (2013-08-08): Wisp 0.3.1 released (Changelog).

Intro

I recently started looking into Autotools, to make it easier to run my code on multiple platforms.

Naturally you can use cmake or scons or waf or ninja or tup, all of which are interesting in there own respect. But none of them has seen the amount of testing which went into autotools, and none of them have the amount of tweaks needed to support about every system under the sun. And I recently found pyconfigure which allows using autotools with python and offers detection of library features.

Warning 2016: Contains some cargo-cult-programming — my current setup is cleaner thanks to using AC_CONFIG_LINKS in configure.ac.

Tail Call Optimization (TCO), dependency, broken debug builds in C and C++ — and gcc 4.8

TCO: Reducing the algorithmic complexity of recursion.
Debug without TCO: Obliterate any possibility of fixing recursion bugs.

“Never develop with optimizations which the debug mode of the compiler of the future maintainer of your code does not use.”°

UPDATE: GCC 4.8 gives us -Og -foptimize-sibling-calls which generates nice-backtraces, and I had a few quite embarrassing errors in my C - thanks to AKF for the catch!

1 Intro

Tail Call Optimization (TCO) makes this

def foo(n):
print(n)
return foo(n+1)
foo(1)


behave like this

def foo(n):
print(n)
return n+1
n = 1
while True:
n = foo(n)


1 Rationale

PDF-version (for printing)

orgmode-version (for editing)

repository (for forking)

Currently I rework my code extensively before I push it into upstream SVN. Some of that is inconvenient and it would be nicer to have easy to use refactoring tools.

hg evolve might offer that.

This test uses the mutable-hg extension in revision c70a1091e0d8 (24 changesets after 2.1.0). It will likely be obsolete, soon, since mutable-hg is currently moved into Mercurial core by Pierre-Yves David, its main developer. I hope it will be useful for you, to assess the future possibilities of Mercurial today. This is not (only) a pun on “obsolete”, the functionality at the core of evolve which allows safe, collaborative history rewriting ☺

The dynamics of free culture and the danger of noncommercial clauses

NC covered works trick people into investing in a dead end

Free licensing lowers the barrier of entry to creating cultural works, which unlocks a dynamic where people can realize their ideas much easier - and where culture can actually live, creating memes, adjusting them to new situations and using new approaches with old topics.

But for that to really take off, people have to be able to make a living from their creations - which build on other works.

Motivation and Reward

Debunking the myth that you can increase the performance of creative workers with carrot and stick.

Update: Good fixed income and long term contracts are a tool to allow people to work full-time without reducing their motivation. They avoid the harmful effect performance-based payment can have on performance while enabling people to work full-time on a project. An empirical study found, that the source and intensity of motivation of free software developers does not differ significantly between people who work for hire and people who work without payment, so many companies employing free software developers seem to do it right (or only the companies who do it right can keep their free software programmers).1

Executive Summary

For creative tasks, the quality of performance strongly correllates with intrinsic motivation: Being interested in the task itself.

The main factors which are commonly associated with intrinsic motivation are:

• Positive verbal feedback which increases intrinsic motivation.
• Payment independent of performance which actually has no effect.
• Payment dependent on performance which reduces the motivation on the long term.
• Negative verbal feedback which directly reduces intrinsic motivation.
• Threatening someone with punishment which strongly reduces intrinsic motivation.

To make it short: Anything which diverts the focus from the task at hand towards some external matter (either positive or negative) reduces the intrinsic motivation and that in turn reduces work performance.

If you want to help people perform well, make sure that they don’t have to worry about other stuff besides their work and give them positive verbal feedback about the work they do.

Note: In the paper »Why Hackers Do What They Do: Understanding Motivation and Effort in Free/Open Source Software Projects« from 2005, Karim R. Lakhani and Robert G Wolf showed empirically that the payment people get to work in free software projects has no detrimental effect on their intrinsic motivation. In their sample 40% of the developers were paid for their work on free software projects and their intrinsic motivation was as high as the motivation of unpaid developers.

1. We find […], that enjoyment-based intrinsic motivation, namely how creative a person feels when working on the project, is the strongest and most pervasive driver. The source and intensity of motivation of free software developers does not differ significantly between people who work for hire and people who work without payment. From Why Hackers Do What They Do: Understanding Motivation and Effort in Free/Open Source Software Projects by Karim R. Lakhani* and Robert G Wolf** from the * MIT Sloan School of Management | The Boston Consulting Group and ** The Boston Consulting Group.

Neither Humble nor Indie Bundle

Update 2016: Later Bundles seem to have gotten better again.

Comment to New Humble Bundle Is Windows Only, DRM Games.

The new Humble Indie Bundle is no longer free, indie, cross-plattform or user-respecting.

When the first bundle had a huge boost in last-minute sales after the devs offered to free the source of 4 of the 5 games, I had hoped, they would keep that.

How to make companies act ethically

→ comment on Slashdot concerning Unexpected methods to promote freedom?

Was it really Apple who ended DRM? Would they have done so without the protests and evangelizing against DRM? Without protesters in front of Apple Stores? And without the many people telling their friends to just not accept DRM?

That “preaching” created a situation where Apple could reap monetary gain from doing the right thing.

Insert a scaled screenshot in emacs org-mode

@marjoleink asked on identi.ca1, if it is possible to use emacs org-mode for showing scaled screenshots inline while writing. Since I thought I’d enjoy some hacking, I decided to take the challenge.

It does not do auto-scaling of embedded images, as far as I know, but the use case of screenshots can be done with a simple function (add this to your ~/.emacs or ~/.emacs.d/init.el):

1. Matthew Gregg: @marjoleink "way of life" thing again, but if you can invest some time, org-mode is a really powerful note keeping environment. → Marjolein Katsma: @mcg I'm sure it is - but seriously: can you embed a diagram2 or screenshot, scale it, and link it to itself?

2. For diagrams, you can just insert a link to the image file without description, then org-mode can show it inline. To get an even nicer user-experience (plain text diagrams or ascii-art), you can use inline code via org-babel using graphviz (dot) or ditaa - the latter is used for the diagrams in my complete Mercurial branching strategy

Sending email to many people with Emacs Wanderlust

I recently needed to send an email to many people1.

Putting all of them into the BCC field did not work (mail rejected by provider) and when I split it into 2 emails, many did not see my mail because it was flagged as potential spam (they were not in the To-Field)2.

I did not want to put them all into the To-Field, because that would have spread their email-addresses around, which many would not want3.

So I needed a different solution. Which I found in the extensibility of emacs and wanderlust4. It now carries the name wl-draft-send-to-multiple-receivers-from-buffer.

You simply write the email as usual via wl-draft, then put all email addresses you want write to into a buffer and call M-x wl-draft-send-to-multiple-receivers-from-buffer. It asks you about the buffer with email addresses, then shows you all addresses and asks for confirmation.

Then it sends one email after the other, with a randomized wait of 0-10 seconds between messages to avoid flagging as spam.

If you want to use it, just add the following to your .emacs:

(defun wl-draft-clean-mail-address (address)
(progn
(let ((wl-interactive-send nil))
(wl-draft-send))
(sleep-for (random 10)))))
"Send a mail to multiple recipients - one recipient at a time"
(interactive "BBuffer with one address per line")
(if (y-or-n-p (concat "Send this mail to "


Happy Hacking!

1. The email was about the birth of my second child, and I wanted to inform all people I care about (of whom I have the email address), which amounted to 220 recipients.

2. Naturally this technique could be used for real spamming, but to be frank: People who send spam won’t need it. They will already have much more sophisticated methods. This little trick just reduces the inconvenience brought upon us by the measures which are necessary due to spam. Otherwise I could just send a mail with 1000 receivers in the BCC field - which is how it should be.

4. Sure, there are also template mails and all such, but learning to use these would consume just as much time as extending emacs - and would be much less flexible: Should I need other ways to transform my mails, I’ll be able to just reuse my code.

Intro

When you enter the freenet Web of Trust, you first need to get some trust from people by solving captchas. And even when people trust you somehow, you have no way to prove your identity in an automatic way, so you can’t create identities which freenet can label as trusted without manual intervention from your side.

Proposal

To change this, we can use the Web of Trust used in GnuPG to infer trust relationships between freenet WoT IDs.

Practically that means:

• Write a message: “I am the WoT ID USK@” (replace with the

The problem

Nature only gives me ris-formatted citations, but I use bibtex.

Also ris is far from human readable.

The background

ris can be reformatted to bibtext, but doing that manually disturbs my workflow when getting references while taking note about a paper in emacs.

I tend to search online for references, often just using google scholar, so when I find a ris reference, the first data I get for the ris-citation is a link.

Emacs

Cross platform, Free Software, almost all features you can think of, graphical and in the shell: Learn once, use for everything.

Emacs is a self-documenting, extensible editor, a development environment and a platform for lisp-programs - for example programs to make programming easier, but also for todo-lists on steroids, reading email, posting to identi.ca, and a host of other stuff (learn lisp).

It is one of the origins of GNU and free software (Emacs History).

In Markdown-mode it looks like this:

A complete Mercurial branching strategy

This is a complete collaboration model for Mercurial. It shows you all the actions you may need to take, except for the basics already found in other tutorials like

Adaptions optimize the model for special needs like maintaining multiple releases1, grafting micro-releases and an explicit code review stage.

Summary: 3 simple rules

Any model to be used by people should consist of simple, consistent rules. Programming is complex enough without having to worry about elaborate branching directives. Therefore this model boils down to 3 simple rules:

3 simple rules:

(1) you do all the work on default2 - except for hotfixes.

(2) on stable you only do hotfixes, merges for release3 and tagging for release. Only maintainers4 touch stable.

(3) you can use arbitrary feature-branches5, as long as you don’t call them default or stable. They always start at default (since you do all the work on default).

Diagram

To visualize the structure, here’s a 3-tiered diagram. To the left are the actions of programmers (commits and feature branches) and in the center the tasks for maintainers (release and hotfix). The users to the right just use the stable branch.6

An overview of the branching strategy. Click the image to get the emacs org-mode ditaa-source.

Practial Actions

Now we can look at all the actions you will ever need to do in this model:7

• Regular development

• commit changes: (edit); hg ci -m "message"

• continue development after a release: hg update; (edit); hg ci -m "message"

• Feature Branches

• start a larger feature: hg branch feature-x; (edit); hg ci -m "message"

• continue with the feature: hg update feature-x; (edit); hg ci -m "message"

• merge the feature: hg update default; hg merge feature-x; hg ci -m "merged feature x into default"

• close and merge the feature when you are done: hg update feature-x; hg ci --close-branch -m "finished feature x"; hg update default; hg merge feature-x; hg ci -m "merged finished feature x into default"

• Initialize (only needed once)

• create the repo: hg init reponame; cd reponame

• first commit: (edit); hg ci -m "message"

• create the stable branch and do the first release: hg branch stable; hg tag tagname; hg up default; hg merge stable; hg ci -m "merge stable into default: ready for more development"

• apply a hotfix8: hg up stable; (edit); hg ci -m "message"; hg up default; hg merge stable; hg ci -m "merge stable into default: ready for more development"

• do a release9: hg up stable; hg merge default; hg ci -m "(description of the main changes since the last release)" ; hg tag tagname; hg up default ; hg merge stable ; hg ci -m "merged stable into default: ready for more development"

That’s it. All that follows are a detailed example which goes through all actions one-by-one, adaptions to this workflow and the final summary.

1. if you need to maintain multiple very different releases simultanously, see or 10 for adaptions

2. default is the default branch. That’s the named branch you use when you don’t explicitely set a branch. Its alias is the empty string, so if no branch is shown in the log (hg log), you’re on the default branch. Thanks to John for asking!

3. If you want to release the changes from default in smaller chunks, you can also graft specific changes into a release preparation branch and merge that instead of directly merging default into stable. This can be useful to get real-life testing of the distinct parts. For details see the extension Graft changes into micro-releases

4. Maintainers are those who do releases, while they do a release. At any other time, they follow the same patterns as everyone else. If the release tasks seem a bit long, keep in mind that you only need them when you do the release. Their goal is to make regular development as easy as possible, so you can tell your non-releasing colleagues “just work on default and everything will be fine”.

5. This model does not use bookmarks, because they don’t offer benefits which outweight the cost of introducing another concept: If you use bookmarks for differenciating lines of development, you have to define the canonical revision to clone by setting the @ bookmark. For local work and small features, bookmarks can be used quite well, though, and since this model does not define their use, it also does not limit it.
Additionally bookmarks could be useful for feature branches, if you use many of them (in that case reusing names is a real danger and not just a rare annoyance) or if you use release branches:
“What are people working on right now?” → hg bookmarks
“Which lines of development do we have in the project?” → hg branches

6. Those users who want external verification can restrict themselves to the tagged releases - potentially GPG signed by trusted 3rd-party reviewers. GPG signatures are treated like hotfixes: reviewers sign on stable (via hg sign without options) and merge into default. Signing directly on stable reduces the possibility of signing the wrong revision.

7. hg pull and hg push to transfer changes and hg merge when you have multiple heads on one branch are implied in the actions: you can use any kind of repository structure and synchronization scheme. The practical actions only assume that you synchronize your repositories with the other contributors at some point.

8. Here a hotfix is defined as a fix which must be applied quickly out-of-order, for example to fix a security hole. It prompts a bugfix-release which only contains already stable and tested changes plus the hotfix.

9. If your project needs a certain release preparation phase (like translations), then you can simply assign a task branch. Instead of merging to stable, you merge to the task branch, and once the task is done, you merge the task branch to stable. An Example: Assume that you need to update translations before you release anything. (next part: init: you only need this once) When you want to do the first release which needs to be translated, you update to the revision from which you want to make the release and create the “translation” branch: hg update default; hg branch translation; hg commit -m "prepared the translation branch". All translators now update to the translation branch and do the translations. Then you merge it into stable: hg update stable; hg merge translation; hg ci -m "merged translated source for release". After the release you merge stable back into default as usual. (regular releases) If you want to start translating the next time, you just merge the revision to release into the translation branch: hg update translation; hg merge default; hg commit -m "prepared translation branch". Afterwards you merge “translation” into stable and proceed as usual.

10. If you want to adapt the model to multiple very distinct releases, simply add multiple release-branches (i.e. release-x). Then hg graft the changes you want to use from default or stable into the releases and merge the releases into stable to ensure that the relationship of their changes to current changes is clear, recorded and will be applied automatically by Mercurial in future merges11. If you use multiple tagged releases, you need to merge the releases into each other in order - starting from the oldest and finishing by merging the most recent one into stable - to record the same information as with release branches. Additionally it is considered impolite to other developers to keep multiple heads in one branch, because with multiple heads other developers do not know the canonical tip of the branch which they should use to make their changes - or in case of stable, which head they should merge to for preparing the next release. That’s why you are likely better off creating a branch per release, if you want to maintain many very different releases for a long time. If you only use tags on stable for releases, you need one merge per maintained release to create a bugfix version of one old release. By adding release branches, you reduce that overhead to one single merge to stable per affected release by stating clearly, that changes to old versions should never affect new versions, except if those changes are explicitely merged into the new versions. If the bugfix affects all releases, release branches require two times as many actions as tagged releases, though: You need to graft the bugfix into every release and merge the release into stable.12

11. If for example you want to ignore that change to an old release for new releases, you simply merge the old release into stable and use hg revert --all -r stable before committing the merge.

12. A rule of thumb for deciding between tagged releases and release branches is: If you only have a few releases you maintain at the same time, use tagged releases. If you expect that most bugfixes will apply to all releases, starting with some old release, just use tagged releases. If bugfixes will only apply to one release and the current development, use tagged releases and merge hotfixes only to stable. If most bugfixes will only apply to one release and not to the current development, use release branches.

Willkommen im Weltenwald!
((λ()'Dr.ArneBab))