Good morning everybody. How are we feeling on day 3 of Vancouver and Vancouver ODS? Good parties last night. Thank you HB for the great party. Also at the Intel. And as I said this morning to a couple of colleagues, friends don't let stackers turn up the day 3 or leave the hotel without your part. My roommate let me let you leave the hotel without your part. Okay, we have got a whole day today of news about what we're doing in the OpenStack community here at Ubuntu. And to kick us off we're going to be doing a session on Lexi and KBM. But I just want to do a quick show of hands. How many people in the room have apparently got OpenStack in production? That's fantastic so almost half the room. How many people here are using Ubuntu OpenStack or Ubuntu as the base to their OpenStack lab? That'd be shy. That's about half the room. That's about right before expecting. The data was out on Monday. 55% of OpenStack deployments have now been done. On Ubuntu having told to talk to a mic. 50% of OpenStack deployments have now been done. On Ubuntu and critically so many of the large clouds. And if you were there on Monday, Comcast, Walmart, digital film tree, all talking about how they're using Ubuntu as the base for their OpenStack deployments. So it's great to have you here for what we think is the biggest breakthrough in virtualisation since virtualisation started. And I'm going to hand over to James and team who leads our OpenStack architecture at Canonical to talk through Lexi and KBM and why we think this is so exciting. Thanks, Chris. Can everybody hear me okay? Okay, cool. Excellent. So let me just get set and then we can go. Technology is already failing me. There we go. Right. Okay. So just quick introduction as to who I am and who my colleague Ryan is. So my name is James Page. I'm a technical architect of the Ubuntu OpenStack team. I've been with Canonical for about four and a half years now, but I've been deploying and working with open source technologies for about 15 years in fairly large enterprises before Canonical. I lead the team who's responsible for all of the packaging that you use for Ubuntu OpenStack and for all of the charms that we deliver for deploying OpenStack using our Gigi service orchestration tool. I'll hand over to Ryan to introduce himself. Hi, I'm Ryan Harper. I've been with Canonical for about one and a half years on the Ubuntu server team technical lead there. And prior to that, I was at IBM's Linux Technology Center, and I've been working on virtualization, open source virtualization for about 12 years there. Okay, so before we dig into some benchmarking figures that Ryan's going to run us through, I'm going to take you through our products and around containerization and the work we've done in the last six months since Paris when we announced LexD, our new Light Advisor product. So what's LexD? LexD is our Light Advisor. It's designed to run full machine containers. So we're differentiating from things like Docker and Rocket, which are very much around running process-based containers. It's a full machine container, and I'll dig into that in a little bit more detail. We're very much targeting getting close or bare metal performance for those containers. So it's a little as possible between your workload and the underlying hardware you're running on. That allows us to achieve some very high density figures for the number of containers you can run on a certain specification of hardware due to a very, very small overhead for each container. So let's dig into what that machine container terminology means compared to process containers in a bit more detail. So in the slide I've just popped up, we've got a host machine, either bare metal or KVM. We'll talk bare metal for purposes of this talk, but we've got a couple of containers deployed on it, and each of those containers feels very much like a full system. So they're running a standard, trusty or vivid Linux image. You've got init running, you've got cron, syslog, you can SSH to it. It feels very much like a full virtual machine that you would get under KVM. And that's the parity we're looking to achieve at LexD. We're not trying to compete with Docker, and in fact it can include Docker within that. So it's perfectly feasible to run a number of process containers within a machine container and have a level of nested containerization to give you more flexibility if you want to do that as well. Okay, so kind of digging into LexD features in a bit more detail. Some of you may have seen my colleague Tyco's DOOM Live Migration demo from Paris, where he live migrated a running DOOM demo between machines. And we've been doing quite a lot of work on that in the last six months to leverage CRIU, the Checkpoint Restoring User Space Toolset to perform smooth, fast and reliable live migrations. There's still a little bit of work to go on that, which I'll touch on later in the talk. But if you haven't seen that demo, please do go down to our booth in the expo hall where that's running all the time and you can see the fantastic DOOM Live Migration running. We've got a real strong focus on security. So by leveraging a number of security technologies, we're able to deliver unprivileged containers. So these are containers where all of the processes within that container are running not as root. They're very important in terms of the security around our container architecture. So by doing that, we're able to provide an increased level of assurance that if a golfer bid, a container breakout, did happen, then that's as an unprivileged user on the host. So the impact of such a possibility is much reduced. But to kind of beef up around that, we're leveraging a number of well-known technologies. App Armor in Ubuntu is very much used to enforce security about what the process is within a container, a running container can do on the host OS. And we're working with most of the major instruction set owners in terms of enabling hardware assist for container security as well. That's not something that's generally available, but as and when it becomes more consumable, that's something that we'll be delivering as part of LexD. So touching on another couple of things, networking and storage. So the approach we're taking with LexD is basically if it can be presented on the host, we can plug it in a container. So we're not doing any heavy lifting in terms of integrating with something like OpenVswitch or any SDNs or specific storage solutions. We're taking the approach that if you can present it on the host OS, it can then be consumed within the containers that you're running on top of that OS. So we're avoiding the heavy lifting in LexD. Fortunately, we have quite a well-known cloud product, which does a lot of that for us. So this fits nicely alongside something like OpenStack to provide the networking and storage components into a container architecture, which leads me quite neatly on to the other project we've been working on in the last six months, which is our Nova Compute LexD driver. So this is a drop-in replacement driver for, say, the Libvert KVM driver that allows you to manage LexD containers in an OpenStack cloud in a very similar way to KVM instances. We've got a technical preview release out with our Agunti 150.04, which came out last month. And in that, we've got some support for fast root FS cloning. We run everything by default as unprivileged containers to assure a level of security. We've got a base level of neutron integration with the ML2 OBS reference implementation. We're fully integrated with Glance, so you can store your LexD root tables in Glance and use those across your cloud just in the same way as you would do for Libvert KVM. And we've enabled support for LexD in our GG Tom for Nova Compute, and it literally is just a single config option to switch between KVM and LexD as the two options. And that allows you to deploy an entire OpenStack cloud using LexD containers underneath the hood. Okay, so I'm going to have you have to write now. I was going to walk you through some of the detail of containers and some of the benchmarking we'll be doing. Thanks, James. So what is in the way of the workload? Let's get started on that. So what we have here is kind of a layered picture showing how we're stacking things together. We've got our physical machine, you boot your Ubuntu Linux kernel, put Ubuntu Linux on top of it, and on the left, if we start up a KVM instance, virtual machines are meant to look very much like bare metal, and so they have all the same things that your bare metal system had. It has a BIOS. It has a bootloader. It's going to load its kernel, and it's going to run through its operating system, user space, come up, and then you get to the point where you can run your workload. There's lots of extra stuff that happens to simulate that machine. In the kernel, it's still probing virtual devices, emulated devices, doing all these things, and that has to happen because it wants to behave like a real machine. In LexD, we don't have any of that. The containers run as processes directly on the host, as processes. We do go straight to init, but we don't have a BIOS. We don't have device drivers or things like that, so that makes things a lot thinner. So if your application is running in the virtual machine, a couple things have to happen before it starts to run. When your application is running, the virtual processor in the KVM needs to schedule your workload process. The host itself needs to schedule the virtual processor to run as well, and so a lot of this introduces just extra time and latency and overhead to actually running what you need to get done. So there's a couple of interesting things that happen on large S&P guests, as well as overcommitted hosts. The host operating system in the Linux kernel has to help provide some switching between all these different virtual processes. In the pure virtual machine world, we talk about a problem called lock holder preemption, where your guest OS is holding a lock while your other parts of your workload may need to do some work, but it's not actually being scheduled by the host.  The Silicon vendors have introduced features to detect this particular situation and tell the hypervisor, by the way, you're not going to get any further with this particular one. Why don't you schedule something else? So for lexity, this is not a problem, and without having lots of extra layers of resources being occupied, that leaves lexity to do things quite well. Let's look at that. So density, just from a memory footprint perspective, we don't have all those extra stacks in that layer in that picture, so we can put a lot more of these machine containers on the same system, and this means that we can do more with the hardware that you have. You can pack more into there. This increases our utilization. So in Tudor, we kind of knew this. Containers aren't as heavyweight as virtual machines, but we really wanted to kind of take some time and say, well, let's put some numbers next to this. And so to get a real number, we took an Intel server, 4 core, 16 gigs, pretty stock setup, and we set up Ubuntu Linux on it, and we decided we'll launch KVM instances with Ubuntu server image, and we'll do this until the hypervisor is out of resources. In this case, the one that we're most constrained with is RAM. So we'll do that, boot up as many as we can until we can't anymore, record that, and then we'll do the same thing with lexity using the exact same image, but using the lexity virtualization technology. So let's take a look at that. On the left, we launched about 36 containers. This is another run where we got a few more. And that was what we expected. These were 512 megabyte virtual machines. They boot up in KSM's active and doing some work to deduplicate pages. But at some point, just all that overhead that happens, these are all full guest OSs with that big stack, or that big stack that's got everything in there, it just takes up space. So we rerun with lexity's basically exact same experiment, but with containers where each container, machine container just has dramatically less memory foot from each one. And so with that, we had a dramatic number here over 600 of the same Ubuntu images are running on this same server. So that was extremely impressive. Now, we saw this and said, this is really good, but let's take this and put it in the context of the cloud. So if I can take a single server and stack very, very, very many lexity machine containers, and then for the cloud, that means we should have some significant density. So we built a 10 node open stack kilo cloud on Intel servers, a little bit bigger. I think there were six cores and 48 gigs of RAM on them. And then we ran in a converged architecture, so a lot of the infrastructure was housed on some nodes. And that gave us about six compute nodes for us to run this experiment.  So let's look at where we got. Now, some explanation for the graphs. These are ganglia monitoring graphs that we grabbed while we were running a boot test. So we just kick off a Nova instance and keep it going and just keep it going until the cloud kind of falls apart. The blue in the charts represents committed memory. So that is memory that's been allocated to the, from the host perspective, it's allocated to running applications and processes. The green represents cached memory, buffer cache, page cache, things that Linux does to speed things up for read and write operations and things like that. And there's one more color, purple, on the lower right on KVM indicates swap. So that's when we started committing memory that's not being actively used and touched into swap. And things get noticeably slower when we get in there. So on the KVM side, we had about around a thousand instances or so is when we kind of hit the red line in there and we started getting into swap and it continued to swap and we committed another, I think it's another 48 gigs or so above to get that last remain. And we started swapping when she said, all right, we'll kill it now. We can't get any further with that. And we re-ran with LexD. And as we were getting up, I think it was around, it was about maybe 1,200, 1,300 instances. You know, we're steadily increasing and it was good to see this memory footprint where we have tons of green just as we have a huge amount of headroom where we can continue making containers. And we kind of, we flat line for a little bit and you may be able to see under the 1,800 there's a bit of a flat line and the benchmark came back and said, I can't allocate, I've got a resource problem. And I said, well, I'm looking at the chart here and it's like, there's plenty of RAM left. So I was talking with James and said, what's going on here with this flat line? What was happening? So it turned out we'd hit the scheduler limit. So the scheduler was saying, actually the compute host has got no more memory. So the default RAM and memory allocation limits that we ran the test with weren't sufficient to deal with the density of containers that we could get on each compute host. So we actually just twiddled those knobs, increased the over commit a lot so that we didn't hit it again and the cloud started creating instances again. So it just shows that the difference between, you know, we didn't hit that on the KVM test. I think we probably would have seen it at about 1,400 instances with the configuration we were running. But we hit that relatively rapidly with the container test and we just had to tweak that up and allow a higher level of over commit on each host. So once we fix the over commit ratios and set them rather high from 1,000 or something, just keep on going, it continued to climb on the web. We ended up cutting off about 1,800 instances or so as the infrastructure, the convergence for structure was just making the spawning really slow. And so I think we've covered in the picture kind of shows exactly what we wanted to show in terms of how frugal LXD is with memory resources. So another feature, something that matters is startup time for developers, right? If you're iterating on a project or a workload or whatever, you can go through your workflow faster and faster if you're not waiting on things to happen. I mean, how many people have rebooted a physical machine and you're waiting for the five minutes for the enterprise firmware to finish probing devices just to get to the boot loader and run? And virtual machines are certainly faster, but LXD, remember that picture that we drew, we don't have that virtual BIOS, we don't have another boot loader, another kernel to load and run, we're right into the workload immediately. And so this means startup time is dramatically different. So LXD launched Ubuntu VM1 1.5 seconds and we're in, we're running, right? All the processes that you saw earlier are already going. You can SSH in, that's there. For the same KVM instance, you've got to go through all those things in that stack to get all the way up and finish it in it and then we're in there. So that makes a big impact for workflows. And so if you recall, the first density test that we did, we took some, and you look at this startup time, we went back and looked at the time it took to do the density run. So when we launched the 36 or so of the KVM instances, we kept how long did it take for us to actually get that far. And then for the much higher, you know, over 500 for the LXD containers, we looked at the time it took to get there. So the same server launched our 37 in 943 seconds and then when we launched, it was amazing to see that we had launched more than 14 times the number of instances, but in less time, about 20% less time than KVM. So startup time matters and the density matters, and that really combines some powerful technology. I wanted to talk about another LXD feature when you think about that stack and how thin it is and what this enables. Latency. So latency is important for many workloads. So telcos are very much interested in reducing amount of time it takes to respond for message passages and things like that. You know, even in an open stack cluster where we're sending messages all across the bus, latency can make a tremendous impact on the speed of your cloud and how quickly you can react. So we did a benchmark here. So we looked at the ZeroMQ as a latency benchmark, and so we set this up. The remote latency setup here is two KVM on the top. We have two KVM VMs running Ubuntu. They're on the same host, on the same software bridge. And the test itself sends one byte packet, a million of them, and then averages the latency across at the time it took for each one of those as well. And in this case, you know, one of the KVM guests, when the test start, needs to send the packet. This is going to go through, you know, the networking layer of our own net. It's going to go down into the host, take the packet, goes to the bridge. It's on the bridge, comes back up into the other guest. It has to wake up and be scheduled and picked and then sent into the user space, and then you get a response. And so that can take a long time. Exact same setup with LexD, two container machines on a shared bridge, running exact same test, and we're over 50% less latent. And that's just, there's not as much in that stack that we have to go through, which means that your applications can communicate at a significantly faster. The other test here, the local latency, takes the software path, or the networking part of the path. It's just the application talking to itself into threads. And it was interesting to see, the local latency on the bottom looks to me, scheduling latency, right? We have two threads inside your virtual machine that need to be scheduled and context switched between. And we see a lot of the, you know, context switch overhead that you'll get in a virtual machine when we have to do VM exits or you've got two schedulers and you've got to make sure that it happens quite right in LexD containers. We don't have that extra layer or an extra kernel or extra scheduler. It's just the same, you know, processes on the host. And so we saw the same 50 plus percent latency improvement on there. So before I hand it back, just wanted to cover some of these key benefits, right? So you think about that picture about how much we're taking out, but still giving you a full machine container and delivers, you know, these key capabilities, right? Density, right? We use less memory per system than you will with the KVM machine. That means you can stack more things together. Startup time, so your workflow, how quickly you can run through things, how you get through these processes has a significant impact on workflows. And finally, latency, right? These, for folks who are interested in high-speed workloads that require very quick response times, getting that, all that stuff out of the way of your workload means that you'll be able to get more of what you need done faster. Okay, thanks, Ryan. So as I detailed below, we've got a technical preview release out with our Ruben 250.04 release.  We're obviously not recommending this for production use yet. We've got a number of features that we want to work on and implement before we're recommending that people start using this stuff in production. And our target there is really around our 16.04 LTS. So this time next year, we'll have our successor to trusty out for 16.04 in April. And we're aiming for a rock-solid container story with OpenStack at that point in time. So test now, give us feedback, tell us what's rubbish, what's good, and we'll definitely work on the results of that feedback. But in terms of what we generally got on the roadmap, we have an integrated roadmap between the Lex-D team and the guys riding the Nova Compute Lex-D driver. And we've got a few things that we're targeting over the next 12 months. So full block device support to allow better syndicate integration is top of the list right now. We're not able to directly present a block device into a Lex-D container right now. So we can't, for example, provision a SF RBD volume and then map that into a Lex-D container right now. But that's something that we feel for kind of parity with KVM and Libvert. That's something we absolutely need. So that machine container experience feels the same for Lex-D and for KVM and allows, you know, a much more comparative feel to the solution. So that's a high target for us. Broader Neutron SDN support is part of our work in the OpenStack Interop Lab. We're working with a number of SDN partners, all who have expressed interest in Lex-D and helping us enable their particular SDN in Neutron to work with Lex-D containers. So I've got a series of work there to enable things like contrails, stuff like that. Broader image format support. So Lex-D is currently constrained to using a root-table format which, if you use a cloud regularly, is not what you use. You're typically using a raw image or a Q-Cow or something like that. Lex-D itself is going to be growing support to support a wider range of formats. So we'll get that natively via Lex-D. So if you're using Lex-D standalone or as part of a cloud, you'll be able to use the standard Q-Cow2 image that you're familiar with using with Ubuntu on KVM but with Lex-D containers as well. We alluded to this during the performance management we talked about, especially around density and the fact that we hit the scheduler limits pretty quickly with containers. So resource management and usage reporting back into Nova is, again, another key focus. So figuring out how we represent the lighter footprint of a container back into Nova and how we manage that more effectively. So how we limit a container to, say, only being able to consume a couple of cores or a certain percentage of the memory of the host. There are all features that are coming in Lex-D to be able to constrain containers and have a container know it's only got a certain footprint. It's only got two cores. It's only got half a gig of memory. That's a feature that isn't in Lex-D in the compute driver right now, but that's something that's coming over the next two releases. And full live migration support. So we can do live migration now. There are some bits that don't get live migrated, mainly the security bits. So Tyco's been working on that to make sure that when you live migrate a container, the security around it also gets live migrated as well. So that's the broad roadmap we got between now and 16.04. I hope you can see how we've come in the last six months to have an initial product for our 15.04 release and where we're going in the next 12 months. It's pretty exciting. I think it's a very compelling story, especially when you start looking at the latency figures that Brian highlighted and how much closer you can get a workload whether that's a virtual network appliance or a big data workload. You can get it right down next to the bare metal and get about bare metal performance, but still have the usability of a cloud-like open stack. Okay, so we've got 10 minutes or so for questions. I'm hoping there might be some. So if anybody wants to ask a question, we've got some mics. I can see... What are the guest OS limitations? So right now, if you want to do anything that requires interaction with the kernel from within the guest, you basically can't do that. So running something like OpenVSwitch within a container is not possible today. I think we're going to look about how far we can push that limit. So there is always going to be some limit on a container compared to a full KVM, because you don't have a dedicated kernel. So it's sometimes not safe to permit those operations from within a container. So that's one key difference. I alluded to the fact that we can't do block devices yet. That's another key difference between containers and live at KVM, but we're looking to plug that gap. And I'm going to look at Tyco now, because I'm sure he can think of some more. Tyco, do you want to cut the front, and then if there's any lexity questions, you can answer that. Yeah, so it's Linux-only guest, so of course you can run a Windows image under KVM on top of an OpenStack Cloud. You can't do that with containers. It has to be something that will run on a Linux kernel. So you could run a CentOS container. Obviously you're going to get the Ubuntu kernel still. You get some propagation of the hostOS kernel down into the container as well. So there's some considerations when you're deploying that you need to consider. Right, another example of an operation. Hello. Another example of an operation that won't work is mount. Right now the superblock parsers in the kernel are not considered secure. And so they've never had to not trust what was on the superblock to begin with. So if I'm a bad user, I can craft a nasty superblock that will exploit some buffer overflow in the EXT4 parser and then I have kernel access and I can do bad things. So we don't trust mount right now, so you have to ask LexD, can you please mount this block device into the container instead of actually mounting it yourself? And there's a lot of tap dancing you have to do to make sure that the user, the container has never been able to write to the block device before it gets mounted because if it has then they can write the bad file system and bad things happen. There's a lot of kernel stuff that's, I think, unexplored and we're also interested in looking at that work and making sure that is all safe and secure as well. So I've been looking at KVM performance and density for the last few months. I get very, very different results. I get a KVM guest starting at about 150 milliseconds. I got density similar to yours. Have you looked at improving KVM in your OS? So these are out-of-the-box numbers, right? I think that's the most important part. You install it and you have it, KVM. You've ever seen the QMU command line or whatever. It is sort of infinitely tunable. So there's lots of things that you could do. There's always a trade-off in those places. So you certainly can trim a lot of that stuff and do it. The question is, do you want to do it everywhere you go? Right? Do you control the KVM or kernel or whatever in the cloud or whatever? Can you control those tunables in open stack if you're consuming it? But you get 10 times faster like Z, right? So because you get 150 milliseconds boot time, you get the same density as you get. So but with all the advantages of... So there's a difference between the time it takes for the processes associated with the KVM sentence to be active to the time when you actually have a usable system and that's a significant difference. I know what I'm talking about. Full hypervisor and full guest OS boot, right? That's what you measure as total. Yeah, that's what we've been looking at. It's time to use of all rather than time to active, if that makes sense. Yeah. You're looking at the same thing, right? All right. Could you talk a little bit about the user space management tools like LXC or Libvert or Nova API? Right. So let me talk a little bit about the Lex... LXC. So LexD is a REST API web service. And then the command line that they have, LXC connects to that and provides a very straightforward interface. So LexD for different operations, image import, update, alias creation, profile settings. But it's all done via REST API. So even the command line client is stalking REST to that. So that makes the integration in LXD it's using the exact same API to define and create and everything. I'm still trying to understand why I would want to use LXD versus just running either Docker or system dns. So the graphs and images that you showed, Docker have shown them in the past, etc. So that your density aspect is no different to running any other container technology. But I need to add an additional demon in there. So this is the difference between machine and process container. You know, Docker is playing very much in that process container space and that's great. And yet the density figures will look very similar because it's all using the same underlying kernel technology ultimately. What we're aiming for is this, you know, the full machine container. So if you have workloads or deployment techniques or whatever it might be that, you know, work with KVM and full machines right now, we're aiming to make those directly transferable without having to rearchitect to something more process-centric, but still be able to leverage all the lightweight container technology. Does that make sense? I think I understand what you mean. So a full software stack that condenses into a single container rather than running on a VM. Yes. There's some more questions here. It's, yeah, you can't run a custom kernel in the container architecture. It's just not feasible, but, you know, we're very much targeting that space between process container and, you know, we're aiming for the full machine container here. So, yeah, okay, yeah. That's close to full machine you can get without having a separate kernel. Yeah. Neutron. What's this? Sorry? What's your current state of integration with Neutron with this? Absolutely. So if you're running the Neutron ML2 OBS reference implementation, that 100% works with LexD with the Nova Compute LexD driver right now. Do you guys have any capability to guarantee, so you guys show that you can overcommit, like no other, but can you guarantee RAM resources or something like that? Yeah, and that kind of fits into the resource management part of our roadmap. So it's about ensuring that, you know, a container that's of a particular flavor type, so, you know, either a single core or a certain memory configuration can only consume those resources on the box and no more.  So there's a balance somewhere in there to getting your overcommit ratio right, and once we have the features in terms of limiting CPU or memory usage for a container, then that becomes a much more integrated solution, which we should feel much more familiar from initial operating Nova with KBM. Question on the block storage integration, what's the timeline on that? So I think that's part of our 1510 plan, so that's within the next six months of development, so between now and October. So hopefully buying Japan will have a good story there. Is there a beta access? I can get early access? Not on the block storage yet, all of the Lexity and Overcommit development is done in the open, and we have a PPA for that, so yeah, you can track it. If you're willing to build from source with a whole tree, the Lexity tree is open, so you can get it as it comes in. Thank you. Questions about using a different type of OS, like can I have cores running in the container? In a Lexi, it's not possible. So you're limited by what you can run on top of a Linux kernel. So CoreS is Solaris-based? Am I on the right operate? No, I'm not. I don't know. If it's Linux, right, it can run in there, right? If you're not dependent on specific kernel features or whatever, but any other Linux Lexity you can run. In Lexi, there is a problem, right? We cannot run Fedora and Mejo and Ubuntu and stuff like that. Sorry, I didn't catch you. Can you speak up? In case of Lexi today, you cannot run a different version of Linux on Ubuntu. There is some file system incompatibility. Sorry, you can't run a different version of Linux, meaning the Linux used like... I can run precise on trusty. Is that... Yeah, he was talking about Fedora. As far as I know, those work as well. If you have an issue, go ahead and file a bug, and like Theo will look at it. That should be supported. Intel announced a clear container, I think, technology. How is that different from Lexi, both technically and in the marketplace? So they're using, I think, VMs, but calling it containers. They just have tuned down a lot of the VTX stuff. I mean, they are the guys who do this silicon, so they really know how it works. How it's different from Lexi is we're still using the traditional kernel virtualization like namespaces and things like that. I think the biggest difference, I guess, is that they probably can't nest, because they're using VTX and they have these sorts of restrictions. It's just KVM. Right, yeah. So it's just KVM, but super lightweight, I guess. They've done a lot of optimization. A question. What kind of hardware assist are you looking at? Hardware assist? It's working with the silicon vendors to, you know, it'd be in the realm of the VMX VTX, those kind of protections that they're using. We have to be hand wavy, I think. Yeah. Any other questions? Yeah, I mean, there's quite a bit. So some of it could be virtual BIOS or whatever. The standard BIOS, I think, it's got like two seconds that it waits no matter what. You can turn it off, but you have to tune it. You're loading the kernel. I don't have the histogram to break that down right here, but it's definitely there. The big rest of the time is all that, you know, once we're through the kernel, we've done device probing. Then we're getting to a knit and a knit spawning, you know, lots of more stuff to deal with. The fact that it has hardware, whereas in the container, we don't have a lot. So we go, you know, we're exacting a knit directly, right? And then system despawns in parallel. We're done. Yeah. You can tune it down. You really can. We were going for out-of-the-box numbers, right? You know, install the package, run the commands. This is what you get. Well, so today we support things like just, you can feed us basically a tar file and it has a little metadata file in there that describes the personality and things like that. That the tar file expects. And I don't know that we have any direct plans to build something to generate those tar balls for you. I think if you like Dockerfiles or whatever, you can generate that tar ball however you want and feed it to us and we'll be happy to launch it and use your username spaces and do all the security for you. Well, so we're going to distribute, you know, the pre-built Ubuntu system container images. And that's basically because we think that LexD is best suited for system containers. I don't think we're competing with Docker and so I don't think we want to get into a, you know, they have a really great story for how to build images and how to share images with people. And, you know, that's very useful for the app container case for a system container where it's, you know, I don't want to have anything pre-installed, you know. I just want an Ubuntu and I want the Ubuntu that the Ubuntu people say is Ubuntu. So there's not a lot of image manipulation that needs to happen there. So I think for our use cases, it's not critical. However, we do have this API and you can feed us a tar ball that was generated however you want and we'll run it in username spaces for you. So... We're about out of time. Sorry. We have to wrap up now. Does any more question? Yes. Feel free to come up. For the break. Yeah. Yeah, thank you. Great talk. Well done.


