Hey, good morning, everyone. We'll give everybody a few minutes to slowly trickle in and then we'll get started I think we can go ahead and kick things off. Can everybody hear me? Yep Okay So good morning Apologies for being away a little bit.  It's been added to the agenda I did one thing but just to start just so everybody's tracking This Sunday is July 4th. So we're canceling next Monday's call just because the majority of Participants in the US are going to be on a long holiday for that weekend and Observance of Independence Day and then same thing for the tug it's going to be pushed out to August 2nd Everybody's tracking the cube con and oh and yes are coming up. So If anybody has anything they want to add to the agenda we can dive into The glossary and the discussion. I Don't know how far we made it on the glossary while I was out But if we think that that one's going to continue to be a big time sink Maybe we look at discussion 177 first I think it's a good way for our community to interface with the rest of the CNCF They were looking for some help This is one of the ones that Adam specifically mentioned that the glossary team could use them help on is Providing just a succinct high-level definition of what a CNI is from the context of network people So I don't know if anybody has any thoughts on that or if we'd rather start with the glossary Maybe we haven't gotten to our Monday morning coffee yet Does anyone have anything they'd like to add agenda items or you can just drop them right in the meeting that switches and zoom All right. I'm a little confused as to why definition of CNI would need our feedback. This is just a An aspect of how Kubernetes works and I'm of the mindset that we just Regurgitate that definition. I don't know. It's just supposed to be readable, right? Like we got the overview on what the glossary is aiming to achieve So and we could do something else It's just one of the things that they asked us about so it in because it's in my opinion It pretty well-defined thing It shouldn't be that hard for the CNF working group to put in a PR and contribute to the CNCF glossary Could you show it on screen again? Yes Tal what they're trying to do is make all of the CNCF glossary start with Definitions and and the terminology that's accessible for people that aren't even familiar with cloud native Working or anything So it would be help with that like just bring it up as high as I think they said like Explain this to a five-year-old type of thing or a third grade or whatever that the terminology is so explain it like that and then go up and Then the otherwise is just making sure whatever goes in there is aligned with Kubernetes and communicate something about networking Additionally, Tal, I think the parts that we can help with is This right here. I mean, I don't know how many people mess around with Cades before, you know, the CNI was drafted and the lack of uniformity, but I mean Just a little bit of color commentary and the problem that addresses and how it helps I think it's something where we could throw our opinions in as network people, but I don't like to your point though I don't think we're necessarily trying to come up with a definition for a CNI. We're just trying to make it relatable as Taylor said Well, I guess if they do want feedback it's for that second sentence It takes care of the basic setup. Well, it takes care of the setup. I'm not sure Basic is the right word here. It could be very very complex and The other part host network interfaces. Well, it could It could do other things as well, which have nothing to do with the host network interfaces Yeah, there's a problem here in the sense of there's what the CNI should do and what the CNI could do Right, you can make it do literally anything what it should do what it's defined to do what is documented to do is a slightly different Well, of course, right, but but even in terms of CNI plugins that we we work with a lot I'm not sure This definition is comprehensive enough. It's a bit odd to me the host network interfaces. Well, that's You know a lot of these plugins work with SDN and SDN configuration and host network interfaces is not the Not the core issue that It's not their main their role is not what is described here I feel Yeah, you could view that in terms of how they get it done and what the end result is because the end result is a container has a Network interface that works the the means to do that is often a lot more complex right so Yeah, but I think We could eventually like add like links to other stuff we provide but like at the end of the day It provides connectivity from the pods to the rest of the network, right? I mean we should be more like Eloquent than that, but like I don't think we're necessarily for this definition You know, we don't need to get into the ins and outs of like what a bird implementation for BGP connectivity looks like in a CNI Right, I'm just saying that the second sentence just seems wrong even if we're not getting into it I would remove the word basic and As Ian said, you know, it's about setting Network interfaces and pods that this part about host network interfaces. I think should be removed If I may add one more perspective, I also agree that we shouldn't make this as complex as like that's seem simple enough, but in the service mesh world we use it The CNI the fact that you can chain load CNI's and they're executed in a privileged mode We use it as a way to actually do You know IP tables and whatever which is not necessarily setting up interfaces It's just you know doing networking stuff the the crucial point here is that this is run in a privileged mode like this thing can do a lot of things That's you would avoid to do on the on the higher levels just make sense, but Yeah, I would take this from what someone was saying earlier explain life on five, right? We're looking for something which is trivial in terms of an explanation using short words that ideally we don't have to contradict in the future when we're explaining to them like they're a grown-up Yeah, I'm Ian. I think the way you put it before was the best, you know, it takes care of setting up pod network interfaces. That's it Yeah, I this is Sheetal Joshi from AWS. I'm a developer advocate for EKS team here. I joined in a little bit late, but I have my basic question. I think I am actually working on the telecom space currently and the CNI I think more questions come related to the core delegate CNI versus the multi-sinterfaces what that CNI should look like and what does the CNI mean for when multiple interfaces are involved are we taking it to that level or we are just working to the basic core definition of the CNI itself for the CN continental network functions to start with I just missed the earlier context. So I'm sorry if I missed any of the basic context around this discussion This one's basic and high level Sheetal I would say that If we don't feel like there's an adequate definition or if we need, you know, more explanation It's something that we could put in the CNF working group glossary But for this it's like I think Taylor said it was like to explain it to me like I'm five things This is for people like executives at your company who know nothing whatsoever about our space and they just want like the pamphlet version And then like you said, I I do think the problem that addresses section into how it helps section is something that this group is uniquely Because we felt the pain of dealing with them and trying to implement them is something that we could add flavor to um, so this is probably still not good, but There's also a semantic thing here. So is CNI is not a kubernetes specification uh, kubernetes CNI is a standalone definition which is lives under I mean, I think either the Linux foundation or the CNCF. I'm not sure which so it's also designed to for configuring network interfaces in Linux containers And I think we should word it such Where we we're rid like that and then we put in such as kubernetes spots Just just to make it exact because we we don't want We we want to make sure that we were presenting the information properly Very good point. I'm going to link the specification here in the the chat For whoever's interested Yeah, and very often there There is additional information. So when you run CNI their Kubernetes will often include additional environment variables, which may be Kubernetes specific So just from a practical perspective It is it is common to see sometimes CNIs that will only work in a In a kubernetes perspective depending on how that's set up but But generally the the purpose of CNI is to Is to be a generic Linux container Network interface API Can I ask why is pot capitalized? because People are watching me type and I make mistakes That's a delightful answer I can't remember what that law in physics is but when something is observed it changes its behaviors My typing ability drastically falls apart anytime I'm on a shared bridge And just Kind of editing this live. It's not perfect. So we'll continue to massage it How about this it has been adopted by kubernetes for Creating network interfaces on pods Do we want to qualify that as well saying at the start of time or leave it more generic and I'm fine with either one I would leave it generic because there are efforts afoot to actually make them dynamic You know, it's It's complicated Right because multis it's actually Just to manage container networking Would do um I'm okay with towels just because we are trying to give it like the context for um this Like the fact that were I mean the generic container network I think is kind of covered in the first one library and specification for networking plugins This second sentence, I think it gives it a little bit of the flavor of How does kubernetes leverage it and puts interfaces into pods? But I'm open to be debated on that Small typo and kubernetes by the way I need all of you to close your eyes for 15 seconds. Will I type this? kishan abderou from from orange trans and i'm a research and development engineer at orange labs And just for that question. So I don't know if you aim only to to define the cni for for developers and users or Or you aim you aim also to to define best practices for using cni so and More particularly using mil test to to attach multiple Interfaces to to the kubernetes pods because I know when using mil tests We are able to to attach interfaces of different types And each type has it dependencies on May have it it dependencies on On the worker notes of the kubernetes cluster like for example the the presence of Given interface on the pods so So it may make network functions less adapt adaptable to to To kubernetes clusters in general. So I don't know if you aim to To define best practices like for for example using additional interfaces Only when it is required for example because I know it Is a little bit more complex than using the default network provided by By kubernetes and the primary cni plugins Yeah, I think part of it as well is not just identifying best practices, but there are some very real gaps there as well So I use srlv as an example. So When you request for srlv There are multiple ways of getting srlv interface into your into your system either through direct or through a current interface but If all you want is like hey, I need something that connects with srlv Then you're in good shape But if you need a specific one such as I need one to go to a specific network with a specific clause That's been configured by a specific top of rec switch And and you need it to align against the certain Numa Certain numizons then these type of questions become much more difficult because the There's there's not a strong topology management historian in current entities just yet So I think part of the best practices is is identifying not just Well, what can you do but also what is what it's still in development or or where are some of the gaps there as well so I part of Part of the initial goal was also to try to work out what some of these things are so we can Ideally try to work out ways to to fix it but we also have to be careful because telecom is not the primary purpose of kubernetes And we need to be careful not to overcomplicate kubernetes for the sake of service provider workloads Especially when you consider the that the total size of telecom is minuscule compared to the overall Uh to the overall Whoa, whoa, whoa Frederick. I'm big and important Don't don't you get To stay on track though, I just want to bring something up because this is not relevant to the Contribute contribution to the cnf cncf some thing. So I didn't catch you's name. It was from orange labs, but Those are the types of exact things that we're looking for for us to add into the use cases, which is um Here you can see that there's a couple That have been committed and then ultimately these use cases will feed into the best practices, right? So like You could start by um providing some use cases following the template in here On the types of interfaces that you are using to connect to your network and you know interface with pods and then from there We could start, you know, building the best practice out of there like here's a really bad way of doing sROV in a pod Here's a good way, etc But um for now, I just like you said, um I don't want to like confuse like the work we're doing versus the work that we're just trying to um assist the cncf Thing and actually I'll jump over to that real quick. It's just so people can see I do not know why my right click does not want to Play nice today. Um So for those who weren't here for adam's presentation, um the cncf You know, it wasn't just our group that complained about the lack of definitions out there in the ecosystem Others also found that when they were writing documentation or trying to explain things It was kind of hard to describe What a lot of the things we just you know use um offhandedly actually mean And it was announced in the most recent kube connie use that there is an initiative to create a glossary That just has very high level easy to consume definitions that give you the basic gist of What an api gateway is for instance, right? And so You know what it is you can see here. I mean, we all know that an api gateway is substantially more complex and complicated than what this um is describing but you know The reality is is um most people outside of like this group and you know People who really care about like api lifecycle management probably are happy with something like this And then the parts that I would like us to really quick at least put some footnotes down and then we can jump to the glossary is um You know, what does the c&i do and I don't know it's not in there But it's my some we want to keep track of on our own is like what problems doesn't address does not address But um, you know, there's I think there's some pretty clear cut examples of what the c&i You know helps with I mean the fact that I can move from psyllium to calico to you know flannel if I'm kicking it old school or whatever And have a reasonable expectation that things are going to work while having completely different network paradigms I think is you know something that that helps with so um The And you know multi c&i multiplex is the whole thing too. So that adds yet another uh Important contribution that c&i does But right this is out of scope for this specific issue. I think I lost my Little write-up. Okay. So thank you for uh clear response. Thank you Yeah, absolutely the stuff that you're addressing though is things that this group uniquely cares about so by all means, please kind of take a peek at the um the section for uh Lost my stuff the section for adding use cases and then building best practices off of that And you could also create a a new discussion directly if you're not ready to add a use case if you have a use case those are One of the best ways for us to have a focused discussion But this discussion area is another place to add Lost that other thing with the goof I don't know why my track pads give me such a hard time today So just real quick at a high level. Um, if anybody wants to Spitball some problems that the c&i addresses And how it helps I'll really quick fix this To help put in chat the second sentence you had given me earlier. Remember it now Yeah, I just took the word linux in front of containers Just to differentiate from virtual machine containers or other forms Or maybe we should leave it as containers because there is c&i to To virtual machines now to to somebody great friend, but although they still configure the never again, so it's at the end of the day, so I think I think Yes network plugins can can be used for virtual machines, but I think the c&i project aims only to To adapt this uh plugins to a container use case use cases, so I don't know if It is useful to It's actually a good point. Um, I did Uh, I posted in the chat My rewrite I did put other resources The reason it's Worth uh pointing out. Well, first of all, it's not for containers. It's pods, right? The interfaces are shared By all containers within the pod But also there are interesting resources in kubernetes that you see and I independently Uh, so cube vert mimics a pod Well, it is a pod, but it's not a pod running containers Vertlet does something entirely different so Um, you know c&i is kind of the standard within the kubernetes world that the internal resources in kubelet use it But also other extensions Adopt it as well so Yeah, I think And I'm trying to avoid Getting into the definition of limits containers here as well because Right, right in reality All of these things if it's configured in every namespace you can make an argument That's running in some form of a limits container with the process sitting in there, whether it's cube vert firecracker vm g visor or so on So you could say that's actually being hosted in a Something that looks like a container like a limits container, but uh, but for the sake of simplicity because Uh, I think maybe keeping the work container there Rather than just saying when this container probably Probably makes more sense because it won't uh less likely to confuse people And by the way, fabric the point you raised about does it only create These interfaces or allow you to change them is a major flaw in c&i Right. It's it's an advantage is how simple it is, but it's it's a problem. It does not address Directly at least yes, see and c&i explicitly is an executable. So kubernetes calls it it runs c&i exits And the interface should exist and it provides information back in adjacent format as to What what's present? So this means there's no long term lifetime of the c&i plugin itself Though you could have something else like an stn or similar Or keep the information and use it out of them So it's so c&i itself because it's an executable has these significant limitations uh, it would be I I don't think the problem is that it's an executable because we we have a concept in the network plumbing group. We call a thick c&i plugin So the executable can just be a client that runs the problem is the definition of the interface itself and when it's called It's called for creation What happens behind the scenes can be a long time running service, but the problem is It's not called again Right for changes, right? So the the problem is the interface itself and how it's defined and how it's supposed to be used I don't know if it's necessarily a problem. It's just not in the scope of what the c&i tries to do So assuming that we're going to tackle c&i like gotchas later What things does it do right now? other than portability How does it help us? Because I'd like a loop to be able to put this in we'll have He kicked us off initially um but I like said It's tough because I know we want to like go down these rabbit holes about like the things that leave us woefully Underwhelmed with the c&i but as far as the cncf You know glossary context What basic things does it do for us right now and how does that make our life better? On another word I would add here is decoupling. It allows decoupling network solutions from A kubernetes development. I'm not sure I I would phrase it c&i itself is also a layer three As opposed to to layer two At least from the specification perspective, of course, it's an executable people can do whatever they want behind it But the interface itself the spec itself calls her for a layer three So frederick, do you know if ipam is part of the c&i specification? Yes, there is an ipam portion to touch to it and ipam itself is a plugin So that's another important actual actually thing that it does it manages addresses Or allows for the management of addresses. You don't have to use it But only pod ip addresses kubernetes itself manages services addresses correct But but within the context of what c&i does right when it creates those network interfaces It also allows for configuration of if you want to use whereabouts or something like that It can let you plug in An address allocation management system Correct and and it returns to kubernetes dns information as well to go into the to go into the Pod so it doesn't actually the file system does not exist yet when c&i runs So there's nowhere for it to actually drop drop a resolve.conf But it does return dns information, which can then be consumed Which which can then produce the right set of configurations with the container down the line So, you know what I would add to the First definition when we say creating network interfaces. We can say creating network interfaces and advocating ip addresses Another thing as well that a lot of people don't realize is that c&i can be changed So c&i is recursive I think there are there are two other aspects that we need to touch as well here Maybe it is very intrinsic and we don't have to talk about the Network core network the untill a network and the network policies So do we want to mention any of those sorts in here Those aspects interestingly interestingly, so The network policies and and similar are more of a kubernetes construct than c&i This is an area where the abstraction breaks down so The c&i itself doesn't actually call for any form of access controller or similar But you clearly need it in kubernetes Do we want to clearly say that out here? I I think we should we should say that kubernetes itself applies additional requirements to the c&i plugin in regards to network policy And and service management because that that is a very important point kubernetes will break if you do not support at the very minimum Services and it won't break if you don't if you don't provide policy but It's a but it's a significant detriment to a runtime environment if you don't have policy attached to it That's a good call out Isn't this true is the c&i? Well, yes, it is extensible in specific ways, that's true Now say have you seen some of the glugy stuff that's come down the plate Um, but we can reword this. I'm just trying to capture some of the thoughts that I'm hearing in these discussions Yeah, and to be clear from a wording perspective. So services is provided by Or even though it's provided by the c&i, it's not called for in the actual c&i spec itself So it's an additional requirement that kubernetes itself adds This sentence is confusing actually because What do I how does it help in the service right the c&i itself? Doesn't do anything with the service Yeah, one call service is a concept either. It's it's a specific resource Thank you, jeffrey for doing your best and capturing this chaos Are we trying to say that a c&i instance? Is extensively on being updated or are we saying the c&i specifications? so that Is you know Do we know if c&i itself is the actual spec is being is being updated? Because that that's been very that's been stable for a very long time. So Historically, they haven't added these additional features onto it. So Is is that just the additional kubernetes requirements are being added on or is it specifically are there specific changes occurring in c&i in the c&i spec itself that That we should be aware of I think c&i itself has been very stable. Yeah Yeah, that's that's my understanding as well. I'm thinking about this in the the historical context So if it's probably not relevant at this point in time at the beginning though, they did On the journey to stable um I feel like It was pretty flexible in getting it to where it needed to be but then once They hit what they wanted it definitely sort of completely ground to a halt and Obviously that standardization is you know stable portability is its big selling feature. So it's not something they want to mess with the whole bunch Yeah, and interestingly from a historical side c&i was not originally designed for kubernetes, but instead was designed for CoroS and fleet and They tried to put live neprekin first, but there were some issues there Won't go into it for what happened in historically at this point, but Then so so the actual c&i has been relatively well defined since then. I don't think it had chaining Within it. That was the biggest change that they added on was was chaining but It's been relatively stable since 2016 ish, I think trying to think of the right way to say this so we have to decoupling it has facilitated the integration to things like kubernetes um I'm trying to find some way to capture in words this notion that if I am a network developer As long as I build against the specification I have a expectation that My stuff is just going to work, which we know isn't the case but like It's not like you know Trying to think like the nearest example I have is like right before the csi came about and like Doing storage there for a while was a nut roll because everybody was doing it very very differently. Um I don't know the right way to capture this in words, but I think you can just put a period here network developers. Are we able to build against this specification? I think that tells you everything you need to know Okay, so think this is not my strong suit so it's helpful to have you guys reel me in um, okay, so This is a little weird like problem it addresses versus how it helps I could just drop This last sentence under the how it helps I'd say that's helpful in my opinion I mean, I know from the kubernetes context Just management is a lot easier with the concept of like pot addressing being handled for you. Um, things like that, but That's not cni specific. I mean it's something that the cni helps you with in a specific implementation but Oh, one another thing as well, and I don't know if this should fit into the wording or not, but If it doesn't cni itself doesn't even call for the creation of an interface. It's actually not interface specific so One really good example of where this played out really really early on was when we were talking about some of the multiple stuff in 2016 ish, I think 2016 2017 time you're it the The Initial wording of it was well, let's get actually the name of the group was the multi interface group and The people from calico pushed against it saying they had no intention of including additional interfaces to it Uh, but instead they wanted to render the changes as part of the same interface So whether the quality of service or or similar so Um, the cni itself doesn't even call for a specific addition of an interface It primarily deals with that ip that ip connectivity So a little bit of a nuance it may it's one that we may not care about capturing here But it's when in the wording we should be careful to to not Mislead us as well Well, we're specific about kubernetes having adopted cna cni for a purpose. So that's inside kubernetes Now extensions other things that people do with cni might not do that But kubernetes itself I think that sentence is correct that kubernetes has adopted cni for creating network interfaces allocating ip addresses for pods and other resources Yeah, that's absolutely true. So that is the primary purpose like kubernetes wants the networking space to have an interface as part of the contract which includes ip connectivity and How you do that? Uh, it's just your cni Right and and that first sentence is true as well that the cni is a container specification for creating network plugins for containers That's open enough that, you know, it can allow for everything you just mentioned Cool Yeah, sorry about impotency here. I just I want to make sure that we're so we're careful Keep in mind this is just going to be a pull request too. So we don't have to Knock it out of the park on our first swing um Hopefully some other contributors in the scenes you have glossary to will Sprinkle their own commentary in here. Um I'm just going to go ahead and we should get the office in here to hawken though We should ask them how can it take a look at the the definition as well to see what he thinks Is he in the senior? Um working group get just tag him in the comments I don't know I'm going to really quick then um I think we have a good starting point We can always circle back next monday if we want to or just put in a pr to the glossary and see how that goes Um, I do want to give the last 15 minutes though to the glossary which full disclosure I am a little bit behind on since returning from my military obligation. So You guys will have to bear with me and kind of Help lead this conversation on where we're at right now with this Is layer three the statement about the layer three is all correct. Um, because it you're talking about in the um, yeah Just reply in the comments on what you think we need to okay. Sure. I'll do that. Yeah So so jeffrey uh to to kind of go to that um pr About our glossary um I we don't have too much time to discuss but I wanted to make a meta comment.  Um uh We've been discussing this pr for for a while and I know I I put a whole bunch of things here in the glossary and there Was a lot to discuss but I I'd like to make a maybe general suggestion for the group. I know we're using github and pull requests for For collaborative work a lot of advantages to that but uh Look guys, we're not we're not this isn't a source code for building We're not breaking builds when we accept the pr. I know it's important to accept things that are good But there might be some sort of limits to how much we can discuss everything because this group can Can't wax philosophical about almost anything. That's that's kind of what we do I I want to suggest that maybe we can move to a mode of You know commit quickly build quickly, you know, the the open source model of you know Move along quickly. So, you know, we can we can accept prs that might have issues But then, you know, somebody can create another pr quickly that fixes those um I think if we're if we're gonna try to have every single line be absolutely perfect for everybody I I I just don't want us to waste so much time on on uh Individual prs. I feel like we have a lot of work to do and uh I'm not trying to shove my pr through. I'm not trying to do that. I'm I'm I'm really happy with all the discussions going on around this um But then I I I'm not the right person to click resolve on a discussion There there's a lot of things in that discussion that are worth opening up to the group um But we're tying the discussions to the pr as well in a way that just makes it really really hard to get these prs through I don't know what people think about that Cal um I appreciate the idea of trying to get things through quicker and iterative I think some of the early stuff on all of this um Including like the white papers was let's get stuff out and get discussions about it. So that's good one thing that would help would be um smaller prs specifically when there's discussion items. So this one isn't this particular pr Is One filled with discussions because it's the glossary if it was a use case Then it's a lot different. We need definitions For what's talked about in a use case But this is the global definitions that we want to agree to that we're expecting Other people to say yeah that we agree and let's move forward. So anytime This would be the same as code if you're doing a massive code change for comments and code then we just go It looks good. Don't worry about it. But if if it's doing something like changing How A storage driver and and the kernel is working and you say I've refactored all of it Then it's going to get blocked for a long time and I would consider this the same thing From the standpoint of what we're trying to do is communicate with kubernetes community kubernetes Communicate with all of the networking community. So we need to have This sort of thing broken down smaller And going forward I would suggest that for everyone else Yeah, I would say tal because this happened to me in my first attempt at the glossary Um, I kind of changed my methodology even if you have a big write-up I would just do each definition as its own pr That way if there's things that you know Aren't going to have a worn piece discussion written about them Then we can just get them pushed But like this was what happened the first time I made a thing is I had like three or four definitions at once I needed to like whack in the rest of them because You know, there was three definitions that would have gone through with no issue But then there was one that tied up the entire pr. So We've got this one here. I'm open to what the group thinks on I mean the simple thing Tal is just get five people to review it and accept it because then it meets the quota that we set forth, right? But I would say in the future like this isn't something I've learned and I think we're seeing in here is I would just break every single definition anytime you involve the glossary or something like that as it's each As its own pr just so like You don't have like 80 of your stuff get hung up by like the 20 percent that everybody wants to pontificate about Uh, yeah, I appreciate that I'll try to do that in the future A few of these glossary terms speak to each other So they might it might not have been a separate pr for each but it could have been broken up into a few prs for sure Uh, anyway, we are where we are with this I I uh, I resolved a few conversations. I wonder if we can We have sometime we can go over what's remaining and see if there are any more objections or desires to fix I also went ahead and squashed all the commits and um So so now everything is a single commit instead of uh the mess it was before So I think the the big one might be about uh pnfs. I think um, there are a few comments about how The pnf definition could be fixed. Um If anybody would like to reword it right now, I'd be happy to do that Jeffrey, can you bring up the view where it shows? Um, that the other view where it just shows all the definitions Might be easier Under files changes file changes and Right right at the top. Um below the review changes There's a code icon in it. Yep. There you go. Yep. You had it rifted You're done Right All right, all right Yeah, I would uh, probably add that it's generally Other than the api that is exposed it exposes. It's generally a black box to the uh, to the consumers Um, so we we get no is it always Not if it's a white box Right, like there's literally a pnf. They call it a white box just because it breaks that paradigm Well, white box is still going over a specific type of thing like they're using mac comp to To configure it Do you have visibility into the actual like a little level hardware details and similar? Through through that I suppose you do in that case Yeah, this is kind of a nuanced thing, especially in the provider world I would say people tell you they do But typically it's them working With um the be used at the various vendors like if you look at something like, I don't know like a Tofino chip or one of these third-party asics that you know, you can Shift and lift resources to different things. I want more in this tkm or something like that. Um I would say you sort of do but you know If you're not the one writing like the embedded codes yourself You're kind of kidding yourself if you really think you Are looking that deeply into it, but I don't think I don't think you could call it a black box though Just because I think most vendors would complain about how those of us on the provider side Demand that like their BU representative gets on a call and like unpack every little secret because we want to know how it all works And drive them crazy, so Yeah, I feel black boxes I use the word encapsulation and isolation and um To me that's that's what it's about whether it's in a black box or an open box Black box is almost a derogatory term, isn't it? Every vendor would like their Well, I I don't I don't tend to see it, but maybe others do because like if I I can create a A linux system and I can say it's based on red hat And all I do is give you a very specific interface to use it You know how everything works inside of it, but your your actual capability to use and affect it are entirely encapsulated by that API So to you it's a black box from a from a usage perspective despite the fact, you know how all the internals work So that that was the mentality I was thinking about the encapsulation that does capture that that that as a point might be worth future Documentation what when a black box in a white box is valuable? But you know the reason we talk about things as black boxes Is not because you don't have interest in how they're being constructed But if you're working with a vendor then if they tell you how it's constructed and then at some point They choose to change how it's constructed Then they have to clear that with you which is really problematic Whereas if it's just you don't know or care how it's constructed You just need to know it's working and here's the definition of working. Then that's a lot more simple to work with Yeah, so real quick because I want to stay on this p&f thing because we have five minutes left I actually to Ian's point though This is the last I'll say it is I think it should be a best practice One of the things that I think went terribly the wrong with mano was You know the fc diagram showed a bunch of these like arbitrary boxes And then service providers thought that they could mix and match those arbitrary boxes Which made the integration of the software a bear. So Um, I think that that's a future discussion where we talk about like if you have a good interface maybe people should just Consume it versus trying to reverse engineer it but As far as p&f's go though Does anybody with the modifications that are in place now have any like Burning questions or comments Can we just simplify it that it is a basically it's an implementation with a tight coupling of hardware and software And make p&f's that Well, I I My problem with that definition is that I think a lot of cnf's and vnf's you can say the same thing about them Well, they wouldn't have they if they were a true cnf or a vnf They wouldn't have a tight coupling of the software and hardware because you have a virtualization layer in between Well, if there's a spectrum of coupling it could be tight coupling and it can be loose coupling and it could be something in between Yeah, but we're talking of we have Or we can say that the software implementation is highly dependent on the underlying hardware I To me the main issue is that it's discreet that is it is separate The p&f is a box that is not part of your cluster. It's not part of your your cloud How it's built internally I think Is beside the point almost of the the definition of the p&f right if it's open if it's closed if it's Allows you to install things the point is that it's not part of your cloud I think I think for the kind of discussions that we have In the cnf working group that is the defining feature in my view so when you're discussing in that manner you're discussing about the Software but a p&f could be part of the cloud infrastructure. It could be part of the underlying infrastructure that you have Okay, if it's a discreet box if it's a discreet box If a p&f is a software element, which is highly dependent on some hardware Then it's slightly different To be honest, uh, it's done from bell by the previous definition that tal did I think is actually the right good enough one is uh And I think he answered as the same thing is how it's wired underneath whether it's using all kind of Open principles and open interfaces the fact that you don't and you know actually explain it pretty well You don't you should not care and you don't really under have a say on whether the vendor decides to change from specific specific api to go from the control plane to the azik or something else. It's just you get you get a Isolated box that you plug into your network Yeah, I think I'm personally good with this definition I think the key word here that tal put in is discreet and that's really What kind of makes it different, you know, because you can couple um c&f c&f's whatever But like the kind like the main notion in my mind and this is sort of what um I someone else was saying Was um the fact that it's discreet means that this software is designed for this hardware Versus, you know the vnf and the c&f for trying to break that paradigm I actually like that this one is kind of sweet but still kind of gets the message across in my opinion Yeah Yeah, sorry for Honestly, I like I'm liking this definition more and more so I'm glad I I do, you know the discussion here is very interesting the the issue of black boxes and Just how discreet things are and with regards to mano is an important one that I think we'll have to continue to discuss because This black box idea is not just we don't just see it in p&f So we see it and the etsy approach to network functions generally every network function to an extent If you look at the mano architecture is like a black box and the point is that You supposedly chain together these black boxes into a network surface, but as I keep saying This uh this very strong Separation between network functions and network services. I'm not sure it always serves us well I don't think it ever existed for what it's worth, but yeah, I mean if you're going to define a black box You've got to be very clear about what the outside of the box looks like and I think that was the problem, right? It isn't that it's a black box. That's a problem It was that it was an ill-defined black box that was the problem. Anyway, um kind of again secondary to the p&f compensation I have to drop friends. Um I'm going to look at the rest of this pr, but yeah, I think what we have here for p&f is good in my book I'm happy with this. So I will look over the rest Take a peek at um Taylor's recent thing. I kind of agree with him that cloudified is kind of wonky So, um, I'll kind of work asynchronously with the group here. Have a great week everyone and I'll talk to you soon Thank you everyone


