You are here

Planet Ubuntu

Subscribe to Feed Planet Ubuntu
Planet Ubuntu -
Përditësimi: 3 ditë 12 orë më parë

Podcast Ubuntu Portugal: Ep 108 – Sim podemos

Enj, 17/09/2020 - 11:45md

Em semana se regresso às aulas, mais 1 episódio no melhor podcast sobre Ubuntu, software livres e outras cenas, de Portugal. Raspberry pi, marmitas e pinetabs fazem parte deste fantástico cardápio.

Já sabem: oiçam, subscrevam e partilhem!


Podem apoiar o podcast usando os links de afiliados do Humble Bundle, porque ao usarem esses links para fazer uma compra, uma parte do valor que pagam reverte a favor do Podcast Ubuntu Portugal.
E podem obter tudo isso com 15 dólares ou diferentes partes dependendo de pagarem 1, ou 8.
Achamos que isto vale bem mais do que 15 dólares, pelo que se puderem paguem mais um pouco mais visto que têm a opção de pagar o quanto quiserem.

Se estiverem interessados em outros bundles não listados nas notas usem o link e vão estar também a apoiar-nos.

Atribuição e licenças

Este episódio foi produzido por Diogo Constantino e Tiago Carrondo e editado por Alexandre Carrapiço, o Senhor Podcast.

