Ulfaction is brought about by the receptors which are present in the olfactory epithelium and this olfactory epithelium is present at the roof of the nasal cavity and has a surface area of approximately 10 centimetre square. Now since this is present at the roof of the nasal cavity the odor answer that is the chemicals which are present in the air need to be sniffed to reach to this olfactory epithelium. Now this olfactory epithelium has special type of neurons whose epithelium has a receptors for these odorants and these neurons are known as olfactory sensory neurons. So let us see what are the different types of cells which are present in this olfactory epithelium. So this diagram here shows the olfactory epithelium right this is the olfactory epithelium and if we see the type of cells here this cell is the olfactory sensory neuron which is basically a bipolar neuron. So see the cell body of this neuron is present in the olfactory epithelium this is the cell body and the dendrite is projecting below this epithelium and here it ends in a olfactory knob okay olfactory knob and from this olfactory knob there are celia which project out of this olfactory epithelium and this part below the olfactory epithelium is mucus okay so the celia are projecting into the mucus below the olfactory epithelium so that is one type of cell. Other types of cells are the supporting cells so here this is the supporting cell also known as sustentacular cell then there is stem cell so here this is stem cell and this is responsible for proliferation and formation of these new olfactory sensory neurons so these are one type of neurons which regenerate actually their life span is approximately one to two months and when they die their regeneration occurs by the proliferation and differentiation of these stem cells. Then finally we also have bowman's glands so these are bowman's glands which are present in the olfactory epithelium and they are responsible for secreting this mucus which is lining this olfactory epithelium right now the receptors for this odorance is present on the celia of these olfactory sensory neuron and the odorants which are there need to cross this mucus and reach to the receptor which is present on the celia and that is brought about by certain proteins known as odorant binding proteins which are present in this mucus so these odorant binding proteins they kind of bind the odorants and concentrate it within the mucus and they can actually cross the mucus and reach to the celia so for the odorants to actually enter into the mucus and bind to the odorant binding proteins and reach to the mucus these odorants have certain characteristics first I have already told you that they need to be sniffed right then they should be partly water soluble right and they should be partly lipid soluble as well so if they are only lipid soluble then they will not be able to reach the celia the receptor okay so they should have some water solubility as well and some lipid solubility as well fine now let us see that how these odorants are able to stimulate these receptors and cause a generation of the action potential see the resting membrane potential of these neurons is minus 55 millivolt and at this resting membrane potential there is some action potentials are already there it is not that it is completely silent some action potential is there but it is very slow like there can be one action potential in 20 seconds right but it is not like completely silent now when the odorants bind to the receptor and sensory transduction takes place that is a conversion of chemical energy of the odorant to the electrical energy there will be change in the membrane potential and once this membrane potential changes to minus 30 millivolt that is the threshold and at that time there will be generation of lot of action potential maybe approximately 20 action potentials per second okay so how is it that this chemical energy of odorants is converted to electrical energy that is the change in the potential known as sensory transduction let us see the mechanism so the odorant binds on a G protein coupled receptor present on the cilia so this membrane is showing the ciliary membrane and there is presence of G protein coupled receptor which can bind with the odorant G protein coupled receptor as you might be aware that it has three units G alpha G beta and G gamma three units are there which are attached to the receptor and as the odorant binds to the receptor this G alpha unit gets separated from the other two G beta and G gamma unit and it goes and activates the enzyme adenylate cyclist which is also present on the membrane nearby this G protein coupled receptor once this enzyme is activated it converts ATP to a second messenger CAMP and this CAMP goes and causes the opening of a channel which is permeable to both sodium and calcium so there will be entry of sodium and calcium within the cell and this leads to depolarization okay so that is a simple method of sensory transduction that is via G protein coupled receptor and once the entry of sodium and calcium is such that it causes a change in potential to the threshold that is the minus 30 millivolt there will be generation of lot of action potentials now how many smell sensations can we actually perceive so actually before there was a concept of primary sensations of smell primary sensations of a smell like we see in color vision that there is red blue green primary sensation then in taste also we say that there are five primary taste sensations similarly in olfaction before it used to be said that we have seven primary smell sensations but now this concept is old it doesn't exist because what we have found that we can perceive thousands of a smell sensations so how is that made possible so first thing is remember that there is no concept right now about the primary sensation of a smell being only seven right so let us see that how is it possible that we can smell so many different types of smell sensations so that is made possible because as I told you that there is presence of G protein coupled receptors on the celia of the olfactory sensory neurons now these G protein coupled receptors are too many actually it has been found that there are thousand different types of genes and out of this 400 are active and they lead to formation of so many different types of olfactory receptors which can bind to different odorants so for example this is a schematic diagram showing these are the receptors and these are the different types of odorants so you see here this odorant is able to bind to a particular odorant receptor protein on the other hand if you see this particular odorant has a specificity for two different types of odorant receptor proteins then another one again it can bind to two other different types of receptor proteins so you see that there are first of all so many different types of receptors that is 400 receptors and that is also not you know one is to one relationship with the odorant that it is not that only 400 odorants can bind to 400 receptors you see because of this different combination of binding there will be a lot of permutation combination by which odorants can bind to multiple receptors and it is this combination of the receptors which are stimulated ultimately lead to the perception of different smell sensation we will see little bit more about this when we talk about the processing of the olfactory stimuli so for now let us limit here that one odorant can stimulate a combination of receptors fine so this is what is happening at the level of the olfactory epithelium that is binding of the odorant to the odorant receptors which are present on the dendrites of the olfactory sensory neurons and there will be generation of the action potential now the axons of the olfactory sensory neurons they cross a cribriform plate which is basically present in the ethmoid bone and this cribriform plate actually separates the nasal cavity from that of the cranial cavity so there are perforations in the cribriform plate let us see in the diagram see here in the diagram this is the cribriform plate and there are perforations in the cribriform plate and these are the axons which are crossing this perforation and reaching to the cranial cavity and in the cranial cavity there is a region just above the cribriform plate known as the olfactory bulb right it is seen in the previous diagram so here you see this is the cranial cavity and just above the cribriform plate we have olfactory bulb now let us see that what happens within the olfactory bulb so here within the olfactory bulb we have certain structures known as olfactory glomerulus okay and it is in the olfactory glomerulus that the axons of the olfactory sensory neurons are making contact with the dendrites of the other neurons that is the mitral cells and tufted cell so this is the olfactory glomerulus and in the olfactory glomerulus you see there is synapse formation so this is the cell body of the tufted cell and this is the cell body of the mitral cell which is outside the glomerulus but their dendrites are projecting into this glomerulus where these olfactory sensory neurons are making contact with them and the axons of this tufted cell and mitral cells are going into the cortex then there is certain processing going on here first of all you see the number of the mitral cells is quite less compared to the number of the olfactory sensory neurons even the number of the tufted cells is quite less there are like only 25 large mitral cells and approximately 60 tufted cells but the olfactory sensory neurons are in too much number there are like 100 million olfactory sensory neurons so you see that how so many of them are making contact with the mitral cells and tufted cell dendrites then there are other cells as well there is periglomerular cell and there is granule cells now if you see this periglomerular cell what it is doing is that the they are making contact with the olfactory sensory neurons but their axon is going and inhibiting the dendrites of the mitral cells understanding so information from one glomeruli is inhibiting the information from the nearby glomeruli what is this actually this is lateral inhibition as is presented for all other sensations as well and this lateral inhibition is responsible for contrast enhancement okay contrast enhancement which is very important for acuteness of the sensation which we feel so it increases the sharpness of the sensation which we feel by inhibiting the other sensation so the odorant which is stimulating this particular receptor say suppose will not be filled to that much since the mitral cell which is carrying its information is being inhibited by the nearby glomerulus connections and obviously there will be one periglomerular cell here also which will inhibit this particular dendrite of the mitral cell however since the information from this particular neuron is not that much so the inhibition will also not be that much isn't it so there will be enhancement of the contrast which is happening because of these periglomerular cells then coming to granule cells granule cells actually receive efferent information from the cortex so they are bringing information from the cortex and they are causing inhibition of these mitral cells and this is responsible for adaptation we'll see when we are talking about the mechanisms of adaptation of the smell sensation so they inhibit the mitral cells so that the information which the mitral cells are carrying to the cortex that is decreased and that is responsible for adaptation now as i told you before that we'll come back to the combination of the odorant with the receptors how that is happening in the olfactory epithelium with the olfactory receptors this combination actually continues forward and there is a creation of 2d map in the glomeruli how let us see certain example say suppose there is an odorant one which is stimulating two receptors two different receptors which are present in olfactory sensory neurons just remember here that each olfactory sensory neuron has only one type of receptor okay there are different celia there will be receptors on all the celia but there will be only one type of receptor in one olfactory sensory neuron so say suppose odorant one stimulates the receptors two different receptors present on two different olfactory sensory neurons now this information will go to two different glomeruli you see in the previous diagram that here i have shown two different types of olfactory sensory neurons with different colors one is green and one is blue so suppose these three neurons have a particular type of receptor only one type of receptor they are going to one glomeruli only and here the green ones are going to one glomeruli only so information from one type of receptor goes to one glomerulus coming back to our example here again you see there are i have shown these are different olfactory sensory neurons with different types of receptors so information is going to two different glomerulus now suppose there is another odorant odorant two which stimulates this type of receptor and other two receptors as well from there again information will go to different glomeruli so you see depending on which glomeruli are being stimulated there is a pattern which is being created within the olfactory bulk of the stimulation of the glomeruli and this pattern is going to project to the cortex so whatever pattern of neurons are stimulated in the cortex based on that there is a perception of a particular kind of smell fine so this is a new concept in olfactory physiology nowadays there is no concept of seven primary sensations of smell fine with this let us now go on to the olfactory pathway now one thing important here is that olfactory pathway is the exception in the sensations where it directly reaches to certain areas of the cortex without passing through the thalamus so here if you see that the axons from the mitral cell and tufted cell reach via the olfactory tract olfactory tract is nothing but the axons of the mitral cells and tufted cells from the olfactory tract and olfactory nerve is basically this the axons of the bipolar olfactory sensory neurons all together from the olfactory nerve okay so then the axons of mitral cells and tufted cells from the olfactory tract which reaches to various areas in the cortex so one is the primitive area primitive olfactory system and that is responsible for the basic olfactory reflexes which reaches basically to the hypothalamus and that is actually a direct connection to the hypothalamus and like basic reflexes licking of the lips salivation these are innate reflexes not learned reflexes okay and that is the most primitive olfactory pathway and that does not pass via the thalamus second is that the pathway also goes to the pyriform cortex and amygdala and from there to the hypothalamus and that is responsible for liking and disliking of the food aversion to the food which foods we don't like which foods we like so this is learning depending on the experience and that is happening because of the passage of information first to the areas of the cortex pyriform cortex then cortical portion of the amygdala and from their information reaching to the hypothalamus so this is also a primitive pathway but it is less primitive than that of the basic innate reflex pathway and finally there is a newer pathway which passes through anterior olfactory nucleus or factory tubercle via the thalamus it reaches to orbital frontal cortex or directly reaches to frontal cortex okay so this newer pathway is actually passing via the thalamus the dorsomedial thalamic nucleus and this is important for conscious perception of the order and analysis of the order that what is the type of the order what is the strength of the order that is by this newer pathway which reaches to the orbital frontal cortex and to the frontal cortex via the thalamus then the information from olfactory pathway also reaches to the memory area that is via the entorhinal cortex to the hippocampus and that is important for the memory of the order so that I was talking talking about the liking and disliking of food so from hippocampus information is reaching to the hypothalamus only when memory is there then only we can remember that this order is linked to a particular food and whether we like it or don't like it so that was about the olfactory pathway coming to the final part that is adaptation of the smell sensation well there are two mechanisms of adaptation of a smell sensation one is the peripheral mechanism which is happening at the level of the receptor and the other is the central mechanism so at the level of the receptor as I told you that it is a G protein coupled receptor right so what happens that we have seen that how G alpha unit gets separated from G beta and gamma unit after some time that G alpha unit comes back and joins G beta gamma unit that is the basic action of the G protein coupled receptor for details you can watch my video on G protein coupled receptors I have given the link in the description section as well so this G protein coupled receptor action stops and there is again decreased activity of adenyl cyclase as well so the sodium calcium channel which we were talking about actually it closes okay so there will be peripheral adaptation however the adaptation is not complete okay in fact there is approximately 50 percent adaptation and after that adaptation is very very slow so there is another mechanism of adaptation that is central adaptation we know actually from our experiences that there is complete adaptation of a smell sensation if we are sitting in a room full of certain odor we will feel a strong sensation for some time but after that maybe even within a minute there will be complete adaptation of the sensation and that is brought about mainly by the central mechanism and this is because of the granule cells which I told you before that granule cell is receiving efferent from the cortex so this granule sense in the olfactory bulb is stimulated which causes inhibition of the mitral cells and tufted cells so that the information doesn't reach to the cortex about a particular odorant just before finishing we'll talk about certain terms that there is something known as anosmia anosmia is absence of perception of smell sensation then there is hypoosmia hypoosmia is a decrease in olfactory sensation we perceive it less then there is hypoosmia hypoosmia is less common but commonly seen in pregnant women it is enhanced olfactory sensation and then there is dysosmia dysosmia is altered olfactory sensation or whatever is the sensation we don't feel that we feel some other perception of the smell so that is dysosmia so that was all about olfaction physiology thanks for watching the video if you liked it do press the like button share the video with others and don't forget to subscribe to the channel physiology open thank you


