Now, should a teacher smile before Christmas? Now, is this a wise piece of advice for behavior management or is it an outdated myth?  And I wonder if the impact on not smiling or perhaps smiling from September might make a big difference to our young people. So is it fair to tell new teachers to hide their smiles? So this kind of sage advice we give new teachers, is it right to equate being stern with effective classroom management? We know behavior management is important. We need classrooms of warmth, not of cold detachment. We should also embrace empathy, not suppress it. And an unsmiling classroom in some respects for want of an analogy is a bit like a garden with no sunshine, all that potential remains unfulfilled. So a link in this video, you'll see some research, well-established research. There's nothing more stifling to the profession than a classroom devoid of smiles. It's astonishing how this myth still exists today.  So in the link in the video, and a piece of research in casting doubt on the old myth, research suggests that students respond positively to teachers who are warm, friendly, and approachable. And these qualities, now listen to this, these qualities lead to better teacher-student relationships and higher student satisfaction. More importantly, teachers who express positivity and care through verbal and non-verbal cues are perceived as more effective. Now, this might not be new for many experienced teachers, but it also challenges the traditional view that not smiling until Christmas is a load of baloney. And for experienced teachers, it advocates to keep smiling and for new teachers to smile from the start. It also highlights the importance of positive emotional communication in teaching, which we know is essential to nurture students' mental health and well-being. So smile is not just for Christmas, but every day to create a classroom that's more than just a learning space, but a place of warmth, connection, and mutual respect. So take a look in the video, look at the link in this video, and tell me what you think. Keep smiling and have a happy Christmas.


Before I had taken this class, I never considered even wildly the possibility that with a little help the workers could do it themselves. No one knows about it, and it's different. It's hard to explain what a cooperative is. It's something that we should do a lot more. I'm an econ major, just trying to fit it into the economics I was learning here. It's different from my other econ classes, like Marksman and Macro, Micro, more team-based. Everyone works just as hard and participates more, if anything, than they do in other classes. You give your voice, your voice is heard, your opinions are meaningful, which I feel like is kind of empowering. It'd be great if this could expand to all of the colleges, because it's a super interesting class. I think it just gives students incentives to want to work hard at a job. People work better when they're self-motivated, as opposed to taking orders. They know that their performance reflects onto the company and it reflects onto their pay as well. So I feel like when you have worker owners as opposed to one owner and workers, there's a lot more motivation. There's a lot more stride to do your best and try to make a company as best as you can. The same way that a more fuel-efficient car is going to aid the atmosphere, Cooperative Model is the only great other option for the financial sector. I think we won't really know what works and what doesn't until we go out there and test it out. Co-ops are awesome. That's probably been one of my favorite classes this semester.


