GitHub CLI on Ubuntu LTS (16.04 & 18.04)
Mar 4th, 2020 by miki

Inspired by a John Sullivan (of FSF) tweet asking about opinions on the new and shiny MS(TM) GitHub(TM) CLI(TM) tool named “gh”(TM) I wanted to try it out on one of my Ubuntu LTS systems (16.04).

I’ve always disliked the proprietary and centralised monoculture of github, especially after that thing with MS, so I’ve mostly avoided using the service for code I produce myself. If interested in independence and decentralisation maybe you should read up on that long fabled subject? Thus I’ve never even tried the predecessor “hub”(TM) tool (main page), and exactly how it differs from this new “CLI” thing is not obviously apparent from the communications.

Nevertheless, the “gh” tool, officially dubbed  GitHub CLI, being distributed under MIT license and written in go(lang) (afterwards, found out that this is indeed also applicable to the predecessing “hub” tool) made me curious enough to go see what they’re up to. Maybe its not that sinister a plot and they really just want to improve the independent and freely available mechanisms for source code storage, distribution and maintenance (I wish)?


A fairly recent (2019-09) version of go, >=1.13, is required so some gymnastics are needed to make stuff work on older distros like Ubuntu’s LTS (with 5 years support from Canonical). Anyway, this is what I did to build a useable “gh” ELF executable (20 MiB!, se below), this is from source, no precompiled stuff, no snaps. It was done on Ubuntu 16.04 (xenial) but I’ve been somewhat careful to inspect that things ought to be good for 18.04 (bionic) too. Non-essential output from the commands is largely discarded here. See Gory Details section below for the full monty.

Add go PPA & install packages

$ sudo add-apt-repository ppa:longsleep/golang-backports
$ sudo apt update
$ sudo apt install golang
$ go version
go version go1.13.4 linux/amd64

Clone repo & build

$ cd
$ git clone .githubcli
$ cd .githubcli
$ make

Setup PATH & test

$ echo 'export PATH="$HOME/.githubcli/bin:$PATH"' >> ~/.bash_profile
$ bash --login
$ gh
Work seamlessly with GitHub from the command line.

GitHub CLI is in early stages of development, and we'd love to hear your
feedback at <>

  gh [command]

Available Commands:
  help        Help about any command
  issue       Create and view issues
  pr          Create, view, and checkout pull requests
  repo        Create, clone, fork, and view repositories

      --help              Show help for command
  -R, --repo OWNER/REPO   Select another repository using the OWNER/REPO format
      --version           Show gh version

Use "gh [command] --help" for more information about a command.
subcommand is required

Trying it out

Randomly picked one of my few github repos, it contains some js experiments on parsing NMEA formatted coordinates, rather uninterestingly empty.


user@host:~$ gh repo clone mikini/coordinates 
Notice: authentication required
Press Enter to open in your browser... 

<auth session in browser>

Authentication complete. Press Enter to continue...

Cloning into 'coordinates'...
remote: Enumerating objects: 10, done.
remote: Total 10 (delta 0), reused 0 (delta 0), pack-reused 10
Unpacking objects: 100% (10/10), done.
Checking connectivity... done.

