If we see the other part of the US foreign policy, assassination, use of drones to quote unquote take out people, baseball cards, who are going to be taken out every Tuesday. This is a part of the US policy today. And they have also supported Israel and its assassinations in different parts of the West Asia. So they have never been particular about this issues as the claim for others. You know, Trump has also brought in other issues like political issues in terms of Middle Eastern politics.  Yes, of course. Now this is again a message to the Saudis that look, you know, Khashoggi is not the issue here. The issue is, you know, I have countered on you, again, first person singular, I have countered on you when I embarked on this path because you guys came and told me and put me onto this and I'm now in a project halfway through. Now you better stick to it and all the support that you promised, you better deliver. And then he mentions also in the statement Israel. What does Israel got to do with Khashoggi? Now he has said this because my son-in-law has up his sleeves a certain package for the Middle East for solving the Palestinian problem. And you told me that you will sell it by endorsing it in some way or the other when it at the eleventh hour to make it possible. Israel comes in two, three ways. Number one, this present arrangement in Saudi Arabia has worked brilliantly for Israelis because a subterranean relationship, subsoil relationship, this Saudi regime has had shown the courage, if you look at it from the Israeli-American point of view, courage to bring it to the surface and openly acknowledge it. It is now therefore got a wider acceptability in the Arab-Muslim world because when the Saudis say it, it's difficult to contradict it publicly. So the Saudi support is very important for Israel and that is important for the United States also. Secondly, the Saudis had promised that they will work with the Americans to impose, I'm using the word carefully, impose a solution on Palestinian issue. On this estimation, that this is the core issue in the Middle East, without this a kind of a quantum jump in terms of a new Middle East will not be possible. So Kushner has been working on this, Jared Kushner trumps son-in-law and Israelis are giving all the inputs into this. So Saudis must continue on this track, that is the second part of it. And the third one is a kind of a regional alliance where Israel will get strategic depth. This is the talk about the Arab-NATO plus Israel- Arab-NATO, yes. And Iran is a bogie. So the Iran bogie and any other aspect can also come into this. But essentially to ensure that Israel's regional isolation is mitigated and it gets embedded in an alliance system which cuts across religions, which cuts across the Arab world. And that is a permanent solution for a greater Israel. You know, naturally it will lead to greater Israel because after that the Israelis couldn't care less about these pockets inside the country Gaza and West Bank and all that. So in terms of the fulfillment of the Israeli agenda, Bolaan Heights are all as part of Israel. So you know, this is the scenario and then you see he has shown another big concession, Trump has shown another big concession by describing the MN situation as something which is unavoidable because of Iran. He says Iran must withdraw its presence and Iran doesn't have a presence to withdraw. So he is refused to criticize Saudi Arabians and all this threat of pressure on Saudi Arabia is lifted. He finds nothing wrong with what the Saudis have done there. So you know, this looks, Prabir, prima facie as something of a very generous attitude like a blank check for the Saudi Arabians. But the cutting edge is that this wish list is so very demanding that one can tell right at the beginning that the Saudis are not going to be able to carry this forward very long. So here's a question. This is a, as you said, a very honorous wish list. Saudis may not have the capacity to carry it. The second is why the Saudi establishment and the, shall we say, the Congress of Princes so should not instead jettison the Crown Prince. See I see that unlikely, now we are moving away from Trump to the alignments there. I see that unlikely because this Muslim Brotherhood factor is definitely at the root of the murder of Khashoggi. Trump also mentions it. Yes, he is also aligned to Muslim Brotherhood. Yes. Turkey, Erdogan is Muslim Brotherhood. Yes. Hamasar Muslim Brotherhood. Yes. So that correlation is there. You know the fact is it has got acceptability in the Saudi ruling circles that is in terms of the family, royal family. This interpretation of the Muslim Brotherhood as an existential threat to the regime. After all, Muslim Brotherhood seeks democratization because it is only through democratization that Muslim Brotherhood can make a headway and can capture power in these countries like it happened in Egypt. So these kings and all these have to go away, you know. So this is an existential thing for the ruling party. Then secondly what I notice is this that there is really no stomach for a removal of the regime or a change of regime. Resume change is a different connotation, changing the regime under pressure like this from the outside because this can have a domino effect in the region. Fragile internally as well. Yeah, regionally also. Because a number of these guys have their own problems.  So you see there is a democratic stir going on in Kuwait, which they are barely able to control. Earlier Bahrain. Big upheaval in Bahrain. You know all this shows that a change in Saudi Arabia can bring about pressures on the other regimes. So on this question of changing the setup in Saudi Arabia, I think there is no support in the region. So projecting this Khashoggi thing as an existential issue, squashing the domestic dissent there by, dissipating the domestic dissent there by. And then a third curious factor, which you know, we again paint the Saudi situation in black and white terms, but there are subtle shapes. Now you know, the point is, this young man, the crown prince, has a very strong constituency in the Saudi society supporting him, the youth. Because you know, day to day, until Khashoggi came, we were not noticing a number of moves he has made in terms of relaxing restrictions on the society. And the kind of modernization vision that he has projected is called the imagination of the youngsters, because this is what they would also want their country to be. You know, Arabs remember, they are very chatty on the internet.  It takes to the internet, you know, and they cleanly follow and make up for the deficiencies in their own media and all otherwise, and you know, they have very, very, very fairly good knowledge of where they want to be and what they are not and so on. So a strong measure of support from the Saudi society for him. And I think even the factions which are known to be outside the corridors of power today within the royal family, even they grudgingly admit that the crown prince is rather popular as a figure in the Saudi society. This really doesn't matter perhaps for an oligarchy, but it's a fact of life. So you see, all this factor also comes in favor of that and we really don't want to talk about it much because these days, we won't only to condemn them for the Kashukji murder, but ultimately the crown prince is also a politician and from a politician's point of view, the mass support is a factor.  He has controlled the entire police and military apparatus inside the inside South Arabia. Apart from that, the only other issue is it also seems to have strengthened Turkey, we should vis-à-vis the Saudis in the region and do you see that, that will continue. We also see that there is no reapprochement which appeared might happen between Saudis sort of also offering shall we say various monetary considerations to Turkey. All that see doesn't seem to have happened and the gun is still on a very shall we say strong note on bringing to book Khashoggi's murderer who he thinks the main culprit is the prince and he's made that pretty clear. So do you see Turkey emerging as a bigger player in this and not sort of towing either the American line and also being able to play an independent role as you talked about the Muslim brotherhood as the key figure of Muslim brotherhood today in the region? Undoubtedly so, you know the Turks are actually it's very ambitious country and they have sets their sights very high as a regional power and they are moving very systematically and it's an ideology based regime and the Saudi situation how it develops is going to affect their own forward march. So you see Turkey is playing for very high stakes. I think a number of people calculated that you know taken this old habit of the Saudis throwing money at any problem and solving the problem they would throw some green money at you know the Turks and the Turkish economy can afford to have money but Qatar is doing that for Turkey. So Erdogan is today liberated from financial worries. Turkey is the second largest military power in terms of forces, soldiers in the NATO. And you know the curious thing which has happened is that the Khashoggi affair has brought about a certain proximity between Turkey and the US intelligence which wasn't there before. This is very interesting because for the US intelligence also Muslim brotherhood has been a very key interlocutor for a long time. Strategic asset for a long time. Yes, yes. I've even got in my computer a photograph of a Muslim brotherhood delegation. Pension hour in 1956. No, in 2017. 2017. A Muslim brotherhood delegation coming out of the US Congress which went there for lobbying and you know how the American system works. Now this delegation has definitely had the support of the intelligence establishment and this lobbying among the US congressmen was in fact to prepare for transitions involving the Muslim brotherhood which are in the pipeline. So you can imagine that you see there has always been a constituency, I don't want to mention the names here of the CIA people but there are people, there is a strong constituency because a number of them are writers also today after leaving 30, 35 years in the CIA. You know who believe that American security interests demand the democratization of the Middle East. But democratization of the Middle East in a way that it brings to power forces which are going to have a congruence of interest with the United States and which will therefore work with the United States and that is the only enduring solution to the American predicament in the Middle East politics. You know that is an interesting point that you are making because this was the congruence why Muslim brotherhood was preferred over what would be called secular nationalist Arab figures like Nasir, like Assad and they were nationalist and were quite willing to have certain relations with the United States but the United States concretely chose these figures including in Iran because nationalism means also control over resources and therefore antithetical to USA. Correct.  You know Muslim brotherhood and Iran have a troubled relationship but of course for transformation of the region what Muslim brotherhood can bring about a transformation of the region, Iranians are not going to block it because Iran also wants you know a kind of a system towards an Islamic regime and also want the monarchies to go. Yes, monarchies to go. So you see but coming back to this point, the Turkish point therefore what I see in this period since October 2 is a proximity developing between the US intelligence, the CIA and Turkey because a number of these leaks have come and they are being picked up and you know they are being burnished and refloated from the United States in the American media so there is a collaborative project going on you know and Trump knows it, definitely Trump knows it and the way he despised the CIA director to go and look into the you know into the Turkish archives to see how much they know that was what was expected when the director came to Turkey for consultations was this that Trump knows that Turkey can spoil it. So what Trump has done is again that part we has not come out very openly here. Let us send a note to the Justice Department and the FBI that Erdogan's number one enemy, this Islamist preacher by name Fethullah Gulen who is sitting in Pennsylvania in a big ranch you know and enjoying the support and his green card was actually recommended by top CIA officials when he fled Turkey. Now Erdogan has got all the dopes on him, he is sitting there that he could be that Turkey's request for repatriation could be partly met by Americans kicking him out of America you know American soil from where so that you know it does not become an issue between Erdogan and Turkey. Erdogan in the United States. Trump's motivation here is very clear because Trump immediately came under attack from American press and American writers who have voiced opinions on behalf of the CIA. This is in fact to bring it out that the CIA is behind Gulen. This is in a way to blackmail and to complicate the CIA's spring with Erdogan. You know this is all very getting very murky now you know and Erdogan knows very well that this is what and then another place where he has done is that is I am going to get into a little detail because it's important here there's a bank by name Hulk Bank. Now that bank was used by Turkey to circumvent the American sanctions. Oh they run oil in fact we also routed our paper through the Hulk Bank. Now that bank's director or assistant director is sitting in person in America, American Scott hold of him and he is undergoing trial in a Manhattan federal court. Now the point is this man's testimony and others have shown that this was done on behalf of people who were either close associates of Erdogan or even family members and even a mention a person like his son-in-law who is now the finance minister. So this can lead to sanctions against Turkey and it can lead very damaging for Erdogan. So he is again a signal from there, a trumpet signal from there that he maybe we can do something about this. He also holds up cards. So you know it is clearly to show that if Erdogan cooperates Erdogan can benefit out of it. Just think hard. Thank you very much Ambassador Bhadrakumar for being with us giving us a detailed exposition of all the things at play because it is a complex chess mode which is unfolding in front of us. Thank you very much. This is all the time we have for NewsClick today. We will continue to discuss West Asia, Saudi Arabia, Turkey and other issues in the region with Ambassador Bhadrakumar and on other programs.


