After an interesting Saturday, finished with a great dinner with some friends in one of our favorite restaurants in Brussels, my Sunday at FOSDEM started again very early.
My choices for the Sunday were again diverse and (in most cases) successful. Apart from the closing keynotes, I spent some time in the Legal and Policy Issues devroom, a couple of talks in the HPC, Big Data, and Data Science devroom and half the afternoon in the Geospatial devroom.
Before continuing, if you want to read my summary of the previous day you can follow this link: FOSDEM 2018: Saturday. You will also find there general info and details about the event itself.
Let me summarize:
This first talk was a bit disappointing. The intro about GDPR took most of the talk, and I bet that almost all of us who where there at 9am in a Sunday knew what GDPR is.
The recommendations for GDPR arrived very late. The speaker made a brief overview of how you can benefit from a nice data mapping and data governance, and how good it is to observe privacy by default and by design. Then, he introduced Identity Management as the ideal tool for the job demonstrating the lawfulness of all the data processing. The fact that he develops Identity Management software has something to do with it, of course.
The next talk in the Legal and Policy devroom was luckily more interesting, but again the title was misleading. Most of the talk was an intro to the right to be forgotten, including an overview of all the relevant legal cases starting with the Google Spain v AEPD and Mario Costeja González. Cristina Rosu complemented the legal intro with some metrics about GDPR compliance in some countries.
In the last slides, the only part related to Artificial Intelligence, the speaker commented some possible approaches to enhance the right to be forgotten in the AI environment: Obfuscation strategies, data minimization, personal data stores, algorithmic transparency or ethical boards inside companies.
The speaker, as a systems engineer, is responsible of the automation of a medium-sized HPC infrastructure at the Louvain University. The purpose of his talk, quite interesting, was to advocate for the use of similar tools at the same time, instead of using the same tool for everything. Some features overlap, but he claimed that each tool can be more powerful in certain tasks, and separating tools also helps in defining responsibilities.
They use Cobbler to install and deploy Operating Systems and set-up hardware specific configuration, Ansible for one-off operations (setup RSA keys, register node to services or prepare config files) and Salt for daily management (configure system, install admin software or mount the user filesystem).
He ended comparing Ansible and Salt, reviewing the best characteristics of each of them as you can see in the picture that I took:
The speaker started his talk reviewing some of the Quality Assurance tools available in the OpenStreetMap ecosystem, being the main ones: Keep Right, Osmose, OSM Inspector and Maproulette. The problem of them, and I know it very well because I’ve used them a lot, is that the detection can be automatic but only sometimes the tool is able to provide fix suggestions or a standard correction guide, and eventually all the corrections need to be done manually by a mapper (like me).
The premise of the talk was about using other datasets to highlight inconsistencies and, potentially, to predict some characteristics not present in the map using DeepLearning and satellite imagery. The results that he showed were impressive, but he also showed that a lot of work needs to be done in order to have enough quality to consider a more automated approach for Quality Assurance in OSM.
Completeness in OpenStreetMap starts by detecting inconsistencies as soon and as detailed as possible.
After some interesting networking in the stands, I entered this talk with low expectations. I did not regret it because it was very interesting.
The talk was about the huge refactor that was needed in the codebase of LibreOffice to make it work in the Cloud. The speaker explained clearly why they needed to re-structure at all, the main problems that they faced (Windows and Linux rendering APIs) and how they solved critical issues like extreme coupling and threads management.
The summary of the talk in a quote is: “Fix each bug only once”. What a great statement.
This was my first talk in the Geospatial devroom, it was somehow inspiring despite I can’t say that I learned a lot. The speaker explained that, as a rock climbing lover, he couldn’t find good data regarding climbing routes, walls and sectors so he started introducing that information himself in OpenStreetMap. He summarized his experience, the decisions that he had to take, and how he is trying to get more contributors for his project: OpenBeta.
I could imagine that this talk was going to be very basic and I guessed right, but I wanted to stay in the devroom for the next talks so I stayed in the room retaining my seat.
The speaker made a general overview about Programming languages to build an OSM based web app, IDEs, mapping libraries, OSM data retrieval tools, routing tools and even version control systems. Good introduction to the topic from a good speaker but I’m not sure if this kind of talks should have a place in FOSDEM.
The speaker was nice and funny, but again the talk was not very advanced. It was more interesting when he talked about the Open Hackerspace that he collaborates with in Tirana (Albania) than the part related to the CitiZen App. The claim that the app is privacy aware is very limited. They just don’t keep your navigation data but in the end whenever they ask for the location of the user, an Android device stores the location anyway (directly or when requesting the nearest POIs).
As a nice addition, CitiZen allows the users to modify or insert the POIs retrieved from OSM by editing them inside the app.
This talk was refreshing and reconciled me with the geospatial devroom. Ilya (software engineer at Maps.me) explained how he ended building the offline subway navigation feature for Maps.me. As he explained, when they started reviewing the available data in OpenStreetMap related to subways they realized that the information was very poor and incomplete. For example there was no way to map properly the connections between lines.
He started building a validator and then station by station, city by city, he improved the subway information in OSM. He even presented a proposal for the subway geospatial information, including new relations for the transfers.
One of the most inspiring talks of the entire FOSDEM with a packed full Janson Room (with capacity for 1415 people).
The speaker explained how during 2016, the Libre Space Foundation a non-profit organization developing open source technologies for space, designed, built and delivered UPSat, the first open source software and hardware satellite.
He explained with some detail how he got involved, the current status of the project, the design, construction, verification, testing and delivery processes, etc. You should consider watching the video :-)
The closing keynote was given by Jon Masters (Computer Architect at Red Hat) about Meltdown and Spectre, as he was tech lead for mitigation efforts against them in Red Hat. Jon was surprisingly capable of explaining in less than 50 minutes what are those vulnerabilities about, how they were possible in the first place and what are the consequences of avoiding them. I already knew most of it but Jon made it even clearer for me, and surely for the rest of the audience given the applause he received.
It was specially amusing for me, as I’ve been refreshing my knowledge about the Tomasulo Algorithm these past months.
And that’s all. See you in Brussels for FOSDEM 2019!!