Okay, I think we could go ahead and start now. So welcome everybody to this special NHGRI Zoom session which was organized to give folks a chance to hear about a very special event and honor involving our former scientific director Dan Kasper. I'm just gonna make some brief remarks, turn over to Dan and then if people have questions you just want them to have a moderated Q&A session. You could put questions in the Q&A and Paul Lewis on board as well. He's gonna moderate that discussion. But one thing I would say is one of the really gratifying experiences I had since bringing Dan Kasper over from NIAMS to NHGRI when he joined us as our scientific director was really just being able to sit back as you all know a baseball fan, just sit back and watch Dan and his group hit home run after home run after home run in terms of publication scientific accomplishments and then watch the accolades come in and the honors come in and it was just so gratifying to watch and it made NHGRI just so proud to see all of those things. Of course we knew what we were getting when we brought Dan over even at that point he was a member of the National Academy of Sciences at that point since then he became a member of the National Academy of Medicine. Most recently I think many of you remember he was federal employee of the year in 2018 but he also has lists of many other honors and honorific lectures and various other accolades bestowed upon him including the Ross Prize in Molecular Medicine in 2019. But then I think completely surprising to Dan was a phone call that he'll probably tell you about that came with an unidentified number that I would have never answered the phone because I was never answered the phone if I can't identify the number but this is an example where it's probably a good idea every once in a while to take a phone call from somebody just assume it's not a telemarketer and indeed it wasn't and he learned that he had been selected for this thing called the Crawford Prize which I wanna point out to you he's gonna tell you much more about it but these prizes are not just all about science they give them out in different thematic areas mathematics, astronomy, polyarthritis and geosciences and I don't think it was something that Dan saw coming and so I think that almost made it all the more pleasurable and it came with an immense amount of pride in part because of the incredible honor and also because it comes with some money that he could actually accept ultimately we would get approval for that and it also came with a very nice trip that he was able to take to Sweden so this is so special and so novel that Dan put a PowerPoint presentation together to be able to summarize it and I know he's been meeting with various groups who are interested in hearing about this including this group assembled here through Zoom and involving NHGRI staff and I should also point out I'm sure Dan will fill in some details this whole thing all happened in the pandemic it kept getting delayed exactly when he was gonna be able to go there that's that the other so it also got drawn out over what seemed like a long period of time but it finally came to fruition and I know it was a very enjoyable and remarkably rewarding trip for Dan and we wanna hear all about it so with that I'm gonna congratulate Dan once again on this incredible honor tell him how proud all of us are and now we just wanna hear about your ticker tape parade through Sweden. Well Eric, thank you so so much for that really kind kind introduction and I have to say that with this sort of thing it is perhaps a recognition of me but it is even more so a recognition of all of the people who work with me in my laboratory and clinical team it's a real endorsement of the environment that we have in the intramural program and particularly in the intramural program of NHGRI the support that I've had over the years has been absolutely wonderful and extraordinary and I have to really start out by just giving a big thank you to you Eric and to all of my colleagues in NHGRI and across the intramural program of the NIH and more broadly too we certainly have a number of collaborators elsewhere. As Eric said, this prize was a total shock to me when it came in and basically what happened was that this was back in early 2020 when I got the call, let's see, was it early 2020? I guess it was early 2020. No, early 2021, you see, I forgot. But in any case, we were in the height of the pandemic mode at that point and I was actually doing a clinical team meeting from home it was a Wednesday afternoon and as Eric said, the phone rang and as had been the habit of my wife who's also an NIH employee and was working from home as well we got so many telemarketer calls that we would just when the landline would ring we would answer it but then quickly hang up. And so I did this like three times the person kept calling and I kept hanging up and then Margaret took over and dished out a couple of more hangups before finally realizing that this person was very persistent and must have something that they wanted to talk to us about. She actually answered the phone and it was a Dr. Dan Larhammer whom Margaret had never heard of at that point from Sweden, he didn't introduce himself and in terms of being associated with the Crawford Prize or the Royal Swedish Academy of Sciences he just said he was Dr. Larhammer and he needed to talk with Dr. Kassner soon, urgently. And my wife said, well, he's in a meeting and can I take a message and so forth. So anyway, at first I had said, well, I'll talk with him after my meetings are over today which would be like at five o'clock in the afternoon but that would be like 11 o'clock at night in Sweden. So I thought better of that and actually played hooky from the Wednesday afternoon lecture series to take his call and then learned that in fact I had won this thing, the Crawford Prize which I knew about the Crawford Prize. I didn't know that I was going to win the Crawford Prize and I was just totally dumbfounded, I must say. It was just an incredible shock when I learned about that. So anyway, so this is the story of what happened since then. I'll just start out maybe by telling you a little bit about the guy after whom the Crawford Prize is named. And that is Holger Crawford and actually the prize is named after Holger and Anna Greta Crawford and it's pronounced Crawford. There's no W in it. So to pronounce it properly it's the Crawford Prize not the Crawford Prize. And Holger Crawford was a business executive. Basically he had been raised in Sweden by a single mother. He had gone to the Swedish School of Economics where he graduated first in his class and he became at a fairly young age the CEO of some company called Akerland & Rousing which is a packaging company. And shortly after he took this job as the CEO of the company, he came up with this idea for packaging milk in tetrahedral paper containers which apparently had never been done before. And he called this the Tetra Pak and founded a company called Tetra Pak in 1950 and made lots and lots of money from Tetra Pak. And by the mid 1960s he had decided that he wanted to move on. He spoke with this guy here whose name was Nils Owal who was a physician in Lund, Sweden. This is where the packaging company was and where Holger Crawford was. And Nils Owal had this idea for starting hemodialysis. And back at that time, hemodialysis was not something that was practicable. He developed the dialysis machine and Holger Crawford underwrote the company called Gambrough that made dialysis machines. And so Holger Crawford made a lot of money from that too. So in 1980, he established this prize, the Crawford Prize. And he did this in partnership with the Royal Swedish Academy of Sciences. And basically the Royal Swedish Academy is responsible for selecting the prize winners. And here you'll chuckle, but the prize is awarded on a rotating basis and disciplines chosen to compliment those in which the Nobel Prizes Award is awarded Astronomy and Mathematics, Geosciences, Biosciences with an emphasis on ecology and polyarthritis. Now you might think that the first ones, Astronomy, Mathematics, Geosciences and Biosciences, maybe they are in the same caliber as physics and chemistry and the other things for which the Nobel Prize is awarded. But polyarthritis, I mean, granted I'm a rheumatologist, but even I would admit that that's a little bit of a stretch to have a Nobel Prize equivalent in polyarthritis. But don't look a gift horse in the mouth with regard to these kinds of things. And actually Holger Crawford had a reason for doing that and that is that he suffered from rheumatoid arthritis in his later years. And he perceived that medical progress at least back at that time in the early 1980s was not very good in developing treatments for rheumatoid arthritis. And as a beginning rheumatology fellow back at that time, I can say that that was true. So in any case, there were these prizes, the Polyarthritis Prize actually was only to be given if there was some progress in the field. In other words, it was not a regular thing that there would be a Polyarthritis Prize. They had to have a special committee that would decide that there had been sufficient progress to do that. And in fact, there was no Polyarthritis Prize for virtually the first 20 years of the Crawford Prizes because they felt that there hadn't been sufficient progress. But in any case, so the prize entails six million Swedish kronor, which is a lot of money in US dollars too. It's over $600,000. So it's a lot of money. And some of the past laureates, I won't read off all of them, but some of them that you might recognize, James Van Allen, the person who discovered the Van Allen belts, E.L. Wilson, who many of you may have heard of at Harvard, and Carl Woos, who discovered the Archaea, the separate kingdom in phylogeny. So a number of fairly prominent people have won the Crawford Prize in other fields. In Polyarthritis, actually, the first of the prizes that was given in Polyarthritis was in 2000. And the first Crawford Prize at all was given in 1982. So it was almost 20 years. And that was given to Sir Ravinder Mani and Sir Mark Feldman, who were the two individuals who first had the idea of using inhibitors of TNF tumor necrosis factor for the treatment of rheumatoid arthritis, which was a revolutionary thing and warranted a prize, whether it was the Crawford Prize or whatever, that was a major change in the field of rheumatology. And subsequently, there have been prizes that have been given with regard to adhesion molecules, cytokines, the role of HLA and environmental factors and rheumatoid arthritis susceptibility, and regulatory T cells. So that's a little bit of the background on the Crawford Prize. Just to give you a little bit of an idea of why did they think that maybe I was worthy of the Crawford Prize. Well, they gave the Crawford Prize this year, the 2021 Crawford Prize, for establishing the concept of auto-inflammatory diseases. And so some of you will say, well, what's that? So at least as we first proposed them, these are a group of disorders that are characterized by episodes of seemingly unprovoked inflammation, but without the auto-antibodies or antigen-specific T cells that you'd see in the characteristic autoimmune diseases. So sort of diseases where there's unexplained non-infection caused, not malignancy caused, inflammation, but where you don't have the usual features of autoimmunity. And we now know that these are disorders of the innate immune system. The autoimmune diseases are more disorders of the adaptive immune system, whereas the auto-inflammatory disorders are more disorders of the innate immune system. And I'll explain that a little bit more as we go along. Just to put it in some sort of historical perspective, actually in the early 1900s, Paul Ehrlich, who was an immunologist, one of the founders, I guess, of the field of immunology and who won the Nobel Prize in Medicine back in, I think it was 1908, proposed that there could be no such thing as autoimmune diseases or diseases where the immune system would attack the host because the immune system is so potent that it would be fatal. And he called that idea horror autotoxicists, the terrible things that would happen to the host if the immune system turned on the host. By the 1950s, it became clear that in fact there were autoimmune diseases and that in fact diseases like lupus and rheumatoid arthritis and thyroiditis in those diseases that you could actually develop antibodies against your own tissue and have real pathology and not necessarily die from it, although some people obviously would die from that. And then in 2000, another 50 years later was when we proposed this concept of autoinflammatory diseases. So it's taken a while for this concept to evolve. In terms of how it happened for us, and this is boiled down to one slide, there's the three stages of discovery that I'll mention to you. The first stage was from 1989 to 1999 and that was the time when my research group was trying to and ultimately did find the gene mutated in familial Mediterranean fever by positional cloning. And at that time, at least in the world of rheumatology there was a lot of skepticism about the genome project. And in fact, of course there wasn't even a genome institute at least initially when we set underway. And the idea of familial Mediterranean fever which is a relatively rare disease where patients have a recessively inherited disorder where they get recurrent fevers and arthritis and severe abdominal pain and sometimes severe chest pain and can develop kidney failure from it. It was thought that that was sort of not a very relevant disease to be studying. And so some said that we were using an unproven method to study an irrelevant disease, but we persisted and ultimately did find the gene. And it turned out that that gene encodes a protein that had not been known before and turns out to be sort of the prototype for a number of other proteins involved in inflammation. And then a couple of years later, we kept seeing patients with unexplained recurrent fevers and we found that there were some of them that didn't have mutations in that gene. They had the mutations in another gene, the TNF receptor. And so we called that condition TNF receptor associated periodic syndrome or traps. And then at that point, the light went on and we figured that, well, there's two of these diseases both of them inherited disorders in which patients have recurrent fevers and inflammation and no auto antibodies. And so this is the basis for a new family of diseases. And so we proposed this idea of auto inflammatory disease. And then during the epiphany stage, which sort of began at the point where we figured that out, we started to sort of refine the concept of auto inflammatory disease and to think about all of the other diseases besides the ones that we had described that might fit under the rubric of auto inflammatory. And so we had a long list, we published a paper with this long list of diseases that we thought were auto inflammatory. And then within a year after that happened, another group in San Diego, Hal Hoffman's group in San Diego discovered the gene that's mutated in a couple of those diseases that we said were auto inflammatory and were somehow related to FMF and traps. He found the gene that's mutated in a couple of those diseases. And lo and behold, that gene encodes a protein that has a domain that is in common with the FMF gene. And so actually there was a connection there. And what's more through work that was going on in basic science at the time, that gene encodes a protein that's a regulator for IL-1. And so we and other people had the idea of treating these patients with those diseases with IL-1 inhibitors and it was miraculous. These patients, some of whom had terrible disease, children with one of the variants of it who developed meningitis, aseptic meningitis.  A lot of them die in adolescence. All of a sudden it was like their inflammation went away. We have kids that started on IL-1 inhibition at that time who are now graduating from college. It's incredible. It makes you believe in molecular medicine. So that's the second phase, the epiphany stage. And then the third stage, we say a little bit whimsically is the horror auto-inflammaticus stage. So rather than horror auto-toxicus, horror auto-inflammaticus stage. And so that's from 2009 to the present. And given the wonderful advances in genomics and DNA sequencing and all of the things that we can do, now we have like over 50 auto-inflammatory diseases. We recognize now somatic mutations can cause auto-inflammation. So really just a lot of fun. So it's been great. And whether there was a Crawford Prize or not, I've had a wonderful time doing all of this. And so there was a Crawford Prize. And ultimately we ended up going to Sweden, my wife and I, and actually we brought along some of our families on both sides of the family in late April. And so because of all of the postponements with the pandemic, they had saved up actually four Crawford Prizes to be given at the same time. Usually they do one at a time on a rotating basis each year as a different discipline, but they had saved up mathematics, astronomy, polyarthritis and geosciences all to be done at the same time, which was wonderful because it really then did make it like it was a smartest board of science that we were going to over at the end of April. So we flew over to Sweden, actually we flew to Denmark and then you take a car across the bridge to Sweden. And we did that on a Friday evening. And I forget what it was, maybe the 22nd or something like that of April. And got to this place here that you can see called the Grand Hotel of Lund. So we checked in to the Grand Hotel of Lund on Saturday. Now Lund is actually a beautiful historic city. This is the inside of a cathedral in Lund, which is almost 900 years old at this point that you can see if you visit Lund. But actually I wasn't visiting the sites of Lund because I was under strict restraints because of NIH travel policy. And so as it turned out, the events of the Crawford days started on Monday. I flew over on a Friday because the Crawford people said I should be there on Saturday, but actually they didn't have anything for me to do in terms of events. They thought that maybe one would want a tour Lund. But I had to have meetings scheduled for the Saturday and the Sunday so that it could justify my being there. So I contacted this guy, Frank Wohlheim, who's a rheumatologist in Lund, who's writing a book on his mentor, Jan Woldenstrom, who's since passed away. The Woldenstrom of Woldenstrom's macroplobulinemia. It's kind of blood cancer. And so we met on Saturday night to talk about this biography of Woldenstrom that he's writing. And then I had some other things I had to do for a rheumatology meeting in Florida that I had to log on to from my hotel room. So in any case, my family went and toured Lund and I talked with Frank Wohlheim, which was very nice. He's a delightful guy. But in any case, and then Sunday evening, we had a family dinner. And as you can see, there actually were a lot of family members that took us up on the offer to go over to Sweden. So we had a big dinner on Sunday evening. And then the next morning was the beginning of the proceedings, the Crawford Prize lectures and whatnot. So this was being held in the grand auditorium of the Lux Building at Lund University. And here I am before the actual lectures began and I'm there with Richard Holmdahl and Ole Kempke. And they were two members. Ole actually is the chair of the committee that chooses the Crawford Prize winners in polyarthritis. They're both rheumatologists at the Karolinska Institute in Stockholm and actually are also members of the committee that chooses the Nobel Prize in physiology or medicine. They were very impressed with the NIH, let me just say, because they remarked upon the letters that they had to write indicating that, in fact, the money that I might get was not for giving a couple of lectures at this meeting, but in fact was in recognition of my work. But they certainly were impressed that the NIH has a real set of standards with regard to that. And just parenthetically, I'd like to thank Ellen Ralfus for helping to move things along with regard to that process and Leonard Ross for everything that he did to help move the approval process along as well. In any case, once we had some coffee, then we had a series of lectures. So the first of the lectures was by Enrico Bombieri from the Institute for Advanced Study in Princeton. He gave the mathematics lecture. And for those of you who actually want these slides, you can have the slides and then you can click on the link and you could actually listen to Professor Bombieri's lecture. But let me just tell you that it was very complicated and I don't think that there were many people in the auditorium that understood very much of what he had to say. He's a very nice man, I must say that, but I didn't understand a lot of it. He talked about his work on prime numbers. A lot of his work over the course of his career has been on number theory. And he is a very prominent mathematician. When he was a young man, he won the field medal, which is another big prize in mathematics.  I tried to think of a little snippet of his talk that I could just play so that you could get a sense of it, but I failed. I just couldn't come up with anything. This slide simply shows the beginning of his lecture. He graduated his lecture in 1859, the epoch-making paper by Riemann on the Zeta function in the period, blah, blah, blah. But in any case, it was something anyway. So then the second prize was the astronomy prize. And that prize was awarded to Eugene Parker. This was actually the 2020 astronomy prize, as was the mathematics prize that was for 2020 as well. And so this went to Eugene Parker, but unfortunately, Eugene Parker, who was a professor emeritus at the University of Chicago, passed away about a month or so before this event happened. And he had been in ill health anyway. So instead, the person who gave a lecture in place of Eugene Parker was this person here, Nikki Fox, who is the director of the NASA Heliophysics Science Division, and very considerable person. And it was really an enjoyable lecture to listen to. You can see that she's got this T-shirt on that is the Parker space probe. She actually is the person that's in charge of the mission. They launched a space probe to measure various radiation coming out of the sun. It orbits the sun between just outside of Venus and then on the other side around the sun. And it goes in successively smaller orbits so that eventually it will burn up, but at least right now it's still functioning. But I thought that it would be fun at least to listen to her a little bit in terms of some of the things she had to say. So as the introduction said, I am the director of NASA's Heliophysics Division. And as such, I get to actually manage and look after a lot of missions, 20 that are actually up in orbit right now and another 14 that are in development, all of which are really studying science that was driven by Dr. Eugene Parker. And so Heliophysics is indeed the study of the sun, our closest star, everything from the very, very center of the star all the way out to the very edge of its influence and indeed beyond. And so here you see a very familiar looking planet, the Earth, and you can see that our magnetic field is protecting us from all of this stuff coming from the sun. If we go up and I take you to the poles of the sun, you can look down on the poles and you will see that atmosphere starting to spread away in a spiral shape, that spiral known as the Parker spiral because of course Gene predicted that would happen. Then we go to the very edge. So this is now the very edge of our sun's influence. This is where the solar wind stops and it meets interstellar space. This is yet another prediction of Gene Parker that in fact our solar wind would form a protective cavity around not just our planet and our star but our whole solar system. So as we are orbiting around the Milky Way, the solar wind actually protects us from the vagaries of interstellar space, from particles, from dust, from cosmic rays coming from us. And so we have a pretty nice life here because of the solar wind. But in 1958, using, and this is in Gene's own words, he solved four lines of algebra. That is how Eugene Parker described finding the solar wind. He actually said to me, all I did was solve four equations. So he solved four lines of algebra and it was all predicated on the Beerman study of the comets, which was so beautifully described to us. Beerman was actually visiting Chicago and he was meeting with John Simpson, who was Gene's boss at the time. And he presented exactly what you just saw, that the comet tails were always pointing away from the sun. And he actually said, well, there must be something moving out, it's some sort of, he called it corpuscular radiation. Now John Simpson kind of dismissed it out of hand and said, maybe something comes out occasionally, but it's not coming out all of the time. And he also cited a famous scientist at the time, Sydney Chapman, who had said that much like the Earth's atmosphere, the sun's atmosphere would be static. And so John Simpson had dismissed everything but he passed all the work onto Gene Parker and said, see what you think about this. So Gene studied it, he solved his four lines of algebra and he came up with different sort of solutions for these four lines of algebra, five of which were physically not possible, but the sixth one was. And I'm actually going to, I don't usually use notes, but I want to make sure I get this quote right because I love this. This is from a paper by Cain in 2009. So Gene Parker went to John Simpson and said, John, Beerman is right and Chapman is wrong. So John Simpson said, Eugene, what is your basis for saying this? Well, my calculations show that the sun's atmosphere is not only not static, but it's highly dynamic. And with millions of degrees of coronal temperatures, the whole place will be boiling and some flow would come out sometimes more, sometimes less, but never zero. And I, Eugene Parker, would like to call it solar wind. So John Simpson said, so what do you propose to do, write a paper or something? Gene said, well, yes, unless the university prohibits it. John Simpson replied, no, no, no, no, we're very open-minded here. Do what you like, publish what you like, but for heaven's sake, don't put my name on it. Wonder if he ever regretted that. So several journals did indeed reject this paper. But luckily, an editor did intervene. But one of the referees went so far as to actually say, if you're going to publish in this area of science, you might wanna go to the library first. And Gene told me this and he said, oh, Nicky, that was the nice review. So fortunately, the editor was Chandra Sacar, who was also at the University of Chicago. And he really kind of enjoyed the controversy. And he said, Eugene, I think this is a ridiculous idea, but I don't wanna see it killed, so I'll publish it. And certainly, Gene got a lot of, maybe ridicules too strong a word, but a lot of pushback and a lot of goodness, what is all this about from colleagues. But then just a few years later in 1962, the Mariner II spacecraft on its way out to Venus did indeed sense the exact solar wind that Gene had predicted. And so the rest is kind of history. But one of my favorite comments that Gene made was, if you do something new or innovative, you should expect trouble. All right, well anyway, moving on, then I gave my talk on auto-inflammatory diseases. You've already heard at least the essence of it, here I am delivering it. This is just a slide that is a note actually that I wrote on the very first patient that I saw with familial Mediterranean fever as a fellow at the NIH in 1985. Then eight years, eight years, 12 years later, when we found the gene for FMF by positional cloning, just a schematic of how we went about doing that. The fact that the gene in fact encodes what was then a novel protein. And of course, everybody very happy to have made it to that point. And I want to add that with the advent of the NHGRI or as it was called the NCHGR at that time, it really made a big difference for us in terms of being able to find the gene. It turned out that the N-terminal 90 or so amino acids that protein form a domain that's found in some 20 different proteins that are involved in the innate immune system. And then shortly thereafter, a couple of years thereafter, we, after we found the gene for FMF, we didn't know about this domain right away. But shortly after we found the gene for FMF, we found the second gene and proposed this concept of auto inflammatory syndromes. A year or so later published the paper in which we suggested that perhaps these two diseases, familial colder to carrier and Muckel-Wells syndrome were somehow related to familial Mediterranean fever. It turned out that then a year after that, Hal Hoffman and San Diego showed that in fact, the gene that's mutated in those two diseases share that N-terminal domain with the FMF protein that in turn led to the insights with regard to IL-1, and this is the publication in 2006 of the paper in which we showed that in fact, IL-1 inhibition is absolutely transformative for patients that have the neurologic manifestations of this condition. And then the two flavors of immunity, adaptive immunity where T and B cells are the major players, the receptors somatically rearrange and mutate and the autoimmune diseases are characterized by high-titer autoantibodies or antigen specific T cells and the innate immune system, which was just beginning to be recognized at the time that these auto inflammatory diseases were popping up. And in the innate immune system, myeloid lineage cells are the major effectors. The receptors are hardwired in the germline genome and the auto inflammatory diseases show inflammation, unprovoked inflammation, but without the autoantibodies or antigen specific T cells. Then with the cost of sequencing coming down dramatically, this is an NHGRI slide, we were able, and many others were able to find additional diseases, discover additional diseases in which there are mutations in genes that encode. Either structural proteins in the innate immune system or regulatory proteins in the innate immune system. In this particular case, discovering mutations in the ADA2 gene and children that have recurrent fevers and strokes, that led subsequently to the discovery of TNF inhibitors as a way of preventing strokes in these kids, which was really a big deal at that time, Mandy Umbrello led those studies. And then this is just a list of the various genes and diseases that we've discovered over the years, at least the ones that we've had a major role and there's 16 of them all together, 14 of them actually are diseases that didn't exist at the time that we started, that were recognized as just a part of doing this work. These are all monogenic diseases. And then there are a number of genetically complex disorders where we've also been interested in defining some of the susceptibility loci. So that was that talk. And then the last talk of the day was Andrew Noel. And Andrew Noel is a professor of natural history in the Department of Earth and Planetary Sciences at Harvard. And he got his Crawford Prize in Geosciences for the work that he had done, characterizing the first three billion years of life on Earth and its interactions with the physical environment. And that was a fascinating talk as well. So basically, he started from the standpoint of going back as far as you could in the fossil record of animals and then trying to figure out, well, what was life like on Earth before those fossils were developed? And so I'll just play a little bit of his talk for you. I'd like to take just a minute to put that animal record, in fact, the animal kingdom in perspective in both time and space. And if you look at that diagram in the upper left, it represents an effort by my friend Ron Milo in Tel Aviv and his colleagues to quantify the amount of biomass in different groups of organisms. And once you can see what they come up with here is that a majority of the biomass on this planet is actually plants with bacteria next and then fungi, then archaea, another group of microorganisms distinct from but organizationally similar to bacteria and then protozoans and algae and the little box in the corner is animals, much less than 1% of all the biomass on this planet. It turns out that plants actually cheat in that if you go outside and actually look carefully at one of the trees that surrounds us, you'll find that more than 90% of its mass is not living tissue. Wood does not become functional until the cells that created it die. So if you only include the living tissues of plants, then we live in a bacterial world with plant second and animals are still a very small part of it. Then let's go to the diagram beneath that, which is what's called a universal phylogeny. It is an attempt using molecular sequence comparisons to build really a genealogy that depicts the evolutionary relationships of all life. Uncontroversially, it suggests that there are three major categories of life, the bacteria, the eukaryotes, which are organisms like ourselves that have a membrane-bounded nucleus and then a group only really discovered to be distinct in 1977 called the archaea, which is organized in a simple way like a bacterial cell but is in fact quite distinct. That diagram shows the eukaryotes as being a sister group to the archaea through work done over the last seven years, some of it done in Sweden. We actually now think that the eukaryotic cell represents a merger between a recently discovered group of archaea and some cells from the bacteria. In any event, the reason for showing this is that no matter how you look at this set of genealogical relationships, all of the animals, both living and in the fossil record, reside on one small distal branch of the tree. And the inference from that is that there must be a deeper history of life than that represented by animal fossils. And that deeper history would be largely microbial. Then finally, if we look at the right-hand diagram, it's simply a geologic timeline. The oldest evidence for animals that we have from the fossil record goes back about 575 million years, but our planet is more than 4.5 billion years old. And so the question that I'll address today is what can we learn about this long interval of Earth history that precedes the advent of large fossilizable animals? Okay, let me then finish up then. The punchline, of course, is that we actually can reconstruct the deep history, both physical and biological, of our own planet. And now in the last 20 years of other planets as well, that there are not only reconstructable histories of life and environment, but clearly life and the environment have interacted through Earth history. And so that major biological transitions both track and I think help to drive environmental changes in our planet's history. And this is something that continues. These are just four panels of changes just during the age of animals over the last 500 million years. Most of you know that Earth is characterized by plate tectonics. So the actual geography of the Earth changes through time. This is what the Earth looked like about 250 million years ago at the time of that great mass extinction that Daniel talked about. And it's about as different from our present Earth surface as it can be that nearly all the continents are amalgamated into a supercontinent and there is a global ocean that's more than a hemisphere in extent. We know that atmospheric composition continues to change in particular the amount of carbon dioxide has changed through time. We know that climate has changed through time. This is just a drawing of what the Earth looked like 20,000 years ago when you have ice extending south in North America to about Long Island covering Scandinavia, things like that. And there's a series of ice ages through time. And every once in a while, bad things happen on short time scales. This is 66 million years ago here, two dinosaurs out on what will surely be their last date. And there's looking at this thing going on, which in fact, as many of you know, was an 11 kilometer bolide that crashed into the Earth in the Yucatan Peninsula and precipitated a major extinction. And one has to point out that we are not living in a static time ourselves. In fact, the evolutionary present is on a geologic time scale, a time of very rapid environmental change. I love these diagrams put together by a guy named Jim Barry at the Monterey Bay Aquarium. This is not the amount of CO2 in the atmosphere, but the rate of change of CO2 over the last 400,000 years. It's boring, it's boring, it's boring, it's boring, it's boring, it's boring. And then the industrial age starts and it gets really interesting. Here is the pH, rate of pH change in the ocean. It wiggles around and again, this is the phenomenon called ocean acidification, that the pH of the oceans has changed dramatically. And that is really the context that in which we and our children and grandchildren will live. And I think that by incorporating the lessons of Earth's past, perhaps we'll be wise enough to deal intelligently with its future. Well, hopefully so. So that was the last of the lectures for the Crawford Prize Symposium. I then went out to dinner with some of the people from my lab, from the early days of the lab, at least a number of them. So Mike McDermott, who was involved in the identification of TNF receptor mutations and traps. Ivona Aksentyevich, who's been with our research team for nearly since the very beginning. Ilone Pras, who was also one of the early fellows who is now the head of a genomics institute in Tel Aviv and his wife, Orit, and Elaine Gremers. The next morning then, so this was really a lot of science that we had during this event. We had a set of four parallel symposia having to do with the topics that each of the prize winners had. So there was a symposium in polyarthritis, a symposium in the geosciences, a symposium in mathematics, and a symposium in astronomy. I'll just play you a short clip from beginning in polyarthritis. Good morning, everyone, and welcome to the Krapfel Prize symposium in polyarthritis. And the theme of today is auto-inflammatory diseases. My name is Hans Eldegren. I'm Secretary-General of the Royal Swedish Academy of Sciences. The mission of the Royal Swedish Academy of Sciences prioritized four areas. The first two is to support science for policy and to influence the policy for science. The other two is that we want to be a meeting place for science and also to promote and award scientific excellence. It is the two latter aims that we are here for today. The Academy's two most prominent prizes are the Nobel Prize and the Krapfel Prize. We awarded Nobel Prize in chemistry and physics and the prize in economy to the memory of Alfred Nobel. We awarded the five Krapfel prizes in astronomy, biosciences, geosciences, in mathematics, and that's of course the reason we're here today in polyarthritis. I hope that you will find this symposium rewarding. I really wish you a great day. I know it will be followed by a dinner tonight, so there will be plenty of opportunity to talk to each other today. And by that, I leave the word to Professor Olle Kempe who will introduce the prize winner. So have a nice day. All right, well, I've already been introduced so you don't need that. And my talk, which was to a more specialist audience, dealt with some of the more recent things that our research group has done. I won't go through those in detail with you, just to flip through the slides of my talk anyway. And then there were eight other speakers that spoke. This was a day long symposium. Molym Camphie talking about the inflammasome. Harold Burkhart talking about psoriasis and its relationship to auto inflammation. Yannick Crow talking about the interferonopathies. Nils Landergren talking about autoimmune diseases as a counterpoint to auto inflammatory diseases. Elaine Ramers talked about her work on the genetics of bedchats disease, Claudia Kemper from NHLBI talking about intracellular complement. Ian and Bryson talking about napriphage activation syndrome and lymphocyte cytotoxicity. And Jean Laurent Casanova who many of you may think of as being more of someone involved in immunodeficiency diseases, which he is, but actually he has also a fairly significant interest in the auto inflammatory diseases as well. And this is just a picture of the people that I showed you earlier on the dinner photo a few slides ago. And then the third day was actually the day of pomp and circumstance. And so we can go through this relatively quickly. This was held in the assembly hall at Lund University. Here's a picture of my wife, Margaret and me. Beforehand, they made us rehearse so that we would do everything according to schedule. They had books that each of us would sign. There was a book for the mathematics prize. This is Dr. Bombieri signing that. The children of Eugene Parker signing in his memory in the astronomy book. Here I am signing in the polyarthritis book and actually revealing that I don't have nearly as much air on top of my head as what I usually think. And then here is the Crown Princess Victoria who is the person who gave out the awards talking with Ebba Fisher who's the granddaughter of Holger Crawford and the chair of the Crawford Foundation Board. Then just a photo of some of the various people that were involved in this. This is Dan Larhammer, the guy that I was hanging up on at the beginning of the story and Hans Ponce Elegren who you saw a moment ago. Then just some of my colleagues waiting for this to start. And this is the last of the photo snippets, a little bit of the pomp and circumstance of the award ceremony. So anyway, Crown Princess Victoria gave out all of the prizes, the medals, the gold medals that went with the Crawford Prize. And then the ceremony ended. Here she's walking out with Dan Larhammer. There was a banquet then that evening, a reception after the banquet. Here's Crown Princess Victoria with me and my family. This is my son Nathan, my son Ben, Margaret of course. And then that was it, it was over. The next day we went on to Stockholm, at least in part because my family wanted to see Stockholm but I had arranged for speaking events in Stockholm as well. And so once we got there, I had a meeting actually, this was something that I was quite surprised. The ambassador asked for, because the embassy looks at all of the things for US government employees anyway, for travel and the travel permissions and so forth. And so they had seen that an NIH employee was coming to Sweden for an award. And so he asked to see me. And so I gave him a mini lecture on auto inflammatory diseases and we met at the embassy. And then I gave a talk at the Karolinska Institute. And then that was it, it was over. And finally, the last thing that some people ask me is, well, what did you do with all of that money? Well, I haven't spent it all, at least yet. But one of the things that I thought was really a good thing to do is to establish a set of awards myself that I've donated money for to the International Society of Systemic Auto-Inflammatory Diseases. And these awards are named after some of the people who are the real heroes of mine and some of the things that I've done. Jörg Chopp, shown here on the left, who was the discoverer of the inflammasome. Isabel Tuatou, who was actually one of my arch rivals in finding the gene for FMF. Mordechai Pras, who was my very important collaborator and the father actually of the lone Pras in getting samples from patients with FMF. Alberto Martini, who's in Genoa and has led a large consortium of pediatric rheumatology clinical trials. And Charleston Arello. And so the idea is that younger people in the field will get these awards named after these people that are more senior and some of my heroes from the past. So with that, it's over. And I think that we're over right at the hour. So I apologize for maybe going a little over. I guess I can make the excuse that I played all of those videos. And so that's what actually took up all of the time. But I just thought that it would be fun because it really was a smorgasbord of science. And it was really fantastic, having the opportunity to hear what these other guys were doing too. And certainly I think in the future they should actually consider having combined ceremonies again. So in any event with that, I will call it to a close. Paul, if you want to, if there are any questions I'll try to answer them or if they're not everybody can leave a little bit early for the weekend. Yeah, thank you Dan, very much. This is a fantastic, quite a royal trait, if you will. And that we're so proud of you and all the great achievements you have made and making us feel like we're among the best in science. And you mentioned, they were the Royal Academy. They're impressed by NIH. I thought they were going to say they were impressed by how many great scientists we have here. But we do have great regulations but I hope you convey that obviously we exemplify what an intramural scientist can do. Indeed, indeed. Okay, I think it's, I do have some questions but I can ask you later. I don't want to hope people Friday afternoon but this is very impressive and I think we're probably to call it a close and I'll email you with some of the questions I have. And this is a really quite an important discovery and thank you very much. Well, thank you Paul, thank you all for being here this afternoon as well. Yeah, I'm sure a lot of people sending their congratulations to you and including some here in the Q&A. Thank you very much, take care. Bye-bye. Bye-bye everybody, thank you for attending.


