All right, let's get this done up. Welcome to the yearly Haskell booth. The southern side is the same one as last year's, but the numbers changed. But in the last year, I'll try to keep the talk part short, so that we can have more time for proper discussions. But I'll still say a few words. Click over here on the Haskell team for those who are not already active in it. Then a few things that have changed recently, during that camp or shortly before, fancy new stuff. And then open discussion for various things. And then a few bullet points of stuff that we could discuss, but of course there's room for more. So yeah, we have a Haskell group, so we maintain both the Haskell compiler, the Haskell library, such as the both. A few Haskell programs have been built. Historically, we were only doing libraries. We took over the compiler later, because actually maintaining the compiler and maintaining libraries is a fairly different thing to do, but yeah, we do it now. So yeah, that works. I like these numbers. They're not the same numbers that I was up to date with the same script from last year. So this is packages in the archive per maintainer. And we are at, but of course the numbers are far too high.  So that's something that the number I'm going to look at. So if we exclude the version from the list, we have all behind the variant kernel and package curl. So they have more packages, but we update them more often. At least if you count the bin that we use. So the read loads on the build CD servers, because of the eye problems. And now we are on the third place of the archive, which is still good, but that's still teaching its binary packages. And if you've used our packages before, you know that there are three types of packages per source package. So the source package is maybe the right metric. And oh yeah, there's still the third place now. We surpassed Ruby extras. I guess that source packages that have ever existed. So we don't maintain 800 packages right now. So there might be some old ones that have been removed in the list. This is just SQL queries on project B, the SQL database containing project information. And of course, Paul is far, far ahead. I once founded the Polyglue, but I don't mind them being first. That's OK, a little bit. This is the number of uploads done per each group member in the last six months. And there's a slight, I mean, the numbers are not very healthy, I would say. So this is one thing for the suppression. How can we make sure that there's more people on top? Oh yeah, we get back to the point. More people on top than maybe, I mean, the number of people is good. It's just that the number of uploads is not very evenly distributed. And there are reasons for that, besides. This is new package upload. This is any package upload. And it's on, of course, depending on when it's in. I ran it half an hour ago, so. Because I had 20 packages except for that. Maybe it's not uploaded, but no, mate. OK, we can have a look at that. It's just that I think the tendency is still right. Yeah, the tendency is still a bit different. OK, we seem to be very efficient compared to team size versus uploads. So we do a lot of uploads per person. And that's partly one of the benefits of packaging Haskell. Because Haskell packages are very homogeneous. They are very consistent in what they get from upstream. They have good metadata. They usually build if the metadata is not fulfilled, and the dependencies are fulfilled, so it can be packaging stuff very efficiently. Less, very little work per package. Otherwise, you couldn't maintain so many packages with so many people. Also, if it compiles a work, so if I change something in the dependency and I rebuild it by Haskell's type system, as long as it builds, I'm fine. I don't have to test it. We do run the test suites. They are there occasionally. But otherwise, I'm happy to upload an un-tested Haskell package to the archive, as well as to the class. Then there's new and spelling mistakes. There are people now working on something like a distribution, but not on the distribution side of things, but rather on the Haskell side of things. It's called Stackatch. It's run by a complete company investing in Haskell. And what they're doing is basically doing our job. So they are creating a curated set of packages, so a set of packages that are known to work together. All dependencies are fulfilled and everything builds. And it's great because that's what we've been doing, and they're doing it better. As in, they have better QH tools, better automation, they are quicker, and they are only focused on Haskell. So the plan that I came up with that nobody complained so far is that we were just building their work. So for the packages that are part of Stackatch, which is on all of them, unfortunately, we will simply take whatever is in the latest long-term release of Stackatch, whereas long-term here means a few months. That's not too long. And then for this way, for a large portion of our packages, we don't have to worry about, is this package compatible with its dependencies in this version? So that's not a time saver for us. A couple of points, as the same as last year. Well, this is kind of a remedy for this negative point. Sometimes, upstream doesn't give perfect metadata. And then we have build failures that we have to cope with, maybe we have to patch things. So for everything in Stackatch, this is not a problem anymore, which is good. And for everything outside of Stackatch, if it becomes a problem, we can kick it out. We can ask them to join Stackatch so that it will not be a problem in the future, or we continue doing the manual patching and working around issues. And then the old problem of having to rebuild everything if we update a new version. But we seem to be coping, and neither the release team nor the WannaBuild team has ripped off my head since we started doing this, so it looks like they're getting this coping stuff. So for those that are new here, a little bit about how we work. So basically, we try to always maintain this invariant per package. So we have a package plan, and I'll come to that on the next slide, which is basically a list of packages and versions. Something that we believe is a consistent set of packages, and that's basically our to-do list, what we want to upload to the archive. Therefore, of course, everything has to be less than what's on package, but that can be quite, it can be ahead of what we have in our packaging repositories. Then, of course, can be ahead of what's being tagged because it's still being rocked on, hasn't been uploaded yet. And that should always be ahead of what's in the archive. And this simple formula kind of guides our work. So if this new version package we consider, and we want to upload it to Gabion, we first make sure that the package plan lists it and everything's fine. Then the next step would be to actually do the packaging, create the change log entry, change control files, and we have a tool that tells us which packages need to do the step, and we have another tool that helps us with the step, and we have to build it. And if we upload it, it'll be tagged, so it's this step, and that step should only be an inequality here if the upload fails because somebody messed up, you should link it in the rejects, or because it's a new, and it takes a while, it goes through a new, so this should be an equality in most cases. You can interrupt me if you have questions. Don't mind that. Okay, package plan is a kind of neat thing that we have, but probably don't have many other teams have. It's readable. It's this file, packages, versions, and then maybe some annotations like don't run the test street, because for whatever reason we don't want to run it. And then we have a tool, which is this one that I ran here, which checks the package plan and tells us about things like, for example, this file, this package has been removed from the archive by now, and I should have also removed it here, so everything in capital letters is something to do, it's a mistake, but actually, everything in capital letters is an error. Anything else is something to do, like these are packages that we want to have in the archive, but we don't have that, don't have in the archive yet, so we need to package them, and then it runs Cabal Install, which is the upstream package tool, comparable to CPAN or whatever you know, and we just ask it, can you install these seven packages in these particular versions fulfilling all the internal dependencies? And if it says, oh, yeah, I could do that, so we're running this Y run, then we're happy. And if not, we get an error message, and we have to do something. So this is the package plan, turned out to be quite a useful tool. Right. We can add patches to upstream metadata, if you have to. We can also add Cabal files for packages that are not on-haggaged, which is an exception, but happens in a very few cases. So it suits the needs. All right, next final agenda is a little update of what has happened recently. So until, I guess I could show that. This is the Debian URL checkup, and right now 89.72% of all Debian packages that have a VCS DAX field have a broken VCS DAX field. Because we were basically the only one using DAX for package maintaining, and now we switch to Git, so our DAX repository has disappeared, and we haven't yet updated the VCS field in the control file. That's something we have to do soon. So now we're using Git. And we do it slightly different with most of other people, so we have all packages in one repository. I think it's a good thing. You don't have to worry about creating repositories and ideas, setting up hooks, whatnot, and you can do commits that affect multiple packages at once, and sometimes bumping the standards version in 700 packages. I don't want to see 700 commits for it. I'll stop here. I can explain the choices even more. Let's defer this discussion if there's discussion about that. I'd only load that it's a Debian only repository layout, so there's no upstream sources in it. There are better tools, I believe, to get upstream sources into your directory. So this has been done, people have convinced me to do it, and slowly the tooling also catches up, so we're adding more tooling to work with the Git repositories. Another new thing that I've been proposing and that we are slowly following is the concept of key packages. So previously what happened was, say, a new version of Git NX pulls in random full diagnostic somewhat obscure package, and the next version drops the dependency again, but then by then we already have it in Debian. Should we just keep it to Debian? Probably not, because the only reason it wasn't Debian in the first place was for the dependency of a certain program that we want to have in Debian, and unless there are other good reasons to keep it, maybe we should just remove it again, similar like you would remove dependencies of your machine, of packages that don't depend on it anymore, so it would get automatically removed. So we don't want to accumulate the crowd. So the idea is that we mark packages that we want to have in Debian on their own right as key packages, and we can do this marking in the package then. This is, for example, for whatever reason, a key package. And then we can use the package line to find out, well, what packages do we have in Debian that are neither key packages nor dependencies of key packages? And then we can look at them and say, oh, well, yeah, let's just get rid of it. Let's just not grow with a package size too much for another reason. So then we don't have to mark hundred packages as key. Packages that are part of Stackatch are excluded from the removal, so they are all basically everything on Stackatch is considered to be a key package, not because it's important, but rather because it's simple. So everything on Stackatch is causing no work for us or very little, so let's just, yeah, let's just keep them in. It's a sign that they're upstream somewhat active, and it's okay. During that camp, we created a package, documented, collected, assembled. Our tools are a little bit better. Previously there was a script running line and rendering repositories. Now we have a proper package. See you next time about that. Before that camp, I backported KABAL and THC itself, 7.8 to Jesse, so in that sense, you are stable, that means release is a bit more useful for the development. You won't get libraries from them in at the moment yet, but you can at least get your compiler and KABAL and install whatever you want with a much four year old compiler. Then we have the latest compiler, which has been released only a few months. So we're still very good for that in standards in experimental. And we have started packaging, like after the packaging has been filed, to support GCC710 and the corresponding Stackatch release, which is Stackatch LTS 3.0. We did that on a branch of the package plan, the package repository, and we are basically making good progress. So there's a dozen packages that need to be looking at and looking at can just mean we're gonna be removing it. And I'm also waiting for a coordination with the Penbook maintainer so that we can test Penbook's reverse dependencies, but it's only a few packages. So I guess we can, maybe actually, just upload everything to experimental by end of the week. Might be a good goal. Then we have something to work on, I feel it. Why do experimental first? There are a few new packages and some of them are interdependency trees. So if we do it to unstable right now, we would have last number of packages in unstable and uninstallable until the new processing has happened. So if you upload experimental first and wait till FTP master have approved all the SQL packages that are new, then we can then again rebuild everything for unstable and upload GCC710 and all seven other packages in one go to unstable and have a very short time of SQL being broken and unstable this time. I've been saying that for every participant it'll always cause something went wrong and it was broken for at least parts of it for a while, at least you can try. Chris has worked on documentation, which is a very good thing. So the Wiki pages are now has a very useful page, which is highlighted in both getting started, which gives you the steps you have to do for training a new package, up-training a package, planning for a new package, these kind of things. I'm constantly making changes to the page because we are developing our tools. So this is a perfect page for the next slide. You can run up-get-installed package-escal-tools and you get a command DHT, Debian Haskell tools, which has sub-commands because our commands are the way to do it this century. And here's a list, we can just briefly go through it. Okay, Cabaldebian is a tool that's actually being developed outside of Debian. It's by David Fox, who in his company uses Debian and Haskell extensively. So he created a tool to create quite nice Debian packages from Cabal descriptions. And he's collaborating with us to make the output suitable for the official archive and we can make more progress there. So, in some cases, you can actually take the output as is without further ado. Mostly depends on where the upstream has put the copyright field in the right place. If not, you just have to modify copyright and control and at least the dependencies are being generated correctly in most cases, which has been the main difficulty upgrading packages. So this is a wrapper around it, which looks at the Debianization with this there and finds out whether we are on the test suite or not, what flags we pass or not, so that in even more cases, you will get the correct output if you upgrade it directly. You still have to manually check it, for example, if flags depend on the architecture, if testing depends on the architecture, these things are not mapped easily, so the output will still be not quite right. Debian.DST is a factory-generated purpose tool, which you point to a Debian directory and affect the upstream tab all and create a Debian system directory without even unpacking the upstream tab all. So nothing you have to use directly in this context, but maybe it's nice to have if you need something like this. DHT-init creates an initial packaging using Cavaldebian and it looks into the packages plan to find out what version number you want. So basically, if the package plan says this is all right, you just say Caval-init, I'm sorry, DHT-init, foo, and then you will get the packaging for package foo, actually, escalate foo, so you give it the Caval name and it'll produce the data package. Make all is like a script, which is a proper program because it's written in Haskell, the difference between a script and a program, I guess. It rebuilds all packages from the packaging repository in a sub directory, making sure that only build packages are being used and not what's in the archive. So you get a clean test of all packages, takes maybe, I don't have a good number, but I think it's somewhere between six and eight to 10 hours to build everything. You can maybe speed it up a bit. And that's basically what I want to use to make sure that transitions like GCC 7.10 are properly tested locally before we connect them. It's also something you can use to get dependencies installed or at least build a new machine that are broken in the archive because I haven't rebuilt them or because it's stuck in new or whatever. So you know that I'm stuck waiting for that to continue all the packages as it was the case before. It doesn't take much space. It's only, it's less than a gigabyte all the build packages, so it just takes time and you can leave it running a little. You'll notice changes and only rebuild what has changed. So if you keep it directly up to date, it might actually be a convenient way of building packages. A mass change is on handy script. If you have to apply a change to many or all packages, you give it a description of the change. You give it a shell script on the line, which is usually running Perl or SED on certain files. And then the list of directories you want to apply the change to in it goes to the directory, make sure that the git state is clean, applies the change, sees if they actually changed something. So to combine this either potentially you just run it again, it doesn't matter. And if there's a change, it creates a change log entry and commits to the repository. Tag, creates a tag, a calling power tag convention. I don't have nothing fancy about that. Upgrade is similar to in it. It uses Cabal Devia. It uses a package plan to find out what version you want to upgrade to. It uses Cabal in it to update the divination. So you get the new dependency specification and the build depends. And it does some fancy thing with git. So it... You need that napkin, if you could return. Yeah, we had a napkin drawing. So it creates an empty branch that's unconnected to the rest. Runs Cabal Debian on your old version which might override some of your manual changes to, for example, change log or dependencies at least. Then it updates the new version, runs Cabal Debian again and takes that commit and cherry picks it on top of your changes so that hopefully you have less manual work to do if there are some changes to the dependencies that are not being done again. Still, it might be the worst conflict in some cases. And you should still check with this afterwards. Upload is just a convenient script to upload, tag and push. So you pass it out changes file and it'll sign the changes file. It'll sign it in the temporary directory. So to not interfere with the make all script which will otherwise maybe redo the package if you sign the source file, the tsc file. And then uploads it and tags it correctly. And the last two are basically a script to tell you where this inequality is something to do. You have what to build. Looks at the packaging repository for any packages that have a change log entry that is marked for unstable or experimental. So it's marked to be, that it's ready to be uploaded but there's no tag. So usually if somebody was not in the X-Ven and pushes a change to the repository, I can run this script and figure out, oh yeah, something new to do for me and I build it and then upload it. What to upgrade compares to the packaging repository with the package plan and finds anything that's where this one is not an equality. And these are the packages that I would then run upgrade on and that's it. You can add more scripts to the tool and add it to the package if you want, of course. So it's the package plan test script part of this. Yeah, right now the package plan and the repository are mostly separate. So the package plan has its own. You have the packages by the heel and you also have the test packages script directly here. I guess that could also be changed since it doesn't really, yeah, I don't really care about. There's no good reason to have it separate. There's no good reason to have it. It's not separate, so it could probably do it. Yeah, people probably should because it makes it by the main page. Are these things that, the main page is not? There is one complication which is that the test package script retains some state inside its own world, which is one of them is it copies your current installation to your C installation's package version's code. So you can add, you only run it for the system. The same, you can't run it on a non-stable for 7.10, even if you switch the brand, it doesn't work. But that's also true for some of these tools, like Kabal Devin. If you're targeting THC 7.10, you would run these scripts or at least some of them, and you probably need to know the scripts about which one in an S-chain route that has 7.10 installed because they query the current compiler for information about versions of the bundle dependencies. So we mean so that it's not just a script, but it also has a state. Yeah. Okay. I'll try to reduce the amount of study it has. So I guess I was still talking more than I wanted to, but okay, we are at the discussion. So some working questions that I think, something in silver from last year's, do we have a good policy on what we want to package in Bedion and what not? Currently, the situation is we package whatever we, as maintainers, individually think, oh, this is what I still have, and let me do it. Let me just keep it there until the end of time or until it's causing problems. Then there has been a discussion on dynamic linking, whether we should support it or not, how we support it, what should be different package names or just use a system of provides and depends. Is there actually a benefit in dynamic linking? Is does it out by the cost of dynamic linking? I guess it's a good discussion to that. And then of course, can we change our workload so that it's spread more even? And for those who are new and want to contribute, here's some things that we can do independent of just updating the package. So this is the end of my prepared part. So I'll happily start now having the both, both these items above. Thank you. So, the question of what should be packaged. I'm, I really like the idea of the Stackage LTS stuff. I think that's very good. But there's still the question of what do we, the Package Haskell Group, package, versus how do we deal with stuff that people who aren't in the Haskell Group have packaged that's built out of Haskell. So Pandox is a really good example here. We have things that depend on packages that Pandox produces that Pandox is not packaged by us. So we have an external dependency. It's annoying. It's really annoying. You know, I can understand Jonas's desire to not necessarily be subsuming into Package Haskell. But by the same token, therefore, one really good question is, should we package anything? That build depends outside of our set. Or should that be handled separately? I don't know if we actually get to ask this question because Pandox is there, Pandox is maintained by Jonas. And we have packages that will depend on Pandox. And I think we want to have these packages. I just almost feel like there perhaps needs to be a separate set, so that we have, because at the moment we've got a set of packages that consist of a strongly connected, as it were, set of things, that we can reliably maintain and manage as a group. And some other stuff that we can possibly reliably maintain and manage as a group, providing their external dependencies so it's in the line. No, technically Pandox is maintained by the group. It's just not part of the technical technical aspects of it. It's not a problem in Pandox, you are therefore allowed to fix it. It's just that it's a bit separate because Jonas is taking care of it and it's also used by lots of non-Haskell geologists. So, like user support or something, it's good that there's a proper maintainer to have it. It's just an annoyance in our workflow. Okay, yeah, but there's no answer to the question. Is it the only package? It's the only package. In that sense. You're right, yes. Only one other Haskell library package, otherwise, it's Akta, which comes to the Haskell library, but it doesn't have any reverse dependencies. And actually, I am told that I'm going to move Akta into our packaging repository, if I wonder. Okay, here, a few people here actually, I don't know. So, we've just talked at lunch, so you knew and you want to contribute, that's great. So, what about Q3? Well, I haven't packaged anything with Haskell. Interesting Haskell, but yeah, I haven't any kind of, mostly I'm interested in it. So, maybe in the future, but not in the future. I have a few packages that I haven't been treating well lately. First, I have to get a good foundation before I go to Insta. What makes it come here? So, of course, the basic assumptions, I also have a general understanding of those. Okay, but I did, so I did try to package something at some point, and I remember there was like, so there was two different wiki entries, which helped you use a cabal, transform a cabal to a Haskell package, but it, so I could, I managed to do something which wasn't enough to use it to put in the server because that was my original idea. I wanted to put something on the server and I couldn't compile the server, so I need to compile it somewhere else. And for now, it wasn't enough, but it wasn't anything that could have been uploaded to Devian and that's why I wanted to work into it better and I thought it was a good opportunity to maybe try it now. So, as a user, what do you think we could do to the packaging of Haskell Devian to make your life better? So, it makes GNC entries very accessible. And there are quite some, not many, so... Is there anything that you want that we don't have? Because it's so easy to use that I might come out and just skip over and you don't have to learn that stuff. And a script that I think would be nice for someone to write would be one that double checks the co-installability of the content of the archive, because in Jesse, we've had a mistake. So, the mistake in Jesse was manifested by the char1 problem that I saw earlier this week. We had two packages that were independent and built against different instances of char1 or binary or something. Binary. Binary. And, because we did a last-minute fix that sorted something out with binary. Having a script that we can run against the archive to ensure that we're not getting into a situation where we need multiple versions of things installed simultaneously would be helpful, because to hit that problem again, do it once, oops, mistake. Do it more than once. I'm not sure if that's actually possible, because I think the situations that lead to that are that you have a package that has a very odd dependency, like it files a new version, something that comes with a THC, and you're making an exception to the rule that there's only one version per package. And that's a logical consequence. Otherwise, you would have to rebuild everything with a package version of binary. And that wouldn't help, because binary is a THC-bundled library. It comes with a THC package, and it's not upgradeable easily. At least there's something. Right. At least to be able to know what the limits are would be nice. Ten of them? Okay. We should just try to think of extra possible tools. Yeah, yeah. That was the initial, I guess we should start. So let's maybe come back to that when we're thinking. Because that is somewhat controversial, and involves work. So for those who are not aware of it, currently, every has to have binary in the study clinic. So all there has to be is being linked to it. It's one big block, maybe a few dozens megabytes in size. But it doesn't have any dependencies into the Haskell world anymore. So all the build dependency, or the dependency problems that we have managed for library packages, we don't have to do that for the binary packages. So even if something is broken, very interesting, people can still install a 10 log. That's the current state of the Salesforce. What we could also do is we could link them dynamically. THC supports that right now. And if we have the dynamic libraries already in the death package, we would probably move them to separate package and only contains the SO file, the dynamic library. And the question is, what are the benefits, what are the disadvantages? So the benefits that people want to have from it are smaller binary sizes, because that is in libraries. And if they have multiple different Haskell programs running at the same time, they save memory. Then another plus is that it's easier to specify data dependencies. For example, I think, let's say, time lock side proc. It may ship some data files that require the runtime. So right now we have to jump through some hooks to make sure that every program that links this library inherits the correct dependencies onto the data package from the library. If it's a dynamic library, you can have the dependencies directly on the dynamic library and everything easy. Then security updates are always a plus. You can rebuild the library and every binary package using it is either broken or gets a security update. Then the downsides are that the size of the packages list will increase for every web user. And I've heard people complain about, I want three packages already. I think four-packages person's package might make difference by more. Then we have breakage and unstable for programs. Unless you have two packages for each program, one dynamically linked, one dynamically linked. Also maybe not the nicest thing. This is basically cosmetics. Installing a package will now put in lots of packages with severe names. People might be put off by that, so apparently we're hiding that in a way. Anything else, yes? We might get upload amplification in the sense that if we update a library package, we may have to update a whole bunch of program packages as a result. That's actually another trade-off. Because the other choice you have when you split the package into the package holding the SO and the package that has the master SO process, is that you can actually, instead of just provide the package with a version number, you can actually generate the package with a version number. Now, that has the great advantage for stable. Once you're not updating very often, is that programs that were linked against an old version of the library will still be there and will be fine. But of course it has the disadvantage in a rapidly developing situation that you accumulate dots and dots and dots of these libraries. And more importantly, every single upload goes through new. And you can't use the built-in views and the new features to rebuild stuff anymore. Yes, so that's another trade-off. Currently, many of you know this, but I regularly look at this output of the script which tells me what Haskell packages need to be rebuilt on the archive, and I schedule them using one of them. I have special access to that. And that's a very cheap way of rebuilding stuff compared to doing a source product look. And I would rate or anything that has less automation than this. So changing packages names, unless we can do it in a new, which is not supported at the moment, seems to be out of features. Yeah, because in that case, what will happen is that you get lots of packages that you get. No, but it's not a pulsing combined source packet that makes up package names. You have the package name into dead-end control. So you're actually manually changing the control file to change the package name. Yes. You can automate that, but it's still a source product. I don't mean that the Java people don't use the Java. It's a matter of frequency, I guess. We will see people do it, but I wouldn't want to do it. So what is Haskell specific on these class minuses? It's just that Haskell is a more rapid changing and that it's historic only offered the one way. And it's more rapidly changing. It's changing in such a pressure because every minor version upload requires an equivalent to an SL name bump in... That there are no APIs. There are already APIs. But they're changing. They're not stable. That's the problem. Another plus is that you can link a non-Haskell SO to a Haskell SO. You can't make a non-Haskell SO to a Haskell .a. So you could have a Haskell shared object that exported signals to other libraries. Did you do that? Today you could depend on a Dev package and use the SO that comes with all dependencies of these libraries, statically linked into it. You can't statically link it into an SO because you're not using PIC. So we'll end here. So our Haskell libraries are not positioned independently. So you can't link them into an SO. So the .a's aren't built back? Right. So we're providing SOs that we don't use them? We'll be using them because CHC requires them if you load something with CHCI from a Haskell. So CHC is using them internally. Right. But we're not using them in the distributions themselves. We still need them to be there. Okay. I think we're out of official time. Is there anything in this room afterwards? I don't think so. But the video team wants people to leave, right? I don't know.  We could just continue the bof, the dinner bof. So go to dinner together. At least those who are not scared by now. And see what comes out of it. Yeah, I guess I got... Again, I talked too much so we couldn't really get much. I think we have more psycho-society things. I think we have a few. Okay. Then I'll officially call this end. And thank you all for attending. Thank you.


