Thursday, November 22, 2018

GNOME+Rust Hackfest #4

Last week, I had the pleasure of attending the 4th GNOME+Rust hackfest in Thessaloniki, Greece. While other folks were mainly focused on the infrastructure work, with my Rust being extremely rusty as of late, I decided to do something that tests the infra instead. More specifically, I took up on Sebastian's challenge of "Maybe someone should write a gst-inspect replacement in Rust". I am happy to report that by the end of the hackfest, I already have an implementation that covers 30% of the typical usage of gst-inspect. This implementation also comes pre-built with paging by default (which I only recently added to the current gst-inspect) and colored output (MR on existing gst-inspect still pending review).

I did run into some rather interesting issues though but there was always someone who could help me out. One specific one was on how best to pipe the output in Rust to a pager. This took more than a day and my implementation was mostly very similar to the one I did in C. Then I consulted Alex Crichton, who was able to come up with a much cleaner solution in 5 minutes. Another issue was that I wanted to name the binary 'gst-inspect-1.0' but turned out Cargo currently doesn't allow that. It's not big deal and I went with 'gst-inspect' (which might be a better name anyway to avoid conflict with existing binary) for now but me hitting this issue at the hackfest, resulted in Alex providing instructions on how someone would go about fixing this issue.

I also found a few things missing in the gstreamer bindings and added those as part of the work.

I'm still slowly working on adding the feature to show details about plugins and elements but it might take a bit, since I'm pretty swamped with work these days. However, once that feature is in, we've most of gst-inspect usage covered and I can file the merge-request for it.

If for some reason you want to try it out already, the branch is here. Oh and here is a screenshot:



Other than that, we had a lot of conversations about Rust, GStreamer and GNOME during the hackfest and such events really motivates folks to do even more awesome work.

I would like to thank GNOME foundation for sponsoring my trip and especially the GNOME Travel Committee for helping me out when I had an issue with changing my accommodation. I'd also like to thank Collabora for letting me use my work time for this event.


Monday, October 15, 2018

Geoclue 2.5 & repeating call for help

Just wanted to announce release 2.5.0 of Geoclue that includes the changes I mentioned in my last blog post.

Also, while I'm at it, I wanted to highlight the "call for help" at the end of that post by repeating it here again. I apologize of repeating to those who already read it but a friend pointed out that it's likely going to be missed by many folks:

The future of Mozilla Location Service

When Mozilla announced their location service in late 2013, Geoclue became one of its first users as it was our only hope for a reliable WiFi-geolocation source. We couldn't use Google's service as their ToC don't allow it to be used in an open source project (I recall some clause that it can only be used with Google Maps and not any other Map software). Mozilla Location Service (MLS) was a huge success in terms of people contributing WiFi data to it. I've been to quite a few places around Europe and North America in the last few years and I haven't been to any location, that is not already covered by MLS.

Mozilla's own interest in this service was tied to their Firefox OS project. Unfortunately Firefox OS project was abandoned two years ago and Mozilla lost its interest in MLS as a result. Mozilla folks are the good guys so they have kept the service running and users can still contribute data but it's no longer developed or maintained.

Since this is a very important service for all users of geoclue, I feel very uneasy about this uncertain future of MLS. So consider this a call for help. If your company relies on MLS (directly or through Geoclue) and you'd want to secure the future of Open Source geolocation, please do get in touch and we can discuss how we could possibly achieve that.

Sunday, September 23, 2018

Recently in Geoclue

After I started working for Collabora in April, I've finally been able to put some time on maintenance and development of Geoclue again. While I've fixed quite a few issues on the backlog, there has been some significant changes as of late, that I felt deserves some highlighting. Hence this blog post.

Leaving security to where it belongs

 


Since people's location is a very sensitive piece of information, security of this information had been the core part of Geoclue2 design. The idea was (and still is) to only allow apps access to user's location with their explicit permission (that they could easily revoke later). When Geoclue2 was designed and then developed, we didn't have Flatpak. Surely, people were talking about the need for something like Flatpak but even with those ideas, it wasn't clear how location access will be handled.

Hence we decided for geoclue to handle this itself, through an external app authorizing agent and implemented such an agent in GNOME Shell. Since there is no reliable way to identify an app on Linux, there were mixed reactions to this approach. While some thought it's good to have something rather than nothing, others thought it's better to wait for the time when we've the infrastructure that allows us to reliably identify apps.

Fast forward to an year or so ago, when Flatpak portals became a thing, I had a long discussion with Matthias Clasen and Bastien Nocera about how geoclocation should work in Flatpak. We disagreed on our approach and we forgot about the whole thing then.

