So my name is Paul Vocio. I work at Rackspace. I'm the director of engineering with our public cloud. And I'm going to talk to you about some of the challenges and some of the scaling problems that we have over at our public cloud and how we've kind of accomplished those and where we've been and where we want to go. So this is a little haiku that I kind of like to remind all our new engineers when we start. And that if you write code, it doesn't really matter as long as we can't get it to production. So that's kind of the key thing that we try to make everyone understand is that's great. You write really awesome code, but we need to get it out to production. So we're going to talk about how we deploy stuff at scale at Rackspace. We're going to talk about where we've been over the past two years with OpenStack and then where we want to take it in the next 18 to 24 months. And so just a little reminder from what we talked about at the Portland Summit. So we launched our open cloud in August 2012. And so the thing that I want everyone to realize is that we'd actually been running OpenStack for the previous year in production before it was actually in production. And so we were deploying code that was roughly two weeks out of trunk. And we've been pretty good at doing that. And over the time, what you can see this graph shows is that our number of releases got slower as our installation got bigger. And this is for a number of factors which we're going to talk about. But a lot of it was just the scale of our deployment got so big and the mechanisms that we had wrote, which worked in the beginning when we were really small, just didn't really scale out. And so once we got to around January 2012, our environment had really gotten so big that our employees were taking up to six hours. And our engineers were getting very, very tired of this and realized that we had to rewrite this process from the ground up. And so that's what we did. And so a little background on our public cloud. So we actually run two clouds at Rackspace. One is the public cloud that you guys interact with on the API. And the other is actually a large internal cloud that we call Inova. It's based on OpenStack. And it actually provides all the external services that we offer publicly, but just on internal APIs on our internal IP space. And so the reason why we did this is we realized that if we are to offer our customers an OpenStack solution, we really needed to run it first to make sure that it scaled. So this is, again, before OpenStack had really taken off and before it was, quote, unquote, mature, we knew that we had to make sure that was up to our standards. And so we built this internally.  And so the conversations that we had with our engineers when they realized that things really didn't work, and that was our motivation to go fix it. Because we had to use it, and we had the same pain that our customers had running it. And so as we encountered these problems, we logged the bugs upstream, go fix these, redeploy it, and kind of run that cycle. So by running everything on an internal cloud, we actually get some of the same benefits and challenges that our customers have in running an internal cloud. So when we spin up our API nodes, we're actually calling an OpenStack API to create a VM and then install the OpenStack code on that. And that's what I'm about to show you here. So this, I'm sure you guys are very familiar with. So we take all our OpenStack services and spin these on to kind of a golden master. And what we do is then we take that master, and we actually store it in Swift to keep a canonical record of it and version it. But we take that, and then we deploy it onto a hypervisor. And we use Zen server at Rackspace. We run a couple different versions. But we take that Zen server, and then we kind of blow that and blow it wider. So we take a couple different hypervisors and bring up a very, very small OpenStack cluster.  And then take that same image and deploy that across a bunch more hypervisors, computes. And then kind of using some scripts will wire that all together. And that becomes our kind of internal capacity for our I-NOVA cluster. So this guy you're very familiar with. So that I-NOVA capacity, though, becomes our internal API endpoint. So then we do is create more VMs.  And then do the same thing where we point those two hypervisors and build our compute. And then what we end up with is two clouds, kind of inception-based, where we have then our production capacity online backed by our internal cloud. So talk about our agile deploy process. And the reason why I put that in quotes is because we started out with building Debian packages. And so this was very easy for us. We're all Linux system engineers. We knew how to do this. And we've been doing this for a long time. So we took all our packaging, all our scripts, all our OpenStack code, worked with the community, used some of their packaging tools, using Freight and Apache, and pushed us. And this worked really well in the beginning. So we're able to iterate very quickly, modify our scripts, we use Puppet, with Puppet Masters. And we, like everyone else, Bash and SSH will take you very far, very quickly. It's very iterative. Our engineers would check out the code, rewrite it, push it back, and Bash and SSH were very quick to modify. So we'd use this behind a load bouncer. And one of the ways we can do this is just AB node rotation to do our upgrades. And so this is normal website stuff. Everyone should be really familiar with this. Website stacks handle this very well. But this was a problem for us. And so we knew we couldn't deploy or compute this way for long-running operations. So we do resizes, migrations, and host maintenance, and anything that is transferring a lot of data from another host, you can't just rip that out and reinstall this. And so this kind of process didn't really work well for us. Another problem that I'll talk about later is also database migrations. When we have a long-running migration, you can't really just swap out your API node if it's expecting that the database data structure to be in a certain way. So load balancing puppet, when we scaled out, like on my first slide, I want to show that our deploys went down as our capacity goes up, load balancing didn't really help us very much. And so the reason why is that our load balancers have dedicated pipes coming into this. And then the more that those are pulling that traffic out, we're saturating some of those network links. And so we tried upgrading these. We're adding more load balancer nodes. But again, that only gets you so far. And so because the way we do our upgrades, we need to do these in a short amount of time as possible. Those upgrades didn't happen in our time windows. When we talked about things are taking six hours to run, what would happen is a couple nodes would go, someone fail, we'd keep retrying this. And then that's what would make that end up longer. So the timing of this became very, very critical for us. We wanted to get it out as soon as we could. So we talked about breakage. So when you're running 10,000 nodes in a region or more, 0.1% down is something that you're going to experience. And so on 100 node cluster, you're going to know if one node is at a rotation, you can kind of manage this. But because we have such a large fleet, it becomes difficult to manage anything down.  So you have to have a way to deal with that when it comes back online or how to fix this. So this is one of the things that we've also taken a lot of time and effort to go figure out. So somehow, scripts to deal with auto healing or inventory management to know if a node's offline and what to do when it comes online is something that we've also paid a lot of attention to.  So a lot of people should be familiar with this kind of strategy, where you can do your code, build your packages, you deploy it, and you verify it. And this is what we use our Inova environment for in a lot of our testing and automation scripts. We'll build our packages, push these out to a dev cluster, we'll run our automated suite against it. If that looks good, we'll promote it to our continuous integration environment. And this environment is where our other groups in the rack space will then integrate their systems with us. And what we'll do is we'll kind of let it bake in that environment for about two weeks before we push to production. And so this is where we will stress test it, run nightly builds, have other groups run their tests against it, look for kind of corner cases. And so this is normal. This is what everyone should be doing. But because we take a different kind of approach at Rackspace on how we, our developers develop, we don't develop internally and then push our code. What we do is we actually develop in the open. So our developers, when we're developing a new feature, we'll commit upstream first and then go through the whole open stack process and pull that into our environment, build it, and then push it. And so I tried to illustrate that here by showing, you know, if we started on the internal side where we're coding, we actually go to the external merge prop first and then go through the task, the approvals, and the merge. And the problem on the external side is that that's an indeterministic amount of time. So this could be a few hours if it's a small patch. It could be a few weeks if it's a larger patch and on some of the larger blueprints this could be months before we see something. And so this is a new conversation that we have when other product groups wanna come and deploy something on Nova like it's, it's a little bit iffy because you don't engage with the engineer and then expect the engineering team to go out into the community. The product owners inside Rackspace really need to be part of the community. And I think we've done a really good job about teaching people that you don't just drop a red mind ticket or a blueprint on an engineer and expect them to be the advocate for that. It really takes having people integrated into the community from the product side and the QE side and the engineering side. And so our process again it's code to merge prop test and then merge and then we package it. So we pull in from upstream at least once a day sometimes multiple times a day, build those packages deployed into our CI and our staging environments and then go through our verification process. So this again can sometimes be a few hours if we're lucky and we know who has minus one that particular patch and we can walk through it with them and fix it and push it or this can be a few weeks or sometimes even longer depending on what the feature is. So I said earlier that we had Debian packages and we used freight and Apache to push these out and we realized after some amount of time that this was getting difficult for us to do and we wanted another way to do this. So we sat down at the summit I think it was a year ago and with our engineering team and decided how do we really want to do this? And one of the ways we talked about was the Python virtual environments coupled with our puppet configs and our source codes. We ended up coming up with essentially a tar ball that has everything you would need to run that environment. And because sure Apache worked but bit torrent actually in some internal testing ran a lot better. So we ended up distributing these with bit torrent and then the way we actually run the scripts and execute these is in collective and ansible. The reason why we did the packaging that particular way is we found it was OS independent and the OS in the Linux sense independent. It was easier on our developers to develop again so they could check out packages that had the particular source code, the libraries that were for that particular release and actually the configuration that went with that particular node. So say our API nodes have all the libraries that would go with that, the source code and then the configuration for that particular API node gets pushed to that box. And so if there's a problem with that release, we know exactly what that config was because there's no kind of confusion. When you have puppet and configs coupled independently of your source code, the puppet revs can change. Your source code may not change and then it becomes kind of an investigation to figure out which source rev were you at versus what configuration you were. So by coupling these together there was never really any question that this release is the problem and this either this code or this config was the problem. So it actually helped us in our debugging a lot. And here's the other thing that we solved with the BitTorrent. So by doing this with Debian and the freight packages in Apache, like this was very easy with 100 nodes and this scaled up to some degree of a couple thousand nodes. But when we started having tens of thousands of nodes in a region, this became a problem. And so like I said, going back and doing some actual benchmarking with Apache and with BitTorrent, we're able to prove that it actually was faster and much more efficient for us to do this. I'm gonna show you some information on that in a second. So this is a test that we ran a while ago. We had 200 hosts and a single Apache host serving our packages. I think we had about a 100 mag payload and the same test that distribution was roughly under 6,000 seconds from that single Apache process. Doing the same delivery with BitTorrent across those hosts ran just under, I think it was like 1,300 seconds for the completion. This was just a kind of one afternoon test we ran. And so after we scaled this up we were able to actually do our distribution across. It was taking, I think, was an hour and a half to distribute some of the packages at some point. We're actually able to get this now under 15 minutes onto a very, very large number of nodes. The other thing to keep in mind here is that you're a layer two domains when you're doing BitTorrent. So I don't know if you've worked with this in a legitimate sense, but BitTorrent can actually consume a lot of connections on firewalls and push a lot of data. So one of the things we had to really think about is how do you design your BitTorrent distribution architecture in a multiple layer two domains? We'll talk about that a little later. So we know we still needed configuration management. So this is, again, why we had to move away from a puppet master type scenario where when the nodes would have to check in and get their configs, normally in an environment where you're pushing packages and you can kind of do asynchronous upgrades, puppet is really awesome for this, is what it's built for. But when we had a specific time window that we knew we wanted to target and push our configuration. So we would change our puppet config, check it in, and then normally what happens is a puppet will then periodically check in, pull our configs, but we needed to be very deterministic around when that happened. So what we would do is we would change our puppet configs, check it out on the puppet master, and then we had to do some action parallel SSH that would go out to each host, execute say, all right, now check in and then that's what would come back and slam the puppet master. So those would get overloaded, we would have some failures, have to go back and kind of keep repeating that cycle until it worked. So by moving away from this distributing it, we're actually removing some of that infrastructure from the problem, pushing it down to the host, everything runs at the same time. So everything has the host, the source, and then we say upgrade now, and then we have a nice distributed action that moves that up, moves the sim links, and then restarts the services. Right now we actually have a combination of mCollective and Ansible. The reason why I think we're moving a little more towards the Ansible side is it's agentless, it's much easier for our teams to write, we don't have to run Ruby on the hosts. And again, when we talk about our layer two domains, one of the things that we've noticed with the versions of mCollective we're using is some of the mCollective nodes on the hypervisor would lose their connection back to the rabbit queues. So as rabbits traversing firewalls, then one side thinks the connection's open and the other side isn't aware that it's closed, and again we have a failure. So then that's another failure that we have to go track, repush, and do it. So moving to Ansible helps us kind of get around some of that. So talking about staging the packages, so you can stage the packages with Debian and Freight, you can push the command out, and it kind of sucks them down. It doesn't get us out of the problem of having to move a lot of data in a small amount of time. By doing this through BitTorrent, we actually have to only push a very small amount of data through our firewalls, and then inside the clusters, it's all distributing it among nodes as BitTorrent does. And so we'd actually see a decreased use in our network when we're doing this, and we can actually wait until later in the night. We don't have to start early in the afternoon to start pushing our packages, saturating our network throughout the afternoon. We can actually distribute this right up to the minute as we're getting ready to go. And the other thing that our configuration lets us do is target a single node or target an entire cell. So we're actually able to do a cell at a time, a region at a time, or a single node at a time. And we talk about a node that has failed or that's coming up after a re-kick and a reinstallation. We can target the single one and say, now you're rejoining the cluster as an API node or a compute node. So things that we need to do to make it better. So DB migrations are still painful. When you have millions of rows in your database, either of logs or instances or snapshots, one of the things that we have to pay attention to is every schema change, everything that comes through we have to evaluate and figure out is this gonna work for us or not. So one of the things that we've done is set up database slaves that pull our data off, we've run those migrations and time it. And so I think in our most recent upgrade last week we were looking at about a 30 minute upgrade. So some of the things that we have to do is and that 30 minutes means that 30 minutes downtime on our API. And for us that's not really acceptable. We're trying to do everything we can to have a zero downtime deploy or at least a couple seconds where we can just call it a latent connect, a latent API request instead of a 30 minute API outage. So I saw that Russell said that we're moving toward rolling upgrade, which I'm very excited about. So I'm hoping to follow up with him and find out how we incorporate our database migrations in this as well. So I know everyone has the Tori, NASA, giant screens and launching rockets, but for us this is a little bit how it actually feels. And so we actually have a large team that's online when we do our deploys. And so we run all our deploys in IRC, we have a bunch of status screens that everybody's watching, one team's watching for alerts on the notifications and other teams watching our network and other teams actually watching the transactions as we go through to make sure we're seeing what we want. Have a QE team online ready to run our smoke tests and QE tests when we're done. But that feels like it's kind of overkill. We shouldn't have to have a team of 15 to 20 people up watching migrations and kind of watching an entire environment. What we really want to do is have just a small team that does this. This could be a few people. So one of the goals that we're really trying to push for in OpenStack and within Rackspace is trying to make it to where anyone on our team can deploy any third shift, the first person developer and operations guy, if I had to do it, I would really like to do it. And we actually use Jenkins to do a lot of our automation. So it's an automated tool. We can kick it off. We can record who ran what. We can record the output. So it's actually very well suited for this. So this is kind of our deploy timeline. So when we talked, you know, where we were in Portland a little while ago, so we're starting in May and we kind of look at what our deploys were. So our grade dots here are kind of major releases and the blue dots here are kind of minor follow-up revisions. And so we'll do a major release. We'll kind of watch the environment. We'll watch the logs. We'll figure out where we want to go. Any bugs that need to get fixed. And then we'll go through that kind of life cycle that we talked about before where if we see anything, we'll go work with the community. Is this a patch that we need to short-circuit? Is it a security issue? Is it breaking something that we need to go address? If it is, we'll kind of bypass that process, get it fixed, push it out into production and then kind of work with the community to get that patched upstream. So we do give a small diff of patches, but for the most part, we're running a couple of weeks off a trunk. I think as of what is it, 10, 26, we were running the full Havana release. And so that's something I'm very proud of. Our team spent a lot of time in making sure that as we pull in from trunk that it works in our environment, that it works at our scale. And then we feed all that back into the community. And so these are our priority deploys. So the one thing that we don't talk about is that we actually are able to deploy a lot very often. That's one of the things we try not to do, but if we have to, we can. And so some of these are maybe not API impacting releases, but using the tools that we talked about, Ansible and Im Collective and sometimes PSSH, we'll do a targeted deploy to a particular cell or a particular node to fix an issue or anything that we see in the environment that we need to go take care of. So we still have a ways to go, I think. So we build infrastructure as a service, but we try to treat it like an application. And I think those are some of the kind of conflicts that we find in the infrastructure world. And so we use cloud, we build cloud, but it's very hard to deploy a cloud using cloud, you cloud thoughts and processes. So what I think we're trying to do is figure out what are those things that are transactional? What are those long running processes that we can restart or try to either hand off to another node while they can run? So if a VM is migrating to another host and if you have a terabyte of disk, it's not something that's gonna happen instantaneously. And if I have to restart that compute node or restart the schedule or restart something that it needs to know that state and that's something that we're trying to figure out how we do for a long time. And again, talk about sticky data. So our VMs actually have a disk on our hypervisors. And so we don't do necessarily volume. So if the host reboots, then that data is stuck to that host. So how can we treat these upgrades and these rolling deploys as something that the data is on that particular compute node and it's not something that's a thermal that moves around. So again, that's a problem that we're trying to solve that may or may not impact other deployments of clouds in different ways. Again, I would really love us to get to a point where we can actually deploy it like a website. We're talking about swapping nodes out, AB nodes, swapping out computes. And one of the things we're trying to figure out is do we need, so right now we have a one-to-one compute hypervisor. And if we could pull that back and say that we have a pool of computes that can interact with a particular hypervisor, this could be one way we could do it. And so I know that we're doing some preliminary work on trying to do that one compute to many hypervisor kind of work. So just as a recap, we reduced our deploy time from sometimes hours up to minutes. And this was the result of a lot of work that our teams have done over the past six months. Most of our time in our deploy is now actually spent testing. So we'll get our deploy out in 15 to 20 minutes and probably spend the next 30 minutes to 45 minutes just doing our smoke test before we're given all clear to make sure we're done. But a lot of the work that we've done is to streamline this and speed this up and make it as the smallest impact as we can on our customers. And the thing that we also try to make sure our teams and our customers know and hopefully the community knows is that deployment tools are part of the product. And it's not something that you build as an afterthought. And so a lot of times what we'd see in the OpenSat community and in other communities is that you write a bunch of code and then it's this long complicated process to get it started. And one of the things we try to stress is that the deployment and the tooling around it is actually part of the process. It's part of what you write and what you distribute. It's not something that you try to bolt on afterwards or hope the distros put a NIT script around. It's actually something that you should take care of in the beginning. So that's all I had. So if anybody had any questions, I'd be happy to answer them. Yep. So your question is between the releases, how, what's the delta in the scheme is changing? So from what we see, because we space our releases out, roughly if I kind of go back and look at this bigger slide, it's roughly one a month and we're trying to shorten that. So very rarely that will have a release that doesn't have some sort of schema change. And so what we'll see is sometimes these are small, these may be index changes. Sometimes it's a column add, but as we have millions of rows in these columns, then something that's very small that works, that should be very easy on a 100 node cluster ends up taking 10 or 15 minutes for us. And so we'll try to figure out, do we need this change? And if we don't particularly need this change, what we may do is push this off to a later migration. And so we'll go ahead and modify those schema files and delay it, or at least we'll schedule an outage at a later time, or we'll do some optimizations. We'll clean up that table, say, if we don't need all the rows, but our analytics team may. So we'll have to go let downstream systems know that, hey, when you consume our slave databases later, that we've cut the records off at this point to reduce those migration times. So it becomes more of an operational issue and kind of letting everyone know, hey, this is how we're having to handle it. I think there's some good ways that we could probably fix this in the community and that we'd be talking about it for a while, but I think as we solve some of the larger problems that we have, particularly in Nova, that we'll start getting a lot more focus on how do we operate these things at scale. And did you have a second piece that maybe I didn't answer? So I think what we're also trying to do, and some of these guys, Sandy, and may know that as we, I think part of it is on us to actually be more participatory upstream and either provide sample data or seed data or actually test in the 100 million row range. And so provide a database that is sanitized or sample data of this and run the migrations against that and kind of test those. I don't think we do a lot of that now. We use C-Torrent. So it's a project that already exists and using the C-Torrent. It's in the Debian distribution now. And so really all we do is we use Cells, which is our kind of layer two domain construct in our public cloud. So we'll run a torrent seeder per cell. And so using the Ansible scripts will actually push that torrent file, which is usually very, very small, push the payload to a single node within that cluster and then distribute the torrent using Ansible and Collective and then just light it up per cell. And so they don't cross the layer two domains because what we would see is in your layer two domains, these are connected by the routers and the firewalls and then they would start crossing traffic and then we'd shut down those links and then our network guys get pretty pissed at us. So we have network nodes per cell and each of those contacts are, we're running an older version of Quantum and then our software defined networking cluster has that interaction. So we run a SDN per region and then the networking nodes then call into the SDN for IPs and Macs and our networking setup. So how do we do our bare middle provisioning and our OS provisioning after that? So being working at Rackspace, one of the things that I kind of get for free is that we've had bare metal provisioning solved for a long time. And so we have teams that, so we, you know, our racks roll in, we plug them in, they light them up, they re-register back in our kind of, our inventory management system and then we pull a lot of that data out and then configure and update them from there. So we kind of cheat in that I get this for free which is why we don't use any of the triple O or any of the other kind of deployment tools because I kind of get that. Sure, so how do we, so the impact of the torrents on the network is kind of how you lay out your physical network. So if you have a large layer of two-domain, you may not have this problem. The problem manifests itself for us is that when we have to transverse network appliances and so then it really becomes a function of how many connections can your network appliances hold based on how big they are. So, you know, for our particular size and scale, it's a cost feature that we scale our network appliances at a certain size for our normal kind of management traffic and because we introduce this torrent concept later, then when our networks were built, they haven't quite scaled out. So what we had to do is push the seating into the cell to do this.  It was just something like, hey, we did that and like, oh, sure, that didn't work.  I think there was one over here, maybe, yeah. So we run, so yes in that, so we run kind of two versions. So we run Zen server as our hypervisor and so that's kind of our base one and so we do apply all our security patches to our hypervisors and then our control pane right now is Debian. So we do run a lot of our updates on our Debian control plane as we see fit. Yeah, that's gonna be a little bit of a different process. So we'll then push those individual Debian packages down and then the Zen packages are also done via some of the other mechanisms. The Zen packages are distributed by a torrent depending on the size. If it's a small patch then we can probably push it with a PSSH script or something like that but if it's a larger update to the hypervisors then we'll use the torrent distribution. So a lot of this, and I think it touched on this a little bit in that it's partly gonna be around your network architecture. So for us, our layer two domains is really what becomes the boundary of where we're able to push a lot of these. So for us we can't really centralize in a single region in a data center where the packages come from. We're just too wide, we have too many nodes and tens of thousands of boxes in a region just you can't update these within a small amount of window without kind of breaking and distributing the problem which is what we ended up doing. So part of it is you kind of need to know where you're gonna end up and so when we started in the beginning I kind of said early on that PSSH and Bash will kind of get you kind of far and very quickly but then that's, will only take you up to a certain level and that's gonna be dependent on your payload, your network architecture and then where you wanna end up. So if you know you're gonna be scaling out wider then I would start looking at some of these other kind of distributed tools but if you're gonna be under two or 3000 nodes you can probably get by with some of the, I'll say the word more primitive but easier to consume tools that don't require a lot of infrastructure in the backside to support. How does a cloud controller scale? And I'm not sure what you mean. So how do we scale the queues in the database and the APIs, is that what you're asking? I mean, most of these are just kind of monitoring the infrastructure and making sure that you're not overloading it. I mean, we monitor everything we can in our DCs to make sure that you're not measuring it you can't really tell what's going on. So what we try to do is measure all the things and then when we see something kind of getting abnormal or if we hear about an incident or we get alarmed on something we have all the data to go back and look at this. So we use a combination of graphite, Nagios, a couple of the tools I think gave West Moss my counterpart gave a talk on that earlier in the week around how you monitor and how you measure. And so as we monitor our API nodes if the API nodes start getting hot because we run in that I know of environment I was talking about earlier actually able to provision a new VM have it join the cluster to make a call out to the load balancer join it to the load and then we're talking 10, 15 minutes which is a lot different than we used to be where we had to go call the DC ops having them provision a physical server we have to install it, configure it which could be maybe a day if we're putting pressure on folks or a couple of days if they don't have the hardware ready so by having this cloud that we can use we then are able to actually use cloud infrastructure to deliver cloud infrastructure. Okay, thank you much.


