Hey everybody So Clemens how are we how is Germany doing in terms of opening back up? My machine was mooted. Hello If you did answer the quest I didn't hear you because you're muted Yes, I have my speakers muted completely.  Hey, hello and Tommy Yo yo Thomas you there I'm here. Hello Hi Hey comments while we're waiting. Um, I'm getting Ping from the CNCF folks who are running One of the conferences in Japan. I don't know which one it is Actually may not be CNCF. Maybe it's a linux foundation one. I don't know one of the guys they keep hanging me asking me whether we want to do a maintainer session Um, and I would say that it's the usual thing, you know, there's a deep dive and an intro I was thinking about saying yes and just um Just doing the intro that we were thinking about doing for the kukai EU um If it's if it ends up being at a time slot that you can make do you want to present if you can't that's fine I can do it myself, but I just wondering if you wanted to be considered to to present if it if the time zone if the time slot works for you So that is all that's all virtual I believe so. Yes Uh, yeah, then japan should work for me because I mean, uh, they are they're not so far off and I mean if they put it into the afternoon, it will certainly work Okay, cool. I thought I would just want to double check. Thank you. Yeah All right colony there I am now excellent. Hello and Eric Hello and ginger Good morning, sir. Good morning you're going yo mark Uh medias, are you there? No, it is It is my apologize. I'm horrible um Manuel Yes, hi. Hello Mr. Scott Negative I have a meat popsicle You have a meat. Oh, what is it? I gotta know No, I am Come on. Oh, I thought you're eating like bacon or something No, I'm quoting The fun movie I apologize. I'm not hip Did I forget anybody I think I got here. Oh, brian Here and also not hip and slightly confused in It's gonna be one of those days. I can tell I just uh It's it's always been a long day for me I'm it Are you there? Yes, I'm here. Hello. This isn't your first time on the call. Is it? No, I didn't think so. Okay. Good. I should have your affiliation them already All right, one more minute and then we'll get the show on the road. Oh, I agree there I'm here. Hello Someone else went flying by uh lance you there Yep, just here. All right, cool I'm also here because I don't know why I keep missing you as you sneak in there. It's not the first time that's happened But welcome And jam. Are you there? I am Excellent A couple more seconds then we'll get started Oh, ryan, are you there? Yes, good morning. Good morning And Tim are you there? Yep Pretty sure I missed it. Oh, I was close. Here we go. T I H O M I R. Got it. All right three after. Let's get this show on the road Um, let's see 23. Okay Um Skipping the AIs for now community time anything from the community people would like to bring up. That's not on the agenda All right sick update no update as of right now if anything happens there. I'll let you guys know Um sdk call so we do have a call after this one Just let you guys know who would normally join that I don't believe slinky is going to be able to join us Just so you guys know I think some of the issues may revolve around him So those would have to wait But we can still see what's on the agenda All right workflow Timmer, would you like to give us an update anything exciting going on there? Yeah, sure.  Sorry. Okay Yeah, we we can alternate on that So, yeah, uh, we got a rapport from the scenes here. That's nice, but we're still waiting on the sandbox final decision of becoming sandbox project We also had another primer call last monday and we have our next community call next monday. So Gently remind us of that All right any questions for those guys All right moving forward then. Okay before we jump into issues in prs Is there anything hot on the agenda that I forgot to add people want to mention? All right in that case um couple Hopefully smallish prs. I believe this one's mine I just noticed that subscriber or advanced subscriber is actually not used in the spec right now This is in discovery. So I just wanted to do a little cleanup to remove it Obviously, we can add it back in if we do want to talk about at some point Any comments on that? Okay any objection to doing that? All right. Thank y'all Sorry, okay. Oh, wasn't that because of one of the other uh, like the discovery doc? Well, it's in the discovery doc. That's what I that's where I was pulling it from.  Yeah, that's fine. Okay, cool And I said we could always add it back in later All right at point is to see this one. I believe is strictly syntactical in nature um Actually, I'm sorry. This actually does two things um, this cleans up Actually, this is kind of odd Oh, I see what I did. I apologize. Yes. So for the most part what I was doing here was on Certain terms. I added a pointer to the cloud event spec if it's a duplicate definition from that spec um, I tried to make sure the text is the same, but I also um added language here that talks about how um, if it is copied from that other spec If for some reason there was a difference between the two definitions The cloud event spec takes precedence in terms of the definition And the reason this jumped out of me is weird is I forgot I actually did some Reordering of the terminology itself. I decided to rather than the ordering that was there Which looked a little bit random to me and I apologize that it wasn't but it looked that way to me I tried to make it in the order of From the server back to the client's perspective So you start out with service and source producer intermediary consumer kind of thing just to get a little bit of a flow there For I thought better understanding, but I think that's about it now I had to fix the link checker to to catch that new this funky formatting thing I don't think there's any semantic change in here. It's more syntactical Mainly just adding these little pointers to the cloud event spec Any questions or concerns about that? Any objection to approving? Okay, thank you This one And I actually should apologize for this. I should have actually done this before we merged the other pr for the provider service change This actually just goes through the rest of the spec and gets the other provider uses to usages and converts them to service Strictly syntactical change, I believe. I don't think I did anything with semantic change Unless I just really screwed up and messed up Any questions or concerns about that? Any objection? Okay Thank you All right Okay, I just wanted to bring this to your guy's attention Because slinky pointed or pointing yesterday to mention He did update this pr I think he updated it a couple of days ago though 23rd. Yeah, I can afford to be there. I guess three days ago So technically it could be reviewed and voted on today, but I don't think anybody noticed So I wanted to bring it up to everybody's attention today to take a look at this when you get a chance This is a change I believe in the cloud events space Just wants to add a streaming proposal for Jason. So take a look at it when you get a chance We'll talk about it on a future call. Obviously if you have questions or comments go ahead and mention it in the pr itself Okay, but he's not on the call to take any questions, but I guess if someone wants to raise one right now You're welcome to and maybe someone else can answer it Okay, so that was just an fyi kind of a thing. All right Clemens since you weren't here to Introduce your spec. Is there anything you'd like to say here on this pr? Because I think there's just some outstanding Things that need to resolve first before we consider emerging, right? Yeah, yeah, there are there so I mean I'm expecting there to be a few more rounds of discussions that I've refrained from updating the documents before this call because there are outstanding questions and I want I didn't want to override them With you know, then you know, it's easy to lose track on github. Once you do significant changes So I want to do it. So I acknowledge I acknowledge things that where I'm going to make changes with your thumbs up and More many of yours and then I made some further comments um, so Yeah, this is what this does is in fact, it takes the proposal that I wrote up in the issue and turns that into a proper document And really what this is it's a somewhat smarter version of a plain File store if you will for schema documents So the idea is that schema documents are typically Text text documents some schema formats may be by but they're of the rarer kind and This basically has a structure Where you have a schema group Which is a Organizational bracket around a set of schemas that are typically belonging to an application or to a particular topic And the reason why the schema group exists We're deriving this from from so this this this proposal doesn't come from thin air We actually thought about Implementation pretty hard. So the schema group exists effectively as the top level grouping for creating access control And also to create, you know, a notion of separation in a global registry For applications that potentially even tendency And then inside of that schema group we have schemas and schemas are That They can be concrete. So I have a note in here at the start and then we should go probably go and take a look at the note first I have this if you go scroll a little bit further down There's this note So there are two ways and I've implemented effectively both of those ways in this proposal and they can go together But we can also just opt for one where Either there's two ways to look at a schema. You can go and look at the schema as a concrete documents and basically have a schema for I'm going to make this Let me make this concrete. So you have a schema that is for storage events Avro So then you have effectively an avro schema document that that ever schema document is being stored and versions as it is And that's the simple the simple way of of dealing with this where you Just store effectively under a schema group you score Store schema and the schema has a particular is for a particular format and then you version that The other way of doing this and that's also in here is to say to be truly restful And restful really means that the representation that you can have an entity and the entity can have multiple representations so The entity is really an abstract concept Where you have an event Of some or the body of an event in our case Of some sort But that body of an event can really is an abstract data Data structure and that data structure can now be rendered in multiple ways So it can be rendered in json. It can be rendered in xml. It can be rendered in avro. It can be rendered in protobuf And so schema in that in that view really represents the abstract data structure And so instead of of managing documents You're really managing managing the schemas that define the representations of that abstract data structure And the abstract data structure is the thing that gets versioned here. So the abstract data structure is something that exists Not in this registry, but exists effectively as a document somewhere else And here you're just managing the the the the the schemas that belong to it So so in that way so in that in that in that world And this is case one here It's a truly it's a restful service in the sense that you can go and apply multiple schema documents Which means multiple representations or or meta meta Meta descriptions effectively of a data structure under the same version Where you simply are doing a put on the version number with a content type of Um, you know for the appropriate media type for the jason schema the appropriate media type for an avro schema The appropriate media type for an xml schema and all of those under the same version describe the same exact same data structure So that you can you can then from a um if you want to go and fetch an avro schema you walk up to the If And then you submit the accept header As you're doing an hdp request Where you say these are the schemas i'm willing to accept here And then you know by your order of preference You're going to get the best matching schema back and then you know what serializer you need to You need to load so that then everybody can go and understand The the respective message So that's that would be the truly restful way of of of making a A schema registry, but it's a little bit more complicated So what i'm trying to do here is to You know satisfy this A little bit more isoteric desire for having the ability to to represent a abstract data structure in multiple ways but kind of in multiple formats And store the schemas All alongside under the same version version number And also satisfy the much simpler need of just storing You know a sequence of documents That are describing effectively just one format all all together and We're still debating so on in microsoft. We're still debating on on which of those two choices are the is the right one And so I just included those in this Right up to You know drive the discussion and to say you know we can we can do both we can do the simpler thing And so kind of with that introduction of of what the motivation here is that's what I would like you to You know to use as an intro to go and read that document and see whether that's whether the more complicated the super restful way is I'm far too complicated for implementation because that's ultimately what what the The make or break here is is whether that mechanism whether the mechanisms that are described here are you know practical practical for for implementation What I don't have what I didn't put in here Our hard are too many hard rules. So for instance When you are creating a new schema You can basically just come and and Come to this registry and under a schema group You can do a post um Or sorry, you can do a put with just a schema name and then a new A new schema basic or actually you can do a post Under the screen under a schema group with a new schema um, and then and then it will go and and create the the The first version for you and then you can go and walk up to that same Schema node and you can go and post a new version And it will go and create a new version for you and will store the latest version under that new under that new schema number Under that new version number and if you do a get Just under that schema name you're going to get the latest version So there's a fairly simple way of doing those things you can now in an implementation You could enforce start enforcing rules and have some configuration on the back end that says well If you're adding a new version of the schema Then the configuration says that you have to be backwards compatible with the prior one, right? That's some schema registries have those capabilities that You know you store an average schema and then you store the next version of the average schema And there's a policy in the background That will enforce That that compatibility is there That's allowed here and there's even a You know, there's a explicitly in the in the accompanying Open api definition That you can then go and return a 409 conflict and say, you know, that's not for us But the schema registry per se this definition here doesn't say what that should be Doesn't doesn't see what those rules should be because the rules can be Different depending on what the format is and it's also not constraining which formats you can store So you can do this for avro. You can do this for protobuf and if you have some Other schema formats including xml or something else that you want to go and store the store in here That should also work. So that's the goal of this is to really have a very very open base spec That can accommodate whatever schemas you like and then Um, potentially in an implementation note, um, you can go and constrain that further and say, you know, here's my My avro lens on this So that's the idea behind that specification. So our goal is that the universal interface For a simple as possible, but then as flexible as possible schema registry that everybody can easily implement Hey, and john your hands up Yeah, so, uh, clements are you when you're talking about supporting, you know multiple multiple content types Are you Like how is that being managed? Like are they are you saying that I'm going to build the protobuf version of the schema and the avro version of the schema and the json version or whatever and The registry is just going to accept those and assume that they're the same Yes So so that you you're going to met. So if you want to have multiple representations Then you're going to walk up to the registry and basically just store them under the same under the same, um version So any incompatibilities or things like that when you're talking about, you know, multiple versions and Skewed them, right? So if I update the protobuf one and now it's ahead of the other ones Like how do I how is a consumer going to even know that? um Because you ought to be disciplined when you when you when you do this. So there's no I'm I'm not this is just the interface And you can go and put a lot and you can put logic at the back Which basically said which basically evaluates the the let's go and let's say you you emit a you have you add a protobuf spec And the protobuf spec is now the first spec that is under version three And now you're adding on avro spec That is also under version three. It's basically you're putting you're putting a new one Then you can obviously Create some logic at the back in in a particular implementation that goes and And basically creates a projection of what the avro of the data structure that the that the protobuf spec describes And then checks that against the the um structure that the avro um Spec describes and if there are mismatches you can go and reject that So there's it's it's perfectly possible to do logic at the back which goes and matches all those things But i'm not demanding here in this in this specification that um, you have to do this So this can be as simple as um a file store that is More or less implemented some logic that that's that's being put on top of a blob store So then I then then given that uh, I'll take the rest offline But given that relative to this spec you should call out that that you know this distinction that you're making of the spec versus you know these other logical um quality of service kinds of issues and in terms of Engaging that You know in in some commentary or something because yeah that that That's obviously a key issue in terms of the implementations and the consumers Yeah, I I I think I've mentioned some of that in the document now. I'm I'm relying on Doug to scroll So I should probably not do that Where do I make a go? Yeah, see that's that's um, um I need to go look myself Um Give me a moment Is it this multi-format section? Yeah, I I have I made some implementation reference um so, uh, so this In under version uh, and uh at the um In the intro Um, even though prescribing the specification and implementation might choose to impose compatibility constraints on versions following initial version of a schema For instance, so then I'm already calling that out there and then we have some of that in the Also from access control for access control rules. I'm also making a comment implementations of the specification may associate access control rules for schema groups um, there was a comment that we should also go and Allow that for schemas themselves for versions potentially and So I've I've made I've made references to implementations in several places. So if you um If you have suggestions for where should be stronger, then I'll I'm certainly Certainly willing to go and make that stronger Okay Ryan, I think my hand was before you and I have a quick question. Um So so comments. I like the fact that for the most part you're describing This is just sort of a blob store with a nice file interface on top of it And and leaving the semantics up to either an implementation choice or if they want to do nothing at all, that's great But then we start talking about the version stuff. That's when I start getting a little confused because Um, that's almost adding semantics. I'm wondering why you just don't say, okay You know, this particular user they own this maybe url or this url's group And then they could put whatever they want there, right? If they choose to use if they only choose to have one url and they just keep updating that one version every single time That's up to them if they want to have multiple versions. It's up to them They just change the url that they do a put to I'm wondering why you decided to add semantics around versioning um Because that is really to accommodate the simple case where you don't Care so much Where you really only what you have like you have a schema and then you want to go and store the schema And then you change the schema changes and you just store the new version of the schema under the same name um So there's no compatibility rules You're okay with breaking changes But then you want to have differentiation between the stuff that you have already sent which means now you have a a You know, ultimately you're you're walking up to the registry. You're posting your schema What you're doing what you're doing is you're you're doing a post you're getting a A url back that is the url that you're going to use and give to everybody and that is going to that is going to have the Version number right and now you're going to walk up to the same to the same name And you're posting the new version of the schema and you get another url back That is the the permanent url the permanent link basically to that to that new schema and you're okay with breaking changes That that versioning Right of of you know just posting the new version um That is making things for the simplest kid for the simplest case arguably Simpler because i'm not even forcing you into thinking the the you know the the management of versions. You basically just get a consecutive stream of history of those of those versions one two three four five just number three You don't need to think about semver. You don't need to think about all any of those other things and as soon as you start As soon as you start thinking about the as soon as you make the version management explicit Arguably things gets get harder for the simple case Okay, I hadn't I thought about that simple case you're thinking about I thought maybe they want to manage the versioning numbers being themselves But okay, I understand uh crying your hands up Yeah, um, I know I made a bunch of comments in the in the pr and I haven't followed up on uh on all of your responses clemen So I'll try to do that this week, but um, I think one big question that I have is like how How standalone do we envision this being? I know this is starting with thought events, but I've seen other folks come in from other groups Interested in some kind of common schema registry um, and I ask that because um, just just in my experience building, you know, very generic You know platforms or or services um It's sometimes useful just to have like a diverse set of use cases just to test the design against so I'm just curious as to what um How you're thinking about that and and how generic you uh envision this being so So I certainly envision this envision this uh to be Broad broader than just the cloud event payload Um, because ultimately this describes a it's a it's a Complement complementary capability to any serialization framework Um, where you need to have where you need to share schemas between two parties and that's true for all of messaging and eventing um, so This can compose with a mqp this can compose with mqtt this can compose with cloud events This can compose with Effectively anywhere where you need to have where you exchange schematized data including htp transfer. So that's how broad I see it um and and that's also Because we have this because it's it's hard in cloud events and generally It's hard to draw the line because what we're doing especially with cloud events with the with the with the transport bindings that we have We're intentionally blurring the lines between you know, what eventing is and what and what message transfers are in general like you have a You have an mqp message and the mqp message can take on a cloud event character because you're just adding the the cloud events attributes to it But it runs for a normal message broker. So it's hard to to draw the line there So I see that here as a as a spec that is is generally applicable or that mechanism is generally applicable for um For messaging in in in general Okay Okay And that's another question. That's also that's also let me let me just add one one more thing. That's also why I think the That this is just for the payload And then this actually hope this this gets integrated um Or complemented by the discovery mechanism And where the discovery mechanism really that's the catalog of the the events that can be emitted That talks about all the various properties of cloud events and then this here is really about the the The schema that we leave out of cloud events intentionally and that is the pay that is the payload Okay, and any other questions or comments for clements? Okay, thank you clements and everybody, please. I mean you get a chance if you haven't already Please read through it and leave your comments in the pr. So clements can try to address them offline All right, thank you everybody Next up uh Jim Would you like to chat about your protobuf? Sure, I was rather hoping clements could use up the whole 50 minutes Well, I'm sure he could if you if you ask him to I'm sure he'll talk about the uh the difference between eventing and messaging Okay, so um I've tried to address some of the the commentary I know Evan Evan have made a lot of comments, which I appreciate and I think I've tried to address um I having had that conversation I think a few points have come up and Some of that I'd like to toss out to the group so The issue of grpc has been raised And yes, that definitely needs to if we want to support that needs to be a different document, but Do we consider grpc to be a transport? I guess that's a question I think I'm interested in clements view on that because it It doesn't really smell like a transport to me, but I could see arguments why we should have You know a spec that might Show, you know grpc endpoints to carry cloud events That's a a question out to the the group if anyone has any opinions on that it doesn't necessarily affect this spec But it's just something to think about um Another question that came up was around the representation of timestamps that I'd used And Doug it might be easier to switch over to the the actual proto spec rather than the Markdown on this You mean down here This this right here. Yeah, so I'm gonna actually view it Yeah There you go. Let me know where you want to go to okay, so that that'll do So When I originally put this pr together, um, I just represented all the attributes as a map. Yeah much like avro does and I was sitting there Mulling over whether that was a particularly Idiomatic way to to do stuff In proto, so I then switched over to this other representation where You know, I've you know explicitly listed the required and optional You know attributes as I defined and then left them essentially a map for any Any additional or extensions? um I'm now toying with going back to the other representation The issues of You know, how durable does this become? You know, I this now would be Something that would only work for v1. Yeah, if we had ever added a new required Field, you know or attribute then, you know, would that indicate? You know a new version of this Schema so I'm toying with the idea of just going back to a straight map of attributes And not formally representing them The question around timestamps was And part of this I think was my sort of speedy reading of the spec originally I'd read the spec to me You know from a cloud event perspective that a timestamp had to be sort of Completely represented including a time zone. Yeah, so I used a native prototype for that but Somebody pointed out to me that the spec actually indicates that the time stamps need to be sent as a An iso string. Yeah And I just wanted to make sure that that was And that's what the spec says. I just want to make sure that's what people Thought it should be Because it again To me, you know, if we have an idiomatic way of sending a timestamp. I am not sure in in a particular format like this why I wouldn't just be able to use A formatted, you know a predefined type for that The other questions I've seen were around my The way I'd address the data aspect Where I sort of allowed it to carry, you know a protobuf message Or, you know textual data or binary data now Again, my understanding from reading the spec is that this is sort of allowed in the spec the spec allows for different You know representations. Yeah, and in fact in You know in the jason schema, we allow a jason object to be data In the avro schema. I think we allow an avro record, is that the right term to be data so Again for me, this was more idiomatic if I have a Event payload, which is actually, you know defined by a proto schema Um, it's much more idiomatic for me to just inject that You know explicitly as a proto object You know rather than externally marshalling it into a string just to be able to jam it into You know the or you know marshall it into bytes to be able to then jam it into you know A byte buffer inside another proto object. It just didn't seem very efficient to me Um, so that's that's really where I stand at the moment. As I said, I'm probably going to go back and switch You know the attributes back to a simple map Where and again following the model if we scroll down a bit more dog Where I sort of come up with this model of allowing all of the Types that we define in cloud event to be sort of formally Carried in proto without losing any of their type information. So, you know, if you had an attribute that was a uri You know, you would put it in a uri Name and so the receiving end would know that that attribute was actually a uri and similarly for booleans and timestamps and whatever so That's really where I am at the moment Um Questions Yeah, so what mic your hand was up first and then criminals will go to you since you came off mute, but Yeah, sorry, I had to rewind a little bit. Um So the question was using a map versus having these types in proto Having these types the way they are now is the right way Using a map to define the attributes would not be protocol buffer idiomatic Um, you know adding Adding new fields to and versioning proto's is a well understood thing at least internally at google. Um, we do it all the time So it's Yeah, I mean, you know having the extensions as a map is fine because We don't know what those are ahead of time, but the things like the id source spec version, etc. Those should be Well-defined names Right. Yeah, that was my thinking Because it just seemed more natural to me as well But thank you for the thumbs up on that. Okay. Yeah, and you know the the um, if you had a you know, if we had a you know Let's say version two as a new required field You know, we would drop it in somebody that's to have the version one their protocol buffer were parsed because Uh new fields that aren't known are just dropped Um, so it wouldn't be breaking unless you removed a field I thought in proso three now the changes were made so we didn't you don't drop unknown fields Or is that still a configuration option? I think it's a configuration option. Um, there are I think the There's a difference on whether unknown fields are made available to you as part of the reflection structure or not Right. Um, so I Yeah, I was gonna say I because we were using a paper we were using proto two and switch to three um, and I think we were one of the You know band of people that was pushing for You know the unknown fields to to be put back in, you know, because it was something that changed between two and three and I thought that was becoming The default behavior rather than a configured behavior, but okay Um, I think I'm not I'm not well versed in the depths of photo It it did raise another interesting question for me though whether These schemers themselves need to be versioned. Yeah, so the the namespacing on the Not just the java package, but probably the proto itself Probably needs to be include a you know the one marker You know so that we can support multiple versions side by side if they change dramatically That was another tweet Okay, comments. Did you want to say something you can't off mute? Yeah, that I think the lengthy discussion that we had about bags is coming back in here Um, because the the we have this we used to have this extension extension bucket um that housed the extensions and then we went back to making everything a flat list And this this brings back the extension bucket which has the with the consequence that if a If there's no uneven support on either ends of um, you know, there's a there's a clouded publisher and the cloud event publisher gives you a is Has a new Well-known property so you know a version 1.2 or version 2 There is an intermediary which has the old Knows the 1.0 schema and then there's a receiver on the other end which knows the 2o schema Then the 2o the 2o publisher would use the 2o proto proto schema Would then publish to the intermediary which is using 1o schema Um, and then would probably go and drop the extra attribute on the floor because that's now sitting at the at the at the at the outer level And the the 2o receiver would not get it That would be a new version of this schema though, wouldn't it if it's version 2 Yes, or you're saying you're saying you add a new I don't know optional attribute. Is that your concern? Yeah, so with with the with with what we did with avro where we're where we're against the against the spirit of avro um, are actually using maps and tagged Tagged attributes, right um You can add a field and that that field will pass through The the the intermediary because it doesn't know it doesn't need to know about an extra field Here if you're making the fields our attributes first class right If you're adding a first class element So you're adding after subject or after time you're adding now Uh, you know the next one Then an intermediary which only understands this schema Will basically go and read the proto event will ignore what's at whatever was extra You will have a deserialized object now, which has which doesn't have that extra information And whatever you want to pass on to the the next party Will miss that extra information that the the client submitted because The the serializer will ignore it So the old the old intermediary will ignore it so I think there's a I know and I think I may have mentioned this in the in the PR there's a halfway house solution where You formally declare the required attributes, you know idea and source, but all the optional ones you just leave in in the in the map Yeah, I think that yes that It grates on me a little bit, but I think that's That's the need to solve to that and I think that would then address your Your concern. Yeah, I I believe that's true because the we cannot add in any future version We cannot add anything that's required right yeah So Jim did you get oh, sorry ryan you go ahead you reach her hand um Yeah, I mean I was just looking at the spec uh, and uh, it does say an intermediate should forward optional attributes It's not required. Um, so that would comply with that I think my my broader question is um, you know everyone put a buffer or solving You know the same or or mostly overlapping problems um should We employ the same model It feels like this is deviating from the avro that the implementation of avro that we already have So I wouldn't claim to be an expert in avro. Um The way I was interpreting that spec is that um From what perspective are you talking about the fact of just having it as a map? Correct. Yeah Yeah, I know I say I mean if we just made it a straight map then, you know, it becomes a much more durable thing It it just seemed odd. You know when you have Attributes that you know Are required and want to be first class citizens that It just sort of Smelt better to me to define them. I mean we define them in the jason schema. Yeah Now missy jason schema is a bit loose because you know, you can just add whatever you want so But we did go to the lengths of actually formally Defining those and defining which fields are required and so on So I I think we already have a level of deviation But Point taken. Okay So what would you would you advocate for just a map or or this would you be happy with this sort of Halfway house solution where we formally declare the Required ones and put everything else in a map Or is your comment more around just consistent approach? But my comment is is more about the whether we want consistency I think you know, there's trade-offs to to all the approaches and it's it's hard for me to to give a hard and fast answer on the fly here Um, I think you know doing that that halfway solution would comply to the spec But I think it it probably needs more thought as to the trade-offs But yeah, I was commenting more to the should we and I'm not saying we should or shouldn't it's just raising the question do we want Consistency across the different You know representations or the different Ways of serializing cloud events And I did I'm sorry Let me shut up and let the other people speak lots of hands up Actually, I think Mike's hand your hand is old Mike. Isn't it? I think yeah, I think So you're you're free to go So I was going to say I mean, I wonder if there are echoes here of some of the stk work now I've not been involved in that a lot but I think there was an attempt to sort of have a consistent programming model for the stks And what those groups discovered over time was that You know when you do that you lose some of the You know the idiomatic nature of the languages that you're working in so, you know, they they've naturally sort of You know gone their own way and made them much more language centric so I I don't know but I suspect having explicit Attributes like that probably is more efficient You know on the wire and from a decoding perspective Yeah, okay, I I'll change the spec to the model of You know required and all the optional stuff in a map And we can readdress it. I did have a question. Maybe for Clemens. Can you comment on the timestamping? I was gonna ask about that. Yeah Um So it's in the cloud event spec itself. I don't know if you want to jump over to that It explicitly says it's a string So am I breaking the spirit of a A spirit of a cloud event by saying I want to put it in a you know in a in a Essentially a timestamp binary field the um the uh I didn't think that would I didn't think that you had to cut it with a string Oh It's it's only so so the the um If you just at the top of this of this of this page. No, no, no stop this specification. So type system, right Each of these types may be represented differently by different event formats and protocol metadata fields So you're okay right What this specification does is it defines a canonical string encoding for each type that must be supported by all implementations So if you represent this as a string, then it must be this That's what that means. Excellent. So I should have just read the document. Okay Yes, it is It is at times a fairly dense Right up. It's a nice piece of work. Come on Pat ourselves on the back Exactly that we all jointly created Okay, running a little low on time here unless unless there's something really major relative to The protobuf pr. I'd like to move on if that's okay So I do want to ask the comment around a grpc. Yeah, so yeah that a transport spec It's a protocol. It's a protocol. Yeah, it's not a transport But what which? grpc So once we've defined assuming we can agree on what a proto format looks like, yeah Um, theoretically then we could define grpc bindings which Allowed for not just proto formats but other You know event formats to be exchanged as well. So the question is where would that Go or is it is it just in a world of its own? From a spec perspective, so grpc is going to be interesting because it's grpc is arguably an overlay over Well, it is actually an overlay over hdp2. Yeah And Defines a way how to well do rpc things So it's going to be it's going to be interesting how we can go and define something that is for cloud events. That's not too constraining That is not just a proto definition because ultimately because ultimately you're you're passing a data structure as an argument for a function, right? Yep, and Um We're also we're also obviously struggling with the the we're now having the same struggle in this project as as exists across the The rest of cncf in that everybody's using grpc, which is a cncf project and then But by default using protobuf, which is a google project Not looking at anybody in particular So it's your comment there that we should stay away from it or you don't see it as something this group should Um Should define Or it's just a new type of protocol binding that we haven't seen before um I think it's a I think it's I think it's Reasonable to go and do a a grpc binding right but by our rules um arguably The protobuf the protobuf binding should be probably be part of a grpc binding because that's the context in which it's arguably only permissible because because of the the proprietary nature of protobuf As it stands if we want to go and play play the police on on per our rules So yeah, I think I think it makes I think it makes sense to to have a grpc binding. I'm just wondering what the Whether there is a reasonably generic way to create a grpc binding for this If I may Regarding the protobuf, I want to say that I mean There's quite some usage of protobuf outside of grpc ecosystem And I think if we split into the protobuf definition of the cloud event Uh, so the definition itself and some grpc efforts uh who In my opinion it would be better because people will come and ask for protobuf definition of cloud event not grpc Relate stuff, but just protobuf It's the first command I wanted to make and uh another one kind of related is that we By we I mean, uh, some forces at puerto and now we're We're trying to kick start the conversation about cloud events streaming And uh, I'm also referring to the licous project that I made and later we started using project beef where we tried to generalize Subscriber subscribe, uh, semantics Kafka like semantics, uh describe it in jrpc And uh, we may also Continue the conversation by merging to because uh, that's something else we're trying to discuss as well Like focus on cloud events streaming Focus on cloud events streaming Gem could could you make it real quick?  Yeah, no, I I would agree. I mean, I think protobuf me the the format needs to be kept separate from the grpc document because you know, we can send these formats over any transport And I'm I'm happy to put a grpc You know proposal together But I'd rather wait until we've got this one to bed before we do that Okay And with that we only have five minutes left and what I wanted to do I had another topic on the agenda, but I'd actually Saving that what I'd rather do is put claus on the spot because he just opened this one of an hour ago Um claus, you want to introduce this one? Because I think this is going to be an interesting topic that may warrant some deep discussion I want to bring it up sooner rather than later Yeah, exactly. So I mean intentionally put in the the work in progress in the title um Because it's I think it's also depending on other changes that will happen before so it's right now It's the change in the event provider and I suppose it will be probably changed to service or something But um The idea I had and I think Was already brought up. I think by Mike or someone in the original google doc we had There was I think a source pattern field um I did some research on existing concepts like what you know probably from open api and those seem to be based on This r of c i'm referencing here for assault for um uri templates And so um That's the the idea of a proposal to have an optional field that would then Uh describe the uh template for how a source field for a certain service would look like then So one example I came up with is this simple example here in the bottom There are of course a few things you might discuss here if this template format is the right one or um this if you look at that r of c it's also defining certain levels of uh complexity I would say for templates if you If we should restrict it to a certain level In my opinion in most cases even level one would be sufficient. So those are things we might discuss or if it's People think it's useful at all The reason I think this is going to be really interesting is because I think this is going to help shape the Uh, how much automation we'll be able to have right versus have to do user input to get things going and And you know once you have this the next question I would have is okay. How do people know what bucket means, right? Do we need some sort of Schema or something that helps to find what actually what this feels actually mean and that that's going to be even more interesting So I want to get this conversation going because I think this is going to be a good one Yeah, so that's of course a big question if you look at other standards like open api or async api they have their own Subobjects for parameters and and quite a big Well a lot of ways you can define those parameters Okay with about a minute. We have left any quick questions for close Okay in that case um Like I said, I did want to talk about this but I'll save that for next week because I think I have an I might need to write something up to better Express it. I was thinking that those come with those questions Um, any other topics you want to bring up before I go back and do final roll call All right. Thank you everybody. Uh curtis. Are you there? Yum, you're hello excellent. Hello Paris are you there Paris Okay, what about grant? I'm here. All right, cool. Did I miss anybody? I'm sorry. This is Paris Lucas. I wasn't near No, not a problem Like do me a favor. I'm not sure I have you in the attendee list yet Can you just either in the zoom chat or someplace like in this on the meeting minutes? Just give your last name and any company affiliation you like to be associated with Um, the last name is lucas l-u-c-a-s And right Ah, I can spell red hat. Thank you Okay Anybody else I missed All right in that case. I believe this part of the call is done We'll start up the stk call in about a minute or two. Just give everybody a chance to get settled or Hit the facility if they need to All right. Thank you everybody. We'll talk next week Okay Hi, it's bright Yep. Bye while we're waiting. Do we actually have any agenda items? You know what happened did I miss up? Didn't we talk last week shouldn't this be like the 21st? Yeah I could have sworn we talked last week Anyway, no big deal. Do we have any items for the agenda? I might expect a discussion of the typescript repo Oh, we could talk about that. I think we resolved that but hopefully we can talk or talk about that anything else Both javascript and go lang went to oh last yesterday Cool anything else Yeah, we can talk about the python sdk Maybe looking for your viewers Okay All right, give me another 30 seconds or so and then we'll get started All right, let's go ahead and do this thing. All right typescript repo Um, so lance correct me if i'm wrong here. Um, and actually I guess grant to since you're on I believe the current state is technically we agreed that as of right now We do not need it and everybody's going to try to do everything within the javascript repo Um, I believe I did get permission from grants to go ahead and delete it However, I decided to hold off on doing that instead. I archived it just because I didn't want to Delete any issues or prs that may be there. I figured it's easy to delete again later But at least it is archived so no work should go on there um Is that a fair summary grant and lance? So I think that was an accurate summary up until maybe Yesterday morning Uh, there is an issue with um type definitions that we're generating Not really, um Not really understanding certainly js docs syntax and and how putting something that's incorrect So as a result, there's a, um We're gonna move forward with you know, um Adding type script to the existing repository But I would say we still do not need the type script repo that I was discussed before Okay, does that make sense? Well I'm trying it sounds like the net of it is still what I said Even though some of the details under the covers may be different. Is that fair? Yeah, pretty much. I mean well, yes the the specifics of for example having to uh constantly run a build which Was not the case in the um in the sort of alternative that I've presented and that landed Will now need to be the case But if those are just details like yeah, I think I think the the net result is we don't need a type script Um And we're taking steps to make type script developers happy in the current repository grant. Would you say that's fair? Yeah, not my grant. Um Yeah, I think uh I mean with the With the changes we're really just trying to get type script support and I think there's um If it's possible We just To generate the script on bindings We need to by itself using type script files The type script bindings sounds great And I'm yeah looking forward to In order to use type script Okay So as I said, I I I'll keep that around the repo just in case something happens and we don't want to Lose the I think the one issue or one pr this upside. Go ahead, Grant I like I don't think it's worth keeping the detail there's I I know I think I had the one pr and If there's I mean, I don't see any reason I already copied the Um, I can have the issue into the JavaScript repo and so Uh, it's all good for deletion from my perspective. Okay. I will do it then. You don't need to be cautious. Okay Cool. Thank you Any other comments questions on that issue or that topic? All right Anybody want to talk about the z2 deliverables? who Scott looking well for go we're looking for feedback and usage and people finding bugs and issues it's um with with the uh Major version 2.0. We're gonna go back to adhere to strict semver protocols and versioning and fun times Yep, that's exciting There's a couple breaking changes from the previews and the rc's because we at the last minute decided to ship all the the protocol implementations as sub modules so some things got Bumped to a different import path, but the code is the same Now earlier was it this week or last week you mentioned a possible Hiccup with the gomod stuff where we need separate repos. Is that issue behind us now? Yeah, I worked around it There's some automation that needs to be written to help make releases happen a little easier, but Basically, like I go to the gomod community and I'm like, yo I want to make sub releases in go modules for sub modules and they're like, yeah, I don't do that. That's that's scary and So it turned out that the documentation for all this stuff is in go files in an internal Full package inside of the go laying Which I don't understand and it's not published anywhere, which is also fun So basically it's like a gomod is highly undocumented And people are unwilling to go and actually understand how it works Okay Any questions about the v2 releases? All right in that case python sdk Who wants to lead that one? Yeah, so I was taking a look at one of the issues published Um, I'm kind of into the sdk, but they there's an issue regarding it not being very pythonic So right now I'm currently creating a class inside of the sdk Directory such that you don't have to do all this overhead of having to manually create Various marshals and stuff. So just making the entire interface much nicer All right now. It's mostly done. I had just I changed some of the internal classes So I'm currently trying to get the other previous tests to pass So I can post a link I guess to the fork that I'm working on somewhere I don't know how this is documented usually So just a Who's the maintainer of python? I can't remember What do we have over there? um I'm Dustin Yes, I don't think you go ahead. Sorry Uh, well, that's a good question. And I don't know if we know the answer um I Does anybody know a denis matto gone? I want to say he might have been from oracle that may be wrong. Yes. It says yeah oracle there's only 30 something Myths on the repo And it looks like he's the primary developer Then said your initial commit in september Usually I guess And so I don't think there's anybody primarily working on this repo right now Okay, I That's one of the issues like in terms of Our view process and developer process getting some feedback from other folks that might be interested in using python As far as I'm wondering That's kind of broken Like the the v2 the v1 sdk implementation is incompatible with the spec That's good. So I can take a look at that. Uh Can someone I guess links to the current when you guys want headers and stuff or somewhere when you guys I think I wrote an issue for it For it All right, yeah, I'll take a look. Um, I was just on the Rapper issue, uh, so I didn't know though Curtis did you mean to me yourself? Oh, um, yeah, I I'm echoing. So that's why it was actually grant I think we might have been coming from grants. We'll try again. He's muted now. Okay Um, so, yeah, I haven't I hadn't gotten a chance to look at all the issues I was currently just looking at the pythonic one because that was one of the older things And that seemed like a good place for me to start Uh, but I can definitely um look at, you know, What's broken with the support? Which issue was that exactly? Was that using extensions with dictas? Yeah, right 32 That's the only thing that prevents this out of the box from working at the moment So, yeah, I will I think I might have So Curtis, are you are you planning on taking a very active role in this SDK? Yeah, um, I planned on more like right now on my branch It has an out of the box. You can just create a flask server and use events to emit and stuff um, so I had gotten that at least working to Um, decent amount so I can work on this like over the summer while I'm here Okay, because it sounds to me like we we really need somebody to own this puppy going forward because I don't think we have anybody else very active and I'd love it if you if you would like to you know volunteer for that and then you know, we can make you a maintainer and all the other Good stuff because what do we? Say it again. All right. Are you an intern, Curtis? Yeah, I'm an intern at the moment. Oh cool. Where are you interning? Um, I'm in new york and I was on the cloud run team So, yeah, neat. Awesome.  Yeah. Well, newbler Newbler, sorry Okay Uh, but yeah, I'll definitely I'll post um, some links like this to my forks and I'll look at the other issues Uh, soon one at a time Okay, so Yeah, so from from a process question It doesn't sound like anybody can identify anybody who's actually really active on this sdk Is that correct? Yeah So to my knowledge, um grant had told me that my point of contact would like to end up being um, I think his name's dustin ingram So, uh, I think we have a meeting with him on friday So I was going to use that to capitalize and get more knowledge on you know, things I don't know that I don't know Okay, cool The reason I'm asking is more from a process related question because obviously you it'd be great Obviously, you open up prs review these issues and do all the great work. But um, if either dustin's not there or Dennis isn't going to be there to review your prs. Then That's a problem, right? And so we so we need to think about making you a maintainer and I don't think that's A problem because we we will make people maintainers if there's no one else in the group to to say yes or no Right because we need somebody Um, but let's make sure that we're not going to be stepping on someone else's toes if for example dustin is actually very active And we just don't realize it Yeah, that's so as grant said before the last committee was in like april 27th. Um So it's a little inactive, but definitely like, you know, it would be nice of another person to get PR Is done in a timely fashion. Yes Let me know how the conversation with dustin goes and see whether he's planning on actually being active or not That'd be helpful All right, cool Yeah, um, so just for context. Um, so I'm I'm going to be working with Going recently Yeah, so our plan is uh, if it's okay to improve the python sdk over the summer and We'll be Curseful He's sending the prs and um anybody that's really interested Can be involved too, but uh It'll be any greatest Dustin since he's Um Thank you. Cool. Sounds great. Thank you guys All right, uh anything else for the agenda today Could be a very short call One once All right We are done then. Thank you everybody and we'll talk again next week Have a good rest of your week. Thank you Thank you. Bye. Bye. Thank you. Bye. Bye