What is one verse that will stop a progressive Christian in their tracks? I'll go first, John 14-6, and Jesus said to them, I am the way, the truth and the life, no one comes to the Father except through me. You see, some people claim to be Christians and yet say that there are many paths to God. This isn't a biblical idea, plain and simple. We like the idea of everyone going to heaven, it makes us feel good. But if we exchange the truth for a lie simply because it makes us feel good, we're not truly loving those who desperately need to hear the name of Jesus. Follow for more Christ-centered content and help support my ministry on Patreon.


of cockroaches to this. So, you know, you have one single database and you simply keep adding nodes to it and you're expanding it, not just from a volume point of view from the size of the database itself, but from transactional volume as well. You can hit any one of these nodes and it's gonna act like a single logical database, right? Interesting enough, we can actually deploy these things in multiple different regions as well or across multiple different clusters, which is actually really cool. So what looks like one single logical database actually underneath the covers is implemented across multiple different regions so I can survive things and whatnot, right? So, number one, a couple of cool things about cockroaches. I'm gonna go five quick things and then Keith is gonna go and do operator and demo and stuff. Number one, this is standard SQL. We aren't requiring you to learn anything else. We are wire compatible with Postgres. So, if you know SQL, you can interact with cockroaches DB. Number two, you could ask any node in a cluster for data and it will find that data throughout the cluster. Every node is a single consistent gateway to the entirety of the database.  I could ask any node, I'm gonna find that data. Number three, in this first question, I was asking for this record and it was in region one, it's gotta go all the way over to Europe and back. That's not efficient. How do we geolocate data near users to reduce read write latencies and how can the database do that? Cockroach has a very unique capability called geo partitioning that allows us to actually do that. So, now when this user, Spencer Campbell, asks for his data, well, it's actually located in Europe. Say he's in Europe, right? And so we can actually geolocate data and geo partition data which is actually pretty unique and allows us to deal with these latency issues at global scale. Finally, I talked about scale, simply spin up a node, point it at the cluster and what happens is Cockroach will consume that new node and balance all the data throughout the cluster so that we can balance for volume of transactions or volume of data, whatever it is. There is no manual sharding involved. And then finally, when a node fails or even a whole region, what we've done is we've actually created replicas of data so that the data still existed, you still have access to this. The cluster itself would actually remedy this situation, actually deal with these sort of things in terms of create a third copy of that data somewhere else but we can actually, you know, survive failure of a node or complete region, right? So that's the high level overview of Cockroach DB and just a couple slides and oh gosh, I did it. Man, we're 10 minutes in Keith. I did it in about eight or nine minutes. So, but I wanted to get into a demo of Cockroach DB and getting started. So Keith, do you want to take over here? Yeah, absolutely. So we're going to demo it. Can you- Hey Keith, really quickly, just let me remind everybody please do ask questions in the QA. I will be monitoring the QA for questions along the way and dump those into Keith. I just wanted to remind you, sorry, Keith, go on. No problem. So I'm going to demonstrate two things today. I'm going to demonstrate using our operator to set up a Cockroach DB cluster in a single region. In this case, it's going to be an open shift environment that's running on my laptop. And then later on, we're going to be working on a distributed environment that I set up previously that's across three regions in Google Cloud. So, and I think I'm running that on GKE. So I'm going to go ahead and kind of share the first bit. So hopefully you can see my screen, Jim. So what we have here is open shift. You're not familiar with open shift. It's Red Hats Kubernetes distribution, right? We have published the Cockroach DB operator in their operator hub, which makes it super easy to get started with Cockroach DB. So all I need to do is search for the operator. We got the Cockroach operator right here. I'm going to click on the install button. I'm going to install it into my Cockroach DB namespace that I created a couple of minutes ago. And that's going to go ahead and actually install the operator on the cluster. Now, while I'm waiting for this to install, I'm going to talk a little bit about what an operator is. So an operator is a manager for a custom resource in Kubernetes. So we define a custom resource called a CRDB cluster. And then the operator is a pod actually that we assign state to. We publish custom resources to and it configures and maintains the database for us. So it does things like easy rolling upgrades. It's going to make it easier in the future to set up backups and restores and do auto scaling and all that kind of stuff. Right now it's doing a full install and upgrades for us, which is not super hard in Kubernetes. We got away with not having an operator for a long time. But what it's really designed to do is make some of those kind of day two operations, like post install operations, easy to manage in production. So we have this operator. It provides a Cockroach DB cluster API. I can click on the link to create a cluster. And the backend, it's creating a CR. We're going to name the CR, CRDB TLS example. It's going to have TLS enabled. So it's going to be an encrypted, it's going to be set up with encryption. It's going to spin up three nodes in this OpenShift environment and each of them are going to have 10 gigs of storage. So we're going to go ahead and create this real quick. And over the next 90 seconds or still, it's going to install the database for us. So that's it. That's all you need to do to get Cockroach DB up and running. If you're running not in OpenShift, we have published instructions on our website on how to use the operator. We also have a published thumb chart that you can use for, you know, that's more for test and dev type environments. Also super easy. We also for custom deployments, which is something we're going to talk about a little bit later. We do also publish stateful set configurations for publishing, for installing Cockroach DB manually against Kubernetes right now because the operator is currently single region, is a single region operator. You would still use the stateful sets for deploying across multiple data centers, which I've done here. For the later demo. Let's see if it's created my resources yet. It has. So I have, it's starting to create my database pods. So we'll go ahead and let it finish starting up. We've got to, we have three more that are going to need to start. You can see in the logs that it's already kind of coming up and going. Let's go ahead and see if we have, we're almost the database is almost live and healthy. We got just one more pod that needs to come up. Hey Keith really quickly why we're waiting for that to come up. You know, we're showing the operator via, you know, open shift in the marketplace. It's also available just raw in our Git repo as well, right? Yes, absolutely. So we have a, this is open source. So this is published. Hold on a second. I'm going to log into the database and create a quick user. And then we're going to log into the admin giveaway to prove I didn't just like kind of fake it. So. Okay. Love watching you tied buddy. This is the only part I couldn't script. I know. Here we go. SQL shell. All right. So. Standard SQL. It's pretty super standard SQL. So let me go ahead and do local host. Cause I am, I did a quick port forward. It logs me in. I have three nodes that are running. You can see that all of these are running kind of locally on my laptop right now. That's right. And Keith, you did local host into one of the pods, right? One of the instances of cockroach, right? It could have been any one of those instances, correct? And then you would get the DB console. That, that is absolutely correct. Yeah. We don't implement like a separate node to do the console and then database. It's everything is like a distributed system saying single binary, every single node implements the same binary, right? So. Right. Everything is a single binary, which makes it really easy to kind of work with this stuff, which is awesome. Yeah. And easy to scale and aligned with the core principles of kind of distributed systems and how these things work, right? So. Real quickly, there was a question about rancher as well. You know, could we use this with rancher? I don't think we're in the rancher marketplace yet, right Keith? But I mean, the operator would work with the instance, I mean. Yeah. So we do work, we work with any Kubernetes distribution. You know, we're not necessarily listed in every single marketplace, but our generic Kubernetes instructions, I have yet to find a Kubernetes distribution that didn't work. So really it's a matter of kind of just following the instructions in our documentation. Right. Yeah, exactly. So that is another question too. We, you know, I think we're in this install, we're definitely using stateful sets. Are we, I mean, is there an option to do this a different way, Keith? Or is that just kind of like the standard way of doing things? So stateful sets are the standard way of doing things. We could theoretically use something like demon sets and there's certain use cases for demon sets. But generally speaking, demon sets are more appropriate for things like log stash agent or whatnot, where you want it to run in every single node. Whereas for us, we would have to be used taints in the background to make sure that the database only landed on specific nodes. That's right. Yeah.  I mean, there is a fair amount that actually goes into what we're using stateful sets for, right?  Absolutely. Yeah. And then, oh, there was also a question about open ID and do we support open ID connect protocol? So, so open ID is, would maybe be appropriate for the admin UI.  Right now, our authorization mechanisms are password, user and password, TLS certificate authentication and then GSS API, which would be backed up by like, like a Kerberos-based infrastructure like Active Directory. We have discussed and we've done this for Cockroach Cloud, which is our kind of managed service and for databases of service where you do have single sign-on. So theoretically, we could make that available and self-hosted as well. I don't think we currently publish the tooling that would be required to do that, but it would be feasible. I hope that answers the question. Yeah, I think so, Keith. And then one more, is this the preferred method of installing and running Cockroach using the operator? I mean, I know we've had a Helm chart as well. Like, and so I think I see you just using the operator now over Helm, like what is your preferred approach? Because we use either, right? Yeah, we can use either. So for production deployments, I still recommend the static configs. So largely because there's always something custom that you need to do and the operator's pretty new. I mean, I think you're aware, we announced it in the fall, right? So it's, we're still, you know, we're still kind of working to make sure that it has full future coverage that we need there. The Helm chart is great for like super simple test and dev environments. You certainly could use that in production, but certain administrative tasks are a little bit more complicated using Helm. I don't think there's a wrong, I don't think there's a bad way to install Cockroach DB on Kubernetes. I think that generally speaking, it's gonna be really hard to really mess things up for yourself. The Helm chart is very flexible for basic install. And then the stateful sets are super dynamic for when you have custom networking and all the kinds of things that go into that.  You know, is it just PV and what are you doing? And I think that's all kind of covered. I think you kind of spoke to that Keith, but stateful sets is really that key thing so that when things do fail, the persistent storage and remounting that to whatever pod that is, it's just a key piece of the overall equation. It's part of what, you know, because we can actually survive loss of a piece of data within the database, we can lose a pod pretty easily and survive that pretty well. You're gonna show that in the next demo, right? Yeah, in the distributed demo across multiple data centers, I'm gonna show that. So it's a little easier here because of the GUI to show off some of the stuff that we're actually doing. So we're mounting secrets as a volume and we're also mounting a persistent volume claim, a PV into the cluster. Right. And each node gets its own volume, right? So it's, and that way if we lose a node or we lose a pod, we can recover from that very easily. And so one last thing before we move on, Keith, and I just wanted to comment, I'm trying to hit the questions live, y'all. Like there's a lot of questions here, which is really fantastic. So forgive me if I'm not repeating the question, I am paraphrasing and kind of lobby them into Keith here. I just wanted to talk to a couple of things. Our operator is somebody who's asking if it's open source or not. Our operator is definitely open source. The Git repo is out there. I'll get it out to everybody as Keith is doing this. I'll go look it up and get the link to that. It is written in Go, which is kind of a unique tune. I mean, well, I mean, unique to us actually. Our entire database is written in Go. So it's pretty well aligned kind of with kind of how these things come together. So, dude, there are a lot of really, really deep questions here, Keith, I'm gonna do the second half of the presentation, just to talk about how we scale and how we survive things.  I'm gonna go back into the screen sharing here, y'all. Okay, let me see where's this guy. Okay. Keith, can you see the share? Yes. Okay, great, awesome. So we showed you how to kind of deal with installation and the operator and whatnot. You know, underneath the covers, what cockroach implements and what we use and we rely on pretty heavily is a distributed consensus protocol called RAFT. Now, if you're not familiar with RAFT, go check it out. I mean, if you're interested in distributed systems, RAFT and PAXOS, really interesting, cool stuff. And we use RAFT to a major extent. I think I heard, and it's not easy to actually get done and do you well within a distributed system. I think I heard Ben Darnell, who's one of our founders, is probably one of the best software engineers I've ever met in my life, say, hey, I could have probably coded RAFT in a couple of days when I was in college, but to do it for a distributed like production grade database, it's taken years to get this right because we're dealing with some really interesting challenges when it comes to a database. And when you start dealing with RAFT and distributed consensus at major scale across different parts of the planet, there's lots of different things that go into that. And there's been a lot of really interesting software engineering from the Cockroach Labs engineering team to actually fix some really interesting things that we found in RAFT that we actually contribute to upstream at CD. And there was a question here about split brain and some of these things actually we've architected out some of those really, really difficult problems to deal with around atomic replication and whatnot. And so there's lots of stuff on our blog. I'm not gonna get too deep into the particulars of what we've done here, but the same kind of core concepts that are driving Kubernetes and RAFT and at CD are the same concepts that are here in Cockroach. And we share a lot of that same lineage that we actually contribute upstream to these things. So I know there was a question about split brain. Man, that's a really, really deep question. There's definitely a great blog post about how we've actually dealt with that in Cockroach. I think, you know, there's been some recent issues about split brain and distributed consensus in this and a whole nother world. But we use RAFT, there's a RAFT group in Cockroach. A RAFT group basically is, you know, because of data and a leaseholder or RAFT leader where basically most transactions will concern, will commit. When we actually place data within a cluster, somebody was actually asking this in the chat, you know, how do you distribute data? I have four nodes and I actually wanna take a table and distribute replicas of the ranges within this table. Ultimately underneath the covers in Cockroach, every table is broken down into 256 megabit chunks of data. And so what that allows us to do is move data around and create these replica sets. And so you can imagine this table, which has dog names here.  You can think of these just shards, but we automate all of that chart. I'm gonna show you that, right? And so, but when we write data to a cluster, we can optimize this four different failure domains or basically for latency. But we can actually survive lots of different things. When we write the first range, we write three nodes, we write the second range, the right third range. And what we're doing is we're distributing data evenly across these various different nodes. We can also do things. We use heuristics in the database itself so that when load is heavy on a particular range, we can actually segment that range out to its own node or its own pod, if you will, so that it can actually, you know, deal with that transactional volume over that is, right? So another way in which we can actually deal with the placement of data is to optimize the overall performance of the cluster. Now we can also do something really cool. And if you have a deeper layer, there is, you know, the architectural deep dive of Cockroach, if you're really interested in how this stuff works, we go into a great explanation of how this works. It's in our YouTube channel, if you really want to after it. But we can actually overload the primary key for each of the tables and actually integrate in, say, a location so that we can actually control where data is going to be placed in a cluster as well. And so there's lots of different things we can do here. This is a unique capability to Cockroach. It's called geo-partitioning. I believe, Keith, you are going to show a little bit of geo-partitioning in the demo, right? Yeah, we're going to use geo-partitioning across three data centers in the US as a part of the demo. And so, you know, ultimately at Cockroach, look at, there are two primitives of which we've defined for and which we designed and implemented for. Number one is consistency of data. So, you know, we've implemented a database that is true system of records, so serializable isolation. So, data is guaranteed correct in our database. This isn't eventually consistent. What you read is what you're going to get, right? And that's, and we've optimized for that. And there's a lot of things we had to do in distributed systems that actually deal with that, right? So, there's these challenges to the cap theorem. I think there have been a couple of questions about them. We could talk about that in a little bit. But we've also optimized for the speed of light. That's our biggest competitor. How do we actually guarantee a transaction and then give low latency access to data no matter where people are on the planet? Which is also really, really difficult to do for it. And so, we've done a lot of those things. When we add replicas or we add a node to a cluster, what it's doing is just simply moving replicas around and rebalancing the cluster. We can actually survive failure. Say node three goes down. Those two replicas are gone. The database is smart enough to heal that. It's going to create, you know, the other replicas that's always going to be available. So, real quick kind of overview. I just wanted to give a little breather so Keith can go into the second half of the demo. Keith, that's all you have to say. So, can you see my screen now, Jim? Yes, I can, Keith. By the way, y'all, I'm trying to answer questions in the background as much as I can. Keep them coming. We'll get all of them afterwards if we don't get to everything. But I'll try to allow things into Keith along the way as well. So, thank you very much for all the questions. So, this is a cluster that I set up earlier today. It's nine cockroach DB nodes plus an additional worker node in each region, which you're not going to see in here because I didn't have them join the database cluster.  So, we're generating a load in each of these regions. The app that we're running is a simulated ride sharing app that we call Mover. A lot of our tutorials on the website use this app. So, this is just a scripted version of a tutorial, the geo partition replica's tutorial on our website if you wanted to go through and do this yourself. So, right now we're running, performance isn't great. It's running like 500 milliseconds per query. I haven't done anything to the database to make it fast. We're running about 650 transactions per second across the nine nodes.  So, I just killed one of the nodes in the US East region. So, I think we'll be able to see it here in a second or two. We have a suspect node. So, US East 1C just went down. I'm going to show that how the database, we're going to have a bit of a performance blip, of course, but then the remaining nodes are going to take over those transactions as they go forward. There was a question about cap theorem, right? So, you can't guarantee consistency, guarantee availability and be partition tolerant all at the same time. And that's still mathematically true. What we do is, because we distribute and use the data and use consensus, we can design the database to survive certain failure scenarios. So, in this case, the database, I just demonstrated surviving a node failure. I could have taken out an entire region as well and the other two remaining regions where it would be able to continue to process data for the database. If we're to lose two of the three regions though, and I lost a quorum for my ranges, then there would be data unavailability. So, it's not like we completely disproved cap theorem. Instead, we're working around those limitations to try to make the database be able to survive the types of failures we need to be able to survive.  It's going to take a little bit of time. Once it does, you'll see that this under-replicated ranges count that you're seeing on my screen right now, we'll go back to zero. So, the node has restarted and now we have caught the under-replicated ranges up. And so, the database is fully healthy. What's great about all of this is with the exception of that dip where we were re-electing the leaders for certain sections of the data, which meant that we were holding some queries, the database was completely self-healing. And it actually self-healed to the original performance metrics before I even restarted the new node, okay? So, but we haven't done any performance optimization and quite frankly, a P99 latency of, in the half a second range is not great for most user-facing apps. Can I just, before you get into the performance thing, can I just ask, there was actually one question that was kind of interesting, this whole thing. And it's applicable to where you're at right now. And so, look at, we just so showed survival, one node went down, there were still two nodes. There was no real impact to the application. I mean, there was a little bit of a dip, but queries were still serviced, right? What happens if two of three nodes go down, however? So, then we would, two of three nodes So, because it's a nine node cluster, remember, I would have to have lost, I could have lost all of my nodes in one region and the database would have continued to operate. If I lost, because I'm only doing a replication factor three here, if I were to start losing nodes in across multiple regions, there's the chance that some sections of the data would not be available. I could manage for that by increasing my replication factor. So, if I were to increase my replication factor, in this case to five, I could survive either a full data center loss or any two arbitrary nodes in the cluster, right? Right now, I can lose, I can only lose a node or a fault domain, in this case, a data center. In the scenario you're describing, if I like up my replication factor to five, then I could lose two arbitrary nodes or an entire fault domain, right? Or a fault domain plus an additional node. Yeah, I mean, long story short, Keith, it's basically like, well, what do you wanna survive and how do you architect a database to survive that? We're gonna give you a couple different knobs and dials to turn, to optimize for what you want to do, but I think you have to think about that when you're architecting the deployment, the topology of this thing, right? Yes, so we have a great tool that's linked from our website about kinda what your minimum topology needs to look like and your minimum replication factor needs to look like to design your database to survive certain failure scenarios. There's no magic here. I mean, it feels magical because distributed SQL is hard, but the reality is that we're using the same fundamental underpinnings that HCD is using to survive the loss of a master in Kubernetes. And that's the reason why we can do this and we can run in Kubernetes and have a pod be maybe get restarted on out from under us and still have the database operate the way we expect. So what I'm gonna do in the background now is I'm gonna start optimizing the environment for being geo-replicated across three sites. So the first thing I'm gonna do is I'm gonna partition my tables and indexes. So right now we're using just kind of the default which is okay, right? But as you said earlier, a customer interaction really needs to be 100 milliseconds or less, which mean the database probably needs to be three to five times faster than that at worst case to have consistent kind of real-time performance or seemingly real-time performance for a user-facing application which is largely what we're focused on. So what I'm doing here is I'm altering my tables to make some partitioning decisions basically to have the leaseholder, which is the RAF leader. So technically the RAF leader manages right consensus. The leaseholder is the replica, the leading replica that's able to respond to reads without doing a quorum check, okay? So we're configuring the database on the backend right now, making some changes to the tables to optimize the placement of those things. So we're running this ride-sharing app in three cities, New York, Chicago and Los Angeles. And so I'm setting up primary rules for each of those cities to have their primary replicas live in the data center that's closest to those cities. And so what you're gonna see is that our query per second count is gonna go up because the database is becoming more efficient and our P99 latency is going to start creeping down here over the next minute or two. And the net effect of that is in Mover, I'm gonna go ahead and I'll actually show you what we've done here. So I'm gonna go ahead and kind of click in to one of these tables. It's gonna take a second to refresh on a sec. I am having some internet connectivity problems. Yes you are. So I apologize for that. So I had a couple of internet connectivity problems there. Let me go ahead and get this going. Here we go. You see we have the DDL for this table now has a bunch of partitions in it and we assigned those partitions to different regions, okay? And what that allows us to do is basically this is the DBA setting default rules for how the database should act in any kind of given situation. So what we see now is our P99 latency is much better, right? 65 milliseconds as opposed to almost 600 milliseconds. Our transactions per second went up from roughly 650 transactions per second across this cluster to almost 1,100. My query latency is gonna continue to improve here over the next, I don't know, couple of minutes. But 35 milliseconds is great, but really I wanna be sub 10 milliseconds because I wanna make sure I have tons of headroom. So now I'm gonna do a further enhancement. We have a table in here called promo codes, which is really a global table, right? We don't have New York only promo codes, right? So what we're gonna do is we're gonna create some a global index, which is going to allow us to do fast reads from all of the regions against that table at the cost of a write performance hit. So if I were to add a record to this table, it's we're gonna be writing to some additional indexes to make sure that we do fast reads. So our write performance will suffer or read performance will get dramatically better. So I'm gonna go ahead and build those indexes. You can see they're already kind of starting to take effect. And the net effect of this is we're gonna have consistent performance in the database of sub 10 milliseconds for 99 out of 100 of our queries. That means that we could theoretically do 10 database transactions. Within a kind of a real-time app like user interaction, if we absolutely had to, that would be a little unusual, right? Usually it's one transaction or maybe two or three. This is going to allow us to potentially have 10 or more if we really needed to. Now, what you're also gonna notice our queries per second isn't gonna change dramatically with this change because this is only impacting like 2% of the queries in this application. But our P99 latency is going to continue to get better until it lands at like, I think it lands somewhere between four and five milliseconds, if you let it. Once the database itself continues, because the database, as you mentioned earlier, self-optimizes under the covers as well. So once that optimization is done, then you'll be, we're gonna be kind of stick pretty solidly in that three to four millisecond range. You see we're already kind of getting there right now. So that was what I had to show today, Jim. Yeah, and so Keith, basically you could then alter the partition as well. And the database is gonna start moving data around, correct? Like, I mean, this was all done in production, correct? Yeah, so there are times when we move data, there are more frequently, what we're actually doing is moving the authority to act on that data, okay? So the leaseholder and the RAF leader, those are the, that's the authority to read and write that range respectively. So what, how the Waycock RHDB works is that every node is responsible for some portion of the data in the database, right? So, and in a normally configured environment, you could theoretically break this if you wanted to, but I don't know why you would. Every node is going to be the leader for some portion of the data, follower, a follower for other portions of the data, and completely uninvolved in certain sections of the data, right? So most of what I did here was actually moving the authority to act, right? If we set a rule where the authority to act, so with those partition schemas, let's say I had four data centers here and I decided for any particular partition, I wanted to move the authority to act to a location that we didn't have a replica, then the database is going to move the data for you. So you don't have to manually load the data in the background to do all this kind of stuff. We will handle that for you, but it's much more likely that we're going to move the authority to act on the data than it is that we're gonna move the data. The exceptions to be that would be like hot ranges, if we take, let's say we're having a lot of transactions across a really small number of ranges, then we might have some things that we would do there. Hey, dude, we only have four minutes and then we gotta cut this thing off, so I just wanna make sure I get to like, there were like two other questions and I'm just gonna share my screen to have that wrap up slide so while we're taking QA, people have that, if you can just turn it off screen, sure, that's great. So one of the questions, and it came in a couple different ways, how about backup restore? And how does that work in CockroachDB? Because it's a unique problem, right? Because we're guaranteeing data lives in locations, right? And so how does that work in Cockroach? Yeah, so the core database, that's the free to use open source database, includes backup and restore to a single location. So, let's say you add an S3 bucket in ABUS or whatnot, you could do backup to S3 and all of the nodes in your database would just need to be able to write to that S3 bucket. The enterprise, so we're kind of, the entire database is source available, certain features are licensed as enterprise features that you have to pay Cockroach Labs for. If you have an enterprise license, we also support distributed backup that allows you to have an arbitrary number of nodes back up to an arbitrary number of locations. So let's say for my simulated use case here where I'm in US East, US Central and US West, I could theoretically have the nodes in each of those locations back up to a local object store. And then I could move those replicas around in the background. That's gonna be faster, of course, in a distributed scenario where I'm backing up to something that's closer. But all of our backups are distributed. It's just a question of whether or not there, it's a many to one distribution or a many to many distribution. And ladder one is what we charge customers.  And, you know, like where the backup itself needs to be controlled from jurisdictional issues, right? And I think it's, you know, it's one of those more advanced features. So another question, Keith, was, oh gosh, oh, there was a, there was, guys, there were a lot of really great questions. I think one that's kind of easy to pick off and to go through.  You know, because we don't want to range scan the entire database, right? We're all over the place. Like how does cockroach deal with those sort of things, Keith? Yeah, so there are a couple of different strategies for management. Remember, we only have about one minute. So just so you know. Yeah, so that would be a sub optimal query pattern for cockroach DB. The easiest thing to do would be to run what we call an as of system time or a time travel query. That way that that long running kind of aggregate query isn't blocking other transactions. All right. We're serializably isolated. So if you weren't to do that, then you potentially have some performance issues. There's some other mechanisms you can use with CTEs and kind of pre-calculated aggregates. Like we could theoretically create an index that included some of those pre-calculated index. But we also, I mean, we also implement vectorized queries. So we can actually do some of columns pretty easily as well, right? Yeah, so vectorized, you know, the vectorized execution engine would help the performance there, but we're still gonna have to hit all of the. Leaders for all of the ranges that host that data. That'll just eliminate some of the like overhead of the transactional engine there. That's right. That's right. I mean, we've optimized a lot of things. There's also a cost based optimizer in cockroach DB that deals with like the distributed nature of the data. There's lots of things. I mean, you could actually go in and spec queries and see what's holding things up. We have just barely scratched the surface in this webinar today.  I mean, the core version, the free downloadable version is available off our site. Just get, get, get Catroach DB. We have a world of resources around Kubernetes in terms of, you know, how well we work with this. We do feel that we are probably the best database that is really designed to run on Kubernetes. In fact, Cockroach Cloud, which is our managed service of Cockroach DB runs on Kubernetes. We have deployed thousands of clusters on Cockroach on Kubernetes in Cockroach Cloud. A lot of what we package into the operator is that knowledge that we've actually captured. But that is really the easiest way to get up and running and try this today. We actually give away free clusters for about 30 days.  And so there's some really cool stuff coming out of us. So Keith, thank you for that. I want to be respectful of, you know, the Linux foundation and our time requirements. You and I can sit here and talk about this stuff for days. Like I said, I think we just, fairly just scratched the surface today. And also there were a lot of questions that came into the QA. I will get these from the LF and get answers out to everybody as much as we can. So Keith, thank you. Thank you. Appreciate it. Yes, thank you both so much. Thanks, Jim. Thanks, Keith. And as we mentioned earlier, this recording will be available up on the YouTube later today. So thank you all for participating and we hope you have a great day. Thanks everybody.


