Okay, so who am I? I'm Mohan Muthukumar. I'm a senior software engineer at Avalara, the largest tech company that you've not heard of. We are in the tax compliance business and we are almost part of every transaction. So if you've bought something online, there's a very good chance that it went through Avalara systems. And so the task that my team does is we go over the internet, crawl a lot of pages, look for product information, tax changes, startup changes, all these things. And effectively we have to run a mini Google. So given the scale of our operation over the years, we've seen all kinds of systems. I mean, if you can name it, we've done it. So the topic at hand, microservices are becoming unmanageable. So if you work at a large company or even a moderately sized company, all this would be very familiar to you. These days, there are more and more microservices. You have a single engineer managing 2030 microservice and all the plumbing code to make all these microservices stock with each other plus the DevOps surrounding it. All this seems to take much longer and a lot of yaml, much longer than the actual business use case. You'll end up in a scenario where let's say a business use case takes only three days, four days to build, but all this deployment and plumbing code making and making sure everything can talk to each other, all that takes a week to x of what it took to queue to solve the actual business use case. So this is, you know, this is not a good situation to be in. So this is just to be clear, this is not a let's return to monoliths like good old days kind of talk. So this is a talk that's, I mean, this is a sentiment that's becoming popular in certain circles and I don't mistake them because, you know, things used to be much simpler 15 years ago. All you had to do was just write some code, deploy that in an application server and you just had a web app. So there is a reason why we got here and those reasons just don't go away so you cannot return back to monoliths. So let me give you an oversimplified version of how things were and how we got here. So this is how things were 15 years ago, you had a single service with multiple concerns. You had all the clients actually talk to this single service. So you had signups, you had multiple resources in different parts and you just saw that. But a couple of things happened after that one, the internet happened. So instead of serving thousands of users, thousands of users, now you had to serve literally hundreds of millions of users. So the internet scale happened and then the most popular runtime Node.js that kind of improved the developer productivity by a lot ran only on a single thread.  So you're essentially going to be wasting a lot of course. But a few years later, Docker came in and one of the things that it gave us was the ability to run multiple Node processes on a single machine. So that suddenly gave you a way to utilize all those ID cores. And so people had something like this. You had multiple copies of the same app running on a single machine and you had multiple copies of the same app running across machines as well. It didn't make a difference. And you just put a load balancer in the front and any client talks to the load balancer, the load balancer directs the request to any client at random and you can just, you know, serve the traffic. And so you're able to scale really well. There was a problem with this. I mean, rather than running multiple copies of the same app, it made sense to slice these up vertically and have these scale up separately. So maybe you don't have a lot of slash sign up slash login requests. So how about we take all that and make the quintessential example of a microservice, the user service and deploy that separately. So people started slicing things up vertically and it also helped that most organizations also could have dedicated teams working on dedicated services with a limited scope. So people started slicing things up vertically and it also helped that you can scale these things separately. Let's say, you know, there is a service that is getting a lot of traffic. You can just scale that service independently without allocating resources for everything else. So it made sense. And this is, I mean, if you ever see microservices, this is probably, this is a diagram that you would have probably seen already. Except this is not true, right? So this is true only, if only your client is the only thing that's talking to all the services, only then this is true. But in reality, more often than not, your services need to be talking amongst themselves too. And so your diagram starts to look something like this and you can already see it becoming more complex than that the previous diagram showed. And soon enough, since there is nothing stopping people from creating more microservices, it is going to look like this. So this is an actual image from Netflix and it in fact looks like this. Now imagine working with a system like this. Not only is this unmanageable because nobody has a complete view of the whole system and companies also have dedicated microservices, sorry, dedicated platforms team, dedicated SRE teams and all that just to alleviate the pain of dealing with this complexity for the business developer. So not only is this unmanageable, but it is also unreliable. What happens if imagine working in this environment and you want to create a new service, you want to deploy a new service, you don't know what is going to break, right? So just as soon as you deploy a new service, if something is wrong, it could bring down the entire system potentially. So developers tend to work in this frightened environment. And also one thing that is often overlooked is if a service call fails in a distributed transaction, let's say for example, if you're doing an ordering service, an e-commerce service, if a service call to the payment service fails, you should also revert whatever came before that, right? I mean, revert the dispatch, something like that. But in a situation like this, people tend to miss that, right? And it's not obvious to people that they should be reverting everything that came before them. So this kind of makes things unreliable. And we kind of got here for scalability, right? We wanted scalability and we sacrificed reliability. And kind of this seems generally true anytime you try to increase scalability, your reliability suffers and anytime you try to increase reliability by introducing transactions or locks, your scalability suffers. But this is not actually true. This sounds true, but it's not true. You can have a system that's both reliable and scalable. So that's where you want to be, right? So is it possible to build a system like that? I mean, we've done this in the past, but it requires a Frankenstein's monster of systems. You need complex state machines involving Kafka queues, distributed locks using HCD, all those kinds of things. You need a centralized data store for anything that's critical, all of those things. And it might still break when a new service is introduced. There is no guarantee. And it does nothing to improve your situation with respect to rollbacks, right? And also, given the number of systems involved, you will have to write, you'll have a lot of different tools, deployment tools, CI tools, all these kinds of tools, and you'll have to write literally ungodly levels of YAML.  So this is the situation. And is there a better way? There is a better way. I mean, if you, for an analogy, if you think about operating systems, operating systems have solved this. Hardware is unreliable, just as distributed systems are. Network is unreliable. So is the hardware, so is your actual hardware, right? But your program doesn't need to account for that because your operating system gives you an abstraction. Your operating system abstracts all this away from the actual programmer, right? So what we need in the case of all these distributed systems is an abstraction. And Temporal is just that. So just to give you a bit of background on what Temporal is. So this is a project that's been brewing for the last nearly a decade. It started the team behind Temporal was also the team behind Amazon Simple Workflow and also the Azure Durable Functions. And right before Temporal, they were working on this open source project from Uber called Cadence, which is very similar to Temporal, aside from some internal differences like GRPC and Fifth. So Temporal treats your entire application as a workflow. You have this idea of everything being a workflow. So everything is a series of steps that executes to completion. If you think about it, that kind of describes any computer program, right? You have a series of instructions that just run to completion. But what makes Temporal different in this case is they have durable state, unlike let's say any, I mean, no way. So they have durable state. And you can do all this using code without writing any YAML.  So you don't have to deal with writing to the right queue and all that. And it also stores your execution state such that if something happens to your workflow because of some infrastructure issue, it can just recreate that state in a different work or a different part. So this kind of sounds like the missing piece in the stateless Kubernetes ecosystem, if you think about it. So creating a Temporal system is pretty easy. So you have workflow functions and you have activity functions. So workflow functions, in workflow functions, you need to specify what comes after what. And essentially, you create the state diagram using the workflow functions. And the workflow functions need to be deterministic. And then you have activity functions, which can be just any kind of functions. So let me just give you a hello world example. So here you can see you have a function, the workflow function, and then you have the activity function. So the workflow function has a few config stuff. And then you basically specify that you want to execute this activity. And this is your activity function. All this does is just return hello plus name, your general hello world example. So this is just going to return hello world to this result. And the workflow is also going to return hello plus name, right? That's basically it. So here is a more complex and more useful example. So let me actually zoom into the first part of the code. So here, if you see the first part of the code is just me setting up some config stuff for timeouts and retries. So if you see, we have some retry policies for the activities, I'll come to that in a bit.  So the interesting piece is the bottom half. So let's let me go to the bottom half. Let's throw away the config part. So this config part, you don't actually have to specify there are sensible defaults. So some of these are required, some of these are not. It'll actually for the things that you don't specify, it'll actually use the default value. And so this is the bottom half. So here, if you see, imagine an e-commerce workflow, right? This is just a part of an e-commerce workflow. Let's say you already have plays an order and now, you know, you need to start subtracting from the inventory. You need to take the item off the shelf so that somebody else doesn't add it to the card. And also, you need to send the user to the payment page. And let's say you want both of these running simultaneously. And so essentially, we've invoked both of these activities simultaneously. And here on line nine is where, you know, you are awaiting the result by doing a dot get call. So if you are now, both of these are going to get executed simultaneously. And here, if you see, we are using Golang's error handling primitives, the way you would normally handle errors in Golang to actually handle an activity failure. So this will, based on our retry policy that you saw on the previous screen, this will already try multiple times, five times, for example, or until you hit the exponential back off threshold. There's a lot already try five times. And if it tries, if it reaches the maximum number of attempts allowed, only then it'll go into this block. And here you can see, you know, if the payment info, info fails, we are putting this back to the ship. So we can just handle the compensation logic inside your error handling. And, you know, it will be, it makes it a lot easier to wrap your head around this. And if you think about it, there is a problem with this code, right? So we are doing this for the payment activity, the payment activity fails, but we're not doing this for the inventory activity, right? So it becomes very obvious that we should also be reverting the payment, but we're not doing it. So you can actually catch this during a code review. Imagine how long it would actually take for you to find out about this in all those YAML based systems where chances are things don't even exist in the same repository. Yeah. So let me give you an example of the activity. All these are, you know, activities can be anything, any goal and function. The only requirement is that it needs to take a context as a first parameter and return an error at least. So here I'm just making a HTTP call to this inventory service. I'm just making a post call. And if the post call fails, I'm returning the error for the post call field. So obviously I don't have the service running. So, okay, before that, so both these activities and workflows need somewhere to run. So that is your worker code. So here, if you see, we have, you know, we are configuring a queue name for the worker and then we are registering every workflow and also every activity with this worker. And then since this is going to run as a Kubernetes pod, we have set a health end point and that's basically it. Now, since this worker is going to be part of a deployment, if you want to increase the throughput of your workflow, all you have to do is scale this worker and, you know, depending on the logic of your workflow code, it is going to horizontally scale. So this gives you reliability since workflows are durable, like anything that you have in the workflow function will actually complete. There is no infrastructure failure, that can actually prevent the workflow from completing. So let's say a workflow function is running on a worker and the worker goes down because, you know, for some reason, any reason, your spot machine went out or something like that, any reason, Temple will know to restore that, restore the state of that workflow in a different worker and we'll resume the workflow. So, you know, that gives you a lot of reliability. Plus, like I showed you, you can handle your failure cases using the other handling constructs in your programming language and you cannot, you cannot forget to handle it and you'll catch it during your code review.  Imagine having to reinvent this every time you're sending an external request that to a flaky service and pretty much anything across network is flaky given long enough time. So you would want retries and Temple gives you that out of the box. So, going back to our activity code, since none of those services actually existed, all my attempts are actually, all my tries hitting that service was failing. So if you see, if you look at the standard, standard out, you can already see that we are attempting it multiple times. So you can see attempt two, attempt three. So, and also you can see that we are in fact hitting this simultaneously. We're not waiting for the payment gateway payment activity to finish in order to hit the inventory activities. So we are trying both of these simultaneously and both of these are failing. And you just by looking at this, you will just by looking at your logs, you can tell that, you know, this is the activity that's failing. Plus, Temple also gives you comes with a web UI, just like Kubernetes. So this is an optional piece that you can install. So this will give you a bird's eye view of all the workflows that are running all the runs that we have. So you can go inside any of these runs and it will give you the entire event history of everything that happened. So here you can see on line 13 that this is the reason you know, this is this is the part that is failing. And it will give you the reason for the failure and the number of price. So this is now here it says attempt five. So this is this this part is being this activity is being tried for the fifth time. And now since that also failed, it says maximum attempt reached. Right. So and that was on reliability and on scalability. So part of the reason why you end up with hundreds or thousands of microservices is one, it's convenient to start a startup whole project from scratch, but also because people try to tend to prematurely decouple services in anticipation of future scale. Right. People might think, hey, maybe today I'm getting only hundreds of requests, but in the future, this can potentially have hundreds of thousands of requests. So let me actually decouple this and put this as a separate service so that I don't have to decouple that at the time. And because people have burnt their fingers trying to decouple monolithic machines, right. So people want to prematurely decouple services these days. And but you don't have to do that in case of temporal. So all you have to do, let's say, let's take this example. So you have three activities running. And let's say, for example, online line 15, the payment activity needs to run at a different concurrency. And let's say it's also an expensive call. All you have to do is just remove this activity from this worker and create a new worker, register that activity over that, and now deploy this worker in a separate Kubernetes deployment and can scale that independently. And here if you see, we have also set the concurrency to six, the default is 1000. So you can have only six instances of this activity running for this worker at any given time. So that way you won't be bombarding the payment service with a lot of requests. If you have especially burst traffic, you'll only be handling six requests at a time. And you don't have to also prematurely decouple services because it's as simple as just registering an activity and registering it in a different worker. So if you think about it, I mean, I'm sure all of you have services at your company that do not really get a lot of traffic, but still need their own deployment because there is no other way to deploy it. There are services that hardly get 100 requests a day, but they run as dedicated services. But with Temple, you don't need dedicated services for that. That can just be another activity executing the logic inside the activity function itself, and this can get scheduled whenever it is required. So that way that also reduces the number of microservices that you need. And your application can be made of thousands of workflows, and all these workflows can actually be executed concurrently. So let's say you are building a complex application, there is no limit to the number of workflows that an application can have. In fact, every day we run 200,000 workflows. And also if there is no limit to the number of activities your workflows can execute, the only limit is you can have only 50,000 events, and you can basically work around that limitation by creating child workflows and making sure that no child workflow has more than 50,000 events in the event history. So one more thing. Now, if you remember the beginning of my talk, I told you part of the problem is also all these infrastructure automation tools for which you have a right conflict. What if your application can bring its own infrastructure? Imagine at the beginning of the workflow, you have an activity that talks to the ASG using AWS SDKs or CDK, anything, and increases the ASG count. Let's say you start with five, you increase that to 10 at the beginning of the workflow, and then you talk to the Kubernetes APIs to increase the part count, and then you execute your business logic, the actual logic that you want to execute that we built in the previous screen, for example, the commerce workflow. You execute that as a child workflow, and then on the way out, you can decrease the part count, decrease the ASG size, and also maybe perhaps send a Slack notification indicating the workflow completion. And you did all this without using a single, without writing a single line of Yaman. So yeah, I mean, your application can bring its own infrastructure. So other use cases, we have a lot of these DAG based systems like data pipelines, the ELT pipelines, and machine learning pipelines. All these actually tend to naturally lend itself to temporal, because temporal DAG based pipelines are a subset of what temporal can do. And also CI CD systems, like I showed you in the previous example, can very easily become temporal workflows. And making them temporal workflows opens up a lot of possibilities, running smoke tests, running integration tests, running chaos tests, all those kinds of tests can be done. You get a lot of flexibility. You can also, aside from these DAG based systems, you can also build complex event driven systems. So temporal gives you a construct part signal. So just like how you can wait on a Golan channel, you can wait on an entire workflow. So your workflow execution is going to halt until you receive a signal from that signal. I mean, you receive an input from that signal. And one more thing that you can do is you can build your own DSL based workflows. Let's say you already have some DSL that you want to execute, you can use temporal to write an interpreter, you write an interpreter for that DSL, you can execute that. Yeah, closing dots. So you don't need me to tell you how powerful an abstraction can be. You already saw that with Linux containers, with Docker and the kind of impact that it did, kind of impact that it had, you already saw that with Kubernetes services and the kind of impact that it had. So a few years ago, we had this serverless moment at the peak of the serverless moment. We had pretty much every single cloud company come up with an offering, and also a promise, a promise that developers wouldn't and shouldn't have to deal with all this glue code around their business code. And that ops will also be taken care of seamlessly. But that kind of fizzled out, right? So now here is a system that helps you check a lot of these boxes, although in a different way. So with this, you know, temporal might just be the system that fulfills the promise of serverless. And with all this unlocked productivity, imagine the possibilities. So thank you. That was my talk.


