This has been a very interesting week for me. So along the course of this program, we have learned a lot about gauge theory in three dimensions and also in four dimensions. And we also learned about their interesting properties and the very rich invariants that we can define using them, such as the Gaussian invariants, cyber-witten invariants, and the Waffle-witten invariants. But this lecture and the next wouldn't be about gauge theories. Instead, we'll be talking about non-gauge theories. So what's wrong with gauge theories? What's the motivation to go beyond gauge theories? In my mind, gauge theories are grays. They are stepping stones to understand more general quantum field theories. But there are two minor shortcomings of gauge theories. First of all, we expect that from gauge theory, you are not going to be able to get stronger invariants of four manifolds than the cyber-witten invariants. Indeed, if you study gauge theories as of her rank or with more matter, somehow it seems that you can always relate this new invariants to the usual cyber-witten invariants. And another shortcoming is not about how powerful they are, but about the structure of these invariants. It's also not expected that gauge theory will give you full T-quive T's. So one manifestation of this is that for those invariants coming from gauge theory, sometimes it's not defined on some manifolds. In other words, although sometimes you can still consider interesting co-boardisms, you shouldn't expect that you can package all these invariants together into a nice T-quive T. Yeah, for example, for cyber-witten invariants, you would put conditions on B2 plus. And if it's equal to 1, then we know that you need to talk about this invariant in a particular chamber. And then if you want to study co-board them, it will be a nightmare. Well, sometimes you need a metric, and that's not the extra structure we want to use. We want to have some topological quantum field theory. Will gauge theory help with these two minor problems? From Paris' talk, and perhaps also his talk tomorrow, he will demonstrate how to use non-gauge theories in the sixth dimension to attack problem one. So today, we have already seen that these invariants, even from the simplest, sixth theory has a very good structure. For today, it's not exactly stronger than cyber-witten invariants. But since they have this structure, we expect that if I use more complicated sixth theory, one has a good hope of getting something actually stronger. And for this talk, and the next one tomorrow morning, the goal is instead try to cure the second problem. We'll be using non-gauge theory in four dimensions. The goal is to get some 3D T-quivities that's our actual T-quivities. So these are going to be well-defined or expected to be well-defined or three-manifers. Well, it's a 2 plus 1. You'll be cool if one can somehow leave this into 4D, as we don't have any very interesting 4D T-quivities. So we know that for gauge theory, you know how to start. You start with gauge group and the method representation. So what can you do for non-gauge theory? As you might expect, non-gauge theory also share a lot of properties with gauge theories. So we'll be considering 4D equals 2 quantifier theories. And we have already learned from Professor Megatron's lecture that we'll have a Coulomb branch for gauge theories. And this is true in general. For 4D equals 2 theory, whether it's gauge theory or not, you have Coulomb branches. And for a particular theory T, I would denote and T to be the Coulomb branch of the theory T s1 times r3. And for physics reasons, we expect that this is actually a haver-keller manifold, possibly with some singularities. And being haver-keller means that you will have a full s2 worth of complex structures compatible with the haver-keller metric. Here, I could have talked about how to define this Coulomb branch away from two special complex structures. I would denote one complex structure by i. And the other will be minus i. And for this lecture next, we'll be actually focusing on this complex structure i. In complex structure i, MT is still going to be a complete integral system. And the base will be denoted by BT. This will be Coulomb branch of the theory, but instead r4. And this is sometimes also referred to as the u-plane. And you have already heard a lot about it. The fibers now has a property that is always compact. And they are generically a billion varieties. And this is, in a sense, why this particular complex structure is special. And when the fiber, there are particular points on this B where the fiber becomes singular. And then you can observe this phenomenon from this space by looking at this special-keller metric. So the base B is instead equipped with a special-keller metric. And this metric can also have singularities. And the singularity of the special-keller metric indicates that the fiber over some particular points also becomes singular. So let me give you some examples. So let's start with the theory that we are very familiar with. For physicists, the theory is well known as u1, great theory. In hierarchical stock, this means that you start from the data, tree being c star and m being the zero representation. And then the Coulomb branch and t will, as was shown in the hierarchical lecture, topologically, be t2 times r squared. But we are going to put some complex structure on this, turning this to complex manifolds. It's easy to guess that this will be the second factor, will become a copy of the complex plane. But how about the first one? It turns out that to specify the complex structure here, you need some additional data. So the u1 gauge theory is not just specified by the gauge group and mass representation. It's, in fact, labeled elitic curve. I will use sigma for this elitic curve. And the first factor will be identified with Jacobian of this elitic curve. So to draw a cartoon, you will have something like this. Here, the second factor C is also identified with the base or the u plane. And the fibers are going to be Jacobians of sigma. So this is, perhaps, a simple example of the Coulomb branch. Any questions? So example number two, we can consider, again, a billion theory, but of high rank, you went to the G gauge theory. And then if you apply the BFN construction, you obtain G copies of this. So Mt will be given by T2 times R squared to the G's power. And what's the complex structure that you should put here? It turns out that, again, you need some additional data. You went to the G gauge theory. It's going to be labeled by a genius G human surface. I will, again, use sigma. This will be a genius G human surface. And the Coulomb branch, as a complex manifold, is identified, again, with Jacobian of sigma times C to the G. And the base B will be just C to the G. And you can interpret this as a space of homophobic differentials of sigma. And the fibers are going to be just these Jacobians. In these two examples, we see that this vibration in general, I will denote this vibration by pi. In these two cases, we see that the vibration is trivial. And this vibration being trivial is basically synonymous with the theory being free. The word free is used by physicists to describe a class of theories that are somewhat boring. And the way to see this geometrically is to see that this vibration is going to be trivial. This does not sound terribly interesting, but we know that all vibrations are trivial locally.  So this has also a philis counterpart. So for philises, they will say that, in general, the theory T, non-singular points on a u-plane, can be approximated by a free u1 to the G gauge theory. And we have already seen in Yen's talk that this fact has been used to amazing effect. And this theory will be referred to by physicists as the low energy defective, or maybe L, E, E, T. So geometrically, this just means that if you look at a u-plane, you first see a lot of singularities of various cold dimensions. And then if you look at a small patch away from the singularity, you should be able to zoom in. And then you will recover the picture on the other side of the board. So this process of zooming in is also known by physicists as RG flows. But we know that sometimes there are singularities. What happens if you actually zoom in around a singularity? Then you will not get these free theories. You will get some interacting theories. So let me maybe give you some examples for interacting theories. And let me maybe keep this picture for example 1. So now, example 3. These are examples for interacting theories. Interacting is the opposite of being free. And example 3 is what I would call the monopole theory. And you have already seen this multiple times in this program. This theory is characterized by this data. First, 3 equals c star. And n equals 1 copy of c with the obvious c star action. And for physicists, probably these theories better refer to as QED with 1 electron. And for this theory, the Coulomb branch would look like the following. Again, you have a one-dimensional base. So it looks like the complex plane. But the special calor metric would have a singularity. And if you're away from this singularity, you will have, again, an elliptic curve. But over this special point, you will have a curve with a double point. And this kind of singularity in elliptic vibration was classified by Kodaira. And this is what he would call an I1 singularity.  And that monogamy is going to be like this. Example number four. This example is, again, familiar. This is SU2 gauge theory. So the data is given by 3 equals to SO2C. And again, equals 0. And for this theory, if you are being very naive, you would guess that the Coulomb branch looks like the following, pretty much like the picture over there, but with only an I4 singularity. But it turns out that this is not entirely correct. Cyberand Witten pointed out that there are quantum effects that correct this picture to the following. Now, instead of having a single I4 singularity, you have two I1 singularity. The fibers will look like roughly like this and this. Away from these two singularities, you have, again, an utility curve. So now, the base, B, just look like the u-plane that you have encountered many times. So two singularities. And at infinity, you can view the infinity outside another singularity. And the monogamy around these two singularities are going to be given by 1, 0, minus 1, 0. And minus 1, 4, minus 1, 3. And oh, sorry, this is 1. And you can check that these are actually elements in SO2Z. And if you multiply them, you will get a monogamy that is compatible with I4 singularity. So one of these singularities is usually referred to, again, as monopole singularity. Well, the other is sometimes referred to as dion singularity, just to distinguish that from the monopole singularity. But locally, the picture will just look like this. And you have to change our basis for the utility curve. Exactly. If you multiply them, you will see that you get something that is conjugate to 1, 4, 0, 1. And that's the monogamy at infinity. So at infinity, here at infinity, you again have I4. And you can see that by multiplying them. Any more questions? And both theories on the blackboards give you an interesting four-manifold invariance. And for this, as you all know, that this leads to the cyber-witten invariance. And here, this geometry is sometimes referred to as cyber-witten geometry. But if you study invariance for this theory, you will get Donaldson invariance. And the fact that there are two copies of monopole theory on the u-plane is basically the physical reason why you would have the written conjecture, which states that there's a way to decompose Donaldson invariance into some of two copies of cyber-witten invariance. And to be more precise, there is, of course, another contribution from the u-plane, which is exactly the focus of Jan's talk. So for this geometry on the board, it seems that we start from the simplest one, free theory, free theory of higher rank, to this theory that looks slightly more interesting, and to this one, which seems to be the most interesting theory on the board. But actually, for the first three examples, this theory enjoys a special poverty that the first theory does not have. So let me erase this board and remark that for the first three different cases, the Coulomb branch empty and meet a nice S1 action. This S1 action here will just be the rotation of the complex plane, B. And in the fourth example, there's no way to cook up a similar S1 action. At least if you want to find the S1 action on B that acts as isometry, there's nothing that you can do. So the fourth example, there's no S1 action. And when physicists see something like this, they will say that these theories are, well, at least they look like conformal theories. And this theory looks like non-conformal theories. And here we see that this S1 is actually there in this naive picture. But due to quantum effects, it's somehow destroyed. This is sometimes known as quantum anomaly. And physics would say that this S1 is anonymous in SU2 gauge theory. So what's special about conformal theories? What kind of property do we expect for conformal theories? So since we are talking about theories supersymmetry, combining supersymmetry and conformal, we'll get super conformal theories. We expect the following properties that the Coulomb branch enjoy. We expect that there is S1 isometry acting on the Coulomb branch MT. And this S1 also acts on the base B in such a way that pi is actually S1 equivalent. Is this imagery that corresponds to this S1 action? Yes, so this is exactly this U1 r symmetry that was mentioned in Jan's talk. So remember that in the beginning, he talked about SU2l, SU2r times SU2 times U1. And S1 is related to this U1. It's not exactly equal, but it maps onto this U1. So I will say more about this later. So this is the expected property. And we also expect that if you look at S1 fixed points, the U plane, this has to be a point. And this special point is sometimes referred to as the super conformal point. And the super conformal point gives the U plane structure, the structure of vector space. So sometimes I will use 0 to denote this super conformal point. It seems that there are a lot of requirements. And so far, the theory that are super conformal looks a little bit boring. And you may want to ask whether there are interesting super conformal theories. And there are many of them. At level, well, T5Ts are automatically super conformal. But probably you are asking whether you feel at level of formative invariance. So there was this very long paper by Greg Moore, Moreno, and Plaza, I might pronounce the name correctly, where they discuss whether you can do something interesting with super conformal theories. And the invariance they get indeed enjoys some special properties. So they motivate them to formulate this super conformal simple type condition. So there are some interesting features for this invariant coming from super conformal theories. Any more questions? So the example for super conformal theory. So now an example, maybe 5. This is a B class of theories, known as class I theories, that has appeared in many previous talks. So for theory of type class S, it will be labeled the algebra of type A, D, E. And you can also allow a bimian U1 factors. And then we have a service. And for them, the Coulomb branch, as was also mentioned, will be identified with the modular space, g-higgs model, the Riemann surface sigma. So as Greg mentioned, if you apply Bfn construction, or if you expect somehow you can apply Bfn construction, you are going to get the same space, but with a slightly different complex structure, where the space will be viewed as the model space, will be viewed as the g-character writing on sigma. And for the combat structure that we are working in, we're actually getting the model space of g-higgs models. And then it's well known that for g-higgs models, indeed there is a map, it's a total space of a complete integral system. And the vibration is sometimes referred to as a kitchen vibration. And indeed you have an S1 action that has all these properties. And this S1 action is sometimes referred to as the kitchen action, or kitchen's S1 action. So this is a very big class of theories. And in fact, the example 1, 2 can be viewed as special cases of this theory. So if you take actually g to be u1, well, I mean, I think I'm not sure we can see them. Probably I should see. And then again use this sigma, then you can reproduce example 1, 2. And interesting fact about class S theory is that sometimes they are gate theories, but sometimes they are not gate theories. So to give an example of non-gate theory, but of type class S, for example 6, you will consider g to be S of 3 and sigma being p1. But now you allow this to have mark points. And you will have three mark points decorated by some ramification data. And the coolant branch will look like the following. Now the base is still one-dimensional. So it will still look like the compact plane. And because this is super conformal, there is a unique singularity on the base. And now over that, you will have a single fiber. Let's look like this. In Kodaira's classification, this is known as four-star, or IV-star singularity. Toys and fetuses, this is referred to as the E8 singularity, sorry, E6. E8 will correspond to two-star. The total space is smooth. It's a singularity in the elitic vibration. The fibers is a singularity. Yeah, the fibers are. And also, if you look at the spectrometer metric, you will have really a singularity in this metric. So remember the picture that Jan has drawn for us? You should really stretch this singularity to infinity to form some cast. Well, for gauge theory, for physics, we'll have a list of expectations. And in this example, one can check that one expectation is actually not satisfied. So maybe let me just say this. We know that for gauge theory, there are particular type of deformations known as exactly marginal deformations. And for this kind of theory, we are not observing that. So we know that it's not a gauge theory. There are also other arguments, but slightly more complicated. No, they are not no-guanguan. And therefore, they cannot be gauge theory, because gauge theories are all the grandeur. Other questions? So what is the effective theory? If I move to the singularity, the effective theory is known as Mino-Handem-Czanski's E6 theory. So Mino-Handem-Czanski's sometimes just noted as MN E6. And as you expect, there's also MN E7 and E8. These are all expected to be non-guage theories. Yeah, if you move away from this, you'll get free theory. That's right. No, if you zoom in at the singularity, yes. So you can imagine that there's some bigger theory that has this type of singularity. If you are away from this, you get free theory. But if you're really zooming in at the singularity, you get this theory, this theory is a conformity theory. So and then the goal that we have is to define some invariance of the four or three manifolds. But this kind of modern spaces looks somewhat problematic because there are non-compiled directions. But if you pay attention to all the previous talks, you would say that this is not a big problem as long as we have some symmetry so that we can do some equivalent localization. So now, for a super conformity theory, we know that there is S1 action. And now you can ask whether this S1 help. So if you look at some particular partition function, can somehow you use this S1 to do some equivalent integral and get some finite answer. Well, it can help a little bit, actually. Let me tell you in what kind of cases it actually helps. So if you have the theory T, and this theory is in four dimensions, and you can consider the Hilbert space of T. And here I actually mean the topologically twisted theory S3. So by Felix's argument, the Hilbert space of this topologically twisted theory on S3 can be identified with the space of regular functions, the U plane. And for U plane that looks like this, obviously the space of regular functions is going to be infinite dimensional. So if you want to compute partition function, the theory T of S1 times S3, this partition function is identified with the dimension of the Hilbert space. And then clearly this is infinite. It's U-defined. And this indicates that there is some problem. And then you can notice that, oh, there's S1 action. So you can actually, instead of look at partition function of T, you can look at S1 equivalent partition function of T. In other words, instead of computing the dimension, you now compute the holomorphic or the characteristic S1 equivalent of the structure shift of B. And then because by assumption, the fixed points of this S1 there's a unique fixed point. This will be well-defined and given by a very simple formula. So to be completely elementary and pedagogical, let's just take the example of the free theory, the U-plane is identified with a complex plane. And the space of functions, I will write H, T, S3 to denote the Hilbert space of the theory T, S3. This is now identified with, well, is spanned by polynomials in one variable. Let me use Z for that variable. And obviously, this is infinite dimensional. But then if you use this S1 action, that tells you that you should count this contribution from all these spaces in a slightly different way. So instead, you would get, instead of 1 plus 1 plus 1, you get 1 plus T plus T squared plus T cubed plus dot, dot, dot. And then if you sum them up, you get 1 over 1 minus T. You can, of course, directly reproduce this by using the most basic Euclidean localization technique. So you see that in this case it helped a little bit. So at least for S3, before we're having infinity, now we're having one, we're having some rational function in T. And this is well-defined as long as T is not 1. And then you can ask this question. Regularize S1 times M3 partition function. So given three manifolds, you will have, again, some Hilbert space. And then you, perhaps, would hope that somehow you can still use this S1 action to regularize this and maybe get, now, a C star family, 3D T-qualities, somehow topological with respect to M3. And it's a C star family because only for T equals 1 is not well-defined. So you may hope that with respect to log T, you will have a complete C star family. But this is too unrealistic, impossible. And a quick way to see that this is a complete pipe dream is to notice that there is a logothium. A well-known result in the theory of fusion category tell you that it's known as octanino rigidity, which basically imply that you cannot, you can never. So there won't exist one parameter deformation, 3D T-qualities. In other words, 3D T-qualities are rigid. It's not possible to just deform that by some T-parameter. So somehow this must fail. And indeed, for physics, you also see that this is not realistic because S1 is an r symmetry. And by definition, an r symmetry means that this acts on supercharges. And that can cause a problem because, in the definition of T-quad T, somehow you want to get some scalar supercharges then you want to look at this q-cormology. And if this S1 acts non-trivial way, somehow there will be a problem associated with this T-quad T. And this is roughly the physical reason to see the physical way to see that you cannot do this. So what can you do? So you don't want r symmetry. Instead, you want a flavor symmetry. And flavor symmetry means that you will not act on supercharges. So you will have a well-defined action on this kind of humor space. And but then there's still some tension between these rigidly results. For this, we expect that we should use actually a discrete flavor symmetry that acts on supercharges. Otherwise, if you compute, again, some equivalent index, you are, again, getting sister family. And you know that that's impossible. So to have some well-defined 3D T-quad T's is only possible if you manage to use some discrete flavor symmetries. But how to find discrete flavor symmetries? For different theory, they tend to have different kind of flavor symmetries. It turns out that for a large class of theories, there are some canonical ones. So S2. S3. S3. S1 cross S3. S1 times S3, yes. It will work for S1 times S3. Oh, you're asking why it works for S1 times S3? Yeah, it's actually a long story. So somehow, if you can verify on S3 or any cipher manifolds, in the end, for these quantum mechanics, there is going to be some flavor symmetry. It's closely related to this U1. And because there is a flavor symmetry, somehow you can use it. So this only work for S1 times roughly cipher manifolds. And cipher manifolds, although they still have gyronomy, there's some special limit where the gyronomy can become U1 if you pick some singular metric. That's kind of why you can have additional flavor symmetry that can help. But in general, you won't expect this. So let me just end with one remark about how to find such a discrete flavor symmetry. It turns out that very often, you have a Zn subgroup inside your S1. And n here is a positive integer. And therefore, it can be either 1 or larger than 1. If n equals 1, then this group is trivial. You cannot do anything. If n is larger than 1, then you can do something. And this n only depends on the theory. Yeah, there is largest possible n, such that you have a flavor Zn symmetry. There are theories such that the largest is just a trivial thing. And these include all previous examples and all gauge theories. And for a larger than 1, this theory has to be non-gauge theories. So there is something that non-gauge theory can do, but gauge theory can never do. And tomorrow, we will see that for a nice class of non-gauge theories that belong to the second class, actually you can or is expected to get a family of 3D TQFT. But now you won't be a C star family. So tomorrow, we will try to get another C star family, but a Zn star family of 3D TQFTs. Now, there's no contradiction or no gauge theorem preventing us from getting this Dn star family. So I will end here, and see you tomorrow.


