So, good morning, everybody, and welcome to the second day of DEF CONF. Just a gentle reminder for the rest of the day, if you come into a conference room, please close the doors gently so that not to distract the speaker, and please do go and rate and comment on our website about the speeches. And so, let's start today with our first speaker, Daniel Rieck, and he'll tell us some interesting stuff. Let's welcome him. Thank you. Thanks for getting up so early. I'm relieved that I have the grayest beard in the room. Just a question, who in the room knows what this background picture is taken from? Okay. I only had one presentation where people knew the movie. That was with some DNS guy at a very sign there. It's from Darkstar, probably the best movie ever made, so yeah. All right.  Great idea to redo all my slides yesterday. So we'll see if that works. They are not all really new. I picked them from a bunch of, but I changed the whole story, so it means I probably have to talk very fast at a point because I run out of time and have some logical breaks because it really sounded great at 3 a.m. this night. So bear with me. You can leave the feedback on the website then and tell me what you think. So Greybeard thinks he's really wise.  If they haven't forked Debian over SystemD yet, I'll probably get them to fork again whenever Debian starts believing what I say, which isn't my first concern because I work at Rathead, so who cares. Let's go and take a philosophical view on what is the role of the Linux operating system. Whenever people at Rathead draw an abstract vision of our stack, right now they put Linux in infrastructure. And there's some logic to it. It has all the device drivers and stuff. It feels like infrastructure. But you can take an alternative view, and if you look at it from an application point of view, you realize the core function of Linux is not to make hardware work or provide infrastructure. The core function is to provide a user space runtime. It's the only point for running IT is to run something on it, not to run the hardware for its sole purpose. So really the core function of Linux is to provide an application runtime. The application might be infrastructure management, in which case it runs in the infrastructure, but most of what we do is actually in the user space. And most of our users are people who really care about the running applications on top. And if you take a historic view, where did we come from? Why are we doing things the way we are doing? And this is very, very long ago when this started. Early on the mainframe model was basically a completely proprietary integrated experience. The vendor controlled what software you could run. The machines usually were leased. They didn't own the hardware if you had it. And that got replaced by what then was called open systems, Unix. In the PC world, Windows wasn't server yet, and I'm going to leave NetWare out. But open systems came along, Unix came along, and there you had a vertically integrated hardware to operating system stack and a vendor controlled tool chain, but you started to see an open ecosystem on the ISV side. You could run your own software easily. You could buy software from a third party. The problem there still was a vertical integration. If you see it, it was the history of Unix. They had all these standards that didn't mean anything in reality because it didn't actually provide compatibility on a binary level. They had all the open labels, and then you were totally locked into one vendor's ecosystem whenever you decided to go with that vendor. There was some level of source code compatibility, but if you ever wonder how a behemoth like Autocon was created and why, look at what they had to deal with to make this work across all these different versions. And I know we are getting there too with Linux. It's getting hard to keep things compatible, but for very different reasons because we're moving faster, not because we have proprietary differentiation on the technology level. And then when PC hardware got good enough, and people started wanting to use PC hardware and you had multiple hardware vendors, it was the need to break up this vertical integration. And that's the role of Linux. Linux provided the neutral user space runtime across different hardware options. That's a historic role of REL in the enterprise. REL became the neutral runtime that the open ISV ecosystem could standardize on, and then you had choice on the ecosystem side, and the hardware vendor side, and you were and bought into that. And if you look at it today, where is Linux being used? Today Linux provides you an application runtime independent of whether you're running on your laptop, you're running on a bare metal server, you're running on virtualizations like VMware, or you're running on the public cloud. It's the standard for getting this level of compatibility so my binary can work in all these options. So today, and that's my proof point, today probably most Linux deployments are either on VMware or on public cloud, which proves that Linux is not just infrastructure. It proves it's an application runtime because the reason people run, the reason why VMware never came up with an operating system is because customers would not have wanted a vertically integrated infrastructure stack where the application runtime is owned by the people who own their infrastructure management. Very simple. Never even happened. And yeah, we'll get back to that philosophical side later, but so the next question is what does that mean in practical terms for how we do software management? Because this is an evolution of a time, right? We went from something very integrated to something semi-open to something open to something even more flexible because basically what happened was virtualization is we got rid of the hardware. Now along the same evolutionary track, we changed how we deal with software, how we deal with the user space. Early on, servers, they were not just pet exhibition docs, they were shared in the center of the doc show. You had multiple admins per UNIX host and they had a lot of termers, a lot of people working on it. You compiled stuff locally on the machine and then because you wanted to map that to the binary stack, you think like Stowe or you mounted binaries on NFS. It was high maintenance. The problem is it was very fragile, right? The behavior of your binary depended on the build environment on the production host and you were compiling stuff on the production host, which kind of leads to disaster if something goes wrong. So that was too fragile and it didn't scale in the PC environment. When Linux took over, there were too many machines. It wasn't efficient anymore to go into each machine and compile software and use a local. It just couldn't be done, right? Couldn't hire that many admins and the value wasn't there. Plus, the software stack started moving faster and it was just too hard to keep that stable and working. So the next thing that happened was that we got to binary reproducible packaging. We introduced RPM. That happened when it took over 94.5, perhaps. Probably was when Red Hat Linux 2.1 came to Germany, at least, that's where I was at the time. Actually, as part of the Caldera network desktop, which is kind of funny in retrospect, because it turns itself into SEO later, but anyhow. So the first Linux distributions I used actually were just bunches of tar and zip files. We had to re-model already because at the time compiling everything was just crazy. So you had tar files, but they didn't have any artifact tracking. And so RPM started to change that. With RPM, we had a clean way to describe the build, build it, package the results in a way it can be distributed easily, and then installed in a reproducible manner, managing dependencies. And then actually removed again. That was important, too. You could actually remove stuff without leaving artifacts behind, or having some file you touch when you install it, then you do fine based on the time and all the stuff we did to deal with that back in the day. There is an important thing, though, that RPM did. It's kind of unintended. I think it was unintended consequence. That it turns the whole system in a pure single instance, single version model. RPM has no viable mechanism to let you install multiple versions of the same software stack, or run multiple versions easily. An example is, so when we want multiple versions, we have to rename the RPM, right? Python 30. That's straightforward, but painful and not very flexible. But the multi-instancing is actually more interesting. We have a lot of software in our distribution that you can install as one binary, but then you want to do multiple versions, like in the web server space, some content management systems, and do weird things with R-syncing stuff into var, lib, HTML, and stuff like that, because RPM doesn't easily you install the code in multiple versions. This has been a big contention with the JBoS community since we actually had anything to do with JBoS. I used to be in product management for a long time, and we had always this fight trying to get the JBoS people to package EAP in RPMs and say, no. And we said, well, do it anyways. And then they said, but no one is using it. Do it anyways. It has to be done. It needs to be done. It's crazy to ship zip files. But at the end, if you look at it, why don't they want it? And why didn't customers use it? It's very simple. Because in the Java world, you're running multiple instances and multiple versions at the same time, always. So they actually needed multiple versions of EAP on the machine at any time, and RPM just sucks at that. And our RPM package didn't allow that. So that's an unintended consequence of what we did with RPM is that we forced everything to be a single version, single instance system. Another aspect is that it's component level packaging. So it's a late binding model. We declare all the dependencies. And they're in different level of specificity. I can't say that in English. Specificity. So sometimes you have a specific version dependency. Something that's just a very abstract package name. And when you install it, that gets combined when you install it, which is fine. It's much better than compiling in user local. But it still means that when you build something, you have one version of the stack. Then you move to test. And person security router came along. And something slightly changed in your stack. And you test that. And then you move to production. And then the expectation is that OpenSSL has another named bug, which isn't really good. So you have to apply that. And that means that in production, you're expecting that you can apply a security fix to your software while it runs. Restart your software. And it keeps running. Which means that what you're running is not what you've developed on and not what you tested. That's an important side effect of component level packaging. Past RPM, there were a couple of things that were added on. Kickstart, spader for a retic, satellite-density engine, and things like that came along. Which all were about in the scale old world where you have all these machines. You don't have a few servers anymore. You have a few big unixos. You have a lot of servers. And you need it just to centralize how you manage that. Basically, this is still the stack we use today. Yes, the F-engine was replaced by Puppet. That's just the F-engine on steroids. It has most of the same problems, if you ask me. If you don't believe me, go to James Shubin's talk later about management. And then now Ansible is a different approach with, is a different animal. But at the end, it's all the same kind of core principle. We still use Kickstart. That was probably the most long-lived thing that Ratat ever introduced. And I blame it for winning over SUSE, because they didn't have something like that. They had a much nicer installer, but the automation capabilities of Kickstart, which is awesome. You could do what you needed to do. So at the end, at large, this is still the kind of stack we use today. So what does that mean for application deployment? If we take this level up, how am I using this stack? So a core model in this is that we have a single user space shared between all applications. That's a traditional model. We have an application runtime that is defined by the lifecycle of the operating system. And it isolates basically applications on the hardware level as a trend. And that's kind of something we inherited from Windows more, because in Linux, there's no problem to run multiple applications on the same host. But in Windows, you could never really do that. So at the end, in the enterprise world, they always buy hardware for applications. And so you end up with one application per host. It has to do with resource control and managing all of that. And the whole thing is very much about long-term, binary stability, moving the hardware cycles, updating, enabling hardware. It has some issues. It has limited flexibility. The lifecycle management on the component level gets fragile. And I forgot to put a slide in here. I wanted to put in the Fedora dependency chart, which blows your mind, because you see that everything is dependent. Because we have to make every option work. And we have to make sure that when we install something, all functions work at the same time. It's basically impossible to get fricking cups out of your server install, which is annoying if you don't want to print on your server, which most servers never want to do. It's really hard to manage the side effects of all this. You add a new version of something over here.  And it basically ties the user space. The current model ties the user space monolithically to the hardware lifecycle. It's not so much on the Fedora side. On the REL side, definitely. Our lifecycle is driven when the kernel needs to be updated, because we can't enable hardware anymore. And that's when we do major changes in the user space stack. So it's tied together. That's definitely a downside, because it's not necessarily how you want to drive your user space. Like if you consider Linux infrastructure, it totally makes sense. But if you consider the user space runtime, then this has some downsides. The next thing that came along are VMs. And I'm just throwing VMs in there. And I'm throwing cloud and VMs together. It's all the same thing from my point of view. Because essentially, it just works around to the hardware tie-in that I just described. All it does is it lets you virtualize your hardware so you can basically run your operating system application-centric. So when you now update your hardware, you update the hyperhazard layer. Whether that is an open source stack running REL or RAF or open stack, or whether that's a proprietary stack is secondary from the application point of view, because you don't even care, because the Linux OS you're using inside the VM abstracts you from all of that. So from an application-centric view, it's all the same. It gives you higher flexibility. It lets you get independent of the hardware life cycle underneath whatever you're running, and you can focus on the application. It lets you also have application-specific stacks. In my VM, I install what I need for the VM I'm running. I don't have to install things for other applications that might be needed. So I can optimize things a bit more. I can have different versions. I can have the same hardware set up. I can run REL 5, REL 6, REL 7. I don't care anymore. I don't get into this either or. But it does the rid of the hardware tie-in. The problem is that it's too much overapplication. And the management is too complex, because it's a black box. It's essentially a new piece of hardware, just a shared hardware. But you can't introspect from easily into it. There's a nice example. We are really bad at that. VMware is much better at this kind of stuff.  Backing up nowadays, it's just taking a snapshot and managing the artifacts that are in there. So you tell VMware, then VMware has an agent inside the guest that tells the VSS service in Windows, hey, I want to backup this machine.  And it flushes the buffers. And it collects the file system and stops everything, takes a snapshot. VMware then takes a snapshot. And then VSS tells everything to start again. It's great. It works great. A, we can't do that because we don't have this level of integration. B, it's a lot of moving parts that have to work together. And the only alternative is to put a backup agent in each VM, which basically undermines the whole reason why I put a VM in first. Because that means that now I have A to share the ownership between the application owner and the ops people. And B, I have to put an agent into the VM that has to be compatible with the user space runtime in the VM. So I'm recreating shared dependencies as soon as I try to actually operate this. So the lifecycle management is still too hard. Another important thing, in theory, it's all cattle. But in reality, and that's one of the reasons why private cloud isn't going where we want it to go, every VM you see in reality is still a pet. So what people do, they might deploy as a virtual image. They might deploy a virtual appliance when they update it. They log in and run YAM update at this point. So it's really just getting rid of the hardware dependency itself. So another philosophical view. So at this point, we got rid of Unix and vertical integration. We have a nice open ecosystem running on Linux. You have choice on the hardware side. Linux even manages quite well to give you at least source code level compatibility across different hardware architectures, which it works fairly well. It's nice. My home automation is all based on Raspberry Pis. And most of the same stuff works there. It's a different distribution at this point, although I'm working on getting Raspberry Pi 2 with Fedora. So even that will be the same experience. So that's really nice. And we got rid of the hardware dependency through virtualization for the enterprise production. And we have a certain level of automation and efficiency. Now there's some other trends in the market that change behaviors right now. And we are in a paradigm shift that goes very deep because it's driving control outside of the traditional software and IT space.  But the biggest trend is that everything is software. Software is eating the world. Traditional business used to be about something physical. That was what mattered. And software was the thing, the IT people in the basement. Who watches the IT crowd? Very good. It's the IT people in the basement that do the software, and you don't have to deal with that. That's changing. Every business now is defined by software. Software is strategic for everything. There are more developers in the business side than in the traditional IT side or traditional software industry. If you look at car manufacturing today, the hard part about car manufacturing is more and more getting the software right than to actually build a car, because everyone knows how to build a car. That's not much changes. And the engines get more efficient, but you have choice there. And Tesla just proved that you can, from scratch, just create industry-leading car business without. But started by a guy who was a software guy, right? And he just had enough money to get that going and decided, let's build this car and get higher some people who know how to do that and let's do it. If you look at the issues that cars recently had, let's say the Volkswagen compliance issue with the environmental limit, how they cheated, there was software. How did they fix it? They changed the software. If cars get stopped on the highway because someone hacked the Bluetooth thing, or a couple of years ago, they hacked, I think, a Dodge or a Chrysler thing by playing an infected song through the MP3 player. It's all software. So software is eating the world. Really, literally means not only that a software is in each device, everything is software. It means that every business is doing software. And that changes how the dynamic in the software industry because it means that business differentiation for a company, not only for software companies. And we know that for us, business differentiation is driven by all software. But now for a car manufacturer, a good part of the business differentiation is driven by their software. And it's an important change. It changes power in companies. It changes who gets to decide what technology to use, what software to use. Right now, in training, you had IT experts decide what stack to use. And they could standardize a stack for the company and say, OK, this is what we're going to use. Nowadays, that's decided by marketing executives in the line of business for a car manufacturer. They set the requirements. They set the pressure. And then that fuels a lot of the other changes we see. Move to cloud. That's partly in CapEx versus OPEX model and flexibility thing, but it's partly also because the requirements change so fast that buying hardware just doesn't, it just takes long to buy hardware. So I have to go to public cloud. I need to use elasticity because, otherwise, I can't keep up with the business demands. That's why I always need the current version of code. I'm not going to wait for a release cycle of RHEL. The line of business is telling me I need this new UI integrated with this new feature and supports this new protocol on that cloud. And it shifts from a broadcast model to an on-demand model. Everything is on demand in the current world. I have to speak faster now because I'm running out of time. I want you about that. So this leads us to a two-faced world. On one hand, we have an ops-centric environment, which is traditional IT that's not going away. People are still operating ops. It might be outsourced. In that case, you don't run it yourself. But someone is operating. It all runs on hardware. It all runs on infrastructure. That's a world where the Linux distribution is at home. We are trying to provide stability. We provide, at the end, what Red Hat provides is an insurance policy for people who need to download and install and update binary components in place. We make sure you can do that. And our community is doing basically do that without a commercial assurance. What we do is we give you a pre-packaged software stack so you don't have to compile anything yourself. You don't have to find out how it put it together. You don't have to find out which versions work together, which versions work with your hardware. And it's amazing what we do there. It's really great. And it really works. I can install. I can update my Fedora laptop, which is really a Fedora laptop, even if it doesn't look like one. I can update that across Fedora releases now with not much problem other than the freaking proprietary wireless driver I need from fresh RPMs. And it just works. I don't have major issues, even at least nothing that would block me from going to the newest Fedora version whenever it comes out. There's another site now, which is the app development site that's growing and growing and growing. That's the business drives, the industry now. And there you are in an area where you download to build. These people do not install binaries. They compile software. They're like us. They compile software and then test it and then deploy it. So that's a download to build user case. And that's very important because right now everything we do, the whole structure of the Fedora ecosystem is optimized to install and update in place model. And it's not optimized for the download to build model. And I'll explain a bit more about that. There's another aspect. It's just a sheer complexity. This is from module counts.org. So I found it on the internet, so it must be true. Count of modules across higher level languages is the most popular repositories. So I don't know why it says Debian unstable down there. So the bottom line is the count of packages in Fedora raw height. Fedubuff is Debian unstable. And then .NET has double the number of components right now. And then it goes up. There's 600,000 individual modules. And there might all be forks of each other. And 90% of them never used. But the message is we cannot package all of that in a Linux distribution. It's just not possible. Just too much stuff. And that's the stuff that these download to build people are pulling from. They're downloading .NET, Maven Central, or Ruby Jam stuff. And they have the choice of 200,000 Node.js packages. And that's putting a Linux distribution. It's a big challenge for a traditional Linux distribution. It's just too complex. And there is no critical mass in this user space. And we're just too slow to give them new versions. Even Fedora is too slow to give them new versions, even of the packages we have. That's why they go directly to upstream. And I only have 10 minutes left, so I'll just skip every other word now. So you get the abridged version. And the solution to that is a containerized stack. In the containerized stack, you separate each runtime. And so you separate the system runtime from the application runtime. And each application gets its own runtime. The host is deployed as an immutable image. Ideally, you don't have to do that, but it really helps. And then each service gets its own container, although you can have multi-service containers. That turns Linux immediately back into a multi-instance, multi-version environment, because you can simply run whatever you want in each container. And they don't affect each other. You completely get rid of interdependencies. The dependency chart basically gets reduced to my container's dependency chart. And the next container can do something else. It gives you maximal flexibility. Also, let me delegate at the container level, because in VMs, one of the problems is that it's still the full operating system, including the system runtime, including the hardware piece, the networking stack. I don't have that in a container. So I can easily give the application, people, control over the container, still control it from the outside. And they don't get to break out of that. And I can still introspect it. I don't need to do these things I described about backups in VMware, because it's not a black box. A host or even a privileged container can inspect into other containers. I can just see it. We'll publish the slides, so don't worry about that. So in the use case for containers, there are basically three levels of use case. And the first one will make some heads explode, and I think I'll get a call afterwards from Brent Baudi, who just did a blog telling me not to do this. But it's a pet container. And this is the first thing you should try if you're doing containers. I do that on my laptop all the times. I just instantiate a Docker base image, or the REL tools image, or Fedora image. And then I basically treat that like a VM. That's perfect if you want to try something out. You want to install random NPM stuff.  So I need a PXE server. And I don't have a machine. I don't want to install all of that on my host because I have to find all the pieces. Even in, you know, it's gotten much better with DNF, but still it's, you know, it's just easier to put it in a container. I do whatever I want.  If I don't need it anymore, I just remove the container, it's done, right? So I'm basically partitioning my laptop already into multiple runtimes this way. Just for convenience to try out things and do things without having to deal with it in polluting my core system. And it's going to get more and more. There are things I can just deploy. You know, I wanted to try out MetaMOS and GitLab. They give you a Docker container with the integrated solution. So it's just run it and you got it, right? Don't deal with anything else. If it's a trusted source, of course, you know, if you do that from the wrong source and you just introduce the botnet in your environment. But no, seriously, it's a valid use case to run a pet container. And if you're moving from an existing application, you know, a lot of people say containers are mode two and then we have this mode one application. It's a continuum and you can make basically every mode one application work in a container. The next thing is multi-service containers. This is another thing that makes some hats explode, right? Because containers are micro services. Not true. Then watch it a lot of work to get system deworking in containers. So just if you need an existing application, a container, just, you know, make CMD has been in it and then you have system de-running in your container, you might, depending which version of Docker you're using, you might need to give it some privilege in newest version, you don't need to do that. And then you can just install your software like you're used to and it just works, right? It just starts the unit files and it just works. And you just need to do the mappings on the outside which is not hard as in dealing with firewalls or anything else. And then you go to multi-contain application is really where you need to start dealing with Kubernetes because that lets you orchestrate them. The real container is applications that looks like this, right? It's everything is a cluster. We are always in a scale-out world. The host is immutable and you in applications basically in an orchestrated set of containers. I have Kubernetes as my cluster manager and the definition of my application is this set of containers and then it starts them. And it's always multi-tenant and multi-source. Taking a step back to the philosophical view, if we compare that to one of my first slides where I talked about the role of RPM when we came from user local compile into something that scales. Docker slash OCI, the container format we are standardizing on basically has the same function that RPM had in this transition. We are at a point where because of the complexity of the stacks, installing things in production on the component level, resolving component level dependencies is so complex and fragile. It's almost equivalent to the problem we had 15, 20 years ago, I'm not really that old. 15, 20 years ago with user local compiles. Because especially one, the next thing we have to do is weak dependencies because we have to get rid of that cups server in our server installed. So we need weak dependencies. Once you have weak dependencies, the installed stack, the late binding stack that gets bound when you install it, not when you build it, is gonna be so dependent on parameters, not known when you build it, that it's gonna be too complex to deal. When you're outside of the RPM space, that's already the case. It's too complex to deal with. So the only way to deal with that is by doing aggregate packaging. Early on when you build it, when you're in the download to build mode, when you're application developer and enterprise, you build the artifact and then you move the same artifacts to build test production, automate that process, and you use the aggregate packager as to manage the installed artifacts. So we go to an early binding model. Interestingly, there's a precedent for this. Years ago, I was in the field organization in Europe for Red Hat. And a big thing for us back then was to install Oracle for customers in like rack clusters. And you never wanted to run the Oracle Java installer on a production system, because it was kind of, it was very fragile, it would not always work, it would be dependent, it wouldn't take care of dependency because it wasn't an RPM, right? So what we did is actually did it on one machine, then build a binary RPM of the resulting installation, distributed that through satellite. So maybe we moved to aggregate packaging to deal with the fragility of this Java-driven installer and fragile software stacks that didn't do the dependency management. So this is basically what Docker does very conveniently. It does a package stack, it's the next logical set. It doesn't invalidate RPM because it's a level above it, right? But it moves the consumption of the RPM dependency resolution in a pre-stage for the application developer. Not for the system people or maybe, but that's a different discussion. And then you use that to distribute that. And it makes you, it allows you in a clean way to add other packaging artifacts on top of that. One thing that Docker doesn't do, it only gives you container-level packaging. There's another thing I'd like to take a look at, which is the Atomic app or the upstream project called NulliQL. And I think we have some talks about that. So this is basically the next step where you go from packaging individual containers, I described an application as always consisting out of multiple containers and being orchestrated through Kubernetes. Neither Kubernetes nor Docker give you a transport format for this higher level construct. It's basically when you wanna, today I can do a YAM install IPA, free IPA, and then a IPA server install and I end up with a ready-to-run orchestrated parameterized instance of IPA. When I want to do that in containers, I'm back to copying templates around and, so VIM becomes my IPA server install, which is really great because it's a functional regression. That's what Atomic app solves. It gives you a way to package the aggregate metadata and define a way how to parameterize that on deployment. That all, like putting this all together, so this is kind of the enterprise stack. It's a bit of a jump, but I want you about that, that there will be some conceptual jumps in my presentation. If you put this all together, we basically operate on three layers. It's the infrastructure, the application, runtime, and lifecycle management application content. Mapping that to what we do. We have a bunch of different cloud options. We have Atomic Enterprise as the runtime, OpenShift as the lifecycle management and our frameworks on top. That's a logical view and I'm out of time, so I'll just skip to the last slide to close the cycle, it's only a slide logical. If we look at what's happening in public cloud right now, we're seeing actually a move back to vertically integrated Unix stacks. Every cloud vendor and every private, proprietary private cloud offering is trying to do vertical integration up to the pass level. If you're going to Amazon, they're trying to get you to use all their services. And they tell you, hey, don't worry, it's just database. Don't worry which one it is. Our role in this model is the same role we had when we broke the vertically integrated Unix stack. We are breaking the vertically integrated cloud stack and we're giving people alternatives and the ability to define the applications independent of the vertically integrated stacks, gives them an open ecosystem to choose from and then run that application without the application actually knowing the specific of the underlying stack across all these options. That's the vision where we're going with the operating system here. That's it. Thank you. And that's a logo I'm proposing. And I'll be around for questions and apologies for going over.