Calorie restriction in primates to extend lifespan. Will it work? There's only one way to find out. There have been four investigations of calorie restriction and lifespan in non-human primates. The first was published in 2003. An analysis of the mortality of 117 Rhesus monkeys followed for about 25 years in a lab, eight of whom had their Purina monkey chow restricted. The average survival of the restricted monkeys was to 32 years of age compared to 25 years for the control monkeys. However, it was more of an observational study since the monkeys weren't randomly assigned, and although in the abstract they talk about the survival advantage and how the ad-liberatum monkeys, the eat all you want monkeys, had more than twice the risk of death, but they acknowledged deeper into the paper that the difference in death did not reach statistical significance, meaning it may very well have been a fluke. That was all we had, though, until results started trickling in from the famous pair of studies that involved randomizing about 200 Rhesus monkeys to caloric restriction or more normal diets, one out of the University of Wisconsin-Madison and another from the National Institute of Aging. The UW study reported that 30% calorie restriction significantly delayed disease and improved survival, but the NIA study did not. In the UW study, calorie restriction reduced the incidence of age-related diseases, including cancer, cardiovascular disease, brain atrophy, and muscle wasting, preserving muscle mass, demonstrating calorie restriction can delay aging, but in the NIA study, the difference in age-related diseases did not achieve statistical significance. In the UW study, the restricted monkeys lived to an average of about 29 years, compared to the control monkeys who lived closer to the average for monkeys in captivity of about 26 years old. In contrast, the one of the restricted monkeys in the NIA study became the longevity record holder for the species at age 43. On average, the restricted group didn't live any longer than the control animals. Why the disparate results between the two studies? In the NIA study that found no significant lifespan difference, the control group was not fed ad libenum, but rather had food portioned out to prevent excess weight gain. In contrast, in the UW study, the control monkeys could eat as much as they wanted throughout the day, so ended up weighing more than the NIA control animals. Of course, caloric restriction would improve the health and survival of overweight monkeys, just as weight loss would be beneficial for overweight people. But the null results in the NIA study suggest that normal weight people might not benefit from restricting further. The NIA monkeys were also fed a healthier diet. The diet in the UW study, where they saw significant benefit to cutting down, was an ultra-processed concoction of largely milk, protein, corn oil, corn starch, and table sugar, whereas the NIA diet actually included unprocessed plant foods such as corn, soybeans, and wheat, so actually had some phytonutrients. About 29% of the UW diet was straight sugar compared to 4% in the NIA diet. American adults get about 17 teaspoons of sugar a day, which is about 13% of calories. The contrasting findings suggest that the worse your diet is, the more important it is to eat less of it. The fourth study was on gray mouse lemurs, among the smallest of primates, standing just 3 inches tall. Those randomized with 30% caloric restriction compared to an ad libitum control group lived a whopping 50% longer, and not just average lifespan, but maximal lifespan. The maximum lifespan was boosted by about 20%. However, the calorie-restricted group still weighed heavier than their wild counterparts, so again, this may just be an illustration of the harms of obesity and another indictment against all you can eat buffets. Also, those in the calorie restriction group experienced an acceleration of age-related loss of gray matter throughout their brains, though this did not appear to translate into cognitive or behavioral differences. Pooling the three rhesus monkey studies together, there seemed to be a lower age-related mortality, but no significant difference in average lifespans, overall, between the caloric restriction groups and the control groups. Given the time and expense, there's little chance we're going to see any more long-term primate studies on caloric restriction for life extension. So what can we draw from the primate data to date? If you're overweight or live enough junk food, eating less is a good idea.