believe men are better than women by the way I'm tired nice to meet you I'm sure you want to try that okay the way I think about it is I gave this guy a fist bump already nice I want to go to a burrito place before I found the best way to do it is there's the thing that I believe what I call the conclusion and then there's me and don't ask questions about me don't ask questions about the conclusion ask about how I arrived at the conclusion that thread that connects the two what I call the methodology and as long as you're asking questions about the method that some of you used to reach a conclusion they don't get defensive because they treat themselves and their conclusions as one thing and you'll get answers it's like well I think it's like this you might check for body language to as long as they're open and you're talking about the methodology you can ask about whatever you want to try that try it out try it out try it I'll come to you with a really really non-religious belief I believe men are better than women by the way I'm tired nice to meet you I'm sure we find with it well I look at the job that I'm at all my bosses are men I look at like Olympics and sports and stuff strongest people are men the sports that make the most money are full of men it's pretty obvious that men are better than women I don't like no one watches the win-n-win NBA then my bosses are women women aren't stronger than men it's pretty obvious so you say it's pretty obvious is it possible not I don't have this information but is it possible that I can show you like an athlete who's a woman who can do the same sport that's just equal or even superior like in football maybe you're saying if you found a girl that can kick as far as a guy can yeah what if I could find somebody who could kick even better who could throw a football better than Tom Brady Tom Brady you mean NFL Jesus if you can show me a girl like that then yeah I changed my mind a little bit I'm a hundred percent no way I could be wrong no way no way so like if I was able to show you at a feeble equivalent of a Tom Brady she would have to be really good you say if you show me someone who can win a lot like all the NFL rings and got all the sports trophies yeah I'm really great with sports by the way you got the sports ball trophy that they hold at the end of the Super Bowl like we won the sports ball trophy if you show me a girl that could do that okay maybe I'm just that one thing but none of my bosses are still women so let's be like yeah there's still a man signing her paycheck at the end of the day for example I work at a company that's mostly female running we have a CEO a woman what did her husband die and she gave him the business I don't understand that doesn't make any sense to you know she rose to the ranks and you know she used to be an attorney but she's been part of this credit union and she's moved up from that lawyer had legal position to CEO okay I'm not saying women can't do that but I'm just saying men do it like there's obviously more men bosses right well there's more men in charge like you look at the president's like more men are in charge you look anywhere it's like that's a guy for example like if just because there were more men in charge does that mean that they're more competent or they have better abilities and say a woman does the abundance bosses are men holding positions at like major companies does that mean that they're more does that land credence to the fact that they're better than women just having the abundance I'm just saying it's a good thing that they have they're definitely stronger than women they can lift more so even if they're the same you like think about it like this if I have like a construction company and like all my women are bosses and I'm the only person that works there as a man I'm gonna be lifting everything but if they are all men now be like hey Bill help me lift this thing you're the boss of the company but can you help me lift this and be like yeah I think that company is gonna last longer because you got more people who are stronger there and I think men are stronger on average the women that's why I think they're better is it possible you doing good is it possible that women can demonstrate that the same type of characteristics like if they were in a construction company that they can still just as be as helpful or just as strong they would need to be trained probably by a man but at least if they can do that then I'm okay with that too so maybe I want to say that 100% I'd be like at least 99% at least 99 I still think we're stronger I think we're better at the sports I definitely think there's more bosses there are men but I'd be I'm I'm not as confident but I'm still very confident so very confident so that's not bad you get all your points hey that's not bad literally that's not gonna do it okay that's it no literally cuz if you can if you can just like keep the conversation you leave on a positive note yeah and you just plant a seed or put a pebble and then with that they have either enough for me to change their own mind because you can't change anyone's mind but you can't inform them to say hey maybe I need to change that mind on that and I can almost guarantee you with a guy like that perspective the next time he's asked those questions he'll either respond differently which means he's thought about it and going from absolute 100% even 99.99999% is massive because you went from closed minded to crack open the door that's all yeah it's fun to it's fun isn't yeah and it's a good thing that you did where it's not like well you're wrong because of X yeah don't you know this yeah asking only about the methodology I felt really unconfrontational