Okay. Shall we start? Hi. I'm Mark Wielard. I currently work for Red Hat and they actually pay me to hack on SystemTab, which is fun. Some of you may know me from some of my Java work and if you were thinking, oh, Mark is going to talk about Java that's going to be a bit disappointing. There will be one example at the end using SystemTab with Java but all the rest is boring old-school languages. The talk itself is in two parts. One about SystemTab itself. Why do we need it? What can it do? Some examples. And the second part is also about SystemTab but what we need besides SystemTab to make it really useful. And what you could do with your programs to make SystemTab and observability on Knudlinix better. And then there will also be a little demonstration of indeed with Java how you make something like a Java runtime more observable with SystemTab. Well, it's not really a circle but kind of a circle. So why do we want to have something like SystemTab? If you are looking at what your system is doing there are a lot of nice tools. You can do profiling with just the top to see what running on the system using O profile or the new Perf tool. You can use some tracing tools as trace to trace your system calls, L trace for library tracing, the new F trace tool to trace kernel function calls. And of course if you then have figured out what is going on you can drop in to the debugger and really inspect what is going on. Kind of the problem is that these are all separate tools. And profiling tools often work system-wide while tracing tools work one application at a time. And with debugging you often just stop your program to inspect what is going on. And with SystemTab we wanted all the advantages of these programs without any of the disadvantages. Of course that also means with SystemTab you give up some things you can do with the other tools. But we hope that with SystemTab you have at least one tool that keeps you going for a while without having to switch between these things. So the tracing tools. What is nice about tracing tools is you can see what is happening while things are running. It is often faster and nicer than printf debugging because it is fully automatic printf debugging. You get a quick overview of your code flow. But the limitations are there of the specialized tools you either can trace system calls or you can trace a function calls or you can trace the kernel. And there is often limited filtering. It means that you quickly get too much information. And when you try to grab it out and your system is really busy you might actually end up changing the system you are observing. With profiling the nice thing is that it also runs while your system is running. And it samples and that means you get statistics about what is going on. And you often can see system wide what is going on. Whether it is in a library, in your kernel, in your program. But it is often limited to time sampling. It would be nice if we could sample every interesting event. And often it is a large data dump you profile for a while and then you have all this data which you then analyze after the fact. Although there are really nice after the fact analyzers for the various profiling tools. And with debugging we have the full context of what we are observing. Often you can access the variables, the parameters of the functions. You can look in memory, record search, you can get a back trace. You even have conditional break points so you could actually run a program and only stop it if some context is interesting. The limitation is again it stops the program under inspection. Which is nice if you want to sit down and look what is really going on. But it is not so nice if a problem only occurs on your production system and people are actually using that system. You rather just look at what is going on and not stop a server. And with debugging again it is one program at a time, not system wide. So with system tab we kind of made a mix. It is an obstructive, difficult word. Nonstop so you can look at your system if you don't hold your system or allow it to hold up your system too long. It should be system wide. You can monitor multiple events. But synchronous, this happens now, a function call, is exited and asynchronous based on time. And it is scriptable. So you can do in place filtering so you don't have to filter after the fact. And you can collect statistics in place. It is not super powerful but powerful enough. And what we wanted was to make all this safe. So enforce that it is nonstop and obtrusive, doesn't use too much memory. System tab will allow you to monitor things and then if it notices your monitoring takes too long, it let the system run. You can overwrite that but by default you are not allowed to do anything dangerous, use too much memory, use too much time, that kind of stuff. So how does it look? It is a pretty simple setup. Basically you have an event and you have a handler for that event. And that event can be something like a function entry for example in the kernel or it could be a specific statement in a process that get passed or it could be a timer that triggers the begin and end of a script is an event. We did that. So in the begin event you can set something up and in the end event you can create a report from all the statistics you collected. And there is this idea of aliases so you can add something to an alias multiple interesting events as if it is one. There will be an example of that. And a handler can do simple filtering on some conditionals in the context of the probe and then you can immediately say, oh, don't do that. I'm done. And there are simple control structures for each is for the, you have associate areas and statistical variables and you can loop over those. Of course, there are limits that see, oh, it did too many steps. It is limiting the whole system too much. And that is kind of the default. We always want that there is no noticeable impact on the system. And that is kind of the default unless you explicitly specify, yes, I want to use megabytes of memory and I know what I'm doing. Yes, sure. And there are three kinds of variables. So you have primitives, numbers, strings, you have associate, error, and statistical aggregates where you can store values and you can get the count, the sum, the average, the maximum, the minimum out of it. And of course, there are some helper functions for actually logging something, printing, getting the time, what is the current process, that kind of stuff. Well I showed some examples. This is the simplest, you invoke system tab as step. Either you give a script on the comment line or you have a script in a file and you can specify a target process if you want. Which actually means while this process is running, this script should run. And to see what kinds of events there are, you have the step minus L list and you can give it a pattern of events you want to see. And if you use minus capital L, you actually get all the context variables also. So I'll show some examples. And then I wanted to do it without any tricks and just have Fedora 12 installed. And Fedora 12 is really nice because for a couple of contexts, it really helps to have debug info available and the latest Fedora has a back port of the variable tracking assignment patches for the next GCC. So the debug info is really nice. It has system tab nicely integrated, test the latest kernel. I had to do some tricks. So I did install debug info beforehand because otherwise it will be a bit long. System tab will tell you if it needs specific debug info files. So I did that. I added myself to the stop dev group so I can actually, that means I've elevated privileges so I can actually see everything. There are a couple of different groups you can put users in so they can only use some scripts and there is a imperfect mode in which you can only inspect your own programs. And I actually installed the Python and Java packages from the raw height version because the version in Fedora 12 didn't have all the probes that I wanted to show. I believe that Java packages is actually going to be updated and next week it will be in Fedora 12. So let's see. Oh, well, so. So I'm going to show that you can do some simple tracing. You can probe a process in LS, show me all functions and just log the probe point where you place the probe. And then we actually, you can run it over in LS. Functions, okay. Function, right. Yeah, sorry, the resolution is a bit. But what you can see is that it actually put probes on all the functions. This is actually a function from an included file. And nice thing is this is also how you can actually specify the probe point. So you can also specify them as they would be found in the source files. And it can do that because the debug info files have all the knowledge of how the source, the binary maps back to the source files. And to show you can also have some, let's only print the probe function and show bits, parameters, parameters. So you can see that I actually wrote this out. How do you, okay, sorry. Right. So here you see that again in a hugely big thing. Sometimes it cannot find all the context. So for example, here the print color indicator doesn't actually know what the parameters are. But for most, for most functions it can actually see what arguments were given. To actually show a bit that you can also format it nicely because this is just too much output. Here we actually use a, we probe each function call. And then we print out, we indent, and then we print out, and then we print out, we add a bit of indent to the current thread. And on each return we decrease the indent and we show arrows if we're going into a function or comeback. If we probe and trace in this way, you can actually see, ha. Now I can show you that it's also system-wide. Because I forgot to actually give it a target process, but I can actually run LS here. Ha. And it saw the LS running on my system. The thread indent function also prints the number of milliseconds, the process name, and the thread ID. And here you can see that, well, you can use system-tap as a fancy L trace, but you can actually nicely format and filter all the results. And, no, let's skip that one for a minute because we're running out. This is all process-based, but you can also, I don't know if you can trace on probe. Cyscal open, show all the files that are being opened on the system at this time. So here we are doing system-wiped probing. We probe, whoa, okay. You can see that Gdome settings is opening prog mounts a lot. And Centmil opens prog load efforts every second. Interesting. What did I want to say? Oh, I just wanted to show that you can do system-wide tracing and get output. The problem here, of course, is you get quickly too much output who is really doing something. Screen is a bit small. But the idea of this script is that you have some globals which are actually associate arrays. And for every virtual file system read you, for each executable, you add the count of what they were reading and writing. And then you see a timer-based probe, which we actually don't use as a probe, but now as outputting all the data we collected.  Oh yeah, five seconds. So, yeah, luckily the thing happened what I wanted to show is that even now, but this is a very quiet system, you already see that by outputting all this you can already have step I'll be on top of what you're tracing. To help a bit with that kind of anomalies you can also use statistical variables where you every time put in the next number and what it will actually do if, since we don't actually print out this global step will, you know, you can also use statistical variables where you every time put in the next number and what it will actually do if, since we don't actually print out this global step will actually run this program and when we quit it, I hope, yes, it actually prints out for everything at monitors. The clock at blood, it did two reads, the minimum read of a thousand bytes, the maximum is the same, the sum of course then two thousand on average it did a read of a thousand bytes. Okay, so what I showed is with system tap you can do fancy scripting of all these events at least, but we need something to observe and for that we need events that we want to observe and we need to have some context and most of what I showed was very low level and I think we nicely covered the low level stuff. You can have timers, you can monitor processes, signals, function calls, you can monitor in the kernel and we're working on data watches that you can actually watch, data being changed and we hope to have events for the performance counters in your CPUs and especially for, especially for the C, C++ based programs, the debugging was pretty good these days, so GC provides us a lot of context. The trick is a bit to get all these techniques also used by other tools. We actually hope that all the tracing profiling and debugging tools also use some of what we're using because then you get more people hacking on more of these low level events, but what we really would like is more high level events. So we have two systems for that. So you can write depth sets, that's basically the aliases. So we have a depth set for the virtual file system and it defines probes and it aliases those to the correct kernel functions and it knows which arguments contain what and then sets up the context for you. And that's really nice, but what we would really like is that kind of context, not that we go through the kernel or a program or something you want to observe and then somebody goes through all the source code, but we would like them in the source code where the developers write their code and they say this might be an interesting point to observe. This is an event and here's some context for an event that might be interesting if you want to know what my program is doing. And this is where you can help. You write programs, so. In the kernel, we're making nice progress. There are actually two solutions. Well, to be honest, the kernel markers are being deprecated and the trace points are the new, the new, the new, the new, the way to do it. System tab can observe them both. And of course there are a lot of tab sets already for the kernel. For user space, we're trying to do a trick. There's detrace, which is kind of similar in spirit to a system tab. And fortunately, it's not really suitable for new Linux systems. Well, that's basically just because the license is completely incompatible in, oh well. But they had a great idea. They have user static dynamic probes, which is markers which you put in your program to indicate here is something interesting. Actually, we had the same idea and we did it slightly different and then we thought, well, that is actually not nice because then we make people choose, do you support detrace or do you support system tab? So we're actually discursing people from using the step probe indicators and encourage people to put detrace probe markers in their source code. And the implementation is completely different. But if you compile your program on a Slar system, it will make those events visible to detrace. And if you compile on a new Linux system, system tab will see them. And we even provide a fake detrace script that kind of does the same things in your build. So there are actually a couple of programs like Postgres, which already have those. And if you configure with enable detrace, those pro points get put in and you can see them through system tab. Where should you put the data?  What are interesting events? And most of the time that is when you would add a verbose flag and say, this is happening now. In those cases, it's often nice to also have a static pro point there because with a verbose flag or if you have a verbose flag if you use logging, you are controlling what the user sees. And often they know better. They know they want to see something in one run or on the whole system and they only need some context. One interesting thing was when we implemented system tab itself, we also had a problem. So, of course, we have minus fee and it parses the scripts and compiles the scripts and so it has a couple of parses. And I was actually adding the verbose output. Oh, I actually want to know how much memory this is using. Oh, I print out the memory. And the timings. And then suddenly it was, wait, but I have a better tool for this. Because if you have these pro points, then we actually provide functions like the memory the process is using at that time or the time and task spent. And so, it's a little bit more we actually provide the actual values, not just the strings. So, people don't have to parse out your minus verbose output. And what was funny was that we added probes to each pass. So, you can see, stop, start phase one, the compile phase. And you can see, it entered phase. And you can see it start and stop the parsing phase. And what is interesting is that now we can actually run this verbose output system-wide. We just run our test suit. And because we have aggregates, we have statistics, you can actually run the test suit, have a little script, monitor all the stop pauses, and then say, on average, pass three takes the most memory. And the argument at that time was this particular script. Am I going to fast? Well, no. I'm on time. Okay. I'm going. A little too fast. That just means you get to ask more questions. So, another way to use this is to make things that aren't C or C++ or the kernel or like scripting languages or a language runtime more visible. Actually, now I have time for a little story. It was kind of interesting because we really wanted these detrace probes to be completely compatible. So, people could just put those probes in their programs and detrace would see it and system that would see it and the whole world would be happy. What was funny was that then we tried to see how Python was instrumented. And one of the sad things is that detrace is actually forked in an Apple macOS version of detrace and a Sun, now oracle, I guess, or a Solaris detrace. And neither of them actually submitted their pro points upstream. So, we actually tried very hard to be compatible and now we might actually submit our version upstream and then they still look slightly different. It's not a big difference, but the argument order and the precise pro point names are different on macOS and on Slars, which is kind of silly. Anyway, the nice thing in the Python case was that it was already kind of done. We just had to pick either the Slars or the Apple version. And indeed when you compile Python this way you get a couple of probes, but the function entry and the function return are the most interesting ones. Again, we do some thread indenting to show the flow. And the argument names are not that nice, but I believe argument two is the function name, argument one is the file name, and argument three is the source line. Yeah, that must be it. Well, we can just run it. But again, that doesn't really matter. So, we can just run it and, yep, I didn't even do anything in Python yet. But as you can see, now you can actually see inside your Python program. You can actually see what functions are entered when, where they were defined in the source code. And so, one thing we don't have for Python, but we do have for Java is back traces, that's sometimes a bit more work. And then, again, we can run it. But this means that you can now kind of instrument and look into your Python program as if it was a normal C program. Well, at least according to system data. I probably should show that we can do the same with Java programs now. Java was also nice because at least in the case of hotspot, which was the Sun VM, which is now in the GPL, they actually spent a lot of time to instrument all the interesting parts. So, you can now see when your Java program starts to garbage collect or when it loads a class or when it unloads a class loader. And the nice thing in that case is that you can also combine it with your other probe. So, you can see, hey, Ben was some swapping out of memory going on in the kernel does that correspond to my garbage collection. And the nice thing is that maybe, I just do one example. Yeah. So, in this case, for example, what's nice is that since, since we're in a system that can look through the whole stack, you can get an interesting, an interesting backtrace where you actually see. So, what I actually did was when the GNI Java native interface get argument length is called give me a full backtrace of this point. And what you can see is that it can not only show Java functions, method calls, but it also knows whether it's jitted. Well, this was just an hello world program. So, probably nothing is compiled, but it knows whether it is interpreted. It can see some parts of the, everything is interpreted. That's not fun. Otherwise, it could see some of the compiler work, the actual hotspot methods, like it at the start, where you can see the setup, the setup, till you actually hit your Java main program. Okay. So, we take some questions. Wait. I must at least give you these two URLs. Oh, my examples were a bit simple because I didn't have that much time to explain everything, but there's a really nice examples page and there is a beginner's guide, which explains a lot about the examples. And there's also a wiki where you can learn how to precisely put user space probes in your application. Yes. Can we use this or? Yeah, can you tell us a bit more about the performance impact of doing a system tap on kernel calls, just calls? So, we try to keep the overhead really low. I'm not sure what our thresholds precisely are, but every probe is executed in place. So, there are no context switches. So, in principle, all the logging is just dumped in a buffer, which is read later. So, the impact is pretty small for most things. So, is there the ability to define a priority in terms of repassation of resources between the monitoring activity and the production activity? Sorry. Is there the ability? If you take the example of SNMP protocol, SNMP protocol on routers and things like this is always defined as the lowest priority. And is there the ability to define a priority in terms of the right execution of the things on the system and the monitoring activity? I haven't really thought about it. SNMP is, that was what you were asking SNMP. It's a higher level thing. This is much more lower level. Any thoughts on using system taps to determine memory usage of kernel modules? So, what's this kernel module using? Why is it chewing up that much memory? You can partly do that. There are actually trace points on K-Malek, for example. So, you could trace that and look at the color of K-Malek and map it to a module. I'm not sure. There might be something like that in the examples. Probably not precisely for modules, but there is something for how much K-Malek is called from where. How much of the debug info is system tap understanding? For example, how can it print a struct? Yes. It, you can, system taps sees the debug info for the struct and you can actually dereference and get the fields of a struct. Maybe it's a little bit of a silly question, but would it be possible to implement this for Windows? I don't know. Because Windows has, of course, a lot of tracing possibilities and it's always nice to have similar interfaces. Yeah. Let's say it has been 10 years since I used Windows, so I don't know. Sorry. Thank you. Is there a library, is there a library with a programmatic interface to it? So, for example, could Python look at the result, look at the profiling information of its own probes and expose that within Python? No. Is that being considered or is that interesting? Well, maybe something like that could be done. I believe Ruby has something like that. Has there been any discussion of adding anything like that? No, not yet. To be honest, that was one trick. The Python support was just done. Not necessarily Python, but is there an in... Hi. Is there any specific support for monitoring multiple systems and looking at relationships between what different machines are doing and how they're causing faults on each other? Sorry. I didn't completely understand. You mean monitoring other systems than the current running one? Yeah. Or monitoring distributed systems running on multiple machines, yeah. Yeah. We have a client server set up, so you could kind of spawn scripts on other machines, but it's not that much worked out yet.