This video is part one of factoring. To begin with we want to use a process called x factoring and to do that we need to look at this x here. In the top of the x we're going to put a product and in the bottom of the x we're going to put a sum and then on either side is where we're actually going to find our factors and it works this way that with factors m times n would multiply to get this product and m plus n would add to get the sum so you're going to just kind of take the two numbers and do the top and the bottom and see what happens. So let's look at this one. We won't normally do it this one but I want to get you in the habit of looking at products and sums. So the product is negative five times eight or four negative forty and the sum is negative five plus eight which would be positive three and the next one negative four times negative eight would be a positive thirty two and if we take four negative four plus a negative eight we get a negative twelve. So now let's go the other way. We want to find that m and that n. So factors of eighteen that add up to eleven well you could sit here and start listing your factors one and eighteen if I add those that would be nineteen and two times nine would be two plus nine would give me eleven. So that must be my factors so I have a positive two and a positive nine again two times nine is eighteen two plus nine is eleven let's try with negative twelve if we start listing our factors we could have negative one times twelve but that would be negative eleven we're trying to get to negative one. So then we could try negative two times six that's also negative twelve that's a positive six and that would give me a positive four that doesn't work. We also have negative three times four and that would give me a positive one so I'm close here this would give me a positive one if I change my signs and make that three and negative four when I add those I will get negative one so I want negative four and positive three. So how do we use that? Well first before we really start factoring we have one more thing that we need to look at before we can actually factor. Just to notice a couple of things that are always true about factoring. So here we have x squared plus nine x plus fourteen and I've told you that it's x plus two and x plus seven. Same thing here we've got this x squared minus four x minus twelve and it factors to x plus two x minus six and again we have x squared plus two x minus three is equal to x minus one x plus three and I really should have a fourth one in here so let me give you that one and it would be x squared minus five x plus six and that one would factor to x minus three and x minus two. So if you look at the factors of the first term if you look inside our parentheses of our binomials the factors of x squared are actually these first terms so the factors of the first term are the first terms of our binomial and if you look at the last terms fourteen factors of fourteen one factor is set is two and seven. Look here negative twelve one factor set is two and negative six and also here negative three we could have negative one and three that's one way to get to negative three so the factors of the last term were the last terms of my polynomial or my binomials. Now let's look at the positive last term that would be this case here and the one that I shared with you and added on. If I have a positive last term notice I had a positive and a positive and I have a positive last term in this case I have a negative and a negative or remember to get a positive you have to multiply two of the same sign. How are we going to know whether it's a positive or a negative? Well look at your middle term. My middle term is positive nine and so are my two signs in my binomials. This is a negative five and so are the signs both negatives inside my binomials. So the positive last term the signs are the same and let's take it one step further and say they're the same as the middle. So our last two cases in it when we have a negative last term and remember to get a negative you have to multiply a negative times a positive you have to have opposite signs so you have to find the right combination but they will always be opposite. We're going to be factoring and look here we're going to make sure that A is always one in this video because things work out nicely. So if I look at this I want to say what C and B are actually we should call it AC. If I did A times C one times six would be six and my B is a positive seven and this is a positive six alright and here's where the X comes in. This is my A times my C so that's my six and this down here is always going to be my B that's my plus seven. So what are factors that I added together to get to seven that are factors of six well that would be six and one both positive because it's a positive number I need the same signs. So here I've given you X plus one so the other one must be X plus six. Say again let's look at AC that'll make it easier for the next video. So A is one and C is six this is my A and this is my C and this is my B. A times C would be again positive six and my B is this middle term which is negative five. So if I make an X for that one I have positive six in the top negative five in the bottom and I need to find factors that will add up to negative five. Now it's a positive first term that means my signs have to be the same and if I'm going to add together and get a negative number that means both my signs had to be negative. So I have factors of six one and six won't do that that would give me negative seven but a negative three and negative two will give me negative five when I add them. So it must be X it was a negative three and X minus two because it was a negative two. Alright again AC let's try a different color AC A is one C is negative eight so we have negative eight and our middle term is negative seven so again making an X here my AC goes in the top that's negative eight my B goes in the bottom that's negative seven and so factors of negative eight that will add up to negative seven well they have to be opposite signs this time since it's a negative and I want my bigger number to be negative because I'm going to have a negative result and so I think it's negative eight and positive one which adds up to negative seven. So I have X minus here for you so the eight would go in this factor and then it would be X plus one for our second factor and finally again we're going to do A times C so one times negative twelve is negative twelve B is the positive four in the middle and if we make an X for that one negative twelve and a positive four remember now we have a negative in our product which means we have to have a negative and a positive number and factors of negative twelve that will add up to four you can't think of it right away again try negative one times twelve nope that doesn't do it that's negative eleven negative two times six oh that's a positive six and there it is right there four six minus two would be positive four so we have negative two and positive six until we would say X minus two and X plus six now I want you to notice that if I gave you the option of what you wanted to put in there we could have written X plus six and X minus two these two things are the same so it doesn't matter what order you put them in you just need to make sure that one goes in each factor so let's try one from scratch so always look for your greatest common factor first we haven't been doing that because we wanted to concentrate on the how to do it but now we're looking do we have a greatest common factor well we don't this time so there's nothing there okay and my A times my C is going to be one times negative ten so that's negative ten my B is positive three so in my X I'm going to rewrite it over here because that one's got words all over it my AC goes on the top that's negative ten and my B goes in the bottom that's positive three so factors of negative ten what does that tell you it tells you that you've got a negative sign and a positive sign so we're really going to kind of subtract these numbers that will give us a result of three well negative five times two would be negative three but negative two times positive five would give us a positive three so negative two is one of our factors five is the other one and if we fill it in here we have X plus so it would be the plus five and X minus that would be our two and that would be our factorization