After announcing he was moving his podcast to Austin, Texas a few years back, Joe Rogan also moved his family home there, which is where he's been living ever since. While his mansion in Austin was about four times more expensive than his former property in LA, with a price tag of $14.4 million, Joe can afford it. His beautiful Texas home spans nearly 11,000 square feet of modern living space, with features like a full gym, sauna, pool, and much more. All interiors have details like exposed concrete walls, soaring ceilings, and wooden floors. No wonder!


So, hello everybody, my name is Roberto Lineros and I'm going to be the host of this webinar. So before to start, let me just remind that we have a different configuration this time, for instance. Now, if you want to make questions for the host, I mean for the speaker, you have to go to the Q&A in the YouTube live chat, so if you are following this stream in YouTube, for sure you're going to see a small chat in the right part of your screen. So there you can write a question and then afterwards I'm going to ask to Nestor about this. So, now also we have a WordPress page in which you can follow all the previous webinars that we have done in the past. You can watch it again and maybe comments and make questions to the host. We're going to try to connect, I mean to the speakers, I'm going to try to contact them in order to answer these questions. So let's start with what is the big thing of today. The speaker is going to be Nestor Mirabal. He is now an NPP senior fellow at NASA GoodWard Space Flight Center. He before obtained a PhD in the University of Columbia and after that he did a post talk in the University Complutancy. So the title of his talk is Identifying Dark Matters of Halos with Fermi. But before to start with the talk of Nestor, I want just to let you know that we have a very important invited person in the Hangout session. We have Luke, Miguel Angel, Roberto Ruiz, Adelostri and Roberto Munoz and they are going to also be participating in the discussion after the Nestor webinar. So if Nestor is ready, maybe you can start. Okay. Thank you Roberto. And thank you so much for the invitation. I think this is a really great initiative to do this talk. I'm born and raised in Venezuela, although I've lived most of my life away, but I think doing this for Latin America is a great idea. So my talk today will be about using machine learning to find dark matter subhalo candidates with Fermi. And the outline of the talk is we'll have three parts, mainly an introduction. Then I will talk about subhalo searches using machine learning and I will briefly mention where we go from here. The level of the talk for some people might seem low at times. I apologize for that, but I didn't know what the level of knowledge about different things was. So I'll start from the very beginning and move on from there. So let's start with what dark matter is and a brief history of what we suspect, why we suspect there's something that we're missing in particle physics. Already in 1933, Swicky had realized that the burial mass in the chroma cluster was much more than what was measured from galaxies in the actual cluster. He called this kind of dark matter because he didn't understand where the mass was coming from. And that idea was readily untouched for many years until rotation curves from spiral galaxies started to show this weird behavior. I'm showing one here on the right. There were the radial velocity of stars in spiral galaxies of these regions, instead of going down as expected in our Keplerian orbit, they kept almost a straight line, which means that even outside the disk, which seems to go down in mass in the visual, there seems to be additional mass that we're not detecting. That is consistent with the same thing that Swicky was detecting. On the lower left here, I'm showing a plot of the blue light cluster, the bright yellow is the X-ray emission, and the contours show where most of the mass could be. So we're basically, the gas is not tracing most of the mass in this image. So again, this is all coming to the same conclusion. We're missing some mass, we're not detecting, at least in the visual, or even in other wavelengths, we're not detecting this mass directly. And this is what we call dark matter. From the very beginning, there have been many ideas to try to explain what dark matter is. Most of them are related to missing particles in the standard model. For most of this talk, there are so many theories that I wouldn't have time to talk about them, even in a few sessions of this seminar. But for this particular talk, I will only prefer to win two weekly interacting mass particles. This is a prototype for cold dark matter, and that's where most of the searches that I will describe are centered on. There are many other options, but I will not touch on those today. So if we take this cold dark matter to even a large scale, it seems to reproduce what we see in the universe, more or less these very large structures. If we model this in time, we see that structures seem to start forming and take more, a better shape, moving forward, receiving more density and more structure, but the scale here is quite huge. If we go to the present day, some of the brightest dots here are the brightest clusters of galaxies and the biggest galaxies that we know of, but again, this is very large scale. So again, for this talk, we want to zoom in into one of these regions and go more to a kiloparsec scale, to a galactic scale, something like our galaxy. What happens around our galaxy in terms of dark matter? So if we do a zoom in kiloparsec scale, this is from the Aquarius project, we see that these numerical simulations of dark matter reproduce what we see in the measurements in spiral galaxies. We see this kind of dark halo that we're not detecting in the optical, but it seems to be there in the simulations, this fuzzy halo that we see in this picture. I plotted here kind of the scale of the galaxy, the inset here, and on one of the predictions in kiloparsec scale is that there should be a lot of substructure around galaxies like ours. It should be hundreds or even thousands of these things that we call subhalos, because they're part of a much larger halo of dark matter, should be many of these things. The brightest things are what we call dwarf galaxies, we have detected many of those faint ones are probably what we refer to as ultra-faint galaxies, these are things with very few stars. But again, we know only tens of those, we have measured only tens of those, we expect hundreds or even thousands of these things, and many of them we expect will not have any stars in them, so how do we find these things? And this is the purpose of this project, and what we want to do is try to find these subhalos using Fermi, this is a very small scale representation of what Fermi is doing in the universe, trying to look for dark matter in this huge structure, but we'll be mainly looking for things very nearby in this picture. So what is Fermi? Fermi Large Area Telescope, Fermi Large Area Telescope is a per conversion telescope, it's a huge field of view on 2.4 stadiums, covers the whole sky every three hours, it's in survey mode all the time, so covering the whole sky, it's almost a square meter in an effective area, and one of the key things that we'll pop up later is the resolution, the point of view spread function is only in the order of tens of degree, a few arc minutes in size, the resolution is the best we have achieved, but it's not comparable to other wavelengths, and this represents a problem and maybe an opportunity, as we will see later. So and why is Fermi Large suited for this type of searches? Because we think we can look for gamma rays from wind panel regulation, the fact that we haven't detected dark matter doesn't mean that it's not there, we just have to find it, and the key equation for that is this presented here, the first term is particle physics, we assume that the wind panel regulation will produce a standard model of particles, and this will decay into gamma rays, and this will create this highly curved spectra that are shown here on the lower left, a very distinctive spectra that we can look for, and basically the scaling factor here, how bright or how faint this thing will be is a function of the distance, square, how far this object is from us, and the mass of the density, basically how many dark matter particles are there to detect, so this J factor, the higher the J factor, the brighter this flux in the instrument should be, and we're expecting that these wimps are mainly in this region in the switch spot for Fermi Large, actually 10 GeV to 1 TeV mass range, so this is very well suited for the energies covered by the Fermi Large, so this is a very feasible search, and it makes complete sense to do this. So if we go back to this picture, again this is what we're showing here, it's just the dark matter particles simulated over many years, if we want to see what this map looks like, and the particles were annihilating, it would look something like this, what I have in this next slide, so the brightest spot would be this bright halo, this big halo that probably creates this flat rotation curve in galaxies, but if there would be a huge collection of point sources around us, that should pop up quite easily, again the biggest points here should be nearby dwarf galaxies, but there should be many, many of these subhalos, small subhalos or nearby subhalos that could be detected as well. So how does this compare to the actual view from Fermi? Well, it sort of resembles that, but it's more complicated, with Fermi we see many other things apart from dark matter, so this map here is, I think it's based on seven years of data from Fermi, and you can see basically the disc of the galaxy is quite clear, and then we see many of these point sources here, and you would say, well, you have to take the dark matter, but that's not the case so fast, because actually these are mainly black holes and neutron stars that have also made gamma rays, so most of these point sources that you see in this map are actually black holes, active-galactic nuclei, jets of active-galactic nuclei that we are detecting as the large majority of sources that make up the sky. So in a way, we have to deconstruct this map in different slices and try to find the dark matter component. So the diffuses, mainly gas in the galaxy, particles in the galaxy that create this glow, then there are all these black holes and neutron stars that exist around us, and there's an isotropic component from things that are not resolved from very far away. So if we can model these three slices, then we'll be left with hopefully the dark matter component. So is there even room for this subhalos in Fermi? So it turns out that there is room. We've only identified two-thirds of these point sources that we see here. So about one-third of all point sources that have been identified by Fermi don't have a counterpart. We call this unassociated. We haven't identified the source that creates the gamma rays. And this is a huge discovery space that we want to explore. So why are these things unassociated? And again, we go back to what I said before. The point spread function in Fermi is a few tenths of a degree, in the best case. So picture the moon, the moon subtends about a half of the day on the sky. So the localization for Fermi is usually really a third of what the moon subtends in the sky. So it's a huge area in the sky, actually, because inside this blue circle that I'm showing here, if you want to think of the moon, there will be thousands or hundreds of traders. If you're looking for what is responsible, the trader responsible for something, you would have to distinguish between hundreds or thousands of traders, and that's very hard. In our case, we're looking for actually the one source that is creating the emission, the gamma ray emission. And here on the background, you can see a typical optical sky. I'm putting different circles here for Fermi. This is with different event selections. But even with the best event selections and brightest sources, the error ellipse is still quite large. So there are many possible candidates to produce the gamma ray emission inside the circle. So that's why for many sources, it's not that obvious which one of these is making the emission. In this case, we suspect this one is probably a neutron star in this case. But again, it's a big problem because with this technique of measuring gamma rays, it's very hard to localize a source in the sky. In other wavelengths, the localization is quite tiny. I mean, you wouldn't even see a circle because it's quite small. It's in the arc-second scale. So that's not a problem, usually. Next, you see that it's usually the worst localization. But in gamma rays, this is a big problem. But again, it's an opportunity at the same time. Many of these things, or some of them, could be these dark matters of hell as we're looking for. So people have explored this discovery area, these unassociated sources, and mainly what hasn't been done so far is look for this highly curved spectra that I showed before and find objects that are recently fit by these theoretical expectations. Here's a good example here from Bertone et al. That shows this type of fit to one of the sources. So what we ask was quite simple. Can we do this in a different way? Can we train a computer to look for these candidates directly using the catalog from Fermi, the source catalog from Fermi? And this is mainly the work that I will describe today. This is a systematic search for subhalos using machine learning. And by machine learning, I'll go to a very basic explanation from Arthur Samuel from 1959. This is one of the pioneers of machine learning. Is there a field of study that gives computers the ability to learn without being explicitly programmed? So what that means, in this case, for the rest of the talk, I'm only going to talk about machine learning algorithms based on decision trees. And a decision tree is something very similar to what we do in everyday life, how we make decisions. It's just if and then are nodes that we use every day to process things. Human decisions are very basic. We can compute two or three variables at a time and make basic decisions. It's something highly curved, yes, now and then going from there. For a computer, these type of decisions, they can handle many more variables at the same time. So you can process hundreds of variables or even thousands of variables at the same time because a computer can construct these, if then, networks very easily and can come up with decisions. So basically what one has to give the computer is the algorithm to construct these networks and how these networks are weighted and how they deal with the decisions. But other than that, we don't program the computer at all. That's what machine learning is. I will show you a better workaround of this a bit later. So where do we learn from? And one of the things that was realized early on is these neutron stars that dominate the capital. We have 200 neutron stars or pole stars have a very highly curved spectra. Very similar to dark matter in the few tens of GEDs. So we could train our computer with theoretical models, but actually we have things that are almost identical to these models and have gone through our detector. So we have characterized 200 of these things. And maybe we can just use them directly to train the algorithms to find more things that look like that, very highly curved spectra. And this is what we have done. Where do we get the information? This is taken from the Fermi catalogs. This is one of the main outputs from the lab collaboration. This is 75 columns per source and the latest catalog that are more than 3,000 sources like this. And we have all the spectra information, variability of the source, location, lots and lots of information that have been done by the collaboration already. So we just want to use this table directly to look for the subhalos without doing any fitting. So this is the basic structure for a machine learning algorithm. We get a data set. In this case, we'll use this almost 200 pole stars. This will be the highly curved sources. And the things that we don't want are these black holes that tend to have this power loss spectra. So they're very distinct spectrally. So dark matter would most likely resemble something very highly curved. So we take two thirds of all these objects to train the model. We use two different algorithms for that, random forest and extreme gradient boosting. These are three base algorithms. And they produce more or less the same results. With the one third of cases that we left out, we can test how well the model does. So we built this network of decision trees with two thirds. And then we run one third of the cases through this network to see how well we do, because we have labels for them. So typically, we only miss less than 3% of all cases. We only miss identifications are very low. So then we take our model and apply it to about 1,000 unassociated sources that are there in the catalog. And in this huge data set, we find 14 more of these highly curved candidates at a latitude higher than 20 degrees. So what does this mean in terms of dark matter? We have to put this in some context. This number doesn't mean much. If these things, these 14 objects, are dark matter subhalos. It's pretty dark matter subhalos. We can see how that translates into an annihilation cross section. So this black dots, this plot is the predicted number of subhalos as a function of annihilation cross section. This is from Bertoni et al. 2015. This is for dark matter annihilation into bottom park. And the black dots here is this number 14. This is the prediction how many subhalos would we expect if an observer was detecting this huge collection from our location in the galaxy as a function of annihilation cross section. So actually, this number 14 is more or less what we expect for this thermal cross section of WIMS. It's really encouraging because it's approaching this prediction that for WIMS, the thermal cross section should be around 3 times 10 to the minus 26 cubic centimeters over a second. So this is promising. But again, is this the only explanation? We will talk about that in the next slide. And just to place this, this limits in comparison to what has been done with Fermi, Fermi can do measure this, can look for dark matter in many other ways. What are satellite galaxies in the galactic center in the halo in clusters of galaxies? All these curves are basically looking for dark matter in many, many other places. And this green thick curve is what we obtain with this work. And around 50 GB, they tend to converge more or less. Below 30 GB, you start reaching even under the thermal cross section. So many methods are converging on these upper limits. We're not detecting dark matter to very faint limits. The faintest here is from dwarf galaxies. It's very promising that the limit from subhalos is consistent with this. What else could it be? We did some simulations of these neutron stars to see how many more would we expect in the catalog that we haven't detected. This is running a simulation over 13 billion years, the age of the galaxy. We can see that from the simulations, we expect at least 10 to 20 additional millisecond pulsars in the catalog that we haven't found. It's very similar, highly curved spectrum. So again, since we're looking for things that are very similar around dark matter annihilation around a few 10 GBs, we'll be very similar to these detected neutron stars. These things could be pulsars as well. So it turns out that from the list we've made of 34 objects above 5 degrees from the galactic plane, so far, 8 has been ruled as pulsars. And many of the others, people are working on them, but sometimes they're very faint. But this is the only way of pulsation. Finding the pulsation from the neutron star as it spins around is the only way to distinguish the two. So this work needs to continue. Some of these things could be dark matter, but we still don't know. We still need to work on that. So where do we go from here? Showing a projection of the sensitivity that Fermi will attain in 15 years of operations. And below 200 GB, this is quite impressive. I mean, it will explore areas well below the thermal cross section. This will be fantastic. Again, this is with different methods that we should converge and find similar results. And hopefully, in 15 years, this won't be a limit, but this could be well at a detection. And we hope for that. We hope to keep trying. Above 200 GB, I think the future will be the main driver will be the Cherenkov telescope array. This is a ground-based array that is being built with a combination of large, medium, and small-sized telescopes. This is using the technique known as Cherenkov, imagine Cherenkov telescope. Basically, any gamma ray impacting the atmosphere will produce a cascade of Cherenkov photons that can be detected by this array. This is quite powerful, above 200 GB. I'm pushing the limits to only 300 GB. And this will be on a very operated with one side in the north and one in the south. And it will totally beat what we have, the current instruments, similar instruments by a factor of 10. We expect that these things will be a factor of 10 more sensitive than current ground-based telescopes. And this will cover the area above 200 GB. So the main search area for subhalos will be this key project to image a quarter of the sky. The huge advantage with Fermi is that you can cover the whole sky every three hours. That is amazing, but no instrument from the ground can do that. So the best CTA can do is slowly but surely cover one fourth of the sky to probably five nmig crab insensitivity. And this will be an area that will include the north Fermi bobble, but we know the north Fermi bobble. It's a structure above the galactic plane. It will cover Virgo, Coma, and Senei, among other things. And maybe from this imaging, we'll find these things that don't have a counterpart. It could be due to dark matter, just of direct signature of subhalos. So putting this together on the green, we have Fermi in 10 years, in red. This is CTA north. Magenta CTA south in red, magenta CTA north, in blue hawk. So the search, there will be almost no gap in the search for wins from tens of GB to hopefully 300 GB or more. And this will let us explore everything that is there in the sky. Putting the sensitivity, the 15 years, this is the projection for Fermi in 15 years. And the dotted lines, the red lines, are mainly CTA lines. And you see that it will also go below the thermal cross section above 200 GB. This will be a key observation to see subhalos or dark matter in other parts of the sky or there. The timeline construction has begun in the northern side especially. Hopefully in five to six years, we will be getting the first sign verification data. And the hope is that Fermi will continue to operate while CTA is functioning. Because that is the ideal scenario, both Fermi and CTA working together. So just to summarize what I've done through so far, the Fermi mission is playing a key role in the hunt for dark matter. Machine learning algorithms are very good to pin down promising targets. For dark matter, the number of these highly curved candidates matches the prediction for a thermal cross section. But unfortunately, the numbers are also consistent with what you expect from undiscovered millisecond pulsars in the Fermi catalog. So the only way to tell these things apart is pulsation, finding the pulsation from the object. And work is ongoing on that. And for the future, Fermi and CTA operating together with Hock might finally solve the dark matter mystery. I will stop there and open the floor for questions if you have any. Thank you. Thank you very much, Nestor. It was very interesting to talk. So I can, sorry, OK. So just to tell to the audience, before to start with the question from the people from this Hangout session, that you can make any questions in the Q&A in the YouTube live chat. So if you are following this in YouTube, it's easy to find. If you are following the transmission in the WordPress page, please, you can click on the link that is down to the YouTube live chat. So maybe we can start with questions from the people that is here for the audience of the participant of the Hangout session. I don't know. Someone has a question? Yes, I have one question. Can you hear me? Yes. We can hear you. OK, I think everything that you have shown is based on the dark matter annihilation to BB bar, right? So if you change the channel to W plus W minus, did it change significantly or not? Or everything remains basically the same? Let me go back to if I can find this plot here. Mainly, we've tried, again, we're using the pulsar as a proxy for dark matter. So a pulsar is most like BB bar, I would say. But if you see in this plot, many of the channels have this very distinct curvature. You're right that probably for W's, it might make a slight difference. But if the decay channel has this highly curved structure, then you would get it regardless of what the channel is. So we haven't tried other channels, flatter channels we haven't tried. Basically, this concentrates on this highly curved decays. So only BB bar, tau are the main ones. OK, thank you. So I have a question. Can you hear me? Yes. OK, so I'm Roberto Muñoz. OK. I'm an astronomer, but I've been working in Virgo and Fornax cluster because we're looking for dwarf galaxies. Sure. And for sure, those dwarf galaxies are quite small, like let's say like to be detected by Fermi. But still, I think that's the opportunity is CTA, OK? So my question, I have a question related to the machine learning model you are using. All the columns, all the features you are using were measured on the data. Like let's say you have a standard pipeline to measure quantities from the spectra you get from Fermi. And then you train the model. So anyone have tried to basically apply a different approach, let's say try to compute different features that people used to compute? Or? Well, so let me see if I can go to this one. For instance, this is a typical Fermi spectrum. I don't know if you are using the screen now. Yes. OK. So unfortunately, the amount of photons we have is not the same as in the optical. So you're dealing with spectra, we call this spectra. We wish we had something like an optical spectrum. But this is very far from me. Unless the source is very bright, it's very hard to get a lot of structure out of the sources. So the beams are quite large. And the scatter is present. You can see that probably this source is not as a structure. But this is the best we can do. But I think it's worth looking into small features, but finding significance in this type of spectra will be difficult to prove. But it's worth looking into. People have done it in the past. People have looked for lines. But so far, lines is the main search. But lines have not resulted in anything positive, significant, at this point. OK. And right now, basically, you're mostly focusing in that matter or annihilation processes that could occur in the Milky Way, or could be any extragalactic source? It could be any source. The problem is distance. So even in 931, to firm me, it's only a few photons. This is a challenge. We wish we had a larger area, but we don't. And then in terms of clusters, I think this is very interesting what has been going on with clusters and all these galaxies that are being found. But one problem that will be there is that we also might expect gamma rays from the cluster interstellar, intercluster medium. So detecting a galaxy in a cluster will even be a huge challenge, too. So but the main challenge is distance. I mean, the easiest thing to detect is our nearby and massive. So even, as I said, M31 looks like a fuzzy thing to us. So the closer the better. If you can find a cluster next to us, that would be amazing. OK, thanks. OK, I don't know. Are there more questions from the? There is one from me right now, please. OK, I have one more question. So did you also try, because you used random forest and XGBoost on basically features that are figured out by humans from the raw data of Fermi? But they are basically like two dimensional counts, right? So did you also try something like a deep learning network or a convolutional network on this data so that it can figure out the important features itself and then go further on that? I think we haven't. I think that's the next challenge. That's always something I like to do. But again, the challenge is that dealing with very few photons is very difficult. So the production of the catalogs, it's an amazing undertaking. So even extracting all the features for one source, it's very time consuming. So I mean, the ideal thing would be to face the sky with an algorithm. But I think it might take more time to do that. But I think that's the next thing to try to do it blindly on supervised. Yeah, OK, thanks. So someone else was with another question, no? Yeah, I may have a question. Please. So it's also related to this differentiation between pulsars and dog matter, next to. So giving all the somehow negative answers that you have given us in the last few minutes about this. So can you actually foresee any kind, any way to proceed in the near future regarding this? So are there any ways that you can think of to actually do better with this differentiation? And related to this, for instance, with CTA, you don't have this problem in principle, because pulsars are basically not respected at those high energies, right? So in that regard, CTA would be an ideal instrument for at least to get rid of all this contamination from pulsars, right? Can you comment a bit farther? You're right. I think CTA, the only thing we probably, and Alberto Amingas is probably someone to ask about that, would be ADN with this weird EVAL features that might create something like that. So I'm not sure if you can create objects, highly curved objects with the EVAL, might be possible. So that could be a problem for CTA if things like that are there. I think in that case, if I can comment a bit, maybe. And in that case, I think you cannot expect a bump that happens in a much wider energy range. So maybe of factor 10, like maybe one or another might do, actually, in energy. So that would be a possible difference between an EVAL and ready feature and a source. But probably also you're right there. But again, yeah, pulsars won't be a problem for CTA. For Fermi, unfortunately, well, your own expertise, you know what spectra we're dealing with. So I think pulsation is the only way. And what we can do selecting these candidates is to give the pulsar guys. There are many people running these pulsar searchers, the Einstein consortium, and many, many people who use huge computer power to look for pulsations because you're dealing with very few photons here. So it's very hard to find the pulsation. So I think at the end of the day, there will be many sources which remain without pulsation. People will have to look for counterparts in other wavelengths. And those sources that are really mute, that don't show anything, I mean, will have to hunt them down to see what they are. I mean, whatever is left at the end of the day might be the most interesting. But it will take time to get there. That's the only way I see. Because as Fermi pushes to fainter limits, he will find many, many more candidates. But it will be harder and harder to find pulsation. So I think what I would do is go from brighter to fainter and try to keep ruling out sources slowly. Whatever is left at the end could be it. But it's a lot of work. It's a lot of work. I fully agree in this. So also as a person working in the field like you, I'm also worried about the if we can actually use this approach to claim any kind of discovery. So that's a completely different discussion, I would say. So how really to say, even if you are left with just one single source, that matches pretty well what you expect from that maturation and so on. Still, how can you claim? How can you use that object to really claim any kind of discovery? So I think, yeah. So then, as you know, we have to find it someplace else too. I mean, it has to be in the galactic center. It has to endure galaxies. If we don't find it, then there is something inconsistent in the model at some point. So we have to find candidates. And to make a claim, you really need at least detection in two different type of sources, I would say. I mean, that's what would be my minimum requirement to claim such a thing, to find it in subhalos and the galactic center or subhalos and dwarf galaxies or subhalos and clusters of galaxies, at least find two distinct populations where you find these things, where you find the same signature. So but we have to talk and talk and sit down and figure out what to do. OK, so our total questions here in the audience. Maybe we can start with from the Q&A. There is one question from Andres Perez. The first of all, he's acknowledged your nice talk, Nestor. And the question is, if the amount of subhalos candidate is compatible with the cold dark matter simulation, the prediction of the cold dark matter simulations? I guess. Yeah, so I was given the constraining time. I didn't fully, I don't think I did a good job explaining where this figure comes from. So the way this plot is made, this prediction is made, this predicted number of sources is basically placing an observer inside these simulations of cold dark matter and saying, if this observer has Fermi in his hands, how many subhalos would he be able to detect in these simulations? So this is where these numbers come from. So the numbers, again, are consistent with cold dark matter simulations because they are coming from cold dark matter simulations. So maybe there's some sort of weird bias here because we're using these simulations to interpret the observations, but it's the only tool we have so far. Yeah, so the numbers are fully consistent because these predictions are coming from the best cold dark matter simulations of Milky Way size galaxies that we have. OK, so a little bit to continue with this question. So that means that this, because the cold dark matter only simulation, usually people, they have this argument that they overestimate of subhalos. So this is kind of the optimistic point of view of the question to look for subhalos because another simulation that includes, for instance, variant feedback, you're going to have less subhalos or dependent cosmology of how they treat the problem. You're right, I mean, I think I don't know if this predicted number of sources deals with that problem directly because what this tells you, this plot is basically how many nearby sources you have. So because of resolution, you're right. I mean, so maybe what this is saying is that we're not resolving things nearby quite well. So you don't see that huge excess in this plot. But you see the excess when you move further out. But that's not represented in this plot because you wouldn't detect that source because it would be too far away. So for the cold dark matter simulations, resolution, and computing power will be key. I mean, that's also another challenge that is left over to do. I mean, if our smaller resolution is 10 to the 5 solar masses, we don't really know much below that. The resolution is not that good to make these predictions. So there is a huge challenge ahead to improve the simulations. And it will be very difficult because this is a lot of computing power. I would like to make a question. Yes. Well, regarding the machine learning part of your talk and the future, what do you think if it is something that will happen that this kind of technology will be used in dark matter searches, not only with Fermi, but with other fields in which we have a lot of data. And we can look for dark matter there. Are you thinking that those methods of machine learning or artificial intelligence will be applying there or will be necessary to apply them into this field? Well, for sure. I mean, if you know what you're looking for, if you have a training set, if you can give the algorithm something to train on, you can basically train on anything. So I think this is actually a quite uneasy machine learning problem because there's not a lot of data here. But these algorithms are thought for even bigger samples. So maybe when surveys, much bigger surveys come online, then if we have an idea of things to look for, then it will be interesting to apply these ideas to that. Because the success of the techniques is even better when there's more data and more things to look for. This is actually quite small in comparison. If you have huge data sets, it is the ideal place to apply machine learning algorithms. And if someone has an idea of what they want to look for, it is very easy to implement. You should. So yeah. So OK. So I guess, Hermann, and there are no more questions here. I have just another question because of the machine learning method at the end, in some sense. So given that to train the algorithm with pool source, the algorithm is able to find new pool source, let's say. But then how confident is to say that a possible source is not pool source. Because at the end, all the time, there is the problem of the statistic in the machine learning problem. I mean, if you have 1 million samples of pool source, I guess the confidence level of a source to be pooled or not is going to be high. But if you have few, maybe there is a misidentification. So yeah, what we do is, I mean, this is the standard way of measuring this is to use the whole data set and leave a fraction of your data set to test how good the algorithm works. And in our case, what we did is to require that two algorithms, which are completely different, have to agree on the classification as well. And we have done also the other thing that we have done is gone back to previous catalogs and applied the methods to see how well the methods perform. And actually, they're quite good. When these things have been applied to previous Fermi catalogs, they find most of the pool source that have been found since then. It works. I mean, the only thing is that, yeah, we might be finding pool source only and not dark matter. That's a disappointing result from a dark matter perspective. But they're quite reliable, I think, because we're still dealing with very bright sources. It is the algorithms are quite reliable. As Fermi pushes on and on to fainter sources, I think the misidentifications will increase. And it will be harder and harder to do this, because there won't be as much data as for bright sources. But we're quite confident that these things are well predicted based on what we have measured from the testing. And maybe you mentioned also that if you start with the approach to starting from theoretical prediction from Pulsar's spectrum, this method can also be performed in some way. Maybe the results are worse, but at least could help to identify Pulsars that are not in the set of Pulsars that you gave to the algorithm. Yeah, that's right. So I don't know, maybe you could know that. But this method is, you know, they have been applied also for, for instance, optical telescopes or radio telescopes that also they have catalogs of very large sources. I mean, the site of dark matter just. Yeah, yeah, yeah. So these methods are starting to be used in many fields in astrophysics. Galaxy classification, for instance, is a huge field. And this transient is also looking for likeers from for very specific things. For a huge surveys like LSD, this will be key because you have millions of objects and you have to identify galaxies. And this is, yeah, people have been doing this for the past decade or even more. Yeah, so these methods are starting slowly to drift into astrophysics. People are using them for many things. Planet transit, I think some applications are even there. So, yeah, the methods are coming, yeah. That's good news. Yeah, so I guess maybe if there are some other question, if not, because in the Q&A there are no more questions. Maybe here, I don't know if someone else doesn't have any question. If not, I guess we can acknowledge thanks to Nestor because of this very nice talk and it was very enlightening to learn about what this is doing in machine learning and family and in the quest of dark matter. So I guess we can close this webinar from today and just let me show this. And just to tell to the people that if you are following us in YouTube, you can subscribe or leave a comment. And if you want to get the latest news about the next webinar, you can check our Facebook page or our WordPress page. So this was the 2009 webinar of this series. This is the last webinar of the season three. So next, we're going to start with the season four and let's see what is the future in this webinar and to know about what is doing people on physics and astroparticle physics. So see you then in the next time. Okay, thank you.


