At the end of January, I went to my second FOSDEM; I went a few years ago, then for the intervening years, various things intervened, although I would have liked to have gone; this year, everything was clear for me to go.

The event was very well-attended, and covered a wide range of topics, with software itself at the centre but spreading to cover both intellectual property law and open-source hardware.

Notes taken during the event

My remarks added in italics.

No legacy (IPv4) connectivity, should work for everything except Android phones.
except for FOSDEM-legacy

Livestreaming available as rooms may be full, and everything is recorded and mostly livestreamed.


Keynote: Are we who we say we are? (Karen Sandler)

Was an engineer before she was a lawyer; pro bono counsel for various open software organizations.

Thinking about representing someone (as a lawyer). Legal ethics for free software, very different from what lawyers from other backgrounds expect, e.g. openness instead of confidentiality.

We say “we” a lot, meaning a lot of different things (even in the same sentence), so who is the lawyer’s client? Employees of companies in open source can have multiple affiliations. Charities and trade associations are different. Some open source conferences are run by trade associations; FOSDEM limits what sponsors can do. Companies co-opt “making the world better by…” “Open source” on IRS application scrutiny watchlist! Our own perception of what is a FLOSS community is varied. Why do people contribute to ubuntu (thus sublicensing to Canonical)? “This is where my friends are”. People can move jobs while on the same project, and it can be unclear when they’re in a professional context. Conservancy publishes everything e.g. travel policies.

Trademarks are identity, and messaging from a particular source. Example: public support for getting Groupon to stop using the name Gnome for a product. That may have needed the gnome foundation to coordinate it.

c-mera: lisp syntax for c

Pretty obvious; just about time someone got round to it. Lisp-style macros would be nice in all languages.

Introduction to freeRTOS

Small useful programs in emacs-lisp

A good way of getting people programming?

Some example programs (talk wasn’t very good, and someone disrupted it a bit)

Upstreaming and downstreaming

Running Linux on Android devices(extremely well-attended)

By David Greaves.

mer, sailfish (focussing on its open parts), jolla, inherited from maemo.

Sailfish for android-focused devices.

The technology: mer is the core of sailfish, opening up the code of the core distribution (about 400 packages, no applications) Trying to make it easy for manufacturers to build devices, not aimed at end-user hacking. Qt: not java! QML is good: declarative design. Qt has become quite big, but is modular.

Mersk is a chroot running Mer under any distro, plus some tools.

Android has binary blobs, and we have to route around the breakage, while hoping for better open hardware. Pressure on manufacturers does work eventually. Shim between glibc and bionic libc: libhybris enables use of glibc on top of Android BSP.

Andriod linker code: dlopen, dlsym, dfclose: renamed to android_dlopen etc, and can then run Linux and Android in the same address space. Some patches to bionic, e..g. threaded local storage.

Working alongside cyanogen mod where available. HADK. Minimal Ubuntu provided.

Install habuild and repo inside the chroot, download a repo to build.

There’s a manifest defining what to build. Then need to build hybris and the drivers. Then make a filesystem image that you can put onto the device, using adb.

You can write error messages into the device serial number, for retrieving adb debugging.

Runs emacs 🙂

About 25 active developers. Devices include N900. port-devices-status

Multirom (multiboot).

Core and some MW is there.

Put on watches too?

Code is not enough.

Jolla discount code FOSDEM2015 will work to 8th feb

CHDK: Canon Hack Development Kit

By Steven Goodwin.

Can use cheap second-hand cameras, which may be more capable than the manufacturers’ software makes available.

Aimed at the cheap point and shoot cameras on most DIGIC chipsets. It’s a temporary upgrade: augments existing firmware (does not touch ROM firmware) and respects hardware limits, adds functionality such as scripting, increases control of existing parameters (can effectively upgrade to a more expensive model in the range) e.g. exposure, flash power, adds controllable elements such as grids, add export as raw.

Compatibility test with /mount/sdcardroot/ver.req put in the camera and put in playback mode; or various tools. The chipset doesn’t change as often as the other parts of a camera range.

Stick tool looks at a jpeg from the camera to decide what it is. Cross-compilation: ARM compiler.