So yes, I'm presenting the gaps in the cascade of care in two high prevalence setting in Zimbabwe and Malawi. So HIV population-based survey enabled to measure HIV outcomes at community level to define and prioritize intervention in HIV program. MSF started the implementation of HIV activities in two settings of GUTU in Zimbabwe and N-Sanjain in 2011 using the monitoring approach by decentralizing the ART diagnosis and treatment from hospital to clinic. MSF took the operational decision of implementing this population-based survey in these two settings to give information on HIV outcome to estimate the impact of the monitoring approach after five years of implementation and to define plans and interventions. Also last year, national surveys were implementing in Zimbabwe and Malawi at national level, which gave us the opportunity to compare the findings of our surveys with the outcomes of the national survey. So briefly to show you where the two settings are located. So N-Sanjain is at the bottom of Malawi surrounded by Mozambique and GUTU at the middle of Zimbabwe. In terms of study objectives, so I'm presenting here the objective for the one we have the result in this presentation, but we had also other objectives. So the primary objective was to estimate the population viral load among the adult more or equal than 15 years old. We took as a definition of viral load suppression, all viral load the result, less than 1,000 copies per milliliter. As a secondary objective, it was to estimate the cascade of care among HIV positive more or equal than 15 years old, to estimate HIV prevalence among the more or equal than 15 years old and to estimate the ART coverage among HIV positive more or equal than 15 years old. So cross-sectional population survey we're implementing in GUTU and N-Sanjain district between September and December 2016 using a multi-stage cluster sampling. We recruited all individual age equal or more than 15 years old and eligible children less than five years old in GUTU district and N-Sanjain district living at the time of the survey. But here I will only present the result for the adult. In term of study procedures, so the team went to the household randomly selected and asked the concern of the head of the household for interview and they performed the household questionnaire. Through the household questionnaire, they could identify all eligible individuals and after receiving the consent, they performed the adult questionnaire. Then they had a pre-concelling session before having HIV test on spot. Then according to the result of the HIV test, for positive and discordant, they received a post-concelling session, then a questionnaire on HIV and ART. We also draw blood for additional testing for those participants to conduct viral load, genotyping, ART blood level, incidence. We also conducted CD4 in GUTU and for 10% of the participants that were positive, we conducted HIV confectionary test for quality control. So in term of participation and inclusion rate, so in GUTU, 2,400 households were completed and 5,440 individuals eligible and we had good inclusion rate with overall 89% of individuals included and tested. In NSANJ, we completed 2,440 households, 5,222 individuals were eligible and overall also good inclusion rate with 87.8% of individuals included and tested. In terms of socio-demographic characteristics, so in both settings, most of half of the participants were women, most of half participants were married, farmers, and living continuously in the district. The median age of the participants was 36 years in GUTU and 33 years in NSANJ. In terms of HIV prevalence, so for the MSF survey overall in GUTU, we had 13.6% of prevalence and 12.1% in NSANJ. We can see in both settings that prevalence among women was higher than prevalence among men. Also stratified by gender and age group, we can see that in both settings that the HIV prevalence curve is increasing most slowly for men than women. And for both settings also, we got a low prevalence among young adults. So now I'm going to show you the results in the comparison of the 1990 coverage between the surveys in GUTU and the national survey. And to do so, we restricted our result to the age of 15 to 64 years to match with the age group of the national survey. So as you know, UNS has recently set up the target of 1990. So the objective is that by 2020, 90% of people living with HIV will be diagnosed. So is what is representing in the first part of the diagram with the first 90 diagnosed. By 2020, 90% of diagnosed people will be enrolled on ART. So that we represented on the second part of the graph. And then by 2020, 90% of people in treatment will have fully suppressed viral load and what we're representing in the graph. MSF is in red and is not appearing here, but the national survey is in blue. So we can see that overall, we have a good result in the 1990 coverage. And we can see that there is a difference between good two-settings and the national level for the two first 90 coverage. And we didn't see a difference for the third one. Among women, again, we can see good results in good two-settings, also in national settings, but we can see also a difference between MSF survey and the national survey in the two first 90s, but no difference in the third 90. Among men, again, good results with a difference in the first 90, even though among men we can see that the diagnosed coverage was lower than women. We could identify the gaps in good two to show that young adult 15 to 24 years old were 71% to be diagnosed, and young men less than 30 years old were 58% to be diagnosed. So now will be the result of N-SANJ, again, same to show the comparison between N-SANJ sitting and the national survey in Malawi. So we can see overall that the results are good. For both survey, but we could not see a difference between the MSF survey and the national survey. It was exactly the same for women. No really difference for the first 90, second 90, and third 90. And for men, we see a difference compared to women with lower coverage among men, but no difference in terms of diagnosis on the RTI or viral suppression between the two survey in good two and the national survey. Here again, we identify the gaps among the adult diagnosed. So with 64.3% of young adult diagnosed and 42.3% of men less than 30 years old. So what we can say about this finding, so we could see that there is an edging HIV positive population and about 25% of all HIV positive were above the 50-year-old. We had very good results in the 1990 coverage outcomes in both setting, but we could highlight a gender and age group imbalance, specifically in the first 90 of diagnosed. There is specifically in good two, difference, significant difference between the good two survey and the national survey. And we could see, we can estimate that there was an impact of good two project in this setting. We use the same method as the national survey, so we are confident that the difference is real. We could see that in N. Sanjay, there was no difference in the 1990 coverage and in both setting that the third 90 was also similar between the MSF survey and the national survey. So based on these results is to see how to move forward in this program and to choose on a strategic operation in these settings. In terms of limitation, we have still very low test results in good two and third. And also during, on the questionnaire, the IRT was self-reported. Although the team when they came to the household, they asked to see, for people who reported to be an IRT, to see the health plan. In terms of strengths, it is a cross-sectional survey that allowed the representability of the population living in both settings. We had a high participation rate even among men and we could compare our results between our results of the survey with the national survey. So I wanted to thank all the study participants, the community also of both settings. All the team worked very hard on this survey and MSF for Zimbabwe and Malawi and all other partners. Thank you. Thank you very much, Nolwen. We have time for a few questions. Looking around the room, so we have one, two, three, four. Let's start with that end of the room and we will take the question and then the answer at the same time. Yes, go ahead. Hi. Can you hear me? Yeah, Nathan, WHO. So the second 90 measures the number of people on treatment and the third is the number on treatment who have a viral load suppressed. What that doesn't capture is mortality and loss to follow-up. So I think if you're asking the question what's the added value of MSF's program, it would be important to also compare those critical outcomes. Or am I wrong? Does the virological suppression include death and loss to follow-up? No. No, OK. Thank you. But oh, sorry, so the question was, do you have an idea? Do you have an idea of mortality to follow-up in the program? OK. Do I have words, all right? Do you have a sense of mortality and loss to follow-up in the MSF programs? I think so I don't, I... I'm sorry, I can actually answer to this question. I think you're towards the field team. Coffee break discussion, thank you. Next one. There's a question up here. Yes, please. Hi, I'm Bev Stringer, I work with MSF. Thanks for an interesting presentation. I see that you work closely with the ministries of health in both locations. Have you discussed with them your results, especially linked to your male participants and what further information you might gather with regards to that? So for this question I'm going to answer on behalf of the team because I'm not working in the... I think there was a presentation in both settings, yeah. Thank you. But again, I'm not part of the operational team so maybe people can answer to that better than me. But I think there was because it was the plan so I think it was presented recently. Thanks. Right at the back of the room, yes. Yes, thank you. Sorry if I missed it at the beginning, but what was the actual rationale for doing the survey? Like, was there any reason to mistrust the national survey data or...? No, no, no. Sorry. Because also then, like, your results were quite similar to the ones that were then becoming clear from the national survey and yes, the question remains, what is the implication for the MSF team? So, sorry if I missed that one. No, as mentioned, maybe I was not clear at the beginning. As mentioned, MSF is working in these two settings for five years now and it was also to evaluate the program. So, to see what's the impact of the program compared to the national level. So, is it a reason... How to orientate the program? Is it a reason to stay? Is it a reason to orientate, for instance, we could see gap among male or young persons. So, how to orientate the program in the... It was not at all to mistrust the national survey and actually could see as we could show in this presentation. For instance, in GUTU, we can see a difference between the setting in GUTU and the national and the country. So, we can estimate that there is a real impact of this program of MSF in this area.