This is Witch Based News for Friday the 9th of July 2021. I'm CMDR Buur. In a packed bumper show this week, the Anti-Xeno Initiative are running a new week-long event, the Apollo 15 Expedition Preps for departure, Frontier share some community calendar work in progress shots and we'll share some thoughts on the future of the Buur Pit, plus much more. To make sure you don't miss any of our videos hit like and subscribe, click the little bell icon and remember to select all notifications. And to further help support the work of this channel you'll also find us on Patreon. Links to everything you need are in the description below. The Galaxy's premiere alien squashing mega community, the Anti-Xeno Initiative, are holding a new week-long AXI Academy event starting on Sunday the 10th of July. During the event the AXI will provide personal mentors to any and all would-be trainees to help them reach their next goal be it a solo kill or a first basilisk kill etc. Teams of Anti-Xeno trainees will score points for hitting their goals and the biggest points at the end of the event will win titles in the AXI Discord and even a shot at a 2 billion in-game credit prize. If you fancy a shot at becoming the Meany Greeny Danger Daisy's next nemesis then check the video description for the link to the AXI Discord's event channel. If you're playing Horizons on console or PC and you're in the market for an expedition then Commander Yannick will be leading the Apollo 15 anniversary expedition from July the 10th to August the 1st. Build as Horizons last hurrah and celebrating the 50th anniversary of the achievements of Apollo 15 the expedition will be leaving from the hind Nebula and visiting the twin mountainous worlds of David and Goliath. The expedition is open to all levels of experience and abilities. To find out more and get signed up check out the links in the video description. Good luck on your expedition commanders fair winds and calm seas from everyone at the pit. With Covid restrictions currently still in place last weekend saw the annual LaveCon Elite Dangerous Convention become a virtual online event again. The SRV fanatics on the Elite Racers and Buckyball Racing Club communities had planned to meet up at the event and weren't going to let something like a worldwide pandemic get in the way of their fun. Undeterred four of the wheeled maniacs met up in Northampton at Sedgebrook Hall the hotel that was to have served as the convention's venue and filmed themselves go-kart racing complete with Formula One style onboard telemetry racing for the honor of first place and a 3d printed elite commander bobblehead. To see the full race in all its first person glory then check out the link in the video description to Alec Turner's channel on YouTube. If you're looking for the next thing to go and visit in Odyssey or Horizons then commander heart kicker of the Elite fan program has produced a huge collage image of options for you. Taking around a thousand hours spread across 90 days to complete the Elite universe guide contains around 800 locations spanning both horizons and Odyssey. It's an incredible body of work and well worth a look. I've linked below to the source image. It's so huge that you'll likely not be able to view it properly in a web browser so be sure to download the image first and then zoom in to the details. It's honestly amazing. In-game there was a server side patch this week that fixed a significant number of predominantly mission based issues in Odyssey featuring but not limited to restoration missions not being completable data theft missions displaying correctly on your HUD and the required data being available to steal likewise salvage missions displaying on your HUD and the required salvage being available a rebalance of faction influence effects and mercenary rank progression has been sped up. There was also a fix delivered to horizons this week that specifically dealt with the spawning of thargoid beasties in nonhuman signal sources so if you've been experiencing problems there then that should all be working as advertised for you. Whilst no patches are currently publicly scheduled from frontier like they were in the six weeks immediately after Odyssey launched community manager Sally has made mention on the forums this very morning that the team are still working behind the seams on the next steps post update 5 and they'll post an official update on that when they're able to. We think we're into a phase of patches fixes and optimizations being delivered as and when they're ready now rather than the somewhat forced roadmap style of weekly patch delivery that the team was pushing out before following David Braben's forum posts. As I've said at least twice before on these broadcasts the expansion was as we all know released too early and Odyssey undoubtedly still has quite a road ahead of it. Most notably in the areas of lighting, terrain rendering and frames per second drops all of which were detailed in the development update from the company last week. However it is in a better place than it was during the rocky launch period so if you've not dipped your toes in since then and are perhaps missing your space fix then it might be worth you giving it another go just to see if things have improved for you personally with the caveats I've just mentioned obviously. We know from here on that we have scheduled monthly developer updates likely in the form of a forum post and community manager Zach made mention on the forums this week that a focused feedback thread on the future of the power play system might be a good idea. We know that previous focused feedback initiatives on combat payouts UI changes and the camera suite for example have all proven very productive so this may well be the wave of the future. Elsewhere on the super cruise news livestream this week the community team shared some images of the currently working progress community calendar being developed by the web team at the company. As we mentioned on the last episode the web based calendar system will allow community members to post their own events that will appear viewable to the whole community after a moderation sweep has been through and approved the post. We're quite liking the look of this system and it could be a really productive way to get the word out about the many weekly community driven events that happen in the game that often go unnoticed. And finally this week we've been asked by a number of people over the last couple of weeks if the burpit is planning on becoming a variety channel creating content for games outside of Elite Dangerous or even moving away from Elite Dangerous completely. Rather than keep answering the same question in as many varied and interesting ways as we can we thought it best and would like to answer the question about the future of the burpit more publicly here. So let me confirm for you now the burpit has no intention of switching games or featuring any other games whatsoever. We are exclusively an Elite Dangerous channel and we will continue to feature Elite Dangerous, its news, its community and its goings on in their many varied forms rain or shine. So with all that being said wherever this journey may take us we hope you'll continue on the road alongside us. That's it for now. Thanks very much for watching. We'll be back later this week with more videos. Until then, O7 commanders follow the greens on the way out and do keep clear of the toast rack. We very much look forward to seeing you next time.