It's time to look at the energetic costs of sex. I would like you to take a minute to think about how, you know, when we think about cost, we think about money. Money is resource. It takes energy to earn money and we invest. We eat so that we have enough energy to go get our jobs so that we can get money so that we can do things with money like buy foods so that we can eat more so that we can go work in our jobs. But think, we can make an analogy between our investment as critters in sex, what we're willing to pay for sex, for being sexually attractive to someone else and potentially making babies with that someone else. Okay, so it's got to be like awesome if we're actually going to do this.  Internet like dating services, I mean we'll pay money, we'll watch advertisements, we'll do, we'll read books. Like look at this, you can find your dating and your Facebook, how to find your homie on Facebook and your boyfriend from matchmaking. I mean like go look for, I want to find a boyfriend and you will be like you could spend all day and all your money on strategies to get yourself a boyfriend, which let's not talk about that too much. Let's just keep this on a biological standpoint. Dude, let's talk about makeup. How much money do we spend on makeup? Well, some of us spend money on makeup. Others of us, I don't know what my excuse is, but there's a lot of money that is spent on making us feel good about how we look. Like this guy, how much money did he spend to give his tail feathers that kind of bling-bling? Obviously he didn't spend money making his tail feathers look like that, but he did spend food. And think about the cost of having a tail like that. If you're strutting around with that kind of a tail, why? Because you are guaranteed to be eaten by a lion. If you have a tail like that, you're going to be slow. You're going to be super obvious. Like why would anybody have that? That is not necessarily the result of weird humanness. That's actually what the ladies find fine. And so the lady pee foul, look at this guy and go, dude, I'll make babies with him. That's awesome. I totally want kids that have those genetics in that amazing tail. And it's worth it to him that he's more likely to get eaten by the lion. It's worth it because he's also more likely to get with the ladies. Think about it. I mean, look at these birds. These birds make these fantastic nests and presentations to the ladies. How much energy are these guys spending going around collecting their special colored things to impress the ladies? Wouldn't you want to go make a baby with a guy who could build this kind of gorgeous little setup right here? I'm super impressed. It's expensive. That takes a lot of food energy to make that happen and to be that awesome and impressive, but it's worth it. There's something about it that's worth it.  Let's start out with the banana slugs.  Oh, my gosh. Okay, so these slugs, they find each other. They're like, hey, baby. And their slugs have boy parts and girl parts. So they are both male and female. And they find each other and they start having some foreplay action going on. And their foreplay takes forever because they have to go walk around each other a million times and they twirl together and they get closer and closer. And then pretty soon they start biting each other and slimy everywhere. And then pretty soon, they start this race to see who is going to get their penis into the other one first.   The whole point of a penis is to put sperm from one place to another place.  So these slugs are slimy around each other and trying to get their penises into the other one. And it's so worth it. They're biting each other. Whoever gets it in there first is the boy and gets to fertilize the eggs. And if you think about that, he who can leave the sperm, the other one has to deal with the eggs. And so she now is going to have to go off and take care of the eggs. So there's this whole other layer of investment for the one that isn't the penis bearer in that interaction. But this is crazy.  So worth it they bite it off. What?    That cannot be a pleasant experience. They do it. They keep doing it. Not very many male honeybees or bumblebees or whatever kind of bee this is. The boys, when it's their turn, possibly impregnate or what fertilize the eggs of a queen bee, they basically throw exploding testes at the lady and hope that their sperm get in her and their testes are done, like they explode. And worth it. This is the epic sacrifice for sex. This is an anglerfish, like the kind in Finding Nemo. And this is the girl. And she's huge compared to the boy. But anglerfish live way down deep in the ocean. So they're just chilling down there in the ocean. It's dark. No, we can see anything. And it's kind of hard to find others of your kind. So the ladies have their lady smell. And the fellas, they're tiny. They're like, I mean, this is a fella right here. He's like tiny compared to her. And not only is he tiny compared to her, he doesn't have a digestive system.  And he swims around and smells for the lady. And hopefully when he finds her, this is the ultimate, like how can this be worth it? He bites her, attaches himself to her body. He's literally attached to her right now. And he basically becomes like a little parasite that her body takes over, takes him over. He, her blood supply goes in and like fuels him. And it's almost like a little pregnancy. But she grows herself around this male that bit her and attached to her.   And then she's like, dude, now I've got a collection of them. I can basically make babies whenever I feel like it because I've got this collection of male parasite testes hanging off of me. How handy is that? I mean, that's incredible. Let's just take a second.  There's no question. Let's take a second just to look at penises. The investment in a penis. And take a look at these penises. Dude, this is some kind of like whistling duck or something amazing.    Maintaining that thing? That's got to be some effort right there. Then let's just talk about the barnacle penis while we're at it.  You know what a barnacle is? It's those little volcano things that are out in the ocean and they have feathery feet and they filter feed like this.    It can't go and make its face all make-up-y and beautiful to impress anybody.  Penises are amazing.  No. The gorilla is huge and he really doesn't need to invest his energy in a penis.  But other than that, like, who cares?    He can just tackle someone, do his thing, and then leave.  It's just necessary, but certainly doesn't have to be flashy or gigantic. The point is that critters of all kinds, including us, are willing to invest tremendous amounts of energy, whether it be money, food, body, mass, whatever.  Okay. Why? There's got to be a reason that we would be willing to do this. I'm about to tell you.