An ordinary OAuth request was spawned for authentication on The javascript executed in the browser seemed to interact with the gh tool through a local TCP connection on localhost:45454 which was the redirection target on authorisation (URL parameter: “redirect_uri=http://localhost:45454/callback”). The socket was rightfully not bound after the authentication had succeeded but this is definitely an attack vector, albeit hopefully only for locally running processes.

Listing issues & prs

user@host:~$ cd coordinates/
user@host:~$:~/coordinates$ gh issue list

Issues for mikini/coordinates

There are no open issues
miki@vcas-miki2:~/coordinates$ gh pr view
no open pull requests found for branch "master"

Creating issues

miki@vcas-miki2:~/coordinates$ gh issue create

Creating issue in mikini/coordinates

? Title Testing gh
? Body <Received>
? What's next? Preview in browser
Opening in your browser.

miki@vcas-miki2:~/coordinates$ gh issue create

Creating issue in mikini/coordinates

? Title Testing gh tool
? Body <Received>
? What's next? [Use arrows to move, type to filter]
> Preview in browser

On the first issue creation interaction I selected “preview in browser” which opened a draft issue in the browser, and dumped me back into the shell on the command line. The second interaction actually resulted in #1.

Gory Details

PPA options

The golang-backports PPA is maintained independently by Simon Eisenmann (credits: ~longsleep, @github, and carries packages up to:

There’s also an official PPA from the golang project (~gophers) which however only carries packages up to 1.11 for both.

Full (mostly) installation dump

Add go PPA, install packages

user@host:~$ sudo add-apt-repository ppa:longsleep/golang-backports
Golang 1.8, 1.9, 1.10, 1.11, 1.12, 1.13 and 1.14 PPA for Ubuntu
 More info:
Press [ENTER] to continue or ctrl-c to cancel adding it

gpg: keyring `/tmp/tmpvnuym97a/secring.gpg' created
gpg: keyring `/tmp/tmpvnuym97a/pubring.gpg' created
gpg: requesting key 56A3D45E from hkp server
gpg: /tmp/tmpvnuym97a/trustdb.gpg: trustdb created
gpg: key 56A3D45E: public key "Launchpad PPA for Simon Eisenmann" imported
gpg: Total number processed: 1
gpg:               imported: 1  (RSA: 1)

user@host:~$ sudo apt update
Hit:1 xenial InRelease
Get:2 xenial-updates InRelease [109 kB] 
Get:37 xenial-security/universe DEP-11 64x64 Icons [194 kB]
Get:38 xenial-security/multiverse amd64 DEP-11 Metadata [2.468 B]
Fetched 7.614 kB in 3s (2.346 kB/s) 
Reading package lists... Done
Building dependency tree 
Reading state information... Done
419 packages can be upgraded. Run 'apt list --upgradable' to see them.

user@host:~$ apt list --upgradeable golang -a
Listing... Done
golang/xenial,xenial 2:1.13~1longsleep1+xenial all [upgradable from: 2:1.6-1ubuntu4]
golang/xenial,xenial,now 2:1.6-1ubuntu4 all [installed,upgradable to: 2:1.13~1longsleep1+xenial]


user@host:~$ sudo apt install golang
Reading package lists... Done
Building dependency tree 
Reading state information... Done
The following packages were automatically installed and are no longer required:
golang-1.6 golang-1.6-doc golang-1.6-go golang-1.6-src
Use 'sudo apt autoremove' to remove them.
The following additional packages will be installed:
golang-1.13 golang-1.13-doc golang-1.13-go golang-1.13-src golang-doc golang-go golang-src
Recommended packages:
The following NEW packages will be installed
golang-1.13 golang-1.13-doc golang-1.13-go golang-1.13-src
The following packages will be upgraded:
golang golang-doc golang-go golang-src
4 to upgrade, 4 to newly install, 0 to remove and 413 not to upgrade.
Need to get 60,2 MB of archives.
After this operation, 322 MB of additional disk space will be used.
Do you want to continue? [Y/n] 
Get:1 xenial/main amd64 golang-1.13-src amd64 1.13.4-1longsleep1+xenial [12,7 MB]
Get:2 xenial/main amd64 golang-1.13-go amd64 1.13.4-1longsleep1+xenial [44,9 MB]
Get:3 xenial/main amd64 golang-1.13-doc all 1.13.4-1longsleep1+xenial [2.542 kB]
Get:4 xenial/main amd64 golang-1.13 all 1.13.4-1longsleep1+xenial [25,2 kB]
Get:5 xenial/main amd64 golang-src amd64 2:1.13~1longsleep1+xenial [3.838 B]
Get:6 xenial/main amd64 golang-go amd64 2:1.13~1longsleep1+xenial [23,0 kB]
Get:7 xenial/main amd64 golang-doc all 2:1.13~1longsleep1+xenial [3.880 B]
Get:8 xenial/main amd64 golang all 2:1.13~1longsleep1+xenial [3.826 B]
Fetched 60,2 MB in 5s (10,8 MB/s) 
Selecting previously unselected package golang-1.13-src.
(Reading database ... 460737 files and directories currently installed.)
Preparing to unpack .../golang-1.13-src_1.13.4-1longsleep1+xenial_amd64.deb ...
Unpacking golang-1.13-src (1.13.4-1longsleep1+xenial) ...
Selecting previously unselected package golang-1.13-go.
Preparing to unpack .../golang-1.13-go_1.13.4-1longsleep1+xenial_amd64.deb ...
Unpacking golang-1.13-go (1.13.4-1longsleep1+xenial) ...
Selecting previously unselected package golang-1.13-doc.
Preparing to unpack .../golang-1.13-doc_1.13.4-1longsleep1+xenial_all.deb ...
Unpacking golang-1.13-doc (1.13.4-1longsleep1+xenial) ...
Selecting previously unselected package golang-1.13.
Preparing to unpack .../golang-1.13_1.13.4-1longsleep1+xenial_all.deb ...
Unpacking golang-1.13 (1.13.4-1longsleep1+xenial) ...
Preparing to unpack .../golang-src_2%3a1.13~1longsleep1+xenial_amd64.deb ...
Unpacking golang-src (2:1.13~1longsleep1+xenial) over (2:1.6-1ubuntu4) ...
Preparing to unpack .../golang-go_2%3a1.13~1longsleep1+xenial_amd64.deb ...
Unpacking golang-go (2:1.13~1longsleep1+xenial) over (2:1.6-1ubuntu4) ...
Preparing to unpack .../golang-doc_2%3a1.13~1longsleep1+xenial_all.deb ...
Unpacking golang-doc (2:1.13~1longsleep1+xenial) over (2:1.6-1ubuntu4) ...
Preparing to unpack .../golang_2%3a1.13~1longsleep1+xenial_all.deb ...
Unpacking golang (2:1.13~1longsleep1+xenial) over (2:1.6-1ubuntu4) ...
Processing triggers for man-db (2.7.5-1) ...
Setting up golang-1.13-src (1.13.4-1longsleep1+xenial) ...
Setting up golang-1.13-go (1.13.4-1longsleep1+xenial) ...
Setting up golang-1.13-doc (1.13.4-1longsleep1+xenial) ...
Setting up golang-1.13 (1.13.4-1longsleep1+xenial) ...
Setting up golang-src (2:1.13~1longsleep1+xenial) ...
Setting up golang-go (2:1.13~1longsleep1+xenial) ...
Setting up golang-doc (2:1.13~1longsleep1+xenial) ...
Setting up golang (2:1.13~1longsleep1+xenial) ...

user@host:~$ go version
go version go1.13.4 linux/amd64

Clone repo & build

user@host:~$ git clone .githubcli
Cloning into '.githubcli'...
remote: Enumerating objects: 168, done.
remote: Counting objects: 100% (168/168), done.
remote: Compressing objects: 100% (100/100), done.
remote: Total 5577 (delta 93), reused 122 (delta 67), pack-reused 5409
Receiving objects: 100% (5577/5577), 7.53 MiB | 2.61 MiB/s, done.
Resolving deltas: 100% (3269/3269), done.
Checking connectivity... done.

user@host:~$ cd .githubcli
user@host:~/.githubcli (master=)$ make
go: downloading v0.0.0-20191202100458-e7afc7fbc510
go: downloading v1.1.0
go: downloading v0.1.6
go: downloading v0.0.6
go: downloading v3.0.0-20200121175148-a6ecf24a6d71
go: downloading v0.0.12
go: downloading v0.3.2
go: extracting v1.1.0
go: extracting v0.1.6
go: extracting v0.0.0-20191202100458-e7afc7fbc510
go: extracting v0.0.6
go: extracting v0.0.12
go: downloading v0.0.0-20200223170610-d5e6a3e2c0ae
go: downloading v0.0.0-20200219234226-1ad67e1f0ef4
go: downloading v0.0.0-20170206155736-9520e82c474b
go: downloading v1.9.0
go: extracting v3.0.0-20200121175148-a6ecf24a6d71
go: downloading v1.2.0
go: downloading v1.0.5
go: downloading v2.0.7
go: downloading v0.0.0-20180428030007-95032a82bc51
go: downloading v0.1.1-0.20200304134224-7e5c90143acc
go: extracting v0.0.0-20170206155736-9520e82c474b
go: extracting v1.0.5
go: extracting v1.2.0
go: downloading v2.2.8
go: downloading v2.0.0
go: downloading v0.0.4
go: extracting v0.0.0-20180428030007-95032a82bc51
go: extracting v1.9.0
go: extracting v2.0.7
go: downloading v1.7.0
go: extracting v0.1.1-0.20200304134224-7e5c90143acc
go: downloading v1.1.24
go: downloading v1.0.2
go: extracting v2.2.8
go: extracting v0.0.4
go: downloading v0.0.4
go: downloading v0.1.0
go: extracting v1.7.0
go: extracting v1.0.2
go: extracting v2.0.0
go: extracting v0.0.0-20200223170610-d5e6a3e2c0ae
go: extracting v0.1.0
go: extracting v0.0.4
go: downloading v0.0.0-20200219183655-46282727080f
go: extracting v1.1.24
go: downloading v0.7.2-0.20200304075647-34d9c7143bf5
go: downloading v0.0.8
go: downloading v0.4.0
go: downloading v2.0.1
go: extracting v0.0.0-20200219234226-1ad67e1f0ef4
go: extracting v0.0.8
go: extracting v2.0.1
go: downloading v1.0.0
go: extracting v0.7.2-0.20200304075647-34d9c7143bf5
go: extracting v1.0.0
go: extracting v0.4.0
go: downloading v1.2.0
go: downloading v1.0.3
go: downloading v0.0.0-20190703233501-fc88cf888a3f
go: downloading v0.0.0-20160403171240-cbb64ac3d964
go: extracting v0.3.2
go: extracting v0.0.0-20190703233501-fc88cf888a3f
go: extracting v0.0.0-20160403171240-cbb64ac3d964
go: extracting v0.0.0-20200219183655-46282727080f
go: extracting v1.0.3
go: extracting v1.2.0
go: finding v0.0.6
go: finding v2.0.7
go: finding v0.0.4
go: finding v0.0.0-20191202100458-e7afc7fbc510
go: finding v0.0.0-20170206155736-9520e82c474b
go: finding v3.0.0-20200121175148-a6ecf24a6d71
go: finding v1.0.5
go: finding v1.2.0
go: finding v1.1.0
go: finding v1.9.0
go: finding v0.3.2
go: finding v2.0.0
go: finding v0.1.1-0.20200304134224-7e5c90143acc
go: finding v0.0.0-20180428030007-95032a82bc51
go: finding v0.1.6
go: finding v2.2.8
go: finding v2.0.1
go: finding v0.0.12
go: finding v1.7.0
go: finding v0.0.0-20200219234226-1ad67e1f0ef4
go: finding v0.4.0
go: finding v0.0.0-20200223170610-d5e6a3e2c0ae
go: finding v1.0.0
go: finding v1.1.24
go: finding v0.7.2-0.20200304075647-34d9c7143bf5
go: finding v0.0.0-20190703233501-fc88cf888a3f
go: finding v1.2.0
go: finding v1.0.3
go: finding v0.1.0
go: finding v1.0.2
go: finding v0.0.0-20160403171240-cbb64ac3d964
go: finding v0.0.4
go: finding v0.0.8
go: finding v0.0.0-20200219183655-46282727080f
user@host:~/.githubcli (master=)$ 

Cursory inspection of exec

user@host:~/.githubcli (master=)$ ls -l bin/gh
-rwxrwxr-x 1 user user 21097487 Mar  4 18:03 bin/gh
user@host:~/.githubcli (master=)$ 

user@host:~/.githubcli (master=)$ file bin/gh
bin/gh: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/l, not stripped
user@host:~/.githubcli (master=)$ 

user@host:~/.githubcli (master=)$ ldd bin/gh =>  (0x00007ffdc4329000) => /lib/x86_64-linux-gnu/ (0x00007fb1018c2000) => /lib/x86_64-linux-gnu/ (0x00007fb1014f8000)
	/lib64/ (0x00007fb101adf000)
user@host:~/.githubcli (master=)$ 

user@host:~/.githubcli (master=)$ nm -D bin/gh
                 U abort
00000000004fd140 T _cgo_panic
000000000045bf10 T _cgo_topofstack
00000000004fd190 T crosscall2
                 U __errno_location
                 U __fprintf_chk
                 U fputc
                 U free
                 U freeaddrinfo
                 U fwrite
                 U gai_strerror
                 U getaddrinfo
                 U getnameinfo
                 U malloc
                 U mmap
                 U munmap
                 U nanosleep
                 U pthread_attr_destroy
                 U pthread_attr_getstacksize
                 U pthread_attr_init
                 U pthread_cond_broadcast
                 U pthread_cond_wait
                 U pthread_create
                 U pthread_detach
                 U pthread_mutex_lock
                 U pthread_mutex_unlock
                 U pthread_sigmask
                 U setenv
                 U sigaction
                 U sigaddset
                 U sigemptyset
                 U sigfillset
                 U sigismember
                 U __stack_chk_fail
                 U stderr
                 U strerror
                 U unsetenv
                 U __vfprintf_chk
user@host:~/.githubcli (master=)$ 

Setup PATH & test

user@host:~/.githubcli (master=)$ cd
user@host:~$ echo 'export PATH="$HOME/.githubcli/bin:$PATH"' >> ~/.bash_profile
user@host:~$ bash --login
user@host:~$ gh
Work seamlessly with GitHub from the command line.

GitHub CLI is in early stages of development, and we'd love to hear your
feedback at <>

  gh [command]

Available Commands:
  help        Help about any command
  issue       Create and view issues
  pr          Create, view, and checkout pull requests
  repo        Create, clone, fork, and view repositories

      --help              Show help for command
  -R, --repo OWNER/REPO   Select another repository using the OWNER/REPO format
      --version           Show gh version

Use "gh [command] --help" for more information about a command.
subcommand is required
Itch: eog core dump on Galaxy 7 panorama image
Jun 10th, 2019 by miki

  • Took some photos with my Galaxy 7. Some were panoramas.
  • EOG crashed while loading them.
  • Memory was low.
  • Maybe related to previously experienced missing EOI marker issue with Samsung camera application.

Will investigate later and amend the post (promise!).

Commandline Dump

$ free; find . -size +25M -exec bash -c 'ls -l {}; eog {}; echo' \;; free
              total        used        free      shared  buff/cache   available
Mem:        7746692     5767656      843228      317764     1135808     1271048
Swap:       7950332     5113012     2837320
-rw-rw-r-- 1 miki miki 39926496 Jun 10 19:25 ./20190609_184124.jpg

** (eog:23320): CRITICAL **: eog_reload_plugin_activate: assertion 'G_IS_MENU (model)' failed
eog: ../../../../src/cairo-xlib-surface-shm.c:619: _cairo_xlib_shm_pool_create: Assertion `*ptr != ((void *)0)' failed.
bash: line 1: 23320 Aborted                 (core dumped) eog ./20190609_184124.jpg

-rw-rw-r-- 1 miki miki 38286099 Jun 10 19:26 ./20190609_183714.jpg

** (eog:23332): CRITICAL **: eog_reload_plugin_activate: assertion 'G_IS_MENU (model)' failed
eog: ../../../../src/cairo-xlib-surface-shm.c:619: _cairo_xlib_shm_pool_create: Assertion `*ptr != ((void *)0)' failed.
bash: line 1: 23332 Aborted                 (core dumped) eog ./20190609_183714.jpg

-rw-rw-r-- 1 miki miki 36181801 Jun  9 17:13 ./20190609_160437.jpg

** (eog:23343): CRITICAL **: eog_reload_plugin_activate: assertion 'G_IS_MENU (model)' failed

** (eog:23343): CRITICAL **: eog_reload_plugin_deactivate: assertion 'G_IS_MENU (menu)' failed

-rw-rw-r-- 1 miki miki 39059177 Jun 10 19:25 ./20190609_184146.jpg

** (eog:23354): CRITICAL **: eog_reload_plugin_activate: assertion 'G_IS_MENU (model)' failed
eog: ../../../../src/cairo-xlib-surface-shm.c:619: _cairo_xlib_shm_pool_create: Assertion `*ptr != ((void *)0)' failed.
bash: line 1: 23354 Aborted                 (core dumped) eog ./20190609_184146.jpg

              total        used        free      shared  buff/cache   available
Mem:        7746692     5773448      495604      659944     1477640      922956
Swap:       7950332     5112700     2837632


[Danish] S&S: Android-x86 og Chromebook
Jun 8th, 2019 by miki

Lidt flere dråber i Spørgsmål&Svar-kategorien fra Facebook.

Når jeg endelig forvilder mig derind, og går på opdagelse i de tekniske grupper, ender det ofte med at får jeg skrevet en fristil i forsøget på at hjælpe.

Denne gang en snak om Android på “PC”, og basale digitale processeringsbehov for den almindelige dansker.


Stillet i gruppen “Danske Android Brugere “:

Er der nogen som ved, om man kan få en pc med Android system?


Mit svar:

Som andre omtaler, kan der fås en uofficiel variant af det frie styresystem Android til x86-arkitekturen (den gængse Intel/AMD-baserede computer kendt som “personlig computer”).

Det projekt lever på Installationsvejledning på engelsk er på Man kan både installere som multiboot på samme disk som et eksisterende operativsystem, starte fra en ekstern disk (USB-medie, cd/dvdrom e.l.) eller evt. køre i en virtuel maskine på et eksisterende operativsystem (VirtualBox,QEMU/KVM, VMware Player/Workstation).

Jeg har kun erfaring med livedisk boot fra USB og VM, og der synes jeg ikke altid tingene spiller perfekt, så forvent ikke en helt problemfri oplevelse.

“Android på PC” er på kanten af noget understøttet, hvor man ofte er på egen hånd. Nogle af folkene bag Andoid-x86 forsøgte at lave en kommerciel forretning på det, hvor det var tanken at sælge det som færdige hardwareenheder, RemixOS –, men det gik ikke så godt og er lukket ned igen.

Hvis behovet bare er “en bærbar computer uden for meget vrøvl”, så er en færdig Chromebook med Chrome OS (der ligesom Android også er bygget på GNU/Linux) eller noget af det der dyre Frugt-udstyr nok det mest tilgængelige (men jeg fornemmer at pris også kunne være en faktor?). Til forskel fra traditionelle operativsystemer til computere, er Chrome OS dog møntet specifikt på at få dig til at bruge Googles webbaserede tjenester (mere om softwaren bag på, så hverken software eller hardware er beregnet til at lagre data på selve enheden, og der er sjældent meget diskplads tilgængelig til f.eks. billeder.

Et hurtigt kig på markedet identificerer Acer Chromebook 15 ( og Lenovo S330 ( som populære Chromebook i 2k kr.-klassen, men kender ikke maskinerne specifikt.

God jagt :).

[Danish] Stallman til Danmark i Maj 2019!
Apr 7th, 2019 by miki

Rygterne har lydt noget tid, men nu er det officielt at formand for og stifter af Free Software Foundation, den ideologiske ophavsmand til GNU-projektet og højlydt fortaler for softwarebrugeres frihed og privatliv i den digitale verden, Richard Stallman besøger Danmark med en række åbne og gratis foredrag dette forår.

Det er Stallmans dedikerede arbejde med fri software og GNU-projektet fra starten af 1980’erne, herunder udformning af softwarelicenser som GNU GPL og udviklingsværktøjer som GNU Compiler Collection (GCC) og GNU Emacs, der er grundlaget for en stor del af det der i offentligheden i dag bedst kendes som “open source”. I Stallmans og GNUs terminologi benævnes det dog retteligt “fri software” (på engelsk: “free software”) for at fremhæve at etablering og bevarelse af softwarens, og slutbrugeren af dens, frihed er det egentlige rationale for at give kildekoden fri.

Kernen Linux er frigivet under GNU GPL og er både inspireret af og anvender GNU-projektets arbejde direkte, og er en vigtig del af et komplet GNU-system (også kendt som GNU/Linux eller en “Linux-distribution”).

Stallman kommer på en veritabel Danmarksturne med start i Aalborg mandag d. 6. maj 2019 og ender i København fredag d. 10.  maj 2019. Foredragsrækken er arrangeret af innovationsnetværket for IT, InfiniIT, som inkluderer de store IT-universiteter i Danmark.

Den samlede foredragsrække er som følger:

Tidspunkt Lokation Begivenhed hos FSF Begivenhed hos InfinIT Anden omtale
Mandag d. 6. maj 2019


Aalborg Universitet
Auditoriet, Lokale 1.12
Niels Jernes Vej 8A
9220 Aalborg SØVejviser:

Richard Stallman – “Free software and your freedom” Free Software, Free Society – Richard Stallman og den frie software-bevægelse (AAU)
Tirsdag d. 7. maj 2019


Syddansk Universitet
Lokale U170
Bygning 44
Campusvej 55
5230 OdenseVejviser:

Richard Stallman – “The dangers of mass surveillance” A Free Digital Society – Richard Stallman og den frie software-bevægelse
Onsdag d. 8. maj 2019


IT-Universitetet i København
Rued Langgaards Vej 7
2300 København SVejviser:

Richard Stallman – “Free software and your freedom in computing” A Free Digital Society – Richard Stallman og den frie software-bevægelse
Torsdag d. 9. maj 2019


Københavns Universitet
Københavns Biocenter
Lundbeckfond Auditorium Ole Maaløes Vej 5
2200 København NVejviser

Richard Stallman – “Computing, freedom, and privacy” Free Software, Free Society – Richard Stallman og den frie software-bevægelse (KU)
Fredag d. 10. maj 2019


Danmarks Tekniske Universitet
Auditorium 116/81 (bygning 116)
Ved Bygningstorvet på Knuth-Wintherfeldts Allé
2800 Kongens LyngbyVejviser:

Richard Stallman – “Copyright vs Community”

(ændrede lokationsoplysninger ikke opdaterede her)

Copyright vs Community Richard Stallman og den frie software-bevægelse

Kilder: FSF: Where in the world is Richard Stallman?, InfinIT-arrangementer, IDA-søgning, PROSA-arrangementer

Begivenhederne er også tilføjet den åbne kalender GriCal:

Information om Richard/GNU/FSF

De primære kilder er hovedsageligt på engelsk:

Kilder på dansk


Anden omtale

Micro:bit – Official Android mobile application maturity and future
Jan 31st, 2019 by miki

The support request replicated below was posted as ticket #20427 on Micro:bit support on 2019-01-31 22:19 CET spawned by discussion in F-Droid RFP #662 about inclusion of the official Micro:bit Android Companion application in the free software application store F-Droid.

Hi at Micro:bit Educational Foundation.

We are wondering a bit in the F-Droid free software community ( whether it is worthwhile for us to try to loosen the official Android companion application ( from its non-free dependencies to make it available in the free software application store F-Droid (

This leads to a couple of questions you can hopefully help answering;

1) Do you regard the application as alive and supported?

The latest release of the application was v2.0 2017-01-17 ( and the publicly available code base ( seems to have been completely abandoned. Only two commits were ever made by Samsung and no involvement with the community has been seen at all.

2) How come the big difference in maturity between the iOS and Android mobile applications?

It seems like the iOS application has received some more attention seeing regular updates through to v3.0.2 released 2018-11-01 ( Also it appears to have a much wider fetaureset ( developed along the way by Insight Resources (

The Android application appears to have been more of a one-off project from Samsung having all sorts of issues especially with Bluetooth that has never been attended to (,

3) Is there a plan to bring the application in better shape?

Some activity can be seen in repository forks and branches from the original Samsung committer ailrohit (…ailrohit:school_project) and microbit-sam (…microbit-sam:partial-flash) identifying as being from the foundation but none of this work seem to be included in releases yet.

4) If a freed fork is made for inclusion in F-Droid would you be willing and able to integrate the changes into the official sources?

F-Droid prefers an upstream source which can be directly built without non-free dependencies using an appropriate set of build options. This greatly simplifies maintenance and build efforts. A forked repository is already in place at the foundation’s Github organization ( but is at the moment even with the stale Samsung repository.

Thanks for any clarifications you can provide.


Generating passwords for Mosquitto MQTT broker using PHP
Jan 13th, 2017 by miki

Here is a delayed writeup of a my involvement in a question posted to the liberally licensed MQTT broker (server) Mosquitto’s developer list list about how to generate authentication tokens programmatically. It kicked the curious cat in me which propelled a journey into the backyards of the C code for the mosquitto_password tool which normally is used for this purpose. This resulted in the proof of concept PHP implementation outlined in my answer on the list which is reproduced below.

MQTT (once Message Queue Telemetry Transport) is a lightweight publish/subscribe protocol intended for communication between low power, low bandwidth embedded devices. These days it is commonly hyped as a holy grail in the religion of IoT. The protocol was originally developed by IBM but is now a standard overseen by the OASIS standardization organization which also has the OpenDocument standard (ODF, think Open/Libre-Office) under its wings. According to Wikipedia MQTT is used behind the scenes of Facebook Messenger, OpenStack and Amazon’s IoT services.

For further practical use of the concept outlined you would need to produce a random 16 byte base64 encoded salt to feed into the hasher, that could be done using something like; $salt_base64=base64_encode(openssl_random_pseudo_bytes(12));

If your need a shrink wrapped solution to this you could try to ping me.

Hi Srinivas.

On 2016-07-26 12:49, Srinivas Pokala wrote:
> Username successfully created using linux command with: 
> "mosquitto_passwd /etc/mosquitto/passwd guest".
> I need to create same with php or javascript how?

Looking at the source of mosquitto_passwd
basically all it does to generate the resulting line you see in the
password file is:

1) draw a random 12 byte binary salt
2) hash the combination of password and salt using sha512
3) write username, base64 encoded salt, base64 encoded hash in one line

A PHP implementation would use something like this ($salt is fixed for
demonstration purposes, it ought to be random in production);

$hash=hash("sha512",$password.$salt, true);

Comparing against mosquitto_passwd using a one-liner (uses the base64
salt from output to be able to correlate the two);

$ mosquitto_passwd -b ~/mosq_passwd_test Bitten Insect
$ cat ~/mosq_passwd_test

$ php -r '$username="Bitten"; $password="Insect";
$salt_base64="mfJ0Eq3rIDLKG33r"; $salt=base64_decode($salt_base64);
$hash=hash("sha512",$password.$salt, true);

As can be seen, the PHP generated password line are identical to the
mosquitto_passwd generated.

I have also successfully tested authentication against the mosquitto
broker with PHP generated users. One caveat is that the above can
generate a salt of arbitrary length, but the broker must see a 12 byte
binary salt (16 byte base64) or authentication will fail.

Note however, that this hasn't been tested on more than a few
username/password pairs, there might be other issues lurking.

[Danish] S&S: gemme data i Arduino ROM/Flash (PROGMEM / F())
Dec 21st, 2016 by miki

Mit svar på et spørgsmål i Facebook-gruppen Danske Arduino Entusiaster omkring Arduino ROM/Flash, PROGMEM og system-inklude-filer.


Hej er der en der ved hvor jeg kan hente dett lib. <avr/pgmspace.h> jeg skal bruge denne funktion PROGMEM
så jeg kan gemme et billede i Arduino uden SD kort
det kan være der er en der kender en anden måde at gøre det på.


pgmspace.h er en inklude-fil som er en del af c-biblioteket til AVR-arkitekturen (avr-libc). C-bibliotekets inklude-filer vil normalt ligge i kompilerens “system include”-sti (se GCC options -I og -isystem). Dermed kan den inkluderes blot med “#include <avr/pgmspace.h>”. Se evt. også Arduino-referencen på
Bemærk at PROGMEM ikke er en funktion, men en storage modifier (lager-modifikator) som fortæller kompileren at den kan placere en en given variabel i ikke-skrivbar lager (ROM/Flash). Der skal efterfølgende anvendes specielle funktioner til at læse data fra en sådan variabel (se referencen).
Arduino-frameworket har dog lavet en nem måde at placere konstant-strenge i Flash på (normalt lagres de i SRAM!), nemlig funktionen F() som kan anvendes direkte i f.eks. printf/write/print (Serial.print(F(“Waiting for connection”));)
Hvis du vil inspicere indholdet af pgmspace.h, kan du finde filen i Arduino IDE’ets installations-mappe under hardware/tools/avr/avr/include/avr/pgmspace.h. Det er ikke en man kan/skal redigere manuelt i, da den er tæt koblet med den binære kode i selve biblioteket.
Der findes også EEPROM-lager du sikkert vil kunne bruge til samme formål;

Se svaret på Facebook.

Den videre færd med F()

Da jeg ikke kunne finde en uddybende forklaring på F()-funktionen (som egentlig er en makro) i Arduino-dokumentationen (brugen nævnes meget kort i PROGMEM , Memory og Print), gravede jeg efterfølgende lidt rundt for at lære mere. I de sparsomme Arduino-eksempler er den anvendt udelukkende med konstante strenge, hvilket også viser sig at være et krav (eller i hvert fald noget der kan castes til const char *).

Makroen er defineret af Arduino-frameworket i filen hardware/arduino/avr/cores/arduino/WString.h (referencerne er ifht. min lokale installation af Arduino 1.6.9, pt. er nyeste 1.6.13) således:

#define F(string_literal) (reinterpret_cast<const __FlashStringHelper *>(PSTR(string_literal)))

Altså parametren til F() bruges som parameter til PSTR() (progmem string, er mit bud på navn) som er en makro defineret i pgmspace.h fra avr-libc.

Dens funktion er at caste parametrens type til konstant streng-pointer med PROGMEM modifier;

#define PSTR(s) ((const PROGMEM char *)(s))

Skal vi se på hvad PROGMEM rent faktisk er, så finder vi endnu et sæt makroer der ender med at blive udviddet til kompiler-attributten  __progmem__, igen definieret i pgmspace.h (hardware/tools/avr/avr/include/avr/pgmspace.h):


#define __ATTR_PROGMEM__ __attribute__((__progmem__))

__progmem__ attributten er en instruks til kompileren (GCC) og linkeren om ved programmering/flashing af programmet at placere disse data i en sektion af hukommelsen der hedder “.progmem“. Se evt. mere om dette i GCC-kompilerens dokumentation. For hver AVR-chip kompileren understøtter er der eksakte definitioner af hvilke hukommelsesadresser .progmem ligger på for netop denne chip.

Dvs. når man i sin kode skriver F(“test”) får man i virkeligheden:

(reinterpret_cast<const __FlashStringHelper *>(((const __attribute__((__progmem__)) char *)(“test”)))

Altså en konstant streng der lagres i AVR-processorens progmem-sektion, og som returværdi får en pointer til en konstant instans af en klasse kaldet “__FlashStringHelper“. Denne klasse må være lavet sådan at den anvender de korrekte mekanismer til at læse fra progmem-området (måske mere om dette i en senere artikel). Arduinos funktion-bibliotek (Serial.print() mm.) er lavet således at de direkte kan tage en parameter af denne type som erstatning for en konstant-streng (og det er netop her Arduino-frameworket viser sin værdi ved at abstrahere sådanne kompleksiteter væk fra programmøren).

Beaglebone Black periodic boot failure; patching mainline u-boot
Jan 15th, 2015 by miki

Patch for u-boot mainline master ( to prevent BBB’s to get stuck in a u-boot prompt because of spurious characters being received on the serial console (see

diff –git a/include/configs/ti_am335x_common.h b/include/configs/ti_am335x_common.h
index 5ed86d9..c58f467 100644
— a/include/configs/ti_am335x_common.h
+++ b/include/configs/ti_am335x_common.h
@@ -12,6 +12,12 @@
#ifndef __CONFIG_TI_AM335X_COMMON_H__
#define __CONFIG_TI_AM335X_COMMON_H__

+#define CONFIG_AUTOBOOT_PROMPT “autoboot in %d seconds (type ‘%s’ to abort)\n”,bootdelay,CONFIG_AUTOBOOT_STOP_STR
#define CONFIG_AM33XX
@@ -102,4 +108,7 @@
/* Now bring in the rest of the common code. */
#include <configs/ti_armv7_common.h>

+#define CONFIG_BOOTDELAY               5
#endif /* __CONFIG_TI_AM335X_COMMON_H__ */

Patch and compiled binaries at

Install the new u-boot by copying the files “MLO” and “u-boot.img” to the root directory of your boot device (first FAT-partition on your SD-card or onboard MMC). Using the stock Debian image ( this can be done via USB by powering the board from your computers USB-interface, waiting for the BBB to boot and register its drive as an usb mass-storage in your OS. Now use your favorite file management application to copy the files from the above zip-file replacing the existing files.

Disclaimer: this is mostly an experiment, there is a lot of u-boot trees and patches floating around for the BBB (like, so probably mainline hasn’t got the most recent stuff for AM335x/BBB yet.

Subversion on Debian ARM: commit failing with space in URL
Sep 16th, 2014 by miki

Working on a Beaglebone Black based product, running the latest Debian GNU/Linux system image (bone-debian-7.5-2014-05-14-2gb.img) from the BB HQ at I just had the following strange experience.

Using Subversion I wanted to commit a change to a file made locally on the BBB. The file resided  in a working copy of a repository on which I had done the initial work on my x86_64 laptop. The working copy was checked out and updated on the BBB without any problems, but comitting I got the following error:

debian@beaglebone:~/VCAS_FR$ svn ci rc.local -m"Append to vncserver.log."
Authentication realm: <https://svn.xx.xx> Subversion Repository
Password for 'yaya': 
Sending        rc.local
Transmitting file data .svn: Commit failed (details follow):
svn: File not found: transaction '414-1', path '/trunk/BBB%20deployment/rc.local'

This failed repeatedly, and checking out a fresh new working copy exhibited the same result.

For the fun of it, because file name issues are long gone in my everyday computing life, I tried to remove the space from the directory path. And voila, unexpectedly it succeeded!

debian@beaglebone:~/VCAS_FR$ svn ci rc.local -m"Append to vncserver.log."
Authentication realm: <https://svn.xx.xx> Subversion Repository
Password for 'yaya': 
Sending        rc.local
Transmitting file data .
Committed revision 416.

Without spaces, things actually did work. Apparently there’s an issue with ARM built subversion and repositories containing spaces.

URL before

debian@beaglebone:~/VCAS_FR$ svn info | grep URL
URL: https://svn.xx.xx/trunk/BBB%20deployment

URL after

debian@beaglebone:~/VCAS_FR$ svn info | grep URL
URL: https://svn.xx.xx/trunk/BBB_deployment

Investigating a bit further narrowed down that the Debian distribution uses an old (old, old) subversion 1.6.17 release from 2009:

debian@beaglebone:~/VCAS_FR$ svn --version
svn, version 1.6.17 (r1128011)
   compiled Mar 15 2014, 21:37:31

Copyright (C) 2000-2009 CollabNet.
Subversion is open source software, see
This product includes software developed by CollabNet (http://www.Collab.Net/).

Probaly, this has been fixed since, a quick investigation in svn issue tracker revealed no open issues regarding this. I’ll look further into this later, and of course report it appropriately if this is an unknown issue.

But as you see, you can still experience basic issues on the latest and greatest stuff out there. Be wary!

Howto: disable HDMI blanking in Ångström on BeagleBone Black (BBB)
Jul 9th, 2014 by miki

A very annoying feature of the Ångström image that is shipped with the BeagleBone Black, is that a display connected to the HDMI output of the board will by default be blanked when powering up, and is first woken when any pointer activity occur (touch/mouse).

This seems to originate from the fbdev that is used for displaying graphics, and it took me some time to figure out how to cirumvent it. The normal X commands for controlling blanking of “xset -dpms” or “xset s off” did nothing, and neither did the terminal options of “setterm powersave off” or “setterm powerdown 0”. I went all the way back to old ANSI escape sequences trying “echo -e ‘\033[9;X]'” without success.

Luckily I fell by at’s framebuffer tips, which listed the sys-fs node named /sys/class/graphics/fb0/blank that controls blanking of the low level framebuffer, thus executing (as root)

echo 0 > /sys/class/graphics/fb0/blank

disables blanking and wakes up the BBB HDMI output.

To do this at every boot (really login) you can use the Gnome Startup Applications Preferences (gnome-session-properties) to execute this at Gnome autologin, or add it to whatever startup script you see fit.

Beware that you might need to delay the execution when using the gnome-session-properties, I had to put in  a sleep, but that probably depends on what other stuff is starting up from it.



»  Substance:WordPress   »  Style:Ahren Ahimsa
© 2020 Mikkel Kirkgaard Nielsen, contents CC BY-SA 4.0