What's up guys? What's going on? Yo view up trader. What's up, Ian?  How's everybody doing today? Let's see. We got the Netflix ER that just came out Everybody is hype squid game.  That's all I can ask for man You know, what's up yet world? See G2k, what's going on? Let's see So compared to last year, this is a 83% increase in earnings per share and In terms of sales, this is a 16% increase compared to last year What was the stock trading at last year around 5 30s for 85 to 5 30s pretty big Pretty big increase compared to last year at based on the rate that's going See, what else they said Netflix says they added four point four million pay I don't know additional subscribers I guess Q4 sales What the hell? Netflix sees Q4 sales at seven point seven billion as opposed to seven point seven one as opposed to seven point six eight however They think the earnings per share is going to be weaker at 80 cents as supposed to be as opposed to a dollar and ten hmm Sus That means they're expecting a weaker. I guess I guess maybe the mind that game studio is gonna affect them a little bit Interactive broker also came out as well Let's dig further in this into this Man, I just want to see them say stocks like please Netflix. Just bless us with that Stock split and I got them 740 calls waiting for the stock split. Where is it? Massive rugpo Sean says After a lighter than normal content slain Q1 you too due to COVID related production delays in 2020 We're seeing the positive effect of a stronger slate in the second half of the year in Q3 We grew revenue 16% year-over-year to seven point five billion while operating income rose 33% versus the prior year quarter to 1.8 billion. We added 4.4 million net pay I don't I guess subscribers Versus 2.2 in Q3 of 2020 so they they they apparently way was doubled the count there That's a huge increase 4.4 mil as opposed to 2.2. All right and with 214 million pay memberships We're very excited to finish the year with what we expect to be our strongest Q4 content offering yet Which shows up as the bigger content expense and lower operating margin margin So they said Q4 is gonna be amazing and and it's gonna be like their best Like contents yet, but it's gonna hit their margins So year-over-year growth So Q4 year-over-year growth forecast is gonna be a little bit weaker looking at 16% as you can see like This is actually a little bit bearish here because you can see the year-over-year percentage growth getting weaker and weaker as the quarter Go on so last year Q3 was a 22% Q4 was a 21 Q1 of 2021 was 24% And then Q2 of 2021 was 19% with Q3 Hitting only 16.3% In terms of revenue growth and Q4 hitting 16.1. So that's a declining trend though So that's like that's a little bit bearish in a way because it's going downhill But at the same time COVID these COVID quarters are very hard to compare it to because Those are the best of the best times like everybody is home and what else they had to do but watch Netflix, right? Um Let me see what else Burning's per share next quarter is gonna be a little bit weaker as well Net income is weaker. Everything is weaker next quarter, man If they don't announce the stock split man This might be a big flop because the data isn't like showing as good So the weekly global pay net additional year to date is a little bit weaker than the other years too And you can kind of see that as well Programming strategies for my member for a wide variety of high quality content. That's not the most large numbers Money heist Season three of sex education Queens gambit May I haven't seen any of these And then I said there's no better example of this than the squid game Leasing September 17. It's become our biggest TV show ever a mind-boggling 142 million members Household globally have chosen to watch the title in the first four weeks. That's huge Yo, apparently this like this this show has been ranked as our number one program in 94 countries Holy smokes. They said they said their movies are also like super successful such as sweet girl kissing move three and This vivo and blood red sky, I don't know. I wouldn't say they're that successful Damn, they're top 10 films. I kind of trash, man. I Wouldn't recommend anybody to watch these. I don't know about you guys though Check out this top 10 film Let me know if any of you guys if you guys recommend any of these is on there yet I give up man. I'm just gonna look for split Watch for a box.  It was just as hype at squid game, but it was it was like utterly trash That was pretty much it. I gotta say not as hype as I wanted to be You know, we're all a little excited for that Netflix Expect them to blow out the water, but the guidance wasn't there You know growth wasn't really there and a lot of decline growth a lot of like weak guidance We didn't get that stock split news. I think we're going downtown Like because it just I just finished digesting most of that earnings report and as other people probably finished digesting it I I can't I can't say I'm like super bullish on a man. Sorry boys Sorry, man. I hope I didn't question anybody's dream Yeah, from YouTube side You guys wanted us to add some some stuff to the chart. I can do that today. I Don't know if we'll have the time though I got to leave at five today because I got to do something after this I'll add Netflix if we have time. I'll chart out We'll get some directions and things like that Let me see what else you guys said. Yeah, world says average revenue for membership was stagnant I see Netflix potentially raising price or introducing ad base membership. That's true That's not a bad idea doing something like Hulu What's up buzzer, I think the subscriber growth doesn't press to this quarter What's our prediction for Roku and Disney is the time to go all in Disney or Roku? I mean Disney is a good price point around 170 could be a bind up to any Roku was saying we versed it upside So maybe but I'm not sure. I it's like the market seems saturated, you know, so it's a little bit tricky Not gonna lie in this pretty earning was pretty hype indeed. It was. Oh, yeah, gotta see that. I got you, brother AV IR if we have time, I'm gonna check AV IR for you. All right, let's go into I think Roku could possibly get affected by this Roku and Roku and Netflix need to trade in tandem But I don't know what happened lately. They decoupled. They don't trade as much anymore. Let's check out IBK or So IBK are Interactive broker group trading company kind of like Robinhood but internationally, right? And offer a much superior product. They just started adding crypto, which I think could be big for them Let's see because there's a lot of boomers to use it and a lot of like international people use it Interactive broker earnings per share 78 cents as it was a 75 cents sales is 464 million huge miss here actually 464 as opposed to 640 estimate how they missed that So EPS earnings per share was 47% increased compared to last year stock was trading around 50 something dollars So $50 times 1.47 I put around that $73 range right there Somewhat fairly priced to a certain extent But sales just didn't do it sales is actually a 15% decrease I don't know what happened there. I'm sure if we dig into it. Maybe they spent some money on improving the platform or something like that But they did just recently add the crypto stuff I think they add like for crypto until their platform. So that's pretty I think that's pretty interesting that that could drive some revenue there as well long-term Martin transport also reported today Let's see earnings per share was 26 cents as opposed to 25 cents estimate sales of 251 million as opposed to 237 30% increase compared to last year 16% increase in sales compared to last year This is a temperature sensitive truckload carrier in the United States Engaging transporting and distributing food and other consumer package goods. Hmm interesting there Maybe it would be a buying opportunity, man. Since everybody keep like whining about all this shipping You know choke holes and things like that What else we got going on today the blue default II also reported earnings as well Earnings per share 61 cents it says it may not come here to Hmm. Am I streaming it?