Copy onto SD card and boot the camera. Firmware update; tells it to run things from card memory. SD card lock switch tells the camera to do an update, and then ignores the switch as it’s advisory.

Everything is in ALT mode gives an extra OSD with different menu. Exposes all parameters.

Scripting: load the script, set the parameters, shoot. Meta-code at start of script says which parameters to expose. Has BASIC and Lua interpreters. Motion detection. Scripts can simulate buttons.

Grids: overlay on the display drawn with drawing commands; can make custom ones such as for passport photo alignment. Can put a hard-to-remove “this camera is stolen” display on it!

Writing modules. People write games on them, too: base it on the snake game that comes with it. Mandelbrot generator!

Debug: can use LED (via memory location). Can crash it and use romlog (will need a map). ShowCameraLog, Printf, LogPrintf.

(Really bizarrely, the guy next to me seems to be copying what’s on my screen rather than making his own notes.)

Tool called Dagger for debugging, intercepts ???

Motion detection hacks: has parameters to say how much of scene has to change, how much dynamic range must change, etc.

Can make your own shutter release cable this way, using the USB connection.

You can make a bullet time rig, triggering many cameras in sync, e.g. simultaneous elements for a panorama.

Kite aerial photography. HAB (with a GPS phone too so you can find it again).

The emacs of distributions: Guix

See Stallman 1981: When large numbers of non-technical workers are using a programmable editor, they will be tempted constantly to begin programming in the course of their day-to-day lives. This should contribute greatly to computer literacy.

What are the barriers to distribution hacking?
– packaging, ability to extend
– package management tools
– esoteric configuration
– implementation language barriers

$ guix package -i guile
You don’t need to be root to do it
$ guix package -i guile-1.8.8 python
tells you about environment variables you may need to set
$ guix package –roll-back
$ guix package –list-installed
There is an emacs mode to do this for you; it gives access to the package profile from the package list, and to the source code from the package profile. You can make generations of a package, and ask for diffs between them. Uses geyser to talk to guile underneath to get docstrings etc.

Packages can inherit to add, remove, and replace parts.

Package recipes are in declarative scheme. # constructs in it are deferred until run time. guix can be set to build locally instead of pulling central builds. No single point of trust.

Reproducible builds: guix build will store the hash of all the dependencies. Binaries should be nearly identical bitwise. Builds are done in chroots with separate UIDs. The build daemon creates these, with guile inside them and the interface in emacs talks to the daemon.

There is also a web interface.

A similar approach to OS configuration, using declarative scheme to define things like which file systems are mounted by default, what services are to be run, etc. Produces a directory which is effectively a closure. Likewise for virtual machines, which you can start with the defined operating systems on them.

initrd has guile in it, as does PID 1 (dmd).

Installable available from 2014-07

Now ported to ARM v7

Recognized at FSF ? compliant.

Dogfood: 1200 packages, 4 platforms Guix System Distribution is standalone, binaries at


l10n into 8 languages.

Quite active: 2448 commits from 36 contributors.

Porting Emacs to Chromebooks and the web (Pete Williamson, from the Google Chrome team)

Why? Chromebooks are selling very well, and he did it as a 20% project.

NaCl (Native Client) is a project to compile chrome webapps to run in sandboxes.

The web emacs is a chrome web app wrapping Emacs. Chrome apps are downloaded absolutely, so can be used offline.

They download emacs from fsf, apply a patch, configure, build temacs.nexe then run that in a emulator on the parent linux environment to complete the build. Not yet building the elisp inside it, but including it as a compressed directory, which was already allowed for in emacs.

NaCl uses a partial glibc. Found some bugs in emacs and its makefiles (which are quite advanced). Choice between implementations. PiNaCl uses LLVM code and JITs after download.

You can use gdb with NaCl. Debugging Lisp without the display is harder.

Various small things needed fixing, including some temporary hacks such as saying all files are executable and writable.

Emacs has been ported to so many systems that the makefiles already have many workrounds for things.

Demo of various things (not all working yet). Still some things to do; pipes not provided by NaCl. Want to be able to mount cloud drives to chrome. Want to build as a web page too, so you can run real emacs on a web site. Want to upstream back to FSF.

Software patents

Cannot patent vague things.