Yeah, this is a birthday present right here for her. She's back, you know? So I'm super happy to have her back. It's beautiful and ready to get home, you know? So let's make it happen. So what is your job? What do you do? Uh, so I'm at SK-2 on board, so the purchasing and all that good stuff. Yeah? How do you feel about being home? Oh, it's so nice, you know? Another patrol down. MK-1 Christopher Tolson. He's a machinery technician, first class engineer. I'm the Tampa. My name is Z-H-R-I-S-T-O-P-H-E-R Tolson T-O-A-L-S-O-N. My wife and my youngest son are here. My older two are in school right now. I get to see them later tonight, but they're just waiting down at the end of the pier and I'm really excited to see them.


A lot of people ask me this question. Is it important to have a computer programming skills in order to become a product manager? Do you really need a technical background to become a product manager? Some people say no, you don't need a computer science degree at all to become a product manager. Some people say absolutely yes, so that you will become much more competitive in the job market. As a hiring manager, I can confidently tell you that both answers were wrong. These wrong advice without customized advice is going to cost you a job offer. The right answer is, it depends. Whether you really need a technical or computer science background to become a product manager really depends on four things. The company culture, the customers, the product, and team structure. In this video, as a product manager, we share with you the correct answer. And I assure you by the end of this video, you will feel much more efficient and confident in your product management job hunting journey. Hey guys, this is Dr. Lin Sili, a direct product from DrLinSili.com. I hope people tradition from worker B to product manager and business leader. If you want to run the most effective way to become a product manager, you should subscribe to the channel and hit the bell button so that you'll be notified every time I post a new video every Wednesday. I've helped hundreds of people to become a product manager in the product manager accelerator program. Lots of them do not have a technical background at all. Let me give you some examples. Some of my students who has an accounting background and got a job offer as a TPM in Facebook. Some of the students has a sales background and he got a job offer from Chase as a product manager. They also have students who has engineering background and got a job offer from Google. So whether you need a technical background really depends on the following four things. Number one, company culture. 90% of the companies out there do not require you to have a computer science degree in order to become a product manager except Google. Google will have a software engineer to interview you to see your understanding of computer science during the interview process because Google is an engineering driven company and their engineers get paid even higher than product managers and engineers are the ones who drive the boat of Google. So therefore with that kind of culture Google really want their product managers to have some technical background. However, product managers that Google does not need to code, they just need to be respected by their software engineers at Google. I have a specific video talked about how to develop a product manager interview at Google. You can check it out right here. I also won't make it in the description of this video. However, it doesn't mean that if you want to join fan companies you have to have technical background. For example, for Facebook, you do not need any engineering background to become a product manager at Facebook as long as you can crack the product management case interviews. I made a specific video about the long product sense interview at Facebook. You can check it out right here. I will also make it in the description as well. Number two, customers. If you are the product manager of consumer facing product or lots of product really require a lot of customer empathy, you do not need technical background at all. Let me give you a specific example. If you are a product manager of a baby product that helps baby to improve their sleep cycles, who would you hire? Somebody who knows how to code? Or a product manager who has customer empathy of moms and understand the baby's sleeping cycle much better than everyone else? If you are a hiring manager, you will definitely hire the second one. However, if you're a product manager of a cloud product, for example, Google Cloud or AWS, Amazon Web Services, it's best to have some engineering background because your end customers are software engineers who is going to use your product on a day-to-day basis. You're going to have a big customer empathy of software engineers. You'd better know how to code as well. I list eight product management skills into master to become a product manager. You can check out this video right here. Now comment in the description of this video. What's your background and what specific product management skills are you trying to master? Number three, product. If your product is super deep tap, yes, you need technical background. For example, if you're building an AI product or you're building a quantum computing product, you better master the computer science skills or the machine learning skills in order to improve and design your product with your engineering team. If you are building a customer-facing product, like lots of B2C products, it's important for you to understand the UI-UX customer emphases and doing customer interviews. And in that case, you don't need an engineering background.  On the opposite side, I really think it's more important for you to master the industry-specific knowledge compared with any technical background or computer science background. For example, I have a student who became a product manager of a healthcare company. They really value her healthcare experience managing big and large healthcare projects. I also have students who join TikTok as a product manager and the TikTok hybrid manager really appreciates his background managing ads, design the consumer ads, and put it in front of the end users. So his ads experience got him that job. However, why lots of job openings always say we prefer somebody with engineering background or computer science background? Let me tell you the secret behind the scenes. The reason I ask you those things as good to have was because they want you to be respected by your engineering team. They also want you to be able to communicate very well with your engineering team. On top of that, they also want you to have realistic expectations of project timeline. What if your engineers told you that this project will take a year to finish? Would you be able to push back? And before, they also want you to ask smart questions. So therefore, you do not really need to know how to code. You just need to know how systems work in the software environment. So I highly recommend the Systems Engineering Design Course from MIT. And I also teach you the Systems Design Methodology from MIT in my PM accelerator as well. And over there, we help you to understand how to break down the comprehensive engineering topics into smaller solutions and smaller modules and know how to ask the right questions and also know which part is going to be missing and how would you communicate with your engineering team. That's the core of mastering the technical background as a product manager to become A plus PM. If you want to learn more about my product manager accelerator, you can go check out this webinar where I talk about my experience getting a full product manager job during the pandemic. I'll tell you more about PM accelerator at the end of webinar as well. I'm going to put the link in the description of this video. Number four is the team structure. For example, even if your product is super tacky such as AI product or cloud product and your current team composition has 10 product managers and all nine product managers has a super deep technical background and they all know how to code. Do you think they would hire another coders to become product managers in this team or for the 10th product manager they won't hire someone with business mindset, business background so that they can broader the view of the entire team. And this business product manager can also focus on the GTM and how to bring the product into the hands of the customers. So I wouldn't recommend you guys just give up because some companies and some jobs are sounds very technical. No, you would use the right networking strategy to lend us job opportunities and confidently present yourself in front of the hybrid managers and package your experience using the right resume template. If you want to know how to package your product management experience even if you don't have a technical background you should download this free product management here resume template where it has been used by thousands of product managers to lend their product manager job. You can check out the link right here and see the description in this video. And don't forget to smash the like button so the more people will discover this organic content. Make sure to check out the playlist of product management interview questions and answers right here as well. This is Dr. Nian City. I'm going to see you next time. Bye.


