Open Source Geolocation
Ali, Zeeshan
In this talk, Zeeshan will share his story of development of Geoclue, the open source geolocation service for Linux. He'll talk about the challenges and setbacks faced during these years in developing a framework designed to provide a simple API to application developers while also addressing the privacy issues related to giving out users' location to random applications. Also presented will be the current big problems faced by the project and possible solutions to them.
 Hello, can you hear me? Well, I was going to say already start from who I am. So, my name is Sishan Ali. I had to check to make sure. I work for this company called IBM, I'm sorry, Red Hat. And it's been two weeks, but I worked at Red Hat before, five years on desktop team. I've been trying to get back for a while and now I finally made it back, but not in the desktop team, but in another team, containers, related stuff. So, new stuff for me to learn and stuff. Should I start with the actual? Yes. Okay, cool. And I've been involved in FOSS in different companies and different levels and stuff. Mostly GNOME stuff, but other things as well, like G-Streamer and related stuff mostly. I went to flying, I have a helicopter license working on my plane license, and I like cats. And the story I'm going to tell you is a very small, boring one, but maybe some interesting, somewhat. I started in 2007 and it sounds like a Spanish conspiracy because these two guys, this guy and this guy, they were both sitting together somewhere with some people from Garmin and they said, oh, what about we have geolocation service for Linux because there is nothing like that right now. And since D-Bus is the way to go nowadays, so it would be using D-Bus. So, they decided to create a project called Geoclue, which is a D-Bus-based geolocation service. The concept is very simple. The application asks this service like where I am right now, and the service just tells them that. And they found a victim, I mean, a summer of course student to do the actual work. And this guy did all the hard work and he made it possible, the Geoclue. And the concept was based on external providers. So, each source of location was an external source. So, within the system, the service itself, there was nothing. It was only an API for applications to talk to and for service providers to hook into the service. So, they can tell it where the location and give it updates about location and stuff. And the easiest one in any kind of application like geolocation, you can implement as GeoIP, which is the simplest one because any service out there can see your external IP and tell what it thinks where it is. And there is a database already out there. MaxMind is a company that maintains it, and they have like a commercial version of that database, and there is a free version of that database. There is not a lot of difference between them actually in practice, but there is some. So, yeah, based on that, they implemented GeoIP provider. They also kind of provided a Wi-Fi geolocation, but they couldn't really because the only ones were proprietary and they couldn't use it in open-source software. So, they kind of created a source that you can manually tell it like, okay, these Wi-Fis, if you see these, then it means I'm on this location. So, a user had to manually do that, and that's not really, you know, it doesn't work out of the box. So, I don't think anyone actually used that. I'd be surprised if they did. And one of the things that is essential is support for GPS devices. So, they created another person, came along, and he was interested in GPS support in GeoCLU, and implemented Gypsy Ian Holmes as his name. But there was already a project called GPS-D. It's maintained by Ira Kremer, I think. And the reason they didn't take that was it had a very, very conservative architecture. They wanted everything to be allocated on the stack, and it created many other problems. It increased memory usage and stuff like that. And they had a very archaic IPC mechanism. They didn't want to use D-Bus at all, and they were afraid of that. They said it doesn't work and stuff. Anyway, so there was a bit of a clash, and they both have written really long blog posts explaining why they did what they did, like why Gypsy and why GPS-D still. Anyway, so, and then since some of the Garmin people were involved in the creation of GeoCLU, they used it in their devices, as far as I know, and also in many MIMO and MIGO devices, GeoCLU was used. It still is being used in YOLA devices, if you know that one. So, yeah. But over time, the dreams were forgotten. People got busy with other things. GeoCLU was un-maintained for years. Gypsy was un-maintained for even longer. The guy who wrote GeoCLU, Yusie Kukar, and he's a good friend, and I still meet him, and he's still involved in open source. But the guy who wrote Gypsy, he has vanished, I think, I haven't seen him for 15 years or something. And then in 2013, when I was still in desktop group of the Red Hat, I was bored. I have been doing the same application for three years continuously, which is GNOME Boxes, and I want to do something different. So I was like, what should I do? And talk to this guy, he's involved in all parts of GNOME, at least, and free desktop software. And he was kind of involved in GeoCLU development at some point. So he had some ideas about creating a new GeoCLU, which, because the old GeoCLU was getting really old, the source code was not really nicely written in the end, and also it was using a lot of libraries and APIs that were not really maintained, those APIs are not there anymore. So instead of revising that old software, and also the architecture is like the external providers I mentioned. So it sounded like a really good idea on paper, but practically it's not such a good idea because many people created their own providers, and they use them in their own devices, but they never contributed upstream. So the upstream GeoCLU you take on your desktop machines, they only have GUIP, and it's not very useful at all. So because of that, we created GeoCLU 2 with Bastia Nocera. And the idea was much simpler architecture, which is not just good for developers, but also for application developers, and for anyone who uses it. For example, we only have internal sources, we don't have external source. There is one exception to that, I'll tell later, but ideally all sources belong in our code. And if you want to add some source, please come and contribute that. And also GeoCLU usually used to provide, GeoCLU 1 used to provide Geocoding service, Geocoding API. And we thought that doesn't really belong there, it should be a separate service. People should be able to use that separately from Geolocation. So that code was put into a separate library called GeocodeGLIB. And another reason for redesigning GeoCLU 2 was privacy, because GeoCLU 1 had no concept of privacy, it would just give the location to any application that asked it. But you know, location is like a very sensitive piece of information, so if any application can get it, it could be a really bad application that wants it. You downloaded some random application off the internet and takes your location and gives it to someone. So the idea was having an app authorizing agent, and that has to be external. And the first OS that was added to was GNOME, because I was working on GNOME stuff, so it was natural for me to add it to that at least myself. So currently if you use some application right now that does location, for example GNOME Maps or something, you will get a dialogue and then it saves that permission from you in a database and stuff. And similarly, elementary, I think one year ago or two years ago, they also added an app authorizing agent for GeoCLU. As for the sources, the first source of course, as I mentioned, the easiest one is GUIP. So we added that as first thing. And Modems was another kind of easy thing, because there's already two back ends for managing Modems. One is Modem Manager, the other one is Ophono. Modem Manager is the one being used on GNOME and stuff, so I use that. I actually have a blog post about that, why Modem Manager is much better than Ophono. But I'm nothing against people adding Ophono, but we have Modem Manager support already. And it does support two things. One is cell tower based location, which is not very accurate. It's a few kilometers at best. And the GPS, which most Modems nowadays, they come with a GPS on it. So we get a GPS location, which is a lot more accurate, of course. But the problem is that not everyone has a Modem and a lot of laptops, even if you have a Modem, many corporates just disable it because nobody, this thing nobody uses. And when you're stuck with GIP, the GIP at best can give you city level location, and that's not good. Sometimes that's even very wrong, and people get really frustrated. So we need something more accurate that is more abundant, which can be used on many most laptops and stuff. And that's Wi-Fi based geolocation. The concept is simple. You see which Wi-Fi network you see. You get a list of that, the strands, and then you send it to server, and server tells you, OK, these devices are in this particular street. So you get a street level accuracy, which is really good already. But the problem was how do we do that? Where's the server? Which server we can use? We can't use Google servers. You can't use Microsoft's or Apple's or whatever. The one we could use was Yahoo's, which was there for a bit that you can use in open source software. But there was some limits to the data rate and all that. So it wasn't ideal, but we had to use something, right? But then, soon after I started Geoclue 2, Mozilla came out with their own service, which is called Mozilla Location Service, and that does the Wi-Fi based geolocation. And they utilized their vast number of users around the world to gather all the data about Wi-Fi. So within months, they had a huge, huge amount of data from across the world. And it was completely open. So it's open source. Data is not open for privacy reasons, exactly. But that's a completely different topic for another talk. But we can talk about it afterwards if you want. But anyway, it was a really good send. We used that service immediately. And we were one of the first users, external users of that service. But as I mentioned, laptops have Wi-Fi, so you can use it. But most desktop machines do not have Wi-Fi. So what about them? Are they stuck with GUIP? More or less, yes. But we came up with a solution for that. A summer, of course, student implemented this. So the idea is that you share from your phone, all the phones nowadays, the smartphones have GPS devices nowadays. So you share your GPS location on your network, on your Wi-Fi network, or your internal network. And then anyone can use it, any software. And as a part of his project, he, of course, added support in GeoClu. So there's an application called GeoCluShare, which you can install on your Android device. And you get the Android device location on your desktop or laptop or whichever device you want. So that was a kind of workaround for desktop machines. But that's the best we could do. There's no other way. And it uses a Wi to tell, announce its location on network. What about standalone GPS devices? As I said, modems have GPS, but not like, that's not the only place for GPS. There's standalone ones that you can plug into USB usually, or Bluetooth. How about them? The problem with those is that they usually need some kind of configuration. They don't work out at the box, at least right now. There's a new Linux subsystem coming. I've heard that we'll solve this problem, at least for many devices, modern devices. But I don't know if it will solve for all devices. So you need to set bot rate and stuff like that on the serial port that it exposes on. So since it needs an external means, we thought, OK, what about Gipsy? We can use that. But that has been maintained for much, much longer, unmaintained for much longer than GeoClue. The guy who wrote it, he's nowhere to be found. Yeah, source code is not that great. And yeah, so we thought like, and it's written in C, and I've been more into Rust these days. So I decided to just write a new one, GPS share, it's called. And another reason to rewrite that is that it's not a Diva service, but it works the same as the GeoClue share I mentioned, the app. So it just exposes your network on the local network if you wanted to. And since GeoClue already had the support for NME over TCP, so it could readily use this software that I wrote in Rust. So that's on GitHub, and you can use that for standalone devices. And of course, from day one, we had GNOME integration because I was interested in that in GNOME. Maps, actually, this is a GNOME maps as a software I started. Nowadays, another person is that guy is maintaining it. And this one I mentioned is a Finnish conspiracy, and the maps is more a Swedish one because always a maintainer is a Swedish guy. And, yeah, anyway. And of course, one of the cool features we wanted to have with GeoLocation was automatic time zone update. So many devices have implemented there so long ago, but we never had this. So it was really cool to have it in GNOME. And of course, clocks and weather needs location as well. Webkit GTK for different web pages. And, yeah, so those were the apps. And more recently, we had some positive development as well. Like, Free Desktop created the GitLab instance, and I think now it's the only GitLab. And GeoClue was one of the first ones to move. I said to Daniel, like, yeah, I want to be the first one to move there. And it was like immediately positive effect because it makes things so simpler and easier. And also, all of a sudden, there were many contributors to GeoClue, not just in terms of issue reporting, but also patches were being submitted before there was rarely any external people other than me giving patches. But now there's a lot of people, well, enough people, more than before. Another change was Flatpak. So I mentioned about privacy. At that time, Flatpak wasn't there. There was a concept of that. There was some development, but it wasn't really there. What is Flatpak? It's an app bundling solution. So you put all your app with all its dependencies in one bundle, and then you can distribute it for all the distributions. You don't have to package it for distribution distributions. And also, one of the core concepts is sandboxing. So first, they were focused on bundling, but nowadays they are focusing on sandboxing as well. And when it comes to sandboxing an app, you don't want the app to access system bus at all. And GeoClue is on system bus for many reasons. So I talked to the person, Mathias Klassen, who is working on the sandboxing solutions. They are called portals. The portals are a way for app to get to system without actually directly having access to the system, the whole system. So it's much more secure. And he wanted to do a geolocation portal, but since we already have a privacy story, we had to remove some of that code. And now, hopefully, we will eventually remove all of our privacy stuff in favor of the Flatpak geolocation portal. And Flatpak will handle all your apps. We'll talk to Flatpak's portal, and that will talk to GeoClue for us for you. So it will be more secure that way. But we have challenges ahead. Mozilla Location Service, when it was announced, Mozilla was still doing devices. They were into mobile stuff, and that was their main use case for it. But they haven't been into that for two years, at least now. They are really nice people, so they are keeping it up. The service is still there. We can still use it. And I think you can also contribute back to it, like with their Android app. But how long would it be there? Nobody knows. So there is this uncertainty about the service. And the service is extremely important for free desktop right now. Because if you can't get your location, all these apps, they are not very useful. And especially, there is something like automatic times on update. Once you get used to that, you're kind of expecting it to always work, right? So it would be a pity if we can't locate you anymore all of a sudden. And we have only your city-level location at best. So I would be interested in hearing about if anyone has any suggestion on how to fix this problem. The code is open source. It can be moved somewhere else. It can be hosted by somewhere else, the same service. So if anyone has any ideas, let me know. You want more platforms. A lot of embedded devices, they took GeoClue 1, and they are still using that one. And that source code is not even there anymore. It's not just unmaintained. It's just not there, the source code upstream. So it's a maintenance burden. So I think they really should all move to GeoClue 2. Of course, it's a bit of a task because the API is different, architecture is different. But I think it's worth it to do that effort. And it's been a while. It's been like four years, three, four years that GeoClue 2 came out. So it's time. Now we need more developers. As I mentioned with GitLab, I saw more contribution coming in, a lot more than before. But I would like some more developers to actually start actively working on it. There we have many different tasks to still fix in GeoClue. So I work. If you want to work on something cool, please consider this project. Also, as I mentioned before Rust, so I really don't believe that any new source code should be written in C and C++ at least. I understand existing source code, especially large code base, remaining in C and C++ because it's a lot of work to port to Rust. So that's understandable. But this GeoClue score is not that big. And it could be done if I count in Mondays like a month at best, if I do work on it full-time. But that's like the worst-case scenario. I'm hoping maybe it will be a summer of code project, but we will see. But if anyone else wants to help me with that, it would be awesome. And it will go much, much faster, much easier. And if you want to have some kind of practice of Rust and or porting to Rust from C, this is a really ideal project for that because it's a simple architecture, very few objects, and it would be really good practice if you want that practice for this. That's my presentation. Thank you very much. APPLAUSE It takes us about 10 minutes of question and answers if you want. So you have all the freedom to show it. Yes. We have been integrating with several ways to get a location. Are there other ways in mind on your roadmap to integrate as well? Not really. I would like to improve. The question was that if we have other sources in mind for GeoClue for getting location. No. The thing is that the app I mentioned, the GPS Share, that doesn't support all devices yet. I didn't get enough time to work on that and improve on that. So if you want to or someone else wants to help on that, that would be awesome. Yeah, that's my main thing. Another source could be the GPS sharing app for Android. It's only for Android. There is no support for Apple for what is it called, iPhone. So if someone can add that, that would be cool too. Anybody else? Yes, please. Similar question from another angle. We are having to use them all GPS. What about including all the other sources like Galileo for instance? No. The question was what about Galileo, most more or less. But when we say GPS, it's not just GPS. It's all the satellites, all the networks. We want them all. And... Yeah, GNSS. Yeah. And actually they were purchased to GPS Share for fixing that. Like I was assuming in the strings that it starts with a GP, which is for GPS. But someone fixed that, I think. So it supports all those. More. No. For real sake, goodbye to you. Is there anybody, because we have five, six minutes left, that wants to do a lightning talk. In the previous sort of surplus time slots, there was always somebody who wanted to do a little blurb in front of us. And he got a standing applause almost, just because he dared, or she dared. Is there a she that wants to stand up and do something? Come on. Did you want something from the crowd? No? You're just here to consume. Well, thank you very much. APPLAUSE
 Hello, can you hear me?  Well, I was going to say already start from who I am.  So, my name is Sishan Ali.  I had to check to make sure.  I work for this company called IBM, I'm sorry, Red Hat.  And it's been two weeks, but I worked at Red Hat before, five years on desktop team.  I've been trying to get back for a while and now I finally made it back,  but not in the desktop team, but in another team, containers, related stuff.  So, new stuff for me to learn and stuff.  Should I start with the actual?  Yes.  Okay, cool.  And I've been involved in FOSS in different companies and different levels and stuff.  Mostly GNOME stuff, but other things as well, like G-Streamer and related stuff mostly.  I went to flying, I have a helicopter license working on my plane license, and I like cats.  And the story I'm going to tell you is a very small, boring one, but maybe some interesting, somewhat.  I started in 2007 and it sounds like a Spanish conspiracy because these two guys, this guy and this guy,  they were both sitting together somewhere with some people from Garmin and they said,  oh, what about we have geolocation service for Linux because there is nothing like that right now.  And since D-Bus is the way to go nowadays, so it would be using D-Bus.  So, they decided to create a project called Geoclue, which is a D-Bus-based geolocation service.  The concept is very simple.  The application asks this service like where I am right now,  and the service just tells them that.  And they found a victim, I mean, a summer of course student to do the actual work.  And this guy did all the hard work and he made it possible, the Geoclue.  And the concept was based on external providers.  So, each source of location was an external source.  So, within the system, the service itself, there was nothing.  It was only an API for applications to talk to and for service providers to hook into the service.  So, they can tell it where the location and give it updates about location and stuff.  And the easiest one in any kind of application like geolocation, you can implement as GeoIP,  which is the simplest one because any service out there can see your external IP and tell what it thinks where it is.  And there is a database already out there.  MaxMind is a company that maintains it, and they have like a commercial version of that database,  and there is a free version of that database.  There is not a lot of difference between them actually in practice, but there is some.  So, yeah, based on that, they implemented GeoIP provider.  They also kind of provided a Wi-Fi geolocation, but they couldn't really because the only ones were proprietary  and they couldn't use it in open-source software.  So, they kind of created a source that you can manually tell it like,  okay, these Wi-Fis, if you see these, then it means I'm on this location.  So, a user had to manually do that, and that's not really, you know, it doesn't work out of the box.  So, I don't think anyone actually used that.  I'd be surprised if they did.  And one of the things that is essential is support for GPS devices.  So, they created another person, came along, and he was interested in GPS support in GeoCLU,  and implemented Gypsy Ian Holmes as his name.  But there was already a project called GPS-D. It's maintained by Ira Kremer, I think.  And the reason they didn't take that was it had a very, very conservative architecture.  They wanted everything to be allocated on the stack, and it created many other problems.  It increased memory usage and stuff like that.  And they had a very archaic IPC mechanism.  They didn't want to use D-Bus at all, and they were afraid of that.  They said it doesn't work and stuff.  Anyway, so there was a bit of a clash, and they both have written really long blog posts explaining why they did what they did,  like why Gypsy and why GPS-D still.  Anyway, so, and then since some of the Garmin people were involved in the creation of GeoCLU,  they used it in their devices, as far as I know, and also in many MIMO and MIGO devices, GeoCLU was used.  It still is being used in YOLA devices, if you know that one.  So, yeah.  But over time, the dreams were forgotten.  People got busy with other things.  GeoCLU was un-maintained for years.  Gypsy was un-maintained for even longer.  The guy who wrote GeoCLU, Yusie Kukar, and he's a good friend, and I still meet him, and he's still involved in open source.  But the guy who wrote Gypsy, he has vanished, I think, I haven't seen him for 15 years or something.  And then in 2013, when I was still in desktop group of the Red Hat, I was bored.  I have been doing the same application for three years continuously, which is GNOME Boxes, and I want to do something different.  So I was like, what should I do?  And talk to this guy, he's involved in all parts of GNOME, at least, and free desktop software.  And he was kind of involved in GeoCLU development at some point.  So he had some ideas about creating a new GeoCLU, which, because the old GeoCLU was getting really old,  the source code was not really nicely written in the end,  and also it was using a lot of libraries and APIs that were not really maintained, those APIs are not there anymore.  So instead of revising that old software, and also the architecture is like the external providers I mentioned.  So it sounded like a really good idea on paper, but practically it's not such a good idea because many people created their own providers,  and they use them in their own devices, but they never contributed upstream.  So the upstream GeoCLU you take on your desktop machines, they only have GUIP, and it's not very useful at all.  So because of that, we created GeoCLU 2 with Bastia Nocera.  And the idea was much simpler architecture, which is not just good for developers, but also for application developers,  and for anyone who uses it.  For example, we only have internal sources, we don't have external source.  There is one exception to that, I'll tell later, but ideally all sources belong in our code.  And if you want to add some source, please come and contribute that.  And also GeoCLU usually used to provide, GeoCLU 1 used to provide Geocoding service, Geocoding API.  And we thought that doesn't really belong there, it should be a separate service.  People should be able to use that separately from Geolocation.  So that code was put into a separate library called GeocodeGLIB.  And another reason for redesigning GeoCLU 2 was privacy, because GeoCLU 1 had no concept of privacy,  it would just give the location to any application that asked it.  But you know, location is like a very sensitive piece of information, so if any application can get it,  it could be a really bad application that wants it.  You downloaded some random application off the internet and takes your location and gives it to someone.  So the idea was having an app authorizing agent, and that has to be external.  And the first OS that was added to was GNOME, because I was working on GNOME stuff, so it was natural for me to add it to that at least myself.  So currently if you use some application right now that does location, for example GNOME Maps or something,  you will get a dialogue and then it saves that permission from you in a database and stuff.  And similarly, elementary, I think one year ago or two years ago, they also added an app authorizing agent for GeoCLU.  As for the sources, the first source of course, as I mentioned, the easiest one is GUIP.  So we added that as first thing.  And Modems was another kind of easy thing, because there's already two back ends for managing Modems.  One is Modem Manager, the other one is Ophono.  Modem Manager is the one being used on GNOME and stuff, so I use that.  I actually have a blog post about that, why Modem Manager is much better than Ophono.  But I'm nothing against people adding Ophono, but we have Modem Manager support already.  And it does support two things.  One is cell tower based location, which is not very accurate.  It's a few kilometers at best.  And the GPS, which most Modems nowadays, they come with a GPS on it.  So we get a GPS location, which is a lot more accurate, of course.  But the problem is that not everyone has a Modem and a lot of laptops, even if you have a Modem,  many corporates just disable it because nobody, this thing nobody uses.  And when you're stuck with GIP, the GIP at best can give you city level location, and that's not good.  Sometimes that's even very wrong, and people get really frustrated.  So we need something more accurate that is more abundant, which can be used on many most laptops and stuff.  And that's Wi-Fi based geolocation.  The concept is simple.  You see which Wi-Fi network you see.  You get a list of that, the strands, and then you send it to server, and server tells you, OK, these devices are in this particular street.  So you get a street level accuracy, which is really good already.  But the problem was how do we do that?  Where's the server? Which server we can use?  We can't use Google servers.  You can't use Microsoft's or Apple's or whatever.  The one we could use was Yahoo's, which was there for a bit that you can use in open source software.  But there was some limits to the data rate and all that.  So it wasn't ideal, but we had to use something, right?  But then, soon after I started Geoclue 2, Mozilla came out with their own service, which is called Mozilla Location Service,  and that does the Wi-Fi based geolocation.  And they utilized their vast number of users around the world to gather all the data about Wi-Fi.  So within months, they had a huge, huge amount of data from across the world.  And it was completely open.  So it's open source.  Data is not open for privacy reasons, exactly.  But that's a completely different topic for another talk.  But we can talk about it afterwards if you want.  But anyway, it was a really good send.  We used that service immediately.  And we were one of the first users, external users of that service.  But as I mentioned, laptops have Wi-Fi, so you can use it.  But most desktop machines do not have Wi-Fi.  So what about them?  Are they stuck with GUIP?  More or less, yes.  But we came up with a solution for that.  A summer, of course, student implemented this.  So the idea is that you share from your phone,  all the phones nowadays, the smartphones have GPS devices nowadays.  So you share your GPS location on your network,  on your Wi-Fi network, or your internal network.  And then anyone can use it, any software.  And as a part of his project, he, of course,  added support in GeoClu.  So there's an application called GeoCluShare,  which you can install on your Android device.  And you get the Android device location on your desktop or laptop  or whichever device you want.  So that was a kind of workaround for desktop machines.  But that's the best we could do.  There's no other way.  And it uses a Wi to tell, announce its location on network.  What about standalone GPS devices?  As I said, modems have GPS, but not like,  that's not the only place for GPS.  There's standalone ones that you can plug into USB usually, or Bluetooth.  How about them?  The problem with those is that they usually need some kind of configuration.  They don't work out at the box, at least right now.  There's a new Linux subsystem coming.  I've heard that we'll solve this problem, at least for many devices,  modern devices.  But I don't know if it will solve for all devices.  So you need to set bot rate and stuff like that on the serial port that it exposes on.  So since it needs an external means, we thought, OK, what about Gipsy?  We can use that.  But that has been maintained for much, much longer,  unmaintained for much longer than GeoClue.  The guy who wrote it, he's nowhere to be found.  Yeah, source code is not that great.  And yeah, so we thought like, and it's written in C,  and I've been more into Rust these days.  So I decided to just write a new one, GPS share, it's called.  And another reason to rewrite that is that it's not a Diva service,  but it works the same as the GeoClue share I mentioned, the app.  So it just exposes your network on the local network if you wanted to.  And since GeoClue already had the support for NME over TCP,  so it could readily use this software that I wrote in Rust.  So that's on GitHub, and you can use that for standalone devices.  And of course, from day one, we had GNOME integration  because I was interested in that in GNOME.  Maps, actually, this is a GNOME maps as a software I started.  Nowadays, another person is that guy is maintaining it.  And this one I mentioned is a Finnish conspiracy,  and the maps is more a Swedish one because always a maintainer is a Swedish guy.  And, yeah, anyway.  And of course, one of the cool features we wanted to have with GeoLocation  was automatic time zone update.  So many devices have implemented there so long ago,  but we never had this.  So it was really cool to have it in GNOME.  And of course, clocks and weather needs location as well.  Webkit GTK for different web pages.  And, yeah, so those were the apps.  And more recently, we had some positive development as well.  Like, Free Desktop created the GitLab instance,  and I think now it's the only GitLab.  And GeoClue was one of the first ones to move.  I said to Daniel, like, yeah, I want to be the first one to move there.  And it was like immediately positive effect because it makes things so simpler and easier.  And also, all of a sudden, there were many contributors to GeoClue,  not just in terms of issue reporting, but also patches were being submitted  before there was rarely any external people other than me giving patches.  But now there's a lot of people, well, enough people, more than before.  Another change was Flatpak.  So I mentioned about privacy.  At that time, Flatpak wasn't there.  There was a concept of that.  There was some development, but it wasn't really there.  What is Flatpak?  It's an app bundling solution.  So you put all your app with all its dependencies in one bundle,  and then you can distribute it for all the distributions.  You don't have to package it for distribution distributions.  And also, one of the core concepts is sandboxing.  So first, they were focused on bundling,  but nowadays they are focusing on sandboxing as well.  And when it comes to sandboxing an app, you don't want the app to access system bus at all.  And GeoClue is on system bus for many reasons.  So I talked to the person, Mathias Klassen, who is working on the sandboxing solutions.  They are called portals.  The portals are a way for app to get to system  without actually directly having access to the system, the whole system.  So it's much more secure.  And he wanted to do a geolocation portal,  but since we already have a privacy story, we had to remove some of that code.  And now, hopefully, we will eventually remove all of our privacy stuff  in favor of the Flatpak geolocation portal.  And Flatpak will handle all your apps.  We'll talk to Flatpak's portal, and that will talk to GeoClue for us for you.  So it will be more secure that way.  But we have challenges ahead.  Mozilla Location Service, when it was announced, Mozilla was still doing devices.  They were into mobile stuff, and that was their main use case for it.  But they haven't been into that for two years, at least now.  They are really nice people, so they are keeping it up.  The service is still there. We can still use it.  And I think you can also contribute back to it, like with their Android app.  But how long would it be there? Nobody knows.  So there is this uncertainty about the service.  And the service is extremely important for free desktop right now.  Because if you can't get your location, all these apps, they are not very useful.  And especially, there is something like automatic times on update.  Once you get used to that, you're kind of expecting it to always work, right?  So it would be a pity if we can't locate you anymore all of a sudden.  And we have only your city-level location at best.  So I would be interested in hearing about if anyone has any suggestion on how to fix this problem.  The code is open source. It can be moved somewhere else.  It can be hosted by somewhere else, the same service.  So if anyone has any ideas, let me know.  You want more platforms. A lot of embedded devices, they took GeoClue 1,  and they are still using that one.  And that source code is not even there anymore.  It's not just unmaintained. It's just not there, the source code upstream.  So it's a maintenance burden.  So I think they really should all move to GeoClue 2.  Of course, it's a bit of a task because the API is different, architecture is different.  But I think it's worth it to do that effort.  And it's been a while. It's been like four years, three, four years that GeoClue 2 came out.  So it's time.  Now we need more developers.  As I mentioned with GitLab, I saw more contribution coming in, a lot more than before.  But I would like some more developers to actually start actively working on it.  There we have many different tasks to still fix in GeoClue.  So I work. If you want to work on something cool, please consider this project.  Also, as I mentioned before Rust, so I really don't believe that any new source code  should be written in C and C++ at least.  I understand existing source code, especially large code base,  remaining in C and C++ because it's a lot of work to port to Rust.  So that's understandable.  But this GeoClue score is not that big.  And it could be done if I count in Mondays like a month at best,  if I do work on it full-time.  But that's like the worst-case scenario.  I'm hoping maybe it will be a summer of code project, but we will see.  But if anyone else wants to help me with that, it would be awesome.  And it will go much, much faster, much easier.  And if you want to have some kind of practice of Rust and or porting to Rust from C,  this is a really ideal project for that because it's a simple architecture,  very few objects, and it would be really good practice if you want that practice for this.  That's my presentation.  Thank you very much.  APPLAUSE  It takes us about 10 minutes of question and answers if you want.  So you have all the freedom to show it.  Yes.  We have been integrating with several ways to get a location.  Are there other ways in mind on your roadmap to integrate as well?  Not really.  I would like to improve.  The question was that if we have other sources in mind for GeoClue for getting location.  No.  The thing is that the app I mentioned, the GPS Share,  that doesn't support all devices yet.  I didn't get enough time to work on that and improve on that.  So if you want to or someone else wants to help on that, that would be awesome.  Yeah, that's my main thing.  Another source could be the GPS sharing app for Android.  It's only for Android.  There is no support for Apple for what is it called, iPhone.  So if someone can add that, that would be cool too.  Anybody else?  Yes, please.  Similar question from another angle.  We are having to use them all GPS.  What about including all the other sources like Galileo for instance?  No.  The question was what about Galileo, most more or less.  But when we say GPS, it's not just GPS.  It's all the satellites, all the networks.  We want them all.  And...  Yeah, GNSS.  Yeah.  And actually they were purchased to GPS Share for fixing that.  Like I was assuming in the strings that it starts with a GP, which is for GPS.  But someone fixed that, I think.  So it supports all those.  More.  No.  For real sake, goodbye to you.  Is there anybody, because we have five, six minutes left, that wants to do a lightning talk.  In the previous sort of surplus time slots, there was always somebody who wanted to do a little blurb in front of us.  And he got a standing applause almost, just because he dared, or she dared.  Is there a she that wants to stand up and do something?  Come on.  Did you want something from the crowd?  No?  You're just here to consume.  Well, thank you very much.  APPLAUSE