Some months ago, we had to make app authorizing agent compulsory to plug some security holes and that made a lot of people who don't use GNOME, unhappy. We had to start installing the demo agent for non-GNOME as a workaround. This forced me to rethink the whole approach and after some more long discussions with Matthias and a lot of thinking, the plan is to:
  • Create a Flatpak geolocation portal. Matthias already has a work-in-progress implementation. I really wanted the portal API to be as identical to the Geoclue API but I failed to convince Matthias on that. This is not that big an issue though, as at least the apps using GeoclueSimple API will not need to change anything for accessing location from inside the Flatpak sandbox.
  • Drop all authorization from Geoclue and leave that to the geolocation portal. I've already dropped authorization for non-flatpak (i-e system) apps in git master. Once the portal is in place and GNOME shell and control-center have been modified to talk to it, we can drop all app authorizing code from Geoclue.

    Note
    that we have been able to reliably identify Flatpak apps and it's only the system apps that can lie about their identity.

A modern build system

 


Like many Free Software projects, Geoclue is also now using Meson for its builds. After it started to work reliably, I also dropped autotools-based build completely. The faster build makes development a much more pleasant experience.

And a modern issue tracker to go with it

 

Bugzilla served us well but patches in Bugzilla are no fun, even though git-bz makes it much much better. So when Daniel Stone setup gitlab on freedesktop.org, Geoclue was one of the first few projects to move to gitlab. Now it's much easier and simpler to contribute to Geoclue.

Minimize GeoIP use

 

While GeoIP is a nice backup if you have neither WiFi hardware nor a cellular modem, Geoclue would also use (only) that if an app only asked for city-level accuracy. Apps like GNOME Weather and GNOME Clocks ask for only that since that's the info they need and don't need to know which street you're currently on. This would be perfect if only the GeoIP database being used would be correct or accurate for at least 90% of the IP addresses but unfortunately the reality is far from that. This meant, a significant number of people getting annoyed with these apps showing them time and weather of a different town than their current one.

On the other hand, we couldn't just use a more accurate geolocation source (WiFi) since an app should not get more accurate location it asked for and it was authorized for by the user. While currently we don't have the UI in GNOME (or any other platform) that allows users to control the location accuracy, the infrastructure has always been in place to do that.

Recently one person decided to not only report this but had a good suggestion that I recently implemented: Use WiFi geolocation for city-level accuracy as well but randomize the location enough to mitigate the privacy concerns. It should be noted that while this solution ensures that apps don't get more accurate location then they should, it still means sending out the current WiFi data to the Mozilla Location Service (MLS) and Geoclue getting a very accurate (street-level) location in response. It's all over HTTPS so it's not as bad as it sounds.

The future of Mozilla Location Service


When Mozilla announced their location service in late 2013, Geoclue became one of it's first users as it was our only hope for a reliable WiFi-geolocation source. We couldn't use Google's service as their ToC don't allow it to be used in an open source project (I recall some clause that it can only be used with Google Maps and not any other Map software). MLS was a huge success in terms of people contributing WiFi data to it. I've been to quite a few places around Europe and North America in the last few years and I haven't been to any location, that is not already covered by MLS.

Mozilla's own interest in this service was tied to their Firefox OS project. Unfortunately Firefox OS project was abandoned two years ago and Mozilla lost its interest in MLS as a result. Mozilla folks are the good guys so they have kept the service running and users can still contribute data but it's no longer developed or maintained.

Since this is a very important service for all users of geoclue, I feel very uneasy about this uncertain future of MLS. So consider this a call for help. If your company relies on MLS (directly or through Geoclue) and you'd want to secure the future of Open Source geolocation, please do get in touch and we can discuss how we could possibly achieve that.

Friday, May 18, 2018

Collabora and GStreamer spring in Sweden

Earlier this month, a few of us from Collabora, Olivier Crête, Nicolas Dufresne, George Kiagiadakis and I attended the GStreamer Spring Hackfest in Lund, Sweden. Hosted by Axis Communications (who uses GStreamer in their surveillance cameras for many years now), it was a great opportunity for the GStreamer community to touch base and work on open bugs and pet projects.



While I've been involved in the GStreamer project in the past, it was my first GStreamer hackfest. While a lot was achieved during the event, the most exciting outcomes were no doubt the closing of more than 350 bugs, and the agreement on a transition plan to move to GitLab.

Overall, the hackfest was very productive, with each member of our team managing to progress in their list of tasks while all taking part in bug triaging & cleaning in preparation of moving GStreamer's issue tracking to GitLab.

George spent time working on improving the new library API that is needed to introduce support for the non-interleaved audio layout, discussed a gst-rtsp-server issue with the Axis team, and merged all qt-gstreamer patches that were lying around in bugzilla and resolved all reported bugs, then declared it as unmaintained.

For his part, Nicolas participated in the planar audio format and split field interlaced video support work, started looking at adding per element latency tracing to GStreamer's existing latency tracer, and also discussed GStreamer CI, which will also move to GitLab to be able to run on pull requests also.

Olivier, during the first day, focused on the collective effort of reviewing all of the open bugs, managing to close a number of them while confirming and commenting on others. He also merged some outstanding patches he had (stay tuned for more details on those), and forward ported gst-validate for Android with the goal of running the CI on Android. He also merged a series of patches that enable bitcode embedding on the iOS target with the eventual goal of supporting tvOS as well.

As for myself, I mainly worked on (or rather started to work on) split-field interlacing support in GStreamer, adding relevant formats and modes in the GStreamer video library. In addition, as a Meson developer (Nirbheek Chauhan) was present, I took the opportunity to discuss with him the last bit of porting build system of Geoclue to Meson, a side project I've been working on. It helped me get it done faster but also helped Nirbheek find some issues in Meson and fix them!

All in all, my first GStreamer hackfest was an awesome experience (even though I was not feeling well). It was also very nice to hangout and socialize with old and new friends in the GStreamer community after a long time. Many thanks again to Axis for hosting us in their offices! See you at the GStreamer Conference this fall!

Monday, April 2, 2018

Joining Collabora

Last Thursday was my last day at Kinvolk. While Kinvolk is a great company run by very nice and talented folks and I really hoped to work there for a very long time, unfortunately it turned out to be not the best fit for me.

While I am sad to leave, I am also very excited to join Collabora in their multimedia team. Today is my first day there. Since Collabora does not exist in Germany, I will be working for them as a consultant and had to register my own one-man company. Yes, I will be staying in Berlin and work from home.

I have known Collabora from its very early days, when it was just a few developers with a vision and passion for Open Source. I also worked very closely with Collabora over the years during the good old Nokia Maemo/Meego times. I always had great appreciation for their work and commitment to Open Source, which is a huge challenge for a consulting company.

While I do not yet know which specific projects I will be involved in at Collabora, I'm most likely going to be working on/with GStreamer again and I'm especially excited about that. Also exciting for me is the fact that people at Collabora share my appreciation for the Rust programming language.

Wednesday, December 27, 2017

My journey to Rust

As most folks who know me already know, I've been in love with Rust language for a few years now and in the last year I've been actively coding in Rust. I wanted to document my journey to how I came to love this programming language, in hope that it will help people to see the value Rust brings to the world of software but if not, it would be nice to have my reason documented for my own sake.

When I started my professional career as a programmer 16 years ago, I knew some C, C++, Java and a bit of x86 assembly but it didn't take long before I completely forgot most of what I knew of C++ and Java, and completely focused on C. There were a few difference reasons that contributed to that:
  • Working with very limited embedded systems (I'm talking 8051) at that time, I quickly became obsessed with performance and C was my best bet if I didn't want to write all my code in assembly.
  • Shortly before I graduated, I got involved in GStreamer project and became a fan of GNOME and Gtk+, all of which at that time was in C. Talking to developers of these projects (who at that time seemed like gods), I learnt how C++ is a bad language and why they write everything in C instead.
  • An year after graduation, I developed a network traffic shaping solution and the core of it was a Linux kernel module, which as you know is almost always done in C. Some years later, I also wrote some device drivers for Linux.
The more C code I wrote over the years, the more I developed this love/hate relationship with it. I just loved the control C gave me but hated the huge responsibility it came with. With experience, I became good at avoiding common mistakes in C, but nobody is perfect and if you can make a mistake, you eventually will. Another reason C didn't seem perfect to me was the lack of high-level constructs in the language itself. Copy&pasting boilerplate to write simple GObjects is nothing most people enjoy. You end up avoiding to organise your code in the best way to spare yourself the trouble of having to write GObjects.

So I've been passively and sometimes actively seeking a better programming language for more than a decade now. I got excited about a few different ones over the years but there was always something very essential missing. The first language I got into was Lisp/Scheme (more specifically Guile) but the lack of type declarations soon started to annoy me a lot. I felt the same after then about all scripting languages, e.g Python. Don't get me wrong, python is a pretty awesome language for specific uses (e.g writing tests, simple apps, quick prototyping etc) but with lack of type declarations, any project larger than 1000 LOCs can quickly become hard to maintain (at least it did for me).

Because of my love for strong-typing, C# and Java did attract me too briefly. Not having to care about memory management in most cases, not only helps developers focus on the actual problems they are solving, it indirectly allows them to avoid making very expensive mistakes with memory management. However, if developer is not managing the memory, it's the machine doing it and in case of these languages, it does that at run time and not compile time. As a C developer and a big hater of waste in general, that is very hard to be convinced of as a good idea.

There was another big problem all these high-level languages: you can't nicely glue them with the C world. Sure you can use libraries written in C from them but the other way around is not a viable option (even if possible). That's why you'll find GNOME apps written in all these languages but you will not find any libraries written in them.

Along came Vala


So along came Vala, which offered features that at that time (2007-2008) were the most important to me:
  • It is a strongly-typed language.
  • It manages the memory for you in most cases but without any run time costs.
  • It's high-level language so you avoid a lot of boilerplate.
  • GNOME was and still is the main target platform of Vala.
  • It compiled to C, so you can write libraries in it and use them from C code as if they were written in C. Because of GObject-introspection, this also means you can use them from other languages too.
Those who know me, will agree that I was die-hard (I'm writing this on Christmas day so that reference was mandatory I guess) fan of Vala for a while. I wrote two projects in Vala and given what I knew then I think it was the right decision. Some people will be quick to point out specific technical issues with Vala but I think those could have been helped. There two other reasons, I ultimately gave up on Vala. The first one was that the general interest in it started to decline after Nokia stopped funding projects using Vala and so did its development.

 

Hello Rust


But the main reason for giving up was that I saw something better finally becoming a viable option (1.0 release) and gaining adoption in many communities, including GNOME. While Vala had many good qualities I mentioned above, Rust offered even more:
  • Firstly the success of Rust is not entirely dependent on one very specific project or a tiny group of people, even if until now most of the development has been from one company. Ever month, you hear of more communities and companies starting to depend on Rust and that ensure it's success even if Mozilla was to go down (not that I think it's likely) or stopped working on it. i-e "it's too big to fail". If we compare to Vala, the community is a lot bigger. There are conferences and events happening around the world that are entirely focused on Rust and there are books written on Rust. Vala never came anywhere remotely close to that level of popularity.

    When I would mention Vala in job interviews, interviewers would typically have no idea what I'm talking about but when I mention Rust, the typical response is "Oh yes we are interested in trying that out in our company".
  • While Vala is already a safer language than C & C++, you still have null-pointer dereferencing and some other unsafe possibilities. Safety being one of the main focus of the language design, Rust will not allow you to build unsafe code, unless you mark it as such and even then, your possibilities of messing up are limited. Marking unsafe code as such, makes it much easier to find the source of any issues you might have. More over, you usually only write unsafe code to interface with the unsafe C world.

    This is a very important point in my opinion. I really do not want to live in a world where simple human errors are allowed cause disasters.
Admittedly, there are some benefits of Vala over Rust:
  • Ability to easily write GObjects.
  • Creating shared libraries.
However, some people have been working on the former and latter is already possible with some compromise and tricks.

 

Should we stop writing C/C++ code?


Ideally? Yes! Most definitely, yes. Practically speaking, that is not an option for most existing C/C++ projects out there. I can only imagine the huge amount of resources needed for porting large projects, let alone training existing developers on Rust. Having said that, I'd urge every developer to at least seriously consider writing all new code in Rust rather than C/C++.

Especially if you are writing safety-critical software (people implementing self-driving cars, militaries and space agencies, I'm looking at you!), laziness and mental-inertia are not valid reasons to continue writing potentially unsafe code, no matter how smart and good at C/C++ you think you are. You will eventually make mistake and when you do, lives will be at stake. Think about that please.

 

Conclusion


I am excited about Rust and I'm hopeful the future is much safer thanks to people behind it. Happy holidays and have a fun and safe 2018!

Friday, December 8, 2017

Moving to Berlin

I have been meaning to document my experience of moving to Berlin, mainly to help people who are considering to move or are about to move. However I'm lazy and unless I'm paid to do so, I just won't get around to doing that so instead of ending up posting nothing, I'll just quickly list all the advice I have here:

  • Don't actually order any services through check24 website. Only use them to compare prices etc.
  • Avoid Vodafone for broadband connection. Follow this thread for why.
  • Consider using an online bank, like N26.
  • For your Anmeldung,
    • go to Bürgeramt in Neukölln or Kreuzberg (unless you speak German).
    • book appointment around noon or be prepared to wait a month.
  • Make sure you have local friends who speak German and are willing to help you out. Many locals will tell you that you don't need German in Berlin but that is simply not true.
  • Either consider hiring an estate agent or make sure your temporary residence allows you to register on their address.
  • Related to above, you don't have to pay deposit upfront if you use EuroKaution service.
  • Consider the after 10am monthly travel pass if you don't commute to work before that time.