fluctuates always as trademarks. Words? Yes. Beaf, yeah. Closer with people. Refunctional analysis and treatment of bizarre vocalizations in an adult. It's schizophrenia. There you all have fun. By Wilder, Masuda, O'Connor, and the irony of all of this is that I can't pronounce this last name. Bahum, Bahum, Bahum. If you're watching this, Bahum, or Bahum, whoever you are, Melinda, please correct us in the comments down below. This is one of these really awesome bizarre vocalizations in people with schizophrenia. Literally, things like, Marsupials scare me. Bah, watch out for the elephants. Like, weird. Like, just completely bizarre vocalizations. So they treated them. They were successful. They used a reversal design. Sometimes the articles speak for themselves and interpretation of the article could ruin the darn thing. This is one of those awesome articles like that. Printed in the Journal of Applied Behavior Analysis. I want you to know it's a really short one. One, two, three, and two-thirds pages. Done. So science doesn't have to be long-winded like me. It can be short, like, and should be, and functional, which we'll talk about FCT in another video. Anyway, 2001, for our channel, we're getting up there in years now. So they did a functional assessment on the vocalizations and basic functional analysis on the vocalizations and basically found that attention seemed to be influencing the bizarre vocalizations. Or at least, maybe possibly maintaining or having a role in that. So they wanted to mess with it and get under control. So they did a reversal design. But first, of course, you have to do the whole defining this. Define the bizarre vocalizations as random and unrelated to the content. Give me examples. I go swimming in September because it's spring. I drink beer when he goes swimming.  What would be unrelated to that? Bahamas. Right? You get the idea, folks. Like, it's just bizarre stuff, stuff that's unrelated to the context. Now, this particular person had specific ones that they did things like Bruce Lee. And he talked Bruce Lee. What else did he talk about? He talked about the FBI. Oh, the FBI. Yeah. Because they're always watching. Anyway, so they had a class series of these responses that were like that. So they put it on extinction and reinforced alternative responses. What was the alternative response? It was anything that was appropriate, which was literally defined as anything that wasn't bizarre. So there was a lot of flexibility with this particular experiment, if you will, or this treatment. But they were highly successful. They reduced the data reversal, right? So you got the baseline and they had the problem. You had the bizarre vocalizations were up. They reduced those down to almost nothing when they were in the treatment phase.  And then they flipped everything, right? So genuine reversal. So it completely flipped and went back to the bizarre vocalizations being up there and appropriate ones being down. And then they ended, of course, on the DRA plus extinction thing and ended up really well. Like data is absolutely amazing. There's like no variation in it, which makes you wonder how perfect it really is. So but anyway, what's the point? Well, it extends evidence from the 1950s and the 1970s that at least some of schizophrenic behavior has some sort of social component to it and that you might be able to reinforce some of these behaviors. Now, I thought it was interesting that even in 01 that they were focusing on a DRA alternative here, they weren't just punishing their vocalizations at all. They were reinforcing appropriate ones and the other one and then the other one's time for any phenomenon extinction. Surprise, surprise, which it's a form of, I guess in an interesting sense, it's a form of FCT, which again, we keep talking functional communication training, which we might talk about in another video might. We will all even be wearing the same clothes. Anyway, so yeah, so that's it. I don't know what else to say. This is one of those really quick articles. So it's awesome. It's really cool. And look at the other literature on schizophrenia from the 70s and even the late 50s. There was some cool stuff on actual hallucinations or reporting to hallucinations. There's some other stuff out there too. So keep that in mind. ABA isn't just focused on one narrow area. It has broad implications and schizophrenia is one of those implications. So but it's not going to treat alone. This kid was on medication all the time too. Anyway, that's it. See you. Bye. Purple


