At Google’s offices in Mountain View, California, KDE 4.0’s release event has ended. Various KDE people have given presentations, and a set of them has been posted online. Among them is Aaron Seigo’s keynote presentation, which is very interesting to watch, and gives you a very good idea of what the KDE project is trying to achieve with KDE 4 (I just finished watching). Other presentations have also been put online.
Dude the guy(the second one) in that video looks exactly like Pitrelli(the young one) from the show “Heroes”!!!
If anyone watches the show please see that video.
That would be Aaron Seigo. Its funny that you mention ‘Heroes’, I couldn’t put my finger on it.
Aaron, I guess you can add it to the list of who you “look like”.
Funny. He seems to have changed his look. Before, when he had a bit of fuzz on his face, a lot of people thought he was Tom Green.
Yup, I thought exactly the same.
PS: Aaron, don’t mind the comments about a bad hair cut, some actually do like it, it’s refreshing in the typically clich~A(c) nerdy world of computing.
Aaron Siego looks more like Tom Green
I think was good, I actually learned a few things from it as I was watching it from KDE 4.0. Love the present windows where you can type the name of the window you want and the desktop wallpaper download search.
It may not have all the functionality yet like KDE 3.x has but I can sure see the potential, KDE 4.0 IS rather fresh. Needs alot of work though, konqueror, plasma crashes out on me but I’m using it part time at the moment so it’s not so bad.
I’m looking forward trying out KDE 4.0 and 4.1
There a lot of info from the presentation. Its good to see they are making a stable base.
There a lot of info from the presentation. Its good to see they are making a stable base.
I like the work they’ve put into all those frameworks. For example the VOIP framework: you can develop a dozen different frontends to it and every time it gets a bugfix or something all those apps utilizing it will benefit. I like GNOME but I am starting to get the feeling that GNOME is getting left a bit behind.
There are similar projects underway in the gnome camp (a look at gnomefiles.org shows them). I think the underlying frameworks/libraries will actually be the same. This isn’t new stuff – both “camps” have been working on this underlying technology stuff for quite some time.
They certainly do have similar projects, but the problem is making good use of them throughout the desktop in a way that is not onerous for developers. At about twenty minutes into that main video, Aaron talks about Akonadi and how within a few lines of code they could integrate with Plasma and make your contacts, e-mail and other PIM data available to various applets for display and retrieval. This is not application specific. I don’t really know of any other desktop environment that is working towards this, and Microsoft didn’t take Windows Mail any further in Vista because they were clearly afraid it would stop you from buying into Outlook and Exchange ;-).
Something called Dashboard was written for Gnome a few years ago, which was able to do an apparently similar thing. Unfortunately, the data that was pulled into this was very much application specific. Evolution for mail and contacts and GAIM (Pidgin) for instant messaging, and there was no real way of making this data flexible beyond those domains. There was no way of adding in other forms of information for display in an easy way either. From that presentation, it becomes pretty clear that that is where KDE is different.
Decibel is basically KDE’s implementation of the freedesktop.org Telepathy specification and GNOME has their own implementation as well, so components of either implementation can be combined.
Work on the GNOME implementation is mainly done by the people at Collabra.
See also http://live.gnome.org/Empathy
Decibel is basically KDE’s implementation of the freedesktop.org Telepathy specification and GNOME has their own implementation as well, so components of either implementation can be combined.
Well, okay
Maybe the KDE folks just have been better at trumpeting their implementations then? 
I don’t think its just Gnome that is getting behind, I think this is the case for most other desktop environments as well. Watch out Microsoft and Apple.
Gnome still holds the advantage when it comes to usability, but KDE 4 rules on the framework side. The fact that applications easily can be ported to various platforms including windows is a winning feature.
As pointed out in the presentation, this could be a way to break the Microsoft Outlook/Exchange lock in situation.
I hope that Gnome manages to do something similar, or even better reuse the excellent work done in KDE 4.
One area where KDE as a software project and developer community still needs to become better in is making the scope of parts of their work more explicitly visible.
For example if we look at KDE2 or KDE3 technology like DCOP or KIO, there are misconceptions about them being KDE specific things, i.e. somehow depend on KDE in the sense of linker requirements.
Both examples above are centered around the concept of communicating processes, where the actual interoperability constrains are in the respective protocol and where the implementation details of one side are shielded from them implementation details of the other.
It will be intersting to see if the KDE developers will manage to make this base requirements more visible and also if non-associated developers will be able understand this separation sufficiently to not turn away working solutions just because someone associated with KDE created it.
I’m not entirely sure what you mean there or what could be done differently. Arts was adopted basically because it wasn’t KDE specific at all (DCOP and KIO are really), and other desktop environments could come in and use it, and what happened?
Well, that’s more an issue for other people. As far as I can see, KDE’s developers have been really open to DBus, as they moved to it, there’s an event loop to hook into Glib and various other things to make interoperability better that have nothing to do with KDE and weren’t developed by KDE people.
Many people have various non-KDE dependencies installed on their system, and no one really cares as long as things work well. However, I have seen more than one bug report where the basic premise is that all Qt and kdelibs dependencies should be kept off the system. Why don’t you start with them?
I meant that software developed by KDE developers is often assumed to be KDE specific whlile in fact it isn’t. aRts is a pretty good example.
It wasn’t adopted despite not being KDE specific, but probably other developers thought it is.
No, good examples of really entrenched misconceptions.
KDE’s implementations of the two system of course are KDE specific, i.e. depend on Qt and KDE code, but since both technologies operate by communication of process through a protocol over Unix domain sockets, there is not tranfer of dependencies from one side of the communication to the other, similar to how it is possible for a D-Bus service to be implemented using one software stack and any client being implemented in any other.
D-Bus is a really promising incumbator for solutions to this problem, because it makes it more obvious that client and server implementation are in fact independent from each other.
GNOME’s problem is not the today – GNOME as it is works fine, and I enjoy using it. It works, looks very pleasing (on my eyes at least, after a bit of work), and is updated regularly with interesting new tidbits and bugfixes.
It’s the future where GNOME’s big problem lies. They have NO plan for the future – that I could live with, if it were not for the fact that GNOME lacks something else: a vision. Where does it want to go, where does it want to be, what does it want to do, what does it want to offer that other environments cannot offer.
KDE 3.5 worked fine the way it was. It may not float everyone’s boat (just like GNOME doesn’t float everyone’s boat) but for those it did float their boat for (still with me?) it worked just mighty fine. Mature, stable, configurable, great development tools. Still, the KDE guys were smart enough to realise that this would not be the case forever. Expectations change, competition changes, and you need to adapt – or die. Or, as the KDE guys put it, you keep hitting the big friggin’ wall. Incremental updates wil get you near the wall – but not over it.
So, the KDE guys took the bold step, and decided to put into words (and later code) their vision of what a desktop environment should be like. Early on in the process, they had some communication issues that made KDE 4 kind of look like vapourware, but later on, they improved this and starting talking a whole lot more about it, making their vision clear. And now, despite many bugs and oddities, we have the first signs of their vision in our hands and on our computers, and as I said in my first-look article about KDE 4.0, the potential is just oozing out of every pixel.
And where is GNOME? Well, to speak in KDE terms – still getting near the big friggin’ wall, just like two years ago – assuming that their users and developers will remain pleased with remaining on the current side of the wall, with no plans whatsoever to try and get over the big friggin’ wall – something that requires more than just incremental updates.
At this point in time, the future looks a whole lot brighter for KDE than it does for GNOME. People will cal this flamebait, and I’m fine with that. Unless someone or some people from the GNOME community step up and lead GNOME to a vision that can get them over the big friggin’ wall, I’m fairly sure history will side with me.
Which is sad, since I really like GNOME.
I don’t really have much more to add to your post
GNOME is mighty fine as-is and there are only very few things I find missing. But the KDE base framework just is aiming for the future, not for the present, and GNOME has to follow sooner or later..The good thing is though that still everything keeps rolling and getting better and better over time as the competition from other DEs keeps pushing devs forward 
I agree mostly with what you said, but let’s not forget that ‘rewriting’ was truly risky: each time you rewrite something there’s bugs, loss of feature/polish, performance concern at the beginning.
Apparently KDE dev has managed to make this new set of frameworks, but the ‘turmoil’ phase isn’t finished yet: KDE3.x is more usable than KDE4.0 right now, the question is how long will it take for KDE4.x to be truly superior to KDE3.x?
The stabilisation/polish phase always take more time than anticipated: the joke “it’s 90% finished, let’s make the other 90%” is true, and in the meantime Gnome compete hard with KDE (I’m more a KDE guy myself but let’s face it the number of Gnome-mostly distribution is high).
I wonder for example how well KDE4 would run on an OLPC?
I think KDE 4.1 will already introduce pretty much everything you’d come to expect from the KDE 3.5.x series. And I’ve seen KDE 4.0 run on an EEE pc – it runs PERFECT. Including compositing. I’m gonna get one as soon as the 9″ are out…
Wow Thom, my hats off to you for that post. I might just have to start eating some of my previous words.
Dave
>It’s the future where GNOME’s big problem lies. They have NO plan for the future – that I could live with, if it were not for the fact that GNOME lacks something else: a vision
Helmut Schmidt, an old german politician said: you should go to the doctor if you have visions.
You write a lot of text but at the end you say almost nothing.
You say that GNOME has to reach the other side of the wall. But what is at the other side of the wall? Why GNOME would need a new major version number to reach it?
You say that KDE has realise something and therefore they did KDE4. But the main reason for KDE4 was Qt4. If there wouldn’t be Qt4 than there wouldn’t be KDE4!
I could take your writing much more serious if you would say something more concrete. Why does GNOME need a new major number? What can’t be done in the GNOME2 serie and why? What is the other side of the wall and again why can’t it reached with GNOME2?
An amusing quote, but that’s not the context we’re talking in here. If you don’t look into the future and see where you want to be and how to get there then things are going to be tough for you.
Going back to my previous example in a comment above, Dashboard was something written for Gnome not long ago that allowed you to see e-mails, contacts and messenger related stuff at a glance on the desktop. The problem with that was that it was application specific. Evolution for mail, GAIM for messaging etc. and there was no way for any other applications to get access to it and show you the same consistent information. KDE has that framework, and thus, Vista’s widget thingies, notifications and stuff that extends beyond any given application becomes a whole lot easier.
To build this framework in Gnome without creating a bit of a mess for developers will require a clean break and a consistent API for people to use.
Errrr, no. KDE 4 didn’t move to Qt 4 because it was the next number. KDE 4 moved to Qt 4 because of what could be done with it.
Honestly, I think it would be better if you spent some time watching the presentation.
>Going back to my previous example in a comment above, Dashboard was something written for Gnome not long ago that allowed you to see e-mails, contacts and messenger related stuff at a glance on the desktop. The problem with that was that it was application specific. Evolution for mail, GAIM for messaging etc. and there was no way for any other applications to get access to it and show you the same consistent information.
That’s just arguments why Dasboard might be bad. Why isn’t it possible to create a application independend Dashboard with Gtk2 and GNOME2?
>To build this framework in Gnome without creating a bit of a mess for developers will require a clean break and a consistent API for people to use.
You wouldn’t have to break the API here because you wouldn’t have to change something which already exist but add something new.
>Honestly, I think it would be better if you spent some time watching the presentation.
I have watched the presentation. And i like KDE4 a lot. But things like solid, phono, etc. could be implemented with Gtk2 and GNOME2 too. I don’t see why we need to break the API for existing features and GUI elements to add a new abstraction layer for something. GNOME has already introduced such layers with HAL & Co. in the Gtk2&GNOME2 series without breaking API for the rest of the platform.
>Errrr, no. KDE 4 didn’t move to Qt 4 because it was the next number. KDE 4 moved to Qt 4 because of what could be done with it.
So you say we would also have KDE4 if Trolltech wouldn’t have released Qt4?
Edited 2008-01-21 00:39 UTC
You wouldn’t have to break the API here because you wouldn’t have to change something which already exist but add something new.
You don’t see the whole picture here.. You see, when you create a KDE app it automatically has all the features like KIO etc enabled for it without having to specifically support them. But under GNOME your app must specifically be linked and compiled with support for such . If GNOME was to have such features automatically useable for all GNOME apps then API breakage would most likely not be avoidable.
I have watched the presentation. And i like KDE4 a lot. But things like solid, phono, etc. could be implemented with Gtk2 and GNOME2 too. I don’t see why we need to break the API for existing features and GUI elements to add a new abstraction layer for something. GNOME has already introduced such layers with HAL & Co. in the Gtk2&GNOME2 series without breaking API for the rest of the platform.
Is HAL automatically useable for all GNOME apps without the devs specifically writing code to support HAL? No. Case closed
So you say we would also have KDE4 if Trolltech wouldn’t have released Qt4?
I would think so. Maybe not in the form it is now, but in some other form. And well, KDE4 was not developed BECAUSE of Qt4, it was rather MADE POSSIBLE because of Qt4. Hope this clear the confusion
I don’t know what’s on the other side of the wall. If I did know, I’d be working on it with the GNOME or KDE or whatever team on getting there, now, wouldn’t I?
There are numerous instances in the technology world that involve the big friggin’ wall. Microsoft, early 90s. They realised that they could not keep on building on top of DOS forever. They could get closer to the wall, but not over it. So, they set up a team of really smart people (like Dave Cutler) to think of how to get over that wall, and to see what was beyond that. Nobody, back then, knew what was on the other side of the big friggin’ DOS wall.
Now we do. It’s called Windows NT and powers 90% of the world’s desktop computers, and a whole boatload of servers too.
Apple, mid 90s. They were hitting another big friggin’ wall – the wall of what we would now refer to as the Classic wall. The Apple guys realised that the Classic OS would not be capable of providing them with a solid enough base to continue working on for the future. So, they started working (read: shopping) for something that could – something that could get them over the big friggin’ Classic wall. Did we knew what Apple was cooking up for the other side of the wall?
We do now. It’s called Mac OS X, and people are loving it.
That’s the point. Knowing what’s on the other side of the wall is the job of visionaries, not that of annoying know-it-all editors like me. If I did know, I’d be making money with it. All I do know is that it has been proven time and time again that incremental updates won’t get you anywhere in the long term.
I actually think you’re being hard on yourself here. We’ll use the walking on an incline metaphor for incrementalism here. The problem with incrementalism is always with the cost of the next step. If you envision a person walking in a straight line up a slope you get the picture. The grade of the slope is determined by the quality of the code, and the amount of aggregated changed, additions, hacks, and bugfixes to the code. This leads to the fun problem the for every step forward the slope increases… Also, as coding norm changes, and new tools and techniques become established, the slope automatically increases over time.
I’ve never liked the wall metaphor, because it’s not so much about leaping a barrier as it is about making a lateral, or even slightly backward movement in order to find a new path forward that has a less sheer slope. The problem isn’t a wall, it’s the ever increasing energy expenditure for that next step… This cost might not be exponential, but it can get steep quick.
There’s actually an interesting contrast between the Linux kernel and the GNOME folks here. Linus said he’d keep plucking away at 2.6 until he couldn’t– Scanning Planet GNOME you regularly get to hear the cry: “Inncrementalism forever” (and there’s mutterings of GNOME 3 there as well.). The scary part is that the ‘kernel’ part of the Linux kernel is rather small and has pretty strict code discipline, which favours incrementalism, and GNOME is not…
Edited 2008-01-21 16:40 UTC
When Aaron talked about the different frameworks that abstract away the operating system specifics and allow you to just ask questions like “How many CPUs are available?” or “Tell me when a new device is connected.” without tying your app to a specific OS, I immediately thought “Wow! KDE4 must be a real bitch to port!”.
So I find it very surprising that many parts of KDE4 already run on Windows and Mac although the Windows guy said they were just a couple of guys working part time on it.
It really says a lot about the quality of KDE4’s codebase, imo.
The mere thought of more apps starting to really use the new frameworks makes me drool
I can certainly see why this technology should be in the hands of developers as soon as possible.
Are there any books about developing for KDE4? I know there are some for QT4 but what about the KDE specifics and new frameworks? Call me crazy but I still like dead tree documentation best
Are there any books about developing for KDE4?
Not that I know .. but I’m really looking forward to be able to buy one.
I think it would be splendid if the KDE team got together to organize in order to write a chapter, or as many as necessary, on each of the technologies available on KDE4 and how to use them on my code, and once done, get it publish either as a pdf dowload or as a printed book (I’m going for the hardcover!)
That is: the “solid” guys write everything you need to know on “solid”, the “phonom” guys write everything you need to know on “phonom”, the “kross” ( I love that feature) guys write everything you need to know on “kross” and so on .. and then some chapters on how to get them to work together if needed.
If you (reader) are a book publisher … well, you just sold at least a hardcover and 3 paperback copies of that book.
(Please Aaron read this: A lot of of ppl could benefit from a book like that! I already have Qt4 books .. I Want KDE4 books !!!!!!!!! =D)
Edited 2008-01-20 19:11 UTC
I’d also like a book.
Books are for me starting points, I know that I have to use the internet to get the most recent information but I try to avoid reading long texts in front of the screen.
So basically I’m waiting for an affordable reading device like Kindle, but affordable and with a better quality.
I’m not sure, but hasn’t HAL been the thing intended to achieve this goal? As far as I know, HAL is available on many UNIX and Linux OSes…
I like any documentation because it’s important for developers. Furthermore, I’d like to have it locally, so I don’t need to start a web browser to search through wikis and forums. In some casesn, “man foobar” is very welcome. “Dead tree documentation” is very useful when you’re going to do work at a customer’s site where usually no documentation is available (thrown away just after unpacking some device or install media). For these “very special customers”, I still have ca. 10 kg of AS/400 documentation in a suitcase to carry over. And you don’t need electical power to read it – at least at daytime.
Good software can impress through good documentation. I hope KDE 4 will impress me some more than its predecessors did.
Furthermore, I hope internationalization will improve, too. No problems if you’re familiar with the english language, but you know my fellow german “functional illitracy and laziness cultivators” – if it’s not completely in German, it’s useless.
Solid basically addresses two issues:
– provide a Qt/KDE style API for hardware discovery/configuration
– make different implementations possible for different platforms
While the second issue could also be always delegated to HAL, it would require HAL to be available on all platforms targeted for KDE4, including Mac OSX and Windows.
This is still an option if HAL becomes available on all those platforms, i.e. there would then be only one backend for all platforms, but it is just not the only option.
That applies for spanish too (regardless of whether you was born in Spain or in any Latin-American country (nested: Argentina in my case).. except Brazil =P)…
I really think that the i18n issue has been a show stopper for non-english speakers .. specially in Latin America (covering from Mexico all the way down to Argentina … that’s a lot of ground … and a lot of people …).
Let’s hope for a book that can be translated on the go by the “Programming with KDE 4” i18n team members before it gets printed
( I’m all in for the Lat-Am team =D )
Edited 2008-01-20 23:25 UTC
That’s the problem, HAL is *nix-specific. KDE4 is designed to run on more systems that HAL could cover. However, the *nix version of Solid does utilize HAL, so that’s not to say there’s anything wrong with HAL, it’s just a narrower target than they’re aiming at.
The OS abstraction frameworks alleviate developers from having to worry about hooks to access system info, network interfaces, multimedia codecs etc. In other words, KDE4 intends to encourage developers to focus on the application without having to worry about the platform it is running on and deal with all kinds of different hacks and workarounds, or outright ports.
It’s a good thing(tm).
Solid is essentially a wrapper for HAL on *nix systems, so why create Solid and not just use HAL?
1. It’s *nix only, at least for now, and they wanted something that could work on OSX and Windows as well.
2. They wanted a higher level API that would be familiar and easy to use for people familiar with Qt APIs. HAL isn’t the easiest thing to use, if you’ve never worked with it before.
3. Backwards compatibility. HAL has been known to change it’s API every now and then, and this allows Solid to maintain the same API throughout the KDE4 series even while HAL is updated in the background.
Edited 2008-01-21 01:58 UTC
One thing I;m happy that Aaron pointed out is KDE’s release cycle. It was something that many of the big distro makers wer asking for and it great to see that they are going to go ahead with it.
You can already see the platform become more stable and the themes is starting to become more appealing as more contrast and separation is added to it.
The KDE 4.0 out today is not the same KDE 4.0 that was out just a couple of weeks ago, it is far more stable and even though it has some issues (Konqueror keeps freezing on me and you could see the same in the demo) at the pace they are going I can already see that KDE4.1 is going to be incredible.
Gnome has to change its turtling approach to development and do what they did when they developed 2.0, break out and make some drastic changes. I have no issues with the desktop itself or how it works, my issues is with the back-end, gnome and the gtk team need to be more forward thinking, more proactive when it comes to developing the actual framework that the desktop relies on. Maybe gnome 3.0 will be a huge refresh of the backend as opposed to the desktop itself,
To be fair to KDE4 after my initial distaste for it, I have been using it since its release as my primary desktop and have been updating regularly (thanks to the Kubuntu projects regularly updated packages). I havebeen running it on a Ubuntu 64-bit install and it runs much faster ans smoother than it did on my 32-bit one install 9that may be dud to all the cruft after months of nonstop use, compilation of software, apt-getting packages, unremoved configs, etc.) Anyways I must say I’m quite okay with it now, I still have some issues with things such as kickoff but almost everythign else is pretty tight, imo.
It’s late here, I’ve been to the gym and I’m knackered, but I sat through the whole presentation and I’m really impressed. I’m not just impressed with what has already been coded and demonstrated, but I’m impressed with the what hasn’t yet been written and their clear ideas on how to get there.
8:00 He actually talks about developers, and catering for them, in a slightly more sane manner than Mr. B. Shock horror.
14:08 Solid. As a developer, you won’t have to be a hardware expert to interact with it. Thankfully, this holds out hope that all those stupid distribution specific control centres that looked out of place and had their own ways of changing IP addresses etc. can be dispensed with. It can all be done within the domain of the desktop.
16:40 Phonon. Same thing as Solid, but with multimedia. You can embed multimedia applications and applets with almost trivial amounts of effort without worrying about multimedia specifics. Multimedia becomes much easier to do, and provides a stable and consistent API with the rest of the desktop.
18:55 Decibel. Same thing, but for VoIP and messaging.
19:25 Akonadi. Similar thing, but for e-mail, contacts and personal information stuff like calendars. This stuff is no longer application specific. It’s available through an API that is consistent with what is seen in Phonon, Solid etc. Stuff can be reused.
21:00 Kross. Scripting extensions, again for developers, to allow them to script for any application.
23:14 Sonnet. Spell checking in multiple languages, and also in the same document. One paragraph can be in German and another in English, for example.
24:27 DXS, otherwise known as HotNewStuff. Users can use applications, and developers can write applications, that connect to the internet and can get updated stuff like wallpapers, astronomy information etc. Anything you want. You click and install. This is basically Red Hat’s much vaunted Online Desktop actually already done today, with applications that use it now and a framework that allows applications to use it. When I tried out the Online Desktop as it is now, this is really what it lacks. This is a part of Freedesktop as well!
26:45 Nepomuk. This is basically what people would know as WinFS, but done in a way that focuses on the right thing – better searching. This searching has to be available to all applications for people to just use. Goodbye Beagle, Windows Search and all those search specific applications. Transparent search is the goal. Nepomuk is about tying together the information relating to the context of something – who sent that document, who altered it and any related information etc.
30:20 Multi-threaded applications and a framework to manage them in a sane manner called ThreadWeaver and QtConcurrent. Solid will tell you how many processors and cores you have, and you can adjust accordingly.
32:46 Symbiotic relationships. I’ve mentioned this before. Trolltech adopted Phonon as its multimedia library, and is being developed in KDE’s SVN. Trolltech develops Qt, KDE gets a great framework to build on, KDE creates some great stuff, Trolltech and others can adopt it and then much more work goes into it. Things snowball.
34:32 Cool desktop effects, with slightly dodgy 90s soundtrack (seem to remember this tune from back then). Somewhat less whooping than Nat Friedman’s SLED 10 presentation, and this stuff is actually useful. Zooming, window arrangement and management, useful highlighting that lets you see instantly what you’ve selected etc.
39:25 Dolphin. Nepomuk integration as well. Interesting.
46:30 Plasma. Resolution independent, and a desktop shell for doing all sorts of things. WebKit stuff is coming etc. Twitter – yet another online desktop thing done now.
51:00 Cross-platform. Linux, BSD, Solaris etc.
53:30 KDE on Mac. Qt 4 and CMAKE has made things much, much easier. KDE 4 and Qt 4 applications actually work well today on the Mac. There isn’t some port that will be completed at some unspecified time. Totally native applications as well, and he demonstrates Marble which looks great.
1:02:10 KDE on Windows. Again, rather like on the Mac, you just get cross-platform applications. A surprising amount has just been ported with little effort. For all those who want Kontact of KOffice on Windows, it is all going to be there.
1:10:00 SVG stuff. Resolution independent.
1:11:07 Marble, which is a component for doing spinning Globe 3D Earth things. Cue the Google jokes about that one with street data. They’re working with Open Streetmap for streetmap data to work towards this.
There was some stuff in there I didn’t know.