Extending Python

By Francisco Fernandez Castano.

Writing native code to work with python. Why write in C? Binding libraries, for example; or for speed, or connecting up legacy code in other languages, or integrating python as a scripting language for another program.

C API to python: PyObject type. PyArg_ParseTuple to get arguments. Py_BuildValue to construct something e.g. to return. Define a module to put your functions in.

distutils module provides a setup function. dlopen in C to load shared libraries.

Manage memory manually, use reference counting macros. To throw an exception, register it and return NULL. Some differences between Python 2 and Python 3.

CTypes is an advanced FFI for Python; allowing Python to describe C structs and convert things to C to use.

CFFI is another advanced FFI. Gives API and ABI access. Recommended by PyPy. Give it fragments of C declarations as strings. Can also put the C functions in as strings, and CFFI will compile it for us.

Three ways, same principles, varying in portability and ease of use.

In Q&A: mentioned SWIG

PyPy and the future of the Python ecosystem

By Romain Guillebert.

How can we get better implementations, without throwing away language features and libraries?

CPython is most popular, but has poor performance, and cannot use multiple cores in a single process. PyPy has a smaller marketshare but better performance. Other implementations are almost unused. Comparing with other languages: Go is quite fast and great at concurrency; JavaScript is pretty fast, even PHP is quite fast these days. So we have no excuse. C extensions make it hard to switch implementations and so Python can’t evolve because of them: a lock-in. More competition between implementations would benefit everyone, particularly users. Libraries use more than the official API; official API makes assumptions on how the virtual machine is written; the C API is against performance and concurrency, e.g. reference counting.

C APIs in other languages: JNI/V8 and Lua/Julia. We could learn from them. Can we implement something similar? Yes! Designing it to make everyone happy is harder than implementing it.

PyPy is the most flexible implementation, and is written in RPython. 6.9 x faster than CPython. Competes against other fast languages. JIT: Pay the cost of what you use (e.g. introspection).

STM: working on removing the GIL without having to deal with threads and locks.

Short term extension support.

We can do better than we are. PyPy is working on it. Making an alternative, portability-friendly, extension ecosystem would be hard but worthwhile.

Python lightning talks

eGenix pyrun

python runtime environment in a single file, with easy installation by a shell script.

ZeroServices: micro-services f***ing easy

Starting a project: the API debate; the missing debate.
Example in 33 lines of python!

Skink (like a snake with legs)

Web developer wall between server and browser.
Some approaches: brython, nodewebkit, pythonium, websockets…
Aim for simplicity. Would like callbacks.
Generates JS on the fly.


for building and installing scientific software
e.g. “Please install QIIME” which has a mass of dependencies, and is picky about versions. Can now install that on an HPC cluster with a single command.


for seeing what software is actually being used.
It hijacks the linker and mpirun.


Supporting accessibility in your distribution

Don’t focus on one technology.

Why not just use text? Some applications assume graphics, e.g. real javascript support; non-technical people don’t like text applications and there are fewer people they can ask for help.

edbrowse, a blind-oriented editor/browser etc are generally a bad idea — too specialized and limited manpower, and compatibility problems. Better to make existing applications accessible.

Synchronized work between sighted and blind people, rather than separate views. Should be pervasive without having to ask for installation.

Status of FLOSS: text mode is quite accessible but not suited to beginners. Gnome is quite accessible, some stick to Gnome 2. Late compared with Windows, stone age compared with Apple which has integrated screen reading.

Generic methodology: connect abstract representation part of app to accessibility bus as well as to visual rendering. For example, for gedit, the representation is in GTK, which communicates with Orca. This shows the logical structure of the application. So technically speaking, a lot of applications are accessible: console, GTK, KDE/Qt4/5 soon, Acrobat reader. KDE Qt3 and xt and self-drawn are generally not accessible. evince may have improved recently.

Text applications usually work well for braille; always provide such equivalent of graphics, also useful for ssh to servers. Putting the cursor in the right place is useful. Keep it simple, making it easier for screen readers and everyone else. Use standard widgets.