just like to say a few words. First of all, first of all, okay, the night is ours but we want to congratulate our opponent for running a clean campaign and a tough campaign and we congratulate him. It's not easy to lose but he deserves credit for running a damn good campaign. I think what we can say tonight is that we have won an incredible victory. Not only, not only have we retained the mayor's seat, we have won in ward one, in ward two, one in one. Okay, Terry, man. Terry Voracious. Is Sharon Bush here? Sharon here yet? Is Tom Smith here yet? Tom, Tom Smith. And from what I heard on the radio, we are still alive in ward five, Bentley here. Mary Bentley here. So what we have done is won three automatic seats and we have a shot at a fourth. And furthermore, furthermore, from what I could understand, we have won every one of the initiatives that were on the ballot. If that is in fact the case and we haven't seen the final results, among other things, what that does mean, after years and years of discussion, we are going to get the people oriented waterfront that we have fought for. The last point that I want to make is this, that tonight's victory clearly would not have been possible without the work of an enormous number of people. There's no question about it. We have never had, never had as good a volunteer and grassroots effort as we have had in this campaign. And there are hundreds of people that we could bring forward right now. But I want to bring at least two people forward. Jim Schumacher. You called the office whether it was early in the morning or late at night, Rachael Levin was there. Okay, what we have done tonight, let's take stock of it. What we have done tonight really is a credit to all of us and to the people of the city of Burlington. What we have shown is that after six years of being the only independent progressive government in the entire United States of America, that after six years, not only are we not getting weaker, we're getting stronger. That responsibility of being a unique type of government in America goes not only the obligation to continue to do the very best job that we can for the people of Burlington. And that goes without saying. And we're going to continue to do that. But equally important, we have got to be an example to the rest of the United States of America that a grassroots movement standing up fighting for world peace, fighting for social justice, fighting for economic democracy, for the rights of all people, rather than just the very rich, is an idea that is as American as apple pie. As Tom says, as Tom says with Vermont apples, that's right. Okay, so I look forward in the next two years with your support and with the support of all of the people in our city to make these next two years the very best that we've ever had. And I thank all of you very much. Thank you. Clearly, not only did we win and retain the mayoral seat, but we did clearly very, very well in terms of the automatic elections. We have, through the victory of Sharon Boucher won another seat on the Board of Aldermen, and it's, I think as most people know, it is not easy to defeat an incumbent. And I congratulate Sharon and the people in Ward 1 who worked so hard to bring that about. Terry Boricius won reelection in a very hard race. Tom Smith won election. And Mary Bentley did extremely well in Ward 5 and is going to be involved in a runoff election. And we're very proud of that. That's really quite a feat. I think of equal importance to me from the automatic and mayoral victory is the fact that we won and won decisively on every single ballot item that appeared before the people of Burlington yesterday. And in my view, what that shows is that the people of Burlington have confidence in the future of their city. And it's one thing to vote for a candidate for election. You have two choices and you're going to vote for one. It is another thing to vote for six ballot items, including several money items to raise your own taxes because you believe in the city and the greatness of the city and in the future of the city. And obviously, as a result of those ballot item victories, it means that the school department is going to have the necessary funds so that we can adequately educate our kids. It means that we're going to be able to expand and improve our police department, something that I believe is absolutely needed. It means that we're going to finally have the kinds of money that we need to create a people-oriented waterfront so that Burlington's extraordinarily beautiful waterfront will be open to all of our people forever. It means that we are going to be able to provide property tax relief and a rent as rebate program to supplement the state program for the poorest people in our city. And in fact, as part of that ballot item, come up with a major alternative, another alternative to the property tax. And that is, of course, the property transfer tax, one-half of one percent. That issue is going to be brought down to Montpelier immediately. And we're going to do our very best to make certain that the people of Burlington who voted overwhelmingly for that item get their way and not be rejected by the legislature. And lastly, we have passed the strongest condo conversion bill in the state, which will enable us to protect affordable housing in the city. And we're very proud of that. So I think overall, not only in a partisan political way was I gratified by yesterday's results, and I obviously was. But also I think what it confirmed to me is what I think many people believe, that the people of Burlington are proud of our city. They feel that we're moving in the right direction. And they're willing to, in some instances, vote themselves higher taxes in order to continue that effort. So it was obviously, from my point of view, an extraordinary night. As I said before the election, and as I repeat after the election, this is going to be my last term as mayor of the city of Burlington. I am as proud as I can be and just grateful and humble for the mandate that we received yesterday from the people to continue another two years. It's going to be an exciting two years. A lot of ideas in the back of our minds that we'll be talking about within the next few weeks. I'm very optimistic about the future of the city, and I'm looking forward to a great two years. Thank you.