Hey, everyone. Good evening. So my name is Tarkesh. I'm from QD42. I'm a UX designer mostly, but I also deal with UI design. And we are a full digital service agency in India. And today I would be talking about designing for privacy, where you balance your user needs and data security. And we will actually find out how one could balance both of them without compromising the UX of a digital product. And a small disclaimer also. I am speaking for the first time outside of India. And I might start at few places. So please bear with me, OK? So the content, basically, what we'll be covering is what is data privacy. Most of the people have different perceptions of what data privacy is actually about. And we would be also speaking about user expectations of digital products and how to balance user needs and privacy. So in here, this particular section, I would be talking about a case study for UNICEF, Laha. So it's an initiative. So Laha is a virtual safe space. It's an initiative by UNICEF, which aims to support gender-based violence in emergencies. So victims of gender-based violence in emergencies and how we have actually built out a feature for Laha. And so in this particular case, we had a very different or exceptional pain points from the users of Laha platform. And it's only for girls and women in conflicted areas. And I'll also tell you about how we have actually found that balancing factor between data privacy and still maintaining and tackling the user needs. So without waiting any further, I would like to get started. And I would like to have a few minutes. So I'll let you read how users perceive what data privacy is. So what data privacy means is that it's the prediction of personal information and management of how data is collected, shared, and used. So one thing we have to keep in mind is that we are speaking in terms of UX right now. And from design point of view here, it's not only about how data is collected and stored. It's all about how you also ask for the personal information or how you're informing the users how the data is going to be shared and used across. A famous statistics by Edelman revealed that 81% of the consumers consider data privacy as their fundamental right. And there's also another statistics which says that it's from Global NGO Technology Report, which says that 92% of the NGOs right now are concerned about their data privacy. And it has been a growing concern across the NGOs. And actions are also being taken by the organizations and the NGOs to tackle this. So this gives us another question, which is that does data privacy actually prevent a better user experience? So let's see what users expect from the digital products. So all that user needs is that they want usable products which are reliable, fast and performant, accessible, and which are personal and contextual as well. So as you all know, all these factors make a good user experience. But one might be actually thinking, what do these factors have to do with the user data? So now we can actually relate the search suggestions, which you usually see in Google and any other search engines. They actually use all your personal user data, which will enhance the user experience and make it more efficient. And this is how usually organizations use the user data to enhance the user experience. And another example is that accessibility features also can be enhanced with the user data, such as themes and color schemes and sizes, which help in increasing the accessibility or maybe personalizing the accessibility for the digital products. And there's also personalization, which is a major feature where every other digital product builder will actually rely on the personal data or the user data, such as providing specific locations and building more contextual information and personalizing blogs and content based on their user interests and data. So now that we all understand that user data is quite important in making a good user experience. And so all these are the factors of good experience. So to meet all these factors, we would need good amount of user data. But can we actually meet the user expectations without having to compromise on the data privacy? So let's just recap what all we have covered until now. So a quick recap is that we have established user needs are nothing but they all need a good user experience. And we have also established that for designing a good experience, we will need some amount of user data. And we have also perceived from the statistics and growing concerns around the privacy is that users are actually considering privacy as their fundamental right as well. Hence to satisfy the user needs, we have to design experiences which doesn't compromise the privacy of user data. But how do we actually design experiences which satisfy both the user needs and data privacy concerns? So for that, we'll have to find a fine balance between user needs and the data security without compromising on the user experience. So I will actually tell you how did we find that balance while we designed a user forum for Laha. So Laha is what I've mentioned earlier. So it's a UNICEF's initiative to find gender-based violence in emergencies. So before jumping into the nitty gritties and how we have actually designed the forum, I would like to tell a few words about what Laha is actually about. So Laha is a safe space for women and girls. And it aims to provide information and services on sexual, reproductive health, and gender-based violence. And it aims to promote all the resources for women and girls in a very safe, culturally appropriate, and accessible to adolescent girls and women. And it also has information in a very fun and creative and a positive way. So the challenge is that we have to build a user forum to find support, ask questions, and seek answers and services. Because until now, what Laha does is that it's just one-way communication. So UNICEF usually puts up the resources on Laha platform, but there's no two-way communication back from the users. So hence to tackle that, we have to build the user forum, which we have envisioned to kind of give a peer-to-peer support through the platform. And what was our approach was that we started off with the design process, which is the user research. And in the user research, we've done some desk research. And we've kind of understood what kind of users are we designing this for. And so we've conducted some workshops with the stakeholders of UNICEF and as well as with the users as well, the prospective users. And goals, we also understood that what goals, short-term and long-term, UNICEF wanted to achieve with the forum. So basically, we have understood and kind of divided the personas while we started to design this forum. We've kind of understood there's an age group of girls that we have to design 12 to 14 years. And there's also another age group of girls where we had to design for 15 to 17 years of girls. And then there's also teenagers of girls and adult women as well. Now, so having understood all this during the discovery phases, then we started out with conceptualizing the features for all personas. And basically, we have started with the wireframes. And this is a prototype, which you're seeing right now. And after putting down all our ideas based on our findings and the wireframes, we have actually tested out with interactive prototypes in Lebanon and Venezuela. So these are the prototypes that we've built. And we've built in multiple languages so that we still maintain a relatability with the users. And so based on our testings from the real users, we've kind of iterated the designs. And it's still ongoing project right now currently. We are in phase two, which we are still iterating with the forum users. And I would also like to mention that we are not deep diving into the process. So I'll be covering mostly the insights about the data privacy and the user experience expectations of the platform. So the main insights what we got was low digital literacy users. And since we are actually dealing with the users who are from conflicted areas, and they don't have a lot of digital literacy using digital platforms, and we also had to deal with very low internet connection. And we had to deal with, so these were the major pain points of the users. And another important pain point is that confidentiality of the users. Because we are trying to give support and information to the users or the victims, which who are actually took some actions against gender-based violence in emergency. So confidentiality of the users was the most important insight that we have got. Because in most of the cases, if a woman is seeking help, there might be a good chances that their relatives might actually see what they are trying to put up on the internet. And there were actually a few cases where we heard from the users while we were doing discovery that they might actually face a life threat. And due to the nature of the product that is Laha, usually sensitive topics are discussed. And sensitive topics resources are also shared by the UNICEF. And there's also a good amount of chances that there'll be unsafe device usage as well. And there'll be also abusers of the platform, since this platform only caters for girls and women. Now based on all these major insights related to data privacy and the user experience, I'll be sharing a few features that we have designed which can tackle these insights. So this is how we've actually designed the forum to be. So for tackling the low digital literacy users and confidentiality of the users, we've kind of gathered zero personal information. But all of you might be wondering, actually, how did we even manage to design and build a forum without using personal data? So we started off with ideating on how we could actually solve this, keep the confidentiality of the users, but yet give a peer-to-peer experience. So we thought we can actually use random names. And Drupal has really helped us here. We have customized the user registration process of Drupal and to process and prioritize the user anonymity. And we've also considered the challenge of account recovery here. So because since we are not having any kind of personal data which is being taken, neither emails or neither mobile numbers, so we had a challenge of how to actually recover an account in case a user name is being forgotten. So we came up with security questions. So that was quite simple, yet effective. So we have built up a set of security questions at the Drupal back-end, which could be used across various domains because Laha is actually personalized for countries and regions and based on different ethnicities as well. It's not a single domain that we are using all across the world. So it is actually customized for country-specific needs. Then since we are not using any kind of personal information, we wanted to understand how do we still maintain relatability and personal feeling for the users while we are not kind of having any personal information being taken. So we wanted to have avatars. So avatars could be customized based on the countries and the ethnicities as well. And for tackling the low digital literacy of the users, we had to give out contextual information and guided tours. So everywhere across the user forum, we had designed it to be as descriptive as possible. And we have given out guided tours all across the site. And be it from asking a question, sharing your answers, how one can actually do that. And this is actually accessible with very low internet access as well. Most of the websites you see or the platforms, they have a very small checkbox saying that you can read our policies. But it was not this case for this platform, especially, because we have to educate our users about what were the policies. And we have actually embraced these policies. So we have given out on the home page and all across while registering as well what were the policies. And we have actually informed the users. And we were actually very transparent as well while we wanted to build trust within the community. So we've also set out guidelines. It's not one huge sheet of guidelines one could actually read. So we've kind of distributed these policies into separate or small sections of guidelines, which could be accessed at various points, touch points across the platform. There would be a specific guidelines while asking the question. And there would be specific guidelines while commenting and so on and so forth for registering as well. Now, since we are dealing with sensitive topics, and we also wanted to maintain the confidentiality of the users, and we also had a threat of there would be perpetrators of abusers. Hence we set up a very robust moderation policies. So every comment, every question that would be posted from Blaha would be first moderated. And these moderators would be from UNICEF who would be going through every question and comment before it is being posted to the public. And one of the example I've shown you here is how the dashboard for the users would be looking. So this is one of the questions which could be in review and questions which are rejected. And we also embraced why was it rejected and how could such a question could be published by giving out certain factors which could help them in coming up with the question or rephrasing their question. And we also had reporting as a feature because we also thought there might be few instances where moderator could actually miss a certain question or a certain comment which could be threatening for someone else. And that is why we had come up with reporting and we wanted to swiftly address these privacy concerns and enforce the community guidelines with the reporting system. Now that I come from a design background, I'm not so much into Drupal technology but we kind of understood how Drupal could be used to further enhance all these security processes that we could do. So we've used text processing and filtering of Drupal so which was actually instrumental in finding the sensitive words and eliminating these sensitive words and these could be flagged at the moderator's admin. Now these are few security modules we have used because there was also a concern where the session limit has to be tweaked. It's not like every other website. You still maintain a session. So we've used session limit settings. We've also used Sec-Kit, that is security kit and we've customized all these settings to enhance the user experience yet balance the privacy concerns of the users. So these were a few features we've used across Laha user forum. So it's not very difficult to balance the data security and the user needs as well. So all we need to understand is this. User needs are nothing but they need a great experience and we also understood that we need some amount of user data while designing for a good experience. Hence from a simple math equation, we can safely say that user needs can be balanced when you design keeping the user data in mind. So basically for an uncompromised experience which satisfy both the user needs and the data privacy which has only achieved when you design for privacy. So the balancing factor for both user needs and user data is when you design for privacy and basically privacy shouldn't be an afterthought. It shouldn't be like after testing out there are some privacy concerns and we have to go back to the design or drawing board and we have to figure out how to solve that. But it should be essentially a component of the design process itself which ensures that user need and data security coexists harmoniously. And that's my topic actually where designing for privacy, you can actually balance user needs and data security. So for a great experience, it's a result of combination of user data and design and this could be only achieved when you consider and design for privacy as an integral part of the user experience. So that is my session actually. I would like to answer any of the questions you have guys. I have some t-shirts here which and some amazing stickers as well and we are at booth 24. We are QAD42 from India. We are a full digital design and development services. And if you guys have any other questions related to tech and wanted to know how the tech was implemented, we would be more than happy to answer at our booth. You mentioned that there was low digital literacy in that region. So apart from what you mentioned, what all you did like basically segregating all the tips throughout the process and so that this isn't a huge page for them to read. Is there anything else that you basically include in the process and as a designer, do you see, did you feel any difference from how you usually design websites and specifically in this case? Like I would like to know some insights on that. Like was it a different experience and how did you learn anything new or anything that we as a developer can understand from the design perspective. Okay, so basically we have kind of come up with new workflow. It's not that you include your developers in the design process. It's after you finish your designs, you hand off to the developer and then there might be some hiccups where the designer says that it could be actually done but technology-wise it's not possible. Hence, to tackle that, we have actually used the design, the developers' instincts and feasibility checks right from the starting of our design process. So while we have envisioned certain features, we also wanted to make sure that it's actually quite possible with Drupal or any other technology. So that is how we've kind of maintained relatability of what we are envisioning and is it really possible to build the features? You can actually come here, yeah. Hi, yeah, thanks for the talk, it was great. So I just had a question really about the clients, effectively, in this case, UNICEF, right? Have you ever had to deal with situations where, say, for example, the client's KPIs are in conflict with the user's expectations of data privacy? So UNICEF had a very high standards of KPIs, to be frank. And we have actually done usability testing for around three to four times maybe just to balance their KPIs and yet balance the user expectations. So that is all done after our wireframes and the prototypes are done. And that is how we have actually kind of balanced both UNICEF's KPIs standards and the user expectations as well. Of course, we have to back down on a few things just to satisfy the UNICEF's KPIs. But we've kind of found a middle ground based on our testing and iterating to satisfy both the user's needs and UNICEF's KPIs.