This is all about Freedom #0, Stallman only mentioned a11y as just a “desirable feature” and assumed people could modify the program (not realistic). Vint Cerf asked “why is accessibility so hard?” Issues are social more than technical. Should be prioritized, like i18n has been for a while. Who is doing it? Concerns only a small fraction of the population; almost no-one in that community, or aware of it, also has the programming skills. So support has to be integrated into the main software.

Should not be specialized distributions; it should be orthogonal to everything else. Specialized distributions tend to be too specialized, too. Such distros can be interesting testbeds, but things should then be pushed to the mainstream.

Graal: accessibility everywhere, installed by default. Requires close integration, e.g. in debian installer.

Please keep text-based distributions. Please keep packaging text equivalents, such as ogg123. Accessibility packages: Brltty, at-spi, orca, speech synthesis, magnification etc. Test it. /dev/vcsa, TIOCSTI, uinput should be included. at-spi-bus-launcher, at-spi2-registryd must be running as the proper user “dm” then the actually user. check the bus with dbus-send –session –dest-org.a11y.Bus –print-reply /org/a11y….

It needs to be enabled: no standard shortcut for this. Also install various other bits such as gtk frontend for libreoffice, xbrlapi to simulate keypresses from the braille keyboard, java-atk-wrapper but doesn’t work with multi-threading yet. If you have 32-bit applications on a 64-bit system, you need 32-bit a11y libraries etc.

Bootstrapping e.g. entering a cybercafe: usb braille device; shortcuts to start synthesis should be standardized; accessibility panel must be accessible. It should be installed by default (e.g. library computers). GPII project aims at a device that will indicate to a connected/nearby computer that a11y is needed, e.g. a usb key with a file that indicates using speech synthesis with certain settings.

New computer, let’s install linux… all debian forks should inherit a11y in the installer. Installer todo details on The installed system should inherit the a11y characteristics used in the installer. Qemu has a virtual braille device, useful for testing. What about the bootloader? Not good so far.

About bugs: take users’ suggestions in, maybe as an option, e.g. bracketed links in text browsers. Be patient, blind users may describe the application in different terms e.g. “braille doesn’t follow” means the application hasn’t left the cursor in the right place; and may not mention visual symptoms of bugs. Discussions: separate mailing lists will mean that mainstream maintainers will not be aware.

Remember blind people want to re-install their system at 2 a.m. too!

OpenStack infrastructure tools you will want to borrow

Openstack is a collection of open components for building infrastructure for a cloud. The infrastructure team provides code review systems, continuous integration etc for the development of openstack. Two main characteristics: daily 1000 patchsets proposed, 7500 gerrit comments and votes, 16000 test jobs, 250 changes merged. All done with open tools. Everything displayed using puppet: fully automated. They also open-source their puppet configuration. This talk focuses on the tools they had to develop for it. This was largely for scalability.

Zuul: a scalable gate system. The github way (human) is not. Use automated tests to decide on merging changes. Handles cross-project dependencies. A traditional gate system is serial, testing changes on top of previous changes that have passed. Tests can take too long for this, so tests have to be done in parallel, which can’t handle regressions on previous tests. Zuul uses speculative gating. It’s still strict overall. Optimized for speed, not resources. At best, as fast as full parallel, at worst, as serial. Main problem is false negatives. Quite hard to visualize it. check, gate and post queues. It is written in python.

Backend is configurable, so can run in clusters other than OpenStack too.

Jenkins-job-builder (JJB)

Makes handling thousands of jobs easier: write YAML descriptions which are converted to XML for sending to Jenkins API. Macros and job descriptions, and job templates, in the yaml.

Jeepyb: a collection of tools for gerrit

yaml description of things
periodic tasks:
– manage-projects includes github mirroring
– close-pull-requests diverts github
– expire-old-reviews
just do a review on the control file
Commit hooks
– update-bug, update-blueprint integrates with launchpad
– notify-impact sends emails to security, docs etc
– trivial-rebase detects trivial rebase and reapplies votes

Sharpening development tools

git-review: a helper for git-gerrit remote setup
rebases on master by default
support hooks
done as “git review” i.e. just a git plugin
can compare patchsets


CLI (ncurses?) version of gerrit web frontend
email/newsgroup style workflow
can download material to review offline

Co-ordinating developers and tasks

need for cross-teams coordination
API server / webclient design
Complex priorities