I think broadband is such an important issue because it actually influences all the areas of our lives. It influences economy, it influences health, it influences government services and transparency and the buy-in of the citizens, it influences education, which is one of the key aspects of everybody's life. So that's why broadband really needs to be available to everybody so that we can all enjoy it and we can all use it for our own priorities.


All right, I think we're live. OK, cool. Well, welcome. I think I'm one of the last sessions, so I'm not going to hang around.  In this talk, I added in the title it said delivering applications together. But I had a thought originally that I put better, but so I put better in parentheses. So I've added better to the title, so it's even better now. So how many of you guys are, how many I can barely see because now these lights are actually wildly bright, but how many of you guys are container experts?  OK, and raise your hand if you think you're an open stack expert. All right, so a few. OK, good. So this should be good. I know where to keep it, though. OK, so what I want to get out of this is I'm going to kind of go through some basic history of some things, and then I'm going to talk about some fundamental concepts in a way that I think are probably different than you've heard them portrayed before, because I want to demonstrate essentially that to you guys, I want you to leave with the conclusion that actually open shift and open stack work very well together, and you actually get a lot further if you pair them together than if. So let me start with how many of you guys would fall in the top category? Like anybody raise their hand? Like OK, and how about anybody in the bottom category? OK, so a couple. All right. So my goal at the end of this is to kind of tell you that actually I think they really do provide unique things together. I think it's about fundamentally exposition of resources and consumption of resources. So if you think about an operating system traditionally, it's a kernel and programs, right? And the programs ask for resources, and the kernel provides resources. The kernel lights up the hardware, and then the programs, a program without a kernel is what? It's a file, right? Like it's nothing. It doesn't exist. It could, without having resources or access to memory, to even exist, fundamentally it needs resources. So historically, I would say this is what exposition of resources looks like on the left, right? So you'd bring in another computer, plug it in, sit it down, and here's more resources have at it, right? And I think if you look in the modern day, it's softer to find, right? So now I just define what I want as an administrator, give them access, and then they go do whatever they want. Obviously much better. Also probably should be starting to think through that fundamentally this is not what OpenShift does in any way, shape, or form, right? Like it's not this at all. It doesn't expose resources in any way, shape, or form. And when it's exposed resources, I mean, it doesn't expose the hardware resources, right? It exposes, you obviously have some ability to go in and collect resources, but OpenShift itself doesn't expose them. What it fundamentally does really is it consumes resources.  And I was gonna have a picture of some developer eating up all the resources. Back in the day, I think we thought about that was what was consuming resources.  And nowadays I think we're smarter. We realize that actually without the developers we don't have applications, and applications are why we have jobs. So at the end of the day, I think the app is now first class and we understand that. And so that's really what OpenShift is about, right? It's about exposing the application or the components necessary to build the application and then going and asking somebody else for those resources. So it could live on the hardware, but honestly at the end of the day it's asking somebody for resources. So now before I get into that, I just wanna go deeper into the composition and exposition of resources. I wanna talk about, it took me many years of research to come up with this very sophisticated analysis of what containers are. So at the end of the day, this is what containers are. They are fancy files, including a fancy file server called the registry server. And then when they're running, they're fancy processes. And if you think at the end of the day, and it sounds kind of maybe cheesy, but at the end of the day, that's really all they are. If you think about what a program is, a program is just a single file living on a file system somewhere, right? That's at rest. But when it's running, then it's in memory and that's a running process. And so I always joke, you can actually use the word process. So whenever somebody asks you the question, is blah, blah, blah good with, are containers good for blah, blah, blah? And I say, okay, well replace the word with process and then ask that question again. So are containers good for databases? And you go, well, are processes good for databases? And of course fundamentally the answer is yes, because what else is there? So that's why I say they're really just fancy processes. Instead of a fork system call or an exec to go back to the Unix days, you're just using a clone system call. And so this clone system call creates essentially a virtual set of data structures in the kernel that are then consumed inside of that process. And that process thinks it's running in its own operating system, but it's not. And on disk, now instead of having a single file, it's multiple files and it's packaged together in a Docker format. And then if you think about the real magic of Docker was it was the push, the Docker push is the magic because I can pull down an LXD image or an LXC image, I can pull down any format, I can pull down a VMDK, but how do I push it back out once I've made changes to it? It's like, okay, well I can SCP it back to the server and then pull it back off a web server or I can SCP it back and forth. But having the layers and having an actual protocol in the registry server is what really makes it a fancy file server. So it's typical CRUD application, right? And in fact, that's what I would say separates it from Cinder too, you know, and or Swift in general, like some of the ways that open stack works, like you don't really want people pushing new layers of images, it's just not fundamentally the way it works. It's merely read only. And then I wanna talk about, you know, and I'm building up to some crescendo here, but the idea of, I think Docker had it right when they mentioned that standardization was kind of part of the, I don't know if you guys saw all the old slides. This is probably three-ish years ago where they would show like a piano and a barrel and you know, like a truck and like all these different things and they were loading them onto a ship. And they would said, well it's hard to load because they're all different shapes and you know, containers give us the same standard shape, right? It has the hooks in the same place and we can load them. And I would say that's part of the value proposition. I think that gives you the hooks and you know, so the cranes here in this picture, like that gives you that, but fundamentally there's another value proposition that I don't think a lot of people have highlighted and I think it's that we're actually packaging at the factory, not at the dock. And so I'm gonna walk through this. So in 1906, the top image, right? It took like 45 days to load a ship. So you would literally load up a truck manually, you know, people would manually load it and then you would drive down to the dock and then it would take you 45 days to load a ship. So from the time the ship came in to the time it left was 45 days. And in that process, imagine you were loading something very fragile like lamps and you break a few lamps and it doesn't quite work, right? This is an analogy, right? The program doesn't quite work, Greg, when I get it at the dock.  And I'm trying to scale up an application and I've gotta run like 20 more nodes and I've gotta run Puppet on 20 nodes and bring them all up and that's a pain in the butt, right? So we do all these things to try and bake it at the factory. We will then like run Puppet, save that AMI or save that, you know, glance image, push it, you know, and then try to move that back to the factory and then modify from there. And we've done all these things to try and hack to do that. But at the end of the day, Docker what it really brought was natively we were packing it at the factory. So you can essentially, again, build it on your laptop, pack the container. If a few lamps break, I could figure it out there, right? I can keep reloading the container until I get exactly what I want. Then I can put it down on the dock and then the sys admins just have to load it on the ship. There's nothing, there's not much. We remove a lot of that pain, at least in the user space perspective. So we've got a pristine user space where everything is set up exactly the way the developer wanted. And that's fundamentally different. So I say, let's build at the factory, not at the dock, right?  So, okay, so you've got, build it at the factory, now kind of understand why we want containers, but let's look at the evolution and why we really get into open shift and open stack. So I mentioned before, you know, processes are fundamentally kind of the basis. It's the standard data structure that we use to run programs, right? And I joke, you know, is there really anything else, right? So, you know, is it good for databases? Yes, of course, because processes are the only thing that we have really. And unless we get into unit kernels, which we will not go down that mark, you know, we will not go down that route. But again, at the end of the day, you kind of look at the bottom row here, it's exposition of resources, right? So the kernel exposes the resources, whether it's a container or process, it's still what lights up the hardware. And if you look at the consumption, it's a process, it's a container, it's a bunch of containers, it doesn't really matter. At the end of the day though, when you get into a distributed systems environment where you need a lot of hardware lit up and you need a lot of fancy processes orchestrated, you know, fundamentally open shift and open stack do different things. You know, open shift is very good at orchestrating those things that were built at the factory, you know, as opposed to the things that were built on the dock. And I would argue, you know, open stack is pretty good at building stuff at the dock. I mean, with heat templates and things like that and puppet and you can bake AMIs in, you can start to try to move the work back to the factory, but it's a lot harder because you don't have the layers, you don't have the docker files. There's a, it's fundamentally, if you bake all that work back into a box, it's like a box that has no manifest, right? You can bake it into a glance image, but then you don't know what's in it and then you have image sprawl and you don't know what's going on. So fundamentally, I think open stack is very good at, at exposing the resources. I think open shift is very good at consuming the resources. And so, you know, getting back to my question of, well, why wouldn't I just use open shift everywhere, right? Why wouldn't I just dump every app in open shift? So since we've decided that building at the factory is better, let's just use that for everything, right? Well, I mean, I go through a few reasons where it actually falls down a bit. So, so I came up with a tendency scale. I just invented this last week. And I, well, I actually invented this like a year ago, but I finally wrote it down. And I used nice red hat icons to try and show you guys, you know, in a pretty way. So, so people will ask me again fundamentally all the time they'll ask questions like, is it, is a container good for my database? And I'm like, well, a container is nothing more than a fancy process. So yes, but it's really about tendency, right? So if I need a database, you know, and it needs to be separated from other, you know, it needs to be isolated from other processes. How isolated does it need to be?  I don't care. Like back in 1998 when I started, you know, I would just tell that into a web server and like I could see other people's files and I could do a PS and watch their processes running. And that was totally fine back then. Like literally that was how things were done at universities all over the country. You know, you'd tell them that in and process isolation was enough. On the other side of this scale, I'd argue, you know, as you kind of build up, you know, maybe I don't, maybe that's not quite good enough. Maybe I need a container. I don't really want people to be able to see each other's processes, you know, but then really honestly, maybe that's not good enough. Maybe I need a VM because I'm worried about noisy neighbors, which we've started to be able to handle some of that. But maybe I'm worried about somebody privilege escalating inside of a container because if we're running user namespaces, we have the ability to privilege escalate as rude inside of a container. So maybe I wanna actually kinda actually segregate by VM. But maybe that's not good enough. Maybe I need a physical server because I'm actually worried if a physical server goes down and we don't have good enough scheduling or where the VMs are. Or maybe I need one in a different rack or maybe, you know what, actually at the end of the day I want it on two different continents with different weather patterns. Like that's the most isolation or maybe we can put it on the moon. I don't know. I guess I could put a little moon in an earth. We could try and isolate it even further. But obviously that's fundamentally gonna be pretty expensive. I don't think anyone really wants to go quite that far. But I literally have had the question, I worked in data centers for a long time and we'd literally get the question, can it be in two different, where's your other data center at? I need to know is it in another weather pattern? Is it gonna be affected by earthquakes? So I'd argue it's about fundamentally, it's about tenancy and isolation and trying to figure out what your risk, what your level of risk aversion is essentially. And then another challenge if you will to containerizing is this is another one where I've invented the code configuration and data. So fundamentally if you think about what's inside of a container image. And in fact they're repositories but for the point of this talk I'll keep it higher level and say they're images, right? They're actually layered images that we call repositories. But for the point of this, the thing that we want to put in those containers and Docker containers in particular, right? I saw the LexD talk and actually I thought it was pretty good but they would preach that you can put anything in a container. And actually Red Hat doesn't completely disagree with that. We're working to put system D in a container but still fundamentally I think we do agree that you should only put the code in the container, not the configuration and not the data. So and I would argue that LexD says put it all in there, treat it like a VM and that's fine. But now you're packing at the dock. You're back to building at the dock instead of at the factory and so that's kind of fundamental. I think there's a happy balance with running multiple processes in a container, you know in a Docker container but you still separate out the configuration and the data. And I would always say this, it's fundamentally about code configuration and data. So I want my MySQL D to live in the container, right? And so then if I pull, if I do a Docker pull, I'm only pulling the code, that's it. If that thing dies, if it runs, the code died. Okay, I restart it, boom, my configuration of my data lives somewhere else. Kubernetes fundamentally, OpenShift fundamentally can pull that back in, you know, whether it's exposing it through secrets or exposing it through volumes inside, you know, persistent volumes, things like that. But fundamentally now the process can run anywhere. The fancy process can run anywhere and it will get access to its data and configuration again. We want to fundamentally separate these things. And I say other stuff because I actually have a blog entry coming out that actually, I have one that's out recently that I forgot to put in the links to this, but I will before I make this public. There's a whole bunch of other stuff too you have to worry about. It's not just that, but I would say that's the minimum set that you need to worry about really fundamentally. It's easy to get like etsymy.cnf, you know, varlib.mySQL, you know, you can know where to put those things. But like satellite six is a little harrier, right? Like it dumps stuff over the file system we're not exactly sure, you know. Like maybe I click in the web interface and it drops a file somewhere. I don't know where that goes. Don't worry, that's gonna be harder to get into a container, you know. I'd also say there's a whole bunch of other caveats. There's licensing. So wait till you put some kind of licensed code, proprietary licensed code in a container image, ship it out to a registry server and the wrong people pull it down and run it and your company owes like $2 million in licensing, right? So like fundamentally there's some licensing issues you gotta think about. There's also the installer issue and I have a whole list of them that I go through deeply. But the installer issue, if it doesn't have a clean installer. So fundamentally I'd argue Docker assumes all kinds of things. Like you can install the program in some fairly easy way with RPMs or DEB packages or something like that. The code, the configuration and data can all be easily identified and I know where they're at. It also assumes that the installer is normal like an RPM or an app to install. But if you have like installed.sh so I was literally talking to a customer a few weeks back and essentially they said, well we have this really nasty program and I won't name the program because I don't wanna dog them, they're a partner of us. But they had a typical Unix install with an install.sh, right? How do you get that into a container? So I can fire up a shell, get into it, run the install or see what happens, save it and I don't know what happened inside but whatever it's good enough, stuff it in a registry and then people can pull it down and use it. It was a network scanning tool so it wasn't like a database or something like that, it wasn't like an app server. So you can imagine for a network scanning tool it's still pretty convenient to have it in a registry server and kinda just stuff it out there and let people pull it down and use it where they want. So there's a lot of other things to think about. Sometimes though, at the end of the day it's easier to just put it in a VM. I mean, so that's what I'm getting at. Sometimes there's times where it's just too hard to identify all the things. And so there's a lot of challenge in the next five, 10 years honestly in my opinion to getting there all the way. So for that, and it's my only solution slide at all if you will, you know Red Hat's view of the world well we have this thing called Cloud Suite for applications that we released last week and fundamentally it's about allowing you and if you kinda look at the middle three boxes the idea is that you can mix and match applications that are made of containers and VMs. So you can imagine a scenario where you want the front end in containers but we have some weird program, some message bus that's some proprietary thing and that needs to live in a VM because we can't containerize that. But I also need a database. Maybe one of them lives, maybe we need an object store and that lives in a container and we have a hardcore Oracle database that still needs to live in a VM. And so the idea is to help you kind of orchestrate these things cross VM, cross using open stack and open shift. And in fact, we did a bit of a design summit couple months back where we actually built this out with heat templates and with essentially YAML files that define the Kubernetes objects for open shift. And it's very possible to do this to where you would essentially build a cross platform app essentially. So now I wanna dig into some of the integration points of where open shift and open stack would work well together. And then I'm gonna do a little bit of a demo. So it works pretty well. So this is one, this in fact, this first example is what I'm gonna demo for you. So again, getting back to exposition and consumption of resources. So storage is a perfect example. The object type in Kubernetes, if you guys aren't aware of it, is there are these things called persistent volume claims and there are persistent volumes. Persistent volumes are exposition of resources and persistent volume claims are consumption of resources.  And at the end of the day, if the sys admin hasn't logged into open shift and provisioned a bunch of five gigabyte volumes or maybe five, 10, 20, 40, 80, and you can imagine you get into this flavor problem. If I've pre-provisioned all of these storage volumes ahead of time, now I have resource, I've alienated a bunch of the resources and they can't be consumed because if an app that only needed five gigabytes ends up getting one of the 80 gigabyte volumes, he's using too much and then other people won't be able to get access to resources. So it would be really nice to be able to dynamically go slice up those volumes as I need them and only give myself five gigabytes. But I don't necessarily want a sys admin to have to log into some virtualization system and carve off five gigabytes and then say, hey, here's five gigabytes. And the idea is I wanna fundamentally get away from ticket systems and requests and things like that. I want this to happen automatically. What just so happens that OpenStack happens to be really good at this, right? So Cinder and what OpenStack can do, it can easily do that.  So one of the ones I'm gonna demo is where we actually integrate OpenShift and OpenStack and where I literally just requested an OpenShift. So as a developer, I log in, I go, give me five gigabytes and I just get a five gigabyte volume and I don't know where it came from and that's awesome because at the end of the day it came from OpenStack. And OpenStack was smart enough to say, here's your five gigabytes, cool. That works pretty well. We're working on heat templates and in fact I have a link at the end of this that I'll kind of show you. We're doing a ton of work around integration and there's still a lot of hairiness around the network of what's right. People are asking me about Contrail and Calico, Project Calico and all these different things and obviously a bunch of partners, Midokura and all these different networking things. Fundamentally, if you just go and install OpenStack and then you install OpenShift on top of it, you end up with double layered networking because the OpenShift installer by default installs an SDI in essentially. So now you've got loss for that. So one of the ways that we've worked to do this is just to provision OpenShift through heat templates and then you just rely on the underlying tenant network and so then OpenShift, which is fundamentally Kubernetes gets its flat network that it wants. It doesn't necessarily have to be flat because again that can be hidden from it by OpenStack but at the end of the day that's kind of where we're going now and then so the open, so the heat templates essentially take the Ansible installer and run the pieces parts that it needs to install it on a flat network, which is pretty cool. That's kind of what we're doing now. It's kind of still a work in progress of where we're going with that. Another place that is interesting is the load balancer. So again, anything that was external back in the operating system days, DNS, load balancing, you can imagine like, you know, NFS volumes, things like that. All of that you need to rely on somebody to give you that stuff. So again, OpenShift is good at just requesting that and OpenStack happens to be good at serving that. So that's another place we're working on integration. I tried to talk about the install. Another place that's interesting is we can actually integrate Keystone but what a lot of people don't fundamentally realize is it's not actually that great to integrate OpenShift against OpenStack. So you can imagine I have a bunch of developers logging into OpenShift, right? And I don't necessarily want all those developers to have accounts in Keystone. I don't necessarily want them to be able to go down to the platform and provision everything. So we're kind of working on it to work in progress but I think that currently internally we're kind of at consensus that having people, having both OpenStack and OpenShift authenticate against a single AD server, a single LDAP server, it's probably a better way and having groups and then you can divide the users out the way you want and maybe a few power user devs can actually log into OpenStack and like troubleshoot things but in general, I don't think you want every OpenShift user to have access to OpenStack. And so that's kind of the consensus for now but it does work. We can actually go through OpenStack, we can both go to the same LDAP server. There's a lot of ways to configure it. And then auto scaling, so in fact, I don't know why it says resources but I guess the idea, we actually have some heat templates that we're building that will create a URL. There's actually some auto scaling logic built into the heat templates so that say CPU goes too high and I'll just add another OpenShift node. So that's kind of fundamentally like, that's kind of reactive auto scaling. And then we've also exposed URLs for OpenShift to eventually be able to go hit a URL and then tell it, hey, somebody just asked me for a thousand containers, I know that in general I need about 100 containers per host so give me 10 new hosts and go pre-provision those so that we're kind of setting it up in that way that kind of we can either reactively or proactively ask for more resources. And now it's demo time and I want to point out that I use this inception picture because what I'm about to demo is running on my laptop in a VM, it has open, actually let me start at the top, there's containers running inside of OpenShift, running inside of OpenStack VM, running on OpenStack in a VM on my laptop and I did that in only eight gigs of RAM. So, but every second is going to be 45 days like in 1906. So, all right, so. And hopefully this works, I've tried this a lot, so I love demos at the end of the day. So, so I want to show you what a PVC is. So we call it PVC, it's persistent volume claim. So this is an object type in Kubernetes that in fact I can make this. Can you guys read that all right? Or would it be better for, a little bigger? Okay, good, all right good because it would mess up my windows and it's so cool looking right now. I feel like a hacker, like it's really perfect. So, so you can see in this thing just, it's pretty simple. I didn't want to show you a giant Kubernetes template that would confuse you. The cool thing about Kubernetes is you can break these, all these different objects. You kind of build all these objects to build up an application. You can put them in one file, in fact, OpenShift has a concept called templates. You can dump them all in. But templates are really hard to read. They're like, they get chaos as they get very big. But the cool part is I can just go create this one PVC and literally this is not necessarily even part of an application. And it names it dynamic-test, you know, 10. And the idea is then I would program, I would then have another app that would come along and say, hey, I need this volume, you know. And so you kind of connect an app to a persistent volume claim. The persistent volume claim dynamically, you know, connects itself to a persistent volume. The persistent volume in this case, since it's running on OpenStack, you know, automatically goes, talks to OpenStack, OpenStack says, yeah, I can build you a five gig or one gig volume and then hands it back. So I'm going to now run that by literally, it is a pretty simple command. You just do OC create dash F and then we're gonna create this PVC. And if we're lucky, oh, perfect. So surprisingly, there it is available. Boom, went to available pretty quickly, by the way. I would say that's pretty sexy because that took like sub two seconds to go actually. So now in Open, let me show it, finish show you. So OC get PV, you'll see that what happened is inside of OpenShift, it created what's called a persistent volume dynamically. That persistent volume used the driver to go set up a cinder volume and then obviously automatically connected it together, which is pretty cool. And that happened like sub two seconds.  Like the app's already up now. Like, and I didn't have to have a ticket to go slice off some volume on our, I need a lawn with one gigabyte volume. And then two weeks later, the storage admins get back to me and they finally add that thing. But I just did it in two seconds. So I think again, this kind of very clearly demonstrates the concept of consumption of resources and exposition of resources. OpenStack is really good at exposing these resources programmatically and dynamically even, which is much better than that little computer sitting in the room again. But OpenShift dynamically just needs resources. And you can imagine as I get into thousands of applications, so I have an error with my application. And my app might be made up of 30 or 40 volumes, right? It might not be just one volume like this. I could go fire up, even a simple WordPress example and every one of them needs a volume. So, or at least I need two volumes. But you can imagine much more complicated microservices apps where having this dynamic provisioning could literally just save a lot of life, a lot of time spent. So that's all I'm gonna show, pretty simple I think. And then I wanna say, what are my conclusions? So my conclusion is that essentially we kind of think about it in a distributed systems environment. OpenShift and OpenStack is kind of the new OS, if you will. It's again kind of the new kernel and the new process manager. And so there is scheduling that's happening in both places and it's very complicated. But at the end of the day, if you kind of fundamentally think about that, I think it clarifies like kind of what you can do with it. And with that, I have a few minutes left. Any questions? Does anybody wanna ask any questions? I can't see, so, sweet. So basically OpenShift is an abstraction on Kubernetes. So that's an interesting and very good question. So OpenShift actually exposes full blown Kubernetes. So Kubernetes is essentially a set of REST APIs. And if you look on an OpenShift master, it actually has a couple different URLs. It actually exposes full Kubernetes. It is essentially a rebuilt binary with all of the Kubernetes code in it and then extra objects added. So I could go into the weeds on that if you wanna go deep, but it has every single variable.  Yeah, exactly. So I could do kubectl, actually, I think we even have it in here, kubectl get pvc. So boom, you can use the kubectl command. So I've got the kub, that's a kub binary and it literally went and hit the OpenShift master and just brought back the same data. So the basic question is why do we need OpenShift? Because a lot of things are happening in Kubernetes. The load balancer is coming, persistent storage, as well as networking policies all the way up to the hardware. Why put another layer? So it's not exactly another layer, it's the same layer, but an extended layer of that same layer. So again, it is, when you install OpenShift, you are installing Kubernetes essentially with extra objects and that's a very, very good question. So the reason why, so I would answer that simply as, like last Friday I was at container camp with Tim Hocken and some other guys and I literally asked them, so if you look at kubectl, if you look at kub12, what was one of the things that came in? It was deployments. So if you guys are familiar with replication controls, what is replication, I could get in the weeds about what these things are, but long story short is these objects that existed in OpenShift were essentially a breeding ground to then bring them into Kubernetes and there's more and more of that happening. The authorization stuff is looking at being moved into Kubernetes, the deployments is something that's moving to Kubernetes. There's work on web interfaces of what we wanna do there. I would say fundamentally the build config objects are probably the biggest thing. So I'd ask the question, how do you patch in Kubernetes? There's currently no way to patch the image. There's ways to patch the app fairly easily with some external building and stuff, but how do you patch the container? So I would argue with, in fact, I have a pretty kick butt demo that shows a cascading build where I can actually, I kinda show a sysadmin can patch the image and you don't notice anything changed and WordPress looks the same, but if a developer logs in, they can actually change the code. So I'd argue build configs are probably one of the main reasons you'd really want OpenShift. And then, again, you view it as a breeding ground for some of the best ideas and honestly anything in code, right? Red Hat's pretty conservative in what we'll add to the Kubernetes code base to make OpenShift essentially, but some of those fundamentally really good ideas are getting into Kubernetes as we speak and so it's like, you're kinda getting the best of both worlds. You're getting stability where we backport features, just like we do with RHEL with Red Enterprise Linux, but you're also getting kind of best of breed features that maybe Kubernetes isn't quite ready for. So it's kind of a weird balance because I think fundamentally we're used to an upstream and a downstream and the relationship with Kubernetes and OpenShift is almost like a cyclical relationship. It's like yes, they fork, make a copy of the code at kube12, snapshot that, add our patches essentially, create OpenShift, which is essentially a super kube and then test those with the Red Hat community, which is a very different user base in a lot of ways than what kube is and then pull the ideas they want in. So it's a way for us to satisfy our customers because there's honestly a lot of use cases that are kinda scary and new for even the kube world because that was pretty much fundamentally designed for web applications and obviously that is not all that Red Hat wants to do with it. We wanna do a lot more than just web apps. So there's some breeding ground going on there. So hopefully that explains it. Any other questions? You did such a good job with that one. I figure I'd ask the other side, but I'm still trying to understand why connect OpenShift and OpenStack at all. Why not just have a container world and then your OpenStacky world and basically keep them separate. I'm still trying to understand is that just gonna end up cleaner or are you trying to kinda cover all use cases here? Well, I think the persistent volume one that I hope to is clear is the one that honestly is the most, that one to me seems to make the most sense. If I just install OpenShift on regular VMs or on bare metal, I have to go provision those PVs somewhere. So if you think about what I have to fundamentally do is go log into some iSCSI server or a fiber channel server somewhere and actually provision those LUNs, get the URIs for those LUNs, create a PV object inside of Kubernetes, map that to that LUN, and make sure that the nodes in the cluster can access that fiber channel or that iSCSI. I have to go, I'll do that stuff manually. So it just makes sense that OpenStacky is really good at doing that particular piece. So it shows that's pretty cool. In the future, I can give you some examples of where I think would be really cool. And the heat templates show it. So scaling is another one, like I wanna scale up. So I wanna scale up the nodes. So again, OpenShift is getting hot. It's starting to say, hey, I'm down to 5% resource utilization. I need more nodes.  Another interesting use case in the future that I think would be cool would be even what we call hypercontainers.  And then it literally goes talks to OpenStack, fires up a VM, which has Kubelet or OSC node in it. And then that automatically registers itself in the master and OpenShift is like, oh cool, my node's ready. And then goes and schedules the workload there. And so like those kinds of things where you see these dynamic interactions back and forth between kind of the resources that we need. And a VM is basically a resource, if you think about it, storage is a resource. Another one is network. Network is another one. So we get some really weird use cases again where people ask us, hey, we need containers that can only talk literally this port to this port on that container. Oh, and by the way, this one also has to talk to this one and this one.  You can imagine having some kind of SDN. You don't want to have two different SDNs. You don't want to have a SDN layer on top, but it would be really nice to go to configure some SDN and say, hey, open this port to this port up from this container to this container. And again, because if you think about that, from this process to this process on these nodes and having OpenShift go ask that to OpenStack would be really nice. And also if I fire up a new tenant, is another perfect example. Say, I've got a new dev team and I want to give them some playground where they can go kill themselves and not hurt anyone. Boom, you can imagine doing an OC new project in OpenShift and Neutron automatically goes and creates a tenant network for that project. That would be pretty cool. Those are the kinds of places where I would want to see more integration or I think it'll only get more, not less. Well, fundamentally, again, exposing those. A VLAN is essentially a piece of physical resource that OpenStack is really good at carving up in a software way. And so I think it would be really cool to see more interaction there. So any other questions? I think we are at time or even a little bit over. Oh, no, wait, we have extra time. We have like five more minutes. Any other questions? All right, if not, I'm done. Let's have, let's drink some beer. Thank you.