There is a long history to the Iran Hostage Crisis that really begins in the middle part of the 20th century. Iran emerged from World War II under the control of a monarch who was known as the Shah. The Shah means king in Persian. So the king of Iran or the Shah of Iran was a man named Mohammad Reza Patlavi. He emerged from World War II as the leader of Iran in a position of partnership and friendliness toward the United States and other Western powers. Now, about five years after World War II in 1950-51, the Iranian people rallied behind a nationalist politician named Mohammad Motsudak, who became prime minister of Iran in 1951 and who challenged the Shah for power and control in the country. There was a brief period of political turmoil which ended in 1953 when the U.S. government and the British government sent their intelligence agencies into Iran to overthrow Mohammad Motsudak and restore the Shah to full power. That was seen at the time by the Eisenhower administration as a great foreign policy success because it restored Iran to a friendly power and stabilized Iran for the foreseeable future. For 26 years, in fact, the Shah remained in power as a friend and partner and ally of the United States government, and he provided certain goods to the U.S. such as access to affordable oil and a sense of military security in the vital region known as the Persian Gulf. Now, the action of 1953 also planted some deep seeds of resentment against the United States in the hearts and minds of the people of Iran. They lived for a generation under the military boot of the Shah's regime, if you will. They were oppressed by the Shah, kept out of political power. But gradually, especially as the 1970s passed, the Iranian people began to rally behind revolutionary leaders like the Ayatollah Khomeini. The Ayatollah Khomeini was a religious figure who did not live in Iran but actually lived in exile, first in Iraq and eventually in France. And from exile, he began to organize a revolutionary movement within the country through the network of religious leaders who resided throughout the state. Push came to shove at a revolution erupted in the late 1970s that led to the overthrow of the Shah in early 1979 in the heroic return of the Ayatollah Khomeini to Tehran a couple of days later. The Ayatollah Khomeini then spent the remainder of 1979 building a religion-based, a theocratic state, a new government in Iran that would be based on the precipice of a certain brand of the Islamic religion and one that would be completely purged of any influence of the old, royalist government of the Shah. That regime had an anti-American flavor to it because the Americans had been the best friends of the hated enemy, the Shah. Naturally, there was going to be tension between the new Iranian government and the U.S. government. Now, for several months after the revolution from January 1979 to November 1979, although tense, the relationship was stable, the embassy in Tehran remained open, the U.S. diplomats continued to engage in day-to-day business with the Iranian government and in Washington, D.C., the Iranian embassy continued likewise to engage in routine business with the U.S. government. The militant students were essentially a group of young, non-official, everyday students, young people, young adults, workers who had been so fired up by the Iranian revolution that they spontaneously took to the streets to demonstrate and protest and shout angry slogans against the U.S. government. It appears, and here we have to engage in some guesswork because this is a mob activity, there's not a real good document trail. We don't know exactly what they were thinking, but it appears that they thought that they could demonstrate against the embassy and maybe somehow embarrass the U.S. government by crashing through the walls of the embassy and taking over the place and maybe rifling through the files, maybe trying to capture some secret documents, maybe embarrassing Uncle Sam. They would do that simply as a way of expressing their anger, eventing their frustrations, of bloodying the nose, if you will, of the U.S. government. It does appear that they fully expected that the Khomeini government would honor the principle of diplomatic immunity and would immediately use police and military forces to end any such demonstration. But what they found was that the Khomeini reacted to the events of November 4th by giving them his blessing, by saying that he was glad that these proud sons of Iran had invaded the den of spies that was represented by the U.S. embassy and had embarrassed the U.S. government. That surprised them, pleased them and surprised them, but then put them in a position where they felt they had some political power and some political influence and they certainly had the ability then to keep the hostages in captivity for a prolonged period of time.