Hey friends and welcome to my channel I am Yoshida and this is Norris Cove I've been wanting to get back to my budgeting it's imperative that I get back to my budgeting but I'm trying to also budget in my B6 I do budget in my B6 but I wanted like a monthly kit for my B6 so I just cooked up this little kit I was trying to make a duplicate because I have another insert coming plus let me see if I can find what I just bought and I got these from Staples they're like inserts for a traveler's notebook I didn't get a size it do kind of fit here in my B6 as you can see but it's just a little wee bit too big but it's fits but I got this as a backup after I get my insert from 1407 planners this basically like this so I want to start with the mini first already had this here this is a new section so I just want to see how it's gonna go this is the mini kit that I made this is the full kit I'm not liking how this come out for some reason I just cannot remember to how to offset my words but it has variable expenses fixed expenses some washy thick wash with weekly check-in the month of July income budgeted expenses budgeted total expenses couple total boxes item descriptions bill do stickers I used to have like 28 bill do stickers I cut those down made these little small boxes for a month like monthly boxes for you know TN and then these monthly boxes here then we have our categories as sinking funds baby steps goals income cash envelopes and another thick wash sheet and then we're back to the mini is this the mini yes this is the mini so I want to start with the mini I'll probably speed through it I just want to show you guys how I'm planning to budget in my b6 so let me get to the front okay you all so I'm finished let me get this out the way all done now I did have a little mishap here on my weekly check-in it broke up and weekly check-ins is what I really really need so I'm going to pull out my b6 pull out all my bills I'm gonna put them here I have them in the month view I'm going to put them in this view so this is just like my estimated income I needed to make two of these so I wanted to do this for my b6 so I could just see exactly how I would use it but this is how I decided to use it and for my weekly check-in I need to make an income and estimate actual I know that it's income so I'm just going to write it in income estimated and then plus or minus so and then I need another banner here so that's something I need to add but I was so eager to get this kit up and my measurements were like one point I did have to trim this down a little bit but only because I didn't take it to the edge here so I need to work on my measurements there but so my estimated income for the month I'm just guesstimate and I'll later come back and see I actually do that wrong that's the guesstimate and that should be here and so my expenses I always start with the ones that I know first which is my car note it is 363 I don't know the change but we're gonna put 363 I pay that twice a month car insurance life insurance they're the same here lately it's been 219 I will see I should have put a date on that sale bill that sale bill Lord only I'm gonna put down to 50 that's my budget for that then I'll go into the smaller things schedule the city that is $20 then I have a flat that's $30 Amazon that is 12 Apple is only 99 cent I have a capital to one minimum is I'll put a hundred but my minimum is 25 and I'm actually giving them $200 this month car insurance life insurance sale bill simply gilded I'm only gonna get maybe one or two more simply gilded boxes and I'll be done I'll get off of those before Christmas I enjoy the pants I'm not going to rely on the gym the gym is like $19 but that's 20 it's like 1999 way fair but wait for a car but I don't think I own anything for this month so I'm not gonna put that down Amazon Apple sale payment oh my other car I just put hubby we have a little personal on that and I give a hundred towards that my booth grant that is $840 I think I'll just see how it goes so the first week I just made income from here so I left it small here I was estimating 700 I did 980 so I was up 280 a second week I didn't write it down in here's in the other one it was only hair so about my air and condor like I said I keep my budget in so many different places it was 13th 13th I really didn't have a budget and put the hundred and it was 1777 and that's actually including a loan so without the loan it wouldn't have I just included the loan as a income because it was income for me so that is my July budget so I've been keeping track of how much I've been spending so I think that's where my variables are going to go let me also show you how else I keep my budget six so this is like my daily sales I have a decorated as you can see so this is for the month of July I just write down what I make every day so it's like I said it's in several different places and then back here it's kind of we I was budgeting so I just write everything down and then I just cross it off as I pay it but I'd like to see it in this form because I was gonna get the air and conjuring petite planner and I was like man I really want that I think you know it's just like my air and conjuring deluxe and I can use that but I just didn't want to buy a plan I mean a cover for it so I'm gonna slide this in here and then I have some build-you stickers here I'm gonna they don't match my little spread here but and I forgot something on the 19th it probably it doesn't fit but it's okay I need to make those a little smaller so that is if I'm gonna perfect that kid because I really like that and I like having it I wanted to put it closer but I like having it in my b6 I do with it lost it already okay here we go so I like having it so like I said I keep my budget in several different places so that I can do better with paying my bills on time but I just wanted to have like a kid inside of my b6 besides monthly that I get from Nikki plus three and I'm debating if I'm going to attempt to make one of these monthly kits for the month part but I really enjoy her stickers but yeah so this is what I got going on and that way I can see it in the same form that I see it in my monthly in my air and conjuring so I'm gonna probably do a quick air and conjuring video I'm just gonna speed through this just so you can see how I do it and then I'll be back so I didn't do July so after today I'm going to be working on my August kit so I can get caught up because I wasn't gonna do this anymore but I'm excited about it so so delicate okay you guys so I don't know what part cut off but I just added my total boxes income budget actual then put in the actual amount I have my monthly laid out and these stickers are so so delicate I got the new premium paper the waterproof matte paper and it is so sensitive so a lot of my stickers were tearing up but it's okay because it's just for me so I'm not even worried about so I'm starting to sink in funds and I'm starting cash envelopes again so we're gonna start that probably next week on the cash envelopes all right in my categories I'll come back in and do it into the week budget unless you all know how that went so and we're doing goals so thank you all so much for watching I hope you enjoyed this video I did two and one I sped through this most of me laying the stickers down so I wouldn't ramble on too bad so I hope you guys enjoyed this video thank you again for stopping by if you're new to my channel you want to follow along with me on my budget and journey please hit that subscribe button also hit that notification bell and I will see you all my next video