I want to talk now a bit about our system for multi-arch, or actually I don't want to talk so much about our system for multi-arch, but a bit more about the way we think and discuss about it. I'll first repeat for those that are not clear in the details how multi-arch currently is set up, some problems that have cropped up with that, and then how I want you guys to think about this kind of problem. I'll edit a little part about some recent discussions that have been going on here at Depconf, and basically I wanted to open the discussion about how do we approach this in the future, what problems are there still to be solved, which is basically the topic of the following both. So if we run out of time, just stick around and Wookiee will take over in an hour, and I think we will have enough chance to collect all the problems and ideas that are floating around currently. I talked about that this morning, so I just really quickly, I'm a freelancer based in Berlin, studied informatics, now I'm doing IT consulting, and a bit of teaching of informatics also. Let's look at what we currently have in terms of multi-arch, and this is basically a stripped down version of the multi-arch spec that Steve and mostly Steve pushed forward and a bunch of others have been discussing since I think 2004, so this has been a topic at my last Depconf in Edinburgh at least since then I know. The spec basically says we have three possible annotations for a package, multi-arch same which says something about the package is co-installable with itself and must be used to satisfy dependencies from packages that have the same architecture, not dependencies of different architectures, that's what the same stands for. Large foreign packages are not actually co-installable with themselves, they know about multi-arch stuff, but they export something that can be used by packages of a different architecture. Then we have the ominous multi-arch allowed that allows reverse dependencies to annotate actually the depends fields, and we have a bunch of problems we've been phrasing in terms of these three categories. Also from the multi-arch spec there's really close to that, I found these two sentences which I want to quote here, if a package is declared multi-arch foreign, preference should be given to a package for the native architecture available, if it is not available the package manager may automatically install any available package regardless of architecture or it may choose to make this an option controlled by user configuration, which is a nice sentence for a technical spec but it really really makes my head hurt. And for allowed we have the definition, this value exists to prevent any packages from incorrectly annotating dependencies as being architecture neutral without coordination with the maintainer of the dependent on package. So what this actually means is we wanted to allow packages to declare this information on the dependencies that they're declaring, but we were afraid to do so and it might have broken our archive, so we have this flag that says my reverse dependencies are now allowed to do something fancy. How did we get there? Well we were basically just trying to solve allowing multi-arch and doing a seamless transition of the archive while doing that. And allowing multi-arch of course means solving a lot of problems for actual co-installability. We had timestamps that GZ inserted into the change lock in GZ, so these two files would be different, which would mean per our rather strict definition DPKG wouldn't allow you to do a co-installation with that. And so there was a lot of really great work that went into that to make this possible. And I think it's fair to say with this scope it was solved. All the people that over the years have been working hard to create a spec that the Debian and the Reborn to Archive could actually transition to with that scope that we started out with, system works as designed. Really again, great thank you to everybody who was involved in that. I know it was a long and painful process. Now we have this nice multi-arch system and we want to do fun and fancy and cool stuff with it in newer exciting directions. We just talked about building cross-compilers and making the building of cross-compilers easier in the before this one by actually using a full archive and saying, well, if I have this for an architecture, but I know there's already a compile-lipsy in the archive for that architecture, why should I need to cross build that just to get my cross board toolchain working. We've also been talking a bit about partial architecture. MinGW came up as an example that would most certainly be partial earlier and people have just while deploying multi-arch and converting their packages to multi-arch have been finding some interesting problems around embedding of interpreters and so on. I will talk later about some of these problems or we will talk together, hopefully, but the problem is a bit that we define multi-arch in terms of the implementation spec, which is a very formal spec. I heard earlier, too much mathematics, in my opinion I would say maybe not enough mathematics in there, but as we have it, we have these three classes of packages with multi-arch is multi-arch that, and it's really hard to reason about.  What I'm proposing is, before we change anything, before we say we need to solve stuff differently before we start hacking on DPKG again, let's work on our terminology. Let's talk about it in a different way and then hopefully our mental model will change with that. And this is something that I don't only want to address to the few people who understand the multi-arch spec who were in the booth on Tuesday discussing about possible futures. This is something I think that hopefully every DD will find helpful if we start discussing our problems in a more consistent terminology, we should be able to come up with better solutions for each small problem we might face there. So instead of enumerating all three use cases, what are we actually trying to describe? Two things. One is a per-package flag. The maintainer has reviewed this package and declared that it should be co-installable. This package is consoleable with itself, as far as we know. So DPKG will even attempt to do that. That's the one thing, one information we want to know about each package. And then we have a bit more graph theory stuff, which I will get to in a second and that unfortunately is a subset of mathematics. But graph theory as we need it is pretty simple. We have three packages, these are called nodes in graph theory, each package is a node. And we have a depends on relationship, so far so easy. The depends on relationship in the graph creates what is called an edge, to be exacted edge. So we know package A has something to do with package C, it depends on it. And what we actually want to do next is to think about it in terms of we have properties of these edges. Namely this dependency, this one specific dependency can be satisfied by packages of the same architecture, packages that provide the same ABI. This is a dependency that does actual C style method calls or using some C++ calling convention or whatever. Or this dependency can be satisfied by packages of any ABI because the API that we're using is actually just call user bin whatever with the following parameters. So we expect that API to be consistent across all architectures. So that would be an edge property or a notation or in mathematical graph theory, sometimes also known as coloring. And of course this is still a bit of an implicit information, even if we say only the same ABI. We could get really explicit and say a package of architecture AMD64 has this dependency and this dependency can only be solved by another package of AMD64. Why the distinction between implicit and explicit is, I will come back to that a bit later. So what does our nice multi-arch field actually mean then, first as I said, packages is co-installable with itself. And then if we look at it like that, from this graph theory point of view, we will actually say, well, this package exports interfaces that are architecture dependent or architecture independent or both. So a package can say, at the moment using just a coincidence, all incoming edges or reverse dependencies have to be from the same architecture or have to be from any architecture or we can have one or the other.  I really think it helps me and others that I've talked with also to sort your thoughts or to sort also our collective thoughts about this promise. Because the other problems that have shown up since then are hard and I've always heard like, ah, if you have this exact specific problem, then just create a wrapper package with architecture like that and multi-arch like that and I always have trouble rubbing my head around that because we're phrasing the problem in terms that are really unintuitive. So I'd like to propose that we all try to think about it more in terms of what are the actual dependencies that we're trying to describe and that we're trying to solve. The con of course is after we've described it like this, we still need to append to our email or something a description how to solve it within the current system or it's not possible to solve this use case within the current system, let's solve it in the future with a different system by maybe some time expanding DPKG, sorry, a few more ideas in this frame of reference. We could start doing, if we change DPKG at all, we could start doing explicit architecture annotations that just would make the solving, the solver a bit simpler in many cases but there are some cases where at the moment we have like still an IA32 libs package that's arch any and only ever installed on AMD64 as far as I can tell and then it depends on an IA32 libs IA386 package which is only built on IA386 but never actually used there because it's just for, both these packages are just for describing this cross architecture relationship, forced cross architecture. So if we start changing stuff around and I'm not saying we will, I know that changing DPKG is a long and hard process but if we do that we might try to go for explicit annotations there. For thinking about possible problems it might make sense to reinterpret or redefine for yourself that architecture all packages as a union of or a package that is installable on all different architectures and once you've installed one of the architectures you have installed all of the architectures. That simplifies the reasoning a bit but it's not really that important for the discussion that we have from here. We might need to propagate dependency information along the graph so for multiple edges and I will show an example of that a bit later and we might also if we stay with a system where we describe packages in terms of interfaces they export we might also annotate these interfaces also with architecture information. So that is first my request to everybody if it makes sense for you try to phrase your multi arch problems a bit in terms of graph terminology I hope that will make our understanding of the problem space and our discussions more productive. Any questions so far? So then I thought I'd use the rest of my time to give a quick outlook. So as I said there was a buff on Tuesday discussing some of the harder multi arch problems we sat down and allowed ourselves also to do some green grass thinking and said well we have a bunch of problems if we were designing multi arch completely from scratch how would we go about it or what would we like to have to really solve this problem once in a really beautiful way. Some of the solutions we came up with would need a modified TPKG maybe even DAC some don't but I thought it might hopefully be interesting for everybody who couldn't attend that buff to get a short overview of where the discussion is at within the Debian project. Two related problems that we came up with is fake root and NSS. People might just as a normal user actually have experienced the NSS problem that maybe you install lib mss mdns for local hostname lookup within avahi but you only install it for your md64 and if you have a binary that runs on i386 it cannot actually load that nss module because you haven't told it to install also for i386. So we have just something in the system saying well it would be nice to have an nss module and some other process running in i386 and not being able to actually make use of that. Fake root is similar, it's a problem that will affect more the developers. So with fake root as architecture all, lib fake root is built for many architectures and as you probably will be aware, fake root is just a wrapper that sets LD preload so it will tell the processes running under it to preload the library that does all the moving around of actual open calls but if you are maybe building for i386 and there's something generated in your package that's run at build time and it's been compiled for i386 you cannot actually LD preload because your lib fake root might be missing in the i386 version. Another problem that has been discussed since November I think also a number of devian mailing lists and rears its head repeatedly is the embedded interpreters thing so an application let's say g-edit embeds an interpreter or a library version of an interpreter. For example here I talked about libparl, libparl is built for a number of architectures. libparl has possibly dependencies directly or indirectly or g-edit has a dependency on a certain Perl module so that a g-edit plug-in can be loaded. This Perl module is also possibly an arch all package because it's only contains Perl code but this Perl module again depends on a different Perl module which is arch any because it's built from C code. So now we have the situation that the g-edit that I install must match somewhere very far down the dependency chain a Perl module. If I just have that XS-based Perl module installed to solve the dependency I have completely lost the information that we have an architecture dependency between the application very far above g-edit and the actually loaded Perl module. So this is a bit of a transitivity problem we have the dependencies between these different things and the information well this dependency is actually wanted for this and this architecture needs to travel with the dependency information. I just wanted to go back to your comments about the general graph theoretic underpinnings of multi-arch and are handling the whole thing. I would like to say that from my memory of the original design discussions around multi-arch we were certainly aware that there were many properties that were essentially edge best. However the one thing that I think you haven't really taken into account here is that the number of edges in the Debian system is very significantly greater than the number of nodes. It's probably somewhere between n log n and n squared I suspect a lot I haven't actually looked at the data for that and it would be we considered it a very bad idea to make people annotate all of the edges. We considered it a very bad idea to make people annotate all of the edges simply because there's so much more metadata involved there and I would I think defend the decision to put most of the information on nodes where possible because just because that has better defaulting kind of semantics and has a better chance of making things work by default. Now you're right that there's some additional reasoning that needs to be done in that case but I think that is worth it. We certainly need to have some capabilities to have edge-based annotations so we have things like the depends, cool and any on multi-arch allowed which is one case, one restricted case of that and I can see arguments for extending that. I haven't quite puzzled out whether you're saying that we should convert all of the annotations that we currently have to be explicitly edge best. It wasn't very clear from what you were saying earlier. No I am saying that you should convert them in your head that when you're reasoning about the system just relying on I depend on something and this declares some multi-arch field and then DPKG will invoke some reasonable defaults just does not scale to all the edge cases we have in our dependency trees. For the problem of should all these dependencies be explicitly mentioned in the packages file. One of the points against doing that at the time was it would blow the packages file too much and I'm still not convinced that GZP wouldn't eat most of that overhead up but physical size it's that there is a cognitive cost associated to people who have to read all of those repetitive annotations and the more that you can do by default the more people can read the content that's actually different rather than the content that's just repeated lots and lots and lots. I don't know about you but I actually do read packages metadata quite a lot. It is for human consumption. I'm also opinion actually that the tool chain if we were to say every and I'm not saying we have to but if we were to say every dependency must be declared explicitly I'm still thinking that the tool chain should create the part line in the packages file so that you don't don't do it in the control file all the time. I'm talking about reading the output as well as reading the input which I do quite a lot. I'm sorry for you. But the people who do this quite a lot are exactly the people that everybody complains about being overloaded so if you're proposing to overload them further by making it harder to see what's going on. No I'm not proposing to overload them further. I'm saying that the normal standard DD is at the moment has trouble describing corner cases that she or he encounters using just the multi-arch field. There was another question over there. Yeah please observe that the problems we are currently facing are inherently not edge-based so by moving the specification of what is architecture dependent or where architecture barriers are to the edges we gain exactly nothing in this respect. So for the fake route and depend SS modules we have exactly the case that the architecture matching does not occur on dependencies but on a different kind of relation. And in this example you're giving over here is very same case that it's not a dependency where it's traveled it's a dependency path. Yeah I'm not saying I'm not saying just putting that into just putting depends on ArchMD64 into one certain dependency solves anything. That's not what I'm saying. I'm saying that what we are trying to do is solve these problems and I'm just giving some examples. You were at the bof you know that the ideas we've had about solving these problems and to solve these problems we first must be able to state them well. Yeah and that's what's missing at the moment. I think actually one excellent thing that somebody could do with who has some kind of interface design skills would be to write some kind of visualizer where you could plug in a set of without having to mess about configuring apt and getting your exact right setup which can be quite challenging. Being able to plug in a set of you know effect control data and say what's the result of this? Which packages are installable? What happens if I select this package here? Something that could be used to assist people in reasoning about this would I think be very valuable. That's an excellent idea. I would like to include the others that were not at the bof into what we've been discussing and I think then we should open it up to everybody. This was an error case. One could say with the current system something that we're not able to solve at the moment. Just to get back to my proposed terminology. The question of dependency nativity is something that actually cannot just be written onto one edge. It's a problem that needs some sort of transitive looking at it for solving it. Currently with the current DPKG and so on we cannot describe that clearly. We have a nice bunch of hacks around that but it would be nice to find some way to describe that at least on a high level for us as DDs. Possibly it doesn't have to be on a DPKG level but it might also make sense to do that. So I'll quickly go through the solutions that were proposed and if you're unclear on one of those ask and I will direct your questions to the team that was at the bof. The first really simple solution is they are all arch all packages that are affected for some power module that depends on native power modules. Mark them as arch any and multi arch same. That solves the problem as even the one with the G edit. It means we have a huge increase in archive size because I think our dependency tree often ends up at native C code but it's a very simple solution but one of the things that I would describe as a hack around the current system. Then it was discussed to have a field install for the same architecture as lipo. So if our G edit depends on lipo we know that we have a lipo of the same dependency as G edit and lipo will be installed in three architectures maybe so any module that could be loaded by lipo and contains native C code also has to be installed in these except exact three architectures. Then we have from April I think we have a proposal by Helmut where that is about calculating a set of running architectures for every package even arch all packages go through the dependency trees look at for each package look at for which of my which of the possible architectures are all my dependencies cleanly satisfied and even store that persistently so if you have a cyclic graph or something you still can do this calculation. Yeah that is rather a big change but I think this or something like this is probably what we'll have to do in the long run from my feeling. Are these three proposed solutions clear or question? Yeah I think we have a we might have a slight refinement to the to the details of the last which we'll probably bring that up in the next session I guess. The one thing I'll say is that the more I look at the XS case the less I'm convinced that's actually a problem because the XS modules depend on Perl so I think that may have been an analysis mistake and thinking that was actually a problem but there are other kinds of situations where the same thing arises. I think if we just limit the scope to XS and libfake root kind of situations that's all what we want to do then this middle solution might might actually be. But like the exact reason why it depends on Perl is why I cannot cross compile my other modules which depend on that module because then the wrong Perl is being installed. That's with current Perl yes. I think we should be a bit more precise about problems and solutions because there are currently two problems and the presented solutions only solve sometimes one of them so the one problem is that we have this transitivity issue where architecture specifications need to travel across architecture all package dependencies and the other issue is that we need to have libraries like libnss modules and fake root libraries installed without even knowing what is going to use them later on so these are distinct problems over there and the very first solution only solves the transitivity issue it doesn't solve the missing libfake root in the nss modules and so we need to evaluate each of the options against both of the problems. Also the third problem solution with running architectures only solves the transitivity it doesn't touch the fake root issue at all. Yeah yeah sorry this should have been clear this slide only is in relation to the slide before with the Perl problem. You write that the first solution will solve the transitivity problem at a in my opinion unacceptable cost in complexity but the third solution will solve the transitivity problem at the cost of getting a page into dpkg which might also be a pretty high cost I don't know. I will leave you yeah we have five minutes so I will leave you with one problem we also came up with which is that a package has dependencies on both interpreters Perl and Python one of them as libper the other as a Python interpreter but it doesn't care which one yeah and as I said before well Perl and Python actually both export two kinds of interfaces yeah and so for Perl we're using a native C style interface for Python we're using a a command line interface or something yeah and when we get into that deep of deeply into the problem space we need and we want to solve this mathematically really clearly and nicely we actually need to partition the dependency trees and so that for example for the running arches solution we don't end up with an empty set of possible running arches for the actual application a yeah so we would need a way to describe using grouping or something else would need to describe a way to say well the the running arches for Perl and the running arches for Python can be disjunct the two sets that is something to discuss more in detail possibly in the next part I don't know what Wookie wants to concentrate on yeah for me it's important to get everybody else who's interested in into this discussion do you have questions so far do you have an error case or use case that we have not discussed yet I see you looked on the on the graph on the the jibker pkg and apps view but running programs don't know about packages they know only about what's on the file system and if a program tries to enumerate possible plugins for example then it then it will see the modules that it cannot use yes well and I don't see any solutions here other than a variant of the solution one you mentioned with every such module put into a multi-arch directory yeah that would be the solution I would recommend in all such cases well if the archive is a problem then then they could be even the duplicator is in some way because the this package is identical for all purposes other than than the directories but no it will not be the same because you only care about the for example compiled extensions and compiled modules and compiled plugins and there will be by definition already a bi specific no I mean I mean all modules that depend that might depend on so right and for example in python it can have the same location for both arch all plugins and arch any plugins or extensions and it enumerates both yeah but but and then you have the transitive problem of where the arch all depends plugin depends on further plugins which end up being yeah what I'm thinking about is putting all AMD64 modules in the with all the both arch all and AMD64 into one directory and all I 386 into another possibly with with with some sim links to to the duplicate them but this way a running program would know what what it can run I think there are multiple ways to to to get around that for example in in python we already name these extensions different so we have for an AMD64 extension we embed the multi-arch name into the extension so we don't have this problem there and I could imagine that that for for other plugin systems or module systems you could do the very same or for Perl you could just add all well architecture dependent library passes to the default point of interpreter and see well just discard some at runtime yeah well whether it is in the in the file name or the directory name well it's a runtime package which should handle runtime exceptions understand the problem but you will have runtime exceptions I can write a file which is pure shell which will not manage to succeed to run on any of their architectures because of the embedded you know things I do with it right and that's something you will have to handle if you do write python module say import C strings this is an arch all module which should run on any native system but it may or may not run if you try to embed it in another application and you're back to the same transitive problem this is not a different problem from the transitive dependency problem okay the video team has signaled us that the time is over so we need to at least cut out the stream and I invite you to keep discussing this we can get to get some fresh air for the next 10 minutes and then bookies uh boff will have a very similar topic so it's identical in fact uh in content so we can pick it up again there so thank you you're now given a short chance to escape but there'll be more okay