The contractors under the umbrella of the Niger Delta Development Commission ended a C Indigenous Contractors Association having the past six days taken over the premises of the commission in protest are frustrating all official activities. Take a listen. The contractors who are of Niger Delta origin with placards bearing different inscriptions noted that all attempts to get their pay have proven abortive. President of the Association Andrew Ejegwai regretted that the contractors for over five years have not been paid for the services rendered to the commission describing it as an act of wickedness. For the past four years we have been waiting for our payments giving us all sorts of excuse but to not avail and as it stands now we cannot longer afford our children's trophies. We collected most of this money from financial institution and we use our houses as mortgage. Now the banks are now collecting our houses back. We have pleaded, we have gone to Abuja, we have gone everywhere but to no avail. Also the Director of Board of Trusty of the Association Victor Fakar noted that if the commission had in mind to clear the debt that have done so at his but that the NDDC was not committed to paying the debts. Knowing thing about it all is some hoodlums, paid hoodlums came to come and like scatter the point where we are and it's not acceptable but we'll see continue this protest. I did a contract in Abuja State and as I speak to you NDDC have taken glory for that. NDDC went on a channel television show the particular project I did and they've taken glory for that but up till now the contractors have not been paid over going to five years now. The loss have been happening and people have been suffering. We are begging aqua. We have met him separately exhausted all means to see that the dialogue with the contractors to pay them but it's not available. Please we are begging aqua. You know that when there is no peace in the society the women they are the peacemaker and we are here to make peace. And the only thing we are asking the NDDC aqua and the Honorable Minister for Niger Data Fair to pay our contractor to pay the contractors. They have worked just like 11 of them they have worked. You can see women these women most of them are their husbands and they are crying at home. They called on President Mohammed Bahari an all-well mini Nigerians to intervene.