Welcome to The Endless Knot. People often confuse etymologists and entomologists, but today I'm going to be a bit of both as I try to pin down the word bug. For such a simple-seeming word, bug has a remarkably complicated origin story, coming at seams from at least two sources, the first being British folklore. In Middle English, the word bug referred to a terrifying creature out of folklore, like a hobgoblin, and this sense is still preserved in the related terms bugbear, bugaboo, bogey, and bogeyman, as well as a number of other similarly named creatures. All of these similar words refer to mischievous folkloric beings or spirits or ghosts, particularly in Britain or other northern European areas, and may stem from a similar folk belief in the Middle Ages. The earliest attestation of the word in Middle English actually refers to a scarecrow. As to where this Middle English bug comes from, one possibility is that the supernatural creature was once some kind of goat-like being, not uncommon in many folklorists, and thus the word comes from the same Indo-European root that gives us the word buck. Alternatively, bug may come from an Indo-European root that means to boil, swell, or puff up, which lies behind many other English words, not only boil and puff, but also big, pock, and bogey, or bogey if you're British. This swelling sense seems to lie behind the expression bug-eyed, though the usage isn't attested in writing until the 19th century. In any case, the sense of a frightening creature has evidently been watered down to mean something simply annoying, something that bugs you, just like bugbear, which now simply means an annoyance. And this less frightening sense may have something to do with another similar-sounding word that seems to have merged with bug. Old English butta, meaning beetle, which is only attested in compound words such as sharn butta, meaning dung beetle, sounds enough like bug that the two may have fallen together. And by the 17th century, the word bug starts to be used to refer to insects, initially bedbugs, and eventually any insect. One imagines that the fact that insects such as bedbugs are potentially frightening, or at least annoying, help these words merge as well. It's also uncertain where Old English butta comes from, but it might be connected with our modern English word bud, as in a chute or seed pod, and might ultimately come from that same proto-Indo-European root that means to swell. In a formal scientific sense, the word bug now ought to refer only to the order of insects hemiptera, which includes bedbugs, but colloquially, bug is used to refer to any insect, and sometimes even to other non-insects such as spiders, as well as the sense pathogen or germ, which develops in the early 20th century from this insect sense. In fact, there have been quite a few slang senses of the word bug over the years, and perhaps the most common now is referring to a computer bug, a flaw or malfunction in a computer's software. The story behind this sense that's often told is that shortly after World War II, when celebrated computer scientist Grace Hopper, who is particularly known for inventing the first computer language compiler, and for her role in the development of the COBOL programming language, was working on the Harvard Mark II computer in the US Navy Research Lab, she coined the term bug, when it was found that there was a moth caught in the relay causing the machine to malfunction. However, the logbook entry for this event, which even preserves the moth taped to the page, makes it clear that the term was already in common use, and the scientists were simply joking that this was the first actual case of a bug being found. This sense of bug had actually been around in engineering circles for over 50 years. It can in fact be traced back at least as far as the 1870s, when inventor Thomas Edison used the word in his notebooks to refer to problems in the telegraph equipment he was working on. The telegraph was a system of sending a coded electrical signal, usually Morse code along a wire, the first electric communication system. Morse code was named after artist Samuel Morse, who turned inventor and helped develop the single line telegraph, the first really commercially viable system. Out of grief, after news of his wife's illness reached him too late to return home while he was out of town. Edison, who began his career as a telegraph operator, soon began to work on improving the equipment and applying for various patents for his work. Whether Edison coined the term bug himself or whether it was already common in the telegraphy world is uncertain. And whether this new sense really grew out of the notion of an insect in the machine or some sort of mischievous spirit in the machine, think bugbear, or simply a worrying or annoying problem is also unclear. What is clear is that this sense of the word made its public debut in an 1889 article in the Palma Gazette on Edison's work on the phonograph, his first really major invention. Mr. Edison, I was informed, had been up the two previous nights discovering a bug in his phonograph, an expression for solving a difficulty and implying that some imaginary insect had secreted itself inside and is causing all the trouble. Edison is of course known for the many patents he held, 1093 in the United States, many of which were for work actually done by employees working in his famous Menlo Park research lab and for some high profile patent disputes with other inventors. But a word can't be patented. And this new sense of the word that Edison pioneered spread quickly. Speaking of the phonograph, Edison invented this first really viable sound recording technology in 1877. It recorded sound by etching small bumps in a groove on a cylinder that corresponded to sound vibrations. Some time later, German born inventor Emil Berliner, who emigrated to the United States to avoid the Franco Prussian War, further developed sound recording technology with his gramophone, which used the record disk more familiar today. Berliner's gramophone records took a while to overtake Edison's early start, but eventually won this early format war, giving us the ubiquitous record albums of the 20th century. And speaking of Edison and Berliner and patent disputes, both men simultaneously invented the carbon microphone, the first design that was effective enough for use in telephone communication. It involves two plates of metal separated by granules of carbon. Sound vibrations against one of the plates causes a modulation of the electrical current passing through the setup, which can then be transmitted along a wire. After years of legal wrangling, Edison won the patent. So I guess the Edison versus Berliner scorecard is even. But the funny thing is, neither of them was the real first inventor of the carbon microphone, which was first developed by English scientist David Edward Hughes. And what's more, he seems to have been the first to coin the term microphone, at least in its electronic sense. But unlike Edison and Berliner, Hughes chose not to patent his work, wanting it to be freely available for the good of scientific progress, a notion similar to what we would now call open source or public domain. Of course, the idea of patents is to allow inventors exclusive ability to profit from their inventions for a limited time, with the trade off that the technical specs will eventually be made public. The overall purpose is to foster innovation and development. Modern patent law, as we know it, has its origin in the 15th century. But there may be a forerunner in ancient Greece. The ancient Greek colony, Ciberus, located in what is now Italy, was so financially successful that the citizens became known for their feasting and hedonism. So much so, that even today the word Ciberidic means devoted to opulent luxury. Perhaps not surprising then, that cooks in Ciberus were apparently granted exclusive rights to any culinary recipe they invented for a period of one year, at least according to the Greek writer Athenias. Even if this report isn't true, that the idea of intellectual property could even be conceived of in the ancient world is an interesting milestone. The first patent in the modern sense was granted in another city in Italy that became extremely wealthy and known for its opulence in the Renaissance, Florence. In 1421, the Florentine architect, Filippo Brunelleschi, who was best known for developing linear perspective and thus transforming Renaissance art, was granted a three year monopoly for a barge with hoisting gear for transporting marble. By 1450, the practice had become systematized in Venice, another economic powerhouse Italian city, with 10 year patents and afterward gradually spread throughout Europe. Etymologically, the term patent comes from the medieval term letters patent or literary patentes in Latin, which means open letters. Letters patent basically grant some special right or privilege. And the word patent was used in English in this broader sense from the 14th century, and from the 16th century onward in the more restricted sense that we use now. The Latin verb pateo means to be open. So there is a certain irony that now the term patent stands in opposition to the idea of open source, as in the case of Edison, Berliner and Hughes. Getting back to the microphone then, its initial purpose was telephone communication. The microphone was originally termed a transmitter. Well known is the story of Elisha Gray and Alexander Graham Bell simultaneously inventing the idea of the telephone and Bell beating Gray to the patent office by mere hours to be henceforth recognized as the official inventor of the telephone. But Bell and Gray had only crude versions of microphones, and it wasn't until the carbon microphone of Edison or Berliner or Hughes, if you will, that the telephone became a viable technology. The microphone went on to be used for things such as amplification of sound and more sophisticated sound recording. And most important to this story, the covert listening device commonly known as a bug, a slang term first used in the 1940s. So after inventors and engineers like Edison, Bell and Morse worked the bugs out of the telecommunication technology, the spies put them back in. But where does this slang use come from? Oddly enough, it may have transferred over from the burglar alarm, which was also referred to as a bug in 1920s criminal underworld lingo. A house was said to be bugged if it was equipped with the burglar alarm. This might be because it was something annoying or to be worried about, or it might simply be a shortening of the word burglar itself, which is unrelated. But another possibility takes us back to the mythological bugaboo. Back in the 18th and early 19th century, bugaboo became a slang term for a creditor coming to collect money or a sheriff's officer, according to a glossary of slang compiled at the time. And in 1828, the word made its mainstream literary debut in a novel by pot boiler writer Edward Bulwer-Lytton, he of it was a dark and stormy night fame. So from bugaboo for actual police officer, to bug for the automated police officer, the burglar alarm. The invention of the burglar alarm is also connected to this story. Of course, guard animals have been used for centuries, and some had tinkered with mechanical noise makers to signal forced entry. But it was in 1853 that Augustus Pope, a church pastor turned inventor, hit upon the idea of adapting telegraph technology to make an electric burglar alarm, which was often referred to as a burglar alarm telegraph. Pope developed his system using components from the Boston shop of Charles Williams Jr., the premier telegraph equipment manufacturer. Williams supplied components to many of the inventors at the time, including Edison, and Bell conducted his work on the telephone in the upper floor of Williams shop with the assistance of Thomas Watson, he of come here Watson I need you fame, who was also one of Williams employees. Unfortunately, due to declining health, Pope was unable to continue to develop his system and sold the patent to one Edwin Holmes, sometimes mistakenly credited as its inventor, who up to that point was a sewing store owner known for making hoop skirts. Holmes took the idea from Boston to more crime wary New York and made a big success of it, and having met Bell through his contact with Williams equipment shop, Holmes hit upon the idea of using existing telegraph and telephone lines to connect burglar alarms to a central monitoring station. But getting back to the computer bug, though Grace Hopper didn't coin the term bug or the notion of debugging, the word debugging was also already in use in engineering circles, she is definitely associated with the debugging of computer bugs and her importance to the history of computer programming can't be overstated. There's a fairly direct line from Edison and Bell and the telegraph and telephone through Hopper and the earliest computers to the internet of today, and the great advances in both software and hardware that have come both through patents and through their opposite, open source computing. In fact there's a saying in open source software development, which often relies on volunteers to check over code, that given enough eyeballs, all bugs are shallow. But of course there are always people more interested in making money for themselves than in contributing to innovation, like the people called patent trolls who are known for buying up patents and trying to make money off them by suing companies for supposed infringement without any intention of actually using or developing the technology themselves. And so the internet is haunted by a new type of monster, maybe just as scary as the bugbearers we started with. Thanks for watching! If you've enjoyed these etymological explorations and cultural connections, please subscribe to this channel to help me make more videos. You can also sign up for email notifications of new videos in the description below. Leave a comment or question or tweet at alliterative. You can also read more of my thoughts on my blog at alliterative.net