A lifelong advocate for social progress, Ruth Abram started her career advocating for women's and civil rights in the 1970s. These experiences led her to consider the relationship between history and social change. In the 1980s, Abram began to examine the history of immigration and its relevance to modern issues, and the idea of a museum dedicated to the immigrant experience was born. In 1988, Abram and her friend Anita Jacobson discovered a largely untouched tenement at 97 Orchard Street in New York City's Lower East Side. The building had been boarded up for 50 years, offering an authentic look at tenement life from the 1840s through the 1930s. Aware that they had struck gold, the two formed a relationship with the owners and co-founded the Lower East Side Tenement Museum. The revolutionary museum preserves and interprets a pair of 19th-century tenement buildings, the second located at 103 Orchard Street. The museum uses these buildings as a tool for addressing contemporary issues by telling the uniquely American stories of immigrants, migrants, refugees, and working-class peoples in the context of the places they live. Throughout her 20-year tenure as president of the museum, Abram focused on fostering empathy by inviting visitors to see America through the eyes of their immigrant ancestors. The museum works with local community members to share these stories, using the neighborhood as a backdrop. Abram also led efforts to create a New York City landmark historic district in the Lower East Side and pioneered the use of online digital tools such as the Immigrant Heritage Trail to help preserve the historic fabric of the neighborhood. In 1999, Abram's work in bridging history and activism became transnational when she organized, along with eight other leaders from around the world, the International Coalition of Sites of Conscience. Now encompassing sites in nearly 70 countries, the group leads the only global movement dedicated to spaces that remember and preserve the most traumatic memories, while encouraging their visitors to make connections between the past and related contemporary human rights issues. After her retirement from both organizations, Abram moved to New Lebanon, New York. In 2014, she founded Behold New Lebanon, a living museum of contemporary, rural American life that focused on cultural tourism. Ruth is now embarking on what she describes as her last big project, restoring the promised land plantation in Georgia to interpret the lives of the rural immigrants and migrants who settled there. Abram's paradigm-shifting leadership has directly inspired countless organizations and institutions to radically expand cultural and interpretive concepts at historic sites around the world.