The story of Rust

by Steve Klabnik from the Rust core team

Nearing the 1.0 release

Rust is a programming language, which has been in development for a long time.

Getting a bit meta first: why the story of it matters. Stories imply history, which is in epochs, defined by the predominant paradigm of the time. Totally not Marx: the history of 1.0 shipping struggles.

Four epochs:
– The personal years 2006-2010
– The Graydon years 2010-2012
– The typesystem years 2012-2014
– The release year

“It took a long time to figure out how Rust ought to work” — Niko
It’s completely different from eight years ago if you compare it by features, but exactly the same by goals.

Rust and Servo are both implemented in Rust. Have experimented with features, many of which were then thrown out. Rust has lost more features than many languages have in the first place.

Graydon’s original aim: a compiled, concurrent, safe, systems programming language. “Many older languages better than new ones. We keep forgetting already-learned lessons.” “Technology from the past come to save the future from itself.” So all the features are a little rusty.

Syntax between ML and C. Easy to parse, to tool for, and to grep. The semantics is the interesting part. Syntax is less important.
– memory safety, no wild pointers
– typestate system
– mutability control
– side-effect control
– you can break the rules if you specify where and how
– in a standard way, that’s integrated into the language
– multiparadigm
– not “everything is an object”
Four years ago, 90% of features working, 70% of runtime, 38kloc Ocaml compiler.

As the team grew, the typesystem grew, and more moved from the language to the libraries, and Graydon stepped down from the project. Now, no one person has control: eight people on the core team.

Non-typesystem things: cargo project packaging system; don’t need makefiles and autoconf. Common patterns can be built into the cargo workflow. .toml package description file, the least bad format for this. Finds and fetches headers etc.

Three camps of users:
— ex-C / C++
— ex scripting languages
— ex functional programmers
In some ways, Rust is a combination of these three things.

RFC process, inspired by Python’s PEP. Even the core team goes through this process, and everything now is logged.

Some code examples.


Gives /dev access to microcontrollers’ pins etc (I think this is for SBCs running Linux on them; might be user-space linux?), abstracts out some low-level detail; in userspace, so less fiddly.

Supports various boards.

Various APIs e.g. I2C, some via SWIG.

Concepts of pin ownership, to avoid clashes. Has contexts for keeping track of this. But can still get conflicts between processes over pins.

Showed an example.

Probably shouldn’t be trying to do bit-banging from Linux userspace!

Raw mode using GPIO numbers directly, instead of via our usual sensible translation map.

Why not use the Arduino API? Keep track of pins; support more languages; more systematic names. More like mBed API.

Extra APIs provided on top (UPM = Useful Packages from Mraa) in various languages, e.g. LCD driver. Works on top of any mraa system.
Uses C++ API to make it easier to use SWIG on top. MIT licence.

Packages provided for various distros.

High-level open and free FPGA design tools from OHR (OPEN HARDWARE REPOSITORY)

(Some lead-in talking about comparing verilog and others e.g. run time of simulation)


A place on the web for experimental physics facilities to colaborate on designs, started and maintained by CERN; not only for that community.

HDLMake a command line python program for agile management and reuse of HDL cores, defining hierarchy using python manifests
Supports synthesis of xilinx, altera, microsemi, lattice; proprietary and free/open simulation.

Some examples. Generates makefile. gtkwave used.

libre-FDATool helps anaysis of hdl filters from high level specs. Non-recurring engineering (NRE). Needs a scientific python package (original FDATool needs matlab). Integrates with simulation engines.

The simple PCIx FMC carrier, which is fully open hardware. Need several building blocks to get a whole SPEC product running: hardware, gateware, software (user libraries and device drivers).

yocto / OE projects. Python-based. Is HDL just a kind of software? We can handle it just like a linux package!

Stable, for production. Python is the glue.

Mobile map technology

MMT: The multi-platform mobile advanced visualization framework.

An open-source library. An API to build native applications for 3D visualization to run on any device.

Problems: fragmentation (particularly OS), performance (large data), usability (maps largely targeted for web use), ease of coding (easy starting to use it).

Target iOS, Android, GWT, whatever, from C++; translated to Java for Android and GWT.

