You are here

Planet Ubuntu

Subscribe to Feed Planet Ubuntu
Planet Ubuntu -
Përditësimi: 7 months 20 orë më parë

Ubuntu Studio: Updates for February 2019

Sht, 16/02/2019 - 9:31md
With Ubuntu 19.04’s feature freeze quickly approaching, we would like to announce the new updates coming to Ubuntu Studio 19.04. Updated Ubuntu Studio Controls This is really a bit of a bugfix for the version of Ubuntu Studio Controls that landed in 18.10. Ubuntu Studio Controls dramatically simplifies audio setup for the JACK Audio Connection […]

Jono Bacon: Forbes Piece: Six Hallmarks of Successful Crowdfunding Campaigns

Enj, 14/02/2019 - 12:17pd

I wanted to drop a quick note to you all that I have written a new Forbes article called Six Hallmarks of Successful Crowdfunding Campaigns.

From the piece:

While the newness of crowdfunding may have worn off, this popular way to raise funds has continued to spark interest, especially to entrepreneurs and startups.  For some, it is a panacea; a way to raise funds quickly and easily, with an extra dose of marketing and awareness thrown in. Sadly, the reality of what is needed to make a crowdfunding campaign a success is often missing in all the excitement.

I have some experience with crowdfunding in a few different campaigns. Back in 2013 I helped shape one of the largest crowdfunding campaigns at the time, the Ubuntu Edge, which had a $32million goal and ended up raising $12,814,216. While it didn’t hit the mark, the campaign set records for the funds raised. My second campaign was for the Global Learning XPRIZE, which had a $500,000 goal and we raised $942,223. Finally, I helped advise ZBiotics with their $25,000 campaign, and they raised $52,732.

Today I want to share some lessons learned along the way with each of these campaigns. Here are six considerations you should weave into your crowdfunding strategy…

In it I cover these six key principles:

  1. Your campaign is a cycle: plan it out
  2. Your pitch needs to be short, sharp, and clear on the value
  3. Focus on perks people want (and try to limit shipping)
  4. Testimonials and validation builds confidence
  5. Content is king (and marketing is queen)
  6. Incentivize your audience to help

You can read the piece by clicking here.

You may also want to see some of my other articles that relate to the different elements of doing crowdfunding well:

Good luck with your crowdfunding initiatives and let me know how you get on!

The post Forbes Piece: Six Hallmarks of Successful Crowdfunding Campaigns appeared first on Jono Bacon.

Riccardo Padovani: Glasnost: yet another Gitlab's client.

Dje, 10/02/2019 - 7:45md

I love Gitlab. I have written about it, I contribute (sporadically) with some code and I am a big fan of their CI/CD system (ask my colleagues!). Still, they need to improve on their mobile side.

I travel often, and be able to work on issues and pipelines on the go is something essential for me. Unfortunately, Gitlab’s UX on small screens is far from ideal (while it has improved over the years).

Enter Glasnost

My good friend Giovanni has developed a new opensource mobile client for Gitlab, with a lot of cool features: Glasnost!

In his words:

Glasnost is a free, currently maintained, platform independent and opensource mobile application that is aiming to visualize and edit the most important entities handled by Gitlab.

Among the others features, I’d like to highlight support for multiple Gitlab hosts (so you can work both on your company’s Gitlab and on at the same time), two different themes (a light one and a dark one), a lite version for when your data connection is stuck on edge, and support for fingerprint authentication.

The application is still in an early phase of development, but it already has enough features to be used daily. I am sure Giovanni would love some feedback and suggestions, so please go on the Glasnost’s issues tracker or leave a feedback on the PlayStore.

If you feel a bit more adventurous, you can contribute to the application itself: it is written in React+Redux with Expo: the code is hosted on Gitlab (of course).

Enjoy yet another client for Gitlab, and let Giovanni knows what you think!

For any comment, feedback, critic, write me on Twitter (@rpadovani93) or drop an email at


Sebastian Dröge: MPSC Channel API for painless usage of threads with GTK in Rust

Sht, 09/02/2019 - 2:25md

A very common question that comes up on IRC or elsewhere by people trying to use the gtk-rs GTK bindings in Rust is how to modify UI state, or more specifically GTK widgets, from another thread.

Due to GTK only allowing access to its UI state from the main thread and Rust actually enforcing this, unlike other languages, this is less trivial than one might expect. To make this as painless as possible, while also encouraging a more robust threading architecture based on message-passing instead of shared state, I’ve added some new API to the glib-rs bindings: An MPSC (multi-producer/single-consumer) channel very similar to (and based on) the one in the standard library but integrated with the GLib/GTK main loop.

While I’ll mostly write about this in the context of GTK here, this can also be useful in other cases when working with a GLib main loop/context from Rust to have a more structured means of communication between different threads than shared mutable state.

This will be part of the next release and you can find some example code making use of this at the very end. But first I’ll take this opportunity to also explain why it’s not so trivial in Rust first and also explain another solution.

Table of Contents
  1. The Problem
  2. One Solution: Safely working around the type system
  3. A better solution: Message passing via channels
The Problem

Let’s consider the example of an application that has to perform a complicated operation and would like to do this from another thread (as it should to not block the UI!) and in the end report back the result to the user. For demonstration purposes let’s take a thread that simply sleeps for a while and then wants to update a label in the UI with a new value.

Naively we might start with code like the following