Hello, my name is Perrine Hamel. I'm a faculty at Nanyang Technical University in Singapore, and I'm one of the developers of the Urban Flood Risk Mitigation Model within the INVEST suite developed by the Natural Capital Project. So today we're going to do three things. The first one is we're going to learn why one would use the INVEST Urban Flood Risk Model. Number two, we're going to learn how the model works in theory and then how the model works in practice. So let's get started with why using the Urban Flood Risk Mitigation Model. We want to highlight first that there are several types of flooding. One of them is the fluvial floods or also called the river or river in floods. And these are essentially when the normal river level exceeds the bank levels and there's water overflowing the banks. So this is flooding coming from the river itself. And the second type of flooding is coastal flooding or storm surge. And this is essentially due to large waves of storm surges that reach the coast where people live. So this is a second type of flooding coming from the ocean or from a lake shore. The third type of flooding is fluvial flooding, which can be flash floods when there's very intense precipitation and more generally fluvial or surface water flooding. And this is actually the type of flooding that we are going to focus on today. Essentially, when there's a lot of precipitation in a short amount of time, and either the soil is saturated or they reach the infiltration capacity, which means that there's too much water produced at the surface of rural or urban areas. And this leads to local flooding. So again, this is the third type of flooding that we're going to focus on and that the model is designed to represent. So some important points about the urban flood risk mitigation model. I want to highlight that it's one of several urban water related services to understand where it fits in a broader picture of ecosystem services. So other water related services include some water runoff retention over longer timeframes. And this is important for water quality, as well as the long term water cycle in an urban watershed. So the difference between the model we're looking at today and that one is that we are today looking at extreme events or storm events when there's a large amount of precipitation for a single event. The other one is more for long term and water quality questions. The other related model or service is the groundwater recharge service, which is essentially looking at how much the groundwater is recharged through infiltration in pervious areas. There are a lot of alternative models and that's the second point I wanted to make. That's important. And some of them you may or may not know and called I tree, which also looks at several ecosystem services and swim the storm water management model and music and heck rise other hydrologic or hydraulic models models that are essentially designed to represent how water flows in that case in urban watersheds. So it's important to remember that invest is one option, among many others, and very often these other modeling options would be more appropriate if you have a strong focus on this urban water related services. And that's because these models are more sophisticated and will allow the user to reach higher level of accuracy. So why why would anyone use the urban invest model in that case, two main reasons. One is that it's consistent in its format, the type of outputs and inputs are consistent with other ecosystem services in invest. And so that's important when one wants to look at trade offs and synergies for different ecosystem services assessments. The second advantage is that there are low data requirements like any other invest model. This one was developed with data scarce environments in mind, which means that you will always find at least global data products are very easily available data products that one can use to run the model. Of course, if you have better data sets for soil data, for example, it's always better but there's a minimum product that we believe is reasonable to ask from users. So some applications just to give you a flavor of the type of model outputs the model produces. This is a map of the flood water retention in Singapore. So we're actually looking at which areas are retaining a lot of flood water, so do not contribute to flood hazard, as opposed to areas that do not retain a lot of water in lighter shades of green. So this is an output at the pixel scale, you can see it's very fine resolution. And we can also aggregate these data at the sub watershed level, like in this map here, and we can also focus more specifically on these areas that are flood prone. And we know there's a risk of flooding. And it's one way to determine how important and valuable this service is. This is because that's an area where there has been flood in the past and we know that it's important to protect or enhance and increase the flood retention service. So this is the type of map outputs that one can obtain with the model. The second example I wanted to share with you today is one in Shenzhen that some of our colleagues from the Chinese Academy of Sciences have developed with us. And so on this slide here, we're showing two maps, one for the flood water retention service, the one we are looking at today, another one for sediment retention. And this was part of an application of the model where we wanted not only the biophysical values for a suite of services, but also the economic values. And this is part of a larger initiative and project looking at calculating the gross ecological product for cities and more generally for provinces in China. So this is another application where we can translate the flood water retention service into an economic value that can be used in such applications. So let's get an overview of the model to understand how it works. The first step of the model is essentially to look at the supply of the service and by supply we mean the ecological functions that provide the impetration and this retention service. And so that's essentially during a storm how much of the obvious water will not be converted to direct runoff, which will increase the flood hazard. The second area of component of the model is the reduction of the water volume in flood prone areas. So that's the connection between the biophysical component and the reduction of flood water where there's a risk so where the value of this service is actually assumed to be the highest. And finally there's the valuation step which can be calculated optionally as the avoided flood damage for a given user. So that's essentially the three steps that I'm going to detail in the next slides. So for the supply, the model uses the SCS curve number method, which is a widely used approach, an empirically based approach that calculates the direct runoff. So if we look here at the graph in inches or in millimeters as a function of the rainfall depth, same thing in inches or millimeters. So this relationship between direct runoff and rainfall depends on what we call the curve number. This curve number is different for different types of land use and cover. So for example, for service versus impervious, and it also depends on the soil type and the antecedent moisture conditions, which is one parameter that the model currently ignores. And so to summarize, it's mainly the land use and cover, which is one of the inputs and the soil type, which is also a model input as provided as a raster. So the model will use these curves to calculate the runoff provided or generated on each pixel over the landscape. And the next step is simply to aggregate. So for each pixel, this peak flow or essentially the runoff generated by the storm event is calculated. And then these individual pixel runoffs are summed up to contribute to the watershed runoff. And so this is an important point for this model. There's actually no routing, which is a simplification. So this I mean there's no direct routing from one pixel to another with perhaps some possibility for infiltration. But there's essentially these processes are ignored in the model. So it's simply the sum of all these runoffs, which is acceptable for this type of model, essentially assuming that everything contributes to during this launch event. So there's no timing difference between the pixels further in the watershed than those really close to the flood prone area. And the runoff redemption is simply the storm volume. So essentially all the water that this storm event, this precipitation brought minus the peak volume. So what is actually coming out of the watershed, what runoff is generated. So the difference between the two is what has been retained by some of the pixels. Next, we move to the value of this service. So we saw that we can focus on flood prone areas and in particular flood prone watersheds to understand where this service might have the highest value. And if we do that, we can also look at the potential economic damage for flood risk. So the model does not explicitly look at the flood depth. It's only saying there's that much runoff that it's generated, but we don't know if it's going to translate into a large or small flood in terms of the depth of the flooding. But still, if we aggregate these values at meaningful units and areas, we may want to look at what is the potential economic damage if there is an important flood hazard in one area. It's value, the value of retention is actually highest if these buildings and the potential damage is higher. So that's essentially what the model is doing here. We're looking at the potential economic damage of an area and summing economic damage for every single building that we had had the footprint for and then looking at the potential service which is simply multiplying runoff retention and potential economic damage. So this economic damage for all the infrastructure in an area. So if we summarize the model inputs that we just went through this first the climate input which is this storm depth and I wrote here design storm depth because often it's a choice that the model user will make to focus on maybe a five year return return period which is the relatively frequent event versus a 10 year 50 year perhaps 100 year return flood so statistically type of event that occurs every 100 years. These can be obtained from engineering manuals and and what we call typically intensity duration frequency curves and essentially looking at these frequencies so if we select a 10 year flood and then looking for a typical duration that one might select as the time of the flood and so how much time it takes for a drop of rain to reach the outlet of a watershed and this could be taken as the duration. This data are also important as we've seen and so it's essentially the hydrologic sort of group that we need for this model, which is a categorization of so it's according to the infiltration capacity. And these are simply ABC or D and they will be codified in the model and as 123 for one for a to four for letter D. The same thing this can be from local soil data sets or global data sets. And finally, on the on that side, the land use and cover is an important input, and as part of the land use and cover which is a buster. And to provide these curve numbers that I mentioned, which for each type of land use and cover in on our landscape in the in the raster. We, there's one specific curve number that's associated with with it. And these curve numbers are actually per hydraulic soil group so there's one for soil group a, and one for soil group B, C and D. The same thing literature and because this model is quite widely used, and this often some existing studies using this data, or the US Department of Agriculture has also some default data that one can use. Other inputs include the watersheds or sub watersheds so the user can define if they want to aggregate at a course or find scan flood prone areas, which can be based on historical information and observation. They can be available from some of the local government agencies as well. And finally, these buildings and damage cost for each building, which is an optional input if one wants to go to this valuation step. And so with all this input data, the model will run and produce essentially these two outputs. One is the raster of runoff retention, as well as actual runoff. So we saw that the runoff retention is the difference between the input precipitation and the runoff generated on each pixel. And so this will be one output as well as the runoff retention itself. And then the shape file will aggregate these values to look at the runoff retention index, as well as in cubic meters so both values are always as a proportion of the input which is the precipitation. Or also as a volume or a depth in millimeter. The potential damage cost as well if this is if the input was entered by the user and this potential service which is the product of runoff retention and damage costs. So before going to the application and hands on demonstration of model. I wanted to give you a sense of some of the limitations and also the next step so the largest limitation of the model is essentially that we cannot look at the actual depth that are predicted or estimated in an area. And so in terms of valuation, it's quite limiting. So I wanted to share here some potential next steps in terms of model development or alternative ways using other models that one can go about quantifying this these values. So can is which stands for so automata dual drainage simulation is one model that we have tested with with some colleagues from the University of Exeter, and to get at this question of flood depth in a spatially explicit way. And so the model produces maps of water depth and velocity as a function of time and using relatively simple inputs elevation surface roughness and infiltration as a raster. So it's still much more greedy than invest in that sense and and it produces relatively rapid simulation, but need calibration so that's one of the downside of a lot of these more sophisticated models where you need to stronger hydrologic modeling background and often need to calibrate the model. The beneficiaries and valuation step of that model can be, as I mentioned, to look directly at the property values as a functional of water depth. And so essentially overlaying the inputs, the outputs of the biophysical model and the flood depth with information on infrastructure or population affected. So as an example for a test golf course actually in Minnesota. And my colleague Ben Jenke ran the model and obtained this map of flood depth here on on the site for a 100 year storm and for the Twin Cities metropolitan area. And so essentially all the darker colors represent higher flood depth up to three three meters. And, and this is the information that we can overlay with the population of our infrastructure data. So that's what this might look like if we look at the building information in gray or information on sensors block so population income age, perhaps more vulnerable people to flood. And so by overlaying this information, we can get a finer and understanding of the value of flood risk mitigation. So that's essentially what I wanted to share with you today. And we'll just go through a live demonstration of the model to make sure that this is well understood where the inputs go and how one goes about interpreting the model outputs. All right, so this is what the user interface. He looks like. And so these are all the inputs for the model that we, we explained earlier, and essentially running the investment all means entering all these data with data pre processed by the user and then running the model. So the first is the workspace and that's essentially anything that the user decides for where you want to write the outputs. And same thing for the results suffix anything that the name of the results. And so we can call it test today. What a shed vector. So this is the watershed that is needed also water sheds. And so you see that this check green checks will appear as as I speak. And for depth of rainfall. This is the design storm depth. And so for Singapore. We use here 105 millimeters based on the water utility guidelines. And we also look at the land cover raster so here we're going to use a raster that we've pre processed. So hydraulic and bio physical table so we can take a quick look before entering this input. So this is what the high, the physical table will look like. And can see that it's actually missing some information so I'm going to use a different one. But that's the curve numbers for ABC and D that I was mentioning for each land use land cover code. And and that's about it we're not going to use the this optional input so we just click run and wait for the model outputs and the model has completed successfully and so we can now check the model outputs by opening the workspace and look at the different outputs that the model has produced. So to visualize them and I will bring up here QTS and so we can start with the shapefile. And look at the type of outputs that the model produce I'm actually going to include them all. And I just wanted before we go into these outputs. This is also an important log file and with summary of all the inputs, and also if there's any error. So you'll find some of the important information to debug the model. But so focusing first on our shapefile, we get look, we can look at the different attributes. And so the model produce the runoff retention index as a percentage and a value in cubic meters. As well as the flood volume so this is the actual runoff, total runoff, not the retained volume. And so of course if we want to represent this in a more visual way, one might want to graduate and represent this as a function of the potential so classify and apply. So now we see proportionally which watersheds are actually have the highest retention value. And so behind this data essentially these data sets here. And so the, this is the first step of the model, this is the runoff produced by the model. And this is the runoff retention so if we subtract this runoff value from the precipitation value. And this is the retention as a percentage so you see these are values between zero and one. So that's essentially it for the for today and thanks for listening and of course I wanted to reiterate as well that all this information is in the model and users guide that one can find on the natural capital project the invest users guide. Thank you and have been running the model.