in this presentation we will take a look at the auditing process for auditing accounts payable focusing in on accrued expenses accrued expenses so here's going to be our assertions that we're focusing in on existence being the first assertion first a word from our sponsor well actually these are just items that we picked from the youtube shopping affiliate program but that's actually good for you because these aren't things that were just given to us from some large corporation which we don't even use in exchange for us selling them to you these are things that we actually researched purchase and use ourselves here we have a western digital wd elements 20 terabyte usb 3.0 desktop external hard drive we use as part of our backup system noting that if you lower the number of terabytes of storage the price will lower dramatically as well when you're thinking about a backup system you usually think about an online system or an external hard drive system like this or ideally some combination between the two given you some redundancy you can also work directly from an external hard drive like this but there are some drawbacks to doing that one being if you use this as your primary drive you're working from it's no longer a backup drive and you're going to need a backup system possibly another external hard drive and or some kind of cloud backup system and if you're working on something that takes up a lot of short-term memory a lot of ram as you're working on it such as video editing the external hard drive can slow up the system so you might want to come up with some kind of system where you download the project you're working on to your computer to your c drive or possibly to a solid state drive which is a much more expensive external hard drive as you do the work once the work is done then save the project to an external hard drive such as this if you would like a commercial free experience consider subscribing to our website at accounting instruction dot com or accounting instruction dot think of it dot com where we have many different courses you can purchase one at a time or have a subscription model giving you access to all the courses courses which are well organized have other resources like excel files and pdf files to download and no commercials accounts payable and accrued expenses are valid liabilities so that's what we're thinking about in terms of existence are they valid rights and obligations with regard to accrued expenses accounts payable and accrued expenses are obligations of the entity so we want to be able to say that they are for the entity these accrued expenses completeness the assertion of completeness all accounts payable and accrued expenses have been recorded all related disclosures that have that should have been included in the financial statements have been included then we have accuracy valuation and allocation as the assertion accounts payable and accrued expenses are included in the financial statements at correct amounts any valuation or allocation adjustments have been recorded related disclosures have been measured and described then we have the assertion of classification all accounts payable and accrued expenses are recorded in the correct account then the assertion of presentation accounts payable and accrued expenses are correctly aggregated or disaggregated and clearly described related disclosures are relevant and understandable now we're going to discuss the substantive analytical procedures so substantive analytical procedures so we're on the substantive procedures but these are those analytical ones the ones that we can do in the office to comparison the auditor's office I would consider they comparison the ratio analysis type of activities so we can compare the payables turnover and days outstanding in accounts payable to the previous years and industry data the possible misstatement we would detect under or over statement of liabilities and expenses the substantive analytical procedure then we can do compare current year balances in accounts payable and accruals with the prior prior years balances obviously this will be a common procedure we'll do we'll compare the current year to the prior year that what we're going to detect under or over statement of liabilities and expenditures so any kind of unusual activity from year over year comparison is something we might look into then the next substantive analytical procedure compare amounts owed to individual vendors in the current year's accounts payable listing to amounts owed in prior years what we want might detect under or over statement of liabilities and expenses next substantive analytical procedure compare purchase return to an allowances as a percentage of revenue or cost of sales to prior years and industry data possible misstatement to detect under or over statement of purchase returns next substantive analytical procedure predict accrued interest expense based on loan terms and the outstanding balance possible misstatement to detect under statement of accrued interest