So hello everyone, my name is Nati, and I'm going to talk about the paper secret sharing schemes for general and uniform access structures, a joint work with Benny Eppelbaum, Amos Beymel, Oriol Faras, and Oded Neu. So I will start this talk by telling you about what we do in this work. So in our paper we construct new improved secret sharing schemes for the two types of access structures. The first is secret sharing schemes for any access structure, and the second is the secret sharing schemes for specific family of access structure that are called uniform access structures. I will define you later in this talk what are uniform access structures. So secret sharing schemes were defined by Shamir and Blakely for the threshold case, and later by Ito Saito and Nishizeki for the general case. So we have a set of N parties, P1 to PN, and an access structure gamma, which is a family of subset of parties that contains the authorized set, which I will explain in a minute. For example, one of the best known access structures is the threshold access structure that contains all subsets of parties of size at least K. So the dealer holds the secret S, and it creates random shares S1 to SN, according to the secret and the random schemes, and privately communicates each SY to the party PI. So in the secret sharing scheme we want that set of parties will learn the secret if and only if it is in the access structure gamma. So more precisely, the correctness requirement of a secret sharing scheme is that any set of the access structure is an authorized set that can reconstruct the secret S from the shells by applying some reconstruction function, and the security requirement is that any set that is not in the access structure gamma is an authorized set that should not learn any information about the secret. So I will show you a simple example of secret sharing schemes. Consider the following set of two parties, P1 and P2, and the one-bit secret S, and the access structure will be the set of both parties P1 and P2, which means that parties P1 and P2 should learn the secret, and the party P1 by itself or party P2 by itself should not learn any information about the secret. So in a secret sharing scheme for this access structure, the dealer choose a random-bit R, give it to party P1, and it gives to party P2 the bit R XOR S. So it is very easy to see that both parties P1 and P2 can reconstruct the secret S by XOR in their shells, and each one of parties P1 and P2 cannot learn any information about the secret since it's all the random bits. So in our work, we consider linear secret sharing schemes. So I will define you linear schemes. So generally, we say that the secret sharing scheme is linear if the shares that the dealer gives to the parties are generated by a linear function. So more formally, the secret is an element for a finite field. And to create the share, the dealer choose random elements from the finite field, and each share will be a vector over the field in which each coordinate is a linear combination of the secret and the random elements. For example, the previous scheme we saw in the previous slide is a linear scheme. In this scheme, party P1 gets a bit R, and party P2 gets the bit R XOR S. So this scheme is linear over the field F2. So we have some good reasons to study secret sharing scheme. The original application of secret sharing scheme is to store sensitive information and to protect data that should be restricted from some parties. And now the secret sharing scheme are using many cryptographic protocol, such as multi-party computation and attributes-based encryption, and many more. So now I will tell you about some of the known results for secret sharing schemes. So we measure the efficiency of secret sharing schemes by the size of the shares. So for this, we define the share size of secret sharing scheme as the size of the largest share. So the upper bounds for secret sharing scheme for realizing any X structure. First, Ito Saito and Nishizaki showed the linear scheme realizing any X structure with share size of O of 2 to the power of N. More than 30 years later, this was improved by Liu and Vaikun Tanatan. They showed a non-linear scheme realizing any X structures, X structure with share size O of 2 to the power of 0.994N. And they also showed a linear scheme realizing any X structure in which the share size is O of 2 to the power of 0.999N. So let's see what we know about the lower bounds on the share size. So, SIRMAS show the existence of an X structure that requires share size of omega of N over log N in any secret sharing scheme that realizing it. And by counting argument, it can be shown that there exists an X structure that requires share size of omega of 2 to the power of N over 2 in any linear secret sharing scheme that realizing it. So as you can see, for general non-linear secret sharing scheme, there is a huge gap between the best known lower and upper bounds. And for linear scheme, we know much better. So the next slide that we tell you about our main results, which is a secret sharing scheme realizing any X structure. So for any X structure gamma over a set of N parties, we show a non-linear secret sharing scheme realizing gamma with share size of O of 2 to the power of 0.892N. We also show a linear scheme realizing gamma with share size of O of 2 to the power of 0.942N. So to construct this scheme, the following schemes, we show a general technique that enable us to construct a better secret sharing scheme realizing any X structure. So next I will tell you about some of the ideas of our schemes. So you and Vankun Tanatan show that for a parameter delta, we can decompose any X structure gamma to free X structures. The first is gamma top that contains the large sets of size at least half plus delta N. The second is gamma bot that contains the small sets of size at most half minus delta N. And the first is the X structure gamma mid that contains the medium size sets of the size between the above two values. So you and Vankun Tanatan show that any X structure gamma equals gamma top intersection gamma mid union gamma bot. So to construct secret sharing scheme for gamma, it is sufficient to construct secret sharing scheme for gamma top, gamma bot, and gamma mid. This follows for non-closure properties of secret sharing schemes. So in our work, we construct improve secret sharing schemes realizing the X structure gamma top and gamma bot. And this scheme uses combinatorial covers. So now we go over the ideas of the construction. We start with a secret sharing scheme realizing gamma with share size of O of 2 to the power of 0.994 N, the scheme of you and Vankun Tanatan. We choose set B of side 0.99 N. When the value 0.99 is arbitrary just for the explanation, it can be replaced by any value between half and one. And we consider the X structure gamma B that contains all subsets of parties from the X structure gamma bot that are contained in the set B. So by the result of you and Vankun Tanatan, there is a scheme realizing the X structure gamma B with share size of O of 2 to the power of 0.984 N. In the next step, we define a cover of the X structure gamma bot as a family of sets B1 to BL of size 0.99 N, such that every X structure of gamma bot is contained in at least one of the X structure, in at least one of the sets B1 to BL. So we can decompose the X structure gamma bot as a union of X structure gamma B1 to gamma BL. And by the non-closure properties, we can realize independently each of the X structure gamma B1 to gamma BL and get a secret sharing scheme for gamma bot with share size of O of 2 to the power of 0.993 N. So for the X structure gamma top, we show a similar secret sharing scheme with the same share size. And using the secret sharing scheme of you and Vankun Tanatan for the X structure gamma mid, we get a secret sharing scheme realizing gamma in which the share size is O of 2 to the power of 0.993 N. So we already get a better scheme than the scheme of you and Vankun Tanatan. So in the next step, we can do the same, but starting with the X structure with the new share size and get an improved share size for the X structure gamma bot in which the share size is O of 2 to the power of 0.992 N. So to get our desired scheme, we choose the optimal parameter and use this construction a constant number of time recursively and we get the scheme with the desired share size. So we also analyzed the way we choose the optimal parameter to get the optimal share size. In this figure, you can see the optimal choice of the parameter. And overall, we get our scheme with share size of O of 2 to the power of 0.892 N and linear scheme with share size O of 2 to the power of 0.942 N. So our analysis can be applied to any secret sharing scheme for the X structure gamma mid, which means that any improvement in the X structure gamma mid will lead to an improved secret sharing scheme for any X structure gamma using our scheme for gamma top and gamma bot. So next, I will talk about secret sharing schemes for uniform X structure, uniform X structure were first defined by insane and she and later by Beymel Kushilevich and Nissem and Applebaum and Arches. So uniform X structure is defined by a parameter K between 1 to N and we call such an X structure K uniform X structure. In K uniform X structure, any set of size greater than K is authorized and can learn the secret also some of the sets of size exactly K are authorized and also can learn the secret and any sets of size smaller than K is unauthorized. So K uniform X structure is specified by the set of size exactly K. In other words, K uniform X structure contains all the sets of size greater than K and some of the sets of size exactly K. For example, we can consider the next X structure gamma which contains the sets P1, P2, P3, P2, P4 and P7 and additionally all the sets of size at least 4. So we can see that this X structure is free uniform X structure. So we have some good motivation of studying secret sharing schemes for uniform X structures. So the first reason is that it is an interesting family of X structure. It looks very simple family of X structure and also is more efficient scheme than the best know secret sharing scheme for general X structures. Uniform X structures can also serve as a test ground for studying secret sharing scheme for any X structures. By recent work, we know that such X structures can be used to construct secret sharing schemes for general X structures. And finally, it equivalents equivalent to conditional disclosure of secret's protocol or shortly CDS protocol which is a cryptographic primitive that enables a set of parties to disclose a secret to a referee, undersecretary to a referee under some conditions. So now we'll tell you about our main results dealing with secret sharing schemes for uniform X structures. So in this work, we construct three secret sharing schemes for K uniform X structures. The first scheme is a secret sharing scheme for long secrets of size T and the shell size of this scheme is O of K squared times the size of the secret T. In this case, T equals to at least omega of 2 to the power of n to the power of K squared. The previous best known schemes for such a secret as shell size of O of e to the power of K times the size of the secret T. The second scheme we show for uniform X structure is a secret sharing scheme for secrets of 1 bit and this scheme has shell size of 2 to the power of O of square root of K log n. The previous best known scheme for such a secret has a shell size of 2 to the power of O of square root of n. Our third scheme for uniform X structure is a linear scheme for 1 bit secret and the shell size of this scheme is O of 2 to the power of H of K over n times n over 2. So in this case, the function H is the binary entropy function and the previous best known scheme that is linear has shell size of O of 2 to the power of n over 2. So for this scheme, we also show a matching lower bound of omega of 2 to the power of H of K over n times n over 2 and this lower bound shows that our scheme, that our linear scheme is optimal up to a very small polynomial factor. So to construct all the above three schemes, we use implicitly or explicitly in a transformation for a multi-partite CDS protocol to uniform X structure. So to conclude this talk, in this work, we study secret sharing schemes for general X structures and uniform X structures. We show an improved secret sharing scheme realizing an X structure and new secret sharing schemes that realize uniform X structures. The open problems that arise from our work is first try to show an optimal linear secret sharing scheme realizing any X structure. And another question is closing the huge gap on the shell size for nonlinear scheme. So there are already some results that uses our work. The first one is a linear secret sharing scheme realizing any X structure in which the shell size is O of 2 to the power of 0.762n and there is a nonlinear secret sharing scheme realizing any X structure in which the shell size is O of 2 to the power of 0.64n. And both of these schemes uses our construction for the X structure gamma top and gamma bottom. So that's it. Thank you. We have time for one or two questions. Yes? So when you say you construct a cover of gamma bottom with sets B1 to BL, so what kind of sets are those and what exactly is the number L and what is exactly their purpose? The number L we show a probabilistic proof about the number L. It depends on the size of the sets in the cover. So this decomposition is meant to reduce allow you to combine secret sharing schemes for less general access structures so I don't understand the goal of this cover set. About the composition of the gamma bottom? Yes. So there is a non-closure properties that show that if you have secret sharing schemes for a few access structures there is a secret sharing scheme with the same shell size for the union or the intersection of those access structures. For key uniform access structures, does it matter? Should it matter for efficiency the size of the specification? So I don't know if you said you can specify your access structure with the number of sets. So does that matter? In uniform access structure the access structure is defined by the parameter k. Yes, it's the parameter k. So the shell size will depend on this parameter. Yes, but it will also depend on the because the specification is on the because you said it's not all sets on k but it's a few sets. It contains some of sets of size k and all sets of size bigger than k. So it doesn't matter which sets of size k do you have in this access structure. So you can realize it with the desired shell size. Thank you. Any more questions? If not, then let's thank the speaker again.


My father used to sleep with a knife in a gun by his bed because he said the devil was coming to get him that night. Go ahead. He said the devil was coming to get him that night. You know what I mean? Like there was always- So no taser as well? I go gun, knife and taser. He snuck a taser in the MetLife Stadium. Yeah, well he didn't sneak it in. He's from South Carolina, so he's used to having it on him. That's why my dad always said, keep something on you. So he literally just walked into MetLife Stadium on 9-11. I think this was like 2011, 2012. He walked in during the Cowboys' Jets game and got into a fight with a Marine on 9-11 and ended up tasing him. True story, Google it.