let label = gtk::Label::new("not finished"); [...] // Clone the label so we can also have it available in our thread. // Note that this behaves like an Rc and only increases the // reference count. let label_clone = label.clone(); thread::spawn(move || { // Let's sleep for 10s thread::sleep(time::Duration::from_secs(10)); label_clone.set_text("finished"); });

This does not compile and the compiler tells us (between a wall of text containing all the details) that the label simply can’t be sent safely between threads. Which is absolutely correct.

error[E0277]: `std::ptr::NonNull<gobject_sys::GObject>` cannot be sent between threads safely --> src/ | 28 | thread::spawn(move || { | ^^^^^^^^^^^^^ `std::ptr::NonNull<gobject_sys::GObject>` cannot be sent between threads safely | = help: within `[closure@src/bin/ 31:6 label_clone:gtk::Label]`, the trait `std::marker::Send` is not implemented for `std::ptr::NonNull<gobject_sys::GObject>` = note: required because it appears within the type `glib::shared::Shared<gobject_sys::GObject, glib::object::MemoryManager>` = note: required because it appears within the type `glib::object::ObjectRef` = note: required because it appears within the type `gtk::Label` = note: required because it appears within the type `[closure@src/bin/ 31:6 label_clone:gtk::Label]` = note: required by `std::thread::spawn`

In, e.g. C, this would not be a problem at all, the compiler does not know about GTK widgets and generally all GTK API to be only safely usable from the main thread, and would happily compile the above. It would the our (the programmer’s) job then to ensure that nothing is ever done with the widget from the other thread, other than passing it around. Among other things, it must also not be destroyed from that other thread (i.e. it must never have the last reference to it and then drop it).

One Solution: Safely working around the type system

So why don’t we do the same as we would do in C and simply pass around raw pointers to the label and do all the memory management ourselves? Well, that would defeat one of the purposes of using Rust and would require quite some unsafe code.

We can do better than that and work around Rust’s type system with regards to thread-safety and instead let the relevant checks (are we only ever using the label from the main thread?) be done at runtime instead. This allows for completely safe code, it might just panic at any time if we accidentally try to do something from wrong thread (like calling a function on it, or dropping it) and not just pass the label around.

The fragile crate provides a type called Fragile for exactly this purpose. It’s a wrapper type like Box, RefCell, Rc, etc. but it allows for any contained type to be safely sent between threads and on access does runtime checks if this is done correctly. In our example this would look like this

let label = gtk::Label::new("not finished"); [...] // We wrap the label clone in the Fragile type here // and move that into the new thread instead. let label_clone = fragile::Fragile::new(label.clone()); thread::spawn(move || { // Let's sleep for 10s thread::sleep(time::Duration::from_secs(10)); // To access the contained value, get() has // to be called and this is where the runtime // checks are happening label_clone.get().set_text("finished"); });

Not many changes to the code and it compiles… but at runtime we of course get a panic because we’re accessing the label from the wrong thread

thread '<unnamed>' panicked at 'trying to access wrapped value in fragile container from incorrect thread.', ~/.cargo/registry/src/

What we instead need to do here is to somehow defer the change of the label to the main thread, and GLib provides various API for doing exactly that. We’ll make use of the first one here but it’s mostly a matter of taste (and trait bounds: the former takes a FnOnce closure while the latter can be called multiple times and only takes FnMut because of that).

let label = gtk::Label::new("not finished"); [...] // We wrap the label clone in the Fragile type here // and move that into the new thread instead. let label_clone = fragile::Fragile::new(label.clone()); thread::spawn(move || { // Let's sleep for 10s thread::sleep(time::Duration::from_secs(10)); // Defer the label update to the main thread. // For this we get the default main context, // the one used by GTK on the main thread, // and use invoke() on it. The closure also // takes ownership of the label_clone and drops // it at the end. From the correct thread! glib::MainContext::default().invoke(move || { label_clone.get().set_text("finished"); }); });

So far so good, this compiles and actually works too. But it feels kind of fragile, and that’s not only because of the name of the crate we use here. The label passed around in different threads is like a landmine only waiting to explode when we use it in the wrong way.

It’s also not very nice because now we conceptually share mutable state between different threads, which is the underlying cause for many thread-safety issues and generally increases complexity of the software considerable.

Let’s try to do better, Rust is all about fearless concurrency after all.

A better solution: Message passing via channels

As the title of this post probably made clear, the better solution is to use channels to do message passing. That’s also a pattern that is generally preferred in many other languages that focus a lot on concurrency, ranging from Erlang to Go, and is also the the recommended way of doing this according to the Rust Book.

So how would this look like? We first of all would have to create a Channel for communicating with our main thread.

As the main thread is running a GLib main loop with its corresponding main context (the loop is the thing that actually is… a loop, and the context is what keeps track of all potential event sources the loop has to handle), we can’t make use of the standard library’s MPSC channel. The Receiver blocks or we would have to poll in intervals, which is rather inefficient.

The futures MPSC channel doesn’t have this problem but requires a futures executor to run on the thread where we want to handle the messages. While the GLib main context also implements a futures executor and we could actually use it, this would pull in the futures crate and all its dependencies and might seem like too much if we only ever use it for message passing anyway. Otherwise, if you use futures also for other parts of your code, go ahead and use the futures MPSC channel instead. It basically works the same as what follows.

For creating a GLib main context channel, there are two functions available: glib::MainContext::channel() and glib::MainContext::sync_channel(). The latter takes a bound for the channel, after which sending to the Sender part will block until there is space in the channel again. Both are returning a tuple containing the Sender and Receiver for this channel, and especially the Sender is working exactly like the one from the standard library. It can be cloned, sent to different threads (as long as the message type of the channel can be) and provides basically the same API.

The Receiver works a bit different, and closer to the for_each() combinator on the futures Receiver. It provides an attach() function that attaches it to a specific main context, and takes a closure that is called from that main context whenever an item is available.

The other part that we need to define on our side then is how the messages should look like that we send through the channel. Usually some kind of enum with all the different kinds of messages you want to handle is a good choice, in our case it could also simply be () as we only have a single kind of message and without payload. But to make it more interesting, let’s add the new string of the label as payload to our messages.

This is how it could look like for example

enum Message { UpdateLabel(String), } [...] let label = gtk::Label::new("not finished"); [...] // Create a new sender/receiver pair with default priority let (sender, receiver) = glib::MainContext::channel(glib::PRIORITY_DEFAULT); // Spawn the thread and move the sender in there thread::spawn(move || { thread::sleep(time::Duration::from_secs(10)); // Sending fails if the receiver is closed let _ = sender.send(Message::UpdateLabel(String::from("finished"))); }); // Attach the receiver to the default main context (None) // and on every message update the label accordingly. let label_clone = label.clone(); receiver.attach(None, move |msg| { match msg { Message::UpdateLabel(text) => label_clone.set_text(text.as_str()), } // Returning false here would close the receiver // and have senders fail glib::Continue(true) });

While this is a bit more code than the previous solution, it will also be more easy to maintain and generally allows for clearer code.

We keep all our GTK widgets inside the main thread now, threads only get access to a sender over which they can send messages to the main thread and the main thread handles these messages in whatever way it wants. There is no shared mutable state between the different threads here anymore, apart from the channel itself.

Brian Murray: What’s the OOPS ID?

Mër, 06/02/2019 - 6:11md

The other day gnumeric crashed on me and like a good Ubuntu user, I submitted the crash report to the Ubuntu Error Tracker. Naturally, I also wanted to see the crash report in the Error Tracker and find out if other people had experienced the crash. It used to be an ordeal to find the OOPS ID associated with a specific crash, you’d have to read multiple lines of the systemd journal using ‘journalctl -u whoopsie.service’ and find the right OOPS ID for the crash about which you are interested.

$ journalctl -u whoopsie.service
-- Logs begin at Fri 2019-02-01 09:36:47 PST, end at Wed 2019-02-06 08:41:02 PST. --
Feb 02 07:08:46 impulse whoopsie[4358]: [07:08:46] Parsing /var/crash/_usr_bin_gnumeric.1000.crash.
Feb 02 07:08:46 impulse whoopsie[4358]: [07:08:46] Uploading /var/crash/_usr_bin_gnumeric.1000.crash.
Feb 02 07:08:48 impulse whoopsie[4358]: [07:08:48] Sent; server replied with: No error
Feb 02 07:08:48 impulse whoopsie[4358]: [07:08:48] Response code: 200
Feb 02 07:08:48 impulse whoopsie[4358]: [07:08:48] Reported OOPS ID 7120987c-26fc-11e9-9efd-fa163ee63de6
Feb 02 07:11:11 impulse whoopsie[4358]: [07:11:11] Sent; server replied with: No error
Feb 02 07:11:11 impulse whoopsie[4358]: [07:11:11] Response code: 200

However, I recently made a change to whoopsie to write the OOPS ID to the corresponding .uploaded file in /var/crash. So now I can just read the .uploaded file to find the OOPS ID.

$ sudo cat /var/crash/_usr_bin_gnumeric.1000.uploaded

This is currently only available in Disco Dingo, which will become the 19.04 release of Ubuntu, but if you are interested in having it in another release let me know or update the bug.

Sergio Schvezov: Snapcraft 3.1

Mar, 05/02/2019 - 6:48md
snapcraft 3.1 is now available on the stable channel of the Snap Store. This is a new minor release building on top of the foundations laid out from the snapcraft 3.0 release. If you are already on the stable channel for snapcraft then all you need to do is wait for the snap to be refreshed. The full release notes are replicated here below Build Environments It is now possible, when using the base keyword, to once again clean parts.

Costales: Podcast Ubuntu y otras hierbas S03E02: Software libre en los ciclos formativos... desde dentro

Dje, 03/02/2019 - 2:15md
En este nuevo programa, segundo de la tercera temporada Ubuntu y Otras Hierbas, con Francisco Molinero y Javier Teruelo y con la inestimable colaboración de Lidia Montero y José Manuel Blanco,  se adentra en las complejas relaciones entre los ciclos formativos y el software libre y sus potenciales salidas y futuros (y abre algún melón sorpresa).
¿Conseguirá ser ésta la Nueva Generación?

El podcast esta disponible para escuchar en:

Ted Gould: Knot Boards

Sht, 02/02/2019 - 1:00pd

Each year Cub Scouts has a birthday party for Scouting in February, which is called the Blue & Gold banquet. We have a tradition that at the banquet were we thank all of our volunteers who help make the Cub Scout Pack run. For the Den Leaders, who are so critical to the program, I like to do something special that helps them to run a better program for the scouts. For 2018 (notice I'm a little behind) I decided to make all of the Den Leaders for our Pack knot boards.

When I was a Scout I remember my mom making knot boards. Back then we had a piece of paper with the various knots that was varnished onto a piece of plywood, which had a rope attached to it. High technology for the time, but today I'm a member of makerspace and have access to a laser cutter. While these knot boards are the same in spirt, we can do some very cool things with big toys.

First step is to pull out Inkscape and design the graphics. I grabbed a rope border from Open Clipart and grabbed some knot graphics from a Scouting PDF (which I can't find a link to). I put those together to create the basic design along with labes for the knots. I also added a place for each Scout to sign their name as a Thank you to the Den Leader. I then make some small circles for the laser cutter to cut out holes for the ropes. I made a long oblong region on the right so the board would have a handle and a post to tie the hitches around. Then lastly I added the outline to cut out the board.

To get the design into the laser cutter I exported it from Inkscape in two graphics. I exported the cut lines as a DXF and I exported the etching as a 300 DPI PNG. The cut lines were simpler and the laser cutter software was able to handle those and create simple controls for the cutter. The knots on the other hand were more complex vector objects and the laser cutter software couldn't handle them. Inkscape could, so I had it do the rendering to a bitmap. The laser cutter can then setup scans that use the bitmap data which worked very well.

For the boards I used ¼th" Lauan Plywood which I was able to get in 2'x2' sheets at Lowe's. Those sheets have a nice grain on both sides. I also liked being able to get sheets that were exactly the size I needed to fit into the laser cutter. Saved me a step. I'm certain the knot boards would be great in many other woods and other materials.

After cutting out the knot boards I needed short lengths of rope to be able to insert into the holes. I couldn't find anywhere that would sell me short pieces of rope. I felt like I needed a Monty Python sketch. To make short lengths of the paracord I looped it in a circle with the circumference as the length I needed. Then I took a blowtorch and cut the circle. This also sealed the ends of the paracord.

Jamie Strandboge: Monitoring your snaps for security updates

Pre, 01/02/2019 - 9:53md

Some time ago we started alerting publishers when their stage-packages received a security update since the last time they built a snap. We wanted to create the right balance for the alerts and so the service currently will only alert you when there are new security updates against your stage-packages. In this manner, you can choose not to rebuild your snap (eg, since it doesn’t use the affected functionality of the vulnerable package) and not be nagged every day that you are out of date.

As nice as that is, sometimes you want to check these things yourself or perhaps hook the alerts into some form of automation or tool. While the review-tools had all of the pieces so you could do this, it wasn’t as straightforward as it could be. Now with the latest stable revision of the review-tools, this is easy:

$ sudo snap install review-tools $ review-tools.check-notices \ ~/snap/review-tools/common/review-tools_656.snap {'review-tools': {'656': {'libapt-inst2.0': ['3863-1'], 'libapt-pkg5.0': ['3863-1'], 'libssl1.0.0': ['3840-1'], 'openssl': ['3840-1'], 'python3-lxml': ['3841-1']}}}

The review-tools are a strict mode snap and while it plugs the home interface, that is only for convenience, so I typically disconnect the interface and put things in its SNAP_USER_COMMON directory, like I did above.

Since now it is super easy to check a snap on disk, with a little scripting and a cron job, you can generate a machine readable report whenever you want. Eg, can do something like the following:

$ cat ~/bin/check-snaps #!/bin/sh set -e snaps="review-tools/stable rsync-jdstrand/edge" tmpdir=$(mktemp -d -p "$HOME/snap/review-tools/common") cleanup() { rm -fr "$tmpdir" } trap cleanup EXIT HUP INT QUIT TERM cd "$tmpdir" || exit 1 for i in $snaps ; do snap=$(echo "$i" | cut -d '/' -f 1) channel=$(echo "$i" | cut -d '/' -f 2) snap download "$snap" "--$channel" >/dev/null done cd - >/dev/null || exit 1 /snap/bin/review-tools.check-notices "$tmpdir"/*.snap

or if  you already have the snaps on disk somewhere, just do:

$ /snap/bin/review-tools.check-notices /path/to/snaps/*.snap

Now can add the above to cron or some automation tool as a reminder of what needs updates. Enjoy!

Ubuntu Podcast from the UK LoCo: S11E99 – Listener Get Together

Enj, 31/01/2019 - 4:00md

We’re having a Get Together in Reading, UK on Saturday March 16th 2019. The exact venue is not decided yet, but will be in Reading town centre.

We’d like to gauge how many people might come, so please sign in and mark yourself as wanting to come.

It’s Season 11 Episode 99 of the Ubuntu Podcast! Mark Johnson is connected and speaking to your brain.

Back in November 2018 we conducted a poll on Twitter to see what kind of social event our listeners were interested in. Overwhelmingly (and perhaps unsurprisingly) you chose a Pub/Restaurant meet, so that’s what we’re doing.

It’ll be a relaxed social event with the presenters having a beer or fruit-based drink, and maybe some food to be decided later.

Do let us know if you’d like to come by marking yourself attending here.

That’s all for this week! You can listen to the Ubuntu Podcast back catalogue on YouTube. If there’s a topic you’d like us to discuss, or you have any feedback on previous shows, please send your comments and suggestions to or Tweet us or Comment on our Facebook page or comment on our Google+ page or comment on our sub-Reddit.

Marcin Juszkiewicz: Upgraded system on my server

Mar, 29/01/2019 - 9:29pd

My current server is few years old. And now runs plain Debian.


I started using that server during my work at Canonical. So it got Ubuntu installed. According to OVH panel it was 13.04 release. Then 13.10, 14.04 and finally 16.04 landed. In pain. Took me two days to get it working again (mail issues).

At that time I decided that it will not get any Ubuntu update. The plan was to upgrade to proper Debian release. And Buster will get frozen soon…

One day I took a list of installed packages and started “ubuntu:xenial” container. Test shown will it be big work to do such upgrade. Turned out that not that much.

Today I saw a post saying that php 7.1 goes into “security fixes only” mode. And I had 7.0 in use… So decided that ok, this is the time.

Let’s go with upgrade

Logged in, added Debian repository, APT keys and started with installation of 4.19 kernel. And rebooted to it.

Machine started without issues so I started upgrade. Used aptitude as usual. There were 10-20 conflicts to solve and then package installation started.

Few file conflicts was on a way but APT handled most of them without issues. Two or free packages I had to take care by hand.

Next step was replacing remaining Ubuntu packages with Debian ones. Or removing them completely. Easy, smooth work.

Getting services running

After copying php-fpm config files from 7.0 to 7.3 release my blog went online.

Then some edits to Courier auth daemon config files (adding “marker”) and mails started flowing in both directions. But if you got mail that my mail account was not found on a server then send it again.

Finally reboot. To make sure that everything works. Fingers crossed, “reboot”. Came back online like always. No issues.

Why Debian?

Someone may ask why not Fedora or RHEL or CentOS? I work at Red Hat now, right?

Yes, I do. But Debian is operating system I know most. It’s tools etc. Also upgrade was possible to do online. Otherwise I would have to start with reinstalation.

Now I have only one machine running Ubuntu. My wife’s laptop. But it is “no way” zone. It works for her and we have an agreement that I do not touch it. Unless requested.

Related posts:
  1. From a diary of AArch64 porter — parallel builds
  2. Let’s compare some cpu ;)
  3. On my own again

Kurt von Finck: So I created a subreddit for interesting G+ refugees. Emphasis on interesting.

Hën, 28/01/2019 - 9:48md

So I created a subreddit for interesting G+ refugees. Emphasis on interesting.

Come and play. Be suave. Don’t be a dick.

Edward Morbius

Kee Hinckley

Rugger Ducky

Sarah Lester

Ward A

Tim S

Matthew H

Yoko F Thunders

Dave Thompson

Grumpy Cat

catty _big

Dan Ramos

Di Cleverly

and the many more I know I’ve forgotten because I need an fud. And invite your friends!

Omer Akram: Control GPIO pins on a RaspberryPi 3 running Ubuntu Core 18, remotely (part 1/4)

Dje, 27/01/2019 - 10:00md
Ubuntu Core 18 is out and one of the features that it packs with it is a set of snapd interfaces to access GPIO pins on the Raspberry Pi 2/3 in a fully confined snap. This enables one to just flash Ubuntu Core 18 on a micro sd card, boot, install a snap (which I author), connect a few interfaces and start controlling relays attached to a Raspberry Pi 2/3.

If you don't have Ubuntu Core 18 already installed, you can see the install instructions here

To get started (assuming you have Ubuntu Core 18 installed and have working ssh access to the Pi), you need to install a snap that exposes the said functionality over the network (local)

$ snap install pigpio

The above command installed the pigpio server, which automatically starts in the background. The server could take as much as 30 seconds to start, you have been warned.

We also need to allow the newly installed snap to access a few GPIO pins

$ snap connect pigpio:gpio pi:bcm-gpio-4
$ snap connect pigpio:gpio pi:bcm-gpio-5
$ snap connect pigpio:gpio pi:bcm-gpio-6
$ snap connect pigpio:gpio pi:bcm-gpio-12
$ snap connect pigpio:gpio pi:bcm-gpio-13
$ snap connect pigpio:gpio pi:bcm-gpio-17
$ snap connect pigpio:gpio pi:bcm-gpio-18
$ snap connect pigpio:gpio pi:bcm-gpio-19
$ snap connect pigpio:gpio pi:bcm-gpio-20
$ snap connect pigpio:gpio pi:bcm-gpio-21
$ snap connect pigpio:gpio pi:bcm-gpio-22
$ snap connect pigpio:gpio pi:bcm-gpio-23
$ snap connect pigpio:gpio pi:bcm-gpio-24
$ snap connect pigpio:gpio pi:bcm-gpio-26

The above pin numbers might look strange, but if you read a bit about the Raspberry Pi 3's GPIO pinout, you will realize, I only selected the "basic" pins, you are however free to connect all GPIO pin interfaces.

The pigpio snap that we installed above exposes the GPIO functionality over WAMP protocol and http. The HTTP implementation is very basic and allows to "turn on" and "turn off" a GPIO pin and get current state(s) of the pins.

Note: below commands assumes you have httpie installed (snap install http).

To get the state of all pins

    $ http POST http://raspberry_pi_ip:5021/call procedure=io.crossbar.pigpio-wamp.get_states

If we only want the state of a specific pin

    $ http POST http://raspberry_pi_ip:5021/call procedure=io.crossbar.pigpio-wamp.get_state args:='[4]'

To "turn on" a pin

    $ http POST http://raspberry_pi_ip:5021/call procedure=io.crossbar.pigpio-wamp.turn_on args:='[4]'

To "turn off"

    $ http POST http://raspberry_pi_ip:5021/call procedure=io.crossbar.pigpio-wamp.turn_off args:='[4]'

I am skipping talking about the WAMP based API for this, to keep this blogpost short, I must add though, that the WAMP implementation is much more powerful than the http one, especially because it has "event publishing", imagine multiple people controlling a single GPIO pin from different clients, we publish an event that can be subscribed to, hence ensuring all client apps stay in sync. I'll talk about this in a different blog post. In a later post, I will also be talking about making the GPIO pins accessible over the internet.

For me personally, I have a few projects for home and one for my co-working space that I plan to accomplish using this.

The code lives on github

Rhonda D&#39;Vine: Enigma

Pre, 18/01/2019 - 4:57md

Just the other day a working colleague asked me what kind of music I listen to, especially when working. It's true, music helps me to focus better and work more concentrated. But it obviously depends on what kind of music it is. And there is one project I come to every now and then. The name is Enigma. It's not disturbing, good for background, with soothing and non-intrusive vocals. Here are the songs:

  • Return To Innocence: This is quite likely the song you know from them, which also got me hooked up originally.
  • Push The Limits: A powerful song. The album version is even a few minutes longer.
  • Voyageur: Love the rhythm and theme in this song.

Like always, enjoy.

/music | permanent link | Comments: 0 |

Stephen Michael Kellat: Following The Drum Beat

Enj, 17/01/2019 - 5:17pd

If you've followed the news in the United States of America, you've probably seen something called a "government shutdown". In non-USA terms, the legislature is refusing to grant supply to the executive. In parliamentary systems of government, the government would fall and there would be an election. In the United States we just get this current weird situation where parts of the government are funded and other parts aren't. Especially disconcerting is that the majority of federal law enforcement agencies have their employees working without pay until the impasse is resolved.

You might be thinking that that is an academic exercise that you have no connection to at all. As a member of the community, though, I've been recalled to duty Thursday and I won't be paid at all until this impasse is resolved. Thursday will be the 27th day of this debacle. I've probably made it a bit more real for you now compared to any news reports you've seen on the BBC, CanBC, AusBC, or from your favorite wire service.

Currently the legal guidance offered is that the civilian staff returning to duty without pay will be prosecuted under a choice of statutes if they set up "GoFundMe"-type efforts to seek funds to ease the lack of cashflow. One possibility is just as a criminal ethics violation but another is under the prohibition on accepting bribes. Due to some perverse consequences of how various mandatory separation payments are structured and the current constitutional prohibitions on payments without valid appropriations as well as due to restrictions on what the HR staff can do right now, I technically cannot quit my job at the moment.

Remember, I am working to build up Erie Looking Productions and am still seeking clients as well as jobs for handling. There is a version of a resume posted to LinkedIn and my mobility is constrained temporarily while some tricky things would have to be worked out. Problems are not insurmountable but they certainly are big. Once the current unpleasantness is resolved, I am more than likely able to cross borders to places in the English-speaking Pacific to work if I don't find something based in the USA.

As to software-related matters, the fiddling with Greenstone that I had coming up is on hold. I really wanted to see if I could get it to compile on a Raspberry Pi 3B+ that runs Ubuntu. It doesn't seem too cross-architecture portable. It does seem like an excellent candidate for snapcrafters to take a try working on, though.

Simon Raffeiner: Updating Micron 1100 Series SSD firmware on Linux

Mër, 16/01/2019 - 7:13md

I've had quite a number of performance-related issues with Micron 1100 Series M.2 SATA SSDs in various constellations over the last 18 months. Turns out a firmware update to a rather "secret" version fixes that.

The post Updating Micron 1100 Series SSD firmware on Linux appeared first on LIEBERBIBER.

Kees Cook: security things in Linux v4.20

Mar, 25/12/2018 - 12:59pd

Previously: v4.19.

Linux kernel v4.20 has been released today! Looking through the changes, here are some security-related things I found interesting:

stackleak plugin

Alexander Popov’s work to port the grsecurity STACKLEAK plugin to the upstream kernel came to fruition. While it had received Acks from x86 (and arm64) maintainers, it has been rejected a few times by Linus. With everything matching Linus’s expectations now, it and the x86 glue have landed. (The arch-specific portions for arm64 from Laura Abbott actually landed in v4.19.) The plugin tracks function calls (with a sufficiently large stack usage) to mark the maximum depth of the stack used during a syscall. With this information, at the end of a syscall, the stack can be efficiently poisoned (i.e. instead of clearing the entire stack, only the portion that was actually used during the syscall needs to be written). There are two main benefits from the stack getting wiped after every syscall. First, there are no longer “uninitialized” values left over on the stack that an attacker might be able to use in the next syscall. Next, the lifetime of any sensitive data on the stack is reduced to only being live during the syscall itself. This is mainly interesting because any information exposures or side-channel attacks from other kernel threads need to be much more carefully timed to catch the stack data before it gets wiped.

Enabling CONFIG_GCC_PLUGIN_STACKLEAK=y means almost all uninitialized variable flaws go away, with only a very minor performance hit (it appears to be under 1% for most workloads). It’s still possible that, within a single syscall, a later buggy function call could use “uninitialized” bytes from the stack from an earlier function. Fixing this will need compiler support for pre-initialization (this is under development already for Clang, for example), but that may have larger performance implications.

raise faults for kernel addresses in copy_*_user()

Jann Horn reworked x86 memory exception handling to loudly notice when copy_{to,from}_user() tries to access unmapped kernel memory. Prior this, those accesses would result in a silent error (usually visible to callers as EFAULT), making it indistinguishable from a “regular” userspace memory exception. The purpose of this is to catch cases where, for example, the unchecked __copy_to_user() is called against a kernel address. Fuzzers like syzcaller weren’t able to notice very nasty bugs because writes to kernel addresses would either corrupt memory (which may or may not get detected at a later time) or return an EFAULT that looked like things were operating normally. With this change, it’s now possible to much more easily notice missing access_ok() checks. This has already caught two other corner cases even during v4.20 in HID and Xen.

spectre v2 userspace mitigation

The support for Single Thread Indirect Branch Predictors (STIBP) has been merged. This allowed CPUs that support STIBP to effectively disable Hyper-Threading to avoid indirect branch prediction side-channels to expose information between userspace threads on the same physical CPU. Since this was a very expensive solution, this protection was made opt-in (via explicit prctl() or implicitly under seccomp()). LWN has a nice write-up of the details.

jump labels read-only after init

Ard Biesheuvel noticed that jump labels don’t need to be writable after initialization, so their data structures were made read-only. Since they point to kernel code, they might be used by attackers to manipulate the jump targets as a way to change kernel code that wasn’t intended to be changed. Better to just move everything into the read-only memory region to remove it from the possible kernel targets for attackers.

VLA removal finished

As detailed earlier for v4.17, v4.18, and v4.19, a whole bunch of people answered my call to remove Variable Length Arrays (VLAs) from the kernel. I count at least 153 commits having been added to the kernel since v4.16 to remove VLAs, with a big thanks to Gustavo A. R. Silva, Laura Abbott, Salvatore Mesoraca, Kyle Spiers, Tobin C. Harding, Stephen Kitt, Geert Uytterhoeven, Arnd Bergmann, Takashi Iwai, Suraj Jitindar Singh, Tycho Andersen, Thomas Gleixner, Stefan Wahren, Prashant Bhole, Nikolay Borisov, Nicolas Pitre, Martin Schwidefsky, Martin KaFai Lau, Lorenzo Bianconi, Himanshu Jha, Chris Wilson, Christian Lamparter, Boris Brezillon, Ard Biesheuvel, and Antoine Tenart. With all that done, “-Wvla” has been added to the top-level Makefile so we don’t get any more added back in the future.

Given the holidays, Linus opened the merge window before v4.20 was released, letting everyone send in pull requests in the week leading up to the release. v4.21 is in the making. :) Happy New Year everyone!

Edit: clarified stackleak details, thanks to Alexander Popov.

© 2018, Kees Cook. This work is licensed under a Creative Commons Attribution-ShareAlike 3.0 License.

Julian Andres Klode: An Introduction to Go

Hën, 24/12/2018 - 3:15md

(What follows is an excerpt from my master’s thesis, almost all of section 2.1, quickly introducing Go to people familiar with CS)

Go is an imperative programming language for concurrent programming created at and mainly developed by Google, initially mostly by Robert Griesemer, Rob Pike, and Ken Thompson. Design of the language started in 2007, and an initial version was released in 2009; with the first stable version, 1.0 released in 2012 1.

Go has a C-like syntax (without a preprocessor), garbage collection, and, like its predecessors devloped at Bell Labs – Newsqueak (Rob Pike), Alef (Phil Winterbottom), and Inferno (Pike, Ritchie, et al.) – provides built-in support for concurrency using so-called goroutines and channels, a form of co-routines, based on the idea of Hoare’s ‘Communicating Sequential Processes’ 2.

Go programs are organised in packages. A package is essentially a directory containing Go files. All files in a package share the same namespace, and there are two visibilities for symbols in a package: Symbols starting with an upper case character are visible to other packages, others are private to the package:

func PublicFunction() { fmt.Println("Hello world") } func privateFunction() { fmt.Println("Hello package") } Types

Go has a fairly simple type system: There is no subtyping (but there are conversions), no generics, no polymorphic functions, and there are only a few basic categories of types:

  1. base types: int, int64, int8, uint, float32, float64, etc.
  2. struct
  3. interface - a set of methods
  4. map[K, V] - a map from a key type to a value type
  5. [number]Type - an array of some element type
  6. []Type - a slice (pointer to array with length and capability) of some type
  7. chan Type - a thread-safe queue
  8. pointer *T to some other type
  9. functions
  10. named type - aliases for other types that may have associated methods:

    type T struct { foo int } type T *T type T OtherNamedType

    Named types are mostly distinct from their underlying types, so you cannot assign them to each other, but some operators like + do work on objects of named types with an underlying numerical type (so you could add two T in the example above).

Maps, slices, and channels are reference-like types - they essentially are structs containing pointers. Other types are passed by value (copied), including arrays (which have a fixed length and are copied).


Conversions are the similar to casts in C and other languages. They are written like this:

TypeName(value) Constants

Go has “untyped” literals and constants.

1 // untyped integer literal const foo = 1 // untyped integer constant const foo int = 1 // int constant

Untyped values are classified into the following categories: UntypedBool, UntypedInt, UntypedRune, UntypedFloat, UntypedComplex, UntypedString, and UntypedNil (Go calls them basic kinds, other basic kinds are available for the concrete types like uint8). An untyped value can be assigned to a named type derived from a base type; for example:

type someType int const untyped = 2 // UntypedInt const bar someType = untyped // OK: untyped can be assigned to someType const typed int = 2 // int const bar2 someType = typed // error: int cannot be assigned to someType Interfaces and ‘objects’

As mentioned before, interfaces are a set of methods. Go is not an object-oriented language per se, but it has some support for associating methods with named types: When declaring a function, a receiver can be provided - a receiver is an additional function argument that is passed before the function and involved in the function lookup, like this:

type SomeType struct { ... } func (s *SomeType) MyMethod() { } func main() { var s SomeType s.MyMethod() }

An object implements an interface if it implements all methods; for example, the following interface MyMethoder is implemented by *SomeType (note the pointer), and values of *SomeType can thus be used as values of MyMethoder. The most basic interface is interface{}, that is an interface with an empty method set - any object satisfies that interface.

type MyMethoder interface { MyMethod() }

There are some restrictions on valid receiver types; for example, while a named type could be a pointer (for example, type MyIntPointer *int), such a type is not a valid receiver type.

Control flow

Go provides three primary statements for control flow: if, switch, and for. The statements are fairly similar to their equivalent in other C-like languages, with some exceptions:

  • There are no parentheses around conditions, so it is if a == b {}, not if (a == b) {}. The braces are mandatory.
  • All of them can have initialisers, like this

    if result, err := someFunction(); err == nil { // use result }

  • The switch statement can use arbitrary expressions in cases

  • The switch statement can switch over nothing (equals switching over true)

  • Cases do not fall through by default (no break needed), use fallthrough at the end of a block to fall through.

  • The for loop can loop over ranges: for key, val := range map { do something }


The keyword go spawns a new goroutine, a concurrently executed function. It can be used with any function call, even a function literal:

func main() { ... go func() { ... }() go some_function(some_argument) } Channels

Goroutines are often combined with channels to provide an extended form of Communicating Sequential Processes 2. A channel is a concurrent-safe queue, and can be buffered or unbuffered:

var unbuffered = make(chan int) // sending blocks until value has been read var buffered = make(chan int, 5) // may have up to 5 unread values queued

The <- operator is used to communicate with a single channel.

valueReadFromChannel := <- channel otherChannel <- valueToSend

The select statement allows communication with multiple channels:

select { case incoming := <- inboundChannel: // A new message for me case outgoingChannel <- outgoing: // Could send a message, yay! } The defer statement

Go provides a defer statement that allows a function call to be scheduled for execution when the function exits. It can be used for resource clean-up, for example:

func myFunc(someFile io.ReadCloser) { defer someFile.close() /* Do stuff with file */ }

It is of course possible to use function literals as the function to call, and any variables can be used as usual when writing the call.

Error handling

Go does not provide exceptions or structured error handling. Instead, it handles errors by returning them in a second or later return value:

func Read(p []byte) (n int, err error) // Built-in type: type error interface { Error() string }

Errors have to be checked in the code, or can be assigned to _:

n0, _ := Read(Buffer) // ignore error n, err := Read(buffer) if err != nil { return err }

There are two functions to quickly unwind and recover the call stack, though: panic() and recover(). When panic() is called, the call stack is unwound, and any deferred functions are run as usual. When a deferred function invokes recover(), the unwinding stops, and the value given to panic() is returned. If we are unwinding normally and not due to a panic, recover() simply returns nil. In the example below, a function is deferred and any error value that is given to panic() will be recovered and stored in an error return value. Libraries sometimes use that approach to make highly recursive code like parsers more readable, while still maintaining the usual error return value for public functions.

func Function() (err error) { defer func() { s := recover() switch s := s.(type) { // type switch case error: err = s // s has type error now default: panic(s) } } } Arrays and slices

As mentioned before, an array is a value type and a slice is a pointer into an array, created either by slicing an existing array or by using make() to create a slice, which will create an anonymous array to hold the elements.

slice1 := make([]int, 2, 5) // 5 elements allocated, 2 initialized to 0 slice2 := array[:] // sliced entire array slice3 := array[1:] // slice of array without first element

There are some more possible combinations for the slicing operator than mentioned above, but this should give a good first impression.

A slice can be used as a dynamically growing array, using the append() function.

slice = append(slice, value1, value2) slice = append(slice, arrayOrSlice...)

Slices are also used internally to represent variable parameters in variable length functions.


Maps are simple key-value stores and support indexing and assigning. They are not thread-safe.

someValue := someMap[someKey] someValue, ok := someMap[someKey] // ok is false if key not in someMap someMap[someKey] = someValue
  1. Frequently Asked Questions (FAQ) - The Go Programming Language [return]
  2. HOARE, Charles Antony Richard. Communicating sequential processes. Communications of the ACM, 1978, 21. Jg., Nr. 8, S. 666-677. [return]

Daniel Pocock: Merry Christmas from the Balkans

Dje, 23/12/2018 - 11:27md

This Christmas I'm visiting the Balkans again. It is the seventh time in the last two years that I have been fortunate enough to visit this largely undiscovered but very exciting region of Europe.

A change of name

On Saturday I visited Skopje, the capital of Macedonia. Next month their country will finalize their name change to the Republic of Northern Macedonia.


From Skopje, I travelled north to Prishtina, the capital of Kosovo.

I had dinner with four young women who have become outstanding leaders in the free software movement in the region, Albiona, Elena, Amire and Enkelena.

The population of Kosovo is over ninety percent Muslim, not everybody observes Christmas as a religious festival but nonetheless the city of Prishtina is decorated beautifully with several large trees in the pedestrianised city centre.

Dougie Richardson: Passwordless SSH access on a Pi

Dje, 23/12/2018 - 12:25md

Passwordless SSH access is convenient, especially as everything is on my local network. I only really access the Pi remotely and you can configure it to use RSA keys. I’m on Ubuntu Linux so open a terminal and create an RSA key (if you don’t have one): You’ll need to upload it to the Pi: […]

The post Passwordless SSH access on a Pi appeared first on The Midlife Geek.