Site Map - skip to main content - dyslexic font - mobile - text - print

Hacker Public Radio

Your ideas, projects, opinions - podcasted.

New episodes Monday through Friday.


Yannick the french guy from Switzerland

Host Image
Host ID: 370

I'm Yannick. I'm french, I live in Switzerland. Hence, the french guy from Switzerland !
I'm a geek, a father, a podcaster.
I'm interested in programming, of all sorts, in all kinds of languages.
I like to tinker with basic electronics components, especially LEDs !
I have half a dozen Raspberry Pis, and probably twice that amount of micro controllers of all sorts.
I have many websites :

episodes: 3

hpr2740 :: Pop!_OS 18.10 (quick) review

Released on 2019-02-01 under a CC-BY-SA license.

This episode is a re-edition of the review of Pop_OS! I did for TuxJam back in December 2018. Pop_OS! is published by System76.

hpr2711 :: Raspberry Pi 3A+ Review

Released on 2018-12-24 under a CC-BY-SA license.

Raspberry Pi 3A+ review

In this episode of HPR, I will do a quick review of the Raspberry Pi 3A+, the latest release of the Raspberry Pi foundation.

Raspberry Pi 3A+ Raspberry Pi 3A+

The Raspberry Pi 3A+ has almost the same hardware as its big brother/sister the 3B+ :

  • BCM2837 BO SOC (system on chip), a quad core 64-bit ARM v8 processor, running at 1.4 GHz
  • On board wireless :
    • WiFi : 2.4 and 5 GHz 802.11 c/y/n/ac
    • Bluetooth : 4.2 and BLE
  • MicroSD card for storing the operating system and the data
  • Full size HDMI connector
  • 3.5 mm jack connector for audio and composite video output
  • MicroUSB connector for the power supply
  • 40-pin header with the same pinout as every other Raspberry Pi

The differences are :

  • Only one full size USB connector, instead of four on the 3B+
  • No ethernet connector
  • Only 512 MB or SDRAM instead of 1 GB on the 3B+

The Raspberry Pi 3A+ is 6.7 x 5.6 cm (2.6 x 2.2 in) and 11 mm high (.45 in). But if you plug a ribbon in the header, then it takes a lot of space.

Raspberry Pi 3A+

In this case, it’s probably better to unsolder the header, and solder a right angle header in place, so the pins are pointing to the side of the board and not upwards

Raspberry Pi 3A+ Raspberry Pi 3A+

With a bit of caution and the help of some desoldering wick, it’s not a complex operation, because there is no component near the GPIO header.

Of course if you plan on using a HAT, then you’re better off using the straight header. The Raspberry Pi 3A+ is actually the same size than a standard HAT.

Raspberry Pi 3A+ Raspberry Pi 3A+

Use case

Since the Raspberry Pi 3A+ doesn’t have an ethernet port, I think I will not use it for server stuff like Mosquitto or Pi-Hole, for which a good network connection is required. Also, those servers sometimes need a keyboard and a mouse, and with only one USB port, that’s not too practical.

For me, the A+ will be used to upgrade projects currently using a Raspberry Pi ZeroW, and for which I need a little more power. The on board WiFi and the small form factor, combined with the extra power, makes the 3A+ an ideal replacement for the ZeroW.


The sound used for the opening and closing sequence is Speaker X-Clash by Daniel H, and is released under a CC-BY-NC license.

hpr2664 :: My git workflow

Released on 2018-10-18 under a CC-0 license.

My git workflow

In this episode of HPR I present the workflow I use to contribute to opensource projects using git. I have no idea if this workflow is something that is commonly used, but it is working for me, so I thought I’d share it with the HPR community.

The first thing I do is fork the project I want to contribute to. This is done on github most of the time, although this workflow can work on gitlab, bitbucket, or even some self hosted git platform.

Once the project is forked, I clone it on my machine :

$ git clone git://server/path/to/myproject.git

Git automatically names my remote project origin.

Then I add a reference to the original project :

$ git remote add upstream https://server/path/to/originalproject.git

Now my local repository references my fork under the name origin and the original project under the name upstream.

In this workflow, I never work on the master branch. So, when I need to fix a bug for example, I create a new branch :

$ git checkout -b bugfix

I can then make changes, test my code, make sure everything is ok, stage and commit my changes :

$ git add .
$ git commit -m "commit message"

Now I need to push this local branch to my repository on github :

$ git push -u origin bugfix

Since I forked the original project, github knows that origin and upstream are linked. If there are no conflicts, github will show me a big green button to create a pull request. Once the pull request is created, I just have to wait for the maintainer to merge it in upstream’s master branch. Then, I need to sync both my local copy and my fork on github with the original project. In order to do that, on my local copy, I checkout my master branch, fetch upstream’s changes, and merge them :

$ git checkout master
$ git fetch upstream
$ git merge upstream/master

Now my local master branch is ahead of origin’s master branch, so I push those changes to github :

$ git push

I don’t need the bugfix branches (the local one and the github one), so I can delete those :

$ git branch -d bugfix
$ git push origin -d bugfix

And now, my local repository is even with both origin and upstream, and I can start again.

To summarize, here’s the complete workflow :

$ git checkout -b myawesomefeature
$ git add .
$ git commit -m "Awesome commit message"
$ git push -u origin myawesomefeature

Create a pull request, wait for the maintainer to merge it.

$ git checkout master
$ git fetch upstream
$ git merge upstream/master
$ git push
$ git branch -d myawesomefeature
$ git push origin -d myawesomefeature

Become a Correspondent