Let's say you've been trading for five years on your own. And in these five years that you've been trading on your own, you haven't really found success. And then you look over to the guy that's been trading for a year and he's banking.  And you find out that instead of spending, you know, $5,000 on a trip to Florida, he spent $5,000 on his education. And now that paid off as an investment into himself and he started to make money. If you want to take double the time, do it through experience. You'll get there. It's probably just going to take double the amount of time.


Hello. This is Bin from AAC. Hey, Bin. Good morning. Yeah, let's give it another couple of minutes for people to join. All right. Looks like today we may not have a very large audience. Yeah, thank you for joining us and excited to be here and hear about your project, ThoughtFlow. We want to learn more about it and how that fits into the cloud-native ecosystem. Yeah. Then we're happy to learn and this session is recorded too. So for somebody else who wants to come in later, they can actually see it too. So yeah, go ahead. Okay, so I can share my screen. I prepared a few slides. So I would like to go through the slides and also have some discussion with all of you. First, thank you for inviting me to this session. Also, it's my pleasure to introduce what I have been doing in terms of ThoughtFlow. So today, yes, this is a project I have been working on for many years. So it's really my pleasure to introduce this to you. So ThoughtFlow, it is a... You can call it the age computing framework or for computing framework to support IOT applications on top of this cloud and age environments. So it has a special kind of capability to support applications with advanced programming model and also it is a runtime system to support such a programming model and also to optimize the deployment of IOT services.  So let's start with a little bit of background. So I have been working in the lab for this project for many, many years. So I'm from AAC Lab Europe. We are located in Heidelberg, Germany. We initiated this project nearly four to five years ago. Right now, it has been an open source project based on the prototype we built before. So we are from IOT area, which means so we collect data from sensors and do some data processing and then derive some timely results, situations, so that actuator, which is also device can react on the results. So the major thing we did is to be able to run such data processing in between the sensors and actuators. So in the old age, this type of data processing can be supported by different type of big data processing frameworks like Hadoop, for batch processing, Spark, for stream processing. Nowadays, Flink could also combine both with the unified programming model and everything works very well in a cluster environment. That was the way we do before. But nowadays, since the system architecture also changed and also there kind of for requirements in terms of for latency and also privacy and the cost in order to support large scale IOT service. So we have to adapt to this type of new requirements and also adapt to the new environment. In this environment, we call it cloud age environment that means it is highly distributed and also have this hierarchy with different resource computation resource, including resource in the clouds and some computation resource located at IOT gateways. That can be deployed on the street or in the factory. So with this kind of for highly distributed architecture, in order to deploy IOT services, we are basically facing two type of challenges. So the first one is to program kind of for such IOT services. First, then according to that, we can easily deploy them to this highly distributed infrastructure without having too much management complexity. So what we did is to improve or to overcome the complexities of from both sides. One is to have this easy to use programming model we call it internet-based programming model to program age applications. On the other hand, to have some kind of efficient framework to be able to manage the task to first translate the programming model into concrete deployments, plan and then also optimize the plan without having too much involvement from the users or system operate. So that are two type of focus we do in workflow. So there are a few principles that we try to follow in our design. By the way, if you have any questions just interrupt me so we can have some discussion. So there's few kinds of principles we try to follow in the design of workflow. So the first part is we try to decouple this kind of computation logic, how we represent the service, the design phase, and also the deployment requirements that we may face at the wrong time when we start to use the service. So that is the decoupling strategy we try to follow and there's some consideration behind this principle because for the same kind of service which may be a same pipeline, but the way to trigger this pipeline may need to be different according to how we use it. For example, if we use it for simulation kind of cloud environments, we may not care about too much about the latency. So we may want to just reduce the cost to use the resource for doing that. If we trigger such service, some pipeline for some kind of for device, then the time may be important, we like to get this result as soon as possible. So that's why we kind of separate out this computation logic to represent it as a kind of for graph which consists of multiple data processing units, each one we call the task. And then on the other hand, we have this kind of for deployment requirements, we call it intent. This basically represents how would you like to trigger such computation logic from different perspective like whether you want to trigger that for a large amount of data or small part of the data, or some kind of for service level objective you would like to achieve. So I will come to that soon as later. So this is first principle in our design and second principle we try to make the data visible. The data between tasks. So in like Spark, Hadoop, the data is basically it's not only to the specific application developer, but it's not open to everyone to share. So that means this inter-probability and also capabilities to share the task or the data processing logic is a limited because you don't know which type of input data you need for the task, which type of output data that could be produced by the task. So we try to make them kind of for standardized based on some common data model so make it visible to share. And also, around time we try to leverage this type of information for the authorization of the application or the service. I have a question. So the intent basically the way you compute the steps on a DAC or that would be, okay, so that actually means the trigger too, right? So the trigger happens at the DAC level or happens at the intent level. The trigger for the computation. Yeah, yeah, that is the trigger, including some kind of specific or customizable requirement, but this intent is a trigger. Got it. Okay. Thanks. And then, yeah. So in terms of programming model that we follow the same way as this Apache link, that's trying to unify the programming model for different cases, especially for this data incentive, intensive or I will do services data oriented application. And then internally, we try to optimize this runtime deployment is regarding to with regard to the high level service objective or constraints like optimize everything based on in order to minimize the cost or in order to minimize the latency, or even for machine learning application you may consider to cover some application level requirement in terms of accuracy. This is still ongoing and try to optimize the pipeline by taking into account this application level requirements. So, at very high level, you can see that for flow is a runtime system on the one hand provide some interface for application developer to structure their applications. And based on our intern based programming model, basically to define this computation logic as a graph, and then by taking that into account, and then with this intent as a trigger, then this a workflow runtime system try to decide how to construct the the instance of the task and then how to conflict the task and the way to deploy the task. In the end, we consider several type of for context, including the system context, we available three resource in the overall system, and then data context, because we make this data visible based on some common data model. And then we also know exactly which type of data available at which place. So this type of for metadata is also taking your account for the orchestration task. And then the usage context is what I mean by intent. It's from the users perspective how they would like to trigger the task. So we consider these three type of context to orchestrate this application over this distributed environment. I think this is somehow yeah self explained. So, as I explained before, we have a graph because service topology, which consists of multiple tasks with some data dependency. And then later, this can be triggered by a defined intent objects. And just to mention the task, actually, the task in the graph refer to operator operator is a docker application, which can take certain input and then do some data processing and then produce some output. The task is just try to annotate this operator in the context of service topology. And then come to the point about intents. This is just a data structure, but to represent covering different part of for requirement like you define which service topology will you like to trigger. And here's a kind of geoscope to fit out the data, you would like to select and put into this computation logic, and then service level objective. This represent from different perspective where the basically is your optimization objective to run the task defined from the cost perspective lentence perspective or this accuracy perspective if that is about a machine learning pipeline. This is the priority of this task for using the resource in the overall system. Yes, so then let me give you a little bit introduction about the system itself. This is a layered view of full flow system. So the top layer we have some interface or graphic user interface for the users to define service computation logic, which is the graph. And then the management layer basically is the core is the server topology master topology master make some decision based on the information come from this discovery because discovery and broker they are the core component for the data management layer. So data is will be managed by different broker at each age, and then reports, which type of data can be available at local age report this to the discovery and discovery, give this information to the master for making decision. About how should, how, how we can plan the computation tasks like basically figure out how many tasks we should prepare for each for many instance we should prepare instantiate for each task in that graph. And later then decide well to deploy. And then once decided to do well to deploy then tell the worker to decide worker is basically this to exclude the command to auto serve to to launch the task. And then the lower layer is the data source layer or some device layer, which basically produce the data to the report to the system but also consume data produced by the task, the data processing tasks in the system. So this may be more concrete than that layered view. So basically, in terms of department we have what we call a full flow cloud notes. And this is kind of centralized part, including all the core services we need for the set up for flow system, including this master for making the orchestration decision and discovery to report availability of the data in the system. And also, this cloud node can also partially be age notes, which is more powerful with more resource but normally this age note located close to the users, like, like IOT gateway. For that, so on the age node we have only two components, one broker and one worker broker basically manage the local data and worker receive the commands from the central master to decide what to do for launching the task and configure the task. And overall, there's a if I get come back here here they are kind of basically two major channels. One is for this data management channel between discovery and broker on the other hand, it's the control channel between master and worker. There. So for, for that we have, yeah, we try to separate out because combined and we may have kind of for buffering issue to propagate this commands in real time, as fast as we can. So we separate two channel to make this control channel to be more efficient and fast. In terms of data management in folk flow as mentioned before. So for each age node as a broker to kind of manage the local entity data, which represents some states or device or just represent the entire IOT device. And then the central discovery just index all this availability of the data. So, just one of the unique thing is the data we kind of follow a standardized data model in this was in the context of five well, as a European community for IOT system. So we define a standard as data model is called and just I but it covers two parts one is this and just say nine for managing the metadata part and just 10 for manage the full entity data. And those provides pops up interface. So for flow is built on top of that. In terms of the last part how we orchestrate this orchestrate the service. Yeah, so basically this graph is given by this application developer. And then after receiving a trigger which is intent, and then the system start to figure out how to generate this execution plan, which consists of for the concrete instance of each task and also this concrete configuration in terms of which input data to put into which task and produce which type of output. This execution plan is just also a graph. Then the last step is to decide how to split up in this graph into different parts so then we can deploy them to different age notes. This will be done by the workers, but to figure out how which task goes to which age note this is done by the master in full flow. There's some optimization objective in terms of how we achieve this service level objective, for example minimize some kind of cost of doing internal data transmission or provide the minimum latency between this sensors to this and actuators. So this optimization objective will be set up by this intent. Yes, then that is some key part of the right. Yeah, so you have the execution plan in that that is actually running in the cloud system. Then that later that when that gets computer and basically gets deployed or, or creating a deployment plan and the deployment plan in the cloud system and then after that's created, and it gets actually deployed in the edge environment. This is an execution plan is calculated in the cloud. Okay, then that will be split up and then deployed. So this deployment plan is actually also calculated by this optimization algorithm in the cloud and then just executed by the worker. So what we just passively receive what to do. Okay, got it. Yeah, so this is a right now this is the open source version. We know that there's a bottleneck in terms of for calculate this execution plan and also figure out how to deploy with this is down in a centralized way right now. So that's why no, also, we have some kind of distributed version to do this authorization decision in kind of for distributed manner. So that is a more advanced version that we haven't really released to this. Yeah, question would be like something like the execution plan and the program plan could be maybe run something like Kubernetes that you could auto scale right like if you need more capacity to create that execution plan you can provision better on demand right. Right, right. So that's, that's correct. Here, it's kind of one layer on top of for Kubernetes, but definitely to deploy this deployment plan, we can leverage to Kubernetes as well like try to deploy this. So right now we just integrate with stocker engine directly. But for the cloud node definitely we can benefit from Kubernetes because we don't flow doesn't have to manage this resource in terms of container so the, the orchestration of container this can be managed by Kubernetes. So, only we do this calculation how to figure out this execution plan once we figure out that we can rely on Kubernetes to, to, to carry out this deployment plan, but the optimization is still done in for flow. Yeah. Thank you. So, on another question about this slide so you have the graphical editor on the left side. Is this part of Fox flow or this is. Yes. Okay, so you can create like your dependency graph and everything using Fox flow. Right. And also we have a graphic user interface to do this. So, right now you have to manually input this data type or so in the next version which I have to introduce a kind of type management system because info flow the data model is standardized. So we, we, we know what are the types of data types we have. So we also manage that so indent and then later this annotation of your task in the graph will be easier to define by using this maintained type data type system. Thank you. Yes, so after talking all of this here's a yes more simple example, we call close child finding. And I know this is a for sure a problem maybe in us because of privacy. It was a use case. Come up with by by business unit in Japan and see is a Japanese company. The scenario is to identify a lost child in big event like Olympic in some area which has many different studios located. If the child is lost and then the parents can ask help from the staff member and the staff member can never this age computing infrastructure to find out the child quickly because many cameras and age gateway will be deployed different location. In this area, and then we constructed a sample application logic. This is a service topology, but has only one task, which is a face matching. The task just take the image of lost child provided by the parents and look at the video stream from each camera and then to match that with the image of the lost child if it's identified from the video that it just reports. And this task will be instantiated. A different location, according to where the camera is located where this age loads have been has been deployed in this area. And to trigger that we need to define an intent object to say. This service has the highest priority. We like to achieve minimal latency for doing this. And then the system will understand even occupied all the resource to do this highly urgent task. And then another question so this, this will happen in real time basically to specify the intent and then you will schedule that to start doing the face matching and then, and then look around. So all the edge notes that have cameras right to try to do that face matching. Yes, it's more less like that. But if you remember, in the previous slides, we have also a scope, which is part of the intent, we can define select a specific area, which is the scope in this intent. Then we exclude this service for that scope first. And in this case, the scope will be what just to just an area in the on the map. Got it. So the normal development process for folk to to implement the full flow service will be like this, because that's basically maybe I can skip this because here is more easy to follow. So there are three main elements in order to program for flow service. First, which is this operate. So in that specific scenario is this face matching data processing unit. This need to be programmed as a docker docker application. And then we register that register that to the system as a reusable operator. And then second step is the application developer basically to use the graphic interface to construct this graph by linking multiple tasks together. This design phase is finished and then come to the operating phase and then whenever we stand with define your intent and then issue that intent to folk flow system, then we will be able to trigger the folk flow system to deploy a survey. This deploy the service for what you have already asked in this intent object. So these are main three step to do. So for implement implementing our operator we provide different temperature for different programming language, but the core part is just to implement this function. For the developer of the operator you don't have to care about the other part only to say you have you will receive this type of for input data, and then perform your internal data processing logic. If you have some data to report back to the system, and you can use the publish and callback function to publish the result back to the system. The other two optional if this input data provided by folk flow system. It's not enough you need to query or subscribe some extra information then you can use the other two functions, otherwise it's not needed. Sorry, questions here so so this pattern can be also be used in maybe several less type of frameworks. Yes, you're definitely right so I didn't mention here because we also have a simplified programming model which is called folk function, but the folk function is a special case so for one service service topology which is very simple contains only one task, plus a default intent this default intent is just to do. Like to do this for the entire system scope, and with always minimal latency. So that is a special case but the idea behind this is like service computing, you just need to implement this function then. Function will be deployed whenever the data unit became available in the system. It's also slightly different from the traditional service funk computing because here the triggering it's only based on the availability of the data we request. In the traditional service computing, you need to have an event this event can be a HTTP request, which provide the input data, or can be some storage system so which is more kind of generic and in folk flow case. We borrowed the idea of service computing but it's a little more specific to data oriented and only trigger that when data you required became available in the system. Okay, so that is her and then the second step is to define this service topology as I mentioned before we have this graphic user interface to compose this graph. With multiple tasks together. And then we also provide this user interface to define a service in this intent, which right now cover this different perspective, this polygon is to specify a scope to trigger this computation logic defined by the surface topology. Yeah, those are main steps three steps to to work out a folk flow application service. And right now this we have a detailed tutorial provided by this link. So if you are interested you can get more information from here. Also, now we are kind of for support the community of the folk flow users. There are some kind of adoption happens in both academia and also industry. For example, there's some provider of gateway provider. And they already designed this hardware, which already have folk flow deployed on the board. Yes, so we got another full request from researchers from different university because they figure out folk flow is easy to extend for different idea, especially some optimization of this orchestration for data oriented applications in this cloud edge environment. So, overall, we are kind of promoting the folk flow in this five year community. I mentioned a very beginning so here, I have a little bit more to say about community of five well it is mainly driven by this European countries for IoT in general, including in different areas next many smart city and now also smart industry. So what we do in this community is to have this ecosystem open source ecosystem to support IoT in general, as you see in this diagram show in this community. There are so many different open source projects. They maintain developer components for different futures like for management for data management interface with devices and for security and for data processing visualization. So for flow is one open source component in this chapter in terms of data processing. We also have kind of promote business together with all the other partners in this community. In terms of research, by looking ahead so we are currently extending this orchestration to have a distributed or we call it autonomous orchestration means this orchestration not just carry out in the clouds in a centralized way but can be carried out distributed by the local age as well, but they are able to collaborate with the other system. And compare with the other existing like each computing framework or for computing framework as for flow is kind of more data oriented because it based on a standardized data model we could end your side. Because of that, it has an opportunity to support kind of data sharing platform. So here we are also exploring using support to support secure data sharing platform. Among different enterprises. For example, they can also enforce how different users can consume the data based on some kind of data usage control policy. It will be a federated setup of workflow, but we also extend this intent to cover the constraint of data usage in different scenario. In the long term we try to as kind of for cover this application level requirements, like machine learning task in terms of accuracy so we can also optimize the pipeline. With regard to this accuracy of machine learning pipeline task. Here's a summary. Yes, I did I mentioned the overall design principle for flow. And also introduce some of the key parts like this intent based programming model and orchestrating the service based on the defined intent and also some way to do this optimization according to this defined service level objective in the intent programming model. As there's a community for workflow we try to support it with our best efforts. Hopefully, we can leverage for flow to support more application in both in 5G area for future application or for AI application in this context of data sharing platform. Yeah, that's all from my side. If you have a question, we can have more discussion. Thanks. Thank you for the presentations. It's very interesting. Yeah, I have a question about the, the future in terms of deployment it. Are there any plans to have some sort of reference architecture around Kubernetes and deploy some of the workloads and I mean at the edge and also in the cloud running on top of the client. It is a in our short term plan. So right now, this integration is only based on Docker engine. One, one of our ongoing task is to replace this patch with a Kubernetes API. So, especially for the cloud node path because then we, we just rely on this Kubernetes setup, then to launch part of the deployment plan. If we'd say this part of the deployment plan is to be carried out on the cloud node on the cloud path, then this will be done automatically by using Kubernetes API. So then we don't have to worry about like reliability or restart the Docker when there's something wrong. So this will be very well supported by Kubernetes. This is the, the cloud node part, cloud part, but the age part we consider to use this lightweight Kubernetes is called K3S. We are just investigating whether that is that provide a similar API as the official Kubernetes. Awesome. Yeah. Yeah. K3S is also a CNCF project. Yeah, I have another question about the secure data sharing platform. Is this going to be a hosted service as a platform or this is going to be more of a software that people could run and basically, you know, set up their own data sharing platform maybe in a federated way. Yes, basically we're being a federated environment. For example, you know, in Europe, people talk about this, this IDSA is international data space. There's a big kind of construction about this. Also, about the, like this guide X, which is this cloud computing vision of Europe, because you know Europe is quite fragmented. So this infrastructure is also need to be federated. So in terms of this data sharing platform, we are thinking that so different company or different countries, they will be able to host their part of this data sharing platform. And then there are some kind of for process data to authenticate who can join this kind of for data sharing platform and how they can communicate with each other. So right now because there's no kind of for agreement about the common data model between different hosted system. So it just, then people decide to go to this up level. So this interoperability between different hosted platform can be based on semantic. This is a much higher level because there's no need to say what Pacific data model you need to have as known as this data is can be represented as a meaningful, meaningful way like at the F or some kind of semantic related technology. So it's a result of form, because it's hard to have a common agreement on the Pacific data model is also competition between different companies. So for flow can play just one role because the other company can also provide kind of data sharing platform as not as they can get certificate from this this conversion. So every company can can provide some kind of implementation for this data sharing platform. You know, I think one of the things I thought about was the data privacy. So they have some, yeah, some kind of regulation. So basically this organization should be able to check which type of security or the usage control you can provide when they start to check your system and give you a certificate they will check whether you can provide this type of privacy guarantee or death level so they have some kind of bring a blueprint but it's still ongoing because carry out this in practice it's actually not easy. Yeah. Cool. Anybody else has more questions ago we got Alina so I wanted to thank Ben for for the awesome presentation and a very interesting use case of all those child and happy to see that the project is considering using Kubernetes and K3S as a back end K3S has exactly the same API as Kubernetes so shouldn't be any compatibility issues. Yes, we are also very happy to really integrate with Kubernetes. Because we see that has really generating big impacts in the community especially for cloud computing. And we see, if we move for flow to a production level, then we have to integrate with Kubernetes. Yeah. So I have a, I have a question here. So what is the, I'm not very familiar with CNCF overall. So, what is the this general interest of different interest group in under this cloud-related computing foundation. So, your question was more about this, the runtime or some other interest groups. It's just for this discussion and to know this latest progress, or do you have some specific targets for each interest group to I think the, the main roles of the six who are part of the TOC sort of like an extension of the TOC. The TOC stands for Technical Oversight Committee and Lena is one of the members of the TOC. So, the TOC makes decisions about projects that want to join the foundation and then also sets a framework for these projects on maturity level, whether this project is entry level, more like sandbox or like incubation or more like there's the level, the highest level is graduated, which means it's widely adopted in the industry and has a certain number of users. So, they set up all this framework for projects and also to work with the communities and how they can grow them and how they can get more adoption.  So, this is just sick runtime, and it's mostly about workloads in the cloud, Kubernetes is in the scope and the sick too, but there are some other projects like AI type of projects or container runtimes. So, the goal is to engage in the communities. So, we have these meetings every two months, or every, sorry, every month, twice, so every two weeks. Yeah, and engage the community so they get interested in the CNC projects and start using more of these projects. Some of these projects also joined the foundation too. So, the idea is to engage also other projects where we might have gaps in the cloud native ecosystem. So, they might want to join the foundation too and then so we're happy to help see that aspect. Does that make sense? Yeah, thanks. Thanks. Thanks for the introduction. I'm quite new to this community. But yeah, to be honest, I think this is really very cool community that we see it's growing very fast and moving fast. Yeah, yeah, so we're happy to have you involved. I know you're part of Fireware, so I mean, you're part of the community, but it's open source so anybody's welcome to participate and contribute and get engaged. Okay, great. Thanks. Also, yeah, thank you for the invitation. We were really excited to report for flow here. Yeah, we're glad that you decided to present and happy to learn and hopefully you'll get more, you get more adoption and also the space actually keeps on growing. All right, so yeah, have a great rest of your day and yeah, see you next time. Okay, yeah, thank you very much. Yeah, bye bye. Thank you. Bye.


