(Or why our project’s name wasn’t wrong after all)
First and foremost, because the Internet isn’t available everywhere all the times. To put it simple: 3G (and 4G) suck. The latency is a joke in even the most modern countries, even at the center of their capital cities. Reliable availability of The Internet simply doesn’t exist for most people. Not even after a decade of promises and billion dollar investments from advertising firms like Google. Balloons that bring The Internet everywhere? Yeah, sure.
I invite you to try a serious Google maps use-case in a Swiss tunnel. The kind of use-case the nineties Microsoft Automap Streets & Tips – like software easily managed for planning vacations and trips across Europe decades ago (without The Internet). Or how about reading the newspapers on the airplane? Technology of pre the year 1700 could do it. Today Google’s tablets & glasses can’t, because I have no reliable Internet (the flight-attendant will reliably give me a newspaper, though – go ahead, try it Sergey). And if Google installed 3G routers in those tunnels, airplanes, forests, all third world countries, seas and the truly remote areas of the planet , I could still come up with a lot more places. Everybody can. By the time the Googles of today are finished, we’ll all travel to Mars with latencies of up to an hour while Google’s data still only travels at the speed of light (that, or fix quantum entanglement to be workable and more importantly: scalable to billions of users).
It’s great that sometimes we can use Google maps, sure. But if I can’t rely on it always and everywhere, it means that in embedded: it doesn’t exist. I want my Boeing 747’s landing software to work (oh and when we land on Mars, too). Always. I want software to land us safely. Same for my car’s ABS, the subway and train’s breaking systems. I’ll probably be dead when those services don’t operate when I need them. During those moments I don’t care about Google fans and their Google HTML5 religion. Screw HTML5, JavaScript, WebSocket and 3G and thank you interrupt based real time kernels that open my airbag, stop the tram and land the airplane.
For the car industry it’s probably cheaper to provide a storage hardware upgrade when the car must be serviced, than it would be to sell your company’s soul to privacy invading Cloud hosting services. Because in future I would like you to provide Facebook-like services in my car, as reliable as my airbag works. Without the Internet being everywhere. I want you to deliver it to me when I’m visiting Mars. And my kids … who knows what they’ll want?!
Your embedded technology needs to provide graph data about the users’ activity to services that your business wants to share the data with. I’ll illustrate this with This-is-Possible-Today use cases:
– The fridge contains no more milk. While walking the street watching his smartphone, the user opens a recipe for a meal that requires milk. When the user is at the supermarket the technology that will in future be installed on supermarket shopping carts (or his glasses) needs to show the recipe, its ingredients and highlight the fact that the fridge doesn’t contain one of the required ingredients (milk, sugar, butter). And if the user allows this, advertise different brands of milk, sugar and butter based on who paid most plus his wife’s buying habits.
– Your kid talked with a school friend on Facebook about an amusement park (De Efteling! Phantasialand!). Your wife decides that because it’s good weather this weekend, the family should (will) go to an amusement park (yes, she’s the boss. And that’s fine: you own the car – don’t worry, she’ll drive the way back so you can have your weekend nap). So the entire family gets in the (your) car and you ask your son: what amusement park shall I drive to?! Your kid opens the infotainment system at the back seat of the car and sees what he has been interested in last few weeks. After privacy authorization (or not) you as the driver of the car sees the list on the dashboard infotainment system. You select it and the navigation software of the (your) car navigates to it. What a dad! Meanwhile your front passenger seat’s infotainment system goes to the ticket ordering website of the amusement park. What a mom! Advertising related to amusement parks and ticket vending is shown. Of course! Phantasialand!
That is why you need Tracker’s Nepomuk based storage with its SPARQL querying and updating capability.
It lets your embedded appliance do what Facebook does. But in a light way, isolated (or not) from the rest of the world. You decide what happens with the data and who receives it. Allowing you to provide a trust relationship with your customers and consumers. You are the industry providing those cars, fridges and TV sets.
As a BMW driver myself, I would stop buying BMW cars as soon as I learn that BMW sells my driving habits (or whatever) to Google or Facebook (or the NSA). Today I’d trust BMW to integrate those habits into the infotainment system of my next car. IF I can trust BMW. I think that in future it’ll be the difference between succeeding and failing as a industry.
With Tracker you get the use-cases and features. But it’s not for free: you must hire brains instead of paying Google or Facebook’s marketing boys. This comes as a surprise? It has always been that way in tech: Brains and hard work, innovate. Ask Wernher von Braun. They landed on the wrong planet, but in the sixties and seventies his rockets got us to the moon.
A car is a car. A fridge is a fridge. A TV set is a TV set. They shouldn’t be Google’s or Facebook’s data mining devices. Besides, why would you give the data away? Your appliances collected it, not theirs. Talk with your customers fairly and openly on how it can and how it can’t be used.
As managers at these industries it’s up to you to solve the crisis of social features vs. privacy mining.
Kind regards, from one of the guys who developed such technology for Nokia’s N9.
“Or how about reading the newspapers on the airplane? Technology of pre the year 1700 could do it.”
I’m *pretty* sure pre-1700 technology did not include airplanes.
Fair enough :), I put the blame on rhetorics.
Couldn’t agree more. Maybe you can convince the other GNOME devs about making sure new apps perform this way? It would be great if we had great offline mapping software, like the new GNOME maps. It’s not clear on whether they’ll allow this or if you’ll need an internet connection or not.
The N900 let you download a 20GiB+ archive of however many countries you wanted offline data for your phone. Hopefully GNOME will let you do this too!
The problem with these “download whatever” services are that they are utter crap compared to Google Maps. Google Maps has a completion dropdown on the whole freaking world update in realtime, working with streets, businesses and places of interest. Google Maps also gives me a trip from Paris to Moscow in 3 or so seconds. I’d like to see you do that on my phone – or even my desktop PC – with a 20GB dataset.
This whole latency part of that tirade about internet latency is made up easily by hard drive and CPU latency of my local device.
Not that I do mind having offline capabilities, but online always trumps offline, even when the online is some stupid mobile data plan.
I don’t disagree that goole doesn’t provide a more featureful service. The fact that GNOME maps/Free Software alternatives aren’t as good is a BUG, and also due to the fact that they have a lot more money and developers. The advantage we have is that there are a lot of great resources for us to use to play catchup, and we’ll ultimately have a better service by giving the user full offline, decentralized functionality. That’s a HUGE feature as Mr. Vanhoof explains in his article.
I disagree about the “phones not being capable enough”. The mobile car “garmin” style devices were/are fully able and functional. Other phones are able too, and they’re getting more powerful every day. If I want to get from Paris to Moscow, I’m happy waiting 5 extra seconds for the results. For a short trip around town, it can probably optimize the database to have faster results for local searches.
Online doesn’t trump offline in a huge set of use-cases. Even when Internet is available I wouldn’t want my building’s elevator software to depend on a website. While using it I might want an infotainment system that interactively shows me a map of the building, though. But no idea why it would need to show Google Maps’ whole freaking world in realtime if I can quickly give it a clue what I’m interested in, in a trustworthy way.
When taking the lift from a underground car parking in the city, its infotainment system only needs to show me info, related to my interests, about the surrounding city area. Not about the rest of the world. Sure it could integrate with Google Maps for that. It doesn’t have to and that way the parking owner has more control over what info will be and what info wont be shown on the map.
I also don’t think infotainment systems need our full identity and online tracking to relate the information they show to what we are interested it realtime: My smartphone can upload a anonymous cookie with the i-am-interested-in information when I arrive to the system. I could turn it off and/or thwart cookie-tracking systems just like DoNotTrackMe does today in our browsers. This is better than face recognition IDing me everywhere for the purpose of ‘informing me better’: The cookie implementation puts the control in my hands and a European-wide law could forbid businesses to ID us using facial recognition or other means. Being forbidden doesn’t mean it does’t happen, but it does mean it won’t be everywhere (and that you’ll be out of business if your profits depend on it – whereas they wont forbid me giving the info to you).
Some of this is what goes through my head when I see programmers write articles about how great it is that they’ve replaced their laptop with a chromebook or tablet, and just log into another machine remotely to get work done.
Or try Recoll, which actually works and provides real functionality. Tracker is a hopeless mess.
Recoll is only for indexing files and doing things like full text search. It can’t do multi domain graphs and relationships. It’s great for desktop search that finds based on the contents of your documents. It’s not great to build applications that work with the relationship context of more than just things that fit into files. Like contacts, events, places of interest, routes, todo and calendar items and relationships themselves. Or even to build applications that work with relationships between files (which exists, and goes much further than just using folders – also why GMail uses tags for E-mail instead of folders). Recoll might be great for replacing Tracker’s filesystem miner someday, perhaps. But its graph is a flat one. And that’s not how the world of things and more importantly relationships between those things is organised. Note that we could probably write a recoll:match() function for Tracker’s SPARQL endpoint just like how we have fts:match() today for our own SQLite fts3 support. Wouldn’t be super hard and a nice integration of both platforms, I would say.
Note that such a match, for us, is just one kind of relationship with the thing. Namely ‘it contains’ or LIKE on nie:plainTextContent. But what about ‘who gave it to me’, ‘who made it and who are his friends’, ‘who’s tagged to be on it and who are his friends’, ‘where was I when I first saw it’, ‘who else was it sent to besides me and what did they sent me earlier’, ‘where did i got it from’, ‘what was i doing and when’, etc? These are all possible queries with Tracker’s Nepomuk + SPARQL (when the data is correctly provided by miners).
I’m not sure why Tracker is a hopeless mess. It works pretty well on the N9. Millions of those phones run it today and silently in the background Tracker provides and stores data for nearly all of the Harmattan MeeGo standard applications on the phone. Messy software doesn’t do that silently.
What version of SPARQL does Tracker support? Sparql 1.1 has very useful extentions such as subqueries, aggregation, custom functions and variable binding.
We support most of 1.1, including all features you just mentioned
All this is good, when applied correctly. Tracker stores metadata that can get out of sync with the data stored in the file system, e.g. bogus picture links etc. This means there should be a proper sync / metadata regeneration mechanism. Or, Tracker could be an option built into the file system.
Then, applications and the user should be able to control what (meta)data ends up being stored in Tracker, who owns it, who can see and transmit it etc. It is a privacy nightmare. AFAIK this does not have a good solution so far.
Brains and hard work …
Your advertising of the tracker technology would be a lot more convincing if you could paint a vision of the future that wouldn’t be so horribly sexist. But I’m pretty sure I don’t want to model my family life (and therefore my professional one) after what you wrote here.
Sure, as long as dad gets his weekend nap, you can have all the geekfeminism you want. That and whatever.