20 Common Acronyms in English from EspressoEnglish.net An acronym is a word formed by the initial letters of two or more words. For example, UN is an acronym for United Nations. Some people are even known by acronyms, such as JFK for former U.S. President John F. Kennedy, or CFO for a company's chief financial officer. We usually pronounce acronyms by saying each of their letters separately. Do you know these common acronyms in English? Aka means also known as, for example, Stephanie Joanne Angelina Germanata, a.k.a. Lady Gaga, is one of the biggest pop stars of the 21st century. B-L-T means bacon, lettuce, and tomato. This refers to a type of sandwich. For example, do you want to tune a sandwich or a B-L-T? B-Y-O-B means bring your own booze. Booze is a slang word for alcohol, so this means you should bring your own alcohol to a party or a social event. For example, the party starts at 8, B-Y-O-B. C-E-O stands for Chief Executive Officer, the president of a company or organization. For example, the CEO of that company makes a million dollars a year. D-I-Y stands for Do It Yourself. For example, Pam would rather buy something ready-made than do a D-I-Y project. E-R stands for Emergency Room of a Hospital. For example, after the car accident the victims were rushed to the E-R. E-T-A stands for Estimated Time of Arrival. For example, what's the E-T-A on the shipment of the new equipment? F-Y-I means for your information. For example, F-Y-I, the bank is closed tomorrow because it's a holiday, so you might want to make your deposit today. G-D-P stands for Gross Domestic Product. That's the value of all the products and services produced by a country in a year. It is a measure of the size of the country's economy. For example, China currently has the world's second largest GDP. H-Q stands for Headquarters. That's a center of operations or administration. For example, the company has offices throughout the country, but its H-Q is located in the capital. H-R stands for Human Resources. That's the department of a company that is concerned with employee relations, hiring, dismissal, etc. For example, my coworker was sexually harassing me and I had to complain to H-R. M-I-A stands for Missing in Action, used for members of the military who disappear during combat or a mission and whose status is unknown. For example, five soldiers are M-I-A after a surprise attack destroyed the military base. P-R stands for Public Relations. That's the practice of distributing information to the public and the media. For example, the nonprofit organization hired a specialist to take care of P-R. R-I-P. That's from a Latin phrase which means rest in peace. We use it for someone who has died. R-N stands for Registered Nurse. For example, after her kids graduated and left home, Joanne went back to school to pursue her dream of becoming an R-N. T-B-A means to be announced. For example, the conference will be held October 15th through 19th, location T-B-A. T-G-I-F means thank God it's Friday. For example, I've worked until 9 p.m. every day this week, T-G-I-F. U-F-O stands for Unidentified Flying Object. It is often used to refer to possible alien spaceships. V-I-P stands for Very Important Person. For example, tickets to the V-I-P section of the nightclub cost three times as much. To continue improving your English vocabulary, take the Vocabulary Builder course at espressoenglish.net. It will help you express yourself more fluently in English by teaching you hundreds and hundreds of common words. Visit espressoenglish.net to take a free sample lesson and sign up for the Vocabulary Builder course.


