I attended GUADEC 2018, and really enjoyed it, and I feel that I got a lot out of it.
The talks were recorded and they should be put online some time soon, I think. They need volunteers to do some video editing first though.
There is an issue for doing that here:
The talks in the main Auditorium room were recorded by the University, but the talks in the other rooms were recorded manually.
The talks schedule is here:
My favourites were:
- Building Flatpak apps with Buildstream
- Have you ever developed for a GPU?
- Patterns of refactoring C to Rust
- Simple tricks to assess and improve security
Sunday had the highest density of talks that I really wanted to see. I missed some because of having to choose. Anyway these are the ones I saw in chronological order:
Ubuntu's journey from Unity to GNOME Shell
By Ken VanDine & Didier Roche
This started by recapping that Ubuntu dropped Unity for GNOME Shell. Got more interesting when he started talking about the work they have upstreamed to do improve performance stuff. I missed the end of the talk because I left to go to another talk in a different room, but it was recorded.
Dealing with controversy - a practical guideline
By Sriram Ramkrishna
This was about how to avoid bad situations before they happen, and how to handle it when bad stuff occurs. An example given was about something that became known as a "GNOME Shell Memory Leak". It was a complex issue that had been known about for 5 years and was difficult to solve.
A blog post on the issue which used the term "Memory Leak" upset a whole bunch of people, and there were angry comments in response. The problem was that this phrase trivialised the problem and has the connotation of sloppiness of development. The blog post was actually positive; about some work to improve the "memory leak" problem.
The suggestion made during the talk was that if the blog post title hadn't said "memory leak" but had used wording like "Improving GNOME Shell resource usage" it could have been avoided.
I think it applies to things we do like code review too, where we should try to word things nicely.
Another point was about involving users in the decision making when changes happen, because it can lead to changes that work for more people's workflows, and can help avoid upsetting people when stuff changes in a way they don't like.
Looking into the future
By Rosanna Yuen
This was actually about the future of the GNOME organisation, rather than about any sort of roadmap for features or technical plans. It was quite interesting though, because they've got a big injection of cash from a donation, so they might be able to organise things a bit better, and fund more development.
They're particularly focused on GTK at the moment, because is is fundamental to the GNOME software stack.
The talk on the other stream, "The infamous GNOME Shell performance" might have been more interesting to me. But that room was recorded, so I should be able to watch it at some point.
Endless product manager
By Nick Richards
This was mostly explaining how to be a good product manager.
One of the points was it's better to tell people what the goals are than just telling them what to do next, because it explains why the things that are being done make the product better.
Another point was about getting information about how the consumers find the product from all sorts of sources, and the the picture can be built up better from that. An example was the GNOME Nautilus file manager application. Endless have metrics what show that it's the most used application, which seems surprising, but that coupled with the heated comments about it whenever it's changed show that it's something the users care about.
It was also interesting to see the issues that concern people in these roles, because if I can understand what they're trying to do, I can probably work with them better.
Maxwell: embedding widgets in WebKit
By Juan Pablo Ugarte
Arrived late because of a lunch ticket fiasco, and didn't have enough context to understand the relevance of the part I saw. But it looked like description of the sort of damage redraw rendering model that's pretty common, and then about having GTK widgets appear in web pages using WebKit.
How to handle design critique
By Hylke and Nick
This was mostly about design of icons.
The main thing I liked about this was a point about finding ways to take any kind of feedback positively. They had been redesigning some icons and somehow they were leaked. The comments were people raging that they didn't like them because there was too much contrast.
The guy took this as, "there's probably enough contrast", because his concern when making them was that there would be enough contrast for the icons to work on any background.
You can't design for one person, even yourself, feedback from others is important.
Also, mentioned that you have conflicting goals when making icons: you want them to all look distinct, so you can tell them apart, but you also what them to look like they have a similar style, so that the whole user interface looks consistent.
Freedesktop-sdk, the future of Linux runtimes
By Adam Jones & Valentin David
Flatpak is for application distribution on Linux. Both GNOME and KDE have SDKs based on the freedesktop SDK. Old ones used Yocto and Flatpak builder. New one just uses Buildstream.
I also learned the difference between multilib and multiarch.
It was a good talk and clearly delivered.
By Robert McQueen & Jorge García
Good explanation of the point of flathub; developers want to get their new versions to users, to get feedback, and users want the new versions for new features and fixes. Sometimes linux distributions get in the way of this, e.g. Debian stable might introduce a two year delay between the developers making a release, and the users actually getting to try it.
With flathub, developers can make their applications available to linux users directly.
There are other advantages too, like sandboxing for security and to ensure the application runs in a consistent environment for everyone.
For publishing to flathub, first, check for existing flatpak, or work-in-progress one, then write the flatpak manifest.
I'm now considering making a flatpak for NetSurf, but we'll see. Sam Thursfield had a stab at making one using Buildstream, rather than the flatpak tooling a while ago.
Building the Libre Desktop
By Louisa Bisio
This talk was mostly marketing. I kind of missed the end and the questions though, because I somehow ended up talking to the person next to me.
It was about a company that makes computers with POP OS, which is a GNOME-based linux system. The OS can be driven by keyboard navigation, and it has a curated app store.
Anyway, during this talk Sam Thursfield was writing his open-talk on one side of me, and a lady (Kat) was writing another talk on my other side. At some point she left the room and came back, and asked what she'd missed. I muttered, "more of the same". The talk was still going on so I didn't want to speak. But as time passed I thought I might have been too rude and terse, so I said something to her, and we started talking and it ended with her trying to press me into giving a lightning talk about brain scanners.
I didn't want to, but she gave some tips about doing talks anyway. The main thing I remember was about getting people you know and like up the front to smile and encourage you. I also said I'd watch her talk, which was on next...
Plan your testing
This was about different types of testing, and making you think about what you want to achieve with your testing. Worth watching to get a sense of various issues if you want to improve your approach to testing.
I noticed she had all sorts of people she new in the front rows and spoke to them during the talk, so she practised what she preached.
It was then Lunch, then another talk, which I missed because I went for a walk along the beach with Sam Thursfield before we came back and he gave his open talk...
Building Flatpak apps with Buildstream
By Sam Thursfield
This was a really clear and honest account of using Buildstream to build flatpak apps. He covered the issues encountered and explained why they're difficult to solve. He had dug into the causes of the problems he encountered and explained those too.
Sam was planning to actually demo building a flatpak app with Buildstream during the talk, but his laptop couldn't connect to the projector, so he had to wing it with just slides.
Have you ever developed for a GPU?
By Benjamin Otte
This was about GSK, the GTK+ Scene-graph Kit. He summed it up as "Clutter* without all the clutter". It was also a really good talk.
First he showed a GTK performance benchmark test thing. It was a window with various GTK widgets bouncing around inside it. It would increase the number of widgets until it reached the most it could manage while sustaining 60fps.
Unsurprisingly the unaccelerated Cairo back end could only manage a handful, while the GPU-accelerated GSK back ends managed loads.
Also, with GSK the using Vulcan it was about twice as fast as OpenGL (although a bit more buggy too, their Vulcan stuff isn't finished yet).
He also mentioned that when they first got the OpenGL GSK working it managed only one widget at 15fps, which was much slower than Cairo. None of them had done GPU stuff before and needed to learn how it worked in order to make it efficient.
He said you could treat the GPU a bit like a remote X server, so avoid round trips and cache as much as possible on the GPU. You need to submit stuff without reading back, do as much computation on the GPU as possible, and renderers can become creative with what gets cached on the GPU.
This was all at quite a high level, but it reinforced what I already believed about this. (I've not really done any GPU stuff before.)
He also mentioned using sysprof for profiling, which I've not used before.
(There was another talk about PipeWire on at the same time, which I was interested in seeing too, so I'll have to watch that on video.)
Design of an UX case: IoT integration in GNOME
By Claudio Alexander Santoro Wunder
This was about controlling and accessing lots of stuff from a single consistent interface. There was little substance to the talk but the guy was very enthusiastic about the subject.
It seemed like the talk was mostly about trying to encourage someone to make a GNOME UX for IoT.
Patterns of refactoring C to Rust
By Federico Mena Quintero
This was probably my favourite talk, and a really good speaker.
It was about the progress made rewriting parts of the rSVG library in Rust, and sharing the knowledge learned from that. The following book was recommended:
Working Effectively with Legacy Code
It started with some basic steps at quite a high level, then there was a video of the "Under the Sea" song from The Little Mermaid, and the guy whistled the music.
After the video the talk got technical, and he started to go into detail with code examples. It was very clearly delivered and made sense. He also had a tip for logging with indentation and there were resources with more information and related topics at the end. Currently rSVG is about 55% Rust, and 35% C.
GLib: What’s new and what’s next?
By Philip Withnall
This was a summary of the changes to the Glib project, as well as a few things that are coming up on the horizon.
The main thing he was pleased with was the change to Gitlab, which is making interaction with contributors and users more easy, as well as giving them CI, and code coverage.
He said there seems to be more contributions since moving to gitlab. They have a Meson buildsystem now, and plan to drop the autotools one for release 2.59.
He plans to do more work on libglib-testing which is something that you can plug into your glib application, and it will automatically run a battery of tests against your gobject interfaces.
Simple tricks to assess and improve security
By Tobias Mueller
This was by a funny guy who kept saying people should go to Philip's talk, which was the other stream. He was a good speaker, especially coping with the projector not working at the start. But that put his timing off and he ran on into the next slot even speaking faster and faster towards the end.
He said that using the address sanitiser compilation flag would have found the heartbleed bug, and gave examples of the types of errors that can be caught with address sanitiser and undefined behaviour sanitiser.
He also gave examples of seemingly innocuous things like integer overflow, leading to remote execution CVEs. These could all have been caught by the sanitisers, and one of the big points of his talk was that there is no excuse for not using them for development builds.
He mentioned various things you can do that can catch security issues. These were: compile time (e.g. -Wall -Wextra, static analysis); runtime (e.g. valgrind, address and undefined behaviour sanitisers); and testing (e.g. libfuzzer, AFL and OSS-Fuzz).
This talk inspired me to add support for building LibCYAML with address and undefined behaviour sanitisers during the hack days. More on that in the hack days section below.
By Philip Chimento
Mentioned GNOME builder, which is an IDE, and some sort of cool feature where the app you develop can have a button, and clicking it flips the window round, so you see the back of the app's window, and it shows the GNOME builder IDE with the source for the app already loaded up.
It then moved onto talking about activities for teaching programming to people with various backgrounds.
During the talks days I asked Sam Thursfield and Javier Jardón to point out some gstreamer people to me. Javier pointed out Tim-Philipp Muller. He wasn't going to be around for the hack days, but he in turn did point out Nirbheek Chauhan who would be there.
I talked to Nirbheek and he gave me some pointers about where to look for the issue I wanted to fix. I couldn't find him on the hack days, but I did speak to him on IRC, and he helped me a bit more. In the end I got gstreamer to build from source and got to the point where I could test my changes. So I can easily do what I want now.
I also spent time reading the gstreamer docs, particularly about how gstreamer plugins are written.
As mentioned above, the "Simple tricks to assess and improve security" talk made me want to enable the address and undefined behaviour sanitisers in development builds of LibCYAML.
It was trivial to add this, and its done here:
Undefined behaviour sanitizer actually found a couple of issues where the handling of invalid schemas depended on (common but) undefined behaviour. These are fixed here:
I did find some issues that make it not as straightforward to add using the sanitisers as was stated in the talk.
First, address sanitiser is incompatible with valgrind, so I
couldn't simply add the
-fsanitize flags to my debug builds,
since doing so would break the valgrind targets.
Second, while it ran fine locally, it didn't work on Travis CI, so currently I don't run the sanitizers under CI yet.
The problem seems to stem from the Travis containers using an ancient version of Ubuntu, and I couldn't coax it to work even after a couple of hours of trying different things.
For the first issue I could potentially drop the valgrind targets, if I'm certain address sanitiser can catch everything valgrind can, although I wouldn't do that without a solution to the second issue.
For the second issue, I could potentially move from github to gitlab, but the current github address is already linked from yaml.org so I'm a bit reluctant to move it now.
I also plan to build and test NetSurf with the sanitisers enabled.
- Using STPA with software-intensive systems
- Codethink achieves ISO 26262 ASIL D Tool Certification
- RISC-V: running GNOME OS on SiFive hardware for the first time
- Automated Linux kernel testing
- Native compilation on Arm servers is so much faster now
- Higher quality of FOSS: How we are helping GNOME to improve their test pipeline
- RISC-V: A Small Hardware Project
- Why aligning with open source mainline is the way to go
- Build Meetup 2021: The BuildTeam Community Event
- A new approach to software safety
- Does the "Hypocrite Commits" incident prove that Linux is unsafe?
- ABI Stability in freedesktop-sdk
- Why your organisation needs to embrace working in the open-source ecosystem
- RISC-V User space access Oops
- Tracking Players at the Edge: An Overview
- What is Remote Asset API?
- Running a devroom at FOSDEM: Safety and Open Source
- Meet the codethings: Understanding BuildGrid and BuildBox with Beth White
- Streamlining Terraform configuration with Jsonnet
- Bloodlight: Designing a Heart Rate Sensor with STM32, LEDs and Photodiode
- Making the tech industry more inclusive for women
- Bloodlight Case Design: Lessons Learned
- Safety is a system property, not a software property
- RISC-V: Codethink's first research about the open instruction set
- Meet the Codethings: Safety-critical systems and the benefits of STPA with Shaun Mooney
- Why Project Managers are essential in an effective software consultancy
- FOSDEM 2021: Devroom for Safety and Open Source
- Meet the Codethings: Ben Dooks talks about Linux kernel and RISC-V
- Here we go 2021: 4 open source events for software engineers and project leaders
- Xmas Greetings from Codethink
- Call for Papers: FOSDEM 2021 Dev Room Safety and Open Source Software
- Building the abseil-hello Bazel project for a different architecture using a dynamically generated toolchain
- Advent of Code: programming puzzle challenges
- Improving performance on Interrogizer with the stm32
- Introducing Interrogizer: providing affordable troubleshooting
- Improving software security through input validation
- More time on top: My latest work improving Topplot
- Cycling around the world
- Orchestrating applications by (ab)using Ansible's Network XML Parser
- My experience of the MIT STAMP workshop 2020
- Red Hat announces new Flatpak Runtime for RHEL
- How to keep your staff healthy in lockdown
- Bloodlight: A Medical PPG Testbed
- Bringing Lorry into the 2020s
- How to use Tracecompass to analyse kernel traces from LTTng
- Fixing Rust's test suite on RISC-V
- The challenges behind electric vehicle infrastructure
- Investigating kernel user-space access
- Consuming BuildStream projects in Bazel: the bazelize plugin
- Improving RISC-V Linux support in Rust
- Creating a Build toolkit using the Remote Execution API
- Trusting software in a pandemic
- The Case For Open Source Software In The Medical Industry
- My experiences moving to remote working
- Impact of COVID-19 on the Medical Devices Industry
- COVID-19 (Coronavirus) and Codethink
- Codethink develops Open Source drivers for Microsoft Azure Sphere MediaTek MT3620
- Codethink partners with Wirepas
- Testing Bazel's Remote Execution API
- Passing the age of retirement: our work with Fortran and its compilers
- Sharing technical knowledge at Codethink
- Using the REAPI for Distributed Builds
- An Introduction to Remote Execution and Distributed Builds
- Gluing hardware and software: Board Support Packages (BSPs)
- Engineering's jack of all trades: an intro to FPGAs
- Bust out your pendrives: Debian 10 is out!
- Why you should attend local open source meet-ups
- Acceptance, strife, and progress in the LGBTIQ+ and open source communities
- Codethink helps York Instruments to deliver world-beating medical brain-scanner
- Codethink open sources part of staff onboarding - 'How To Git Going In FOSS'
- Getting into open source
- How to put GitOps to work for your software delivery
- Open Source Safety Requirements Analysis for Autonomous Vehicles based on STPA
- Codethink engineers develop custom debug solution for customer project
- Codethink contributes to CIP Super Long Term Kernel maintenance
- Codethink creates custom USB 3 switch to support customer's CI/CD pipeline requirements
- Codethink unlocks data analysis potential for British Cycling
- MIT Doctor delivers Manchester masterclass on innovative safety methodology
- Balance for Better: Women in Technology Codethink Interviews
- Introducing BuildGrid
- Full archive