Globe view, scenario, “flat”. Any kind of data. Can develop offline/online applications; real-time; cache. Camera and models animations. Utilities: tasks, HUD, tools data transformation.

Symbology: non-overlapping markers.

Vector — tiles, e.g. on open layers 3.

Point clouds: point-cloud.glob3mobile, serving only the points you need to show for your zoom level etc.

Various examples (showing good performance from Android, its lowest-performance platform).

Showing synthesized views of / below an aircraft.

Linino technology

Virtualizing MCU peripherals.

Having an MPU (big processor(s) with full OS e.g. Linux) talk to one or more MCUs (rich peripherals)). Integrate the MCU peripherals as though they were standard Linux peripherals (including interrupts). Written using OpenWRT linux distro and THOS. Arduino Yun. Can optionally drive it using javascript. Arduino shields. Interrupts.

Basic idea: poor man’s PCI: let the MPU see MCU peripherals like “local” devices. bus/device/function/offset addressing, through memory-mapped registers. Makes it look like a memory-mapped peripheral, but over any transport. Can have multiple busses and multiple devices on each bus. There is a standard memory map independent of MCU, making standardized virtual peripherals. Poor man’s PCI Function Descriptor, for plug and play. Frame size is fixed (16 bytes = size of a standard UART’s buffer). Smaller than PCI’s equivalent: 8 bytes at start give the description. Also convenient if DMA is available.

Linux implementation: the mcuio bus. (bus is a software layer, the foundation of linux device management). Allows matching drivers to devices according to some criteria. A line discpline based HC, talking over a serial port to the MCU, but it could also be a socket to some other form of communication.

Next steps: MCU support, typically uses I2C which is not plug-and-play. Shield drivers. BLE/ipv6 support, 802.15.4 support. Possibly loading programs from the MPU to the MCU for realtime work; would need more complex resource management.

Plenty still to be done, please volunteer! Code is on github.

Keynote: introducing SILE: a new typesetting system.

Written accidentally. Needed covers for books of various sizes; printing company sends a template; we’d rather do that from a simple text spec file. Blurb on the back, needs to be nicely justified. PDF2 library adjusts letter proportions to justify! TeX’s justification algorithm is 30 pages of dense 1970s Pascal. This has been translated to javascript, so he translated that into Perl; found that someone else has put TeX’s hyphenation algorithm into CPAN too. These made much better blurbs! Just need to add some more stuff from TeX e.g. the page-breaking algorithm. Note: Sile is not TeX!

Intermission about TeX. It’s older than him! When it was designed, many things we now know had not been invented, e.g. vector fonts, PostScript, PDF. Brilliant design decisions way ahead of their time. Then PS fonts and PS then PDF came along, so some changes were made in TeX. Then XeTeX to use system font library. Then luaTeX for macros. So, gradually, design decisions have been removed, although the core Pascal is still there.

Should throw each project away at least once, especially in perl. Now writing it in javascript, as some has already been written in that. Use cairo and pango, and XML (at that stage) as parsers were already available. Assumed few people write documents in text editors. Then Martin at SIL came along, on the mailing list for some software called Graphite that chooses fonts for multilingual documents. Looked for a standard format for multilingual dictionaries in XML. Then “signwriting” via unicode, by the same person. He’s in SIL typesetting team, gets the hard typesetting problems no-one else will take. Is pushing TeX beyond its limit, has written his own version.

Examples: Arabic typesetting. Unicode has not solved all the problems! harfbuzz, graphite, some versions of TeX. Each language has specific typesetting conventions, e.g. Japanese paragraphs, very different from western paragraphs (TeX can do a bit of this). Bible typesetting: produced on thin paper, so must mesh lines on the two sides of the page. ConTeXt can do this a bit. But footnotes and sidenotes are difficult too. Two columns, but with some material across both columns e.g. headings and footers… all across both sides of the page, and TeX just cannot do this: 35 years ago, you didn’t have enough memory to have more than one page in memory at once.

Then diglot and parallel Bibles… only SILE does this.

Let people look at an early version, then replaced JavaScript by Lua, and added another input handler as well as XML. Implementing things multiple times helps to separate concerns. Now uses harfbuzz and fontconfig (almost undocumented). libtexpdf, cairo, podofo output.