Well the countdown to kickoff is getting closer just three days away now until the Lumberjacks take the field for the first time and after taking a step back in 2016, the Jacks are ready for a fresh start. Coming off a 1-8 season in 2016, but Midgie is hoping for a fresh start. With that, a new motto, trust the process. Trust your teammates, trust the process. We're going to have some adversity along the way. Could happen on the first play, could happen in the first quarter of the first half. Doesn't matter. With a bunch of new faces and the makeup of this roster being mostly young players, it's easy to wipe the slate clean. I think the biggest thing is to realize that we're a new team. We don't have very many returning players. It's not like we need to just get over the last season and we have a new team here. That includes a new man orchestrating the offense replacing Jonah Moller and they're hoping junior Jacob Bberg is ready to be the guy. He's the only guy that has any experience and he's an extremely athletic kid that we really like in our offense. He's had a great offseason. He's had a great two weeks. He will, he'll make plays for our offense. The Jacks philosophy dominate the line of scrimmage and run the ball effectively and they're hoping some new faces up front and balance in the backfield will help set the tone. We have a lot of running backs and we'll just play it by ear. You know we're gonna we're gonna obviously have some kind of a rotation by Thursday but right now we're going to get them reps and see who climbs at the top. On the other side of the ball it's simple go back to the basics. Working a lot at the fundamentals this year kind of went backwards. Decided that we needed to just look at all the simple aspects of everything hitting hard and hitting with her shoulder and not her face. Just making sure everybody knows how to tackle, where to tackle, when to tackle. So trusting the process and starting fresh will ultimately lead them to their goals. To take it one game at a time make sure that we understand that we don't need to have a winning season. We just need to have a successful season within ourselves. We need to win one game at a time focus each week on everything that we're doing. They'll open up hosting Rogers Thursday night at BSU at 7 p.m. If you've enjoyed this segment of Lakeland News please consider making a tax deductible contribution to Lakeland Public Television.