Open_Source_Geolocation_The_story_and_challenges_ahead_fWW5D8iAsT4_0_179.png Open_Source_Geolocation_The_story_and_challenges_ahead_fWW5D8iAsT4_180_227.png Open_Source_Geolocation_The_story_and_challenges_ahead_fWW5D8iAsT4_228_371.png Open_Source_Geolocation_The_story_and_challenges_ahead_fWW5D8iAsT4_372_671.png Open_Source_Geolocation_The_story_and_challenges_ahead_fWW5D8iAsT4_672_1439.png Open_Source_Geolocation_The_story_and_challenges_ahead_fWW5D8iAsT4_1440_2027.png Open_Source_Geolocation_The_story_and_challenges_ahead_fWW5D8iAsT4_2028_2399.png Open_Source_Geolocation_The_story_and_challenges_ahead_fWW5D8iAsT4_2400_2483.png Open_Source_Geolocation_The_story_and_challenges_ahead_fWW5D8iAsT4_2484_2723.png Open_Source_Geolocation_The_story_and_challenges_ahead_fWW5D8iAsT4_2724_3023.png Open_Source_Geolocation_The_story_and_challenges_ahead_fWW5D8iAsT4_3024_3443.png Open_Source_Geolocation_The_story_and_challenges_ahead_fWW5D8iAsT4_3444_3767.png Open_Source_Geolocation_The_story_and_challenges_ahead_fWW5D8iAsT4_3768_9275.png Open_Source_Geolocation_The_story_and_challenges_ahead_fWW5D8iAsT4_9276_10391.png Open_Source_Geolocation_The_story_and_challenges_ahead_fWW5D8iAsT4_10392_11399.png Open_Source_Geolocation_The_story_and_challenges_ahead_fWW5D8iAsT4_11400_13055.png Open_Source_Geolocation_The_story_and_challenges_ahead_fWW5D8iAsT4_13056_14039.png Open_Source_Geolocation_The_story_and_challenges_ahead_fWW5D8iAsT4_14040_17015.png Open_Source_Geolocation_The_story_and_challenges_ahead_fWW5D8iAsT4_17016_17375.png Open_Source_Geolocation_The_story_and_challenges_ahead_fWW5D8iAsT4_17376_23951.png Open_Source_Geolocation_The_story_and_challenges_ahead_fWW5D8iAsT4_23952_25379.png Open_Source_Geolocation_The_story_and_challenges_ahead_fWW5D8iAsT4_25380_31271.png Open_Source_Geolocation_The_story_and_challenges_ahead_fWW5D8iAsT4_31272_31871.png Open_Source_Geolocation_The_story_and_challenges_ahead_fWW5D8iAsT4_31872_32159.png Open_Source_Geolocation_The_story_and_challenges_ahead_fWW5D8iAsT4_32160_33179.png Open_Source_Geolocation_The_story_and_challenges_ahead_fWW5D8iAsT4_33180_33299.png Open_Source_Geolocation_The_story_and_challenges_ahead_fWW5D8iAsT4_33300_33551.png Open_Source_Geolocation_The_story_and_challenges_ahead_fWW5D8iAsT4_33552_33671.png Open_Source_Geolocation_The_story_and_challenges_ahead_fWW5D8iAsT4_33672_34055.png Open_Source_Geolocation_The_story_and_challenges_ahead_fWW5D8iAsT4_34056_34175.png Open_Source_Geolocation_The_story_and_challenges_ahead_fWW5D8iAsT4_34176_34331.png Open_Source_Geolocation_The_story_and_challenges_ahead_fWW5D8iAsT4_34332_34379.png Open_Source_Geolocation_The_story_and_challenges_ahead_fWW5D8iAsT4_34380_35279.png Open_Source_Geolocation_The_story_and_challenges_ahead_fWW5D8iAsT4_35280_35591.png Open_Source_Geolocation_The_story_and_challenges_ahead_fWW5D8iAsT4_35592_35855.png Open_Source_Geolocation_The_story_and_challenges_ahead_fWW5D8iAsT4_35856_36611.png Open_Source_Geolocation_The_story_and_challenges_ahead_fWW5D8iAsT4_36612_37235.png Open_Source_Geolocation_The_story_and_challenges_ahead_fWW5D8iAsT4_37236_37283.png Open_Source_Geolocation_The_story_and_challenges_ahead_fWW5D8iAsT4_37284_37355.png Open_Source_Geolocation_The_story_and_challenges_ahead_fWW5D8iAsT4_37356_37499.png
Hello, can you hear me? Well, I was going to say already start from who I am. So, my name is Sishan Ali. I had to check to make sure. I work for this company called IBM, I'm sorry, Red Hat. And it's been two weeks, but I worked at Red Hat before, five years on desktop team. I've been trying to get back for a while and now I finally made it back, but not in the desktop team, but in another team, containers, related stuff. So, new stuff for me to learn and stuff. Should I start with the actual? Yes. Okay, cool. And I've been involved in FOSS in different companies and different levels and stuff. Mostly GNOME stuff, but other things as well, like G-Streamer and related stuff mostly. I went to flying, I have a helicopter license working on my plane license, and I like cats. And the story I'm going to tell you is a very small, boring one, but maybe some interesting, somewhat. I started in 2007 and it sounds like a Spanish conspiracy because these two guys, this guy and this guy, they were both sitting together somewhere with some people from Garmin and they said, oh, what about we have geolocation service for Linux because there is nothing like that right now. And since D-Bus is the way to go nowadays, so it would be using D-Bus. So, they decided to create a project called Geoclue, which is a D-Bus-based geolocation service. The concept is very simple. The application asks this service like where I am right now, and the service just tells them that. And they found a victim, I mean, a summer of course student to do the actual work. And this guy did all the hard work and he made it possible, the Geoclue. And the concept was based on external providers. So, each source of location was an external source. So, within the system, the service itself, there was nothing. It was only an API for applications to talk to and for service providers to hook into the service. So, they can tell it where the location and give it updates about location and stuff. And the easiest one in any kind of application like geolocation, you can implement as GeoIP, which is the simplest one because any service out there can see your external IP and tell what it thinks where it is. And there is a database already out there. MaxMind is a company that maintains it, and they have like a commercial version of that database, and there is a free version of that database. There is not a lot of difference between them actually in practice, but there is some. So, yeah, based on that, they implemented GeoIP provider. They also kind of provided a Wi-Fi geolocation, but they couldn't really because the only ones were proprietary and they couldn't use it in open-source software. So, they kind of created a source that you can manually tell it like, okay, these Wi-Fis, if you see these, then it means I'm on this location. So, a user had to manually do that, and that's not really, you know, it doesn't work out of the box. So, I don't think anyone actually used that. I'd be surprised if they did. And one of the things that is essential is support for GPS devices. So, they created another person, came along, and he was interested in GPS support in GeoCLU, and implemented Gypsy Ian Holmes as his name. But there was already a project called GPS-D. It's maintained by Ira Kremer, I think. And the reason they didn't take that was it had a very, very conservative architecture. They wanted everything to be allocated on the stack, and it created many other problems. It increased memory usage and stuff like that. And they had a very archaic IPC mechanism. They didn't want to use D-Bus at all, and they were afraid of that. They said it doesn't work and stuff. Anyway, so there was a bit of a clash, and they both have written really long blog posts explaining why they did what they did, like why Gypsy and why GPS-D still. Anyway, so, and then since some of the Garmin people were involved in the creation of GeoCLU, they used it in their devices, as far as I know, and also in many MIMO and MIGO devices, GeoCLU was used. It still is being used in YOLA devices, if you know that one. So, yeah. But over time, the dreams were forgotten. People got busy with other things. GeoCLU was un-maintained for years. Gypsy was un-maintained for even longer. The guy who wrote GeoCLU, Yusie Kukar, and he's a good friend, and I still meet him, and he's still involved in open source. But the guy who wrote Gypsy, he has vanished, I think, I haven't seen him for 15 years or something. And then in 2013, when I was still in desktop group of the Red Hat, I was bored. I have been doing the same application for three years continuously, which is GNOME Boxes, and I want to do something different. So I was like, what should I do? And talk to this guy, he's involved in all parts of GNOME, at least, and free desktop software. And he was kind of involved in GeoCLU development at some point. So he had some ideas about creating a new GeoCLU, which, because the old GeoCLU was getting really old, the source code was not really nicely written in the end, and also it was using a lot of libraries and APIs that were not really maintained, those APIs are not there anymore. So instead of revising that old software, and also the architecture is like the external providers I mentioned. So it sounded like a really good idea on paper, but practically it's not such a good idea because many people created their own providers, and they use them in their own devices, but they never contributed upstream. So the upstream GeoCLU you take on your desktop machines, they only have GUIP, and it's not very useful at all. So because of that, we created GeoCLU 2 with Bastia Nocera. And the idea was much simpler architecture, which is not just good for developers, but also for application developers, and for anyone who uses it. For example, we only have internal sources, we don't have external source. There is one exception to that, I'll tell later, but ideally all sources belong in our code. And if you want to add some source, please come and contribute that. And also GeoCLU usually used to provide, GeoCLU 1 used to provide Geocoding service, Geocoding API. And we thought that doesn't really belong there, it should be a separate service. People should be able to use that separately from Geolocation. So that code was put into a separate library called GeocodeGLIB. And another reason for redesigning GeoCLU 2 was privacy, because GeoCLU 1 had no concept of privacy, it would just give the location to any application that asked it. But you know, location is like a very sensitive piece of information, so if any application can get it, it could be a really bad application that wants it. You downloaded some random application off the internet and takes your location and gives it to someone. So the idea was having an app authorizing agent, and that has to be external. And the first OS that was added to was GNOME, because I was working on GNOME stuff, so it was natural for me to add it to that at least myself. So currently if you use some application right now that does location, for example GNOME Maps or something, you will get a dialogue and then it saves that permission from you in a database and stuff. And similarly, elementary, I think one year ago or two years ago, they also added an app authorizing agent for GeoCLU. As for the sources, the first source of course, as I mentioned, the easiest one is GUIP. So we added that as first thing. And Modems was another kind of easy thing, because there's already two back ends for managing Modems. One is Modem Manager, the other one is Ophono. Modem Manager is the one being used on GNOME and stuff, so I use that. I actually have a blog post about that, why Modem Manager is much better than Ophono. But I'm nothing against people adding Ophono, but we have Modem Manager support already. And it does support two things. One is cell tower based location, which is not very accurate. It's a few kilometers at best. And the GPS, which most Modems nowadays, they come with a GPS on it. So we get a GPS location, which is a lot more accurate, of course. But the problem is that not everyone has a Modem and a lot of laptops, even if you have a Modem, many corporates just disable it because nobody, this thing nobody uses. And when you're stuck with GIP, the GIP at best can give you city level location, and that's not good. Sometimes that's even very wrong, and people get really frustrated. So we need something more accurate that is more abundant, which can be used on many most laptops and stuff. And that's Wi-Fi based geolocation. The concept is simple. You see which Wi-Fi network you see. You get a list of that, the strands, and then you send it to server, and server tells you, OK, these devices are in this particular street. So you get a street level accuracy, which is really good already. But the problem was how do we do that? Where's the server? Which server we can use? We can't use Google servers. You can't use Microsoft's or Apple's or whatever. The one we could use was Yahoo's, which was there for a bit that you can use in open source software. But there was some limits to the data rate and all that. So it wasn't ideal, but we had to use something, right? But then, soon after I started Geoclue 2, Mozilla came out with their own service, which is called Mozilla Location Service, and that does the Wi-Fi based geolocation. And they utilized their vast number of users around the world to gather all the data about Wi-Fi. So within months, they had a huge, huge amount of data from across the world. And it was completely open. So it's open source. Data is not open for privacy reasons, exactly. But that's a completely different topic for another talk. But we can talk about it afterwards if you want. But anyway, it was a really good send. We used that service immediately. And we were one of the first users, external users of that service. But as I mentioned, laptops have Wi-Fi, so you can use it. But most desktop machines do not have Wi-Fi. So what about them? Are they stuck with GUIP? More or less, yes. But we came up with a solution for that. A summer, of course, student implemented this. So the idea is that you share from your phone, all the phones nowadays, the smartphones have GPS devices nowadays. So you share your GPS location on your network, on your Wi-Fi network, or your internal network. And then anyone can use it, any software. And as a part of his project, he, of course, added support in GeoClu. So there's an application called GeoCluShare, which you can install on your Android device. And you get the Android device location on your desktop or laptop or whichever device you want. So that was a kind of workaround for desktop machines. But that's the best we could do. There's no other way. And it uses a Wi to tell, announce its location on network. What about standalone GPS devices? As I said, modems have GPS, but not like, that's not the only place for GPS. There's standalone ones that you can plug into USB usually, or Bluetooth. How about them? The problem with those is that they usually need some kind of configuration. They don't work out at the box, at least right now. There's a new Linux subsystem coming. I've heard that we'll solve this problem, at least for many devices, modern devices. But I don't know if it will solve for all devices. So you need to set bot rate and stuff like that on the serial port that it exposes on. So since it needs an external means, we thought, OK, what about Gipsy? We can use that. But that has been maintained for much, much longer, unmaintained for much longer than GeoClue. The guy who wrote it, he's nowhere to be found. Yeah, source code is not that great. And yeah, so we thought like, and it's written in C, and I've been more into Rust these days. So I decided to just write a new one, GPS share, it's called. And another reason to rewrite that is that it's not a Diva service, but it works the same as the GeoClue share I mentioned, the app. So it just exposes your network on the local network if you wanted to. And since GeoClue already had the support for NME over TCP, so it could readily use this software that I wrote in Rust. So that's on GitHub, and you can use that for standalone devices. And of course, from day one, we had GNOME integration because I was interested in that in GNOME. Maps, actually, this is a GNOME maps as a software I started. Nowadays, another person is that guy is maintaining it. And this one I mentioned is a Finnish conspiracy, and the maps is more a Swedish one because always a maintainer is a Swedish guy. And, yeah, anyway. And of course, one of the cool features we wanted to have with GeoLocation was automatic time zone update. So many devices have implemented there so long ago, but we never had this. So it was really cool to have it in GNOME. And of course, clocks and weather needs location as well. Webkit GTK for different web pages. And, yeah, so those were the apps. And more recently, we had some positive development as well. Like, Free Desktop created the GitLab instance, and I think now it's the only GitLab. And GeoClue was one of the first ones to move. I said to Daniel, like, yeah, I want to be the first one to move there. And it was like immediately positive effect because it makes things so simpler and easier. And also, all of a sudden, there were many contributors to GeoClue, not just in terms of issue reporting, but also patches were being submitted before there was rarely any external people other than me giving patches. But now there's a lot of people, well, enough people, more than before. Another change was Flatpak. So I mentioned about privacy. At that time, Flatpak wasn't there. There was a concept of that. There was some development, but it wasn't really there. What is Flatpak? It's an app bundling solution. So you put all your app with all its dependencies in one bundle, and then you can distribute it for all the distributions. You don't have to package it for distribution distributions. And also, one of the core concepts is sandboxing. So first, they were focused on bundling, but nowadays they are focusing on sandboxing as well. And when it comes to sandboxing an app, you don't want the app to access system bus at all. And GeoClue is on system bus for many reasons. So I talked to the person, Mathias Klassen, who is working on the sandboxing solutions. They are called portals. The portals are a way for app to get to system without actually directly having access to the system, the whole system. So it's much more secure. And he wanted to do a geolocation portal, but since we already have a privacy story, we had to remove some of that code. And now, hopefully, we will eventually remove all of our privacy stuff in favor of the Flatpak geolocation portal. And Flatpak will handle all your apps. We'll talk to Flatpak's portal, and that will talk to GeoClue for us for you. So it will be more secure that way. But we have challenges ahead. Mozilla Location Service, when it was announced, Mozilla was still doing devices. They were into mobile stuff, and that was their main use case for it. But they haven't been into that for two years, at least now. They are really nice people, so they are keeping it up. The service is still there. We can still use it. And I think you can also contribute back to it, like with their Android app. But how long would it be there? Nobody knows. So there is this uncertainty about the service. And the service is extremely important for free desktop right now. Because if you can't get your location, all these apps, they are not very useful. And especially, there is something like automatic times on update. Once you get used to that, you're kind of expecting it to always work, right? So it would be a pity if we can't locate you anymore all of a sudden. And we have only your city-level location at best. So I would be interested in hearing about if anyone has any suggestion on how to fix this problem. The code is open source. It can be moved somewhere else. It can be hosted by somewhere else, the same service. So if anyone has any ideas, let me know. You want more platforms. A lot of embedded devices, they took GeoClue 1, and they are still using that one. And that source code is not even there anymore. It's not just unmaintained. It's just not there, the source code upstream. So it's a maintenance burden. So I think they really should all move to GeoClue 2. Of course, it's a bit of a task because the API is different, architecture is different. But I think it's worth it to do that effort. And it's been a while. It's been like four years, three, four years that GeoClue 2 came out. So it's time. Now we need more developers. As I mentioned with GitLab, I saw more contribution coming in, a lot more than before. But I would like some more developers to actually start actively working on it. There we have many different tasks to still fix in GeoClue. So I work. If you want to work on something cool, please consider this project. Also, as I mentioned before Rust, so I really don't believe that any new source code should be written in C and C++ at least. I understand existing source code, especially large code base, remaining in C and C++ because it's a lot of work to port to Rust. So that's understandable. But this GeoClue score is not that big. And it could be done if I count in Mondays like a month at best, if I do work on it full-time. But that's like the worst-case scenario. I'm hoping maybe it will be a summer of code project, but we will see. But if anyone else wants to help me with that, it would be awesome. And it will go much, much faster, much easier. And if you want to have some kind of practice of Rust and or porting to Rust from C, this is a really ideal project for that because it's a simple architecture, very few objects, and it would be really good practice if you want that practice for this. That's my presentation. Thank you very much. APPLAUSE It takes us about 10 minutes of question and answers if you want. So you have all the freedom to show it. Yes. We have been integrating with several ways to get a location. Are there other ways in mind on your roadmap to integrate as well? Not really. I would like to improve. The question was that if we have other sources in mind for GeoClue for getting location. No. The thing is that the app I mentioned, the GPS Share, that doesn't support all devices yet. I didn't get enough time to work on that and improve on that. So if you want to or someone else wants to help on that, that would be awesome. Yeah, that's my main thing. Another source could be the GPS sharing app for Android. It's only for Android. There is no support for Apple for what is it called, iPhone. So if someone can add that, that would be cool too. Anybody else? Yes, please. Similar question from another angle. We are having to use them all GPS. What about including all the other sources like Galileo for instance? No. The question was what about Galileo, most more or less. But when we say GPS, it's not just GPS. It's all the satellites, all the networks. We want them all. And... Yeah, GNSS. Yeah. And actually they were purchased to GPS Share for fixing that. Like I was assuming in the strings that it starts with a GP, which is for GPS. But someone fixed that, I think. So it supports all those. More. No. For real sake, goodbye to you. Is there anybody, because we have five, six minutes left, that wants to do a lightning talk. In the previous sort of surplus time slots, there was always somebody who wanted to do a little blurb in front of us. And he got a standing applause almost, just because he dared, or she dared. Is there a she that wants to stand up and do something? Come on. Did you want something from the crowd? No? You're just here to consume. Well, thank you very much. APPLAUSE
geolocation service for Linux because there is possible, the Geoclue. And the concept was based was only an API for applications to talk to and between them actually in practice, but there is good for developers, but also for application GeoCLU usually used to provide, GeoCLU 1 used to location to any application that asked it. But was completely open. So it's open source. Data is knows. So there is this uncertainty about the will be a summer of code project, but we will that because it's a simple architecture, very few