So, my name is Feroz Park and I'm going to be talking about title snippets and result previews. My general area of focus is core ranking in search, but the last few years I was asked to look into this area about result previews and there's a pretty good reason for it. If you think about it on a search page, one of the large tasks that a user has is to sort of find the content they want, find the page they want to get to. And in the world of Ten Blue Links, this was the only information they had literally was a title and a snippet and perhaps the URL. So part of what we did was we sort of rethought what would be sort of the important pillars for an effort around result previews. So primary to our goal of course is relevance to the user need. We certainly cannot have previews not be relevant to the user query. Our second goal would be to make sure that whatever preview we generated actually helped users make a choice. We wouldn't just generate previews, apps in mind of that. A third one would be we would want to illuminate the depth of content within websites. I personally believe that there's a ton of content out there written by wonderful people out there like yourself and it's important for users to understand that there is a lot of relevant information within sites and if they don't know that information is within that site, they're unlikely to visit it. So this is a large pillar. And the final one was this notion of diversity. There is a ton of different kind of content out there. It goes from imagery to videos to forums to lists to tables. I mean it's sort of boundless I think in terms of human imagination. And so we needed to catch up and we need to be able to express the diversity of the content that was out there in the ecosystem. And our sort of sense was if we did this then people would benefit, users would benefit and then consequently the ecosystem would benefit. So here's what we had to work with. We had to work with something called attribution which is the source of the site, the name of the site, the title itself for the URL and then this sort of abstract notion of a content preview with its character limits and size limits. So the next few slides I'm going to talk through some of the newer formats that we sort of have built out. These are all algorithmic driven by those original pillars. But as you'll see they're actually quite useful for users. We were putting a lot of effort. It's not that the previews themselves were just built without effort. Here's an example of us attempting to change the snippet in response to the query. The same algorithm that decides that a page is relevant for a query can be used to decide what part of the page should be relevant for the user if they were to choose it. So if you change the query you can expect your snippet to change and you can expect the user to read that to understand if that page indeed is relevant for them or not. But we can do more than that. So an example, one of the things we discovered I think it was around 2016, 2017 was that images really help users choose between different results. This latent desire, I want to see a particular type of image, I want to see a particular type of flower or I'm looking for a particular type of shoe. And the image suddenly becomes exceedingly relevant for them. So this was, we can algorithmically extract relevant images from the page and show them. The placements on the right, this is important because you want the image to be secondary to the main source of information which is the title in the snippet. Occasionally we can extract galleries. This is when the content of the page cannot be rendered by a single image. Rather the user would benefit if they saw a sense of the kind of content, the kind of imagery on the page and we make sure not to use all the images. There's limits on what fraction is used. And as a consequence we noticed that users actually would start visiting a greater diversity of sites. So this was sort of a very strong, in a strong sense this helped us understand that this can benefit the ecosystem. Following images the obvious thing to do is then look at videos and you can understand similarly that you're going to look for relevant videos. There could be multiple videos on the page but you're going to look for the relevant one. And you can sort of mutate your preview type depending on whether the video is the dominant content on the page and you'll see this notion in subsequent previews too or whether it is only supportive and therefore on the right. If you wanted to express the depth of content within sites then the sort of within that height limit of ours, the only information we have is this ability to sort of generate what are called site links. And these are links to pages within your site that we believe are relevant for the user. So if you're looking at a restaurant then clearly contact drinks, private events, finding tables. These are all links that can be very useful for users. These are all extracted algorithmically. Occasionally the site structure does help us and it drives traffic into your site. Sight link images was another change we added when we realized that if their page had image previews then it should be simple for us to again algorithmically decide what the site links could have images. And this actually helped in cases where the site links don't really help the user disambiguate the type of content that's on your site. We could go further. We went down this path of entity facts. This is when, if you can imagine, as in the bottom right, if you're, in this case I think Killen Jorné is a wrestler. And there are facts around this wrestler that are pertinent to the user.  It does explain facts about this user and therefore it's deep and therefore I'm willing to go to this site. Similarly, forums. I think Allen had talked about structured markup to help us understand forums. But there are tons of forums, community sites. There are tons of forums out there that don't have structured markup on them. And it's a big disservice to users if we're not able to help people understand that this is a forum and help people understand what kind of contents out there. So algorithmically we can extract posts subject to our ability to do so. We choose the forum cluster. There's a set of related content on the site that might be related to the query for the user. We certainly see users engaging with this a lot. And we know that if you're going to provide us with markup, then we certainly want to use that. And so markup always takes priority over these algorithmic forms. We can do the same thing with tables and lists. So if your site has a dominant table, and we want to show the preview for that page, and clearly showing that table to some extent is a better thing for the user, because they can understand this is really what the content is on this page. And the structure and the position of that HTML does guide the preview. So in summary, relevance infuses everything. If these previews have to be relevant to the user, they have to be relevant for the query. Attribution helps the user choose the source. We make a lot of effort to ensure that the depth of your content is well expressed. And therefore, a user is sort of invited to visit your site. And you can see that both with site links and forums. And we make sure that we have a diversity of preview formats to sort of support the ecosystem. Thank you.