What's up everybody, Jason for Jasper's casebricks.com This sells out 1920 chronicles picking team number six by selling out the Memphis Grizzlies So we're giving away the Memphis Grizzlies here and a little filler break So first we randomize customer names and teams distribute the hits out of the one-pack sell And at the end of the break we'll take all 30 customer names and randomize them and our new dice roll a randomizer And number one will win the Memphis Grizzlies Which were like a $800 team and then by winning the Memphis Grizzlies you're now part of the break and have a chance to win the Pelicans So there you go. Good luck guys Roll it and we got a two and a four six times three four five and six Kevin down to Matthew six times here one two three four five and six 76ers down to the Hawks Kevin with the 76ers ties with the Clippers foot with the Bulls Chris with the Pacers John with the Suns and Rockets Kevin with the Lakers Rio with the Grizzlies Quinn with the Heat John with the Nuggets Daniel with the Blazers Zach with the Hornets Ryan with the Wars Robert with the Spurs John with the Knicks Mark the other Raptors Daniel with the Pelicans Zach with the Nats Celtics Quinn with the Thunder Gerald the Magic Matthew the Kings Ryan with the Cavs Matthew the Bucks Phillip the Jazz Ryan Harold with the Mavericks Roger the T-Wills Matthew with the Wizards Mark with the Pistons and Matthew with the Hawks so let's quickly Advertise it here, and we'll close the trail. I know guys just a quick sell a pack and then we'll come back and see who wins spots In the mixer Or not mixer. I guess the break itself will wins and Grizzlies Just get to use the same mixer All right Windu Julie Okufor Brocolopis, Demarda Rosen, Valenchunis. I mean the way he's going he might score another goal DJ Warren Actually just had like how many points? Back to back Tyler Leiden. All right guys, so there you go Now let's see who wins the Memphis Grizzlies number one gets them Roll it two and a six eight times one two three four five six seven eight Eight times two and a six Mark H Congratulations, man You just won the Grizzlies and now in the break and have a chance to also win the pelicans after eight times Appreciate you guys coming up next is Chronicles