So when you think of firsts, there are a number that spring to mind immediately. First man on the moon, Neil Armstrong. First person to climb Everest, Sir Edmund Hillary. Although we'll never really know if Mallory and Irvin made it to the top before him. First person to run 100 miles on Zwift. First person to run a marathon in under two hours, Elliot Kipchoge. And the first person to run a mile in under four minutes, Sir Roger Bannister. And that happened right here on this very track. We are at the Ifleet Road track in Oxford. And we are going to run a Roger Bannister mile. So we're just going to do a warm up and then we'll get going. The problem with doing this session today is that yesterday Victoria and I ran a rather grueling 50k over the mountains in Snowdonia. So our legs are in no fit position to run a fast mile. Ideally we'd have come here fully fit, raring to go to break our mile PB on the Roger Bannister track. That's not going to happen today. So Victoria's doing her mile as we speak. So Victoria's just finishing her mile. There we are. Roger Bannister mile on the Ifleet track in Oxford. Well done Victoria. That was hard work after yesterday, wasn't it? From a UTMB World Series to a Roger Bannister mile. Right, I've still got to do mine. I've done five laps of warm up. I've got four laps from here now. And there we are. So that is our warm up. Our Sir Roger Bannister one mile and cool down done. About 6k in all. If you enjoyed the video, please do click subscribe. And comment down below what is your favourite first ever? It could be a personal thing, your own favourite first or a world famous favourite first. Let's hear your comments down below. Take care. We'll see you for the next film I run. Bye bye. I can say that I'm still the overwhelming delight that it was a great surprise to me to be able to go today. And I think I was very lucky.