Generation change has improved my capacity by equipping me with a set of critical peace building tools. It's giving me the opportunity to see conflict management and peace building entirely differently. I have gotten a lot of information, a lot of knowledge, a lot of skills from generation change. The generation change of training, the strategic planning meeting, all these things. But one important thing that has actually parted into my life by generation change was redefining my purpose. My vision in life as a leader in our community. And the lessons I learned through the conflict analysis course at USIP is actually the faces of conflict, the faces that lead to a violent conflict. Many people don't realize but there are very many things that do happen prior to a violent conflict occurring in any particular society or community. But what I've learned from this generation change training is that there's a place for every style or there's a place for every approach, you know. There are some times you need to avoid, there are some times you need to compromise, there are some times that problem solving technique is very, very important. The generation change experience, especially the trainings have been able to boost my confidence as an individual. But most importantly, give me the skills and the techniques on how we engage in our communities, especially our communities that are engaged with lots of conflicts. How do we deal with providing that sense of purpose, that sense of possibilities among the young people. Generation change training actually impacted on me positively. I learned a lot on conflict resolution, so we are facing a lot of conflict in Nigeria. When I go back to Nigeria, I will apply the skills I create to resolve numerous conflicts. I learned a lot about how knowledge can be transformed from facilitator to participant and then from facilitator to new participant. These series of sharing information and building on knowledge is amazing during this program. I've learned so much during the generation change lessons and I was able to use it in my activities in the community and most especially the role plays, the exercises, the group activities. It has helped me carry out my activity easily and effectively. The potentials that have sprung out from such region as West Africa and Nigeria to be specific is mind-blowing. If such energy can be channeled towards positive goods, to be mind-blowing, you have no idea. Teach them how to be peaceful, teach them how to use such power to build a generation that is unstoppable, a generation that will change the world.