In this presentation, we're going to take a look at the formatting of the unassigned categories and take a look at some alternatives for the formatting of the unassigned categories.  Not for profit organization dashboard. We're going to be opening up our income statement worksheet going to the accounting drop down going to the income statement worksheet on the right hand side where we have these unrestricted items or the unassigned items I should say not unrestricted. So we've categorized all these are worksheet works well but we still have these items in unassigned and that looks a little bit funny. So in other words if we look at this first item we've got the unrestricted has nothing restricted has that 204 in it and that makes sense for the total these three columns are correct. However we still see that one of the 204 160 over here which is a little bit confusing why is it over there. Well it's because it's part of a restricted category and because we had two separate categories of restrictions we didn't categorize it for the unrestricted category. So there's a couple different solutions you can you can do to solve this problem. It's not really a problem but it's a little it's a little annoying to see this here we'd like to see basically these two columns zeroed out and that would indicate that we had assigned everything. So one one way you could fix this is instead of having two separate class categories here we could have put everything whether it be unrestricted or restricted in one class category and therefore have one column and then just simply choose the proper categorization every time we do a data input form and so we wouldn't have two unassigned columns here we couldn't because there's only one column of a side I'll show you that or detail in a second or we can basically every time we enter a transaction it doesn't relate to one of these categories we make a new category that just says you know doesn't apply here in a or something like that not not applicable. So that's what we'll do so let's take a look at how this would look and again just note that this worksheet is fine you're fine with this worksheet we wouldn't really have to do this but this is just to make it a little bit cleaner in terms of the worksheet setting so you could do it going forward also know that you could do this as you go we're going to go in and do it kind of retroactively but you could do the data input as you go in this type of format as well so I'm going to right click on the tab up top I'm going to duplicate this tab going to go back to the tab to the left and then I'm going to go up top and we're going to go into our settings so I'm going to go into the not-for-profit dropdown we're going to go into the settings so we'll take a look at these settings and then we want to go into the advanced settings so I'm going to go down to the bottom to looking for advanced settings and I'm going to click on it because we are indeed looking for the advanced settings and that's where they are so then we're going to go down here and say we want to go to the category tracking or tracking categories tracking categories is what we want and here's what I mean by this we have two separate sections here so we have two kind of categories and then subcategories or category options within them. So we could just make one category which is basically everything which is called you know this is our category thing and then put all the options down below in it and that means we'll only have one column. We won't have two separate columns in our data input forms and we just make gotta make sure that we select the right ones for the unrestricted categories and the that might make it a little bit more confusing when we allocate the items in our data input form rather than having two separate columns but that could lessen you know the room on the data input form and that's one option we could use to make it possibly easier to make our reports. The other thing we could do is we could have two items as we do here and then add another I'm gonna add another category and just call it NA or non-applicable or something like that I'll say NA non-applicable and I'll say non-applicable and make sure I say this is for the unrestricted so that it's distinct from the non-applicable I'm gonna put over here on the restricted item so I'm gonna then say save that. Now every time we input something and there's not a category for unrestricted we'll go to NA non-applicable so then I'm gonna go back to the restricted side and I'm gonna do the same thing here I'm gonna say alright every time we don't have something in here I'm not gonna just leave it blank I'm gonna say I'm gonna add another category and I'm gonna say NA for non-applicable, non-applicable for the restricted items and then say okay. So now when we do the data input we're gonna do it retroactively but you could do this as you go I'm gonna go back to the income worksheet I'm gonna go into each of these unrestricted items and I'm just gonna assign them to an NA category it's not applicable so to do that I'm gonna go up top I'm gonna right click I'm gonna duplicate the tab then I'm gonna pull the tab from the left to the right the reason I keep doing that is because that makes it so I have a separate tab and then I can go back to this report as I make changes on this one by drilling into it and this one's already been populated I don't have to wait for it to populate then I'm gonna go into the 204.160 so we're gonna go into the 204.160 here and we have two things in it so I'm gonna do the same thing I'm gonna right click on the tab up top gonna duplicate the tab I'm gonna hold I'm gonna pull the tab from the left to the right so again I can make adjustments on this tab and then this tab's the same one I can go back and do it again on that tab so I'm gonna go into the 108 here so we're gonna go into the 108 and drill down on this item then I'm gonna edit this item so I'm gonna edit it and then on the unrestricted instead of leaving it blank because it doesn't apply there is no unrestricted item here so instead of leaving it blank which means it's gonna populate in that unrestricted category I'm gonna say I want to just put it into in a not applicable so not applicable and then I'm gonna update that and then hopefully it'll turn green so hopefully we'll have a green item up top or it says I think it's good think it's okay so I'm gonna check it out now I'm gonna close this out and then I'm gonna update this report and one of these should go away so I'm gonna update this report and one of these should disappear so there we have it now I'm gonna click the other one I'm gonna do the same thing I'm gonna click on this one this is gonna be the other item that was in that unrestricted category I'm gonna edit this I'm gonna go to the option up top I'm gonna edit it and note again I'm doing this retroactively this is not something you have to wait till the end to do anytime it's not it's not applicable to one of these categories you could go in here and say in a basically as you go as you do the data input and so then I'll say update so there we have that and so then we update that report and then I'm gonna close this back out that'll take me back to my income statement worksheet which I will now update and now we have removed it I'd like to see these dashes over here not these things to be empty and then I'm gonna go into the next one I'm gonna do the same thing so we're gonna say the 237 237 went to each of these I'm gonna right click on it again I'm gonna right click up top so we can drill down on these I'm gonna say we want to duplicate the tab I'm gonna pull the tab from the left to the right these two are the same but this one's gonna be the one I'm gonna it's already populated I can drill down on it so now we're gonna drill down on it and make the changes in this tab so we're gonna enter into edit it so I'm gonna say options we're gonna say that we want to edit the edit the transaction and then within the transaction I'm gonna just say that we're gonna put this item to in a for the restricted side this time because it's an unrestricted so for the restricted side not applicable gonna update this then again update this looks good then I'm gonna close this back out and go back to the prior tab so now I'm gonna update this tab one should disappear now updating this tab one disappears I'm gonna do the next one actually I shouldn't I should go back I'm gonna go back and I'm gonna duplicate the tab again so duplicate tab and duplicate the tab I'm gonna pull the tab from the left to the right and then I'm gonna go into that 1897 1897 top we're gonna say that we want to edit the transaction editing the transaction I'm gonna say this restricted column should now be not a sign not in a and so then I'm gonna say update that one so there we have that and that looks good so I'm gonna close this back out and then in this report we should have a signed one out now so I'm gonna update it and it should then repopulate for us so I'm gonna update that and then I'll go into the next one there's only one left so I'm just gonna go right into this one and then we're gonna go to the options up top we're gonna edit this transaction editing the transaction and then I'm gonna say on the restricted side I'm gonna say in a I'm gonna go this is in a and then update that one so we'll update that and that'll take us back to our our report so that looks good so I'm gonna close this back out and then and then go back to our worksheet which have gone away somehow accounting I'm on the income statement worksheet it's gone I'm just gonna keep on going here's the this one is unassigned here so note that these two columns should tie out to this column that's how you know that things are working out and what we might want to have here's another column as well that calculates this by adding these two columns up and that way we can just easily look at those two columns but in any case I'll go into this one now and we're gonna say that we'll change this one so we'll go in here just one item so I'm gonna go into that one item and restricted here we're gonna sit on I have to edit it options we'll edit the transactions and then I can go into that item we're gonna go into the unrestricted item and put in a in a so there we have it and then let's update that so we'll update this one and so once again I I haven't been duplicating my tabs again so I'm gonna have to go to the accounting and go to my income statement worksheet again so let's open up the income statement worksheet keep going this time I'm going to right click on this tab up top I'm gonna duplicate this tab so we're gonna have another tab this is the way I should have been doing it the whole time here find these out so these these are all done below and once we're done we'll also add another total column so be ready to do that I think that's a useful thing on the worksheet as well so then we'll go to the restricted so this item we're gonna do the same process here so we'll go into that one item in it so let's just go into that item restricted one below this one is on both sides where we have a portion of it that's not assigned to go up top and edit it and so this one's unassigned on this side and so I'm gonna say in a here in a there and then this one's unassigned on this side so I'm gonna say in a here and then post that one so notice we're just filling every time there's a blank on the on the one of the restricted categories we're filling it in closing this one back out we're gonna update to this report so there we have that and then let's do this also that took care of both of those so now these are all all applied out now we still have all these items in the unrestricted column for for all the expense items I won't go through all of them but just note that on every expense item let's not do depreciation because it's a journal entry let's do one that's a not a journal entry so I'll go back on over and say let's say like the rent we went into the rent when you do the data inputs you don't have to wait till the end like we did before what you want is it for to be to be possibly leaving it blank for the unrestricted item and then on the restricted ones you can then so I'll go into any one of these will go into the same transaction could be applied it out to four places here so on all the restricted when you're doing it when you're doing the data input you could leave the unrestricted basically blank and then apply it out as we did at the end and that's what should properly show up in unrestricted so that you can then go back in and apply it out the restricted items then you could put all them as you do the data input just to in a and so I have to hit the options to do that so we'll go to options and we're gonna go to edit the transactions so this you can do as you do the the data input so that it doesn't show up in the restricted and as we then adjust it will in the restricted area we'll say in a not applicable and then in a not applicable and then in a not applicable and in a not applicable and so then we'll save an update that and once again I didn't copy the report so I'll go back into it again I'll go to the accounting drop down we'll go to the income statement worksheet assigned that one out so at the end of the day these two unassigned should be kind of of a check figure to tell you that that they should all be zero and everything should be assigned and then these two columns should tie out so so like I say if the if if you see these things that that you leave it the way we had it before it's still fine because you can tell that this one's unassigned for for for the restricted because it was an unrestricted that's why it's unassigned for the restricted side so that's fine it's just cleaner if you can make them all zero because these should be a check figure and then we might want to have another total column that sums up these totals two separate ways for our worksheet not for external reports but our worksheet and that way it's kind of a double check for us so let's check that out I can I can edit this worksheet here and say let's let's say we add another column I'm gonna hold down control scroll down just a bit to let's go to the 100% this total column notice it's total by category so let's rename it total by category and then let's add another one let's add another line and this make this one a formula so I'm gonna make this one a formula and I'm gonna say I want to make this the unrestricted plus the restricted unrestricted plus the restricted and this one's over to the right we can't see it if I double click on it this is going to be total by formula total by formula and then I'm gonna drag these two totals to be next to each other I'm gonna grab that blue item drag it to the left and so now they're side by side and this will give us for a worksheet a double check on our calculation this one's calculating one way not adding these two up but just assigning the categories which should be the same and then these two are adding the two up and those two should be you know the same and you know you even could have another column which would take the difference between these two items which should be zero right and that would mean that these items over here these three columns would be our check figure which should be zero at the end of the day so for example you could take another column and this is really neat that you could do this with zero and you can say okay I want to have another formula and I'm just gonna call this our check number and the check number should be the the total by category minus the total minus the total by formula and this right and then this if I double click on the name this is gonna be check numbers and that should be zero now and I'm gonna then pull this over next to the total columns and so now now these three columns should all be zero at the end of the day in essence those are our check figures at the end of the day so we're gonna say done and then pull up our worksheet on the zero over here and this column is checking these two numbers so these two columns are the same they're calculating different ways this one's with a formula this one's with a category it's really nice to have the category here because it also allows you to drill down on it so this one allows you to drill down on it this one gives you a double check this one might be redundant you might not need that because you could see these two tie out but if you have a column of zeros it's just so easy to see those zeros and this report's not too big that that's not too bad to be able to see so these last three columns then if we input everything you know properly in this in the new system we set up with these an unassigned means that these should all be zeros and again these we know why these are not but you know if we did it that way we can then see all these are zeros not a problem these are here you don't have to do that but like I say it could be a cleaner report and you can kind of double check on this and then you could take this report and make our our final reports which will basically be this report with just these first three columns and I could just make another report this is my internal worksheet that helps me to have my check figures in it then we can have an external report which is the one that of course we would be providing to whoever needs it the board or whatever with minor adjustments we might make within Excel however a lot of the stuff we can do is actually in the system with this formatting of the reports