Well, I'd like to thank you for having for the award interview special.  I grew up riding motorcycle when I was a kid. And it's phenomenal to be at the opportunity to serve the Cycling Company. I had my entire team at the back because we are thrilled to be able to pick this up from our store. And we love to take awards. Thank you for recognizing our efforts and I'm so happy this is for the team. Thank you. Before this award, I probably accepted really the August something that is there. It's been very privileged to be part of this company. I think it's really exciting to serve this award on behalf of amazing event organizers, from all over the world right now. And the guests are busy changing the way in which we're now trying and buying food in across the country. When we come to accept him on behalf of Team L'Oreal, he's a person very interesting in the world of beauty. Hopefully, we'll be creating more innovations with our products, the marketing and the experience. Thank you so much for tuning in to the forum. And congratulations to all of us here.


Hello. First, I want to thank everybody for coming. My name is Clark Murdoch. I'm a senior advisor here at the Center for Strategic and International Studies. My colleague to my left, Ryan Crotty, is a senior fellow here and a deputy director for the International Security Program. Angela Weaver, to my right, works for me as the program coordinator for the Defense and National Security Group and also as a research assistant. The three of us were the co-authors of this study that we're about to talk to you about called Building the 2021 Affordable Military, the cost-capped approach to a defense, deep defense drawdown. Thought I might explain, first of all, what I mean by cost cap. This was a concept I stole from defense appropriators who realized and struggling to deal with continued growth in acquisition programs and the inflation that would be chronicled every year and in terms of the cost inflation, said, okay, we're going to just cap the amount of dollars you get, say, for example, for F-22s. And we're not going to tell you how many F-22s you can buy with that, but we are going to tell you $35 billion is all you're going to get. We've captured cost on that. So we're taking this approach, as I said, originated in my mind with appropriators, both the Senate and the House side, and applied it to how do we think about the defense budget as a whole. Going to the next slide, this is a study that started over two years ago. It was for the first year called the defense drawdown study. It was a pro bono effort in the sense that I didn't have a funder at that time, but knew or believed that we were facing a drawdown that was considerably deeper than people were generally thinking about two years ago and that we needed to embrace budget realism and start thinking about how we do a deep one. After a year of effort at that time, we were able to get funding for a follow-on project that we called the affordable military, which is this is the military you could afford under the budgetary caps. We're taking his reality, the budget control act caps that were imposed by Congress, signed by the president in August of 2011, the first tranche of those caps were applied in the FY, started to be applied in the FY 12 budget. They mandated $487 billion in cuts over 10 years. Then there was a second tranche of cuts that were called the sequester cuts. Actually, it's a little bit of a disnomer. There are new budgetary caps that if they are violated trigger sequester. But that round is another $460 billion documented in the report itself. As I said, we had two working group meetings. Ryan and I've been part of the team for the full two-plus years. Angela joined us. I'm sorry. Yeah, Angela joined us. Kelly was where the first year Angela has joined us in the beginning of 2012. Next slide. Defense drawdowns compared. This is our first wheel indication as we started working on this in 2012. This was a chart that an earlier version of it first appeared in the work of David Briteau, one of my colleagues here. But Ryan was working on that one as well. And as you look at this chart, it becomes clear that while it looks like the drawdown in terms of relative percentage is about the same as previous drawdowns, what differentiates this one is that unlike previous ones, it's only going down to about $500 billion in real terms. All other drawdowns went down to $400 billion in real terms, constant dollars. Why? Because internal cost growth inside the department had drive up costs so much, you essentially could no longer afford to build up, and we didn't during the 9-11, post 9-11 buildup, buy lots more uniform personnel, salaries, benefits, medical costs had been going up so much that the buildup that occurred during the post 9-11 period consisted of increase of dollars, but not increase of uniform personnel. Those extra dollars largely went for civilians, went for contractors, and it went for the active duty pay for reservists who had been called up. But as you can see from that line that goes across, did not apply as well to the uniform military. Next slide. Impact of internal cost growth. What you see here is the first of what we develop, what we call OMI charts, that when you look at it, you say OMI because of, as several senior Department of Defense officials have, it shows how the impact of internal cost growth is hollowing out the defense budget from within. The top line is the top line that's mandated by the Budget Control Act. So that's the top-down pressure that most people have been focused on in terms of the projected defense drawdown. But when you look at internal cost growth, it is swallowing up the room in the defense budget and essentially forcing a very tough trade-off between modernization and personnel. Healthcare and military personnel look sort of constant, but they're not really because the amount of personnel is actually dropping about 140,000 at that time. This includes the first round of cuts to the Army and to the Marine force structure. So the only reason that they're not rising as well is the number of people are coming down. But the operations and maintenance budget and the acquisition cost growth have been going up and essentially eating available space from within. And one of the things that as we see on this chart that in order to restore this, the modernization accounts to this budget out in 2021, which is the last year of the Budget Control Act cuts, you have to essentially give up 166,000 people. If you give that up, you will get 32% of the budget for modernization, which is RDT&E and procurement. Next slide. The cost cap methodology is very straightforward. It's explained in the report and then implemented in the report. There's an annex in it that also describes how it evolved over these two years of the study. I doubt many of you will be interested in reading a detailed examination of how the methodology, the cost cap methodology evolved, but I have to admit I find it fascinating. I guess that's why I'm here. We accept the harsh fiscal reality and then we try to maximize the military utility of the force that is affordable with significantly through. So you have a pre-drawdown force, 2012 is our departure point. You apply the BCA caps. You then build the 2021 sequester force by essentially cutting the budget in the same way that the Budget Control Act mandates. That is across the board cuts to all programs and activities except for uniform personnel. We built the 2021 baseline force by essentially saying, look, we're going to adapt. The Department of Defense will adapt to a changing environment as the drawdown occurs. So you're going to see changes in the composition of forces that the department will have. So the 2021 force that we call the baseline force is an adapted sequester force to new strategic realities. Then we create more options by varying the force structure still within the cost caps and then we choose one. The first step next slide of the cost cap methodology is to redefine how we think about the defense budget and Ryan is the expert on that. Thanks Clark. So actually, Angela, if you want to go back one slide for a minute, the key to sort of starting to really develop this methodology and to execute it in a cost capped way was in fact to find the costs that you want to cap and the ones that you want to be able to trade against. So this involves sort of redefining and quantifying across the defense budget all the different costs that are sort of inherent in what we pay for. And then set them up in a way that you could manipulate them to demonstrate the tradeoffs that you would want to make to go from a point where you're looking at this baseline and sequester force that are based on inertia to really trading for strategic options. So in order to facilitate these tradeoffs, we developed an approach to break down that was targeted at essentially three things. First, to start with the building blocks that we wanted to work off of. So those were for structure and modernization. The procurement and R&D spending to to take those building blocks and apply the cost growth that would demonstrate sort of what the 2021 force really can be expected to cost. And finally, by combining these two pieces, look at a fully costed 2021 force that can then demonstrate the impact of the drawdown and these inflationary pressures inside the defense budget and the capabilities tradeoffs that are required under the cost caps in 2021. So with those sort of as the goals that we started with, we had essentially a four part methodology. One was to pull out the costs that we did not want to be trading against. These are the institutional generating costs for the entire force, which is not to say that they are unnecessary overhead, but they don't go to developing sort of combat capability. This is sort of what we call the institutional support functions. We wanted to be able to separate those out for two reasons. One, because we wanted to be trading against combat capabilities, as opposed to the entirety of the defense budget. This is sort of the not directly connected to manning, equipping, sustaining the force. But also because we wanted in this cost capped methodology to be able to actually try to bring institutional costs down. If the goal of the military is in fact to generate fighting forces, then I think one of the goals that you want to aim at and something Clark might want to talk to you, but it is to actually be able to hold those institutional costs down to get more bang for your buck. But then second to then after we've pulled out institutional support costs is to take what we call what's left, what's the operational force costs, the combat support, combat service support costs, those functions that are required for military operations, and divide them into pieces of force structure and modernization decisions, because those are the things, the big building blocks that generate military capability and capacity, and those are the things that need to be traded against in a real budget drawdown scenario when you need to decide what you need to execute your strategy. So then we need to apply the expected cost growth, which Clark mentioned earlier. This is the more realistic cost growth that we see the Congressional Budget Office talk about, what we can realistically expect going forward for the cost of health care, the cost of paying benefits, personnel, the cost of acquisition, which is a big one, as well as the always rapidly rising operation and maintenance costs to look at a realistic cost in 2021. So to go back to institutional support, these were across all budget components. There are elements in R&D, in personnel, in O&M, in procurement that we pulled off the table for trading against. The operational forces were modernization and force structure to trade against. Force structure was broken down by each service component, so both active and reserve for each of the services, and in the report there's a full breakdown of every force structure unit that was traded against. And once this was broken down, we applied our cost growth and we saw that we had to take $100 billion of force structure and modernization out of the force in 2021 just to reach back down to the budget gaps. So in Appendix D of the report, which is online now, you can see the probably overly detailed explanation of how each of these costs were developed, how we got to the point where we were trading against the core decisions of F-35s, of how many BCTs we should have, of how many carriers and battle groups we can afford, those sort of big questions. We can see how those costs trade against each other. But I know we want to get to the more exciting part, which is in fact how we made those decisions, what those decisions were, and how we executed those tradeoffs and for that I'll turn back to Clark. Thank you. On this, it's important to remember that we're talking about what we've called the double whammy effect on the budget. The top line because of the Budget Control Act is coming down 21% during the period 2012 to 2021, at physical year 2012 to 2021. The internal hollowing out effect is 15% and that's a conservative assumption. It could be as high as 20% or even higher than that, but that's the loss of purchasing power of the defense dollar in terms of the amount of capabilities you can buy with each dollar. Essentially, using economic terms, the defense dollar is getting weaker and weaker as time goes on because of cost inflation. So you'd have fewer dollars, 21% fewer dollars, that have 15% less purchasing power in FY 2021. Next slide, please. This is a summary of the methodology, institutional support, what we estimated, modernization, a wedge of modernization that's at the historical average of about 32%, 33% of the defense budget, which we then had accompanying modernization profiles for each one of our strategic options. As I said, the sequester force, which is a mindless approach to how you do a defense drawdown, nobody's going to do that. So we came up with a baseline force and then the alternatives that could be added to it. The purpose of this was not to say, you know, we ended up selecting the great power conflict as being the force to go to for reasons that I could explain. But the purpose of this is really to demonstrate the methodology, not so much to say everyone should go out and endorse the great power conflict alternative for the FY 2021 force. Next slide. These are an element of the building block that we used of the transition from the sequester force to the baseline force. We did a lot of work on the future security environment. Angela has an annex in there about the future security environment and the implications of the implications of that future security environment and changes in the evolution of warfare upon what kind of forces you're going to need. Essentially, we looked at three kinds of strategic realities in the 2020 and beyond time period. One is changes in the threat, changes in the opportunity, changes and challenges. The second was evolution in the nature of warfare, greater emphasis upon cyber. And the third was essentially preserving key American competencies. For example, situational awareness. We have world class ISR capabilities. We're going to seek to maintain that into 2021 and beyond. So we developed a cheat sheet essentially said that these are the things we're going to plus up from the sequester force level. These are the things we're going to keep it the same and everything else is a bill payer for those first two, which meant that our cuts came down disproportionately on those capabilities that we said we're not must have capabilities. In 2020 to 2030. Next slide. We built three alternatives. I've talked about those. The choice at that point then was to say which is the least bad option because I think it could be said that each of the options probably lack adequate capability to deal with the full spectrum of challenges you're going to face in a 2021 environment. That's the reason why we emphasize that you've got to prepare for a deep drawdown because under the normal or the traditional force planning structure as Secretary Gates and many other secretaries have emphasized. The United States wants to build the most robust force structure that they can so that they have capabilities that are flexible across the full spectrum of challenges. My argument is in a cost capped world, you can't afford to do that. So you have to look at the alternatives and say, okay, I'm even though I'd like to have some of this capability, I've got to put more of my capability into this basket.  It's not a question of doing more with less. Next slide. Final remarks. The digital question, as I said, is that planners, strategists tend to say let's talk about the strategy and ask how much is enough. And I think given the harsh budgetary realities that the Department of Defense faces in a 2021 environment, what they have to ask now is how much is affordable. And you have to start with balancing your ends and your means at the very beginning and make a decision. If this is an accurate force, maybe you come back and say maybe the sequester level cuts isn't such a good idea. We've got to figure out another way to solve this. People are saying that now, but they're saying it out of denial. They're not saying this is what it really means in terms of the forces that you're going to have in a 2021 environment. But it does explain one thing, and that's why the Department of Defense started complaining so vociferously after the passage of the Budget Control Act that this meat acts approach would have a disastrous impact upon U.S. security because they understand and are increasingly understanding. And you can see that clearly in the 2014 Quadrino Defense Review. And the follow-on report that talked about the impact of sequester level cuts on Department of Defense is that the combined effect of the top-down decrease and the internal hollowing out is having a real impact on the capabilities the United States will have in a 2021 timeframe. Anyway, I apologize for going on too long. Happy to take any questions. I know it's early in the morning. It's two days before a holiday. Please. Sure. Why don't you go back to slide seven so it's there? The Asia Pacific Rebalance obviously has a China component because of the rise of China. But it also has a component that's reassuring U.S. allies in the Asia Pacific. So what we did in this force is say this is an emphasis upon, yes, more capabilities that can counter China's growing anti-access area defense capabilities which themselves are growing, but also increased naval presence in the theater because that's been an element of the Asia Pacific Rebalance strategy from the beginning. And as you know, there's been a considerable debate over how much has that really changed our naval presence. I think recently the CNO said that over 10 years they expected to increase their assets in the Asia Pacific by 15%, I think was a figure that he used. Well, when we applied the sequester caps, I believe it took the carrier force down to seven, took the carrier force down to seven from where we are today. So we wanted to buy back carriers. Carriers are very expensive. And they also cost $3 billion a year to operate so that when you buy back carriers and buy back marine force structure to increase your presence in the Asia Pacific, it forces you to cut out a lot of your high-end capabilities. So one of the main differences between the force structure that goes with great power conflict, which is all about countering Russia and China at the high end, is that in that one we invested a lot more in monetization. We plus up the monetization accounts. We tried to stay ahead of the evolution of warfare. And so the real difference between those two capabilities is the Asia Pacific spends a lot more of its money just in the Asia Pacific and does a lot more to reassure U.S. allies in the Asia Pacific. And the great power conflict one is focused on the U.S. global competition with both China and Russia. And one of the reasons that our group recommended great power conflict, and that's just our recommendation out of the options, is that we think recent Russian activities in Eastern Europe and in the Ukraine bring a much more distinct adversarial component to U.S.-Russian relations. And the Chinese, you know, they're actually acting like very much a responsible stakeholder now in terms of the indisputable territorial claims that they're making in the South China Sea. And so we think, you know, while the allies might want us to increase our presence more, we think it's probably more important for global security, which includes allies, security, that we do a lot more to deal with those who are threatening everybody than to reassure those people who are being threatened by them. As I think the Japanese Prime Minister just demonstrated in recent emphasis, they are changing their military structure and philosophy and abandoning some of the principles of the pacifist attitude they had to increase their capabilities to deal with China. This is what we think all of our allies have to do. They have to do more in their own defense. We have fewer resources. We'll focus on the big guys. They can focus on protecting their own security. And if I could just add one thing. I think one of the things to keep in mind in this cost constrained environment is that a lot of what we are doing is subtracting less in the areas that are most important. And our colleague here, David Briteau, has often said that if we're moving to an Asia-Pacific rebalance that goes from 50-50 in Asia to 60-40, that is probably going to end up being more about subtracting the rest of the world than adding to Asia. I think that you see that in the China trade-offs that we had to make. I mean, if you're planning to look at an Asia-Pacific strategy where in fact there's one less carrier, that's the reality that we're sort of living in, that we would love to keep all of them. But if you want to be able to react to a lot of scenarios there, you have to subtract somewhere. Please. I can't remember what page it is. It is in the main body of the report. But one of our tables is on the cheat sheet that we used for adapting to 2020-plus strategic realities. So we increased ISR, we increased S&T, RDT, and E. We increased soft direct action because you're still going to have, we now have the Islamic State, we're still going to have global terrorism to deal with. We plused up Air Force long-range capabilities, that's the great power conflict aspect of it. And then Army Reserve components, why? We wanted to hedge because we're cutting so much Army active structure. We wanted to increase the Army Reserve components. But we also plused up Marine Force structure because they want the role, we gave them the role of being the United States crisis response force. We maintained at 2021 sequester force levels. And remember, this is a cut from where we are today. But what we maintain were space, ballistic missile defense, unmanned aerial systems, UASs, and the triad, essentially. Everything else was a bill payer, which means that when you look at the detailed force structure charts and you have one for each of the options, you will see how many F-35s we had to give up to pay for that. From my perspective, the F-35 as a short-legged system, pretty hard to use in a great power conflict kind of mode. Because that's how you bring U.S. vulnerabilities within the target range of your adversaries during that time. So for me, tactical aircraft are turning into presence reassurance aircraft that are used in relatively safe environments as opposed to trying to penetrate either with missiles or with the delivery system itself at the high end of the conflict. So that's pretty much it. Now, if you wanted precise, you know, how many F-35s that you have to give up in this world, in this world, it's all in there. Because what we did is a modernization profile. The modernization profile is not year-by-year the way force structure is, where we have a year-by-year inflationary effect. What we did was total all of the modernization dollars during the FY-12 to FY-21 period that equals $1.8 trillion. And then because annual buys vary so much, we were then able to take the profile of today's force and create the cost of that in $2021. And that created today's force in $2021 was about $140 billion, wasn't it? $140 billion over the budget cap. So then you apply the budget cap to bring it down. Both for force structure and for the modernization profile. Sure. And thank you. I have to admit, I'm a capabilities guy. And when you don't have many dollars, you don't have dollars to spend on keeping the defense industrial base healthy in order to be able to build capabilities that you can't afford to buy. That's the thing I think about dealing with the budget realities that we're in now. You have to focus your dollars on the must-have capabilities. And if you buy those, you'll keep that portion hopefully of the defense industrial base healthy. Although healthy will be a relative statement because dollars are going down during that time. So there is an industrial base problem during this time. We do not have the industrial base that we had during the Cold War. We don't have the industrial base today that we had 10 years after the Cold War because there's been a gradual decline in the purchasing power. And when there are fewer dollars being spent, people look elsewhere. That's why the Defense Department is having to become more adaptive and flexible and deriving its technological advances out of the private sector during that time. So when you have fewer dollars, it forces you into lots of economies of a strategic nature. And part of the point that we made very explicitly is that when we capped the dollars, we're not trying to say that the 2021 baseline force or any of its strategic alternatives are sufficient to meet the challenges that we're actually going to have in 2021. One of the purposes of this study is to strengthen the case for those who are advocating. And that's not enough. We have to have more capabilities for it. And my belief is that one of the ways you do that is by accepting the reality of what's in the law. And when I hear people from both sides of the aisle in Congress saying, sequester ain't going away, you know. And I look at the prospects for the midterms coming up and a couple more years of political paralysis there and then you start thinking through scenarios. Once it's in the law now, and it is in the law, the Budget Control Act is there. And people are saying, well, we didn't apply it the first couple of years. Well, yeah, we did actually because while the sequester level cuts were supposed to be about 50 to 52 billion dollars per year, there were some adjustments made so that in FY 14 it was only 35 billion. Well, that's still a cut. That's not an increase. We had planned increases at the end of the Gates, or secularized year of the Gates administration in the Department of Defense, for like a steady growth along with the rate of inflation. I think it was about 1.5%, something like that. Well, we're not in those days anymore.