Norman, thank you for that. Now Dan, Sujik, is joining us. What I didn't say in the introduction that Dan, in fact, is what I could say a student of Norman's work, having written a book on him and produced, in fact, authored and narrated a beautiful film on his work. So in many ways this conversation also becomes more intimate. Andrew Adonis, as you know, unfortunately, can't be here, a number of the issues that you raised, Norman, about infrastructure and airports, which I thought would be happily moved on to Andrew. I can't do that, so I feel very nervous and want to put on my crash helmet in case we start talking about the Airports Commission of Decision on Heathrow. Some of you know what I mean by that because I wasn't the Airports Commission, but we're not going to go there directly. But I thought, Dan, we might start just going back a moment. You wrote a few years before we started The Urban Age, a book which for many of us actually is incredibly influential, still is today, called A Hundred Miles City. And there you, in a way, chronicled some of the problems of the cities as you saw. You traveled to different cities with a great photographer. You described the sort of homogeneity that was appearing. And it's going back a number of years, 13, 14 years. I can't help, but after hearing Norman sort of talk, feel actually, even though you bombard us with statistics and you show us things of enormous beauty, by the way, every single beautiful project was by him, just in case you didn't get it, and quite a few of the colleagues in this room, I couldn't but help feel a sense of optimism, actually. You could solve some of the problems. Now, Dan, it might be fair that even The Urban Age, let alone your book, nearly gives a sense of not hopelessness, but here's a problem and is it intractable. And as you sort of think back and, in a way, are informed by the analysis of this work and these ideas, what are your reflections on that? Have things changed? Is there greater potential? There's greater knowledge of the problems. Well, Norman is obviously the consumer optimist. You know, I thought watching that, what Norman was doing was making extremely difficult things seem extremely easy and straightforward. I remember a long time ago thinking about Norman's relationship with Buckminster Fuller, who once proposed the idea of putting a dome over Manhattan, which in his day was a speculation, I think Norman could possibly do it at a pinch. Yes, optimism is what one takes from that. It made, I mean, to me, the optimistic things in particular were that image of smog being dealt with in Britain, the green belt, Britain responding to the big stink, and that sense that you can make things happen. But that was also the period, of course, of Brunel, who was perfectly right about making broad gauge railways. It was a far better way of doing things. However, we have a narrow-er gauge system because by the time Brunel came along, it was too late. We couldn't go back. First, that's some of the arguments that we see about why Heathrow is an investment that will not be walked away from. I saw lots of big ideas, and I think that some of the world has an allergy to big ideas. We saw those great mares, but there's also a tradition of technocrats, I think, about Robert Moses, who made Manhattan, but also provoked Jane Jacobs to see him as Beelzebub destroying what makes a city special. Houseman did much the same for Paris, but perhaps rather more beautifully. We have, I think, this other tendency in the West in particular of activism, that sense that cities are too complicated to leave to big ideas, that maybe there's another approach which is to solve each problem one pothole at a time. I suppose we have that continuing tension. We like to think of ourselves in London as being a fundamentally conservative city in which nothing very much happens. Of course, look out the window, and you see an extraordinary amount has happened in the last 10 or 20 years. I think back to 1984 when the Prince of Wales created a collective nervous breakdown in the architectural profession of this country by objecting to one 18-story high building that was never built by Mies van der Rohe. Look out the window now, and you see a forest of 1,000-foot-high skyscrapers. How has that changed? What's actually allowed what was seen as being insanity building high-rises over London to seem normal? It's not based on the electorate in London voting for it. I mean, in fact, Ken Livingstone did actually have an agenda when he was elected the first mayor to make London a world financial centre, and in his mind, I think that also involved making it look like a world financial centre, which is the high-rises. We do have some of those technocrats. I think that Peter Hendy's contribution to London is extraordinary. I think we now have one of the best mass transits. The head of transport for London for a number of years. We have one of the best mass transits in the world now. It's a fantastic system which has technologically advanced as well. One of the ways that London has changed is City Appa. It was a big idea. It was a very big idea. So I suppose I'm ogging with myself as usual. So I suppose really what lingers in my mind is how is it that one creates a democratic consensus for the big ideas? But just I could pick up. There are good guys with good big ideas and there are bad guys with bad big ideas. New York wouldn't exist without the big idea of a grid. And there was a very interesting article in the Wall Street Journal that chronicled the history of one block of that grid. When it had no value in the 17th century and was given to slaves and it had gone up and down. And one of its biggest rises was in the 60s when you had the painters who were doing great big paintings and they could suddenly use that stock. So it had gone up and down. So you need the fix, the framework of the big idea. Big idea Central Park. The only three dimensional park in the world. Probably the only park that was created for the social good. All the other parks, Royal Hunting Grounds, which eventually were shared by everybody. Those two big ideas, just pick two, New York wouldn't exist without them. What would London be without Regent Street? Big ideas. And the underground, that's the biggest idea of all. So you either go forward or backwards. And it's the mix of the two, the small initiatives. So it's not just, but it is planning for future generations. It's looking beyond. I think that's very encouraging in terms of some of the things that are happening around us now. What is interesting about the points you're both making is where do these ideas ultimately come from? Some are good, some are bad. And how do you test them? I mean, one of the reflections we've been making recently with Fiddup, my colleague at the urban age, is we've been observing for 10 years this extraordinary pace. You've talked about it. We've all talked about the pace of change. The numbers and the amount of things that happens in the hour that we're speaking here are unheard of. I think it's probably fair to say that most of the things, 95% of what is built out there in India, in Asia, et cetera, is probably spatially fragmented, socially disruptive, and environmentally negative. In other words, most of that which is built out there is problematic. There was an occasion in Shanghai where the city architect looked out of the window with us and said, you know, probably 25% to 50% of everything that we're building now, that I'm commissioning, will have to be torn down because it actually will become socially dysfunctional. So the question for me about the ideas to you, to Norman, to you, Dan, also, is there a problem ultimately, or how do you deal with this problem, of speed? In other words, is there a benefit, maybe, of having a little bit more time, maybe not too much time, you're impatient, I know, in terms of just knowing whether we've got things right. I mean, if Andrew were here, I would say you've set up a National Infrastructure Commission. You're going to commission thankfully things that go beyond political cycles. This is a massive political innovation in this country. All good news. How do you know what you're getting right and how do you, in a way, test that? And I was wondering whether you've reflected on that because, you know, you rightly said you have good and, there are good and bad ideas. How do you deal with that issue of time? I think that if you, if I think of the experience in places like Barcelona or Bilbao, there was a very conscious gathering of talent. In other words, you were not just getting people because they were influential names in the society. You were getting them because of their skills and the fact that they could make a contribution and they could put the collective interest above their individual interest. So, and a tremendous amount came, I think, from the architectural profession where you had individuals, I think you've come across it, who would use their skills not in designing, and of course, this is what your cities program is about right here at LSE. So, I think it's the quality of the team, the collective, and that being chosen for its expertise rather than- My question was, how do you deal with that in a city that's, say, Lagos, Contrasa, Dakar or something, which is moving at a pace where perhaps you wouldn't have that maturity of, I don't know, checking, bringing in the right people. But you know, Ricky, when Engels wrote the condition of the English working class, he was actually in Manchester in a city which he described, which does sound not unlike Contrasa or Lagos now, in which he looked at multiple degradation. He looked at things happening very quickly. He looked at things being destroyed. I don't think it's the first time in the history that things have actually changed remarkably quickly. I suppose there are intellectual and architectural and planning fashions as well. I think if we look at what's happened in the West, we've gone from a period in the 1960s when a technocratic approach allowed us to think that big things could work. Many of those things actually did work. The British New Towns, for example, I think now look like a very solid achievement, the sense that you might actually have technocratic adventures, and there was a loss of nerve. Culture's learned from one another. London built the world's first underground railway. Paris didn't do very much for another 40 years and then built a better one. And finally, Crossrail is better than that. Hausmann and Napoleon III saw what Nash did in London and took that to Paris. Things do go up again. Isn't it the bigger picture?  And it's almost like the opening address right at the beginning. The city in that sense is a little bit like a manuscript that's added to, things will be done in a hurry. They won't be good enough. They'll be knocked down. They'll be replaced. New technologies will come along, improvements. But I think that there is a certain inevitability. Perhaps there are things that you can try and slow down.  It's got an energy and a dynamic of its own. What is interesting on that note is your last project, the drone project, which in many ways is a piece of infrastructure effectively that you've been thinking about together with Jonathan, which frankly, it's very difficult to see what the downsides are. And in that sense, it could actually leapfrog a whole series of otherwise inevitable transformations, investments from the wrong people, terrible roads which will cut off communities, have negative impacts on. How does one get that story there? Now, a few days ago you were interviewed by Rowan Moore, a journalist, critic, writer in The Guardian and The Observer, and the headline was, I don't know if you ever saw the headline, and coming from Northern, there's a sort of quite amusing, says, I have no power as an architect, no power whatsoever. That was the headline that came out from you. Now, I think there's an interesting connection there, which is there's the leadership issue. You have to have the people who are ready to listen to assemble, as you said, the right team, but you nearly denied the role of the creative mind. And therefore, the ability of people in power, and this is, if Andrew were here, it would have been interesting to ask him that, but we can all reflect on that together. Where does beauty come into this? How do you convince someone that actually spent more money on that beautiful bridge in France is actually worth it? You can't say you don't have power, come on. Well, you didn't finish the quote, you see. So I'll finish the quote for you. Right, okay. I said I have no power as an architect, absolutely no power whatsoever. The only power I have is advocacy, because I can't, if I try to convince somebody that they should do something and they should do it so it's beautiful, and it wouldn't necessarily cost more. But if it does cost more, then it would be justified. I can't go into my back pocket and pay for that. I can't pay for the project, so I'm not commissioning it. I'm not a developer. And maybe that would be a more interesting position to be in. Maybe to be like a Nash in the past who was an architect's stroke developer and could put his money where his whatever was. I mean, I made the point that I can't direct. I can only persuade. So I think that if with my colleagues we have a passion and a belief about what we do and how we do it and why we should be doing it, then sometimes we're more effective than others in terms of persuasion. So it's the power of advocacy to be able to try to demonstrate that you should do it that way rather than that way. That if you spend a little bit more money doing it this way, you will have a better environment or you will save some energy or you will have better internal communications. And that will result in greater productivity. Power is a very slippery thing. A developer is actually usually not an individual. A developer is usually a group of people who manage to assemble a pot of cash in a site and deal with a panning system. My experience of developers, they're led by individuals who are prepared to take massive risks. With other people's money. Yes, well, they always have the power of advocacy. Exactly, exactly. But usually the developer will say, of course there are exceptions. But they're probably putting their own financial lives on the line as well. So they're taking a gamble. There's a downside to it. What only hears about the success stories. And that's true of any walk of life. But the idea of the individual... It's interesting you're both... Wait, finish that because I want to go on. No, I mean, I think you're right. Of course there are. And there is that strength and that leadership. But more often there are multiple levers. And usually the individual will say, well, it wasn't me. It was them. I was told to do that. I couldn't do this. And so the sense, I mean, good things emerge from groups usually. Of course you have a very strong client down the road. Before we begin to open up questions from the floor, I just wanted to take this discussion and connect it to what was talked about last night here. Saskia introduced this extraordinary statistics, which she then referred to as practically chronicling a monstrosity of what was happening in the sheer numbers of square meters, square feet, that are owned by foreign investors in different cities. Not that in and of itself was just the problem, but that was having an impact on the fine grain effectively, on the porosity, on the architecture of the city as we know it. And I think one of the things that we have all been reflecting on since that moment, since there is this extraordinary need in the world. We've all talked about it. You showed it with your sort of statistics of what's happening in Africa, Latin America and elsewhere. There could not be a moment in history where we need more valuable fundamental infrastructure, fundamental as in the drone project, fundamental as in the hospitals and health centers. And you've been involved in many of those. You didn't have time to talk about it. Why is it going a bit beyond your developer conversation that money is not being channeled into exactly this meaningful necessary infrastructure? What is happening out there whereby the investment is not happening? Is that a political problem? Is that a risk averse problem? What is that? I never think it's about money. I think it's about attitude of mind. That's as simple as that. And if you take it out of infrastructure and you use the metaphor of making a building, there are some countries where you will pay a price for doing something. They'll do it once, they'll do it well, and that's it. And there are some countries where you'll never get it right and in between there are some countries where you do it two or three times before you get it right. Which is the cheapest, most economical, high-value route? It's doing something, doing it well. That's value for money. It may be a higher or lower first cost. In my experience, it's never about money, it's always about attitude. Some of the best buildings that I know are essentially low-budget buildings. Since Stephen's war broke, Ren was on a shoestring. There were very, very few things he could do. What he did, he did very, very well and just sacrificed himself. The big church in Covent Garden is a great barn of a building, has a super sort of facade. I think it's not only about money, but I think that when investment flows around the world, development becomes a simplified process. It depends on people who are sitting in a bank in Shanghai understanding the proposition of development in London or in Mexico or in Moscow and that tends to default to simple basic solutions. And those things simplify cities. Cities are not simple things, they're complex organisms, but if you start to simplify them too much, then they start to lose that sense of essential urbanity. Right, let's use the last 10 minutes to have some questions. Being the London School of Economics, there's a well-known tradition. We ask you to say who you are, wait for a microphone and don't make a speech. Ask a question and what we will do is take four or five of them and then ask Norman and Dan to, in a way, respond to those that capture you. So lady over there on the right-hand side. My name is Susie Hall and I work at the LSE. I'd like to ask what kind of political courage and optimism is required to take or reimagine social housing in London seriously? So we'll just go through a few. Gentlemen there, third row. So yeah, say who you are please. My name is Merlin Fulcher and I'm with the Architects Journal. I'd like to ask Norm Foster, would you support Jeremy Corbyn's idea of people's quantitative easing if that could be used to direct infrastructure investment towards projects for social good? And also projects like your own Estri Airport, thanks. All right, right in the middle. Gentlemen there, I'll have you take a few more and then... Jason Sayer, Architects Newspaper. Cities such as Oslo have since become car-free, juicy London and other European cities following the same suit. I didn't fully understand that. Could you just repeat it, sorry? Oslo City Centre will be car-free in 2016, according to their current mayor. Juicy London and other European cities following the same path. So in terms of car-free. So way up at the top over there. Philip Abarth. I was interested in this comment about the idea of planning and doing things by improvisation, maybe multiple times or doing them properly once. Can you comment on how the speed of infrastructure development might have to change with situations of crisis or emergency such as, for example, the influx of refugees into Europe at the moment? Dan, you want to touch on a couple of those questions? No, I'll leave it to Norman. I'll leave it to you. No, it's okay. Andrew. Well, taking the question that was specifically directed at me on quantitative easing, I'm not the person to ask about that. I'm not an economist. So I guess it's intuition, and I'm not a historian, but I think there's a link between inflation printing money and living outside your means, whether that's a nation, a household, or an individual. I just intuitively, and I don't think there's a connection between the need for affordable housing and quantitative easing, which is a euphemism for printing money. I would have thought that with such a land stock within the ownership of local authorities, that there could be a mechanism whereby a certain proportion of that would be sold at a rate which had conditions attached to it in terms of the way it would be priced on the market and another proportion that would be made available under a different system so that you could use the regulatory powers of those who sell the land to sell them with strings attached so you could address the issue at every level in society. I mean certainly we do have a housing emergency. It's a similar problem in other majorly successful cities. If you talk to people in San Francisco, Los Angeles, they have some of the same issues that we have in London, which is unaffordability, people buying housing as asset classes, and that might have something to do with quantitative easing as well when you have zero interest rates, then of course housing as an asset starts to bubble. But there is something really disheartening about London and the UK in general, which in the 1960s could build 400,000 houses a year for a smaller population, about 50 million then. We now have 10 million more people and we simply can't manage that. It's partly about the market. Market housing does not really prosper on building large numbers of housing units quickly. It depresses prices until now governments have actually also discouraged the local authorities to build more and I would certainly think that that needs to be altered. I think there is a, if we can manage transport for London to do one of the best mass transit systems in the world, there's no reason why Britain can't use some of those techniques and skills to address its housing crisis. Just on note, do you see London becoming more car free over the next generation years? Absolutely.  And we're now at that tipping point where, I mean, the conflict between cycling and motoring is now at a critical point. But I think that as cycling becomes safer, it starts to take more cars off the road and I think we're at a tipping point there as well in the way that London functions that way. Maybe also the car may morph into something else. It may change its nature. The ability to perhaps with robotic potential for cars to be nose to tail like a convoy to reduce accidents. The drive becomes leisure time. The car is on autopilot. It's following the same pattern which has evolved in the airways, in the aerial highways. And that could give greater saturation of a road system. It could change the perception of suburbia. It could avoid more road building programs. And the aircraft themselves could also change. The largest regional carrier in America, which is Cape Air, in terms of its orders for new aircraft has gone totally electric. I'd like to try and capture and maybe conclude with some thoughts on the tool. Let's call it social questions that were framed a moment ago. When Norman, you and I talked about inviting you to speak at the celebration of the event, said, well, what might we talk about? And said, you know, design infrastructure. And I think you became very interested in the notion of social meaning of infrastructure.  And in hearing what you said and also what Dan was talking about in terms of the reactions to some major events in the 19th century, in the mid 20th century, or as has been referred to now, you know, a very real problem. Do some ideas actually come out of these shocks? Do you need something to completely throw things around, to change the paradigm, to question what you're doing also to consider what the value of architectural infrastructure is? And I think it would be interesting to just reflect on that, Dan. Sometimes you do think that there are very few basic ideas about the city. It's high density or low density. It's, let's say, fair or it's control. There's always this duality between the two. There are, I think, speed has impacted. I also keep going back to one of the ideas that Saskia Sassen had in one of the earlier sessions of the urban age, where she came up with this idea of sittiness. And maybe these urban agglomerations that we see everywhere have greater or lesser degrees of this sittiness quality. So the edge of Brazzaville is a place in which rural Africans have migrated and live on market gardening. So it's urbanism that's actually bypassed industrialization. Does that have a quality of sittiness or not? I'm not sure, whereas in the Western world, perhaps we start to leech out this quality of sittiness as cities become oversimplified or the grain loses. Maybe we lose that and maybe the most essential quality that we need to really nourish and nurture is sittiness, whatever that means. So what is the infrastructure of sittiness, Norman? I think it's all the, in a way, I suspect, if you wind back decade by decade and you had a gathering like this, there will be a certain rhythm to it. You would hear the same elements being protested and the city would be responding by changing, by morphing. Some areas would be going up, some would be going down. I remember with Elena, we traveled to China to meet with artists who, some of whom are household names, Ai Weiwei in the Royal Academy, totally unknown, then saw the areas that they had led and transformed, rather like Soho, and then saw that those areas became popular, gentrified, 9-11 in Beijing, and they move on, colonize, it's not affordable, everybody's protesting. They move on, they find another place, and it's that kind of those waves, the chance things. I mean, the ideal city, I mean, in London, I don't think it's ever been better than it is at the moment, all the problems not withstanding. It has an extraordinary vibrancy. For different reasons, other cities, Madrid is an extraordinary city, Berlin is an extraordinary city. They all have their own qualities and identities, and thank God for that, there is a there there, there are differences. Well, it's clear, just by referring to these cities and their different characteristics, there's much more for all of us to do, just in response to the question about the refugees issue, we've spent the last five hours with many of the colleagues sitting here in the front rows of the urban age, really saying we don't have an answer to that question. What are cities in Europe and elsewhere doing, even though, as the mayor of Washington City reminded us, it's the city that's the front line. It's national policies can fail, international policies can fail, but it's the city that has to take it all in a way. So I think that is an issue that generations of urban age and the students who are here and fellow city makers will need to take into account. But in the end, it's the environmental and the social meaning of infrastructure that needs to be understood. And I think tonight, Norman, you've given us great insights on that. Diane, Norman, thank you very much.