last of the Mohicans, just beautiful, what a beautiful artwork. The following pictures have been excerpted from a story by James Finmore Cooper that took place during the French and Indian wars. They concern a white scout called Hakai, a Mohawk, Mohawk and chief called Chingachuk, his son, his son, Unkas, and their personal feud with the Huron Indian tribe. These six pages attempt only to give a tantalizing glimpse into that great classic, the last of the Mohicans. Where are the blossoms of those summers fallen, one by one, so all my family departed, each in his turn, to the land of spirits. I am on the hilltop and must go down into the valley, and when Unkas follows in my footsteps, there will no longer will be any of the blood of the Sagamors, for my boy is the last of the Mohicans. Sagamors is Mohicans and Delaware's, and he's telling the story to Hakai. Thus spoke the words of Chingachuk, tribal chief of the Remnani Mohicans. Thus listened Hakai, fearless scout and hunter, friend of the Sagamor. Thus answering, Unkas, son of Chingachuk, bravest of warriors, enemies to the Makwas. Unkas is here, Makwas Huron. Do the Makwas dare to leave the print of their Makasans in these woods? I have been on their trail and know that they number as many as the fingers of my two hands, but they lie hid like cowards, the sun replies. The thieves are out lying for scalps and plunder. That bushy Frenchman, Mont Calme, will send his spies into our very camp and he will know that road we travel. This enough. They shall be driven like deer from the bushes. Hakai, let us eat tonight and show the Makwas that we are men tomorrow, says the Chiefston. I am ready to do one as the other. Talk of the devil and he will come. Here is a pair of the biggest antlers I have seen this season.  Hakai, will you fight the Makwas? Hakai replies.  The Inquas, Eroquai to eat. Unquas Eroquai Huron. That's what it's referred to. In another moment, the thwang of the cord was heard. A white streak was seen glancing into the bushes. The buck plunged from cover. Avoiding the horns of the infuriated animal, Unkas darted to his side and passed his knife across the throat of the bounding deer, supper. That was done with Indian skill and it was a pretty sight to behold, Hakai says. Though an arrow is a near shot and needs a knife to finish the work. The chiefs then saying be quiet. By the Lord, there is a drove of them. If they come with in range of a bullet, I will drop one, though the whole six nations should be lurking within sound. What do you hear? For to my ears, the woods are dumb, Hakai says. And the chiefs then put his head on the ground. See if you can hear them. There is but. There is but one deer and he is dead. I hear the sound of feet, Euston says. Perhaps the wolves have driven the buck to shelter and are following on his trail. No. The horses of white men are coming, Hakai. They are your brothers. Speak to them, he says. That will, that will I. And in English that the kings need be ashamed to answer. There goes something. Now I hear, yes, God keep them from the Iroquai, the Hurons. Who comes? Who comes hither among the beasts and dangers of the wilderness, Hakai asks. Believers in religion and friends to the law of the King, men who have journeyed since the rising sun in the shades of this forest without nourishment and are sadly tired of their wayfaring. We are lost, they reply. There's a couple of ladies with them. With an Indian guide lost in the woods when the sun is scorching the treetops and the water course are full when the moss on every beach he sees will tell him in which quarter the north star will shine at night the woods are full of deer paths which run to the streams well known to everybody what Indian is he. Magwa Huron recognized by Hakai and his two companions and sensing his plight failing he plunged at a single bound into the thick thicket. The Huron had escaped to try trickery some other time. Though the small British party was saved from the Magwa's that day, they journeyed on to Fort William Henry only to find Mont Calmes troops. Mont Calmes troops had begun invading the place. Hakai knowing the land so well was able to lead the party through the French lines unseen. The overwhelming forces of Mont Calmes took the fort with an honorable surrender. The Magwa's being cheated of their British scalps attacked the British and before the French could help the Magwa's had taken captive the colonel's daughter. With the skill of Hakai one daughter was saved and later the Delaware the Delaware the Delaware cousins to the Mohicans brought tribal war of Magwa and the Hurons. After a vicious fight the Hurons were put to flight in defeat. Magwa raising a yell that spoke volumes of anger and disappointment darted away from the scene attended by his two only surviving friends.  Magwa's scalp Hakai and the two British officers followed Unkas. Hakai holding his fire for Unkas desire for victory. The Hurons leaped into a thicket and entered into the mouth of a cave that led up the mountain. For a moment the race was believed to be lost when a white robe was seen fluttering in the dark. This Korra Korra Korra this the maiden courage lady we come we come Hakai the knaves will pick us off at this distance the knives will pick us off at this this knave no knaves can pick us off at this distance and see they hold the maiden so as to shield themselves at this moment the forms of all four were strongly drawn against an opening in the sky and they disappeared the impetus young men were rewarded and encumbered with Korra the Hurons were losing ground in the race chasing us through the mountains stay dog of the wind dots a Delaware girl calls stay one dots Hurons again I will go no further kill me if that will detestable Hurons I will go no further she says woman choose the wigman wigman or the knife or the subtle choose the subtle magus french title magas french title just then appears in cry was heard above them and Unkas appeared leaping from a fearful height magas ate she sheathed his own knife in the bosom of Korra oh diverted by this interruption magma buried his weapon in the back of the Delaware Unkas rose from the blow as a wounded panther unstruck the murderer of Korra then with a stern and steady look he turned to magwa his failing strength uh expended the latter seized the un unresisting Delaware and passed his knife into his bosom many times keeping his gaze on of scorn Unkas fell dead at his feet magwa issued a cry of triumph and made a desperate leap falling short of his mark though his hands grasped a shrub all he had to do was pull up for escape the long rifle of Hakai was raised pouring out its contents dealing death to the cunning magwa thus came the burial of Unkas why weep that a chief has filled his time with honor he was good he was dutiful he was brave but Manitou had need of such warrior and had called him away i am now a blazed pine in a clear clearing of the pale faces my race has gone i am alone the chieftain says no sagamore not alone the gifts of our colors may be different but the god placed us as to journey and the same path haka replies then spoke Tamin Taminod chief of the Delaware to dis disperse the multitudes it is enough go children of the linear the Delaware tribe the anger of the Manitou is not done why should Taminod stay the pale faces are masters of the earth and the time of the red man red men has not yet come again my day has been too long in the morning i saw the sons of unamesh happy and strong and yet before the night has come have i lived to see the last warrior of the rot of the wise race of the mohicans


At university, you make notes to use them for an assignment or to study for an exam and to develop your understanding of a topic. Effective note making requires you to be active and focused. It is not a passive action. Keep the keywords of the assignment written and in mind whilst reading and note making. Underline keywords and phrases, circle words and write questions and notes in the margin. Copy any quotes and keep precise records of referencing details. Write in point form using abbreviations and symbols. Use colors and highlighters to mark relevant parts. Choose a note making style that suits you such as Cornell. Cover your notes and write summaries of your notes for understanding. Write out questions and answer them for recall and to help your long term memory. Make connections between texts as you go. Write some assignment body paragraphs before you make more notes from other texts. This will help you make better, more useful notes as you go.