Hi, I'm Leonard Petterling. I'm one of the system-D developers. Today I'm going to talk about one specific facet of the system-D project. System-D is this big suite of different components that you need to build an operating system from. And we'll focus on one little component of this, which is incredibly useful, but very little known. And everybody should know about it. I've been frequently doing talks about system-D. And usually I try to do the big picture talks. This time I start about just talking about one specific little tool out of it, because I think everybody should know about it, and particularly administrators, or people who build software, or people who test software, people who, I guess everybody what nowadays is called DevOps people should know about this, because it's actually incredibly useful if you deal with containers, if you play around with building container images to then ship and so on and things like that. But also if you're a developer and try to quickly build something for a different distribution or test something on a different distribution or things like that. Usually I talk relatively fast. If you have any problem with that, please show up and I'll try to slow down. If you have any questions, please interrupt me right away, just show up. I much prefer if we could make this an active session rather than something where I just keep talking and then everybody asks questions in the end. So yeah, interrupt me. Yeah, I assume that everybody of you knows that change would come out on Unix? Like who knows it? Sure, it's actually the first time I ever asked people a question like that on a talk. So let me rather ask, because everybody actually showed up like does anybody not know change route? OK, everybody knows it. So I guess I'm at the Linux conference here. So yeah, system.yanspawn is basically the same thing as change route. It's just so much nicer. So yeah, let's start by discussing why it is actually part of system.d. So I mean system.d has mentioned this nowadays. I mean it started out as an internet systems and most people probably considered one and that's the end of the story. There's actually much more than that. It is for us basically this suite that we build an operating system from, which I already mentioned. So it will contain everything that you need, like that we think are absolutely essential for building of most operating systems, regardless if it's for embedded, for servers, for desktop machines. Just a couple of components that we think that deserve being nicely integrated and make use of what the Linux kernel provides and work well together. While doing this, of course, we look at the various components of the Linux kernel that already exist and try to figure out if they're actually in any way relevant to system.d or not, or if there's some specialist feature. In some cases, especially in the container case here, we saw all the container stuff is actually not that hard to use from what the kernel exposes and we would like to integrate it more with system.d. However, currently there was, like when we started looking into it, there wasn't really such a nice tool to play with it. Container stuff on Linux usually means LXC, or means Lippert LXC, which by the way are completely different projects, and maybe OpenViset and these kind of tools. All of those are written primarily, I guess, for distribution of things and servers. They are relatively comprehensive. They expect a relatively high degree of understanding of what's actually going on. They are, in a way, way different than good old change routers, because change route, everybody can use that. Every administrator on his home machine, if the machine doesn't boot, or if he then boots up with some USB disk and then wants to get back onto his home machine, he's totally capable of using change route and he just knows how it works. These other tools are certainly not that like. So because we actually develop operating system, we thought, OK, we need something like a tool that just makes use of these kernel facilities and makes it really that easy to use just for our own testing purposes in the beginning, because we wanted to make sure that the entirety of system should work equally well on a bare-bound system, in a virtual machine, and in a container, and should just work. Like previously, if you ran system near something inside of LXC, you probably, or especially as this file in it, you had to make quite a few changes, like you would have to disable the Gettys and these kind of things, because we wanted to make sure that systemly ran nicely inside of containers, we actually were looking for a tool to actually test that. And so we actually started playing around. OK, LXC, kind of nice, but very complex. Like for example, it exposes all the C-groups attributes and all the complexity to the user, even though in many, many cases it doesn't make much sense. Like for example, they expose, like if you want to grant access or take away access of a container to a device node, you specify that by a major and minor number. But the thing is major and minor numbers are not stable in the current kernel, so you cannot actually write a configuration file that will survive a boot. Because basically the assignment of the major and minor numbers is not defined. It's there on every boot it might change. For a couple of devices, like DevNull and DevZero, and these kind of things, it's stable. But it's not for hardest, for example. It really depends on the order of how things get probed by the kernel. So yeah, all these tools appear a little bit too low level and knowing the back end of it, like the actual kernel system, because we thought, OK, we can just write a tool that does exactly what Alexi does on the lower level, but it's as easy to use as change route. And that tool is what we call system.nspawn. So it's called the nsense for namespace, because it makes use of the Linux kernel namespace feature. And spawn means, yeah, because it can spawn. So that's a little bit the background story why we added to system.d. Now people could assume that it's kind of like a competitor to Alexi or Lyppard Alexi. And we clearly want to tell everybody it's absolutely not. We push nspawn, like we created nspawn for our users, and we try to get people to use it for testing, for debugging, for profiling, and for building things. If you actually ship something on the server, you should not use this. It's not the tool that you want to use there, because it doesn't have any management things and stuff like that. It is such really that thing that, like the same way as you would not, or probably not, I hopefully not, ship something on the server that just uses the user bin, a change route command, the same way you shouldn't ship something on the server, really, that runs nspawn. So in that regard, it is just another tool, and the powerful tool side that you have nowadays to run containers and Linux. Yeah, if Alexi, I mean, just a little bit of background, but if you want to know more about Alexi, Lippert Alexi, and the kind of things, and probably the other conference that it's in parallel is probably more interesting. But just a high-level overview, like what people, in case you do not know that yet, what people always confuse the fact that Alexi and Lippert Alexi has nothing to do with each other, that basically they use the same kernel interfaces. So since nspawn also uses the same kernel interfaces and does not share code with either Alexi and Lippert Alexi, basically the relationship between Alexi and Lippert Alexi is the same as between Alexi and nspawn, and Lippert Alexi and nspawn, which is there is no relationship except that they use the same underlying kernel APIs. I think actually here LWN has actually pushed out a couple of articles about the underlying kernel stuff. So if you actually want to know what's actually below Alexi, Lippert Alexi, and nspawn, you can read those articles. Yeah. So again, it's not about shipping something on your server. It's not about actually using that in production. It's about building stuff. It's about testing stuff. It's about debugging stuff. And it's about profiling stuff. And there are actually a couple of distributions which nowadays use that for setting up the build environments for packages. Because it basically was very little work. You can set up your container, and then you can put it up and it will just work. So the entire deal of nspawn is that there is no configuration. The same way as there is no configuration for change route. Like if you want to start your change route machine, you don't configure anything. You just invoke change route, and then the directory, and I will change route into that. The same as the idea with system.nspawn. There is no configuration. It's the thing that just works. Well, sorry, at least. The thing, though, is that to make it just work, a couple of bugs currently left, at least on the Fedora 19, or actually the Fedora 20 that I'm using here, and we actually run into two bugs that are still a bit nasty, but I will tell you how to work around them. And I assure you that probably F21 at least will have all of them fixed, and the final version of F20 will have most of them fixed. So yeah, it's a bit, basically telling you that it requires no configuration just works actually doesn't. But yeah. Again, not fully applying. You'd live with Alexey or something for that. So the essence, basically everything I want to talk about in this talk are these two commands, like the upper one and the lower one. The upper one doesn't even have to do anything with system.nspawn. It's just the configuration line that you need on Fedora machines to actually create a minimal Fedora installation inside a subtree. So it uses yum. It uses dash y just to say it should always say yes. You pick a version.  You say where you want it installed, like this is the root for the container. You say, yeah, basically it disabled everything except for Fedora itself. And then you install the base packages and that's it. After you've done that, you actually have a directory there. And it looks exactly like a normal Fedora installation. It doesn't have a kernel though, right? Like these are the dependencies of these packages what you installed, not a kernel. And that's good that way because for a container you don't need a kernel. And then, yeah, of course, this is the Fedora specific command, which is yum, of course. The equivalent exists, of course, for Debian where it's that bootstrap. And there is something for Arc Linux and there's something for the other distributions. The man page of system.ly and spawn will actually help you with that. And we'll just show you the one line that you have to type. So if you're actually looking for the counterpart of this for your specific distribution, just check the man page. It's all in there to make it really super duper easy for you. So after you type that, you have the image. And with this command, you can actually then start it. It's looked a lot like change. Would you specify the pass to it? The dash D means specifying the pass. If you don't specify the dash D, it will basically start the operating system that's kind of working directory. And the dash B, the lowercase B, basically means that the machine should be booted up rather than just getting a shell. If you traditionally just use the change would command, it will just give you a shell. It will not boot up the machine. So if you look at this, the basic difference at this point is mostly this can be used to actually boot up the full container, as if it was a real machine. So now we have seen these commands that actually try this because I didn't want to rely on the network here. I actually already did the first part. So you have to trust me on that. One of the bugs that they actually still have is actually in Fedora so that actually this command will break you something with slash var and slash run. But that's really fixed soon. But anyway, it's really the goal that this actually will work. So let's do this. I have prepared, as mentioned, this YAM command to get the directory set up. I hope everybody can see the font, I think so at least. I prepared that in my home directory in the Fedora tree if you go in there, then you actually see, yeah, it looks like a real Linux in there. It's just sitting in my home directory. It's created by YAM. I actually have the same thing here because I need that for testing with Debian. So in the Debian tree directory, I have the equivalent with step bootstrap. Since step bootstrap is actually packaged for Fedora, I could just do that trivially on Fedora. Just as a thing that I mentioned was the man page. If you go to the man page and go to the end of Fed, then you see the examples. See the upper one. The upper one here is the YAM command that I just showed you, unfortunately truncated here. But we can scroll to the right and then you can see that. Here you see the equivalent commands for Debian. Then you have the equivalent command for our Linux. And the other one is something different. But anyway, so just to show that. So I've already prepared that. So then let's do that. Let's actually invoke, and you see that you can, this directory. So I'm using, since I installed into a different directory, I have to slightly modify the command and then actually specify the real directory. And then I can, after, this has to be done as root. The same way as change root has to be done as root, because the functionality of the kernel is not available if you're not root. Then we have a syndicated. And there we go. I'm already logged in. See, if you look at this, and now I actually started the Debian machine, sorry, because I'm specific about the Debian tree. So sorry for the confusion. But anyway, you see here suddenly you get the normal method that you would get if you boot Debian nowadays. You're like, welcome to Debian to do Linux, as he said. It's a relatively old version of SystemD running inside of the container, like in this case, SystemD44. It's ages old. But there you go. You have your virtual machine. We can power it off again. And the thing that I actually wanted to do, which is start the Fedora tree, where you get it like this. And if we scroll up to see what actually happened, it's a little bit cleaner here. You get the welcome to Fedora 19 thing, what you see on a normal bare bone machine as well. And yeah, this is just because we didn't specify anything. So try to boot actually into graphical mode. But it doesn't really matter, because there was no GDM installed. And it doesn't even work having GDM installed in there, because there's no hardware vibe in the virtual machine. But anyway, and then you see the normal boot process of Fedora, and then you can log in, and you get a shell. Now you are inside the container here, so if you type PS, then you actually see the processes here. And because you don't see the host processes, you only see SystemD here, JournalD, Debus, SystemLoginD, and your actual login shell. Otherwise, there's nothing installed, and so you can't actually have anything. Since this is a full container, you can install software then inside of it and do whatever you like. Yeah, it's a full blown machine. I can power it off. OK, this is actually one of the bugs. It's currently in the kernel. Sorry. Can you say more about this bug? About this bug? OK, so I mean it's a little bit off topic, because this bug shouldn't exist, but it's there. It's a bug in the kernel. It's basically we, in some cases, don't get the notification of the kernel that a container really germinated. And because we don't get that notification, the container basically stays around all the time. So in SystemD, every container that is running, regardless of actually if it's an N-spawn container or a Lippert LXC container, carries a name. That name is attached to all the processes of it so that you can actually see it with PS and things like that. And that name is never freed again. And if you do not specify what I'm adding here now, dash m and some random words, then it will generate this name for the container from the directory that you have specified here, which in this case it would take the Fedora tree stuff. But since the Fedora tree container didn't get cleaned up because the kernel sparking didn't send us a notification, we just pick a completely random bullshit name here, which is in this case is fffffff, and then we can boot it up again, right? So yeah, it's unfortunate that there's this bug. And I need to isolate a bug. Like I've talked to Tejun, who's the secret container where this problem lies, and he's kind of waiting for an isolated test case for this so that we can actually get that fixed. Let's just do that. So let's first do that inside the container. OK, we don't have PS3 in the container. And I don't have network, so I can't install it, sorry. But let's do it outside of the container. I hope I have it installed here, yeah? So there we go. It's a bit hard, a bit difficult to see here. Let's try that through less. So that's where you see it. You have the GNOME terminal of Bash. Where is it here? It says in the N-spawn. You see that these are child process of that. I can fully see inside. Yes, it's basically like any other. I mean, that's not a particular property of N-spawn. That's a particular property of all the containers that we have on Linux. Basically, everything that we run in container to the outside appears as if it was addressed in normal child process. Of course, what you will notice, I mean, you don't see it here, but the PIDs will be different, of course. Because this process here is the PID1 of the container. So everything appears differently. So if we type PS on the host and pipe that into less, then you will first see this is the system D of the host. But then if you actually go down, so where is it? There, you see the other system D. And this one has something that is not one. But if you do it inside the container, which we can totally do as well. And then you see that's actually the same process, this one that's called PID1 here from the outside, something different. But actually, since we actually looked into this PS tree, the PS tree is, it doesn't really show you that this thing is a container. We offer an alternative to PS tree, which will not show you the hierarchy of the processes, but will actually show you the hierarchy of C groups. I'm not sure if you guys are aware of the C groups feature. If you are aware what that is, then I'm sorry, because I will give you a little bit of introduction to that. C groups is basically, it's a much-discussed feature of the recent Linux kernels. It's basically something where you can take a couple of processes and make a group out of them, a C group out of them, a control group out of them, which is basically just this group of processes. You can attach a label to them, like a name. You can organize these in a hierarchal fashion. So you can have a tree of groups. And then you can optionally apply resource limits to them. It is one of the basic building blocks of what Linux containers are built of. You take the processes of the container, you put the label on it, you possibly add resource management. That's basically what C groups are. C groups, as mentioned, are organized in hierarchy. And we can actually easily show that. SystemD comes with a tool called CGLS, meaning C group list. If we type that, then we actually see the C group hierarchy of the system. It's an incredibly useful format. Come on, it really reminds, it looks a little bit like pstree, except that it totally does not. So you basically see all the C groups here. In this case, it's a slice. I'm not going to go into detail what a slice is, because it's very systemally specific. Let's just say every user gets a slice, every log in session of the user gets a slice here. Yeah, so every user 1,000, that's me. And then I got a session. And these are all the processes that are running inside of it. And if we then go down, they are the process that is. That's true. So and here, you see the machine scope. That's actually the thing that we created. And there you have actually basically the subtree here that you see from there to there. It's the same thing. That is the entire thing, just for the container, if you follow what I mean. So because I'm logged in once, I have one user thing. And I have one session inside of that. You will see that. Then in system, you find everything that is basically a system, everything like diamonds and stuff like that. And for every diamond, you have one C group. And inside of each of those C groups, you have the process of this diamond. And that's in this case pretty boring, because it's just one process each. But anyway, so the takeaway of this is, if you run this, you can type system.dcgls. And we'll actually show you the hierarchy of the system, how it consists of login sessions, and machines, and services. And then you can hierarchically go down for that and go further down into the individual containers. System.dcgls, again, is no way tied to system.dn spawn. It works for any kind of C group setup. And it's particularly interesting if you have containers, because then you actually can go down. We need to go further down and stuff. But it's an incredibly useful tool. There's a similar tool, actually, called system.dcgtop. So Cgls just gives you a plan list of all the C groups with what's contained in that. System.dcgtop will actually show you the resource usage of this. This case, unfortunately, because the window is too small, can't really see the stuff that's inside of it.  Yeah, like, oh, that's a good explanation. Anyway, I think this goes a little bit too much into a different topic, which is resource management, because it will actually show you the resource management, like the resource usage of these services. Because we don't have any resource usage in the container right now, because there's nothing actively running. You don't see it in the CPU thing there.  But anyway, let's ignore that for now. Let's just focus on Cgls and how awesome it is, and actually shows you the recursive things of everything. Yeah, let's go back. OK, now I have to terminate the other container, this one. OK, I first have to power off the container. So by the way, you can even reboot and all these kind of things. It will just work. It will just appear as everything. Oh, something that N-Spawn, by the way, is very good at is that it will automatically inherit the network configuration of the host, which is systematically different from how LibVert, LXC, and these kind of things usually are set up. Because basically, yeah, we copy the ETC resolve conf of the host automatically into the container so that everything just works. We do a couple of other things to make things just work. Like for example, the time zone is automatically synchronized from the host into the container, so that the timestamps look nicely in the container. You don't have to set anything up. The idea, again, is that with that yam command, you set up the container. And with systemDnSpawn, you can just boot it and it will just work. Let's go back to the, OK, now I have to do this. There we go. Yeah, again, this is like the most important slide of them all, because it actually tells you how to do this. If you're wondering how, again, just remember systemDnSpawn, go to the man page. You find this line, and you find this line. By the way, again, if you guys have any questions at any point in time, totally interrupt me. OK, the next command I would like to talk about is the machine control. Machine control is, again, something that is incredibly useful in context of systemDnSpawn, but is not bound to systemDnSpawn. It's supported with Lipford LXC the same way. Basically, in systemD, we wanted to make sure that containers are nicely integrated into the rest of the West. The basic idea there is that on Solaris you have these concepts of Solaris zones, which are relatively nicely integrated into the rest of the Unix commands. Like, for example, you can list the services on your local machine, and then you can actually recursively go down and also see the services with the same command of all the containers that are, all the zones that are running on the same host. We are interested in providing the same kind of integration on Linux. So far, the container worlds and the rest of the operating system were pretty isolated. We wanted to make sure that they're nicely integrated. Nicely integrated, for example, means that if you type PS, where you, like, you know PS, right, like where you see all the processes, the name of the process, PODs and things like that, and you can show all kinds of attributes, we wanted to make sure that you can also show the container name that a process belongs to, because after all we have seen the PS tree, you have all these processes all there in the host, and you see this gigantic tree of things coming from all the containers. What you really would like to know is what it actually belongs to. For that, we created a little bit of a mini-down, like mini-services that just activated if people need it. All it does is make sure that if some container manager, like Systeme and Spawn, or like Lyft.LXC runs, it will tell the system that, the system will remember that, and it will provide this functionality for PS and things like that to actually show you those columns. All that works already, at least if you run Fedora 20, so that you can actually, yeah, if you type PS, you can actually get the columns for, for to which container that works. Again, this works for Lyft.LXC containers as well. However, I can show you how this works here for and Spawn because it's so much easier to do. If we type machine control right now, because of this bug that I mentioned earlier, the machines will not have been cleaned up. So if I type this, you actually still see them running there. The reason why we call this machine control, by the way, that probably deserves a little bit of an explanation. We wanted to make something work that is capable of recognizing processes which belong to containers the same way as the recognizing process which belong to virtual machines, like QEM or KVM or something like that. So we try to come up with the names that are generic enough to cover any kind of virtualization technology, regardless if it's more like virtual machines, like running a kernel inside of the thing or more like containers running the things on the shared kernel. And the name we came up after looking for a long time as machine is basically the generic thing for that. Yeah, in this case, you see the list. As mentioned, they're actually dead, but because of the kernel, we didn't learn that they're actually dead. So the original one was Fedora tree and then renamed and started another time with FFF still running. This one says basically this column is if it's a container or a VM, since we did not start a VM, we don't have an entry there. So everything says container and then services, like just a little bit of information about what actually started that. So machine control can give you a list of the current stuff and these, like if you type PS, but actually I don't know the problem is I would like to show you that with that, how that looks in PS, but I don't know the precise command lines. So yeah, let's see that it's a machine column. So let's try that. I hope this will work. So eight that, so then let's start the container again. And let's give it another name. And so this is this thing running now and now let's try PS. See, and okay, it doesn't look that nice because I manually put together a couple of columns here, but if you use this, this is standard PS again, you see the, we say we want to have the list of the processes with the PID in the first column with the arguments in the second column and with the machine name in the third column. And then we see, okay, these are the ones that actually belong to the machine. If we run a couple of containers at the same time, this of course gets more interesting as we will have more processes that actually have listed something in the third column. If there's nothing listed in third column, this means that it's eyes are not assigned to a container, it's actually off the host, or that the software in question doesn't actually tell system D about machines. Libvert LXC tell system D about machines, not Libvert LXC, like the non-Libvert LXC, the project that's just called LXC doesn't do that to my knowledge as far as I know. I guess in a way, yeah, we work very closely together with the Libvert LXC guys, the LXC people are a little bit more distant, so the updates don't happen that quickly. Anyway, so machine control, let's continue with that. If I type machine control right now, we see the three machines. Actually, one of them is currently running. Again, the other ones are because the kernel didn't tell us that I stopped. You can actually use a couple of commands on that. For example, we can do machine control status on this third machine, because we run it, it's the most interesting one. So, and if you run that, you actually get a lot of more information. For example, you know the PAD of the, who started that, like who's the PAD one of the machine. In this case, it's system D, because the container internally also runs system ES. In its system, then you see that it was N spawn that registered this, and you know that it's a container and not a VM. You have some information about what the router actually actually was. And you have, there's a C group contents, basically, with everything that's running inside of it. So, all of this is also viable as a lower level command with machine control show. So yeah, the stuff that is exposed to you is actually, the machine control is nothing but, I guess in a way, a test case for us. Because we provide APIs, how people can actually enumerate the machines that are currently running, like the containers and version machines. And this one is, this tool is basically just the front end for that. There's also a couple of diverse interfaces, like you can, it's basically like, yeah, it's a generic way how you can list, regardless what machine manager is used, what containers are there, and actually go to a couple of operations on it. Yeah. So, that's machine control for you. Well, I'm not logged in into this one, but if I log in into this one, and shit, and now I go to the shell again, and I do the, where did this command go? Anyway, let's do that again. So, I actually see the scope there. It's just about logging in, actually. Oh, it is. This is a slice and this is a scope. Okay, so what might be misleading is the fact that here it doesn't have a slice thing, that's because it's a slightly old, filler 19 and not that old 20. Yeah, machine control is a very powerful, no, actually, if you use directly, very useless, but also like it basically exposes the subsystem to other programs that are incredibly useful. The same information is actually also viable in GNOME system monitor, like this PS-like tool that GNOME has. So, if you ever feel like browsing your containers with GNOME tools, then you can totally do that, and we'll see the same information. Still no questions at this time, or that question. Yeah, it's basically, it's a tiny diva service that just keeps track of what N-spawn and libvert LXE and potentially in the future LXE tell us, so that we then can hand it out to PS and all the other tools. Like our goal with something that we're probably going to add very soon actually is that system control, you know, system control is a primary interface, how you can start and stop services, learns about containers the same way. So basically that you can just issue system control dash M for the machine name, and then you can issue commands instead of on the host on a specific container of your choice. And also the same thing that I mentioned earlier with Solarisone, where you could get a recursive list of what's running on the host and what's running in the individual containers. That's the same thing that we then will provide basically by simply numerating all the machines that are running and going into everything or one of them and inspecting the state. And then, yeah. Yes, well I mean to system the inside. So basically the machine control that you run on the host is affronted not only for the system D on the host but also system D on the many containers that you might be running. So with that we have something that starts to feel a little bit like what Solarisones can do. Yeah. Again, there's this three bugs. One you already mentioned that you saw which is this kernel bug that we don't get the notification as a secret branch entity which is definitely fixed by the time Fedora 20 is out. The second one is the audit system is still incompatible with this entire scheme. So you actually have to turn off the audit system in the kernel. If you don't do that, then you cannot lock in into your containers. It's because audit is doing weird things. There's a patch for that, but it's not fixed yet. To turn it off, auditing, you don't have to recompile anything or so. All that you have to do is that you're on the kernel command line specify audit equals zero. Again, this is something that will be fixed soonishly and the patch already exists. And what was the third bug? Hmm? Oh yeah, the bar time thing in Fedora. Like I mentioned that already, like the yum command will currently not create a working image for you because it forgets creating a simulink from var run to run which is the bug that Fedora needs to fix. But with that one, yeah, if you have all these three things fixed or worked around then everything works without configuration, yeah, right? So yeah, I'm making basically the promise here that everything will be awesome in the future but it's not yet that awesome, yeah. Another thing that is actually kind of nice to know if you run system.d and spawn then you can actually, if you run it with a default command line it will actually create a sim link between the hosts journal directory in case, I mean, does anybody not know the journal? The journal? Everybody knows the journal? There's somebody who doesn't know the journal. So the journal is basically, it's an indexed logger that system.d includes. It's basically, I mean, yeah, I can do talks about journal of its own but it's a very useful index database of everything that happened on the system and it's a little bit like classic Unix syslog except that it's indexed and it's, yeah. It is, what we can do with a journal what you can't really do that nicely with syslog is that we actually can interleave multiple journals from different hosts with one command. So what we can actually do here is, okay, this is actually, I hope this actually worked.  Okay, it didn't work in this case. Sorry for that, it's probably a permission problem but I'm too lazy to debug that now. So if you, yeah, that didn't work. Anyway, that's a permission problem, I'm pretty sure. Maybe we can work around that permission problem. Anyway, the idea basically is that the same way as we try to integrate system control of the host so that it can issue operations not only on the host itself but also all the containers that we can do the same for journal control. And so basically there's this journal control switch dash M and that means merge and it basically merges all the journal files that of containers running on the system into one single stream. So if you use journal control dash M, you basically, you can look at the stream of logs the same way as you would look on a stream of logs from your local server but it would actually include everything that happens on the system regardless in which container and things like that. So system control and spawn supports that. It will actually set that up by default except that it didn't work in this case for permission problems but I'm too lazy to debug that here in front of you now. Something else that might be a nice theory to know. This in the end spawn as mentioned by default make sure that the network configuration of the host is inherited into the container simply to make it as easy to use to get started. And that in this case means that it will, we are like all the network interfaces available on the host are also available in the container and ETC Resolve Conf is copied from the host into the container to just work. You can also use in a different mode where you basically specify the command lines and just system the end spawn dash dash private network. If you do this here you basically, yeah if you specify this stuff then instead of actually getting access to the real network you get a private loopback device and a little else so you cannot actually get out of the container which is ideal for build systems because build systems usually download everything from the internet to set up the images to build things from and the sources from the internet but then again while they build they probably shouldn't phone back to the vendor who did them. So you can actually turn that off nicely. Just because we see this here currently a couple of other features of system the end spawn like the D and the B is the ones that you already saw that you actually can specify the directory you want to put. If you do not specify the B then you get a shell. I can quickly show that I guess. Do we have, so let's pick an even different name. This was with the B was where we actually boot the entire thing. And if I drop the B and change an even different name then I got a shell, right? And in that shell there's nothing running except dash and PS. So it's basically running. It's basically as if you would boot a real system within it equals bin s h on the kernel command line. But let's shut down this thing again and have a look at this again. So dash u you can actually change to different user ID inside of the container which is sometimes useful for executing stuff. By the way you can actually add a couple of commands here to the end like if we do this I could actually invoke ls at the end. Even different name and then you get the output directly back. Let's see other stuff that there is. The thing that I always use to pick a different name is the dash m thing where I just picked any name for the thing. Again the name is that stuff that machine control shows you when listening the machines and what PS shows you in the machine column. Slice is something that is relevant for, like a slice is basically a concept that system recently introduced in context of the C group rework. I'm not going to go into much detail for that but basically allows you to, you basically can have slice off the part of the of the available resources for a particular customer and then you can assign services and machines to that slice and then everything you can apply resource limits to that slice and then yeah that's basically counted together. So with dash s you can actually specify the name of that slice. Private network is a thing that I was just talking about. Read only is an interesting one. It makes the root directory as a container read only which is kind of powerful because it allows you to yeah limit what the container can do and you could actually relatively easily run a couple of containers from the same directory. You can actually do that. So there's the bind thing here. With bind you can like bind a directory from the host into the container and then there's bind RO which does the same thing but it's read only bound amount. So you can actually, I mean either you specify a single pass and then that pass will be taken out of the host or it's still available in the host but it will taken from the host and made available the inside of the container in the same place or you use the colon and pass the second thing and then we'll place it in a different thing in the host. So for example, if you wanna make your home directories available to the container which it won't be by default then you can just pass dash dash bind slash equals slash home and then you have the home directory. Of course this is not as good as it sounds because the use IDs might not match, right? So because the password database in the container is not the same one as the host, likely, not necessarily you can of course have synced that manually but if you have not synced it manually then they won't match and then the home directory is not as useful as it sounds but it will probably still useful to do this like dash dash bind RO. The link journal mode is what I said here is that they actually get the, okay, now I know what I forgot, I never actually specified the dash J. So let's give it a cert try that I actually boot up the machine or force try it actually is by now. So and then let's, oh by the way, one nice thing here is actually that the machine name that I specify we actually pass on as the host name of the container later on. So if I on dash, specify on dash M any name I like we'll actually P here as the host name, yeah? Because basically like Linux containers support host name virtualization, we just pre initialize that like, like we just in N spawn we know the name and then right before we hand off to the init process of the container we set the host name. And then the system, the inside of the container is actually smart enough to detect whether the host name that is already said is a valid one, like in this case or is just the default name that the kernel applies which is none, right? So yeah, we try to be kind of smart and make sure that this name of a container is something that transcends all the layers of our stack, right? Like so that it's a viable, it's originally supplied by you on the command line, it's on one hand passed down into the container to be used as host name and on the other hand passed to machine D and machine control we actually get a list. So how much time do I actually have? I think I've got 50 minutes so that's five more minutes but I'm mostly done anyway. I actually wanted to show you the merging thing and there it actually worked in this case. So now you actually see a merged output here of the journal control of the journal logs. So basically this one is Delta is my laptop and this is the container that I just started and you just see that intermixed here. Then this is again my host and in this case it's kernel message because I said Linux because we mounted a couple of file systems in the container. Yeah, it's kind of cool actually that you was this command basically journal control dash M and again is the thing that merges all the machine all the registered machine journals into one and E just jumps to the end of it we'll just show you everything in one stream. Yeah, I think I already mentioned that that we wanna have nice integration with system control as well so that it can apply all your operations on a couple of containers. Again, this is not specific to N-Spawn but N-Spawn is the thing that we use basically for development but usually Daniel Bernier who hacks some lipid LXC is really good at very quickly adding similar integration into lipid LXC. So basically our goal there is yeah use N-Spawn on your local stuff to debug test build and sync like that and then ship it on lipid LXC but have the same kind of integration available in PS in system control in machine control and all these kind of things. And that's all I have for now. So if you guys have any questions, shoot. I'm sorry. It's a very different tool, right? Docker is something where you can actually create operating system images, hand them out and spawn as a tool that's just changed route on steroids, right? So it's a different level on what you're trying to do. N-Spawn in a way is very close to system D so it actually makes use a lot of system D functionality. You cannot really take N-Spawn and run it on something that's not system D. The goal of the Docker people is to be compatible with everything that ever existed on the sun. Yeah, it's a different thing. Docker is the focus is pretty much on having something like a vision controlled file system that you can hand out to people. But yeah, I mean, again, I do compare N-Spawn to LibVert LXE because it's very similar. It just has different properties. One easy to use, a trivially easy to use and the other one more like deployable. But Docker is a different story, right? Like Docker eventually will probably, at least on Fedora machines or so, but I don't really follow that closely but it will probably make use of LibVert LXE eventually. But yeah, I hope that Kaina answered the question. No. Yes, currently at least. I mean, we'll probably add a couple of more things because we want to, I mean, again, it's not necessarily what you want for testing, building, profiling and debugging. So it's not an out to do list way up but we probably will add a little bit of it. We'll probably never add the mismask rating and all kind of other stuff but we'll probably add support for VATH stuff simply because we want to play around with a couple of things and because they're currently problems with, so our model how we consider OS containers to look like from the inside is basically that they never get access to physical hardware and that most particularly results in the fact that UDEV, right? This device manager does not run in containers, right? SystemD is configured that way that will automatically skip execution of UDEV D in the containers. But if then software comes and wants to know what network interfaces are there and ask it via UDEV, it will say there are no devices, go away. And of course that breaks some network management software instead of containers. However, we of course need to make that work, right? Like for the VerdexE. So I would expect that soonishly we will have some support for VATH simply so that we can make sure that discovery of network devices works properly in containers. It's easier for us to test. I mean what people should understand is that testing things with EnSwan is super easy because you can actually GDP, you can S trace from the host into the container and there's nothing better than that if you're actually developing an init system which is normally really hard to debug because you can never, like the startup routine of the init system is incredibly hard to debug because you have nothing else running at that time and they could actually attach to it and supervise it. But you can if you actually use these containers. So for us again, the feature, like the focus of it is really debugging testing, providing building and for that we don't need so much the, except when we actually try to make things work like that. So we can spot the host inside the container. What are the environment variables that the host receives? It's pretty much empty I think but we can actually check that. Like if we, I mean I don't wanna lie so let's check that better. That's just, and let's pick an even different name. I must have been like, I think machine control because the kernel doesn't notify us about container ends. I think it must be about 16 TET machines now. So this is inside of the, like just a shell. And now if we do export or so then we, yeah well now we don't know really what's actually for us and what's not. So this is what's in it. It's a bit hard to read. It's a pass that we set. It's like, this is actually something like, like yeah I think I don't have any more time but this is basically it's an unofficial standard that people agreed, like a couple of container people agreed on how the container manager can inform the container about the fact that it's running inside of a container manager and which container manager that it is. So it's basically an environment variable that says the container equals the system the end spawn where, system the end spawn is basically the identifier. And we set the term because otherwise things would not be useful. I think this comes from the shell though. And yeah. Does that answer, so basically nothing. Was the exception of container and pass. I guess my time's over. So I would take one last question but if there is none then I would thank you very much. If you have any further question that's the one last question. It doesn't work. So this all integrates closely system D and it makes use of a lot of modern system D features. Like for it integrates really nicely with system D like for example you can take the system D end spawn and run it as a service like a service unit and then it can use resource management on the service unit to apply resource limits to the container and all these kind of integration that there is doesn't really make it possible to work outside of it. I mean I'm pretty sure people could port it but I will not support that and it's not a trivial amount of work. But yeah okay then the really, really last question. Now that the end spawn wouldn't it make more sense to have it integrated into system D itself? Like wouldn't I maybe want to run a service not in a container inside a different network? Oh you can do that. So what I mean this is not specific to end spawn now but for system services you can actually specify that there's a Boolean setting that you have on each individual service whether it runs in a private network or not. Right and if it runs in a private network that it's pretty much exact equivalent of the system D end spawn dash of private networks which basically means you only get a loop active as nothing else. It's actually incredibly useful feature because I mean now I'm completely off topic here but if you use socket activation which is a system D feature where you can basically spawn a service depending on network traffic coming in you can combine that with the private networking stuff which basically means that the only way how a container or a service that you start gets access to the network is via that socket activated socket that you passed in and nowhere else and nothing which is an awesome feature like super security fantastic but yeah I don't know it's a different topic I guess talking about that. So anyway this was really the last question if you have any further questions find me outside or talk to us in RC or write me email and thank you very much.