Thanks, Francesc. So, hi. My name is Matt Baustock. I am a platform engineer working for CloudFare in London. I'm interested in distributed systems and performance and until September I was studying a masters in computer science at night school for the last two years, which was hard but super interesting. So today I want to talk to you about building and designing a distributed data store, which I did as part of my master's final project. So this won't be a talk about stuff I'm working on at work. It's really a personal project and the project is called Timbala. That's the logo. That's actually the second logo because logos are important. And it was originally called Athens DB. So if you see references to Athens DB, that's why. And so Timbala is a distributed time series database or would be if it was finished. Distributed systems are a huge topic. I won't be able to explain everything during this talk but hopefully you'll be able to take something away. So it's quite a broad talk. And I'm going to talk really about how I approach the problem. So it's more about the design of building a system like this and doing that in Go rather than going into like very deep-deck technical details. So just a disclaimer, Timbala is not production ready. So please, please don't use it for anything you care about in production. So what is distributed? Why am I talking about distributed systems? Well, a distributed system is a system where you essentially have coordination between network computers. And this is how our Wikipedia defines it. And I think the coordination part is really important and it's really hard as we'll find out. So why distributed? Why do we need a distributed system? Well, first of all, we want to survive the failure of individual servers. So if an individual server dies, we want the system to keep working. And we also want to be able to add more servers to meet demand. So if we have it's a distributed time series database. So if we have lots of users sending metrics, we want to be able to scale up the number of servers to cope with that demand. So otherwise known as horizontal scaling. So there's a great list of fallacies of distributed computing that came out of some micro systems. I think it's got some great things in here. Like the network is reliable. If you're running a distributed system that tells you that the network must be reliable for the system to work, be very distrustful of it. So this kind of thing makes building distributed systems interesting. And so the use case for a Timbala was to create a durable and long-term storage system for metrics. And so I've worked a lot with Prometheus and really what I wanted was a place to store my Prometheus metrics over a long period of time, say five to ten years. And it was important that this system could store multi-dimensional metrics. So metrics defined using labels or tags. And it also must be also capable of storing more metrics than could be accommodated by a single commodity server. So why not just use the cloud, right? Everyone's using the cloud. You know, you could just use like S3, put your data in there. Well, first of all, it wouldn't make for a very good master's project. So that was the first thing. But also sometimes you want to run stuff on premise, maybe for because you don't want to run your data. You don't want to put your data in the cloud. And you have enough data that you need a system that can handle a lot, a reasonable amount of data. But maybe it's not so much data that you want to run a system like say Hadoop or stuff, which are big complex systems and can be difficult to operate. So the other use case I had in mind was the system needed to be highly performance. So it needed to be able to ingest a lot of metrics very quickly. And I also wanted it to be really easy to operate. I think this is really important with distributed systems that you have to bear in mind how they're going to be operated in production. So being able to see what is happening in the system at any point in time was really important. So what are the requirements? So well, first of all, the system needs to be able to shard the data. So it needs to be able to store more data than could fit in a single node. And by sharding, I mean, essentially spreading data across multiple servers by splitting it up into chunks. It also, the system also needed to replicate data. So we wanted to make copies of data in case a single node dies. We would still have a copy of the data on one of the other servers. I mentioned throughput. So the system needs to be highly available for data ingestion specifically. So I focused on high availability for the right path because when you're reading data, when you're querying the system, a human can always retry. You want to avoid that if at all possible. But if worse comes to worse, they can do that. If your ingestion, if your right path is not available, then the data that you need to ingest is going to start backing up. You're going to have back pressure. And then when you try to catch up, you need to ingest your normal traffic plus the traffic that is backlogged as well. So we want to try and avoid that and really make sure that the right path is available as possible. And operational simplicity. So it needs to be simple to operate and maintain. I wanted to keep the number of configuration options to a minimum, so less things to tune, which hopefully would translate to less things to get wrong. And also add good instrumentation, so logging metrics and tracing so that you can see if a certain client hit a given server, which other servers that request had to traverse through to be able to serve a request. And the other requirement I had was interoperability with Prometheus. So I mentioned the original use case I had in mind for this was to store Prometheus data long-term. So I wanted to reuse Prometheus best features, which is the query language and its data model. And also it has APIs already defined. So I didn't want to have to redesign those APIs when I could reuse those. So that helps me to focus the project. And it allowed me to focus really on the distributed part of the system, which was the part that was most interesting for this project. So it's easy to think about distributed systems if you have a really small amount of data because, you know, you could just put it on one box and it's not really a distributed system. So I think it helps to kind of at least have a target to work with in terms of numbers. So I just looked at Cloudflare's OpenTSTB installation. This is where we keep metrics for long-term storage currently. And in mid-2017, we're storing 700,000 data points per second. So 700,000 metrics observations ingested per second and 70 million unique time series. And those are multi-dimensional metrics. So 70 million unique metrics. So this kind of gave me a goal and you're always going to achieve this for my master's project, but at least helped me to think about what the constraints of the system would be and how I'd need to design it. So how do you build a distributed system? Like where do you start? You have all these servers talking to each other. Like it seems like really complex and difficult. So I had a hard time coming up with an MVP and I didn't have a lot of time to build this because I need to do it on evenings. So I started thinking about ingestion versus querying. So the read and the write path. That was one of the first places I started. And then I thought, well, how can I also reduce the scope of what I need to do? Well, reusing third-party code wherever possible. So reusing those Prometheus libraries was one of the most beneficial decisions in the project. And so I reused the PromQL query library. So I didn't need to reimplement my query engine. And I reused the API code as well. So the system would be API compatible with Prometheus. So any existing integrations would work with it. So I came up with some milestones. The first one was to just get the system working on a single node. So no coordination, no communication between servers. Just be able to store data on a single server and then query it back out afterwards. And then the next milestone was to actually get the servers talking to each other, start sharding the data across the nodes, replicating the data so that we have enough copies to survive single node failures, and then also look at rebalancing data between servers so that we can recover from server loss. And then there were other things I wanted to do if I could take this beyond a minimum viable product. So one of those things was read repair. So that's the ability to, as you're reading data, you can see if a given server is missing some data and basically tell it, hey, you're missing data, you should have a copy of this. So that was one thing. A hinted handoff is the ability to store data on behalf of another node in the system so that if that node's down, you can basically hold onto its data until it comes back up and then send that data across to it. And then the other thing I wanted to look at was active anti-entropy, which is a fancy way of saying having a background process that runs and tries to detect missing data in data that you might not read very frequently. So with read repair, read repair only works for data that you're reading, and with metrics you're often reading just very recent data. So active anti-entropy would allow you to repair data that is maybe further back in time. But I was pretty sure I wouldn't be able to finish that for this project. So I was like, okay, this is cool, this is really exciting. I'm going to start reading research and papers. And this was really cool. I read all these things about Numer and write amplification and how to work with SSDs and M-App and hashing and all this kind of stuff. And it was super interesting. But yeah, there's so much to work with here, and I needed to start small. I needed to get something working. So let's ignore that for now. So back to the essentials. So what did I need to think about for the system to work? Well, the servers need to be able to talk to each other, need to coordinate. Peter Borgon wrote a blog post about his system for ingesting logs called OKLog. And that was really influential to me in terms of framing the problem in terms of coordination between servers. And then indexing, how do you know where your data is stored in the system? How do you store the data on disk? How do you know which nodes should be in the cluster? And when you know which nodes should be in the cluster, how do you decide where to send the data between them? And then finally, how will the system fail because it will fail at some point? So to try to understand the problem more, let's consider some of the traits or assumptions we can make about time series data. So the first one I made was that data once ingested would be immutable. So basically, the data would be append only. So there would be no need to worry about updates to the data. So we don't have to worry about, like, updating a row essentially in a relational database or having to manage multiple versions of the same data. So that helps relax some of the requirements because it makes it... we don't have to worry about managing all those versions. And so the other thing about metrics is the data types can be really simple. So time series can include events, but in this case I was just focused on numbers. Numbers can compress really well. Prometheus 2.0 and above use is a variant of the gorilla compression algorithm from Facebook and this uses double delta compression for 64-bit floats. So it takes the difference between the two numbers and then it takes the difference between that difference and it uses that to compress the data. And if you're interested, the gorilla paper explains how that works. So the other thing to bear in mind with time series data is the tension between the read and the write patterns. And this is really important when thinking about design the system. So you essentially have continuous writes across the majority of your individual time series. So in the case of Cloudflare, for example, we had 70 million unique time series, we might have maybe 40 million of those time series being written to within the last five minutes. So you have a lot of updates across a broad range of data, but then when you're reading back from the system, you're often reading for a given time range of data. So you have this tension between the write path, where you're searching many different time series and the read path where you're going across time. So that was something that was difficult to... There's one of the most interesting properties of storing time series data. And Fabian from the Prometheus project goes into this in more detail in his blog post. So I looked up prior, right? I was like, okay, what exists currently? I won't go into detail now, but the main thing I drew from these existing systems was the idea of storing data in columns, in the stores, and from Amazon's Dynamo paper, the idea of using consistent hashing to determine where to place data in the system. So I mentioned coordination, and coordination, being able to think about the system in terms of coordination was really helpful. And the thing I realized was if I wanted to support a high throughput on ingestion, I wanted to keep coordination to an absolute minimum because that would help reduce the complexity of the system and, as a result, make it more reliable. And also avoid coordination bottlenecks because those bottlenecks could be a bottleneck for the ingestion throughput. So the other thing was to know which servers were part of the cluster at any given time. So I could just do this statically. I could just tell each server what other servers exist. But that's going to be kind of painful, especially if you had a lot of nodes. And also I needed to know when a node fails, so being able to detect a node failure. So for that, I used the memberless library. This is used by Hashicope Surf and also Consul. It's a Go library. It uses the swim gossip protocol. And by gossip protocol, I mean that the servers talk to each other using UDP, and they synchronize their state with each other using UDP. And then occasionally they have a TCP mechanism for reliably synchronizing their state.  And swim has some really nice properties. One of them is that you can detect if a node is still alive, even if you can't access it directly. So the nodes can snitch on each other, and you can indirectly detect if a server is still alive. So that worked really well. The membership library was really easy to integrate. Peter Morgan also uses this in OKlog. And it was a lot easier than I thought to get this up and running. So that was really, really good to use. So indexing, how do you find the data quickly? You have all these nodes in the cluster. Where do you know where your data is? So I could use a centralized index, and I've worked with the RAF protocol before. I knew a bit about consensus, and I started thinking, I'm sure I need consensus for this system. And then I thought about it, and I thought, well, actually, I probably only need consensus for the centralized index. You have a consistent view of what should exist in the system at any one time. But to do that, you need to be able to coordinate between servers so that you can decide what that centralized index should be. And that's likely to become a bottleneck at high-ingestion volumes. So I wanted to try and avoid that if possible. So the other thing you could do is just use a local index and have each server know about what it stores itself. The big disadvantage to this is that if you lose data, you don't really know exactly what you've lost, because if you've lost the index along with your data, then you don't know what you've lost. But maybe we could work with this. Maybe we could do something. Dynamo, Cassandra, and React, they all use this idea of consistent hashing to determine where data should go. So I started looking at that. And so I was looking at data placement and how we place data on the different servers. So consistent hashing is essentially a way of placing items into buckets. And hashing is just a way of using maths to put items into buckets. And consistent hashing aims to keep the disruption to a minimum when the number of buckets changes. And so in our system, that translates to when the number of nodes in the cluster changes, then we want to keep the disruption to a minimum, and we want the amount of data that is displaced to another server to stay to a minimum as well. So in this example, if we have five nodes in a cluster and one node fails, we should only a fifth of the data should have to move to another node, assuming that we're not able to replace that node immediately. So I looked into consistent hashing algorithms. There's a decision record on the GitHub repository for this project that goes into more detail. And I'll show these slides afterwards. Basically, the first one I looked at was the cargo algorithm. And then I kept it writing in and looked at jump hash. I'd encourage you to look at everything to the papers here. I want to explain them in detail right now because I don't have the time. But I'll just show you the jump hash implementation, which I think is super elegant. Jump hash is an improvement over the cargo algorithm because it uses less memory and it's a lot faster. And the thing I really like about it is that that stood out to me was that it uses this magic constant, which is a 64-bit congruential random number generator. And it uses this magic constant to make this faster. So Damien Grisky has an implementation of this. And this is the whole jump hash algorithm. So the other thing I needed to figure out was while the hash function that I use in consistent hashing needs a partition key. So I needed to figure out what that partition key could be and the choice of partition key could have a big impact on how many nodes you have to query when you're querying data and also how many nodes are ingesting data at any one point in time. So again, I've gone into detail on the repository for how to choose this. But what to include in this was a critical decision in the system. And we need to store three copies of each chart, of each copy of data. So I achieved this by prepending the replica number to the partition key. So then I was like, okay, well, I know where to put the data and how to index it, but how do I store it on disk? And I started looking at different kind of structures, different libraries. I started working with RockDB and storage is really hard. I mean, this could have been a project in itself. And luckily, around the same time, Fabian and the Prometheus team were working on this and I thought, well, I'm already integrating heavily with Prometheus, so why don't I just use this library? So the interfaces for this library were really clean to use. The conclusion I got from this was that good programmers or lazy programmers constructively so, because if you can reuse something, then why build it yourself? So I solved the on disk storage problem by using an existing library. So this is the architecture that I came up with. So no centralized index to keep the ingestion throughput high. So the only shared state is node metadata. Each node in the system has the same role and any node can receive data and any node can be queried as well. So what about testing? Well, I found that integration tests were the most useful because I could quickly iterate on the system without having to worry about breaking my unit tests. And so integration tests, I had unit tests as well, but integration tests really gave me the most value. So for the unit tests, one thing I looked at is how even is the data distribution across the nodes in the cluster? So I wanted to make sure that no single node was storing more data than the others. And also are all replicas of the data stored on separate nodes. So I wrote the data. I want to make sure they don't all end up on the same node. So I wrote unit tests to do this with little histograms. And you can build histograms like this using the Go testing library really simply.  And I used the standard deviation to measure what the distribution was between nodes. And I used the Go sub-tests to test this against different numbers of replicas and different numbers of nodes in the cluster. And this was really helpful because when I changed the consistent hashing algorithm, I could actually see the difference and see the improvement in balance when I switched to jump hash. So the other thing I looked at was data displacement. So if I remove a node, how much data has to move. And this helped me find a bug because I was quoting the list of nodes alphabetically because I figured that would make it more deterministic and determinism is a good thing. But in this case, it didn't actually help because it worked against the jump hash, the way that jump hash works. And in the jump hash paper it says that the main limitation is that buckets must be numbered sequentially. And I was treating them as names of servers rather than just numbers of buckets. So my conclusion was that each node in the cluster needed to remember in which order it joined the cluster. The other kind of tests I wrote were acceptance tests. And I did these by executing the binary itself. And that allowed me to do things like test if my command line flags were still working. And I also did things like test if I looked for certain canary metrics to make sure I hadn't forgot to register metrics. But also other things like can I query? Can I find the result of one plus one? And can I query data out of the system? I mentioned the integration test as being the most effective. There was some crossover between these and the acceptance tests. But they were by far, but the integration tests focused more on the integration with other services such as Prometheus. And I actually had Prometheus writing data into the system. And then I was able to query it back out again to make sure that that worked. And when I queried it back out I would use the official Prometheus client library so I could be sure that it worked with both the Prometheus server and the official client libraries. And I used Docker Compose for this for portability because it was really easy to get set up. And I had the Docker Compose integration test running in Travis CI for every pull request. And this actually worked really well. So I'd highly recommend this. I also set up a benchmarking framework so I could see how the system was working as it's running. And that allowed me to do things like my throughput and also CPU usage and memory. And again I used the benchmarking framework with Harness in using Docker Compose. I'll just go through these. I used Pprof to help determine where I could speed things up. I think that's been covered in a later talk in more detail so I'll just skip through that. And the last thing I want to say is that I didn't get the chance to do this but I really wanted to do it is in failure injection with Docker Compose you can use failure injection to test how your distributed system manages with failure. So you can have a privileged Docker container that can stop nodes in the cluster, inject packet loss, latency and that allows you to see how well the gossip protocol works and how well the system copes with failure. So conclusions. I think the greatest challenge in writing distributed systems is anticipating how they will fail and how they lose data. The implementation is already hard in itself but it's even harder to figure out how they're going to fail. And the other conclusion I took away is make sure you understand the trade-offs that your production systems are making because they are making trade-offs. Finally, use DEP. It's awesome so thank you so much to Sam and the other contributors to DEP. And if you're interested in reading more all the links are up here and I'll share the slides on the FOSDEM site afterwards. Thank you. Before we do the Q&A before we do the Q&A I want those two people that are taking care of the doors to go to the doors. So do not leave yet just let you go to that door. Marcelo, can you go to that door? Oh, perfect, okay. Because otherwise it's going to be a chaos in a minute because there's a huge amount of people outside already. Now, you're going to start preparing and in the meanwhile we have the Q&A. Thank you. Any questions? Yep. So the question was what tools that I used to benchmark the system. So I wrote a little tool that would generate load. It generated random metrics using a seed so that they would be generated deterministically and the benchmarks run in docker compose. So I'd spin up three nodes of the cluster, generate metrics, ingest those and then I'd see how they performed in Prometheus. Yes? So I'm not sure I fully understood the question but I think it was, did the system provide one interface to query all of the metrics? No, so this system is designed to stand alone so it integrates with Prometheus but you could use it without Prometheus. It implements all the Prometheus APIs essentially, the majority. Any other questions? Thank you.