A música do genérico é: “Won’t see it comin’ (Feat Aequality & N’sorte d’autruche)”, por Alpha Hydrae e está licenciada nos termos da [CC0 1.0 Universal License](

Este episódio e a imagem utilizada estão licenciados nos termos da licença: Attribution-NonCommercial-NoDerivatives 4.0 International (CC BY-NC-ND 4.0), cujo texto integral pode ser lido aqui. Estamos abertos a licenciar para permitir outros tipos de utilização, contactem-nos para validação e autorização.

Ubuntu Podcast from the UK LoCo: S13E26 – The evil eye

Enj, 17/09/2020 - 4:00md

This week we’ve been playing with arcade boards and finishing DIY in the kitchen. We discuss if old technology is more fun than new technology, bring you a command line love and go over all your wonderful feedback.

It’s Season 13 Episode 26 of the Ubuntu Podcast! Alan Pope, Mark Johnson and Martin Wimpress are connected and speaking to your brain.

In this week’s show:

  • We discuss what we’ve been up to recently:
  • We discuss if old technology is inherently more fun than new technology?
  • We share a Command Line Lurve:
opusenc in.wav --downmix-mono --bitrate 6 --cvbr --framesize 60 out.opus

That’s all for this week! 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 Toot us or Comment on our Facebook page or comment on our sub-Reddit.

Ubuntu Blog: Design and Web team summary – 16th September 2020

Mër, 16/09/2020 - 10:58md

The web team here at Canonical run two-week iterations. Here are some of the highlights of our completed work from this iteration.

Web squad

Our Web Squad develops and maintains most of Canonical’s promotional sites like, and more.

CloudNative Days Tokyo 2020 <noscript> <img alt="" src=",q_auto,fl_sanitize,w_720/" width="720" /> </noscript>

This year will see a lot of physical events move to a virtual event format.  However, most virtual booths bring low engagement with the audience, limit the abilities to do demos and showcase interactive content and have very low conversion rates.

Visit the CloudNative Days Tokyo 2020

New homepage for

We released a refreshed homepage for Providing a lot more outreach for different audiences.

Visit the new homepage

<noscript> <img alt="" src=",q_auto,fl_sanitize,w_720/" width="720" /> </noscript> EdgeX page on

A new page with information about the exciting EdgeX ecosystem. Allowing you to sign up for our new EdgeX newsletter.

Visit the EdgeX page 

<noscript> <img alt="" src=",q_auto,fl_sanitize,w_720/" width="720" /> </noscript> Brand

The Brand team develop our design strategy and create the look and feel for the company across many touch-points, from web, documents, exhibitions, logos and video.

Brand Hierarchy

We collated all of the work we have done so far, analysed the content and decided on the outcomes and next steps to complete the system and roll it out across all areas of the company.

<noscript> <img alt="" src=",q_auto,fl_sanitize,w_720/" width="720" /> </noscript> <noscript> <img alt="" src=",q_auto,fl_sanitize,w_720/" width="720" /> </noscript> Charmed Kubeflow

Illustrations and web design for the updated Kubeflow page.

<noscript> <img alt="" src=",q_auto,fl_sanitize,w_720/" width="720" /> </noscript> <noscript> <img alt="" src=",q_auto,fl_sanitize,w_720/" width="720" /> </noscript> <noscript> <img alt="" src=",q_auto,fl_sanitize,w_720/" width="720" /> </noscript> Document Hierarchy testing

We took the templates developed in the last iteration and inserted real content to make sure that the styles and typography are robust enough to roll out.

<noscript> <img alt="" src=",q_auto,fl_sanitize,w_720/" width="720" /> </noscript> <noscript> <img alt="" src=",q_auto,fl_sanitize,w_720/" width="720" /> </noscript> Livechat branding

Initial colour and design work to brand the Eye catcher and Livechat instance on

<noscript> <img alt="" src=",q_auto,fl_sanitize,w_720/" width="720" /> </noscript> MAAS

The MAAS squad develops the UI for the MAAS project.

MAAS new CLI iteration 2

Last week, we have been testing out the CLI prototype with 6 MAAS CLI users to collect feedback on what we can do to improve our current CLI experience. 

The first thing we tested out was the concept of the initial help or what our testers mostly referred to as “cheat sheet”.

When a user types “maas” or “maas –help”, you will see a cheat sheet as a guideline to help you do basic operations. In the first prototype, we introduced the concept of a primary object (machine), so by default, MAAS interprets an action against machines as an object when no object is indicated. 

<noscript> <img alt="" src=",q_auto,fl_sanitize,w_720/" width="720" /> </noscript>

We received a lot of positive feedback for this concept and our testers wanted to see what other objects are available in the CLI. So to provide learnability, we added “Hints” to this page and indicate the current version of MAAS as well as other useful information.

One use case was frequently mentioned during the test regarding how to operate bulk actions for multiple MAASes or data centres.

<noscript> <img alt="" src=",q_auto,fl_sanitize,w_720/" width="720" /> </noscript>

Breaking down MAAS objects. In the current CLI, we have both singular and plural forms of object as a way to indicate collection services VS individual services. In this version, we stripped down all plural objects and broke them down into different categories for readability. We’ve also added a link to the documentation page for further readings. 

Highlight: 5 out of 6 users mentioned that they don’t like reading the documentation and would not bother to read them because when they are working with the CLI they feel like they have to start the search over again in the documentation page. It felt like they have to do a double search to get to the point where they get the answer. So to reduce that hassle, we attached the right documentation link to the relevant commands help page. 

In this prototype, we also introduced the concept of the primary profile, which is reflected in the current prompt. A user may log in to multiple profiles and set one of the profiles as their primary profile. When a user wants to take actions on multiple profiles such as deploying 10 identical machines 3 MAAS profiles, they just need to apply a profile flag to their deployment action.

<noscript> <img alt="" src=",q_auto,fl_sanitize,w_720/" width="720" /> </noscript>

The user will always see their current profile when they take action. This is to help prevent our users from making mistakes and that they are aware of their current environment.

<noscript> <img alt="" src=",q_auto,fl_sanitize,w_720/" width="720" /> </noscript> <noscript> <img alt="" src=",q_auto,fl_sanitize,w_720/" width="720" /> </noscript>

To enhance the experience for learnability, we also try to break down the help page to be more meaningful. This is an example of the new help page. It will show you a brief description of the action, options, different ways to customise the outputs, examples, and related commands. For instance, maas list will list multiple or individual node description in a compact format as an overview. Whereas a related command is “maas show”, where a user can drill down detailed information of a particular machine in an elaborate manner. 

After going through this user test, our team has agreed to make the default experience in the CLI compatible with our scripting users because we have a separate MAAS UI that can achieve the same purpose. However, if a user prefers to do things in MAAS using the CLI and expecting a beginner’s experience, they can use the” –interactive “ flag or “ -i” to use the interactive prompt.

<noscript> <img alt="" src=",q_auto,fl_sanitize,w_720/" width="720" /> </noscript> <noscript> <img alt="" src=",q_auto,fl_sanitize,w_720/" width="720" /> </noscript>

When a user indicates -i in the CLI, they will be presented with an interactive prompt where, it will ask for required information for the deployment such as OS, release, kernel, setting a machine is a KVM host, and customising cloud-init user-data.

By default, “maas deploy” will throw an error, because a user needs to supply information about the machine or a characteristic of a collection of machines they wish to deploy. 

<noscript> <img alt="" src=",q_auto,fl_sanitize,w_720/" width="720" /> </noscript>

However, if an error occurs, the prompt will provide guidelines and suggestions including documentation to help our users perform an action correctly.

Since the default experience is tailored to scripting users, by default a user will get the prompt back when they perform an action. They will also be informed that the machine(s) they deployed are running in the background and they may use any of these suggestions to check up on the status of the deployment. 

<noscript> <img alt="" src=",q_auto,fl_sanitize,w_720/" width="720" /> </noscript>

If a user wishes to have their prompt block when performing an action and want to see if it’s running, they can use the --wait flag to see the waiting state of the CLI. This will show a broken down version of the running task, a loading indication, and the time elapse. Time is quite important for MAAS users because for many users, if something is processing longer than usual, they would rather have that process aborted and reboot. 

<noscript> <img alt="" src=",q_auto,fl_sanitize,w_720/" width="720" /> </noscript>

What’s next?

  1. We are still working to define a better way to help our users debug when an error occurs. So the error state is another important piece that we are focusing on. Our current goal is to enhance the learnability aspects of our CLI and help our users recover from their errors or mistakes. 
  2. Another interesting feature is partial matching of the machine name. Currently, MAAS operates on machine IDs, which is not easy to fetch. We will allow our users to operate based on the machine names instead and they can either supply the full FQDN or just hostname. The current prototype provides suggestions for misspelt names and our next task is to allow partial string matching for this.

If you are reading about this and would like to add feedback, we are more than happy to find out how we can improve the CLI experience. Your feedback is a gift.


The JAAS squad develops the UI for the JAAS store and Juju GUI  projects.

Cross model relations

We posted our UX work about CRM on discourse last iteration, thanks for the positive feedback from the community. The final visuals for the MVP has been completed – the Cross-model relations information is displayed in the Relation view, Application panel and a dedicated Relation details panel. 

<noscript> <img alt="" src=",q_auto,fl_sanitize,w_720/" width="720" /> </noscript> Relations view <noscript> <img alt="" src=",q_auto,fl_sanitize,w_720/" width="720" /> </noscript> Apps panel with relation and offer details <noscript> <img alt="" src=",q_auto,fl_sanitize,w_720/" width="720" /> </noscript> Relation details panel Charm Actions UX Exploration 

The team are exploring ways to provide actions which can be performed on a charm or units, with better visual affordance and representation. We started investigating the existing feature sets from Juju CLI, talking to charm writers and Juju users, organising feedback and comments from Discourse. A workshop with prepared design proposals and ideas will be held next week.


The Vanilla squad designs and maintains the design system and Vanilla framework library. They ensure a consistent style throughout web assets.


Work continues on a unified notifications pattern for use across our websites and web apps. Our UX team has been working on defining problems, auditing our use of notifications and benchmarking against the best-in-class notification experiences.

We’re hoping to deliver a notification experience that’s useful, lightweight and doesn’t interrupt user flow as they accomplish their important tasks in our software. 

Accessibility audit and fixes

We’ve completed a component-wide accessibility audit, and we’ve started applying enhancements to many components and example pages, including navigation, breadcrumbs, the switch component, buttons and others.

Modular table React component

We’ve been continuing the work on creating a new modular table React component. After initial proof of concept, we created a basic component in our React components library and will continue to extend it with features used by the tables in our products.

<noscript> <img alt="" src=",q_auto,fl_sanitize,w_720/" width="720" /> </noscript> Snapcraft and Charm Hub

The Snapcraft team works closely with the Store team to develop and maintain the Snap Store site and the upcoming Charm Hub site.

Snapcraft Forum

The snap team have published a forum category. You can come and join us by giving feedback or engaging in design conversations with us directly there.

Weekly active device by architecture

Snapcraft publishers page can now get the weekly active device by architecture. A publisher can go to the snap metrics page and filter by architecture. Please, provide us feedback in the forum.

<noscript> <img alt="" src=",q_auto,fl_sanitize,w_720/" width="720" /> </noscript> Your month in snaps email

The system that was providing the “Your month in snaps” emails has now been updated to run as a cron job in the Webteam’s Kubernetes. The repository for this cronjob can be found on GitHub.

Brand store admin

The brand store admin pages are in the process of being re-designed to become more useful, provide deeper insight into how the snaps published in them are used, and to become more easily manageable. With the redesign they will also be moved into, from

Charm Hub  Charm Hub Developer Experience

We have been iterating on the charm detail pages to be able to accommodate for content that helps charmers build their own new charms by reusing Python libraries from other charms, as well as help consumers, make integrations between charms in a more intuitive way. Along with the improvements of the developer experience, we have done visual improvements on the rest of the detail pages.

Store page

Responsive filters and sorting have been added to the store page for a better experience when browsing charms and bundles.

With ♥ from Canonical web team.

Full Circle Magazine: Full Circle Weekly News #182

Mër, 16/09/2020 - 7:47md
Groovy Gorilla Is In Feature Freeze Ubuntu Beginning the Switch to NFTables in Groovy Gorilla IP Fire 2.25 Core Update 148 Released with Location-based Firewall Lenovo to Ship Fedora on its Thinkpads Raspberry Pi OS 2020-08-20 Out

Q4OS 3.12, Centaurus Out

Linux from Scratch and Beyond LFS 10 Out

Linux Mint’s Warpinator via Flatpak Out

SuperTuxKart 1.2 Out

Htop 3.0 Out

Ubuntu “Complete” sound: Canonical

Theme Music: From The Dust – Stardust

Ubuntu Blog: Security corner: snap interface & snap connections

Mar, 15/09/2020 - 5:08md

One of the defining features of snaps is their strong security. Snaps are designed to run isolated from the underlying system, with granular control and access to specific resources made possible through a mechanism of interfaces. Think of it as a virtual USB cable – an interface connects a plug with a slot.

Security and privacy conscious users will certainly be interested in knowing more about their snaps – what they can do and which resources they need at runtime. To that end, you can use the handy snap interface and snap connections commands.

Aw, snap…interface!

The snap interface command allows you to see the list of all the different snaps that have been granted access (automatically or manually) to any of the supported snap interfaces. This way, at a glance, you can have an immediate mapping of the system access for your snaps. For instance:

snap interface home
name:    home
summary: allows access to non-hidden files in the home directory
  - cncra
  - cncra2yr
  - cppcheck
  - doctl
  - gimp
  - heimer
  - icdiff
  - irfanview

The output provides an explanation of what the interface does, and then the list of all the connected plugs for the home interface. Similarly, you can also see the list of all the interfaces that have at least one plug on your system.

snap interface
desktop-legacy          allows privileged access to desktop legacy methods
gsettings               allows access to any gsettings item of current user
hardware-observe        allows reading information about system hardware
home                    allows access to non-hidden files in the home directory
kernel-module-control   allows insertion, removal and querying of kernel modules
log-observe             allows read access to system logs
lxd-support             allows operating as the LXD service
network                 allows access to the network
network-bind            allows operating as a network service
network-control         allows configuring networking and network namespaces
network-manager         allows operating as the NetworkManager service
opengl                  allows access to OpenGL stack

From a security and/or privacy perspective, you can quickly inspect your system and determine whether there are any potential gaps in your baseline, or whether there are applications that have the ability to utilise resources that you may not necessarily want to allow. This can be quite useful if you have devices that are not necessarily used in an interactive way, like IoT gateways, allowing you to inspect and monitor their configuration.

It’s all about connections

It is worth mentioning that the information provided by the snap interface command is a transpose of the data you can obtain by running snap connections. This one-liner allows you to see all the connected snaps for each interface, or all the interfaces defined for each snap (whether they are connected or not).

snap connections
Interface                                     Plug                                       Slot                                                                  Notes
audio-playback                                cncra2yr:audio-playback                    :audio-playback                                                       -
audio-playback                                libreoffice:audio-playback                 :audio-playback                                                       -
audio-playback                                obs-studio:audio-playback                  :audio-playback                                                       -
audio-playback                                vlc:audio-playback                         :audio-playback                                                       -
audio-record                                  obs-studio:audio-record                    :audio-record                                                         -
browser-support                               obs-studio:browser-support                 :browser-support                                                      -
browser-support                               spotify:browser-support                    :browser-support                                                      -
camera                                        obs-studio:camera                          :camera                                                               -
content[gtk-3-themes]                         cncra2yr:gtk-3-themes                      gtk-common-themes:gtk-3-themes                                        -
content[icon-themes]                          cncra2yr:icon-themes                       gtk-common-themes:icon-themes                                         -
content[wine-3-stable]                        cncra2yr:wine-3-stable                     wine-platform-3-stable:wine-3-stable                                  -
content[wine-runtime]                         cncra2yr:wine-runtime                      wine-platform-runtime:wine-runtime                                    -
content[gtk-3-themes]                         cncra:gtk-3-themes                         gtk-common-themes:gtk-3-themes                                        -
content[icon-themes]                          cncra:icon-themes                          gtk-common-themes:icon-themes                                         -
content[wine-3-stable]                        cncra:wine-3-stable                        wine-platform-3-stable:wine-3-stable                                  -
content[wine-runtime]                         cncra:wine-runtime                         wine-platform-runtime:wine-runtime                                    -
content[gnome-3-28-1804]                      gimp:gnome-3-28-1804                       gnome-3-28-1804:gnome-3-28-1804                                       -
content[gtk-3-themes]                         gimp:gtk-3-themes                          gtk-common-themes:gtk-3-themes 

For instance, you may want to know what the kompoZer snaps requires:

snap connections kompozer
Interface               Plug                      Slot                              Notes
content[gtk-2-engines]  kompozer:gtk-2-engines    gtk2-common-themes:gtk-2-engines  -
content[gtk-2-themes]   kompozer:gtk-2-themes     gtk-common-themes:gtk-2-themes    -
content[icon-themes]    kompozer:icon-themes      gtk-common-themes:icon-themes     -
desktop                 kompozer:desktop          :desktop                          -
desktop-legacy          kompozer:desktop-legacy   :desktop-legacy                   -
home                    kompozer:home             :home                             -
removable-media         kompozer:removable-media  -                                 -
unity7                  kompozer:unity7           :unity7                           -
x11                     kompozer:x11              :x11                              -

When it comes to system configuration and inspection, the output provided by this command allows you to focus on specific snaps rather than specific resources. It can also help you troubleshoot any potential problems with snaps at runtime.

A good example here would indeed be kompoZer. The snap has the removable-media interface defined, but for security reasons, it is not auto-connected. This means that if you try to reach and open files that reside on a USB drive, for example, kompoZer will not be able to access them. You can inspect the list of connections that this application uses, quickly determine that the removable-media plug is not connected, and then manually connect it on the command line with snap connect. If you are not comfortable with the command-line, the Ubuntu Software frontend allows you to toggle connections on and off using a simple applet.

<noscript> <img alt="" src=",q_auto,fl_sanitize,w_720/" width="720" /> </noscript> Summary

The snap interface management functionality gives security-minded Linux users a high degree of granular control over their applications. In this case, unlike social media, you want as few connections for your snaps as possible, without compromising on the functionality. The snap interface and connections commands give you an instant overview of your snap ecosystem state, allowing you to quickly adjust and trim permissions as you go about your Linux adventure.

If you have any comments or suggestions, please join our forum for a discussion.

Photo by israel palacio on Unsplash.

Raphaël Hertzog: Freexian’s report about Debian Long Term Support, August 2020

Mar, 15/09/2020 - 12:01md

Like each month, here comes a report about the work of paid contributors to Debian LTS.

Individual reports In August, 237.25 work hours have been dispatched among 14 paid contributors. Their reports are available: Evolution of the situation

August was a regular LTS month once again, even though it was only our 2nd month with Stretch LTS.
At the end of August some of us participated in DebConf 20 online where we held our monthly team meeting. A video is available.
As of now this video is also the only public resource about the LTS survey we held in July, though a written summary is expected to be released soon.

The security tracker currently lists 56 packages with a known CVE and the dla-needed.txt file has 55 packages needing an update.

Thanks to our sponsors

Sponsors that recently joined are in bold.

No comment | Liked this article? Click here. | My blog is Flattr-enabled.

Stephen Michael Kellat: Middle of September 2020 Notes

Mar, 15/09/2020 - 3:49pd

"A person is praised for his insight, but a warped mind leads to contempt." – Proverbs 12:8 (Common English Bible)

It has been a while since I have written anything that might appear on Planet Ubuntu. Specifically the last time was June 26th. That's not necessarily a good thing.

I have been busy writing. What have I been writing? I knocked out a new novelette in Visual Studio Code. The print version was typeset using the novel class using LuaLaTeX. It is a bit of a sci-fi police procedural. It is up on Amazon for people to acquire though I do note that Amazon's print-on-demand costs have gone up a wee bit since the start of the planet-wide coronavirus crisis.

I also have taken time to test the Groovy Gorilla ISOs for Xubuntu. I encourage everybody out there to visit the testing tracker to test disc images for Xubuntu and other flavours as we head towards the release of 20.10 next month. Every release needs as much testing as possible.

Based upon an article from The Register it appears that the Community Council is being brought back to life. Nominations are being sought per a post on the main Discourse instance but readers of this are reminded that you need to be a current member either directly or indirectly of the 609 Ubuntu Members shown on Launchpad. Those 609 persons are the electors for the Community Council and the Community Council is drawn from that group. The size and composition of the Ubuntu Members group on Launchpad can change based upon published procedures and the initiative of individual to be part of such changes.

I will highlight an article at Yahoo Finance concerning financial distress among the fifty states. Here in Ohio we are seemingly in the middle of the pack. In Ashtabula County we have plenty of good opportunities in the age of coronavirus especially with our low transmission rates and very good access to medical facilities. With some investment in broadband backhaul an encampment for coders could be built who did not want to stick with city living. There is enough empty commercial real estate available to provide opportunities for film and television production if the wildfires and coronavirus issues out in California are not brought under control any time soon.

As a closing note, a federal trial judge ruled that the current coronavirus response actions in Pennsylvania happen to be unconstitutional. A similar lawsuit is pending before a trial judge here in Ohio about coronavirus response actions in this particular state. This year has been abnormal in so many ways and this legal news is just another facet of the abnormality.

Santiago Zarate: Ext4 filesystem has no space left on device? You liar!

Mar, 15/09/2020 - 2:00pd

So, you wake up one day, and find that one of your programs, starts to complainig about “No space left on device”:

Next thing (Obviously, duh?) is to see what happened, so you fire up du -h /tmp right?:

$ du -h /tmp Filesystem Size Used Avail Use% Mounted on /dev/mapper/zkvm1-root 6.2G 4.6G 1.3G 79% /

Wait, what? there’s space there! How can it be? In all my years of experience (+15!), I’ve never seen such thing!

Gods must be crazy!? or is it a 2020 thing?

$ touch /tmp touch: cannot touch ‘/tmp/test’: No space left on device

After shamelessly googling/duckducking/searching, I ended up at but alas, that was not my problem, although… perhaps too many files?, let’s check with du -i this time:

$ du -i /tmp `Filesystem Inodes IUsed IFree IUse% Mounted on /dev/mapper/zkvm1-root 417792 417792 0 100% /

Because I’m super smart I’m not, I now know where my problem is, too many files!, time to start fixing this…

After few minutes of deleting files, moving things around, bind mounting things, I landed with the actual root cause:

Tons of messages waiting in /var/spool/clientmqueue to be processed, I decided to delete some, after all, I don’t care about this system’s mails… so find /var/spool/clientmqueue -type f -delete does the job, and allows me to have tab completion again! YAY!.

However, because deleting files blindly is never a good solution, I ended up in the link from above, the solution was quite simple:

$ systemctl enable --now sendmail

After a while, root user started to receive system mail, and I could delete them afterwards :)

In the end, very simple solution (In my case!) rather than formatting or transfering all the data to a second drive, formatting & playing with inode size and stuff…

Filesystem Inodes IUsed IFree IUse% Mounted on /dev/mapper/zkvm1-root 417792 92955 324837 23% /

Et voilà, ma chérie!

This is a very long post, just to say:

ext4 no space left on device can mean: You have no space left, or you don’t have more room to store your files.

The Fridge: Ubuntu Weekly Newsletter Issue 648

Mar, 15/09/2020 - 12:57pd

Welcome to the Ubuntu Weekly Newsletter, Issue 648 for the week of September 6 – 12, 2020. The full version of this issue is available here.

In this issue we cover:

The Ubuntu Weekly Newsletter is brought to you by:

  • Krytarik Raido
  • Bashing-om
  • Chris Guiver
  • Wild Man
  • And many others

If you have a story idea for the Weekly Newsletter, join the Ubuntu News Team mailing list and submit it. Ideas can also be added to the wiki!

Except where otherwise noted, this issue of the Ubuntu Weekly Newsletter is licensed under a Creative Commons Attribution ShareAlike 3.0 License

Ubuntu Blog: An Introduction to Testing Robot Code

Hën, 14/09/2020 - 7:06md
<noscript> <img alt="" height="326" src=",q_auto,fl_sanitize,w_580,h_326/" width="580" /> </noscript>

The myriad of different fields that make up robotics makes QA practices difficult to settle on. Field testing is the go-to, since a functioning robot is often proof enough that a system is working. But online tests are slow. The physical environment must be set up. The entire system has to be in a workable state. Multiple runs are needed to build confidence. This grinds development to a halt. To those who took courses in computer science, this is akin to using the auto-grader “as the compiler.” It’s slow, it makes it hard to narrow down what isn’t working, it’s prone to wasting time seeing runs fail for simple errors.

Many roboticists don’t come from a background in software engineering, and they haven’t seen firsthand the benefits of having a solid test setup.

Having a good test system:

  • makes development significantly easier and faster.
  • allows one to make changes in one part of the codebase without worrying about understanding the rest.
  • lets one verify integration with the whole system without having to worry about how errors will look at higher or lower levels of abstraction.
  • allows newcomers to be confident in their ability to contribute to a project when they can get feedback from the test suite.

This post will hopefully help get those unfamiliar with the basics of writing tests up and running with an offline test suite for their robot.


We’ll start with some definitions and descriptions


An “assertion” is a programming expression that contains a statement that should be true when run, and raises a descriptive error when false. Often a language feature that produces more descriptive output when run in a test or debug environment.

Test Case

A “test case” is a basic unit of testing. A block of code, often in a function/method, containing one or more assertions.

Test Runner

A “test runner” is a software tool that manages invoking the code that contains test cases. Tools often look in specific locations or for specially annotated code to run. Can also provide functionality for mocking code and setting up fixtures (defined below), or fabricating program state, as well as tearing down and restoring state between tests.

Dependency Injection

When code is designed such that external dependencies are passed as arguments to the functions that will be accessing them, tests can “inject” special test objects as those dependencies instead of the real deal. This practice is called “dependency injection”, and it can lead to dramatically simpler tests with a narrower scope. Also, structuring the codebase in this way makes it more modular, flexible, and allows developers to more easily respond to change.

For example, imagine a function in a robot’s path planner that accepts a series of waypoints and attempts to generate a path between them. This function relies on an external path library, which has a PathPlanner class with children AStar, WeightedAStar, and Dijkstra. Rather than have the function body make mention of these classes right when needed, dependency injection would mean adding an argument of type “PathPlanner” to the function, where PathPlanner defines the interface different implementations will implement.

This first allows an easy way to change how the path is generated without changing the code itself, and secondly allows us to easily pass in test objects (defined below) to handle generating the path when testing.

Monkey Patching

“Monkey patching” is the process of dynamically replacing parts of the code. For example, changing the definition of a function at runtime, or overwriting a constant in an imported library. Monkey patching is natively supported in dynamic languages like Python, where assignment is rarely restricted. Various libraries extend support and add functionality to limit the scope of the patch and restore behavior after use.

Languages like C++ are more difficult to monkey patch, and are more reliant on good design principles like utilizing dependency injection to provide a foundation.

Fakes, Stubs, and Mocks

These are each different types of objects that are coded to match a specific interface, but are used exclusively for testing. Often used interchangeably, they refer to specific ways of substituting test logic in for the actual logic.

When a program has a complex data flow, with many objects that carry information through multiple functions, these tools let you quickly isolate a step in the call chain and test it without needing to record and manually rebuild objects from earlier in the data flow. With good use of dependency injection, you can use these objects to cordon off your test code, preventing the test from failing because of calls to external functions despite their preconditions being met.


A “stub” provides fixed data instead of relying on normal logic, and is used to isolate specific parts of code under test. Stubs are often used in place of systems that rely on network, disk, or hardware reads.

For example, to test that a function that takes an action based on a sensor reading, stubbing the sensor object allows you to slot in arbitrary sensor readings without relying on actual hardware reads.


A “fake” is an object that circumvents normal logic to provide an easier or more performant result when under test conditions.

For example, a function that relies on a path planner might not need optimality, or to start an anytime or dynamic path planning system while under testing. When the test data is a simple, low dimensional occupancy grid, a fake object could instead just run A*.

Similarly, a fake object can replace a network stream object so that when a test attempts to make a network connection, it instead automatically succeeds and subsequent calls to read from the stream feed out a scripted sequence instead.


Fakes and stubs are generally used to allow for testing the behavior of a given piece of code, where they’re passed in and never touched by the test again. A “mock”, on the other hand, is dynamically modified by the code performing the test, and it provides tools for introspection on how it was called. Mocks allow for verifying an interface between the code under test and the object being mocked. For example, how many times was a particular method of this mock object called, and with what arguments?

Aside: Overmocking

Test objects like mocks, fakes, and stubs are great tools for setting boundaries for your tests and creating test states. However, test design is a skill, and knowing when and how to apply these tools is a part of that skill. Test objects don’t necessarily have to behave like what they’re replacing, which means you can easily create an “ideal” case that never matches up to how your code actually behaves, or have behavior drift as your implementation changes over time.

It’s important to keep in mind that mocks work best when you’ve correctly targeted the behavior, and not the implementation, of your code. They can hide errors or real world cases that only well designed test data, or real world data, can catch. Be careful of overmocking!


A “fixture” is a convenience tool provided by test libraries. Fixtures are objects cleanly rebuilt before each test case and disposed of immediately afterward. Good testing design should not have state shared between tests.

Unit Test

A “unit test” is a test case covering the smallest unit of logic possible. Unit tests should generally be limited to one function, and not reliant on the behavior of other functions. Test objects or manually crafted variables should be used to simulate input and any state variables.

A unit test should prove that a function, when all preconditions are met, performs what it is expected to do. In design by contract parlance, all “requires” and “ensures” are met.

Integration Test

An “integration test” is a test case that includes dependent logic. Where a unit test makes sure that each function does what it’s supposed to, an integration test makes sure that the logic that could involve many such function calls is sound. In addition, integration tests make sure that the data flow is correctly set up. For instance, after a refactor, integration tests will make sure that the pieces of code are still interacting with each other properly.

Unit Test Example

Integration tests are simple enough: create data and pass it in to a function, and check it performs correctly. Every call it makes should perform correctly, and those parts are implicitly also under test.

Unit tests are where things differ. We need to understand how to break apart the test to validate only a single unit, that way we know WHY a specific part breaks. Let’s create an example scenario to see how to unit test.

Consider the path planner mentioned in the Dependency Injection section. Let’s make it in pseudocode:

combinePathSegments(waypoints: Sequence[Waypoint], pathAlgorithm: PathPlanner) -> Path: path = Path.empty() if any (waypoint not reachable for waypoint in waypoints): raise InvalidWaypointError() try: for i in enumerate(waypoints[:end-1]): path.addSegment(pathAlgorithm.getPath(waypoints[i], waypoints[i+1]) except NoPathFoundError as e: e.segment = i raise e return path

Some unit tests immediately spring to mind

  • test_handle_empty_list: test that an empty waypoint list returns an empty path.
  • test_handle_singleton: test that a single waypoint returns an empty path.
  • test_handle_valid: test that a valid path causes no problems.
  • test_fail_on_invalid_waypoint: a simple case, we want to verify that when an invalid waypoint is passed in to combinePathSegments, it raises InvalidWaypointError. Pass a waypoint that fails the reachability test, however it is defined, and verify the error is raised.
  • test_fail_on_no_path_found: here we want to verify that a path planner failing, which we are signaled to with NoPathFoundError, is forwarded out with the additional information of which segment failed.
Using test objects example

Let’s look at two of these test cases and see how test objects like mocks, stubs, and fakes can be used.


Since the function relies on external behavior in PathPlanner, we don’t want to actually test if a specific PathPlanner implementation is valid. That’s an integration test, and doesn’t tell us if the logic in our code specifically is OK.

Rather than create data where we should get a valid path, we create a PathPlanner stub to return a valid path. Our test is that when the PathPlanner returns a path, we handle it correctly, after all.

Using the python Mock library, generate a PathPlannerStub from the PathPlanner interface, and set it to return a valid path.

In python’s syntax:

test_handle_valid(): pathPlannerStub = unittest.mock.Mock(spec=PathPlanner) # creates stub of the PathPlanner interface ## pathPlannerStub.getPath is also a stub, `side_effect` attribute sets return on repeated calls pathPlannerMock.getPath.side_effect = [Path([(0,0), (0,1)]), Path([(0,1), (1,1)])] result = combinePathSegments([(0,0), (0,1), (1,1)], pathPlannerMock) expected = Path.empty() expected.add_segment(Path([(0,0), (0,1)])) expected.add_segment(Path([(0,1), (1,1)])) assert result == expected

Note we used the mock library here to implement a stub. We could have written a class for this as well, but Python mocks are versatile and cover most every use case for a test object, since they duck type and match the interface as expected. Either option is valid.


This is another great case for a stub. Generate a PathPlannerStub from PathPlanner, and set its behavior to fail at a specific, known point.

In python’s syntax:

test_fail_on_no_path_found(): pathPlannerMock = unittest.mock.Mock(spec=PathPlanner) # creates mock of PathPlanner interface # pathPlannerMock.getPath is also a mock, `side_effect` attribute sets return on repeated calls pathPlannerMock.getPath.side_effect = [Path.empty(), Path.empty(), NoPathFoundError(), Path.empty()] # the path planner will fail on the 3rd call, aka index 2 test_waypoints = [Waypoint()] * 4 # this asserts that the call in this with block will raise a specified type of exception with pytest.raises(NoPathFoundError) as e: combinePathSegments(test_waypoints, pathPlannerMock) # we now have the exception raised as `e`, lets verify that e.segment is 2 assert e.segment == 2, f’Reported incorrect segment as cause of exception’

Hopefully this gives you a good start on seeing where unit tests differ from the more natural feeling integration tests. We want to isolate the logic of a specific unit and verify it, not relying on dependencies or carefully constructed data whenever possible.

Test Runners for ROS Pytest

Pytest is the standard test runner for python, expanding on and improving the standard unittest library.

  • Tests cases are written as python functions or methods, grouped in files that usually follow the naming convention These suites are handled by pytest itself, which handles calling the individual cases, silently adds fixtures and information from the configuration file, and handles recording test outcomes and capturing standard output/error streams.
  • Monkey Patching is handled using the monkeypatch fixture. Methods are provided for patching code. Once an individual test case finishes, the original behavior is restored so there is no side effect on other cases.
  • Mock support is provided in the unittest.Mock library. Mocks created using this library can automatically match the interface of existing objects, record attribute access and call arguments, and can have members that are mocked further (like we used in our examples above).
  • In addition, mocks can be monkey patched into existing code using the various forms of the patch feature. In fact, most monkey patching will probably be done solely through the mock library. Patches can be used as decorators, as a context manager in a with block, or as a function that can also accept a mock.
  • Fixtures are provided via pytest in the fixtures module. A fixture can be defined using the @pytest.fixture() decorator within a test suite, or in a separate file that will be common to all test files in its current directory. Additionally, pytest provides a number of fixtures by default for things like capturing stdout/stderr and handling temporary file and directory creation. The monkeypatch fixture above is an example. Fixtures are included in a test case simply by adding the name of the fixture as an argument to the test case, and if the fixture provides an object for additional functionality, it can be accessed from that argument.
Test Layout

A typical ROS package can be laid out as follows:

example_package example_package [code files] resource example_package test [test files go here] CHANGELOG.rst LICENSE package.xml has two notable changes to make it test aware.

setup( … packages=find_packages(exclude=[‘test’]), tests_require=[‘pytest’] ) Googletest/GTest

C++ tests for ROS are generally written using the Googletest framework (GTest for short).

  • Test Cases for GTest are written using macros imported from gtest/gtest.h. The basic form is the TEST() macro, written as follows:
TEST(TestSuiteName, TestCaseName) { // asserts and test body }

Macros like EXPECT_EQ and ASSERT_STREQ provide assertions, and can have error strings piped to them with << like a normal pipe. EXPECT_* macros record failures but don’t exit the test case, whereas ASSERT_* macros exit on failure.

  • Monkey Patching is not easily done in C++, and is generally bad form. Using dependency injection, tests can replace behavior by injecting test specific code.
  • Mocks are handled using the gMock framework. To effectively use them, your code must again utilize dependency injection. You can then create a mock as a derived class of the interface you inject. gMock provides the MOCK_METHOD() macro that will be used to define the mocked methods of the interface. In tests, expectations on the mocks can be set using the EXPECT_CALL() macro, which has functionality for checking arguments, number of calls, and behavior.
  • Fixtures are provided via deriving a class from ::testing::Test. They can be included in tests by using the TEST_F macro instead of TEST and including the fixture as the first argument.
Test Layout

A typical C++ package would be laid out as follows:

example_package include [header files] src [source files] test [test files] CMakeLists.txt package.xml

CMakeLists.txt will require a separate block to handle registering the tests, explained in the ament_cmake user docs. Each test suite (aka .cpp file in the test dir) will need to be added with the ament_add_gtest macro, along with instructions to link libraries or declare dependencies on external targets. An example can be found in the tf2 library.

Invoking Tests

Once tests are set up for a package, colcon test can handle running all tests for you.

To use colcon test, invoke it from the workspace after running colcon build.

ubuntu@ros2-dev ~/workspace $ colcon test

All tests in the workspace will be run, and results will be printed and logged.

To run only specific packages, use the --package-select argument.

If the workspace was built with --merge-install, include that flag in the colcon test invocation as well.

For additional output, use the --event-handlers argument. --event-handlers=console_cohesion+ is a good default.

See the documentation for more specifics on using colcon test.

Hopefully this gives you a good starting place on understanding how to test your code. Solid test frameworks make iteration on code much more enjoyable for a developer.

Jonathan Carter: Wootbook / Tongfang laptop

Dje, 13/09/2020 - 10:44md

Old laptop

I’ve been meaning to get a new laptop for a while now. My ThinkPad X250 is now 5 years old and even though it’s still adequate in many ways, I tend to run out of memory especially when running a few virtual machines. It only has one memory slot, which I maxed out at 16GB shortly after I got it. Memory has been a problem in considering a new machine. Most new laptops have soldered RAM and local configurations tend to ship with 8GB RAM. Getting a new machine with only a slightly better CPU and even just the same amount of RAM as what I have in the X250 seems a bit wasteful. I was eyeing the Lenovo X13 because it’s a super portable that can take up to 32GB of RAM, and it ships with an AMD Ryzen 4000 series chip which has great performance. With Lenovo’s discount for Debian Developers it became even more attractive. Unfortunately that’s in North America only (at least for now) so that didn’t work out this time.

Enter Tongfang

I’ve been reading a bunch of positive reviews about the Tuxedo Pulse 14 and KDE Slimbook 14. Both look like great AMD laptops, supports up to 64GB of RAM and clearly runs Linux well. I also noticed that they look quite similar, and after some quick searches it turns out that these are made by Tongfang and that its model number is PF4NU1F.

I also learned that a local retailer (Wootware) sells them as the Wootbook. I’ve seen one of these before although it was an Intel-based one, but it looked like a nice machine and I was already curious about it back then. After struggling for a while to find a local laptop with a Ryzen CPU and that’s nice and compact and that breaks the 16GB memory barrier, finding this one that jumped all the way to 64GB sealed the deal for me.

This is the specs for the configuration I got:

  • Ryzen 7 4800H 2.9GHz Octa Core CPU (4MB L2 cache, 8MB L3 cache, 7nm process).
  • 64GB RAM (2x DDR4 2666mHz 32GB modules)
  • 1TB nvme disk
  • 14″ 1920×1280 (16:9 aspect ratio) matt display.
  • Real ethernet port (gigabit)
  • Intel Wifi 6 AX200 wireless ethernet
  • Magnesium alloy chassis

This configuration cost R18 796 (€947 / $1122). That’s significantly cheaper than anything else I can get that even starts to approach these specs. So this is a cheap laptop, but you wouldn’t think so by using it.

I used the Debian netinstall image to install, and installation was just another uneventful and boring Debian installation (yay!). Unfortunately it needs the firmware-iwlwifi and firmare-amd-graphics packages for the binary blobs that drives the wifi card and GPU. At least it works flawlessly and you don’t need an additional non-free display driver (as is the case with NVidia GPUs). I haven’t tested the graphics extensively yet, but desktop graphics performance is very snappy. This GPU also does fancy stuff like VP8/VP9 encoding/decoding, so I’m curious to see how well it does next time I have to encode some videos. The wifi upgrade was nice for copying files over. My old laptop maxed out at 300Mbps, this one connects to my home network between 800-1000Mbps. At this speed I don’t bother connecting via cable at home.

I read on Twitter that Tuxedo Computers thinks that it’s possible to bring Coreboot to this device. That would be yet another plus for this machine.

I’ll try to answer some of my own questions about this device that I had before, that other people in the Debian community might also have if they’re interested in this device. Since many of us are familiar with the ThinkPad X200 series of laptops, I’ll compare it a bit to my X250, and also a little to the X13 that I was considering before. Initially, I was a bit hesitant about the 14″ form factor, since I really like the portability of the 12.5″ ThinkPad. But because the screen bezel is a lot smaller, the Wootbook (that just rolls off the tongue a lot better than “the PF4NU1F”) is just slightly wider than the X250. It weighs in at 1.1KG instead of the 1.38KG of the X250. It’s also thinner, so even though it has a larger display, it actually feels a lot more portable. Here’s a picture of my X250 on top of the Wootbook, you can see a few mm of Wootbook sticking out to the right.

Card Reader

One thing that I overlooked when ordering this laptop was that it doesn’t have an SD card reader. I see that some variations have them, like on this Slimbook review. It’s not a deal-breaker for me, I have a USB card reader that’s very light and that I’ll just keep in my backpack. But if you’re ordering one of these machines and have some choice, it might be something to look out for if it’s something you care about.


On to the keyboard. This keyboard isn’t quite as nice to type on as on the ThinkPad, but, it’s not bad at all. I type on many different laptop keyboards and I would rank this keyboard very comfortably in the above average range. I’ve been typing on it a lot over the last 3 days (including this blog post) and it started feeling natural very quickly and I’m not distracted by it as much as I thought I would be transitioning from the ThinkPad or my mechanical desktop keyboard. In terms of layout, it’s nice having an actual “Insert” button again. This is things normal users don’t care about, but since I use mc (where insert selects files) this is a welcome return :). I also like that it doesn’t have a Print Screen button at the bottom of my keyboard between alt and ctrl like the ThinkPad has. Unfortunately, it doesn’t have dedicated pgup/pgdn buttons. I use those a lot in apps to switch between tabs. At leas the Fn button and the ctrl buttons are next to each other, so pressing those together with up and down to switch tabs isn’t that horrible, but if I don’t get used to it in another day or two I might do some remapping. The touchpad has en extra sensor-button on the top left corner that’s used on Windows to temporarily disable the touchpad. I captured it’s keyscan codes and it presses left control + keyscan code 93. The airplane mode, volume and brightness buttons work fine.

I do miss the ThinkPad trackpoint. It’s great especially in confined spaces, your hands don’t have to move far from the keyboard for quick pointer operations and it’s nice for doing something quick and accurate. I painted a bit in Krita last night, and agree with other reviewers that the touchpad could do with just a bit more resolution. I was initially disturbed when I noticed that my physical touchpad buttons were gone, but you get right-click by tapping with two fingers, and middle click with tapping 3 fingers. Not quite as efficient as having the real buttons, but it actually works ok. For the most part, this keyboard and touchpad is completely adequate. Only time will tell whether the keyboard still works fine in a few years from now, but I really have no serious complaints about it.


The X250 had a brightness of 172 nits. That’s not very bright, I think the X250 has about the dimmest display in the ThinkPad X200 range. This hasn’t been a problem for me until recently, my eyes are very photo-sensitive so most of the time I use it at reduced brightness anyway, but since I’ve been working from home a lot recently, it’s nice to sometimes sit outside and work, especially now that it’s spring time and we have some nice days. At full brightness, I can’t see much on my X250 outside. The Wootbook is significantly brighter even (even at less than 50% brightness), although I couldn’t find the exact specification for its brightness online.


The Wootbook has 3x USB type A ports and 1x USB type C port. That’s already quite luxurious for a compact laptop. As I mentioned in the specs above, it also has a full-sized ethernet socket. On the new X13 (the new ThinkPad machine I was considering), you only get 2x USB type A ports and if you want ethernet, you have to buy an additional adapter that’s quite expensive especially considering that it’s just a cable adapter (I don’t think it contains any electronics).

It has one hdmi port. Initially I was a bit concerned at lack of displayport (which my X250 has), but with an adapter it’s possible to convert the USB-C port to displayport and it seems like it’s possible to connect up to 3 external displays without using something weird like display over usual USB3.

Overall remarks

When maxing out the CPU, the fan is louder than on a ThinkPad, I definitely noticed it while compiling the zfs-dkms module. On the plus side, that happened incredibly fast. Comparing the Wootbook to my X250, the biggest downfall it has is really it’s pointing device. It doesn’t have a trackpad and the touchpad is ok and completely usable, but not great. I use my laptop on a desk most of the time so using an external mouse will mostly solve that.

If money were no object, I would definitely choose a maxed out ThinkPad for its superior keyboard/mouse, but the X13 configured with 32GB of RAM and 128GB of SSD retails for just about double of what I paid for this machine. It doesn’t seem like you can really buy the perfect laptop no matter how much money you want to spend, there’s some compromise no matter what you end up choosing, but this machine packs quite a punch, especially for its price, and so far I’m very happy with my purchase and the incredible performance it provides.

I’m also very glad that Wootware went with the gray/black colours, I prefer that by far to the white and silver variants. It’s also the first laptop I’ve had since 2006 that didn’t come with Windows on it.

The Wootbook is also comfortable/sturdy enough to carry with one hand while open. The ThinkPads are great like this and with many other brands this just feels unsafe. I don’t feel as confident carrying it by it’s display because it’s very thin (I know, I shouldn’t be doing that with the ThinkPads either, but I’ve been doing that for years without a problem :) ).

There’s also a post on Reddit that tracks where you can buy these machines from various vendors all over the world.

Ubuntu Blog: The State of Robotics – August 2020

Sht, 12/09/2020 - 7:10md
<noscript> <img alt="" src=",q_auto,fl_sanitize,w_720/" width="720" /> </noscript>

So that’s the summer gone (hopefully, that heat was awful). Or winter if that’s where you are. Seasons change and so does the state of robotics. Fortunately, that’s what we’re here for. Before we get into it, as ever, If you’re working on any robotics projects that you’d like us to talk about, be sure to get in touch. Fire an email to, we’d love to hear about it and share it with our audience.

ROS Kickstart

Interested in getting started with ROS 2 but not quite sure where to start? ROS is huge, and even though there’s a ton of great documentation, it can be overwhelming just to figure out where to start. If you find yourself needing some guidance, check out the recently published tutorial and associated videos on ROS basics from your friendly Ubuntu Robotics team. They’re intended to introduce you to the fundamental concepts of ROS so you can dive into the more advanced documentation.

ROS and ESP32: Great Together!

The ESP32 system-on-a-chip microcontroller from Expressif can be a great, inexpensive and simple robot controller. The chip boasts onboard WiFi and bluetooth for connectivity plus a number of peripheral interfaces. And since it’s able to run FreeRTOS, why not add it to your ROS 2 system?

“Wait,” you say, “ROS doesn’t run on FreeRTOS!” Well, you’re right, but you should check out micro-ROS, a project that allows you to integrate such components into ROS 2, where support for the ESP32 was recently announced. A communications agent ties components like these into the rest of your ROS system. Check out the micro-ROS tutorials and get started building your own low-power ROS 2 IOT device! Did we mention that the communications agent is now also available as a snap?

Snap your ROS 2 Foxy Robot

The snapcraft CLI (the tool used to create snaps) has long had support for building snaps that use both ROS 1 and ROS 2. ROS 2 Foxy Fitzroy is the latest ROS 2 LTS, which runs on Ubuntu 20.04 (Focal Fossa), and the snapcraft CLI recently gained support for building snaps that use Foxy. This is an awesome way to deploy and update your ROS 2 application on your robots without needing to host your own infrastructure. Check it out!

RosWorld 2020: Join us!

ROS World 2020 is happening online on November 12th! Sure, it’s not the same as being there in person, and we’d love to see you there, but it’s being held right in your office, and it’s free! Besides, we’ll have a “Virtual Exhibit Booth”. No, we’re not sure what that means either, but it sounds like you can still come on by and chat with us.

An affordable robot dog

You know how much we like robot dogs in this newsletter, so you can imagine how hyped we were when we found out about the Bittle robot on Kickstarter. Developed by Petoi, it is a rather polished and capable hardware kit backed up by an ever growing community and open source software. The campaign is already quite successful as it reached its goal in a single day! But that’s not a first for Petoi as they are the ones behind Nybble, an affordable, adorable robot kitty financed through crowdfunding too. Have a look at the Kickstarter page for more info and some really cool demos.


For all the makers and hackers out there, if you have an open-source project or initiative you’d like us to showcase in this monthly series, shoot us a message on We’ll take it from there.