Frames, in which you write things, are an important concept in SILE. How do we declare frames? Use cassowary constraint solver. Drop caps are easy! Embedded programming language. People want to use their LaTeX packages… no you can’t, and that’s a feature. The macro facility is deliberately limited, to force you to write Lua code. There’s already a LuaTeX community.

The core of SILE is about 3000 lines of Lua, most of which is the justification algorithm. Much of what is in the core in TeX is in packages in SILE. You can subclass the typesetter object, overriding methods. You can have two typesetter objects on the page (for two columns) talking to each other. Examples: various multi-column Bibles, an automatically-generated Greek dictionary.

Things he learnt

When he translated from JavaScript to Lua, it was more a change of notation than a rewrite. The libraries are interesting. Lua is a good base for a really good programming language. All PDF libraries suck; TeX’s is least bad, and he’s trying to make it stand-alone. A system which can be extended in multiple dimensions cannot prevent conflict between extensions. Hacker News gets a lot if interest to the project, but only got one pull request. Avoid buses…. good community is important, he’s still important for building the community.

Technical goals

The core is largely there
– vertical typesetting
– pdf outline features
– split off libtexpdf

Many things to do in packages. Need to talk about community goals. Wants to see five packages by other people before he does another release — see github wiki.

Leihs, the leading free equipment booking system

Originally in German in the code, and used a changing platform.

Internationalize things from the start, not later!

Tried rspec, then rspec story runner, then rspec + cucumber, then just cucumber. Parallel testing took 9 hours down to 23 minutes that one of the team wrote (cider CI).

Next mistake: not having a UI person on the team. Got one later, improved things. Another mistake: building specifics into the system.

Should write a glossary defining an agreed meaning of each term you use in writing the system. Make sure management understands what free software is. Get authorization for time talking to community. For public sector: point out the taxpayers have paid for it, so should get it. Learn to say no. But first have an idea of where you want the project to go, otherwise you’re just being a jerk.

Data about your favourite community

Tracking: the Grimoire library.

Open projects produce massive data; how can we take advantage of this. Is it useful to analyze my community?

Transparency db layer for metrics grimoire. Based on grimoire output SQL ddbb) Reuse code. Developed in R, migrated to python.

Metrics: source code: commits, authors, branches, companies etc; then demographics, demographic changes, timezone; code review (gerrit, github), merges, abandons, people, time to close, etc; mailing lists: who asks, who replies, what are the longest threads, etc; Q&A e.g. stackoverflow; downloads, wiki use, etc.

Filters for the metrics. API with four methods e.g. aggregated numbers.

OpenMotics: Open source home automation

(Very well-attended.)

Integrated lighting, switching, heating and cooling per-room, power measurements, automation with sensors. Open software and hardware. Started as someone’s hobby project, open sourced two years ago as they think the integrated (expensive) and off-the-shelf systems (hard to integrate) are a broken arrangement.

All about choice: DIY: schematics and PCBs online; buy modules: open hardware forces fair prices, easy to calculate what it actually costs.

Integrated systems maintenance by a professional with a special device.

Manuals for installation by DIY users or electricians; easy-to-use web interface to configure.

Customization of closed systems is limited. We have customization on all levels, e.g. python plugins, or can modify the main software, or even the firmware of the IO modules. Can create your own hardware.

Modules have bootloaders so they can all be updated.

Can interface to other devices over serial ports or ethernet.

Keynote: Living on Mars: can we open-source a society?

By a physicist candidate for the project.

What has open source software to do with a mission to Mars? The project has open source firmly at its heart, to make sure there are no technology problems.

– the apollo effect
– why mars?
– how do we reach Mars?
– the Mars One mission
– open sourcing a society: martian society’s implications for earth society
– questions

The Martian day is just right for people! Temperatures can get into the earth range. There seems to have once been an ocean and more atmosphere, but lost the core heat and magnetism. Terraforming? About 8 months to get there by Hoffman transfer orbit. You can take a lot less if you want to have enough fuel for a return trip. Selecting the right people (who will stay sane and not fall out with each other) is all-important.


Post a Comment

Required fields are marked *


%d bloggers like this: