Coder's Log

zbus As many of the readers already know, for the past (almost) 2 years, I've been developing a Rust-crate for D-Bus, called zbus . With this being my first big Rust project to start from scratch done almost entirely in my spare time, the progress was rather slow for many months. My perfectionism didn't help much with the progress either but also the fact that implementing a Serde API for the D-Bus format was quite challenging. Then along came my old friend and ex-colleague, Marc-André Lureau who sped up the progress 10 times and soon after we had the 1.0 release of zbus. While my original plan (perfectionism again) was for the API to be primarily async, with the synchronous API mostly just a wrapper around it, it was Marc-Andre who ended up doing most of the work and coming up with nice high-level API and his use case was primarily synchronous so we decided to go with synchronous API first. I still believe that was the right thing to do, since neither of us were fam

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

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

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

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

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

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 beca

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

Well, no, not really but maybe I'll be able to claim that at some point because I'm moving to Berlin to join Kinvolk. I'm told that I'm changing countries and companies too often but that's not true. I was at Red Hat for 5 years and at Nokia before that for 5 years as well. The decision to move out of Finland was not exactly mine. Regarding Pelagicore I'm not as much leaving Pelagicore as I'm leaving the automotive industry, more specifically the software side of it. While the automotive industry is changing and mostly for the good, I realized that it still is not a place for me. Things typically move very slowly in this industry and I realized that I don't have the required patience for it. Also, C++/Qt are big here and while an year ago I thought it's just another language and Open Source UI framework, I no longer think so. Since you can find a lot of rants from very experienced C++ developers on why C++ is a horrible language, I won't rant

For gps-share to be useful to people, it needs to be tested against various GPS dongles. If you have a GPS dongle, I'd appreciate it if you could test gps-share. If you don't use the hardware, please consider donating it to me and that way I'll ensure that it keeps working with gps-share. Thanks!

So yesterday, I rolled out the first release of gps-share. gps-share is a utility to share your GPS device on local network. It has two goals: Share your GPS device on the local network so that all machines in your home or office can make use of it. Enable support for standalone (i-e not part of a cellular modem) GPS devices in Geoclue. Since Geoclue has been able to make use of network NMEA sources since 2015, gps-share works out of the box with Geoclue. The latter means that it is a replacement for GPSD and Gypsy . While "why not GPSD?" has already been documented , Gypsy has been unmaintained for many years now. I did not feel like reviving a dead project and I really wanted to code in Rust language so I decided to create gps-share. Dependencies While cargo manages the Rust crates gps-share depend on, you'll also need the following on your host: libdbus libudev libcap xz-libs Supported devices gps-share currently only supports GPS devices tha

In the light of my latest fascination with Rust programming language, I've started to make small presentation about Rust at my office , since I'm not the only one at our company who is interested in Rust. My first presentation in Feb was about a very general introduction to the language but at that time I had not yet really used the language for anything real myself so I was a complete novice myself and didn't have a very good idea of how memory management really works. While working on my gps-share project in my limited spare time, I came across quite a few issues related to memory management but I overcame all of them with help from kind folks at #rust-beginners IRC channel and the small but awesome Rust-GNOME community. Having learnt some essentials of memory management, I thought I share my knowledge/experience with folks at the office. The talk was not well-attended due to conflicts with other meetings at office but the few folks who attended were very interested an

While I'm known as a Vala fanboy in GNOME, I've tried to stress time and again that I see Vala as more a practical solution than an ideal one. "Safe programming" has always been something that intrigued me, having dealt with numerous crashes and other hard-to-debug runtime issues in the past. So when I first heard of Rust some years back, it got me super excited but it was not exactly stable  and there was no integration with GNOME libraries or D-Bus and hence it was not at all a viable option for developing desktop code. Lately (in past 2 years) things have significantly changed. Not only we have Rust 1.0 but we also have crates that provide integration with GNOME libraries and D-Bus . On top of that, some of us took steps to start converting some C code into Rust and many of us started seriously talking with Rust hackers to make Rust a first class programming language for GNOME. To make things really go foward, we decided to arrange a hackfest , which took place

Are you a student? Passionate about Open Source? Want your code to run on next generation of automobiles? You're in luck! Genivi Development Platform will be participating in Google Summer of Code this summer and you are welcome to participate. We have collected a bunch of ideas for what would be a good 3 month project for a student but you're more than welcome to suggest your own project. The ideas page , also has instructions on how to get started with GDP. We look forward to your participation!

Quite a few major life events happened/happening this summer so I thought I blog about them and some of the experiences I had. New job & new city/country Yes, I found it hard to believe too that I'll ever be leaving Red Hat and the best manager I ever had (no offence to others but competing with Matthias is just impossible) but I'll be moving to Gothenburg to join Pelagicore folks as a Software Architect in just 2 weeks. I have always found Swedish language to be a very cute language so looking forward to my attempt of learning Swedish. If only I had learnt Swedish rather than Finnish when I was in Finland. BTW, I'm selling all my furniture so if you're in London and need some furniture, get in touch! Fresh helicopter pilot So after two years of hard work and getting myself sinking in bank loans, I finally did it! Last week, I passed the skills test for Private Pilot License (Helicopters) and currently awaiting anxiously for my license to come through (it

Last week I travelled to Brussels to attend and present at FOSDEM . Since I was going there anyway, I decided to also join 2.5 days of GNOME Developer Experience Hackfest . Travelling to Brussels is usually pretty easy and fast, thanks to Eurostar but I turned it into a bit of nightmare this time. I had completely forgotten how London public transport is a total disasters in peak hours and hence ended-up arriving too late at the station. Not a big deal, they put me on the next train for free. I decided to go through security already and that's when I realized that I have forgotten my laptop at home. :( Fortunately my nephew (who is also my flatmate) was still at home and was going to travel to city centre anyway so I asked him to bring it with him. After two hours of anxiously waiting, he managed to arrive just in time for train staff to let in the very last late arriving passenger. Phew! While I didn't have a particular agenda for the hackfest, I had a discussion with Ale

What makes for a good maintainer? Although I do not know of a definite answer to this important but vague and controversial  question, maintaining various free software projects over the last many years, I've been learning some lessons on how to strive to be a good maintainer; some self-taught through experience, some from my colleagues (especially our awesome GNOME designers) and some from my GSoC students. I wanted to share these lessons with everyone so I arranged a small BoF at GUADEC and thought it would be nice to share it on planet GNOME as well. Some points only apply to UIs here, some only to libraries (or D-Bus service or anything with a public API really) and some to any kind of project. Here goes: Only accept use cases There are no valid feature requests without a proper use case behind them. What's a proper use case you ask? In my opinion, it's based on what the user needs, rather than what they desire or think they need. "I want a button X tha