Diamondback AM2. Hey there friends thanks for checking in at the range down we've got the Diamondback AM2. New release from Diamondback it's a cross between a compact and a subcompact firearm right around the same size as an FNS-9C. It does come with a 12 and 17 round magazine 3.5 inch barrel it does have a trigger bar safety in there. Nice trigger breaks right around six pounds reset right there for the follow-up shots. Three dot sights steel sights orange dot in the front they are Glock compatible does have a pick rail, polymer frame nice texturing, striker fire indicator and a witness hole. You may notice that slide is stainless steel with some black where the serrations are and a matte black top of the slide. Nifty little gun here that can be purchased right around 230 bucks I think it's a steel let's see how it shoots from about 10 yards it's got a nice feel to it it controls the recoil very well it is a light gun which is consistent with Diamondback now the the magazine release on the left side sits flush with the frame very much a snag-free gun and this is the 12 round magazine now I also mentioned that it comes with a 17 round mag all right and so you're looking at a full-size feel and yet a 3.5 inch barrel let's take a few shots here we'll start at the right this time what am I doing little there we go all right couple of those cases came back in hit me in the hat but for the most part they seem to be spread out right right behind me a couple feet behind me which is which is good so it's a new gun and we'll see you know how that works out over time one of the cool things is that it has a pretty light spring weight also easy disassemble that we are used to with Glock's and so many others very well machined gun budget no doubt about it and it does also have a serialized chassis which means that Diamondback may be coming out with other polymer frames stepping back to 20 yards got the Diamondback AM2 let's see if the Diamondback AM2 slide will charge if I slam a mag yep and sure will how about one-handed here we are about 24 yards away I've got the AM2 let's try for that set their target probably 50% here we're gonna shoot some 124 grading hollow points made by LTCH works fine so far the Diamondback AM2 has performed very well for me right around the same size as as a Ruger American compact Walther PPQ subcompact FNS-9C but a lot less money I think I already mentioned Buds is selling it for right around 230 bucks I think it's a great deal for a mid-size subcompact if you will handgun that fires very well at the range and I have to say so far I'm pretty impressed if you like videos like this please subscribe and share I always appreciate thumbs up button thanks for watching and you guys be safe