Welcome back MechanicalEI! Did you know that pipe joints are used to connect a straight pipe, tubing sections and regulate or measure fluid flow? This makes us wonder, what are pipe joints? Before we jump in, check out the previous part of this series to learn about how police are classified. Now, the selection of pipe joints depends on pipe sizes, material, fluid flow pressure, etc. A pipe joint should withstand the pressure of each pipe. There are many types of pipe joints, namely angle joint, cross joint, T joint, Y joint, etc. A special type of pipe joint is a flange joint. It is a connection of pipes where the connecting pieces have flanges by which the parts are joined. It consists of two companion flanges, bolted together and made leak-proof by means of a gasket in between the flanges. Shown here are two pipes being connected by a flange joint held in place temporarily by a press before being bolted together. Another special type of pipe joints are expansion joints which are necessary for systems that convey high temperature substances such as steam or exhaust gases or to absorb movement and vibration. A typical joint consists of bellows of metal, plastic, fabrics or an elastomer such as rubber. Bellows is made up of a series of convolutions with the shape of the convolution designed to withstand the internal pressures of the pipe but flexible enough to accept axial, lateral and angular deflections. Shown here is a pneumatic blower inlet and outlet rubber expansion joint with its bellows made out of rubber. We first saw what pipe joints are then saw what flange joints are and then went on to see what expansion joints are. In the next episode of Mechanical EI, find out what valves are. Thanks for watching!