Right now thousands of gun rights activists, white nationalists, militia groups, all swarming the Virginia state capital. There are a lot of people nervous about what's going to happen. Authorities in Richmond are on high alert. It could be a tense day. Just polarization, what may happen in Virginia.  White nationalists. White nationalists. White nationalists. White nationalist groups. White supremacists. White supremacists. White supremacists. White extremists. The entire rally stands in opposition to the meaning of this day. It's been a few days since the pro-2nd amendment rally in Virginia and many have already commented on it. But I want to take a look back at past protests and show how the media has always deceptively reported on left wing protest versus right wing protest. Before the Virginia rally, we all knew that they would demonize it and the attendees.  They've been doing this for as long as I've been paying attention. There's certainly a lot of concern here. Raising fears of a dangerous confrontation. It could be violence. There is real concern there about what the intention is behind this. There's a lot of concern about the potential for violence. To spark violence, tensions high in Virginia may cause violence there. Northam clearly trying to evade another Charlottesville. In Charlottesville. Could see a repeat of what we saw in 2017 in Charlottesville. Similar to what we saw in Charlottesville. Worrying about a repeat of Charlottesville. First off, we need to talk about the media's use of the terms left wing and right wing. The media and the democrats use right wing as a slur. To them, right wing is synonymous with racism and hatred. That's how the media uses the label and they use it very often. Along with right wing extremists, partisan republican, and hard right. Not so much when it comes to left wing, hard left, far left, liberal, socialist, or communist. Take this study done by a writer from the national review. All he had to do is a nexus database search for these politically loaded terms and this is what he found. The term partisan republican has turned up 85 times in the English language news media over the past 90 days. By contrast, the term partisan democrat has turned up only 58 times in the same time period. That's a ratio of 1.5 to 1. The term extremist. A nexus search of extreme right over the past month scored 212 mentions. A nexus search of extreme left over the past month yielded 58 items. This search reveals that the print media label right wingers extreme nearly four times more often than they label left wingers extreme. How about hard right and left? Nexus search for print media uses of hard right over the past 90 days, 683. Nexus search for print media uses of hard left over the past 90 days, 312. Again, the media are apt to label an individual or group hard right more than twice as often as they are apt to label an individual or group hard left. Now let me just say that while I'm not surprised by the bias shown in this basic study, I am kind of surprised that the media use those terms at all in regards to left wingers. I'd be hard pressed to remember any time in recent memory that I've heard the media use any of these terms in regards of left wingers or Democrats. After the re-election of George W. Bush, the media research council did another study and found the same imbalance in the use of these terms. So I think it's pretty obvious at this point that the media portrays their political opposition in the worst possible terms and their own side in the best possible terms. Going back to the George W. Bush years, just like Trump, protests began the day he took office. And the media always portrayed those protests in the most positive light. Take for example the extreme left wing protests and calls for violence against Bush. The media never raised a fuss and of course they defended them as a sacred American tradition. You might remember a woman named Cindy Sheehan who was a hero in the media for protesting Bush. At the time, anybody who dared criticize any of these protesters was shouted down by both the Democrats and the media. I am sick and tired of people who say that if you debate and you disagree with this administration, somehow you're not patriotic and we should stand up and say- Don't forget though, it's different when they do it and those standards go right out the window when a Democrat is in the White House. When Obama took office and protests erupted against him, the media and Democrats suddenly flipped and began demonizing these protesters as racist, white supremacists and all the typical labels that we've become familiar with. They even turned on Cindy Sheehan who was at least consistent and began protesting Obama. So-called journalists who championed her under Bush suddenly turned on her and told her enough already. CNN who loved their anti-Bush protests suddenly were lashing out at regular people who were just exercising their right to protest. Catholic schoolgirls, marked on Jackson Square, they and their teachers say more money is needed to fix the levies and they hope the president would stop by after his meeting with business leaders. But while a lookalike showed up with a wad of cash, Mr. Bush did not. This guy, would you come over here with me please? You know, what is this supposed to mean? What do you mean by that?   He's the president of the United States.  Do you realize how offensive that is? Hey, sorry for the interruption, but I just wanted to give you all a quick update on this channel. We need to keep trying to open people's eyes to the media's deception. You can help do that by liking and sharing this video. If you know somebody who fears supposed right-wingers, show them the examples that I laid out here and perhaps they'll be a little bit more skeptical during the next media con job. Not only is YouTube demonetizing everything I upload, but now they're not even giving me my manual reviews. Look, I love what I do, and I'm gonna do it regardless of the money. But the hard fact is, it takes a lot of time to create these videos, and I need to be making money with that time. If you would like to support this channel and my mission, consider joining me on Subscribestar, Patreon, or just sending a donation on PayPal. With this support, I can continue to grow and improve this channel. However you decide to support this channel, just know that I deeply appreciate it. And it just got worse. You know how Trump is attacked every single day in the media? Well back then it was the Tea Party. The Tea Party protests were constantly framed as racist, right-wing fanatics and militias. Any time an act of violence occurred anywhere in the country, the media jumped at the chance to somehow blame the Tea Party. And something that might be significant. There was a Jim Holmes of Aurora Colorado page on the Colorado Tea Party site as well. Talking about him joining the Tea Party last year. I don't know much about him. An earlier report that I had was incorrect that he was connected with the Tea Party. In fact, that's a different Jim Holmes. A good example today would be how the media so quickly jumped on the Justy Smollett hoax. Or how they instantly framed the Covington boys as the aggressors. The media was more interested in confirming biases than getting to the truth. But just like the protesters in Virginia, the Tea Party rallies were always peaceful and they even cleaned up their trash afterwards. You see, the Tea Party had to go above and beyond to look good because the media was looking for any reason to demonize them. And because of this, the media literally had to make up incidents. Like when MSNBC edited footage of a black man at a Tea Party rally and cropped it so you couldn't tell.  This leads me to MSNBC where on Tuesday, a contestant brewer filed a report about health care protesters showing up armed. In it, she used tape of that same black guy with the rifle and said this. And the reason we're talking about this, a lot of talk here Dylan, because people feel like yes, there are Second Amendment rights for sure. But also there are questions about whether this has a racial overtones. I mean, here you have a man of color in the presidency and white people showing up with guns strapped to their waist. But like I said, the guy was black, but you never would have known because MSNBC had strategically edited the tape. So the race of the armed dude wasn't revealed. Or how about when the Democrats and their media coordinated to manufacture a lie that Tea Partyers spit on black congressman Emmanuel Cleaver? Despite there being cameras everywhere around the time and place that he claims this happened, no evidence ever surfaced to back up the claims. Oh, but that didn't stop the media from getting as much use out of the claim as they could. Repeating the basis claim over and over for weeks. Breibart.com even offered $100,000 reward to anybody that could present audio or visual evidence. It was never claimed. And that's why we call them the drive-by media. Now let's take a look at violent left-wing rallies that occurred around the same time that the Tea Party rallies were going on. Those mostly peaceful protests involving thousands across the country on May Day turned violent in the northwest with what police called a riot in Portland, Oregon and nine officers injured in downtown Olympia, Washington. As many as 100 protesters clashed with police in those two cities with smoke bombs, rocks and bottles being thrown and fires set. Those small pockets of violence marred peaceful demonstrations with marchers protesting the Trump administration's immigration and labor policies. The city was forced to shut down its May Day march after the peaceful protest to support labor and immigration rights turned violent. Anarchists clashed with officers, trashing police vehicles and some businesses. For the most part, demonstrators came together peacefully hoping to keep attention. Notice how they hedge when it comes to the left-wing rallies. They make an obvious effort to downplay the violence and separate the peaceful people from the violent ones.  How about Antifa or BLM? When BLM members and supporters began ambushing police officers, the media went out of their way to distance the group from those terrorists. Exactly the opposite of what they do to the right. That's what the Black Lives Matter protests have been about. That's what the policing protests have been about. They have never been anti-police. They have been about ensuring that the lives of Black people are protected and that there's proper policing in our communities. Are you seeing this pattern yet? When violent left-wing activists rally or protest, they're protected and their violence is downplayed. When peaceful right-leading activists rally or protest, the media exaggerates violence and demonizes all the people. What we witnessed in Virginia was just more of this. That's all I got for you today, folks. Please like, share, and subscribe. Thanks for watching. Keep coming back. I'll see you next time.