So today, I want to talk to you a little bit about contributing, not actually money. So I guess the contributions I'm talking about, many people will probably first think about when you're contributing to an open source project, you're contributing code or changes in that way, but that's not true. There's a lot of different ways that we can contribute to an open source project. In particular, I'm going to be focusing today on the Selenium obviously, but this kind of applies to many other projects that you'll find on GitHub, BitBucket, or various other open source platforms. So things that we're going to talk about that you can contribute to are the other items, like not just code or bug fixes that pertain to maybe something that you care about or someone else's reported, but you can do things like improve the test suite of Selenium itself. We have documentation. There's seleniumhq.org. There's also a new, I guess, a new documentation site that we're trying to work on, but it's not quite there yet. There are helping with other people's issues on the issue tracking list, reproducing their problems, code reviewing pull requests if you feel capable enough to look at someone's proposed changes and give them feedback, also responding to the users lists, like Google groups or Stack Overflow and that sort of thing. So let's talk about that first. There's various forums that Selenium uses for discussion of issues that users encounter. Maybe some of you have used some of these, but one of the things that make these forums work is other users responding and giving advice, feedback, answering questions, and that's a very important thing to contribute to the project. Our Selenium users group would probably not be as active if we didn't have very many people responding to their posts. It would feel like a black hole otherwise, and we don't want that to happen. So having more people follow up on posts of the users lists, I would say you don't need to necessarily respond to everything, don't try to do that, only respond to things that you know about. A good learning tool also is looking at people's questions and going, oh, I don't know how that actually works and either looking into it or hopefully following along and seeing if someone else gives some advice. I would highly recommend not trying to.