He's a world-class Grandmaster who's won several elite events including the Gibraltar Masters. He was the President of the Association of Chess Professionals. Today, he joins us as Director-General Fide. We are very happy to have with us Emil Sutovsky. Welcome to Gibraltar, Emil. It's an absolute pleasure to have you with us. Yeah, thank you. It's always a pleasure being here. Now you've been here several times. Your relationship with this event goes way long back. What's it like to be here but not play? Well, a very strange feeling indeed. I have been playing nine or ten tournaments here starting from 2005. And of course it was always a pleasure to play. I can say that it was one of the most successful places for me in terms as a player. And also previously we had a very good cooperation between ACP and Gibraltar. So it is indeed a special place for me. We are entering a tournament venue seeing all the colleagues sitting and playing and not playing myself. It is a bit of unusual but I'm starting to getting used to that. Right. Now you mentioned you came here for the first time in 2005. It's also the year you won the Gibraltar Masters. How have you seen the tournament evolve over the years? Well, I remember when it started I think it was 2002 first. Then the announcement came that it will be a new tournament in Gibraltar. I remember at that time Stewards Reuben was organising it. And well, nobody even knew properly how to get here. I mean for the chess players it was a new place and from year to year it went stronger and stronger. When I won it in 2005, I shared the first place in 2005, it had several very good players but still it was not the best open tournament by no means. But then few years passed and I think for the next decade it was just absolutely by far clearly the strongest open tournament in the world and still it managed to retain the atmosphere of a big festival. It is very important actually because you have a lot of amateur players, you have club players, you have players like from 60 countries every year coming in. You have a lot of women players so it is still a unique tournament. It preserves its strengths, it's probably now the second strongest open tournament in the world after Isle of Man. But at the same time it's the first choice for many players and I remember when we conducted a poll in ACP about the favourite open tournament and Gibraltar won it like four or five years in succession. Yes absolutely and it is one of the only true opens in the world with no rating cut-offs. Yes, that is also important. Some organisers put this rating bar on 2200, 2300, here you don't have a rating cut-off so definitely it provides a chance for players with maybe 1800, 1900, 2000 at least to play some against strong grandmasters and it's also quite special for this event. It is really a festival I think, that's one of the things that makes chess specials and you have a top professional like Leveronian or Hikari Nakamura or Maxim Vashilagrov playing here and nearby you could occasionally see it on the adjudged boards, you have players who are maybe 1900s and so on. Absolutely and now you were also the president of the Association of Chess Professionals before you took on the role of Director General Fide. When you look back at the success of ACP, how do you feel about it and which achievements for you have been very special? Well I think we did a decent work in the time I was a president, I was president for seven years and we had so many projects which we managed to implement, one of them was contacting with all organizers with major tournaments and providing wild cards for players so we established a sort of qualifying system that allowed players to qualify to the top events like like to Bill, like to Bekovsky so they qualified. We established an agreement also with organizers of open tournaments that provided exceptional conditions for our players like it happened here and you brought so many occasions, it happened in Isle of Man and it happened in Qatar and it happened in Bill once. So it was really fruitful cooperation. Another side of our activity which was always very important for me it was the support for chess veterans. We established a program together with the then administration of Fide and it ran successfully for four years and we managed to support about 25 veteran players with the stipends and the words and they helped them in not so easy years of their life after their career was way after its peak. So it was an important topic. We were also what I considered to be very important. We were maybe not that strong but everybody knew that ACP is an organization that you can approach and can ask for an advice for help and we were always there for the players. Always there, it's not like we always could help but we always would try to do it and on many occasions we did. These very feelings, I want this very approach, I want to convey now through Fide because it is my responsibility on what I'm doing now to let everyone understand that Fide is changing its policies. Fide should become much more friendly towards chess community, not only professional players. I'm more in charge of the professional players and those who are involved in world championship cycles and so on but in general Fide should become much more open, much transparent but also much more friendly that you approach Fide and you know that you will get an answer. That's really nice to hear and especially ACP was often the voice of chess players across the world and the fact that you want to translate that for your work with Fide now. It's something that I'm sure the chess world looks forward to. Tell us a little more about your role and responsibility as Director General Fide. Well, my position involves several important duties. One of it is I'm being in charge also as Director General and Chairman of the Global Strategy Commission of Fide of everything related to the world championship cycle. It connected to World Championship match itself, candidates, Grand Prix, Ceres, Olympics, World Team Championships and so on and so on, World Rapid. And it was important for us to establish a proper mechanism for decision making and taking there, establish a proper cooperation with partners because previously a lot of these things were so untransparent that we really as ACP we saw it from inside that it couldn't continue like that. Now this whole policy is changing and if you saw it was the very first event we organized by ourselves in St. Petersburg we managed to make it in absolutely different level to have people coming to visit the venue, to be engaged with this massive chess what's called FIST and it was great. I really, it's like self praising but it was great. I was there and I enjoyed every minute when I saw the spectators, kids, veterans coming enjoying the atmosphere. Of course, very important thing is to try and establish proper cooperation between chess and corporate world. We have been talking about that for years but doing almost nothing. We are going to change it and one of the steps is going to have a bidding procedure tender for every major event like World Championship match or candidates and we are going to do that. It is also important to establish some sort of understanding where we are heading to and the Global Strategy Commission which I chair. We have to envision what will happen with chess in 5 years, 10 years. How do we respond to the challenges of today's world? Because it's a bit different from what it was in the 90s. Let's say you have a chess boom in Asia. How do we make it happen to something even bigger? Let's say, like in India for example. 20 years ago there was almost no India on the chess map except for Vishay and now it's completely different and things are changing and we have to think about new formats, about new ways to attract spectators, new ways to communicate with sponsors. It's a lot of work and we are trying to do it in the best way. Absolutely. Now as president of the ACP you were in close contact with the old FIDE and now you are part of the new FIDE. Personally for you, what are the big differences between these two administrations? Well, there are so many differences. I can start counting and it would be... I think it's not for me to evaluate, I think. The proper way would be to work properly and to see public responses for what we are doing. I do think we have a sort of support from general chess society and the feedback we are getting is very positive. It's understandable that this is a transition period now and some people can feel that they are not very happy with what we are doing. Some decisions may seem to be a bit too radical or whatever but all in all I think we've got this feeling that what we are doing is appreciated because everyone says that we work hard to do the best and I think we will keep delivering good news for chess world. Yes, I was just going to say that the current FIDE is only five months old but there have been big positive changes already in the chess world. What have been the big highlights for you? I think it's even four months old. Yeah, October 5th and then we actually started to work properly only in November after the first presidential board, all the management team was appointed. So it has been very little time indeed but I think we managed a lot of things today, really. I mean, we rescued this world rapid and bliss championship. We established a totally new system for a women's world championship cycle. We increased the prices drastically there and we are coming soon with some very important news actually. I already sort of hinted on that during the opening of the round. So it is something massive that's going on all the time and it is a huge challenge for everyone. I can say not only management team because I can say for FIDE president, who is many expected for him to be like the guy who is coming to be president but mostly a figurehead, nothing of the kind. He works as hard and maybe even harder than the management team does and we do a lot of things. What is important, we keep informing chess community so I do not think I should praise ourselves. I'd rather be expected to be praised not personally but as FIDE by the chess community. Yes, and I'm sure that the response from the chess world has in fact been phenomenal for this new FIDE. Let's move to the candidate selection because that's always a very hot topic for the chess world, especially the wild card spot. What is your opinion on it? Well, candidates has been always discussed and debated heavily how the composition should look like and obviously the public has been discussing but previously it was mostly decided behind the curtains, not this time around. We are going to assemble in three days in Vaikon. There is a commission meeting in Vaikon there and we are going to finalize all the details and I can only convey my personal belief that we should try, if possible even in this cycle, to get rid of any wild cards in the candidate's tournament. I think we should try and stick to the format which will allow all the best by sportive merits, whatever the merits are. It's always debatable but sportive merits and not a wild card selection. We have successfully done it in women's candidate tournament. As you know, women candidates will take place in Kazan 2019 in summer and we don't have a wild card there and I would strive to... It is not entirely my decision but I would strive to push for decisions that will remove the wild card per se in the candidate's tournament. In the women's cycle, this transition to the men's formula has also been very positively accepted by the chess world. It's something that we've all been waiting for. Now I want to ask Emil the chess player. As Rapid and Blitz continues to grow in popularity, there's been a lot of talk, especially after the World Championship in London where it went into tie breaks without a single game that ended in a result. Do you feel, personally, that the classical format is going to lose in popularity and we're going to see more and more Rapid and Blitz event? What is your take on this? Well, there are two sides to your question, actually. If you ask if more Rapid and Blitz are going to take place, yes, I would say so, but at the same time, we do not have to shift to make something evolutionary here or even revolutionary in this regard in terms of World Championship match. We will do adjust the format. It has already been discussed. Inside we sent a post to all the top players asking for their opinion. Actually, we sent two posts. One was about the World Championship match format and another about World Cup format. We inquired about the length of the match, how many games, what would be a preferable time control and so on, and the response, actually, even from the top players, they are actually valuing pretty much the classical part of the match. We will make some adjustments. One thing which I can already say is that it will be more dynamic, it will be less free days, because days often the match were just too often and it sort of ruins the pace, you know. But there are some ideas which has been supported by several top players. We took it into account already and once again I think we will have some sort of a decision during the meeting, but all this to be approved in March, I think for the final decision we shall have to wait till presidential board in March. But I believe that there is obvious need for a change, but not for a drastic change, but for adjustment. But yes, once again we realize that the format of rapid play or bleeds play has its appeals and it should also be more and more, let's say, promoted, but not replacing the classical championship. Not at this stage anyways. Very good point. Now Emil, you had some big announcement to make which you had mentioned in the earlier rounds here. Can you share it with us?  And the news are about our agreement with World Chess, previously known as Aegon. You know Aegon previously had control over the whole World Championship cycle. It's no more, the agreement has been signed and starting from the already next candidate tournament and World Championship match everything. It passes under the direct control of FIDE. So FIDE would be in charge of all these events, regaining control. Aegon or World Chess, I call it Aegon because everybody knows under its name, although it's for a couple of years now World Chess, will conduct Grand Prix Series in cooperation with FIDE 2019 and 2021. They preserve this right to conduct the series. FIDE will actually help financially to raise the status of these events because the Grand Prix Series we are launching. We also wanted to be very strong and to have all the best players because we also have two spots to the candidate tournament through this Grand Prix Series. But the most important part that the World Championship, which is a pinnacle of whole chess activity, which is the event everybody follows, FIDE will be in full charge and control and responsibility, of course. It is important also to notice that the Grand Prix Series changes its format and it will be, I think, rather attractive KO and knockout format with 16 players on every leg. And we expect it to be attended by the most of the top players because two spots, once again, two spots will be there. And previously, if you remember, the Grand Prix Series did have a spot but did not have a decent prize fund. And we found out that players basically had to play it even under not very convincing conditions just in order to try and qualify with thought it should not be a case. And FIDE stepped in just finding money to increase the prize funds to a decent level. This is big news. So FIDE and Aegon's agreement on the World Championship, the contract, has been terminated? Yes, it has been terminated or amended, whatever you call it this way. And the new agreement has been signed and it has been just a couple of days ago confirmed by the FIDE Presidential Board, which means we are sort of untying our hands and we are already announcing that we will stage a tender, a bidding procedure, both for candidates and for World Championship match. And the party is interested, could also take part in it. So it would not be under the curtains decision. It would be proper tender. We would be welcoming bidding procedure and everybody who believes that it is on a high level are welcome to bid. Of course, under the regulations we are going to issue. So it will be a very transparent process? Well, it will be very clear regulations. Then you submit a bid. It is not going to be a direct and very blunt one who pays more gets it. There are several factors to it. Obviously it's the level of organization, proven experience, the venue and so on. But obviously we are going to do it and I cannot confirm officially the numbers but the prize fund for the match will increase drastically. I have to say, Emil, that your style of play that enterprising and spirited play translates into your administrative roles as well? Well, maybe. But I would not take on myself the responsibility for all these decisions. Maybe the responsibility but not all the praise anyways. The responsibility I'm ready to take. But of course it's not only my decisions. It's the decisions of board. A lot has been done by president himself personally to contribute and to find the ways to attract sponsorship for these or that format. And of course the work of the whole management board which involves many people, actually it's paid off with all these developments. But I try to do my best. It sounds like great teamwork and my final question to you, Emil, is that what do you enjoy more? Do you enjoy the action over the chess board or the one in the boardroom? Well, that's a good question. I can still say that nothing was more pleasing than playing a great game of chess. At the same time I can unfortunately admit that with the years it was less and less these games I have produced. So yes, it was, let's say, there was a life in an old dog, yes. But at the same time I saw this new challenge as very, very encouraging. And when we sat down with Mr. Dvokovic to discuss what could be my role, I felt that my experience both in ACPN as a player of a high level and also as a person who knows quite a lot about how the things are regulated and done in an organizational point of view. I felt my contribution here might be more valuable than the games I still could produce over the chess board. So unfortunately I had to basically quit as a professional player. The only event which I have kept just because due to my old ties I'm playing for my team, local team in Israel, but that's the only event. Unfortunately I cannot even think of taking 10 days off and play something. I could occasionally take some time out but I would be so unprepared to play on a good level and I don't want to play poor chess. So I would rather resume it once I finish my career as an administrator. We are going to miss all your tactical masterpieces. You've produced several which have gone down in history books, but we also really look forward to your work with Fide under Mr. Dvokovic. Thank you very much, Emil. Thank you, Tanya. Thanks.