This is Witchbase news for Friday the 5th of January 2024, I'm CMDR Buur In Elite Dangerous news this week, a new must have tool for explorers and exobiologists is released. The first great planetary expedition plans an anniversary celebration, there's an excellent roundup of Elite Dangerous in 2023 and are the Alliance lining up for a Thargoid ground war. You know how this bit goes, please like, subscribe and ding that little bell so that YouTube shows you all our content and if you'd like to directly help our work here at the Buur Pit you can also support us through Patreon, links to that and everything else are in the description below. Five years ago the galaxy's favourite daredevil SRV Keneval Alec Turner was the originator and host of the first great planetary expedition. The first time a group of commanders had circumnavigated an entire planet in SRVs as a weeks long organised event. The target planet was Kume in the Chai Hercules system and this year Alec has begun canvassing to see if any players would be interested in recreating the event for its 5th anniversary in March. The plan is to recreate the event exactly as was terrain and equipment wise and as the arrival of Odyssey significantly changed planetary surfaces forever it will mean firing up the game in legacy mode. This does however have the advantage of running adjacent to the live game meaning your live character will still be available wherever to do whatever. If you're interested in recreating your experiences of the event or perhaps participating for the first time if you missed it 5 years ago then head over to the planetary circumnavigation discord server which you'll find linked below this video. Colin Ford otherwise known as Commander Phoenix Defier of the Lave Radio podcast has published part 1 of his excellent summary of the last year of updates to Elite Dangerous. The first part of the summary covers updates 14 and 15, the arrival of the game's first fully dynamic and emergent Thargoid invasion and the subsequent deployment of the authorous variant of the Interceptor and the Glaive Hunter class vessel into the game. As well as providing a solid summary of the year's content updates Colin also offers some well-reasoned and balanced criticism of the year's updates, most notably its almost complete focus on all things Thargoid and the problems that players had hardcore and casual alike dealing with the unique problems presented by the introduction of systems like the Glaive. It's easy to overlook just how much has been added in what has been one of Elite's more turbulent in-game years but Colin's video does an excellent job of rounding up updates 14 and 15 and I'm very much looking forward to hearing what he has to say about the last two updates of last year in part 2 of the review. You will of course find Colin's video linked in the description below this one. Most large portions of humanity have been on a seasonal and festive yearly break, such trivialities over of no concern to the evading slavering insectoidal hordes of Thargoids massing on the southern borders of the bubble. There was a slight increase in the number of alert systems under threat of invasion over the festive period but it was nothing outside of the usual ebb and flow that particular systems state tends to see. In the run up to the end of this year, the bubble had seen a drop off in the number of actual successful invasions. So much so in fact that for weeks running there were in fact no invasions at all. On one hand that's obviously a positive thing but no invasion also means the gameplay associated with them goes away, most notably station rescues and hauling whilst under fire from Thargoids and the associated AX gameplay. Fortunately, or indeed unfortunately depending on where you stand personally, the invasion level upped again slightly over the Christmas period ensuring that the aforementioned gameplay is now an option again. Whilst the total number of Thargoid controlled systems has increased again of late, up to 323 from its previous low of 288, it is still nowhere near its all time high of 1186 from May this year, 6 months after the initial invasion began with the arrival of the first of the 8 player tracked Stargoids which was codenamed Taranis. As the war has progressed so have the options for players to engage in it, one of the more gated of those options has been the extraction of human captive filled bio-storage capsules from the Thargoid Titan mother ships. Whilst the rescues of the millions of captured humans began, the sticky issue of what to do with the recovered and revived individuals began being discussed on the in-game Galnet newsfeed and as of this video at least, the three superpowers Alliance, Federation and Empire have now made their respective positions clear. Whilst the rescued captives had shown largely little to no physical effects from their time inside the hive, there is still the question of whether something has been done to them that we simply can't detect and whether returning these individuals to the general galactic populace can yet be entirely safe, the fear being that they have been unwittingly altered during their incarceration to serve as a Trojan horse in some manner taking human society down from the inside once activated. The Federation and Empire have made their positions abundantly clear and are taking a cautious hardline approach, keeping their rescued citizens in quarantine for the foreseeable future. The Alliance however has opted to be a bit more touchy-feely on the whole issue and has now released its captured citizens. It does seem extremely unlikely that Fdev would go to the lengths that they have to spin out this particular yarn if they had no intention of following it up somehow and so if the returnees are to start randomly hiding all the TV remotes, changing the wifi password, exploding or eating or assimilating their nearest and dearest then it seems it's likely going to happen in Alliance space and if we had our guess it would likely be with the arrival of update 18. Just to a fortuitously timed tweet from Canon Research over the holiday period, we discovered a third party tool aimed squarely at the exobiology community in the game just as my own second account character was heading out to start his own exobiology adventure and the tool has in just one week become an absolutely vital must have for me. The tool, called SRV Survey by Commander Greening 2001 provides extra on-screen HUD elements when a player is near a planet in an SRV on foot or in a ship. The extra HUD information provides tracking on the latest organic scan showing in an easy to read diagrammatic form where the last scan was taken and how far away from that particular scan you need to be to gain sufficient genetic diversity to make your next scan for that item. The tool also estimates how much each scan is worth and keeps track of what life forms you've scanned on a planet and what ones you haven't. The tool also provides aiming guidance towards specific latitude and longitude coordinates on a planet's surface and further can track visited areas and the locations of items within guardian ruins and structures and assist with detailed surveys of guardian sites as well as providing a sortable list of all known guardian sites. I've only touched on just some of the functionality that the tool has so check out the link in the video description to get the full rundown of what else the tool provides if you're interested. Overall for my own exploration and exobio I've been running SRV Survey alongside Elite Observatory and found it to be an excellent complimentary companion app and I now wouldn't consider exploring without having it running highly recommended. Are you planning on driving round an entire planet? What was your favorite update from last year and what would you like to see added in the year ahead? Let us know in the comments below. That's it for now. Thanks very much for watching. We'll be back later this week with more videos. Until then, 07 Commanders, follow the Greens on the way out and do keep clear of the toast rack. We very much look forward to seeing you next time.