In section 7-8, top seeded Deer River and Sherry. Third set, match even at one apiece. Katie Peterson going for the kill, but hope Schenken is there for the stuff. Then moments later, Schenken's shot gets returned. But second time's the charm. She puts it away to extend the lead. And how about another black on defense? This time it's Devaney Tibbetts, get out of her house. This one goes the distance, but the Warriors fall in five. That'll end their season. If you've enjoyed this segment of Lakeland News, please consider making a tax-deductible contribution to Lakeland Public Television.


British Prime Minister Boris Johnson has paid a visit to the G7 foreign minister's meeting after it was hit by COVID-19 scare when India's foreign minister and his entire team said they were self-isolating after two delegation members tested positive. Britain is hosting the three-day meeting, the first such G7 event in two years, which has been heavily built as a chance to restart face-to-face diplomacy and an opportunity for the West to show a united front against threats from China and Russia. India, currently undergoing the world's worst surge in COVID-19 cases, is attending the G7 as a guest and had been due to take part in the meetings on Tuesday evening and throughout Wednesday. The meeting is a precursor to the main G7 summit due to take place at a rural English resort in June with US President Joe Biden and other world leaders set to attend.


There's an epidemic of a very specific and certain kind of disorder in today's world. And in my mind, it's the epidemic of both nervous system disorders and psycho-emotional or psycho-spiritual illness, whatever term you want to use. But in this video, I thought I would share a key that I found for many of my patients that has helped them. Hey guys, I'm Dr. Alex Hein, author of the health book Master of the Day and doctor of acupuncture and traditional Chinese medicine. So before we jump into this video, there are two very important links right below the video. The first is for a free guide I've put together, which is four daily rituals that can potentially help you add years to your life with traditional Chinese medicine. And the second is if you'd like to become a patient of my locally in Los Angeles or virtually via telemedicine, you can reach out to my private practice right below in the description there. Recently, I was traveling in Morocco and I had an experience that really made me think.  And as she was passing by a little intersection, a giant dog jumped out of the alleyway and barked at her. Now she completely freaked out and she clutched her chest like this. Now I didn't think anything of it, but later that night we were walking on our way to dinner and this time I saw a different older woman who was looking at her grandchild for the first time that she was meeting in a restaurant that her, I guess it was a family sort of meet and greet.  And what did she do? She did the same thing. I got always like a cute little heartwarming sort of gesture. And it made me think about a key healing lesson in traditional Chinese medicine. The heart is almost the holographic center of the nervous system. And whether we are experiencing heart shock, like fear, the dog, or whether we are experiencing something that is heartwarming, like love, like this grandmother seeing her new grandchild, the heartwarming so cute sensation, human beings throughout the world and throughout history, we develop the same sort of gestures for specific archetypal purposes. And the heart is one of those mirrors of the nervous system. Now encoded in this story is both a profound lesson about Chinese medicine, but also about healing and wellness in general. You know, we say that in traditional Chinese medicine, our ancient texts say that the heart is like the emperor. And all of these other organs in the body almost are responding to the heart, right? And if all of these organs are having issues, it's almost like there's a rebellion in the kingdom and people are trying to overthrow the emperor. But the heart is the seed of the big spirit, right? The spirit is in the consciousness of the person. The consciousness is in someone who is healthy and has bright eyes and has vitality. And clearly you can see in them wellness. You can see vitality, not something measurable in labs or blood work or imaging, but vitality anyone can recognize that is immediately perceptible. When there is a disturbance in the heart in traditional Chinese medicine, this is one of those reasons people have issues with anxiety or depression. Now, heart is not just in a holographic sense, it is an emotional thing. In a clinical sense, we utilize formulas that we say treat the heart if people are experiencing clinical depression or clinical anxiety. And one thing I'm interested in is how often my patients who have issues with our nervous system or with HPA access dysregulation will experience physical issues with the heart, like having an elevated heart rate. So many people that I see that are primarily experiencing a lot of stress see the symptoms in their in their chest, tight chest, elevated heart rate, dysrhythmias like heart palpitations, they're having obviously insomnia, anxiety, depression. But how often stress and this dysregulation, this disconnection in day to day life, how often it does manifest physically, even in the chest on its own. Now I love this idea of somatic healing or somatic sensing. In other words, one of the most illuminating exercises I had ever done in my own healing journey was learning to pay attention to where I felt certain stressors were in my body. So if I drink a cup of coffee, and today was not the day where I should have had a cup of coffee, where do I notice it? I close my eyes and I notice my hands feel a little sweaty. That wasn't like that before, or I'm noticing my heart, I feel boom, boom, boom. I can feel my heart and I couldn't feel my heart an hour ago, or I'm noticing a little bit of indigestion, and I was feeling fine prior. Just this concept of somatic sensing, learning to recognize where you feel certain parts of your body is really key to having a built in sort of biofeedback mechanism, where going forward, if I'm working on my healing and my healing journey, recognizing, okay, what gives me that feeling of this is heartwarming or I feel peace? So as I go up on my day-to-day life, that keep baby, oh, that elevated emotion, that energy, where do I feel that sense in my day-to-day life? And where do I feel the opposite, right? I'm driving, I'm driving in traffic, I feel tight chest. That is not the feeling that I want. Or I'm having a cup of coffee, I feel anxious chest, or I have a healthy meal, I feel calm, I feel grounded. I work one job, I feel constant tension and pressure in my chest, I work another job on the weekend, I feel positive, I feel relaxed, I don't feel that pressure in my chest. The heart is the mirror of the nervous system in many different ways, and is the mirror of really the psyche in so many ways as well. And certainly within traditional Chinese medicine, there's a reason for that, because the heart is really the center of the big spirit, consciousness of the person. And for so many of my patients, when I'm helping them retrain to recognize how they feel, the number one thing I have to pay attention to is, if the heart is where you feel tension and stress, go about your daily life and see how varying things affect that physical location, and try to find more things that give you that sense of peace and that calmness. So for many of us, regulating the nervous system is about learning to regulate the heart. And that is a retraining journey of going about your daily life and noticing what makes your physical body actually feel the best, because very often it's affecting the nervous system. So the heart has a holographic mirror of the nervous system, very useful in something you see every single day. Alright guys, so don't forget to check out those links right below this video, and I'll see you soon.