Ladies and gentlemen, the President of the United States and Mrs. Reagan, ladies and gentlemen, friends, we have felt that it's important for the President of the United States to meet a broad cross-section of a very sophisticated modernizing society. It was a hard selection, but we have some of the really remarkable here this evening. We have that our President should have an opportunity to see that Korea is indeed a diverse and wonderful modern society, and we believe the representatives here tonight truly embody that society. We're happy to have you here. It is my distinct honor to introduce to you the President of the United States of America, Ronald Reagan. Thank you. Well, ladies and gentlemen, good evening. Nancy and I are honored to be so warmly greeted by your distinguished group. We've come to Korea to demonstrate the deep and affectionate concern that the American people have for your country. Our hearts went out to you in the wake of the two murderous attacks on your citizens, and we came today to say that we'll continue to steadfastly stand by you. We hope our presence in your country will show the world our firm support for Korea. Probably the most important contribution we can make here is to continue helping protect your national security. Our shared commitment, your defense is symbolized by the presence of American soldiers standing with Koreans along the demilitarized zone. This is the shield that enables you to pursue your bold economic and political objectives. We also support your development of a democratic political system. As you know, the United States pays close attention to political developments in Korea, particularly those that are affecting democratic rights of matter very important to Americans. We do this not because we believe our security commitment gives us a right to intervene in your internal affairs, but simply because such issues are at the center of our own political ideology, and we feel are reflected then in our foreign policy. But in approaching such internal matters, I believe it's important to adhere to the discipline of diplomacy rather than indulging in public posturing. This has been the policy of our administration throughout the world. Where we feel strongly about a particular situation, we make our views known often quite candidly to the appropriate level of the government concerned. I have faith in the Korean people's ability to find a political system meeting their democratic aspirations even in the face of the heavy security challenge presented by the North. You have accomplished so much already in the face of that threat. Who would have predicted in mere 20 years ago that an impoverished Korea would become one of the world's legendary economic success legends? This was a Korean accomplishment. Your friends offered help and guidance as these were needed, but they didn't seek to dictate your course. Political development may in some respects be a more difficult process, but it too is one in which you alone must control. I respect and strongly support President Chun's pledge to turn over power constitutionally in 1988. This will be an invaluable political legacy to the Korean people, and I believe in the will and ability of the Korean people to develop the foundations required for viable democratic institutions. The shared democratic aspirations of our two peoples are important to our relationship, and continued progress toward the broadening of democracy in Korea strengthens the ties between our two countries. As you continue along this path of political evolution, you do so with our deep support, our affection, and our prayers. And again, we thank you from the bottom of our hearts for your warm and very gracious welcome from the first moment that we arrived here today. We are deeply grateful. God bless you. Enter into his gates with thanksgiving and into his courts with praise. God is spirit, and they that worship him must worship him in spirit and in truth. It's about you to turn into the inside of your folder. This is our heavenly Father. We're grateful to you this morning for this beautiful day upon which to... This I'll be reading from the book of Isaiah. This is the Lord, who will maintain justice and practice the right accepted on my altar. For my house shall be called a house of prayer for all people.  From whence cometh my health? My health comes from the Lord. He will not suffer thy foot to be moved. He that keepeth thee will not slumber. He will not be healed as it is. The Lord is thy keeper. The Lord is thy shade upon thy right hand. Starting from Colossians, therefore as God chosen set apart and enjoying his love, clothe yourselves with tenderness of heart, kindly need humility, generous patient endurance, fear one another and forgive each other. One has a grievance against another, just as the Lord has forgiven you, so do you. But crown me all with love, which is a perfect band of union. And let the peace of Christ reach your goal in one value, habituate in your heart. And be thankful. That is, in reaching message of Christ as a mental role in your lives as an instructor and a homage to one another, in all wisdom, exam, and him as a spiritual song, war will be to eat all in the name of the Jesus through whom you are offering thanks to God, the Father. This morning in our service we have the children of the Sanclean Orphanage to share a song with us. The Sanclean Orphanage is an orphanage that is supported by many of the orphanages here in Korea, by our military people. This particular orphanage is supported by the 1st of the 9th infantry, who are stationed here at Liberty Bell and at Camp Greaves, by the Joint Security Area Command to station across the street at Camp Kitty Hall, and by Bravo Company of the 2nd Engineers at Camp Edwards. This time the children will be back.


Goddess of time. Receive my light, Lysfunga. Let this power flow through you. And fight again alongside your past selves. I'm here again. Another me. I look good. I rewind. I begin again, but with another me to fight back. You're coming with me! You're not the only one who can be in multiple places at once. I will become Legion and crush these demons. I can feel that there are more.