Yes? I am sorry for the late start. A little bit of laptop trouble but I'm on الن belongs to books now. So maybe I should have done that from the start. So my name is Simon Glass. I'm here to talk a little bit abreviatedly David walls new Noble on what's new in New lyrics. So, here's my goals of this talk. I will say that I'm, I don't know everything about U-boot. It's a huge project, but I, so I'm going to talk a little bit more about things I know about than things that I don't, and it's only natural, right? And I also, I also know that some people use quite old versions of U-boot. How many of you are using a U-boot that's five years old? Yeah, what about two years old or more? Yeah, so it's not very common to update your U-boot. So some of these things, I will mention some things that have happened perhaps older than two years ago. So just an overview of U-boot. It's been around quite a while. Since 2012, Tom Renie has been the head custodian, and there are about 50 other custodians for different areas of the project. It's about 2.2 million lines of code, but a lot of that is board specific, you know, drivers and things like that. The amount of code you actually compile into your particular board is considerably less. It's a release cycle that was two months, and now it's three months. There's a lot of contributors, a lot of things going on in the project, and it has quite a strong links to Linux. It uses Linux code style, obviously, and some Linux drivers and so on. I'm not going to talk about these things, and probably these things have been true five or even ten years ago, certainly five years ago. So U-boot has very wide architecture and board support. It has a mechanism for loading U-boot, which is, you know, several hundred k, when you've only got a very small amount of SRAM and you need to get your SDRAM going. It's called TPL and SPL. It's got pretty wide image support. There's also a sandbox architecture, so you can run U-boot on top of Linux just for testing and for development, and so certainly in my case any feature development is done in sandbox because you can use normal host debugging tools and all that sort of thing, and then it just works as expected on the actual board.  I won't be able to run it on this Chromebook, but take my word for it, you can run all the different commands and things like, you know, looking at files in the files system, looking at memory, changing memory, that kind of thing. So here are some things that you may not have known about if you're using the U-boot from four or five years ago. So U-boot has a driver model now, which is designed to take care of all the different drivers and devices you might have in your system. It uses k-build and k-config. There's several, actually, at least three verified or secure boot mechanisms. It supports firmware update and fastboot, that sort of thing, and it's attached to the co-verity system, so we actually get security emails telling us to go and fix our code, that kind of thing. So just to look at a couple of these things. First of all, driver model. How many of you have used driver model or seen driver model? Okay, some of you. All right. So it's fair to say that it came out in 2004, and I think it's, sorry, 2014, and I think it's settled down a bit now. We have it sort of embedded in most areas of U-boot. The goal is to allow you to specify the devices in your system using device tree as we do on Linux. And by doing that, we can then effectively use those devices within U-boot without having to run a whole lot of code to set them up. So here's an example. On the right, you can see there's an I2C bus. It has a PMIC in it. That PMIC has a LDO, and we want that LDO to be set to 2.8 volts and some other things as well. And so at the bottom left, you can see that we're automatically setting all the regulators where we know the voltage. You can imagine behind the scenes what's happening. It's going and finding that PMIC. U-boot has lazy initialisation, so it will only do it when it needs to. It will go onto that I2C bus. It will send some register commands to that PMIC to set the voltages, and it will do that for the three different regulators that we've mentioned there. So that's something that driver model can do, whereas previously, perhaps you would have had to code all this up with register accesses directly in your board code. I'll just mention this. I don't think it's widely used, but it's a mechanism for measuring boot time through the different stages of U-boot, through different phases, and getting that sort of microsecond count to find out where your boot time is going. And there's even a tracing mechanism that you see function tracing. It's a little bit atrophied now, but it will record tracing information. You can actually write it. Here we're writing it using a network, and then analysing it on the host. So I want to mention Buildman. A couple of years ago, there was a script called Make All, which was designed to make all the boards, and that would tell you whether things were good or not. And that got retired in favour of this thing called Buildman. At the bottom right, you can see I'm doing a build, a very ambitious build here. I'm building a tree with 145 commits for all of the boards. It's about 1,300 boards in U-boot. And it's busy there working away, and it's going to be done in about 24 hours. I didn't continue that. I didn't let that finish. But Buildman essentially lets you build any number of commits. It lets you build for any number of boards. You can select architecture and that kind of things. And it handles the tool chain for you. It downloads the tool chains if you ask it to. And it's pretty easy to use. And on the top, we've got the analysis phase. So when you say minus S to Buildman, it looks at existing build that you've actually completed. And here it's telling us where our code size is changing or our data size. It's a little bit... There's a lot of changes going on here because this is a series which introduces... Refactors and introduces SD RAM support for a particular SOC. And yeah, there's a lot of commits. But basically if you look at this, here you can see the text size has gone up by about 60 bytes, which isn't too bad. And some of these functions have gone up in size. Red means they've got bigger. Green means they've got smaller. So it's pretty easy to see where you've made things better or worse in terms of code size. Buildman also supports config changes and environment changes. So now I'm going to talk about some of these new things. I'm just picking a selection of things that I'm going to mention. Hopefully, if you've not looked at Uber in the last couple of years, you won't quite know what these are and you'll learn something. If not, please tell me what you wanted to know afterwards. So the first thing is device tree overlays. These are not... Not needed on every board, but here's an example of a base board where we can connect a number of additional add-on boards to it. And the device tree basically is used to describe what devices are on that board and when you add a different adapter board on top, obviously you're changing the devices that are available. And the mechanism used in the kernel to support this is device tree overlays. So here on the right, you can sort of see I'm loading in a couple of device trees. I'm then applying the overlay and now I can see that my display has appeared, whereas previously it wasn't there. So that's a very, very simple example of an overlay being applied in new boot. And so when we have an add-on board, we can access its peripherals. If you do this early enough in new boot, then new boot can use those peripherals too. New boot can use that same device tree. So obviously that's supported in new boot and SPL workers in progress. It's also possible to do this within Linux, but the nice thing about having it early and having it ready to go is everything is consistent. So new boot's had device tree for quite a while, but it was a little bit clunky. There's a new interface called a live tree interface. The code for that was largely copied out of Linux.  So we've got several examples here. The simplest one is on the bottom left here where we're reading boolean values from the device tree. That's just going to read it from the node associated with that device. And we've got other things here like reading the address of the peripheral and reading resources and so on. So it's a fairly consistent interface. You don't have to worry about device tree pointers or anything like that. You've not got config.of live enabled. It will still work. The dev read interface still works. It's transparent. It'll work no matter whether it's a live tree or a flat tree. So in new boot now we're trying to use this interface in preference to anything else. So this is a little bit of a crazy thing. It's not really widely used in new boot, but there are about, I think, five or ten boards that use it. The device tree does add overhead. Typically the code size increase on ARM is 3K, 3 or 4K. And the device tree itself, obviously the device trees are typically 40 or 60K or even 100K in size. What we do in new boot is we actually grep down the device tree and remove the things that aren't used in SPL. So SPL is a very small memory constrained thing. You get the device tree down to about 3K in SPL. So the overhead typically is 6 to 7K, which is not too bad. But if you've only got 32K of RAM, it's VES RAM, it's too much. So this is a scheme for converting the device tree into C automatically. You can see what it's doing here. On the top right you've got a device tree node for a memory controller. And here's what it produces. This declaration and the header file here. And then it produces the actual contents of the device tree here and then declares a U-boot device. So hopefully that makes some sort of sense. You can see what's going on. The point is when you run SPL now you don't need the device tree. It's just not necessary at all. You've got all the data you need and available in C. And if you're interested, the code that's actually used to access it is a set series of assignments to assign from this web structure that DTC creates into your correct one, the normal one that you would use with device tree. And if that's enabled, you do this special code to copy things over. And that's much smaller code than having LibFDT in there. A couple of other things to mention. There's Android bootloader support, LibAVB is in U-boot now. And there's a... There's also an opti driver, although no command. So there's an example of a boot flow there, very simple. You run through this verify command. If it verifies, then all is good. Otherwise, you've got a problem. It's just... I think it's the third or fourth verify boot mechanism in U-boot now. U-boot, sometime this year moved to GitLab. And I quite like it. It does similar things to Travis. It's a little more integrated.  So that's fairly new. We're still using Travis CI, but we'll see how it goes. If you've got a build server sitting around, not doing anything and want to hook it up to provide capacity, please don't let me stop you. Which leads me on to this, which I think is really cool. U-boot's firmware's not the best place for testing. Quite often, when people write firmware, they just write the code and they manually test it, and they don't change it ever and that sort of thing. Or maybe there's a lot of manual testing or functional testing of the actual device and that sort of thing. U-boot, in the last several years, has been an effort to increase the amount of automated testing that's available. So there is a thing called Pi test. It's basically a number of unit tests and functional tests that are built into U-boot. Things like, for example, do the file systems work? Can I write and read files with the file system support? Can't do all of the different driver model U-classes actually work. For example, there's a test that basically uses a simulated USB stick. It goes and tries to read a couple of blocks off that simulated USB stick. Obviously that requires going right through the whole USB stack and therefore we get some feeling that that kind of works. When you run, it's actually make Q-check, or make check, it will run all these tests. It takes about a minute or so including all these things. And they use sandbox when you run them on your machine. The test can also run on QMU or they can run on real hardware with appropriate hooks. And there's a thing called T-bot. Is anyone using T-bot? Anyone familiar with that? Yeah, okay. So I don't, I guess it's not widely used, because of all this, you test U-boot Linux and beyond on real hardware and it collects the information, the failures and that sort of thing. So I think what's going to happen over the next few years is more and more of this stuff is going to become possible. Traditionally, or more recently there has been this use of these Wi-Fi flash sticks. They're used for cameras, but you can basically send U-boot and then reboot the device with some sort of power control module and that allows you to test that it's working. But there is this thing which I recently discovered and maybe I'm just slow which is called SD wire which plugs into your board and then connects to your development machine via USB. So now you can control, you can write to the SD card over USB, some sort of new U-boot Linux, whatever and then use power control to reboot it. And now you can obviously access the console and see what's happening there. So connecting that to GitLab I think will happen, hopefully as well, more and more people will have these things running automated tests on actual real hardware. So U-boot supports EFI, the EFI interface effectively. You can boot, for example, you can boot Linux, but you can boot Grub 2 and use that. And this came from Sushi and I think it's been fairly widely publicised, there's been a few talks about it. Essentially with this you can run an EFI application, U-boot provides console support, serial support, network disk and that kind of thing. So you don't actually need U-EFI as such if your platform supports U-boot. And there's pretty good tests associated with that as well. There's a recent change to use restructured text for documentation and also the documentation this is a large amount of documentation in U-boot. It's all sort of traditionally been in this big doc directory and you kind of grip for it really because otherwise you couldn't figure out where it is. So now it's kind of moving to being inside a directory which mirrors the architecture and the board directories. So for example you'll put your board or documentation in doc board and then the name of your board, that kind of thing. So I think there's a minor change but it should help people find things a bit more easily. And I'm just going to mention some things, some other random things. These are things that I've worked on and that I wanted to have to put up with me talking about basically. I won't take too long. The first thing is Binman. Binman is a firmware packer. It's not widely used. It's used by SunXI, Integra and a few other things in X86. It's written in Python. Basically the way you use it is you put a device tree description of your image in there somewhere and when you run Binman it will automatically produce an image. Here you can see it's taking SPL, it's taking the image, it's a bit weird but this is, have you heard of Coreboot? It's another bootloader. The state is making a Coreboot file system with these three files in it, with some compression and so on. So that's what Binman does. It's basically a one pass firmware packer based on a configuration description. So it's not run lots of commands to build up your image. You just describe it in one place and it very quickly puts it together. It's very handy for complex images to assign a particular piece of the image and put that data somewhere else and all that kind of thing. So the status of this is it's kind of, I wouldn't call it feature complete but it's been in use for a while and recently it's had a bit more effort and we'll work on it and we'll see how it goes. So those of you know me a little bit over the years, traditionally I've not had a huge amount of interest in X86 stuff. However, for various reasons, I was briefly the X86 maintainer for Uboot. We now have a much better maintainer, luckily. That has still maintained some interest in it. Uboot supports bare metal operation on various different X86 CPUs. Traditionally, X86 uses UFI and Coreboot and so on, but Intel FSP that's become standard now. There's actually not that much code needed in the bootloader. A lot of it is in the FSP. In fact, Intel has a thing called Slim Bootloader. Anyone heard of that? Yeah, it's very new but this effectively lets you boot using the FSP, this sort of binary blob stuff that Intel provides and very quickly get something running on a platform and Slim Bootloader recently supports Uboot as a payload, so you can jump into Uboot and then have all these features, all the Uboot features that you expect, but you haven't had to do very much work. So X86 is an interesting environment. I'll just quickly mention logging. Again, this is not widely used, it's fairly new, but if you build, for example, if you build Uboot with all the logging enabled and run it, it will produce huge amounts of stuff. All the debugs turn into printfs or whatever. So there's an ability now to categorise things. Let's say, for example, it's a USB message or a spy flash message and you can filter accordingly. There's different levels from debug up to info or warning or critical or whatever. And some little helpers like this thing here, which if there was an error, then we just return the, we log a message and return the error. Now this gets cut down to just simply a return of the error, but if you've got logging enabled, you get a message telling you why it returned with an error. This can be very handy when you're trying to debug a particular driver or whatever. So again, it's not really widely used, but I think we'll start to see the sort of thing used a bit more. And Pat Mann is really, really old. I really shouldn't be, I really shouldn't be talking about this and something that's new, but many people are not aware of it. It's just a little tool which lets you essentially build a patch set and send it to a mailing list. Here we're going to send it to Uboot and I'll CC this guy and we're going to, here's our cover letter and it will just produce the patches, tidy them up and email them off before you will let you check them first and that kind of thing. So just mention that. I'm not going to do a little demo. It doesn't run on my Chromebook. So it's going to talk at the end about what Uboot might look like in a few years. So Uboot is, it's very hard to predict because it's very much set by contributors. Someone will turn up and say, gosh, I wish Uboot could buy a supporter. I wish it supported, whatever it might be. And we never really know, you know, never really predict. It basically is driven by the market and by, you know, technical demands, right? And so lots of random things come along out of the blue. Uboot is basically there to quickly and easily boot your system into an operating system and whatever that system might look like and so as systems change trends change and so on, Uboot's obviously going to evolve. But here's a few things that I think I can predict with some confidence. I mentioned the test farm business and I think we'll likely see a lot of custodians having two or three boards or four boards sitting there, running tests, pointing to a particular tree, maybe it's master or some of the other trees on that lab and running automated tests and emailing me or somebody when they break things. So I, for example, I know that Nvidia does this because every now and then I'll get an email from some automated thing at Nvidia saying, you broke this. Not very often, I should hasten to say. But yeah, I don't think there's very many companies doing that. I listed some, I think, do it but it's not widespread. I think that will grow and the benefit is that regressions become less common. At the moment, if you're using a really widely used board, it pretty much always works but if using some weird board that, you know, and you've it's been two years since you updated Uboot and you're going back to update it, then maybe there'll be a problem because it's not getting a lot of testing. I think the driver model migration will start to come to an end. There's quite a lot of deadlines this year for most of the subsystems and k-config, I think there used to be 9,000 config options. We still have 4,500 out there, most of them are board specific but I think that migration maybe will come to an end at some point before the end of the universe. I think we're going to see more Linux code in Uboot, some of the subsystems that are coming around is a lot of pressure to make them work in a similar way and be able to update them from Linux back and forth and that sort of thing. So I think that's something we'll see and I'd like to see this but I don't know if it'll happen that new code comes with tests so when you write a new file system or when you driver or whatever there's a test that goes along with it to make sure that it works and that nobody breaks it down the track. And finally Uboot just keeps getting slightly bigger, a few bytes here, a few bytes there little new features and so on and it's extremely configurable. You can turn off an awful lot of stuff you know you can turn off a command line for example and save a huge amount but I do have a scraping concern that you know it's getting a little bit bigger to do the same thing as it did 10 years ago and so I think we'll likely see some effort in that area to sort of start to trim it down a little bit as well. So sorry that was a little bit abbreviated due to my laptop fell up but thank you for listening. I do want to say if you've never seen a patch to the Uboot mailing list now would be a great time to do it. It's a pretty friendly mailing list I think people most of the time you know all in it together and get on pretty well and they're happy to help there's an IRC as well where people are always helping out I'm not very good at that but yeah if you don't have any trouble please sing out my details at the bottom if you email the Uboot mailing list and CC me you'll get me so that's it I don't know if anyone wants to have any questions but thank you very much sure are you talking about Buildman this thing better in what way if you're building your own board you typically do an increased use make we use an incremental build yes you can use Buildman every time you want to build for your board but it's not very efficient for that it's more to do with all of them yeah I mean I don't know love to improve it it's basically it doesn't use it's incremental in the sense that when it builds the first commit and then it builds next ones they are incremental so it's not just rebuilding each one very fast I mean I know 24 hours to build 200,000 commits is not too bad yes there's a config file that lets you select the toolchain so you can do what you want there but yeah patches are definitely welcome anyone else yes LPDDR training well I'm seeing for example Rockchip recently moved to using TPL and doing the training there because the code is so large yeah I think I don't know where that's going to go I'm also just recently been looking at until Apollo Lake and I think it needs 180k of memory for the memory phase and it takes something like 30 seconds 25 seconds to do the memory training so well I think you might have problems probably not as bad as that it is a challenge that the technology is getting more and more bleeding edge and more and more advanced and I'm not too sure where that's going to end up anything else okay well thank you very much for listening