B-R-R-B-R-I-T-T-A-N-Y B-R-R-I-T-T-A-N-Y That's my name. Come. Prophecy! I hear NYEAH!  Why are you laughing? Because that's my husband's name. Prophecy! Come on, somebody! Shall prophesy! Shall prophesy somebody! Is this your husband? Yes. Your child shall be Ricky Jr. Amen. Ricky Jr. Prophecy. Because I moved in the realms of the Spirit. This connection was written from heaven before you were born. Where's the Lord? Go deeper! Because I stood in 1917. I am no longer here. I am in Sweden. That's where I'm from. That's where I'm from. That's where you are from. Yes, sir. And I saw a man in the realms of the Spirit. Prophecy. And in the realms of the Spirit I saw heaven opening in 1964. That's the year. And I saw a man in 1964. Looked in the realms of the Spirit and on the bed, I saw people trying to name the child. But at the end I saw them writing a name with an L, E, O. That's the name of my father. He was born in 1964, Leo. Prophecy! I am in 1964. Go deeper. Leo, Leo, Leo. That's my father. I moved in the realms of the Spirit. I saw him in the realms of the Spirit. Prophecy. Prophecy. Prophecy. I saw him in the realms of the Spirit. Go deeper. I saw him wearing a blue jean. I know this one, you don't know it, but you understand something. I am in the 80s. I'm in the year I was born in 87. I saw him visiting a city. Like Bora, Bora something. That's the seat I come from, Boros. Boros. Oh my God. Oh my God. Go deeper. In 1987, I saw him walking and I saw Rabasante car. Go deeper. It's like a shopping mall. It's like they are in a shop. There is a lady that dropped something and I saw him picking it up. When he's picking, I saw him looking at this lady face to face. I see him smiling. I see him pursuing over this lady. I am seeing a G and a U and an N. Yes, sir. That's the name of my mom, 1987. The year before I was born. I saw them meeting in the mall. I saw them dating each other. Yes, sir. Go deeper. I saw her pregnant. I don't know why I don't see a wedding yet but I'm seeing a pregnant. It's true. I was born outside of the marriage. It's because your birth was already let. You were destined for greatness. Amen. Amen. And your journey started in 1917 in Sweden. Amen. Go deeper. The prophetic word was released. That they shall be a man of God within the family. Amen. Go deeper. Go deeper man of God. Go deeper man of God. I moved in the realms of the spirit. I saw a man in 1917. I see H-A-R-T. That's my surname. Hartikainen. Hartikainen. 1917. I moved in the realms of the spirit. And I saw him receiving a prophetic word. And the Lord is saying you are the one who is a light. Who is a connection to the manifestation of this prophetic word. Amen. Amen. I received man of God. I saw in the realms of the spirit heaven opening. And I saw you in the realms of the spirit. I don't know why in the realms of the spirit, why there is a blessing coming to you in the month of May. I am seeing a special blessing coming to you in the month of May. Amen. I received. I received too. I'm born on May 1, man of God. Go deeper. May 1. Yes, sir. I saw 8-8. That's my year of birth, man of God. I saw 8-9. I saw a wedding. Connection in the realms of the spirit. Yes, man of God. That was when my mom and dad got married. When they got married, I saw you being born. 9. 8-9. When did they marry? In 8-9. 8-9. Prophecy. There is a connection that God plays in your lives. Amen. Go deeper. There is a special anointing that I see in the realms of the spirit. Amen. For the favor of the Lord is upon your life. I receive, man of God. The grace of the prophetic is upon your life. Amen. I receive, man of God. You shall marry a baby. Amen. Prophecy. Divine connections from heaven. I receive. Divine connections from heaven. I receive. In the mighty name of Jesus. I receive. So someone connected to you with a name like P-A-U-L. It's my junior brother, Paulus. Paulus. Yes, sir.  I see the anointing of prosperity. Amen. There is an anointing of business upon you. Amen. And there is an anointing of ministry upon you. I receive, man of God. I see teaching anointing. Amen. I see prophetic anointing. I receive, man of God. I see deliverance anointed. I receive, man of God. I see grace from salvation. I receive, man of God. Your season and your time is around the corner. I receive, man of God. And I'm about to bring it turn around. Amen. Without just saying to confirm that this prophecy is true, but what did it mean for both of you guys to hear from the man of God these certain defined details of such a great prophecy? Okay. Oh, man. She does interviews all the time and she just went for the mic. I'm gonna put my hand behind my back. So, you know, this prophecy really meant a lot for us because for those of you who know us, and for those of you that don't, this relationship between us has been a very long time coming and God has truly blessed us together. And it was just such a confirmation to hear that our coming together was divinely set in heaven from before we were born. And our story is very unique in that I'm a girl from Tri-Cities, Washington, born and raised, and he's from Sweden. And we met each other in Lagos, Nigeria. And we were in a place where we're not even allowed to be friends and yet somehow we still found each other and God brought us together. And so it really brings a really great confirmation for the two of us that, you know, it was set in heaven from the beginning and no matter what was gonna happen, no matter what we went through, at the ages of 29 and 30, yes, we're old, that we found each other in two different countries.  And you can clearly see from the prophetic message that was given to us that it was God's divine will. Amen! And, Richard, what would you like to share with that? He completely just went into a defined detail about your guys' family line all the way to 1917. What did it mean for you? Praise God. The prophecy yesterday was really amazing. I've been doing family research since yesterday. 1917 is a little bit before my time, but I've been asking parents and grandparents and so on. In 1917, my great-grandfather was actually born and he was the only Christian in the family and he was the one that started and set our families line into the path of Jesus Christ. And he was also known to be a healing minister and really fasting and praying and being close to Jesus and all that, so I'm still trying to find out about I know that the man of God, what he said was true about the prophecy and all that, so I'm asking my grandparents and I'm waiting to hear back from them and everything. Anyway, the message of prophecy, it really encouraged me. I have lived close to prophets pretty much all my life. I have seen a lot of miracles and a lot of things happening and as someone that has always been serving, working during the service pretty much, I've always seen other people being touched and because I've always been working in the church, I kind of felt deprived of the blessings that people come to church to do and I know many people that might be serving a lot may identify with this and sometimes I just thought, wow, here I am serving, I want to work for God and yet the blessing seems to pass me by but I felt yesterday that it was just an encouragement to those that are serving, that are working for God that many times you might not be the one to receive a message of prophecy like the people that are sitting down enjoying the service but God Almighty sees what you're doing in the secret place. And also, as I said, my family watched on Facebook and YouTube and they were all shocked and the way that he went into detail, I've lived in this church now for three months and many of the things nobody here knows, some of the stuff even my wife didn't know, it's to show that God Almighty really sees everything and he knows exactly where you're at right now in your life and he knows where you're coming from and he knows where you're going and he is really guiding so it was really an encouragement for me having seen all that and never actually, to be honest, I never received a prophetic message before in my life so coming to this conference I've been at a crossroad where I've been kind of asking God which path should I go because I always go all in whichever path I choose I go all in and so I've been like should I go towards business or should I go towards ministry what does God really want me to be seeking God and this conference I came and I told God I think many of us should be bold when we speak to God you're my father I need to hear from you I need a confirmation you have to speak to me this week I need to hear something from you God just a confirmation that I'm on the right path and obviously as the messenger prophesied said you can't have it all you don't need to choose one direction God can give you grace for all directions as you follow his word Amen and do any of you have just any last words of encouragement for those that are watching on live stream or that are here today and maybe it's their first time hearing about prophecy and maybe they're skeptical or they don't know how to respond to this what would be your encouragement or advice so my advice to everybody is be expectant I think that's pretty obvious be expectant but know that if for some reason on this weekend that you don't receive a word of prophecy or you come here and many of us are here because we're really hoping that God is going to speak to us my encouragement to you is take encouragement from my husband Richard he went his whole life he served nine years in Nigeria amongst a great prophet never once received a word of prophecy but he kept serving and working and doing the work of God and trusting God and growing in his prayer life and growing in his relationship with God and only now at the age of 30 is he ever receiving his very first word of prophecy ever in his life and I want to tell you that what matters most is your relationship with Jesus with your relationship with the Holy Spirit and God will speak to you wherever you are at so don't give up don't lose heart take every prophecy that people are receiving here and take it for yourself and take it home and pray those promises for your own life in Jesus' name Amen


The term is believable... Sorry. No, it's not! The term is believability. Believability is when a researcher convinces themselves that the data itself is usable and is somewhat valid given the situation that it's been collected in. Oftentimes, believability is linked to inter-observer agreement or inter-rater reliability. An example of data that is not believable would be data that was collected by one person who was paying close attention to their phone while they were supposedly counting how many times something happened among a subject. So, although this person may be writing things down appropriately about what the subject is doing, they may not be accurate. I don't find their data believable. So we often use two observers in order to establish some inter-observer agreement. This makes the data more believable, assuming that their levels of agreement are reasonable.