Hello everyone and welcome to this mini-series on modeling developmental systems small and short and brief and simple explanation of why we need to model to understand developmental processes. I have about two hours to introduce a topic that takes several semesters of lectures usually so what we're doing here is clearly vision impossible. It's going to be very condensed, it's going to be very superficial, it's going to be very broad. So fasten your seat belt for a little introduction what I want you to sort of get out of this is not expertise in how to model a developmental process, a developmental system. But I want to sort of instill in you this sort of understanding why it's a good thing to model. So as an experimentalist as a maybe bioinformatician so that you can go and find sort of the colleagues in your department that can do the modeling for you can understand what the purpose of modeling is what it can and what it cannot do. So it's going to stay at this very sort of conceptual level high level, and I'm trying not to be very technical. The strategy is to sort of introduce the general purpose of modeling in this first lecture, and then provide two examples of what I think a really successful and illustrative cases of where modeling was used to do something that you couldn't achieve with sort of molecular and genetic experimental work alone. So this lecture is going to be busy with the question. Why should anyone model of course, nowadays it's good to have a model in your paper because that increases the likelihood of it getting accepted by editors but that's not the point and often these models that are just added on top of some experimental work. Anything to the understanding of the developmental process under study. So basically what I want you to understand here is when do we need to model and what does that get you that you cannot get with experiments alone so we do not just want to have a model because it's fancy. We want to model only when it's necessary and when it's beneficial and whether it contributes to some sort of explanation or understanding of a developmental process. The way I would like to frame it because I am coming from the field of evolutionary developmental biology, I would like to see development as the sort of process that mediates between the genotype and the phenotype. So in my head I contextualize development in terms of the genotype phenotype map, which is what maps variation at the genetic level to phenotypic variation, which is ultimately what population processes such as selection work on this is where the variation occurred. Variant phenotypes that are being selected. And of course, this is just a sort of a thinking help. It's not very realistic. In reality, animals are actually phenotype to phenotype maps right so you go from one generation to another generation that resemble each other, but it's helpful nonetheless. If you sort of consider that it's a cartoon and also that there's some additional factors here. You have an organismic and external environment that contributes to tissue level factors environmental triggers to contribute to this mapping. It's not a closed mapping this sense. And also you will notice that in the drawing I am showing you here several different genotypes sometimes map for the same phenotype here. And that is of course robustness, canonization or resilience of development, while sometimes the same genotype can map to different phenotype under different environmental conditions. And this is called developmental plasticity. So there's a whole lot that goes into this very simple picture, but it's, it's nevertheless good to structure your thought this is the main task we want to understand how genetic variation maps onto phenotypic variation. The structure of this highly complex and degenerate map determines the variational properties and hence the evolvability of the development system. This is my own personal interest, but I would like to make an argument not only that modeling is important to understand development, but also the comparative analysis of developmental processes will come to that later. What's really important here is that you can interpret the mathematical structure of a map in two very different ways. So this sort of mapping here, it's also called a morphism in mathematics, could be a correlation. So we could just be measuring genotypic variation and correlated to phenotypic variation. This is what, for example, quantitative genetics does. But development, of course, looks at this map in a clearly different way, a more mechanistic way. We're going to try and understand what it means to explain this map in a mechanistic sense. And so what is really hidden here is not a correlation, but sort of a causal process. Okay, so we want, we don't want just correlational explanations. But we want a causal mechanistic explanation of this map. And then we need to realize that what's hidden behind this very abstract formulation is a process, of course, very beautifully illustrated by Conrad Howe Waddington's epigenetic landscape. And I'm showing you a rather less well known example, an illustration of his landscape here, where you can see two little X shaped sort of shapes here and then different valleys that lead to different tissue types, or even regionalizations in the embryo. So you can build a thorax, a wing, different kinds of leg parts, antennae, mouth. And what is represented in this landscape is a trajectory. Okay, so this, this sort of visual metaphor that Waddington is presenting here is not an exact model. It remains at a metaphorical level. It's very powerful exactly because of that. The visualization is very compelling. And also, the formulation is sufficiently vague, so you can actually adopt this picture to many, many different contexts. Just think about it. What are the different axes here? So this sort of depth axis here is time, of course, time flows downward. But then it gets more difficult if you think about the height, or sort of this X axis here, what is the difference between those different fates.  Why are they separate from the landscape itself? What do they represent? Do they represent a cell, a tissue, an organism? It's not clear. So this is both the power and the limitation. The genius of Waddington was to not explain exactly what he meant by this picture. So everybody can adopt it to its, their own purposes. But on the other hand, this is not a precise model of development. What it tells us and what the power of a metaphor like this is that is what we need to understand is not a thing. Okay, it's a process and Waddington called his developmental processes the process of rolling down the valley. He called it a creode. This is a word that's no longer in use. So we will call it a developmental trajectory. We need to explain the shape and the dynamics of this sort of trajectory here. That is our task. And this is where modeling becomes crucially important. So let's, let's have a sort of a historical look at how do we explain these trajectories historically. And we could arbitrarily start maybe in the 1970s when people were starting to describe developmental genes and in particular they were discovering Hawks genes and found out that they're active in all animals. They're active in the specification of whole body regions. And if you actually mutate one of these Hawks genes, you switch the identity of one body part into the identity of another. So the first view, the first type of explanation for these trajectories is the genes act as sort of switches that put you in one of these valleys or another. So development is just sort of a sequence of switches, one switch after the other, and what we're called selector genes like the Hawks genes were executing those switches between the valleys. Okay, that's, that's fair enough for the sort of knowledge at the time. So what I'm showing you here is a beautiful study by Michaelis Averhof and Michael Aiken on the identity of different arthropoc segments and how they correspond to the rearrangement of different Hawks genes. But it leaves many, many things, many answers open. For example, what, so you now know how you switch from one valley to the other, but the shape, the exact shape of each of the valleys is not clear. So let's move forward and develop this, this sort of type of explanation a little for further. And throughout this lecture, I'm going to talk a lot about one of my favorite animals here. This is a vinegar fly, not a fruit fly, fruit flies, parasites, fruit, tephritis, flies like the MedFly in California. This is Drosophila melanogaster, of course, one of the most commonly used systems. So this lecture is aimed at sort of early stage PhD students. So you're probably familiar with the animal we're going to use the segmentation gene system that creates the beautiful segmented body plan. Visible here in California. And by the fact that different appendages are attached to different thoracic segments here. We're going to look at that as our example system. So here is the segmentation gene system of Drosophila melanogaster, very brief sort of just reminder. It's active during the blastoderm stage of development during the first three hours of development, when the embryo is a syncytium. There are nuclear divisions, but there are no membranes yet between the different nuclei, and the nuclei migrate from the center of the embryo to the periphery where they form the blastoderm, which is visible beautifully here. The advantage of this embryo is obviously that it's developing very fast. We're looking at here about one and a half hours of developmental time, and also there is no growth or sort of cellular rearrangement involved. So what's happening is that you can have transcription factors expressed that diffuse through the embryo and directly regulate each other's expression in this spatial temporal context. It's very simple. And this is great to study pattern formation because you can focus when you have a mutant of one of these factors, segmentation genes. The only effect it has before gastrolation is that it affects the expression of other genes, no other morphological or any other. So a very simple developmental system, that's its basic power. And you have this cascade of maternal coordinate genes, such as bigwig, which is shown here, RNA localized at the interior of the embryo, then the protein is translated and diffuses through the embryo. You can see the single nuclei here and the different concentrations of this transcription factor in the nuclei. And these maternal coordinate genes activate transcription factors that activate at a first step. The gap genes, hunchback, crudable, shown here in the middle of the embryo, canerbs, giant tailors, and huckabine, and these genes are expressed in these sort of broad overlapping domains. Together, the maternal coordinate genes and the gap genes regulate the peril genes, the first sort of periodic expression pattern here, seven stripes, even skip dots, skip hairy, run fuchsia terrazu, and paired are examples of peril genes. And all of those together finally regulate the expression of segment polarity genes, in particular, engrailed and wingless, which mutually inhibit each other and form these sort of parasygmental boundaries, which are a pre-pattern, a molecular pre-pattern that reflects the formation of the segments later on. And you can see this is already after gastrolation, the embryo has wrapped around the posterior. Now here, the interior is here, and you get 14 stripes in this molecular pre-pattern. This is a classic, of course, system, and we know a lot about the genes, their interactions, and also sort of the principle by which it works.  So big weight is a classical morphogen. So it was sort of the discovery of big weight and its expression pattern was a triumph because it confirmed a model that was formulated by Lewis Wolpert much earlier in 1968 and 1969, in which he said he wanted. So Wolpert's idea was to refocus the sort of attention of developmental biologists from temporal gene regulation, which came from Jacoby's and Mano's paradigmatic example of the lack opera. Wolpert wanted to refocus our attention back to spatial, problems of spatial pattern generation. And what he did is he assumed a very simple sort of situation in which you have a tissue, there's a source of a substance called morphogen, a morphogen on one end of the tissue and a sink at the other end. And if you have no degradation in between what you get and no production of the morphogen in between what you get is a linear grade. So this sort of linearly decreasing slope of morphogen concentration across the tissue. You can then imagine. So this is sort of the first step development involved with model is fundamentally seen as a two step process in this first step. The cells in the tissue can sense different concentration thresholds. Here is one here is one in that morphogen gradient, and they will then in a second step, the differentiation step switch on different target genes which are represented by the different colors blue, white, and red here. And that forms, of course, the French flag what is very important in this very simple. This is a model of development. It's a static model, but it's a cartoon model, but it's a very strong tool, thinking tool that influenced generations of developmental biologists who are looking to try and identify different morphogens and different developmental systems based on the prediction that you should be finding those. What's important here in this very simple model morphogen thresholds correspond exactly to where the target domain boundaries will lie in the tissue later on. And in this way the morphogen gradient can be said to encode positional information, especially the thresholds here. By reading the concentration of the morphogen, the cell somehow knows where it is in the tissue. So the gradient contains information for the cell to read and interpret by switching on differentiation genes, target genes. The French flag is a classic sort of model of spatial pattern formation and the segmentation gene network with its maternal gradients and the gap genes that were switched on later on was sort of a paradigmatic experimental confirmation of this classical model. Of course, there's much more to the segmentation gene network and luckily we have this absolutely beautiful Nobel Prize winning work by Ms. Lime Bollhardt and Eric Grishaus, who performed the saturation mutagenesis screen, and then classified the resulting mutants into these different classes that we saw before, but also examined every single sort of mutual interactions between different genes. So we get a very complicated network that not only involves these sort of hierarchical interactions, but also cross regulatory interactions among gap genes, for example, and even auto regulatory interactions of the segmentation genes themselves. So we get a rather complicated network that creates a pattern. And this of course is already a big step forward from this sort of simple explanation of genes as switches. Okay, so we could call this genetic mechanism version 2.0, where you are saying we have now a genetic regulatory network or GRN very popular now. These genes they interact together and what's important are the interactions that determine the sort of pattern and the dynamics of the process. This was famously first suggested that development works like this by Britain and Davidson in 1969 and this absolutely fantastic pioneering science paper I recommend you read it. And this is one of the figures where they tell us that development is basically to be explained as a sort of an electric or electronic circuit. So this is a completely different type of explanation where the focus is no longer on the activity of single genes, but an activity that comes out of the organized sort of interactions between different fact. So, but still, all of this is based on genetics only. So what you do is you perturb healthy system, you check what's going wrong, and then you try to sort of read out what the healthy system is supposed to be doing. So this is a reductionist approach. You're trying to decompose the system into its component factors. So you try to identify the different genes, come up with a parts list of different genes, and then interactions between them to reconstruct the network. This is a massively sort of successful research approach. The history of genetics is 100 years old now. And, well, if you go back to Mendel even more and has been absolutely, fantastically successful, but it has its limitations. So let's think about those limitations. One of them is that many genetic perturbations are lethal. So they're lethal in a way that's not very interesting. Drosophila is a special case. The embryo doesn't grow, while the segmentation process occurs in the flower beetle, triboleum, the embryo elongates while it's segmenting, and most of the mutations, or a lot of the mutations of segmentation genes simply have a growth effect. So if the embryo doesn't elongate, there is no segmentation, but that's not very interesting for reconstructing the network that creates the pattern, because you simply have no pattern, not very informative. So we need informative mutants that have a specific effect on the process that you're studying. But many mutations, on the other hand, making things worse, do not have a phenotype, especially bad invertebrates with their genome duplications. So about a 30% at least of the genes in mice do not show any detectable phenotype at all. But to assume that these genes don't do anything, that's premature. We don't know that. There's a lot of redundancy built into the system, and genetics really hits a limit when trying to decompose such redundant systems. Furthermore, many interesting developmental phenomena are not associated with any specific mutation. In the second example that I'll show you, I will have a specific case point to make the point. So it has been a little bit lost on us, not the classical embryologists, that not all phenomena we want to explain in development are genetically determined. Okay, so we need to come back to that. Another really big problem is that if you've already gathered some experience in a lab, then you know that it is really difficult to interpret mutant expression patterns. Again, an example here from the gap genes in Drosophila. Let's take a wild type embryo, here's my simple depiction of it and the expression pattern of the gap gene Kruple in the middle. Remember that picture that I showed you earlier. Kruple interacts with another gap gene called hunchback, which is both maternally and zygotically expressed, which makes the genetics really complicated. And so if you mutate both the maternal and the zygotic contribution of hunchback you will see that Kruple is moving into the interior of the embryo here. So it's expanding into the area where hunchback used to be expressed. I should say it's expressed in the interior of the embryo. So how do you interpret this? Okay, so you can do the reverse experiment. You can say, okay, I overexpressed hunchback using a heat shock promoter. So now hunchback is everywhere. And in this case you can see compared to the wild type, the interior boundary of Kruple has been pushed back towards the posterior of the embryo. How would you interpret this? You would say, okay, hunchback is gone, more Kruple in the interior, hunchback is overexpressed, less Kruple in the interior, hunchback must be a repressor of Kruple. However, at the same time, in the hunchback mutant Kruple gets a lot weaker. You can see that even with qualitative assays. And also if you overexpress hunchback, Kruple expands very much to the posterior where hunchback didn't used to be. Okay, so this indicates that hunchback at the same time as being a repressor is also an activator. Okay, what's going on? There are two possibilities we could imagine. One is that hunchback acts as a repressor at certain concentrations, but maybe as an activator at different concentrations. So interpreting this, people have said hunchback acts as a repressor at high concentrations, as an activator at low concentrations. Could be. But it could also be that we've forgotten the third factor. There is another transcription factor encoded by the gap chain Knurps, which is expressed just posterior Kruple. And it is a repressor of Kruple. And at the same time, strongly repressed by hunchback. You can see if hunchback is gone, Knurps expands all the way through the area where Kruple is expressed. Since Knurps represses Kruple, hunchback is gone, you derepress a repressor, you get an activation. Double negative is a positive interaction. And consistent with this, if you overexpress hunchback, there's no Knurps, which explains the posterior expansion of Kruple in December. So basically the activation could be indirect through the repression of a repressor. There is no way you can do genetics and molecular biology and get around this problem of not knowing exactly whether an interactionist, director or not. Molecular asses will show you whether Kruple, Knurps, and hunchback bind to each other's binding regions, but they won't tell you whether they're activating or repressing. Okay, so to piece a whole system together again is very complicated, especially if you consider that there's more factors here. Another gap gene, giant and terminal gap genes that are also involved in a regulation of these genes. So the situation is much more complicated, even in this very simple system. The last problem with genetics is once you've sort of worked out doing a lot of genetics and molecular biology, you've worked out an entire network. So what I'm showing you here is a bit of a dated sort of picture in 2010, but it nevertheless gets the point across. It's a mapping all the interactions between maternal coordinate genes. It's just a great coddle. And then gap genes, giant Kruple Knurps, hunchback here, and other factors and you can see it's very complicated. Basically, you've done all the work, you've drawn the summary diagram of a network, and now you're supposed to tell me how this works. Okay, it's very, very difficult to understand what this network actually does. It's much easier to reconstruct it to get to this point than it is to understand what this does. This is the grand challenge. So what we're having here is not an explanation in this sense, but the starting point, a challenge to understand what such a network is actually doing. These are all sort of limitations that are intrinsic to any reductionist approach. You're decomposing the system, you're localizing function, but the task is now to sort of put all this together again and find out what it actually does. And one of my favorite philosophers of science, Gandalf from the Lord of the Rings, has put this beautifully to the point. He that breaks a thing to find out what it is has left the path of wisdom. This is the Saruman and where reductionism leads can be seen in this beautiful illustration of Isengard flooded by the ends. It does not end well. So we cannot stop there by just taking everything apart. We do not understand anything. That's the take home message here. So to put it slightly differently, this is how we understood sea urgent development in 1967. You have a beautiful sort of series of stages. We have an understanding of certain cytoplasmic determinants that are localized and that lead to the segregation of different lineages, such as the micro mirrors here in red that will go and ingress into the embryo during gastrulation and then form the skeleton of the embryo. Beautiful. And it hatches here. So this is a sort of a descriptive understanding of development with a bit of a mechanistic understanding that there is something like these determinants that differentiates different areas of the embryo. This, of course, is how we understand sea urgent development. This is a picture that I downloaded in 2016, but it hasn't changed much since then. This is how we understand sea urgent development today. And you could argue that, you know, I mean, you have a gene regulatory network, the different boxes here represent different tissues, different time points, and you have a lot of interactions. You can argue that this isn't, in a sense, progress, right? Well, we've abstracted away a lot of things like the geometry, the cellular interactions, the sort of, you know, complicated behavior of those micro mirrors ingressing, crawling into the inner, the seal of the embryo. And it's all gone the tissue geometry, this sort of very proactive behavior of the cells, all of that is gone out abstracted idealized away out of this model. So not only have we gained a lot of genetic knowledge, but we have lost some context. And how can we put this together again? So I would say if you do this, this is not system spellage. And so this, this sort of advanced from the action of single genes to networks hasn't really overcome reductionism at all. What it is is doing reductionism at a genome-wide scale.  And I would call this, to quote a dear colleague of mine, Janne Hofmeyer, I would call this system-wide biology, not systems biology. The difference between that and true systems biology is simple. Systems biology worries about what this network does. But if you go to any sort of systems biology meeting, often what you get is you get a lot of these sort of network graphs thrown at you, they're called hairball graphs, just like something that your cat would puke up after eating a bird. And people are impressed because they show, you know, the system is complex, you've done a lot of work to draw this graph, fantastic. But it doesn't really tell you what the system does. And to do that, that's a really grand challenge. So let's take a very, very, very, very simple network. Three genes indicated by different color dots here and interactions between them. All of these genes are constitutively activated, and they are transcription factors that repress each other in the way that's depicted here. So you have these sort of mutual repressive interactions. And it has a funny name, this little circuit, it's called an AC-DC circuit. And it was named like that by James Briscoe and his group when they discovered and described the circuit in 2012, 2012. And it's called AC-DC because it does both positive and negative feedback. So just like the current AC-DC, it does sort of steady switch between the green and the red gene. And if these interactions here are very strong, you have a double negative interaction. Remember, double negative is a positive. So this is a positive feedback group. And because these two factors hate each other, you get an expression of either the green one or the red one, but never both at the same time. So it's like a switch, a toggle switch. While this sort of second feedback group here between the three genes, three negative interactions that's a negative feedback group, they can create oscillations just like you have AC or DC current in an electric circuit. So a very simple circuit, but it can show many, many different behaviors. So it can switch, it can oscillate. So what you see here is the situation of the switch. Interestingly, it can have a switch that's not stable, it goes back or back and forth. This is called a relaxation oscillation. It can just create, if the interactions in the negative feedback group are stronger, it can create oscillations that are damped, that are stopping after a while, or that are sustained or stable oscillations. So you have at least four different qualitatively different behaviors that come out of the simple system. And I haven't even mentioned the most common and most typically absurd behavior, and that is that all genes are just dying off and nothing happens at all. Okay, so five, in reality, this simple circuit can exhibit five qualitatively different, what are called behavioral regimes, completely qualitatively different types of behavior. And so imagine that if you want to understand this huge Eric Davidson network about the sea urgent, you need to understand how this sort of behavior comes about, which is difficult for even such a small circuit. So this figuring out what the circuit, what the system does is is true systems biology in my opinion. So, to wrap up this lecture, we've come to a place where we have to introduce mechanism 3.0 if you want to have a causal a mechanistic explanation of a developmental process, you need to do modeling. Surprising. Okay. And here is why this is work by two philosophers Bill Bechtel and Adele Abrams Abrahamson and very, very interesting work. And it's about how do we explain things in biology. Okay, and so they say we need to take into account the parts and operations of the mechanisms of the parts or the genes, the operations are their interactions. They're spatial organization. Of course, if you have an embryo like the Drosophila embryo, you have to take into account where the interactions are happening. And the pattern of change over time in properties of its parts and operations. That's very important. So the interactions, the concentration of the different components changes over time. And so the interactions will change over time and you need to track that as well. And that results in the orchestrated behavior of the mechanism. So how do you track those spatial temporal interactions? You need mathematical modeling and dynamical systems theory for this. So not just any mathematical model, but you need a model that tracks all these different interactions happening at the same time in different locations at different times.  As soon as the system is above a certain complexity. So you don't need to model if the system is very simple. But in the case of the gap genes here, we've seen that it's very hard to track all the interactions at the same time. And they say such modeling provides understanding beyond that which is available from identifying the parts, operations and organization of the mechanism. So deep composition and mentally rehearsing its function.  And you need computational or mathematical modeling to help you. So here's a basic recipe for what they call dynamic mechanistic explanation. You need to do all the decomposition. You need first the parts and their interactions. You need to draw this hairball. You need to reconstruct that. But, and that's very important. That's just the first step after decomposing the system you need to re compose it again. So you need dynamical systems modeling, which is not in itself a sort of a causal mechanistic explanation a model without evidence is not an explanation, but a model combined in this way with mechanistic decomposition amounts to an explanation and mechanistic explanation of the system. This is the last point I'm going to make so that the sort of, you know, reductionist perturbation approach like genetics will never give you sufficient explanation so you will never be sure whether the parts that you've assembled are sufficient to explain the behavior of the system. It's not necessary. You've knocked them out in a mutagenesis screen. You've targeted them by reversing genetics, whatever you do, you know they're necessary, but they're not sufficient. You need a mathematical model to get a sufficient explanation. So, if you want to make an explanation of a developmental process counterintuitively, you not only need to let Humpty Dumpty fall off the wall, but you need and that's the much more difficult task to put Humpty Dumpty together again and see if the interactions actually do what you think they're doing. To summarize this part of the lecture, I told you that development provides a mapping between genotype and phenotype. Developmental processes can be represented by interacting dynamic regulatory networks. That's how we like to represent them. The components and interactions represented by the network implement a developmental mechanism. So different components, their activities and their organized behavior. And these mechanisms are too complex for us to decipher just by mental simulation or rehearsal and we need computer models to understand. Very simple. I'll provide two examples in the next two lectures that illustrate this point. So if you have any questions, comments, please email and you can follow me on Twitter at this Twitter tag as well. Okay, I'll see you for the next lecture. Bye bye.