We explain mitral valve prolapse based on a true story Meet Maddie at a recent doctor's appointment a pediatrician discovered that her daughter Lacey has a heart murmur After being evaluated with an echocardiogram Lacey was diagnosed with mitral valve prolapse If the heart was cut in half This is what mitral valve prolapse would look like compared with a typical heart Maddie is still unsure what this means, but Lacey's cardiologist Dr. Goldstein is happy to explain To start mitral valve prolapse also known as MVP No, not that kind of MVP is when both the flaps or leaflets on the mitral valve collapse backward into the left atrium The most common cause is abnormally stretchy valve leaflets Although it can also be caused by other health problems such as connective tissue diseases Some people with MVP might not experience any symptoms while others may experience a racing or irregular heartbeat Dizziness or lightheadedness difficulty breathing shortness of breath fatigue and chest pain Dr. Goldstein tells Maddie not to worry because typically MVP is a minor issue But Lacey should still get checked regularly because sometimes it can become very serious For example, it can cause arrhythmia that could become life-threatening Also in certain cases the prolapsed valve regurgitates or let's blood leak backward Which, in large amounts, can form blood clots that potentially lead to stroke or heart attack Depending on severity, Dr. Goldstein reveals that he may treat Lacey with medication But if her symptoms get worse, the left ventricle of the heart becomes enlarged Or the heart function worsens, they may need to repair or replace her mitral valve Dr. Goldstein assures Maddie that now the condition has been diagnosed, Lacey will be in good hands They will closely monitor her and if the problem becomes severe they will appropriately treat her to ensure she is healthy