Practical advice for speakers at FOSDEM 2021 Open Source Design devroom

Here’s some practical advice for speakers at our Open Source Design devroom at FOSDEM 2021.

1. FOSDEM organisers recommend using OBS to record and edit your talk video. This how-to gives useful advice. (

2. We recommend you recording and editing the video as soon as possible.

3. Don’t overload your slides. Make sure everything is readable when scaled down slightly. The 1280×720 video you send in might or might not be scaled down to fit onto a FOSDEM template!

4. Make sure your video presentation fits into your 20 minute assigned timeslot with room to spare for questions and answers. FOSDEM 2021 works on a strict broadcast schedule. The FOSDEM systems will ruthlessly cut you off at the end of your timeslot!

The Open Source Design group recommends you talk for 15 minutes and leave 5 minutes for questions and answers.

5. You must upload your talk video yourself to the FOSDEM system – we will send this to you in the coming days.

Your recording video format must follow these technical requirements:

resolution: 1280×720
frame rate: 25 fps
video codec: h264 video codec, main profile
video bitrate: <= 2Mbit/s
audio codec: aac audio codec
audio sample rate: 48 KHz mono
audio bitrate: 128 Kbit/s
media container: whatever is easiest for you

Helpful tip –

When you upload the video, the FOSDEM upload system will verify that your video file meets the above constraints. If it doesn’t, the video will be transcoded first, but this will take longer.

If you have issues with the video upload we recommend first comparing video details with the above requirements. If you need help, you can ask your Devroom Point of Contact.

What languages do Cloudron users speak?

The objective of this quick survey is to get some understanding of what languages are spoken by Cloudron users. You can find out more about translation work in this forum link.

The data gathered will be shared on the Cloudron forum.

NB: This survey has been created by Bernard Tyers, a Cloudron user. I am not professionally affiliated with Cloudron in anyway.

Making a Python virtual environment on OS X

OS: Mac OS X Catalina 10.5.6
Python version: 3.9 (most up-to-date at this time and installed like this)
Package to install: guinness (Good things come to those who wait)

This is a reminder to myself on how to do create a virtenv.

pip3 install virtualenv
mkdir guinness
cd guinness
/Users/bernard/Library/Python/3.8/bin/virtualenv guinness
pip3 install guinness

### deactivate virtual environment
(guinness) bernard@machine guinness % deactivate

Installing Python on Mac OS X Catalina

(This is a reminder to myself, and maybe a help for someone else who might be in the same situation as me. The purpose was to be able to lint documentation I’m trying to update for the pip project work.)

This applies to installing “the latest” Python on Mac OS X 10.15.6.

I’ve used this helpful How-TO. Everything worked until the very end where brew couldn’t create a necessary directory:

Permission denied @ dir_s_mkdir - /usr/local/Frameworks

(no idea why!)

==> Summary
๐Ÿบ  /usr/local/Cellar/openssl@1.1/1.1.1h: 8,067 files, 18.5MB
==> Installing python@3.9
==> ./configure --prefix=/usr/local/Cellar/python@3.9/3.9.0_1 --enable-ipv6 --datarootdir=/usr/local/Cellar/python@3.9/3.9.0_1/share --datadir
==> make
==> make install PYTHONAPPSDIR=/usr/local/Cellar/python@3.9/3.9.0_1
==> make frameworkinstallextras PYTHONAPPSDIR=/usr/local/Cellar/python@3.9/3.9.0_1/share/python@3.9
Error: An unexpected error occurred during the `brew link` step
The formula built, but is not symlinked into /usr/local
Permission denied @ dir_s_mkdir - /usr/local/Frameworks
Error: Permission denied @ dir_s_mkdir - /usr/local/Frameworks

I reran install python and got:

bernard@computer-number-6 ~ % brew install python 
Updating Homebrew...
==> Auto-updated Homebrew!
Updated 1 tap (homebrew/cask).
==> Updated Casks

Warning: python@3.9 3.9.0_1 is already installed, it's just not linked
You can use `brew link python@3.9` to link this version.

Solution (hack?)

The solution was to create the /usr/local/Framworks directory manually:

bernard@computer-number-6 ~ % sudo mkdir /usr/local/Frameworks

Then change the owner and group to mirror other directories (bernard:admin)

bernard@computer-number-6 ~ % sudo chown bernard /usr/local/Frameworks 
bernard@computer-number-6 ~ % sudo chgrp admin /usr/local/Frameworks
bernard@computer-number-6 ~ % ls -la /usr/local/                  
total 0
drwxr-xr-x   17 root     wheel   544 11 Nov 12:01 .
drwxr-xr-x@  11 root     wheel   352 12 Dec  2019 ..
-rw-r--r--    1 root     wheel     0 18 Sep  2019
drwxrwxr-x    3 bernard  admin    96  1 Apr  2019 Caskroom
drwxrwxr-x   63 bernard  admin  2016 11 Nov 11:39 Cellar
drwxr-xr-x    2 bernard  admin    64 11 Nov 12:01 Frameworks

And finally run the brew link command from above:

bernard@computer-number-6 ~ % brew link python@3.9            
Linking /usr/local/Cellar/python@3.9/3.9.0_1... 5 symlinks created
bernard@computer-number-6 ~ %

And then I could start what I wanted to actually do. ๐Ÿ™‚

Creating rapid CLI prototypes with cli-output

I’m working on the usability of pip (the official Python package manager) at the moment.

This short blogpost isn’t about how to design CLIs. It is about creating rapid prototypes with this tool – part “look at this useful tool, part “thank you Pradyun” part feature request list. ๐Ÿ™‚


After putting together the feature request list below, Pradyun’s already updated cli-output with request 1 and 2 below. Reusable blocks, or repeatable blocks are a bit more work.

Prototyping CLIs

Prototyping commandline interfaces, for the non-developer, is not easy. While we have countless interface prototyping tools for graphical UIs, unless you can write code (Python, HTML/JS, etc), when it comes to commandline user interfaces, there’s little available.

One thing I have struggled with so far is being able to prototype commandline interfaces that look “real enough”, without it taking “a lot” of time.

I’ve tried making stop-motion videos, describing it in long verbose explanations, doing paper prototypes, but none of the work. A CLI is essentially an interactive scrolling text-only interface. Without that “motion” it is very difficult to prototype, without coding skills.

Pradyun Gedam, one of the pip maintainers, put together a nice tool to prototype commandline interfaces. It is essentially simulating a CLI in HTML and JS. Easy when you know how.

It allows you to do nice things like this:

prototyping commandline interfaces with cli-output

Feature list

1. Being able to include comments. Done!

As a CLI UX designer, I want to be able to write comments (which won’t show up in the cli output), so that I can include human-readable explanation or annotation in the output.

Things to think about: can I use common characters like `#`, `>` if they are going to be printed in a cli output? ๐Ÿค”

2. Being able to easily repeat a large block

As a CLI UX designer, I want to be able to build output on previously drawn elements, so that it saves time.

I need to add a video here to show what I mean.

3. Being able to share the URL of a cli output prototype.

This would help so that I could share them in PRs, etc.

As a CLI UX designer, I want a weblink for each cli prototype I create, so that I can share them with people (in GH issues, users, etc).

Things to think about: I think using something like a pastbin unique URL (which allows editing) would be nice. I think something like how hastepin does URLs would be good.

4. Having the output scroll up like in a real terminal Done!

I need to add a video here to explain more.

5. Having reusable elements

As a CLI UX designer, I want to be have a number of elements I can use, so that I don’t need to build them from scratch each time.

Things to think about: It’d be nice to be able to reuse elements (for example a spinner) instead of having to redraw each `-`, `\`, `|`, `/` each time. For example, like you’ve created the spinner here.

What elements? I think a spinner, and simple progress bar would be a great start.


Anyway, thank you Pradyun for what you’ve done so far. ๐Ÿ™๐Ÿพ

If you are a UX designer and you need to make quick CLI prototypes, I suggest you have a look.

A Python community announcement about our pip work

Sumana Harihareswara the pip PM put together a video for the Python community to tell them about our UX work on pip, the package manager.

Initially I was thinking “I hate seeing my face on video, I hate hearing my voice. This better not have ukelele music. I hate those kinds of videos.”

I liked the explanation she gave for wanting to do it – ‘so Python community, and users can see the human faces behind pip, that we’re real people’.
We often forget (me included) that, for the moment, it’s still humans that make most software.

I think the video turned out well, and people seem to like it.

Post categories

Posts archive

Bernard Tyers, Proudly powered by WordPress.