Hello and welcome to NewsClick. Today we have our show Talking Science and Tech and we will talk about the Hyperloop experiment and I am calling it experiment advisedly which has been done recently in Nevada. We have with us the Raghunandan who has been following transportation technologies for quite some time. Raghunandan, if we look at this case which has been doubted as a test run, it seems to be a very preliminary exercise and best it can be called proof of concept. But really nothing more than that. It was only roughly about 100 miles per hour that even 100 years back a steam engine could have done that. So that's not particularly shall be exciting technology if you look at just the test parameters. So what does it really show? Yeah, I absolutely agree with you because in fact even as a proof of concept I believe it is inadequate because the whole concept of the Hyperloop is that you accelerate up to very high speeds and then you really don't put in too much energy in running the system because the momentum itself is expected to carry the pod forward. So I mean that's where the real energy balance of the Hyperloop system and its supposed advantage over other systems would have come into play. So this time all that we know is that yes you can run a pod inside a tube. Beyond that I don't see how much more has been done and I have not seen yet the data of what the pressure was like inside that tube. How much of low pressure or etc was created. Let's take a step back and talk about the Hyperloop itself as a technology. It's supposed to be near vacuum conditions so the air resistance is much lower. It's supposed to be magnetic levitation so you don't have rails you're really running on a cushion of magnetic repulsion as it was so that you the whole rail coaches above the so-called tracks and then there is no resistance except air resistance then what you're talking about is the air resistance is in fact the major component of the problem and if you have then a vacuum then of course the air resistance is not there. So the magnetic levitation which is that used is also being used in different places that runs into the problem of cost of transportation when the air resistance becomes high and high speeds it does. So this does not show that part of it can actually do high speeds and the resistance is there for shown to be much that doesn't happen. That's right. So without that you've not really proved the concept that the Hyperloop was supposed to be. And the other part of it is that this is basically just half a kilometer track in Nevada and there you have this pod which had two people in it and so all that you showed is that you can run a pod in magnetic levitation. Now again magnetic levitation Maglev is a known concept and I think this is this has been there for almost 75 years that as a concept and we have had functioning maglev systems from 70s onwards. Yeah that's right. So the maglev concept is quite different of course from what the Hyperloop was supposed to be. The Hyperloop incorporates the magnetic concept by having induction motors around the outer tube through which the pod is propelled. So the two things that you would expect from a Hyperloop demonstration is number one acceleration to high speeds inside the outer shell of the tube and then from there the continued propulsion largely using momentum and not requiring much energy input in terms of this. Now clearly in half a kilometer you're not going to either achieve the high speeds that you're looking for nor would you have constructed the low pressure near vacuum conditions which will enable onward propulsion using largely momentum already generated which would then give you high speeds at relatively lower cost. So neither of those we have seen so far. So do we then see at least that a tube through which this works as distinct from the normal maglev that we are seeing around at least that has been. Yeah so at least you have seen that inside a tube you can have a pod going and it's not clashing against the sides. I mean that's but you know the fact is that till now over about 400 tests have been conducted by Virgin Hyperloop by HTT by the former Hyperloop one company without people sitting inside has already demonstrated travel of the pod inside the tube which demonstrates the thing. So all you've done is you've put two people inside to show that yeah it can carry people but the same thing could have been done by using two dummies as well which also has been done by the way. So it's a bit like the manned moon exploration the as it was argued before during and later you didn't really have to have human beings going to moon you could just send cameras grams and so on which is what we have done subsequently. But the idea of the Hyperloop is of course it's supposed to revolutionize transport. Now coming back to what is the difference in terms of performance of a Hyperloop system if it does come about in terms of the speeds and what is it supposed to do in terms of cost of transportation. Is it significantly different in terms of speeds first and then of course we'll come to the first question. The two aspects are the speeds expected to be reached are in the range of 1000 to 1200 kilometers per hour. Those are the expected speeds expected to be transonic speeds which is why the name Hyperloop came about because it is supposed to be well not really hypersonic but transonic at least. So about 1200 kilometers per hour speeds which then would mean as I said earlier if you reach that kind of speed then the rest of the journey is expected to be covered largely by the momentum already generated not requiring further inputs of energy and that is what differentiates it from either maglev or high speed rail which require continued inputs of energy for the journey. Here because you've got these near vacuum tubes and air resistance is so low once you've propelled the pod and achieved high speeds it virtually runs on its own for the rest of the journey. So the economy was supposed to lie in lower running costs substantially lower running costs that was number one and the claim was that it would cost about 40 to 50 million dollars per kilometer in terms of the capital costs of the infrastructure whereas you are getting high speed rail or maglev systems approximately at 10 to 12 million dollars. So the argument of Elon Musk and the other champions of Hyperloop has been that countries which seek to establish high speed rail may as well spend a little more money and establish Hyperloop which according to the promoters then although this is mimicking rail systems the time taken would be comparable to air travel that was the selling point because at 1200 kilometers per hour you're aiming at something like a Delhi Bombay run in about 45 minutes or under an hour which is shorter even than your air travel. So that was supposed to be the selling point and then if you compare it with rail you've got a let us say Chennai Bangalore journey which takes today by about four hours by Indian so-called superfast express and may take about two hours by high speed rail etc. The promise was that this kind of distance of 400 odd kilometers you would be able to do in half an hour to 40 minutes. So these are the claims for the kind of systems that were there in terms of time speeds and costs. Quickly on the question of course of the speeds the current Maglev systems looks like it can scale up to 600 to 800 kilometers speed my kilometers per hour and 600 is sort of near 600 kilometers per hour speeds are being achieved in the trial runs already so it's not something which is very far away and also if you look at the cost what you talk about the capital cost of course as we know capital costs always go up. Yeah, yeah exactly. Land for the system if you say X it ends up it becomes absolutely X and that we have seen even after systems but the Maglev is now relatively established technology in fact Chennai airport to Chennai city center this has been running for some time and earlier also it was running in UK and I think another place Germany. Germany both are not commercially running. Even Russia had a system that's also not commercially running. But the reality is that Maglev systems now have been tried out tested extensively and therefore what Japan is doing what South Korea is doing and what China is doing all of them seem to have gone now to the direction that they can put it as a part of the high speed railway systems. So in that sense this would be the Hyperloop would be completely something quite different and a lot of new challenges which would have to go through. So there is a difference between the maturity of the Maglev systems today and what the Hyperloop would try to do. Yeah absolutely the only thing about the Maglev is like you said the current only commercially running Maglev is the Shanghai system over 7 to 8 kilometers distance. The other ones have not really established themselves commercially partly because there is already a reasonably well established network of high speed rail in Europe and they did not see such great advantage in substituting those with Maglev systems. So they seem to be quite happy doing this because Maglev will then involve new infrastructure etc etc. So they didn't see the percentage of shifts. China has always been a slightly different case including in high speed rail. China did not have a very extensive railway system earlier to begin with so they leapfrogged into high speed rail and they were prepared to invest the capital in doing that whereas most of the other countries had a fairly well laid out railway system which they partly transformed into high speed rail and partly added new completely new infrastructure and the same steep seems to be the case with the Maglev system where the Chinese have felt more free in doing that as well. The other issue with this regard is that the Hyperloop system although it is frequently compared with high speed rail and Maglev systems essentially really competes with Aetra in terms of the time factor like I was giving you examples of the Delhi Mumbai etc. thing. So the real comparison in terms of time saving and cost is in relation to air travel and the sales argument of the Hyperloop promoters including Elon Musk is when you are getting the advantage of air travel like speeds and times why would you invest comparable amounts of money on high speed rail although as we've discussed the cost can be actually quite substantially higher than high speed rail could be as much as four to five times if not more. The other question that you asked maybe we could discuss this in a separate part which is the kinds of problems you are likely to encounter with Hyperloop which have not been foreseen so far and which could then raise substantial entry barriers, post problems in terms of regulatory systems and both these put together would further push up costs compared to what we know today. Just a quick comment on the Chinese issue they have 36,000 kilometers in stone as of this year already and therefore they really are far ahead of the rest of the world in terms of high speed rail and the Maglev also both they and the Japanese seems to be quite into it. They also have they're not looking at long distances also they're looking at maybe what the Japanese are doing from Osaka to Tokyo. China would also do Shanghai to Bijik. Now there of course this is an infrastructure cost that you are building so the question when Elon Musk says why would you do that when you can actually do a Hyperloop why would you do Maglev and so on. The argument would be that this has to run on the ground therefore you have huge issues regarding land acquisition getting right of the way building that infrastructure and so on unlike air travel for example. So if you're going to get the same advantage the only argument could be how many people can travel the number of people traveling could be much more which doesn't seem to be the case either and in fact one of Elon Musk's winning points in this it is argument is supposedly you can go park your car inside the pod and then drive off of the other side which could appeal to Americans but rest of the world doesn't seem to be very interested in this particular concept. Yeah I mean that's the other advantage which Hyperloop unlike the air travel is expected to benefit by giving you connection in the heart of the city rather than on the outskirts like you have with an airport it's like high speed rail you go into the heart of the city and get into the train and like that you'll be able to get into your pod in a Hyperloop tube right in the heart of the city so it'll take you from one business district to the other district. That works if it is a Los Angeles and San Francisco kind of scenario but if you're going from Delhi to Mumbai or going from Delhi to Chennai that may not be the major argument because then the Shanghai road route which is you go to the airport Pudong airport and then you go to Shanghai city center eight minutes in a maglev might be a better option you know if you're interested in shortening that journey then a maglev to the center of the city probably is a better investment than investing in the whole route. You know there's one issue which we haven't talked about the United States has the most old infrastructure as far passenger railways is concerned. The speeds are abysmal in fact India is almost there with the United States on this if you take entire Europe virtually very few countries have the kind of speeds that you see on the American railway systems and therefore Hyperloop suddenly becomes something which is new attractive and is going to give them you know really even if they give them 600 kilometers it would be something very striking because the speeds over there is 160 to 200 kilometers it becomes very fast and most of the system doesn't work on that either. No just a small correction there just like you're comparing 600 kilometers you say for the maglev that's the maximum speed you reach in high speed rail the 150 to 200 kilometers that you're saying is an average speed which you may reach maximum speeds of 350 to 400 kilometers so the comparison apples to apples would be high speed rail gives you maximum speed of 400 and maglev seems to be able to reach maximum speeds of 600 or thereabouts. At the moment they're reaching in test tracks they're reaching about 550 odd kilometers yeah and they say that they can reach here more so the average future you could talk about apples to apple the promise of hyperloop versus the promise of maglev maglev says 600 to 600 to 800 hyperloop says 1200 to 1400 these are the promise actually implemented at the moment maglev is about both in the different places they have run it on a test track of almost 600 kilometers that's what i'm saying that's what i'm saying so that's not the promise that is the actual that's what i'm saying so 600 is what they have reached in maglev and the french high speed rail the the TGT trains regularly reach 400 max speeds which then averages out over the distance to 250 to 300 thereabouts like the shinkansen trains in japan so the comparison i think there in terms of speeds the hyperloop is not claiming only this kind of a difference they are claiming three times the speed and therefore shortening of time considerably like the example i gave you of a deli to mumbai kind of travel at about 45 minutes to 50 minutes i got i get that but the point is nothing jumps to the top of the tree in one lead so there is a good path so if for instance you go to hyperloop 1200 kilometers well you have to first they've started at 100 miles okay then they have to go from 100 miles to 1200 they won't do it in one loop shall we say so therefore the issue is really if you take realistically you might see 600 to 800 as the next step implementation wise if it succeeds so that is the the infrastructure would have to be based on that yeah so so all that we honestly all i'm saying is the united states there seems to be the need for a high speed rail particularly given the speeds that you see the united states today and in terms of intercity if you have a set of cities in which you can connect them to high speed rail then perhaps it would really help the united states in terms of transportation and for that hyperloop or maglev if that is the option then at least it's a something which is starting afresh because they don't have a high speed rail system in the united states but when there is already high speed rail system so you really get high speed rail system maglev hyperloop these are the options then those are the kind of options that countries will consider you already said for instance in europe they are not looking at maglev because the high speed railways have enough potential in fact the tgv that you are talking about they have reached speeds of about five seven that's right exactly so therefore that's not such an issue so no all the all the discussion we've had till now are really the hypothetical promise of the hyperloop the hype the hyped hyperloop promise shall we say whereas once you come down to practicalities there are going to be all kinds of issues that will come up for example okay now you've had a run with two human beings sitting inside over a half kilometer journey but if you have a 500 kilometer journey running at 1000 kilometers an hour we have no idea of the kind of safety issues that are going to come up therefore what kind of safety regulations are likely to be required therefore what kind of costs are likely to build in terms of the infrastructure etc these are complete unknowns right now completely unknown we don't know them at all we have no idea about performance of the hyperloop system of the pressure low pressure vacuum type maintenance maintaining that over a long period of time how that will work we don't know we know for example that when Elon Musk has been holding discussions across the US on the hyperloop he was reminded quite often that drones for example today the technology may be known but by the time the regulation to practical applications of drones in civilian utilization come about it has taken more than six years to even reach a stage where regulatory standards can be laid down safety standards can be laid down etc so the practical translation of the hyperloop is I think so far down the road that we are not even able to envisage how that works the same with autonomous vehicles on the roads except for trucks the passenger vehicle segments of autonomous vehicles we are still many years away from standardized regulatory systems and safety requirements let's talk about what the practicalities are likely to be let's talk about autonomous vehicles another day because that's really new kind of worms okay because you're talking about artificial intelligence driving vehicles so that that part has just been about for the time being but I just like to conclude that Elon Musk has been propagating this but he's not putting his money in this space xx or the electrical batteries electrical cars this is not where he's putting his money yes he's letting others put his money but he's a promoter he's using his success with electric cars electric batteries and of course overthrowing the bolivian government for lithium for all of that basically in fact he made that as his tweet live with it that you know we can overthrow governments okay on the question of bolivia so if we take all of that into account what we see is Elon Musk wants others to carry this baby this is not where he's putting his investment he's putting an investment in space xx and of course on the cars so this is really the high profile hype that he adds and Elon Musk after having made a success with cars electric cars and with the space xx is now saying this so the people put in this money and it could be argued that the main reason for the hyperloop hype that we've seen you see 100 mile per hour would not have created a hype except for the hyperloop hype already getting to be Elon Musk so that you can get capital into these companies what you really have is this kind of hype works for essentially raising capital on the money market and maybe this experiment therefore was rushed more with an eye for that than for really proving technology yeah except in this case of course you've got that other maverick he's not an inventor like Elon Musk is but he's a champion of a self-proclaimed champion of these frontier technologies virgin is competing with Elon Musk for space travel and Richard Branson would like to see himself as this tomorrow man and so Richard Branson has put some money into this and as you say that's right virgin hyperloop system and they're all eyeing a future prospect of this and are really targeting countries which have underdeveloped rail domestic rail systems and you will see one of the major pushes for this coming in the Middle East area where there is money available and there's a lack of an effective railway system and that's where they're trying to do it trying to tap into the aspirational oil money of the Middle East and combine it with the show of the high-tech promise that Branson brings to the table so we can expect to see maglev versus hyperloop go head to head on such fancy projects that's right focus projects in west Asia where they made money but looking at it at the moment it looks like it's the real target is not so much west Asia not so much railway systems but the share market and the capital markets could very easily raise money because that is going to determine the future of the hyperloop that unless there is money you need a couple of billion dollars to be able to bank role a functional system because right now apart from angel investors and a few multi-billionaires who are prepared to invest a few a couple of hundred million dollars you're not seeing money going beyond that and I frankly do not expect the share market to respond very well at this stage of development of the technology no that is why the hype rug is important yeah whether it's a Pfizer hype or it is a Remdesivir hype that we saw earlier all of those hypes I'm not saying the Remdesivir didn't pan out but the Pfizer vaccine may but a lot of it is targeted at the stock market because you can see the ones who start the companies or who are the basic the major stockholders start selling their shares and the share market goes up after such hype and we'll have to see and observe whether Branson puts in more money or sells his shares or recoups that money very quickly all I'm saying is that technology game is as much about hype and the share market sure is about technology sure not of course this is does not mean that the the hyperloop therefore is a failed technology it is not the question is the cost benefits we'll have to see what are the real costs that we'll have to see on the ground and whether the economies of that systems will make sense that has been the problem with Maglev systems as well why these are the high speed rail so all of these things are on the table but all of that Raghu today shared with us is that this experiment doesn't settle all those questions it's just that you see well the technology is feasible which we already knew we have put two people in the pod to show that yes human beings can be carried and that is something which we did not really need to do in order to prove this fact but on that note we'll let it go and we'll meet with Raghu again on such issues as well as following up the hyperloop system what happens to that hype and how it pans out thank you Raghu for being with us for our viewers do keep watching news click and do visit our website


The East Africa Rice Conference 2021 will zoom in on thematic topics crucial to agricultural growth and food security in the region. Learn from scientists and experts about different topics that support sustainable agriculture and improve farmers' productivity and livelihoods in the region. Rice research and development. Rice research plays an important role in addressing major challenges related to rice production in the East Africa region. This session will focus on two critical aspects. Rice mechanization and post-harvest technologies adapted to local conditions and the roles of regional centres of excellence in accelerating rice research for development. The use of agricultural machinery is limited in the region, and harvest and post-harvest losses are relatively high, with dominance of traditional production methods leading to low yields, poor grain quality, and less market value and competitiveness compared with important rice. Scientists and experts in this session will share experiences from Asia and Africa to effectively address these issues. Several centres of excellence are now being established in East Africa to act as incubation centres and lighthouses for innovative research, capacity building, and technology validation and dissemination. Two models will be presented. This session will also bring in discussions on potential roles that these centres should play in coordinating research and development efforts in the region, including those under the new OneCGIAR initiative. Inclusive markets and value chains. Inclusive agri-food systems can reach, benefit, and empower the population, especially the socially and economically disadvantaged groups and individuals in the society, both producers and consumers, helping to contribute to multiple sustainable development goals. This session will focus on how inclusive rice-based markets and value chains can bring a wide range of economic and development benefits. It can create better income opportunities, thereby reducing hunger and poverty. Key actors can spark innovation in the production and consumption of healthy foods, thus improving nutrition for both producers and consumers, and boosting the incomes of small holder farmers and other rice value chain actors. In East Africa, rice-based agri-food systems are now at a critical juncture. The scale and the pace of change taking place in regional, national, and local food systems are unprecedented. These systems are evolving quickly to meet growing and changing demand, but they are not serving everyone's needs. This challenge is compounded by the COVID-19 pandemic. As the international community battles the pandemic and as African economies and livelihoods are disrupted, poor and vulnerable people are likely to suffer. Addressing the immediate impacts of the shock urgently requires effective targeted policy interventions to protect the most vulnerable in the short term. Thus, an inclusive value chain approach can zoom in on the hidden middle of the rice value chain. As rice value chain becomes longer and more complex in response to urban demand, there will be a critical need for ensuring food safety and quality through regulation, certification, and inspection, as well as innovations for storage and transportation. Rice-based livelihoods, gender and youth integration. The Rice-based livelihoods, Gender and Youth Integration Stream is focused on the integration of gender and youth in programs and processes to support the transformation of rice-based agri-food systems in East Africa. Women and youth play a large and growing role in East Africa's rice systems and constitute up to 80% of the agricultural workforce in some countries. They handle most farming operations. The role of youth, especially young women, is also pivotal. Yet notwithstanding the central role of women and young people in the region's rice-based systems, there is still an unsettling disparity in the support they receive from both public and private sources, a key reason behind their lower average productivity compared with men. They acquire only a small portion of their harvest because of the existing norms, policies, and laws that put them at a significant economic and social disadvantage. Women are also at a disadvantage in accessing inputs, mechanization, and knowledge of new technologies and innovations. In addition, their access to credit and financial resources is minimal because of current lending policies of financial institutions. Youth, on the other hand, are marginalized in many countries lacking sufficient employment opportunities, land if they choose to stay in agriculture, and financial capital if they attempt to enter the rural, non-form economy.