All right. Awesome. Sorry for that. Thank you, everyone, for coming. I'm Jamie from the Habitat Core team. I'm also the lead engineer of Habitat. Habitat is an open source project from Chef. We've been building it for about two years. It's a collection of pieces of an overall application that has a focus on applying distributed systems to application automation. If any of you all are familiar with traditional configuration management, it typically takes an approach of building a system that your application will live on. So it maps pretty well to a system's administrator persona. So you provision out a machine. It's a VM or a container or physical hardware. And then you choose a distro that's part of the provisioning. And then from there, you layer software on top of it and you configure the machine the way that you want it to be. And then you put your applications on it. Habitat takes an approach where it applies distributed systems to make, instead, applications the focus and then applications as autonomous actors in a system that interact with each other to set state using choreography versus orchestration. Orchestration would be micromanagement, top down. So I'm the CTO of this company. And I'm going to ask Phil to do a thing. And I'm going to ask you to do a thing. And I'm going to go down the line. And then I'm going to ask each person, did you do your thing? Did you do your thing? The problem with that is there's a network partition between every one of those requests. And as the system gets more complicated to set up, you need to build in more logic into your orchestrator to handle failure cases through those network partitions or through those different systems. With Habitat, you set a goal for the system. And then the actors in the system make that goal happen for you. And we do that using distributed systems. So Habitat itself is a process supervisor, a developer studio, and also a hosted build service.  Habitat currently works on Linux, any 64-bit version of Linux, 2.6 kernel and higher, I believe. Windows Server 2008 R2 and higher. And currently, we have just support for the client in Mac OS. The process supervisor is a large part of what makes this an interesting talk for all systems go. But the thing that I like to talk about first is the hosted build service. So we have our process supervisor, and it runs packages. So Habitat has its own package managing system that we'll go through. And the build service is the thing that actually runs those. The first thing I want to do is show you all the build service and get a job going so that way we can show the basics of where to get started. So here I am at Habitat SH. If you log in, you'll see this screen. I'm logged in as me. These are the origins that I have. There's a bunch of them that are test origins. The one that we care about is my personal one here right now. So what I would do normally is create a brand new origin when I land here. Origins are like an organization in GitHub. It's a way to segment packages into different containers. So instead of having just one Redis package, you could have one for Facebook. You could have one for Chef. You could have one for yourself. Or you can consume from the core origin, which is where most of our software lives. You'll see on this previous page that the core origin has about 484 packages in it right now. So if you landed here, you'd create your own origin. I'll create a new one for all systems go. We support public and private packages. So a public package is one that you want to share with the entire community. A private one is just like a private GitHub repository where we'll store your packages for you, but without authorization, no one will be able to download them. All the private data around the build output and things like that as well is quarantined off unless the person is a member of your origin. So let's just make a public one. So you'll see that we also generated some origin keys. These signing keys get used when we build packages to identify where that package came from. So if you receive a package, it's got a signature associated with it. And as long as the public key matches, you know that it came from a verified source. So if I was to connect a new package to this or a new piece of software to build the package, I'd come connect a plan file. This is reaching out to GitHub. Sorry, the internet is giving me some trouble here, so it's going to take a minute. But this is reaching out to GitHub to find a GitHub repository that contains not just my software, but a file describing how to build that package. So if we go to my GitHub, actually, I just want mine. I've already forked a project to prepare for this. This is just a sample node application. In this directory is just a node app, but there's a Habitat directory as well that has a plan.sh file. This is the entry point for how to build Habitat software. This might be a little small. Sorry, guys. It's just nine lines of bash. We used your system scripting language to represent how to build packages in the Habitat system. This is nine lines long because we know really well how to build node applications. This is called scaffolding. You can build any software with Habitat. It's not just for Node or Ruby or Python or a high-level language. We built an entire, I mean, it's not a Linux distro, but we rebuilt every piece of Linux from G-Lib C up.  So nine lines, and this describes exactly how to build the package that we're going to put through the build service. I'm going to make it a public package, and I'm also going to export it to Docker. Oh, I haven't set up an integration yet. So part of the process here is, and this is optional, we have post processors for the build process. So after we build a package, we'll upload it back into Builder where Builder hosts your software. So your process supervisors come, they download the software from Builder, and then they run them there. You may have a preference in your organization to use containers. So one of the things that we're going to do here is set up an integration with Docker Hub. I just got to get my password, sorry about that. Whoops, live demos are great. So I've got the integration set up. If I come back here and refresh, connect the plan again. Let's put it out to a container in that origin. Okay, so I've set this up. What I'm going to do here is edit the file to make sure that the origin matches the origin that I just created in Builder. So it's all systems go, and yeah, this is good. Just commit these changes.  So if we look at the output here, this is the Habitat build system, which is called plan build. And it's running and just taking care of installing, installing any of the package dependencies that we have, building that software, uploading it into itself, and then exporting this all to Docker. I happen to have a Docker container already built of this so I can skip ahead and do the cooking show thing for you. Oh, yep, the cooking show thing's going to fail. We're going to wait a minute while this actually does build. So this is a good moment to chat a little bit about while this is building, how the packages work, and why we went the route that we did. So every Habitat package is immutable, atomic, and isolated. So the thing that we're building right now is isolated from the rest of the system entirely. This sample app that we're outputting depends on G-Lib C, but it depends on a particular version of G-Lib C that's a snapshot in time from the moment that we issued the build. So because they're isolated in this way and because they never change, it gives you those superpowers from a container, but it doesn't just work with containers. You can use this for physical hardware, virtual machines, or in this example that we're going to do, a container. And first, traditional configuration management where you have an artifact that configures a machine that has global state. You don't really know if that thing will succeed in running a year from now. You also don't really know if it will just tomorrow or today because the machine that you run that configuration management on basically is dealing with global state at all times. Because we instead set up the machine and we cared about that first and the application is a citizen of the machine, when you try to configure the application, you just don't know what the rest happened on that machine before you came there. So we say that Habitat packages are immutable, isolated and atomic, meaning they never change, they're all or nothing atomic, and they're isolated from everything else in the system. And interesting, why we went this approach and why things are isolated in the way that they are and they only work against the thing that they were built against. Let's take a little bit of time back and talk about a story from about 2000 or 2002, which was a day that Linux rebuilt the world because of a vulnerability in Zlib. Zlib is a compression library that every socket pretty much uses, which allowed for arbitrary code execution if your machine was vulnerable. And because of that, basically every piece of software on the planet had to be rebuilt to remedy this issue. The problem with that is at the time, people weren't dynamically linking to Zlib or some people were, but one of the larger issues at the moment was it was less common to dynamically link to a shared system library. So you couldn't just patch Zlib and then restart all the services. Instead, you had to go to your build server if you had one because this is 2002, cruise control landed at like 2000 or something like that, right? So it's a way back time machine that we're in.  And the problem with that is you just had no idea sometimes which applications were built with which versions of that software. And today in 2017, we still have that problem with containers. People are trying to solve for what is in that container? Do you know, did you just go to Docker Hub, download Redis and then run it and hope that everything in that container is copacetic? Do you know what version of OpenSSL is in there? Do you know what version of Zlib is in there? And the answer is no unless you built it into your build system. And Habitat gives that for you for free. All this is open source and free. That build service that's running right now, $0. You don't give me a credit card. It builds your software for free. So actually what I wanna do right now is rebuild G-Lib C in production as a live demo. I'm not gonna promote it to stable because I don't actually want a problem. But I will rebuild the world right now and show you guys what that looks like. One of the reasons that we built Builder to support this process supervisor and packaging manager is for this problem. We realized if we isolate things in the way that we do, it will be, you will constantly be rebuilding software manually trying to figure out which software at which level needs to be rebuilt to remedy the issues that you have at the leafs or the applications of the dependency tree. Okay, so this failed because my password wasn't any good but we'll get to that in a second. For now what we're gonna do is, I'm looking at Fletcher and Chris's face, the people on my team that didn't know I was gonna do this. I didn't even know. Yeah, I didn't know. If it does, if it's live demos, man, I don't know. I don't know if it's gonna work. It should work, worked like a couple of days ago. All right, so while this is building, I just wanna show you quickly a dashboard that we have. This is private. This data we hope to get out to people so you can see what's going on in the system. But right now, we just launched. So this is private and internal. But this is basically what's happening in the system right now. And G-Lib-C will start working through it in a minute. Right now, I wanna see why this fails. I don't. Thank you very much. All right, so what happened was my username on Docker is different than I thought it was. That's right. Oh, I got this part right. This will just take a second. I'm sorry, guys. Can I get a time check really quick? How many minutes? 20, excellent. Thank you. We have to validate that input. We've got an issue on our board. Also, this entire project's open source. The build service included. So if you go to Habitat on GitHub, here, you can follow our project tracker, see exactly what we're working on right now. We also have a roadmap. I can show you guys that in a minute. But it's all open source. So you can see 100% what we're doing. So this is kicked off now. This is that sample app. And we can see that we've got a number of jobs kicked off. G-Lib C is building right now. And as soon as G-Lib C is done building, it looks at the rest of the dependency graphs. So everything that depends upon G-Lib C kicks those builds off. And they happen in stages. So if 20 things depend on G-Lib C, those will begin building. If 40 things begin to build off of those things, they'll start building. So on and so on until we get to your applications. And why this matters is if you depend, if you have your own origin, say you create Facebook, and you depend upon core G-Lib C for anything. As soon as G-Lib C rebuilds, we issue a command to your projects as well to rebuild. So you'll have a message, it'll automatically rebuild your software, and it won't affect production. That's why I'm pretty okay rebuilding G-Lib C right now. I hope my live demo doesn't fail, but I know that nothing's gonna happen because inside of Builder, we also have this concept called release channels. There's two by default. One is called unstable and one is called stable. Unstable is where all this is happening right now. If you depend upon unstable packages, I mean, more power to you, but I would not. Once we're done with this, if I wanted all these packages to be consumed by other people's projects, or if I wanted to promote, say, our production environment of Builder here, I would promote everything to the stable channel. Builder, this service that you're looking at right now is built on, so my history is I built video games for 10 years. I worked on Guild Wars Two, Lord of the Rings Online, Dungeons and Dragons Online, League of Legends, large online distributed games. In this whole build system, our goal is to have about five nines of uptime or more in a year. This is brand new, and it's in preview, so I can't guarantee that this moment, but the backend architecture that's under this is a distributed online game system, basically, and it models really closely to the experience that I learned from working with the server programmers at Guild Wars Two, where their uptime was unbelievably ridiculous. Anyway, so this build is kicking off now, and it's pushing it into Docker, where I'll be able to pull it in a moment. If we look, G-Lib C's still building. All right, so it's done. So I'll look at latest here. You'll see it's in the unstable channel. There's no latest stable build of this. If I wanted to put this into stable, I take this package identifier, and I simply run this command to promote it. This will be in the UI at some point, but it's not right this moment. So if I push this into stable now, any supervisors that are running the software and connected to the stable branch will automatically be updated, and it'll be automatically updated in a rolling update fashion, if so you want. We'll get to that in a moment just as soon as we get to this Docker container bit. So if I look in Docker now, it created this for me. Like I said, this is optional. You don't have to output a Docker if you don't want to. Just trying to, yeah, there it is, for 8080. So after I pull it, I'm gonna start the Docker container, and forward some ports, 8000, where the app is listening. What just output was the supervisor itself. Our process supervisor runs as PID 1. Why this is important is if you go back to the moment where I described how our packaging system works, and we know every version of every piece of software running. Because we're process one, there's literally nothing else in here. This isn't even Alpine Linux or Busybox. This is nothing other than the process one. We know for sure every single piece of software that's running in your container, and what ports are listening to. All that metadata about the application travels with the package, and because the package is immutable, it never changes, it always works. So if I look here, we'll see I'm running version 1.0.2 of this really, really basic sample app. And if I wanted to change that, something about this app, I just commit something here. Builder picks up the changes, auto builds it. And if I had that container set to auto updating, the container inside would auto update. If not, I could just pull down a new container and deploy it if I'd like to. So let's take a peek at our G-Libs is still building. So we'll move on to the next bit of the slide deck, which talks about the Habitat Supervisor itself. So I talked a lot about packaging, the build system, those are the sexy things. To this crowd, this might be the sexy thing, which is the process supervisor that runs all of this. So Habitat is a peer-to-peer process supervisor with a network thread that communicates in a peer-to-peer fashion to spread rumors about the processes that it's running in an epidemic protocol. I like to play a game with everyone here. If you don't want to play, it's okay. This usually works for a less experienced crowd. You guys might know how this all works already.  So every one of you is a process supervisor running services right now, okay? And the protocol that we're going to speak is a fist bump. We're going to do that for sanity reasons. If you don't want to fist bump, you don't want to play, you can stay sitting. But you can high-five, you could wave anything that you're comfortable with.  So if you want to play, let's do it. All right, wait, wait, whoa, not yet. We're going to, I'm choreographing this, okay? I'm the operator here. I get to say when it happens. Thank you, thank you for being ambitious though. Okay, so I'm going to issue a configuration change right now.  And if you've already received one, just take it anyway and drop it on the floor, right? Okay, config. So three peers, everyone three peers.  All right, so the rumor's pretty much been propagated to this room of 10,000 people. That was very fast, right? A lot of people came to this talk. So if I personally got off the podium and went and issued a command to every single person, it would be error prone. Maybe during that time, someone has to go to the bathroom or I couldn't even give the talk. I can't go do the rest of my work if I was going to each machine or person, which is a machine, in issuing this command. So what I just simulated here was the audience is a peer to peer network. I suggested that a configuration change happens. You didn't have to play if you didn't want to, but if you did, what you did was established a membership list with each other.  I mean, I'm abstracting a whole lot of what that fist bump meant, but imagine that you were a supervisor telling each other about the processes that you run.  The person that's confirmed dead could come back and be like, what happened? I just went to the bathroom, still you're saving my seat, man. And they can come back and rejoin the ring. If they come back and they start causing problems, one of the permanent members of the ring can permanently get rid of them and say, oh, that person has departed. Or as an operator, if I know that somebody's coming back and they're misbehaving, I can permanently depart a member as well and they're not allowed to join the ring again. It's a kick ban. What I just described and simulated is something called the swim protocol. Habitat's process supervisor has this built into it. It uses swim to establish a membership list with the peers around it. Swim stands for scalable weekly consistent infection style process group membership protocol. All that means is mathematically, it scales indefinitely or at least linearly over time. And its job is to figure out who's alive, who's there and who's not. Now that doesn't have anything to do with the services in general, but it does have a lot to do with who's present and what supervisors are available. How we figure out what you're running and what services you have is with something called newscast. And we use this to spread rumors on top. This is a sub protocol, no, this is not a sub protocol, I'm sorry. This is the main protocol for how we issue rumors. There's sub protocols built on top of this which I'll chat about in a minute. So spreading rumors, we spread information about what services we're running, what their health is, what their state is, are they up, are they down, what configuration they have, and if they're the leader, if they're the follower, we build sub protocols on top of this as well. Those sub protocols are leader election. So say you had a database server, three of them running in a ring, an application server is connected to them. You automatically figure out where those databases are through service discovery, linking the services together. So the app servers find the database servers. Let's imagine that you shoot one of the database servers in the head and it was the leader. Well, they'll perform a leader election using Swim to identify the failure and then spreading rumors to figure out who the new leader is. And then the application servers will identify, oh, one of those database servers is gone. I stopped talking to them and they'll be reconfigured and sent a message. All this was done without operator interference. This happens when you're sleeping. As long as you build it into the packaging, which again are immutable, they never change, they always work, the system will just self heal itself as long as you set the packages up correctly. This works with any software. You don't need to change your software.  And it does. Let's check on G-Lib C really quick. Okay, so it's done building and now it's kicked off a whole lot of stuff. So there's about 30 builds running that it's dispatched now and there's 31 other builds that are pending and waiting until those are done. Now they go off in groups and eventually builder will be rebuilt. This thing, this app that you're looking at right now will be rebuilt because I rebuilt G-Lib C and if I promoted the entire world to stable, builder will be automatically updated because builder is running itself, I'm sorry, Habitat supervisors are running builder. Builder is building builder and builder is building Habitat supervisors. Habitat supervisors also can automatically update themselves without a service outage. When they do so, they'll update, reattach all the processes and then eventually builder will be rebuilt and the builder components will auto update themselves. They'll do so in a rolling update fashion and we shard our data one 128th and we have them separated in concerns. So there's a session server, there's a job server, there's all the workers and they'll auto update in a rolling fashion. So you won't notice a service outage either. Unfortunately, maybe next year I'll do that on stage but right now I'm not gonna update G-Lib C to the world and show you that process. All right, back to the slides here. I've got a little bit more time. So the last bit I wanna show you is how to interact with the supervisor and what I'm gonna do is run a multi-tier application with Habitat. It all starts with the Habitat CLI. You can get it a couple different ways with brew, with chocolatey, if you're on Windows and there's a curl bash that somebody in the audience is gonna complain about that if you don't want it, you don't have to use it.  I don't care how you get it. You can even install Habitat with Habitat because Habitat, the CLI is packaged with Habitat but you get to start somewhere. And then what we do is we enter something called the studio. This is one of the large pillars of Habitat. So we have the distributed build service, we have the supervisor and then we have this development environment. Basically it's an isolated CH route. It depends on your platform. If you're on Linux, it's a CH route. If you're on Windows or Mac, it's currently a Docker container and it has just enough of what you need. It's completely isolated, clean room environment. So when you build software in here, it doesn't pull in the dependencies of an operating system around you. You can only link to the things that you've depended upon. And what's really nice here is this studio is exactly what Builder is using to build your software. So if you've ever used another build, I'm sure everyone here has used a build system before but what sucks about them often is troubleshooting them. You make a change in your local machine, you're like, that's probably gonna work.  And anyway, I digress. We did this so we would avoid that. Basically, the studio builds the software the exact same way that Builder does so you don't run into those problems.  And so I already have Habitat and I'm gonna enter something called the studio. So once you're in the studio, it gives you some information here. So for instance, I'm already running a supervisor and if I type SL, I'll see the output. It just went and grabbed some information from Builder itself. This is connected to the internet. I'm connected to the internet. I just went out and connected to Builder and downloaded some packages and now the supervisor's running but there's no processes in it. So if I run HabSVC status, there's no services loaded. So the first thing I'm gonna do is pull down the router for Builder. So it's downloading it from the stable channel which is the exact same version that's running in production. And it also is downloading all of its dependencies. Everything that the router has ever linked to. In our infrastructure, we have gateways at the front, a router and then all the services are in a service tier and then the database is in our data tier. So this is like the message router between all of that and how we can stay online. So if you look in the Hab directory here, you'll see that that's where the packages went. So if I look in the router and at the bin directory, let me move this over a little bit. I'm gonna LDD Builder router so you can see what I mean about the isolation. So you are linked to only Habitat packages here. There is no system glibc here that we're linked to. We're linking to a specific version of 0MQ and LibSodium and LibArchive. All those were built with Builder and with PlanBuild. So that's why I know everything that it's running. I'm gonna start the supervisor again because I hit Control C and killed it. Stupid bug that we have, sorry about that. So if I wanna start the service, I just type start. If I look, it's now taken that package and began to run it as a service. I check the status, it's running. And I also have on every single supervisor an HTTP gateway that's running which will give me information about what's on the system. So I don't have curl because I mentioned only what is needed. The very bare minimum is in this studio. So I'm gonna ask what provides it.  But normally it works, trust me. And I'm gonna install curl and pass it this dash B flag which bin links it into my path. So if I say which curl, I've got it. Okay, I don't have which, you get the point. I'm gonna ask what services are running. And it's a bunch of spew here. So let me get something to format that. If I look, this is information about every single service that's running in the system. That's what it's path is. This is every piece of software that it's running. Or every piece of software that it depends upon the service does. You can hook this up into any system that you want to put data over it or graph it, et cetera. The next piece that I'm gonna show you is running the application server that connects to this. And then I'm gonna have to stop. But I can talk to anybody about this afterwards. So I'm gonna install the API server. And if these were on two different machines, it would still work the same way. Just for the sake of time. And there's a bind that I have to connect this to. So I connected to the builder router service which is running in the default service group. I don't have enough time to describe service groups, but there's tutorials online. There's a 10 minute tutorial. You can, there's everything you need to learn. We try to make habitat as simple to learn in two lunch breaks.  So we start it. The API server started. And I'm gonna look at its config really quick. And you'll see that the routers were automatically filled out in this configuration. This config is my apps config. I config our servers in Toml. But this would work with yours too. And the routers, normally, again, it's all open source. You can see how any of this works too, like how our whole live service works. This is the part of the plan for configuration. It's very simple, just handlebars. If you look at the routers, we went through each alive member of our router bind. We iterated them. We pulled out their sys IP and the configuration that is port. And it's a simple polymorphic relationship between the router and the API server. Router saying, I exposed these things. And the API server saying, I wanna depend on something and you must expose at least this port thing for me. Last thing that we should do here is check on our G-Lib C build. It's still going. That's gonna be going for about another 25 minutes or so. But at the end of it, if I wanted I could promote the entire world and software running anywhere that is depending upon our stable channels and automatically updating would be updated. I have no more time. That's all I could show you. All of this was completely unscripted. So I'm very sorry if it was terrible to listen to me talk for 45 minutes in stutter. But I'm Jamie Windsor. You can find me here on GitHub, on Twitter. Two of the team members, two of the core team members are here as well. Chris and Fletcher, if you guys wanna stand up. I think we're all wearing Habitat shirts. If anyone's interested in Habitat, anyone's interested in Builder, the Dev Studio, we'd love to chat with you. Thank you very much for listening.


Hi, my name is Dennis VanDorp and I'm a general surgeon at Mid-Michigan Health. I was drawn to the field of general surgery based on the wide variety of pathologies and cases. I chose the field of minimally invasive surgery because I am a person who loves new gadgets and technologies. This field allows me to offer cutting-edge technology and techniques like robotic surgery, which allows for complex procedures to be performed using smaller incisions. And smaller incisions means that patients are able to heal and recover more quickly. I'm fellowship trained in advanced gastrointestinal minimally invasive surgery and specialize in a broad range of surgical treatments for conditions of the esophagus, stomach, small bowel, colon, gallbladder and more. I perform laparoscopic and traditional open surgery. Additionally, I have extensive robotic surgery training and offer a variety of robotic assisted procedures. Surgery often offers a definitive treatment for medical condition. I like being able to help my patients recover from medical problems and to improve their quality of life. I work hard to comprehend my patients' unique medical problems and understand their personal beliefs in order to develop long-lasting patient-doctor relationships. I want to teach my patients about their disease so that they are comfortable with me and their decisions. This allows for patients not only to participate in their own medical care, but also to make informed decisions. It allows us to create individualized treatment plans that satisfy their individual wishes. In order to deliver this care, I believe in a team-based approach, which often involves collaboration with multiple specialties, such as the patient's primary care provider and other specialists.


ICT Digital Accessibility The key to achieving a digitally inclusive world. We're living in an increasingly interconnected world. Information and communication technologies or ICTs have become an important part of our everyday lives. While millions of people connect daily to work, obtain information, receive education, buy essential products and services and socialise, many others from vulnerable groups are being left behind. Digital inclusion is the foundation upon which digital communities can be built to bridge the digital gap and ICT accessibility is the key enabler. As a ramp ensures access for everyone in the physical environment, ICT accessibility facilitates the attainment of digital inclusion for all. Digital accessibility guarantees that all people regardless of gender, age, ability or location benefit on an equal and equitable basis from the opportunities offered by ICTs. Accessible ICTs are devices with embedded accessibility features from the design stage, for example smartphones. But accessible equipment is not enough for everyone to understand information and be able to interact. To guarantee access to and use of ICTs by all people, regardless of their specific capabilities, needs and or circumstances, digital content as well as any product or service provided through digital platforms must also comply with the accessibility guidelines and related standards. For example, in a noisy space, a person can communicate through a chat just as a person with a hearing disability would. A visually impaired person will send voice messages just as a person caring for a baby does or someone who cannot use their hands to write. A migrant or a person who does not master a language can access important information if it is provided in easy to read or intuitive formats which will also serve a person with cognitive disability. Three building blocks are needed to achieve digital inclusion for all. Access and digital infrastructure to ensure internet connectivity is in place. Affordability so that users can afford internet access and buy devices to connect. Accessibility of ICTs, which is key to fulfilling digital inclusiveness for all people and encompasses implementation of ICT accessibility policies, regulations and standards. Development of accessible ICTs including devices, products and services. Appropriation and digital knowledge skills by all end users. Building inclusive digital communities is everyone's responsibility. Only through collective efforts will we successfully build the digitally inclusive world we want. Join ITU's work in ICT digital accessibility. For more information please visit our website and resources www.itu.int.


Okay. Good morning everyone. Thanks for coming here. My name is Konstantin Serebryny. This is my co-speaker Dmitriy Lyukov. We're both from Google, from Moscow. And we'll be talking today about two bug detection tools and a little bit of how to apply them to the channel. So first bug detection tool we want to tell you about is called Adverse Sanitizer. It finds memory errors and currently works for user space programs. The second tool is called Thread Sanitizer. It finds data races also in user space programs. After we tell you about these two tools, we'll tell you some of our thoughts about applying these tools to the kernel. And at the end, we'll share some of our requests to the kernel and to the limit distributions to make these tools better. So Adverse Sanitizer. The beauty of C++ comes with a lot of different kinds of bugs. Probably the nastiest bugs are buffer overflows and use after free. But there are quite a few other kinds of memory bugs that you don't want to have in your program. Let me give a brief overview of the tool that we have. The tool is using compile time instrumentation, which is more or less platform independent. And it also has a runtime library which currently supports Linux, OSX, Android, which is the flavor of Linux and Windows. The Linux support is the best on other platforms. The tool has been released in May 2011. In November 2011, it has become a part of LVM distribution. And just recently, around a month ago, it has become part of LVM distribution, starting from 4.8. Let's start from some examples. How do you use this tool? Suppose you have a program and here is a four-line C program that has a global array. And the program is accessing this array out of bounds. In red, you see the buggy part of the code. You compile this program as you do usually, but you add one extra command line option. And you simply run this program as you usually do. If the bug is found, the warning message will be printed to STDR or to some other file if you change options. And it will show you the type of bug. It says global buffer will close here. It will show you a spec trade where the bad access happens. And it will give you some more information. In this case, it says that the memory access is four bytes to the right of the global, and it gives the name of the global and some examples. Some more examples. The tool is also capable of finding stack buffer over close. This is a similar case. We have a stack buffer and we access it out of bounds. Again, the tool shows the stack trace, and now it shows the complete stack frame of the function and where the memory access happens. In this case, we see that the array ends at 432, and the access was at 436 bytes. Next example is key buffer recall. You have a buffer located by U or by malloc or whatever else. And you again access it out of bounds. Very similar situation, but now it shows you where the allocation has happened. And this is probably one of the most frequent bug types you find. It's user to free. You allocate key memory, you deallocate key memory, and then you access it. So in this case, the tool finds you where the bad access happens. It also shows you where the memory has been deallocated and where it has been allocated before that. So how does this work? First, let us know that if we take any aligned 8 bytes of the application, they have only 9 states with regard to addressability. First, n bytes are good, and the rest, 8 minus n bytes are bad. This gives us just 9 different states. And there are no other states because malloc always returns 8 aligned memory, and you can align your stack of global memory by 8. So just 9 states. And since 9 is less than 256, you can encode the state in just one byte. And we call this information byte, this metadata, we call it shadow byte. And this picture shows how we encode the shadow. If all bytes of the 8 byte word are good, the shadow byte is 0. And there are other values that show that there are bad bytes in the 8 byte word. We store shadow in a separate portion of the address space. This example shows you a typical 32-bit address space on Linux where the application uses a little bit at the bottom and a lot of the address space at the top. So we take one eighth of the address space in the middle. We say that two parts belong to the shadow memory. And the mapping is very simple. You simply shift the application address by 3, and then the constant also. So this way you get a mapping between every 8 bytes of application and 1 byte of shadow. This mapping causes one portion of address space to be completely unused, so we end protected just in case. Pretty simple. It actually can get a little bit simpler. If you build with the IE on Linux, you get all of the application addresses at the higher parts of the address space. So you don't need the bottom. And this gives us even simpler mapping, which is just shift the address by 3. One instruction. So what do we do in compiler? When compiler sees some memory access, whether it's read or write, it doesn't matter. It computes the address of shadow by shifting and maybe adding an offset. Then it reads this shadow just one byte. And if this byte is non-zero, it means there is a bug. And we report it. And then the original memory access code. This example is for 8 byte access. And for smaller accesses, the implementation is just four instructions more. But these instructions are very cheap. Let me give you an example of assembly, which is generated by the compiler. This time this is x8664, where two works perfectly as well. So the original address is an RDI. We move it to another register. We shift that register by 3. Then we simultaneously add an offset, load the byte and compare it with zero. This is magic of x86. We can do it in one instruction. If the result was not zero, we jump to the place where we call the error handler.  Very simple. Very fun. In order to find bugs like buffer overflow, we need to create so-called red zones around the buffer. So when you hit the red zone, it actually has some non-zero shadow value and the report will happen. So what do we do with stack? Suppose we have some stack variables in a function. The compiler inserts red zones around this variable. It inserts a 32 byte red zone at the left. And then it inserts red zone at the right, so that it's 32 bytes plus a line on top of 32 bytes. Then, in the very beginning of the function, it puts poisoned values in the shadow. This fsfsf means that we're poising the whole 32 byte region. And these many fs and 2 zeros means that we're poising 24 bytes and left unpoisoned 8 bytes. Then the original code colors and then we unpoisoned the shadow before the function ended. So as you can see, we spend just like six store instructions for every function to make it poison. Of course, if there are more stack variables, it gets more. We do the same for globals. We do it as a program start-up. And the runtime library does this for heap. When a user asks n bytes, it actually allocates n bytes plus something and poisons the red zone. The runtime library also collects stack traces, delays the reuse of freed memory, and does some other book to keep. So this is a good part. Many of you probably have heard to find bugs where MAMSAT touches bad memory. Yes, the question was, why do we need to intercept MAMSAT function? If MAMSAT function touches bad memory, which it shouldn't touch, we will find it. If we don't intercept MAMSAT, we'll not find it because we're compiling implementation and MAMSAT sits in the EC code. And we actually have quite a few interceptors, like maybe a hundred. The good thing about this tool is performance. It is insanely fast. On spec 2006, it shows on average less than two times slowdown. And this is fair comparison, 02 versus 02 plus at the same time. On most GUI applications like Chrome, and this is I'm presenting from Chrome now, you will not see any slowdown typically because GUI applications don't require all of the GUI. On server side applications, we typically see from 50% to 3x slowdown. And this is 02 versus 02. Memory overhead of the tool comes from many different sources. But typical, the overall overhead is between two times and three times compared to the regular run. So this is one of my favorite slides. These are trophies. In the first two months, in the first 10 months of testing Chrome with this tool, we found about 300 bugs, 200 years of the freeze and 100 of different buffer overflows. Now it is almost two years that we're testing Chrome with this sanitizer. And I think we already found more than 1,000 bugs in Chrome and in other libraries. Besides Chrome, our users found bugs in Mozilla, I guess more than 100 already. And basically everywhere else where we or someone else applied this tool. Of course, we are also testing Google server side applications with this tool and perhaps couple of thousands bugs found already. There is some future work we want to do. We want to do some static analysis to avoid instrumenting safe memory accesses to make the tools faster. We want to instrument or recompile the libraries so that we find bugs in any library code, not just memset. We want to learn how to instrument in line assembler if your program has one. Because currently we don't handle in line assembler. I mean, the program will work, but it will not find bugs if they pee in assembly codes. And finally, we want to adapt this tool to use it in kernel to find bugs in the kernel. And this part we will discuss later in this talk. So as a summary of this tool, C++ has suddenly become much better, much safer and we are welcome to use this tool. One tool we will not be talking today is memory sanitizer, which finds users of uninitialized memory. It's sort of, if you combine memory sanitizer and memory sanitizer, you get functionality of Veldrin, but 20 times faster. The tool we will be talking today is ThreadSanitizer and I am giving the word to my colleague. Hi. So ThreadSanitizer is a data-raised detector for C++ and the Go language. So what is data-raised? Data-raised occurs when two threads access the same variable concurrently and at least one of them is the right. So here you see a simple program with the data-raised. And you also just need to add the F-Sanitizer equals Thread flag to the compiler. And below you see an example of the report. We described two racing memory accesses, print the stack traces for them, and describe the involved threads, print stack traces, and also describe the new text that was held during the memory access. So we started working on the ThreadSanitizer back in 2009, but it is now what we call ThreadSanitizer version one. It was based on the Veldrin and it was very slow, like 20, was it typical slow down and sometimes it was more than 400. But we still found thousands of races with it and at that time it was faster than others. So about a year ago we started working on ThreadSanitizer version 2, which is also based on the compiler instrumentation instead of Veldrin. And we completely redesigned the runtime library, so now it's really parallel. There is no mute access so expensive atomic operations on the fast pass and it scales through really huge applications. It has better and more predictable memory to print and also brings very informative reports. So here is some performance numbers. This is our server-side application. The RPC benchmark is a highly parallel to boot benchmark and there is some typical server application test and stream GPU test is a very simple single-server test. So there you see that slow down of ThreadSanitizer 1 is like 25, 40 and on the RPC benchmark it's more than 400. And for ThreadSanitizer 2 the slow down is about 2 or 4x which is much, much more acceptable than much faster. So the compiler instrumentation is very simple. We just insert the function calls into the runtime library to intercept the interesting events. So we insert function calls in function and try before function exit and before each memory access we insert the callback which says whether it's the read, write, the size of the memory access and pass the address. And we also intercept the atomic operation in the compiler model. So ThreadSanitizer also uses the shadow memory and also the simple zeroth mapping which is very similar to address synthesizer so currently it requires dash 5 flag so that all application memory is at the top of the address space and the shadow mapping is similar with just two arithmetic instructions. So the shadow is more complex. It consists of so-called shadow cells. Each cell is 8 bytes and it represents one, describes one previous memory access to the application memory. So there is 16 bits for ThreadID, 42 bits for default or a scalar flow when the memory access was done and 5 bits describe the size and position in 8 byte application block and one bit says whether it's read or write. So all the information is in the shadow cell it's completely empty. Then for each 8 bytes of application memory that you see on the left we have 4 such shadow cells that describe up to 4 previous memory access to that 8 byte application memory. So let's consider a simple example. So initially all shadow cells are empty and then Thread1 makes the write to the first 2 bytes. Since the shadow is empty you just remember in the first slot the ThreadID is closed and the size, position and that is the write. Then Thread2 makes the read of the last 4 bytes so we remember that information and we check the different cells to find potential races. So in this case they do not race because they touch different memory. And then Thread3 makes the read of the first 4 bytes so we store that information and check the previous memory access. So it does not race with the second memory access because both are released. But it can potentially race with the first access because they are from different threads. At least one of them is the write and they access the same memory. So now we need to answer the question whether there is a data rate or not and so we need to check whether they are synchronized or not whether they run concurrently. So for this we use the so-called happened before relation I won't describe in the details how we exactly calculate this but this constant time integration we just need to extract the thread ID and the clock from the shadow memory and make one load from that local storage and make one compare. So when all shadows are full and we need to store a new memory access sometimes we can replace one of the previous memory access without losing any useful information but if it's not possible we just replace the random values with the new memory access. So when we find the data race we bring the report and it contains two spec traces for the current memory access and for the previous memory access. Current stack trace is easy just need to unwind the stack but the previous memory stack trace is kind of problematic because all memory access we don't know if it will erase with some future memory access or not and it means that we need to remember full stack traces for all memory access in that situation and to remember the stack traces we use the surface cyclic buffer of events so events are memory accesses function and try exit and mutics lock and lock each event is 64 bits for type and 61 bits for program counter or associated address so when we need to restore the stack trace we just replay this buffer from beginning to the memory access and while we replay we model the state of the stack and when we reach the interesting memory access we get the stack trace for this memory access and similarly we get the set of mutics that were held during the memory access so this replay is slow but it's done only when we report the race so it's not relevant but it's very fast to add to the stack trace we just need to increment the position and store one word into the trace and also has the predictable memory footprint but since the buffer is cyclic we lost the information after some time so by default we hold 128,000 events per fret which is roughly 1,000 sorry 128,000 previous memory accesses for each fret so we also have function interceptors for more than 100 functions like malloc free to pre-thread mutics, something pre-thread create, destroy and so on for memory copy and also for read, write, open and for example this we can find races and file descriptors when for example you write the file and can currently close the file descriptor so what are our headaches, it is timeouts so the programs are still slower so some typically server applications sometimes trigger some timeouts, usually just increase the timeouts so it's memory consumption sometimes programs get killed due to out of memory also we have problems with non-instrumented libraries especially if we miss some synchronization on atomic variables for example in non-instrumented libraries and the last thing is so-called benign data races it's when you increments encounter without any synchronization and you think that it's okay yeah the threat synthesizer complains about such things as well. Now I move to address synthesizer for Linux kernel so we are not kernel hackers at all and currently we only have very early proof of concept of the tool so it's more about what we want to do so what is currently there, there is config debug slap which adds red zones and poison into the kernel memory blocks, it can detect some out of bounds and use after free, but it doesn't detect out of bounds reads and use after free detection it's kind of best effort there is KMM check which triggers page and fault on every memory access and just simulates the memory access so it kind of finds I think most of the bugs are very slow due to page and faults there is also debug page alloc which unmaps the freed pages from address space so it can find use after free but only if whole page is freed so there are also some static analysis tools but they're kind of complementary to the dynamic tools and there are some experimental or academic tools but as far as I understand that they are not in the widespread use so what we want to do is config asen which is intended to be fast and comprehensive solution for use after free and out of bounds bugs so it's based on the compiler instrumentation so it will be fast so it can find out of bounds for both reads and writes it provides strong use of the free detection due to delay to use of memory and it detects the bad memory access promptly right when they happen and also provides the informative reports with stack traces for when you where you're located freed the memory block and so on so this is our ideas and on how to implement this so on top you see the virtual address space in the kernel there is a user part and the kernel part and in the kernel part there is physical memory region so we want to place the shadow memory into the physical memory region at the constant offset for example 64 max or something and the size of the region will be 1 eighth of the physical memory so then the calculation the shadow mapping is very similar to user space so we need to check that the address belongs to the physical memory range and then also just divide by 8 and add an offset so there is also virtual memory and now it's unclear what's the best way to handle it because so ideally we want the mapping for the shadow memory to be just a divide by 8 and add an offset without any additional branching or something so so we want to start with the slab allocator and add red zones and poison and poison them and add the delivery use of the memory blocks to find the use of the free box so the API that the ASAN will provide is looks like this there is a function to poison the memory region and poison the memory region and check the addressability of the memory region so with this API we want to instrument the mem set mem compare function and so on and probably some other memory allocators in the kernel so here is the problem that we know about so we need to find the way to do the fast shadow memory mapping we need to figure out what to do with the bootstrap process because we can turn off the instrumentation due to performance considerations so there will be some text size increase and there may most likely be some problems with interrupts especially if we want to print a report from the interrupt and there may be some problems with modulus for example like if the module is not instrumented or instrumented with the wrong version of the address sanitizer and most likely there are a lot more problems so potentially we can also implement the threat sanitizer but it's much more challenging because address sanitizer need to intercept it need to intercept some memory management function and some memory accesses so if it does not intercept some other memory accesses it just won't report the bugs there but threat sanitizer need to intercept all synchronization absolutely otherwise it will report false positives so and the main issue that we see there is with the atomic memory operations in the kernel so in user space we rely on the C11 like atomic operations where you also have where you have the address of the atomic access you see that this is an atomic access and you also have the associated memory ordering like a query release but in the kernel it's usually expressed just like a plain memory access and then there is a write a read memory barrier and there is no way to figure out what exactly this memory barrier intended to synchronize and now I'm giving the word to Kostya as we told the tools perfectly well very well at least for user space but they could work even better with some of the help from the Linux kernel and distributions actually mostly from the kernel so the ideal address space layout for these tools is when all of the application memory is somewhere in one place either it's at the very bottom or at the very top we don't care the simplest thing is when everything is at the highest one eighth of the address space if this is 64 bit of course so this is from 7 all zeros to 7 ffff and today we actually achieve this ideal address space layout on Linux if this is x8664 if this is PIE if address space layout randomization is enabled and if the stack size is limited and this is what we use for T-SAN and this is what we prefer to use for A-SAN ideally we would have this space layout always as Bill Gates said in 1981 16 terabytes of address space should be enough for anybody say it again sorry we didn't see any slowdown it's round noise maybe 1% this is not peak this is PIE so PIE is less expensive than peak and on the programs we would try to measure this and we didn't see it and some programs are already built with PIE by default like Chrome is built with PIE by default so there is no difference at all a little bit more like complain about address space with address space layout randomization off so if you take a C program that prints an address of main and if you build it with PIE on the recent Ubuntu it will print something like 5555 and this is with ASLR off and on the older Ubuntu you will see something like 7FFF and we like this 7FFF much much more so this actually means for us that T-SAN threat sanitizer cannot work with ASLR off for example if you run it in GDB you have to explicitly disable it so that you can run T-SAN and this is for us it is a serious regression between Ubuntu 10 and Ubuntu 12 we know actually the guilty commit and we would like to find someone to explain us do you really need this folks? another problem is unlimited stack which is really too greedy today if you run a program with U limit-S unlimited it will actually allocate 84 terabytes of address space for stack do you need that much? I don't think so so this is one this is another complaint it also causes us some trouble with T-SAN because we cannot run T-SAN in a setting where stack is unlimited and for some unknown reason GNU make sets stack to unlimited so if you run T-SAN from make it will not work unless we do something tricky this is not a complaint this is a request we run these tools in a memory limited settings like we want to run many many tests on a single virtual machine where they compete for memory and since the tools take more memory than the regular run they sometimes require more memory than there is available and then the process just dies due to out of memory the good thing about the tools is that all three tools are designed in this way that the shadow value zero means it's okay no bug there it's a good memory so if we could give these shadow pages to the kernel when it is close to out of memory such that when we need it back it comes either with the old state or with all zeros this would be perfect and this a little bit similar to M-advice don't need but not exactly equivalent we've seen something very similar as f-advice volatile somewhere in the patches but this is not in the main kernel so this is something we want very much to make the tools more stable in the presence of strict memory limit we actually don't want the VM to discard these pages first we don't want the VM to discard these pages first we want the VM to discard these pages lost if we talk about this yesterday at much time we really want to end it by once but don't need if you don't have to but if you do get rid of them because we're interested in the data but if you need them take them away because zero page is fine for us and it helps people to use malloc alfator as well because two more commands exist you know if I want these pages I want them back because you know I've got my structure set up for them and I can use them but it's not there this is required for the tools to run in the memory limited environment otherwise the tools work well today also one of our request is how to limit the memory of the application running under these tools ASAN address sanitizer uses 20 terabytes of memory T-SAN uses 97 terabytes of memory or virtual memory of course and memory sanitizer uses 72 terabytes in this setting u-limit-v is useless you cannot say I want to use like 73 terabytes of memory it will not work so we need some way to limit the real memory for the process maybe the containers will help us I'm not sure but I guess we're not the only guys who want this functionality in the kernel another problem is general robustness in the presence of large m-mapped regions so all of the three tools map the shadow memory with m-map no-reserve flag which means that we allocate these many terabytes of memory but we're not actually using all of them and unfortunately in the current state Linux is very unstable if you are actually starting to use all of those 20 terabytes or 40 terabytes there was a bug with mloc all which caused the machine to hang if you first allocate 20 terabytes and then you say mloc all machine dies this bug has been recently fixed about couple of months ago in the trunk and we still see problems if you just start using that memory too much most usually this is either bug in our tool or some very serious bug in the user code which triggers these hangs but still I think that the kernel should not be dying on such conditions one of our requests to the Linux distributions so all of these three tools are very good at finding bugs in user code but sometimes a user may call a library code like maybe libc or maybe things like gtk or qt or whatever and that library will access some freed memory for example so this is not a bug in the library this is a bug in user code which calls library code on incorrect pointer but all of those will not find it because the library code is not instrumented which is worse for T-SAN if the library is using atomic synchronization and we don't see it we will see false false positive reports so the best solution we can think of is to ship instrumented libraries or maybe to have some automated way to build them from scratch if needed and I'm afraid this has to be done on per distro basis or at least like it has to be done one way for RPM, one way for Debian packages one way for anything else so let me summarize our talk address sanitizer finds buffer overflows used after free bugs in C++ code this is very fast, very robust and we believe it must have for all C++ developers and this is actually already like this in Google more or less all of the C++ code is tested with address sanitizer thread sanitizer finds data races not just in C++ but also in the Go language so if you are using one of those languages and you have threads both tools are possible for the kernel T-SAN is a little bit more tricky because of these atomic synchronization issues we are currently in the investigation stage and help is more than welcome if we get some support from the kernel and Linux distributions the tool will become even more awesome both tools, well actually all three tools are open source A-SAN and T-SAN are part of both LLVM and GCC distributions and M-SAN is a new tool which is currently only in LLVM thanks a lot and we are ready to take questions. The question about ARM architecture yes, these tools can work on this device we do have regular process of running Chrome tests for Android on the Android device, no virtual machine just a plain device we know that someone has tried A-SAN on Ubuntu for ARM but we ourselves didn't do it so it is known to work on Ubuntu ARM. Yes, when we free memory in A-SAN we need to mark the shadow for the freed memory as poisoned. We don't need to touch the actual memory and since the shadow is 8 to 1 it is compact we actually need to memset much less memory than the actually the allocated chunk. It is a fast operation yeah so there are red zones or like if you have a region either global or stack or heap buffer around it we have poisoned areas. They are typically something like 32 bytes on each side for large heap locations they are larger so if you access 1 byte out of bounds or like 10 bytes out of bounds you hit the red zone and it is poisoned for example like 1 kilobyte out of bounds you may be unlucky and you may hit another location so the bug will not be detected. But the red zones are adaptive so if you have a large heap block the red zone will also be large. Yes before we actually read the memory location we also read the shadow of the memory location we cannot detect all of the wild pointer references but the way our locator is made we actually do find a lot of wild references just due to we sort of increase the probability of finding wild references Yes so the question is about the GoFret synthesizer so the algorithm is essentially the same. We have maybe a few defines in the runtime library for Go because for example Go is type safe language so we don't need to store the size of the memory access so the first byte identifies the variable and we also have some different constants for example for max count of frets because GoRoutines and GoA might much lightweight so they can do more of them but the compiler instrumentation is done in the Go compiler but otherwise it's the same. Thank you for the questions. If you have more we are here for the rest of the day and we will be happy to answer more questions. Thank you


Most of this information comes from instructions for Schedule 8812 credits for qualifying children and other dependents tax year 2022 specific constructions you can find on the IRS website irs.gov, irs.gov, looking at the income tax formula, we're down at the bottom in the credit area. Remember in the first half of the income tax formula is in essence an income statement ending with the taxable income, which is similar to net income in a normal income statement. We're then going to calculate the tax based on the taxable income, not with a flat tax, not with one rate in other words, but with the progressive tax system to get to the tax before credits and other taxes. Then we deal with the credits and other taxes like the self-employment tax, and we deal with the payments in the form of estimated tax payments or the withholdings finally getting to the tax refund or tax due. Note that we have this breakout between the credits on two lines. We have the credits up here and then the credits down here. That is generally to deal with the issue of having refundable and non-refundable credits. When we think about an income tax system, normally you would think it would not be correct to have credits that bring the tax liability below zero. So the credits up top here are typically those that are non-refundable. They will not bring the liability below zero. The ones down here are the ones that are refundable, meaning if your liability goes below zero, you might still get a quote refund, end quote, which is really kind of a benefit program, the tax code being used as a benefit program in that instance. All right, specific instructions. Part one, child tax credit and credits for other dependents, all filers, line number four. We'll take a look at this in more detail with some examples of the forms in future presentations right now. We'll just go through the line items. So add the number of boxes checked under quote child tax credit, end quote, and column four of dependents section on form 1040 or 1040 SR and enter the results on line four. So first page of the form 1040, you have then all of your information. You've got your personal information, your social security number, your spouses, their social security number, your dependents, their social security numbers, and then in the dependents section, you're going to be checking off if they qualify for the child tax credit or other dependent credit. You can't have both of them checked off, just one or the other, and then on page two, we can then kind of interpret what's going to happen with regards to the calculation for the credits just by glancing at page one and whether you checked off the box for child tax credit or other dependent next to your dependents. So caution, you cannot check both child tax credit box and the credit for other dependents box for the same person. If you do that, that would be a big red flag you would think to the IRS and there could be a delay on the return. So line number six, add the number of boxes checked under quote credit for other dependents in quote in column four of the dependent section on form 1040 or 1040 SR and enter the result on line six. So line 13, enter the amount from credit line worksheet A. So we'll go into, I won't go into the worksheet in a lot of detail here because we want to get the general concept down and then rely to some degree on the software so that we can basically communicate with people in terms of the projections that we can, their tax planning as well as just explaining the credits and then we can use the software to kind of back into, let the software do the calculation and then try to verify the calculation to make sure it is correct. So when completing credit limit worksheet A, you may be instructed to complete credit limit worksheet B. If you meet certain conditions, complete credit limit worksheet B only if you meet all the following. One, you are claiming one or more of the following credits. B, you've got, sorry A, mortgage interest credit form 8396. B, the adoption credit form 8389. C, residential clean energy credit form 5695. Part one, D, district of Columbia first time home buyer credit form 8859. So these are kind of more unusual type of situations that could complicate the calculation possibly because it might have a calculation adjustment for like the modified AGI calculation or something like that. These are areas where of course tax software is helpful because hopefully the tax software if you're doing the data input properly can help to pick those kind of changes up and then you can kind of double-check and verify by deconstructing to make sure everything's properly done. Two, you are not filing form 2555. Three, line four of schedule 8812 is more than zero.


Welcome everybody to another exciting edition of the top 12 most anticipated manga releases, this time for the month of July 2023. Lots of interesting books to talk about, so let's get started. Okay, so I might be cheating on this one, but I do have to talk about it. It is the final volume of Dr. Stone, Volume 26. Now, the reason I say I'm cheating is that usually in these videos, I tend to recommend Volume 1's new story collections or anthology series, stuff like that, and I don't usually go and say, hey, you like this? You might consider getting 25 other volumes for you to enjoy Volume 26, but this is pretty monumental. I like this series a whole ton. I've been collecting it ever since Viz Media put out the first volume, so I'm eagerly anticipating to get my hands on the last entry in Dr. Stone. I'm only going to read this one sentence here, the science-powered adventure comes to its dramatic conclusion. I don't want to read the full description, because it'll spoil some things for people out there that might be getting into Dr. Stone or collecting Midway, stuff like that, but this series is great. I love its attention to detail to science and celebrating humanity's triumphs and achievements and all that fun stuff, while also being tongue-in-cheek and having fun with Shonen Jump Tropes and that power of friendship stuff. Love it. This is one of my favorite Shonen Jump series. I think Lichiro Inagaki and of course Boichi did a phenomenal job. So yeah, if you are interested in Dr. Stone, you just watch the anime. Consider getting the manga. The art is breathtakingly awesome at times and really fun too. I highly recommend Dr. Stone in its entirety, if you can get it. Classroom of the Elite, Horikita. Volume 1. This is being published by Seven Seas. This is an alternate universe spin-off manga from Classroom of the Elite. So technically, you could go in blind, but it is recommended to at least have some knowledge of Classroom of the Elite. Horikita Suzune wants nothing to do with her annoying classmates. All she wants is her distant older brother, the student council president, to acknowledge her presence. Horikita turns to a student almost as anti-social as she is. Ayano Koji, Kiyotaka, for help. Despite a rocky start, Horikita and Ayano Koji spark a friendship. But can their growing relationship survive the suffocating and cutthroat atmosphere of their elite school? Honestly, going off from that description, I think you're safe if you want to give this a blind buy. Definitely be on the lookout for Classroom of the Elite, Horikita, Volume 1. Like a butterfly, Volume 1. I think this is the first time I'm talking about a Shojo Beat book here from Viz Media, but it's pretty cool. You got a romance slice of life series written and drawn by Su Morishita. Suiren Shibazeki is often compared to a beautiful flower, but one that grows on the tallest peak of a mountain, forever out of reach. When Suiren develops feelings for the quiet Taichi Kawazumi, however, she doesn't want to be a distant flower. She'd rather leave her lofty perch and fly towards him like a butterfly. After Kawazumi rescues her from an unwelcome admirer, Suiren finds herself captivated by him. But Suiren is too shy to speak to anyone, much less this reserved karate boy. What's more, Suiren isn't the only one interested in Kawazumi. Will a class trip offer the opportunity to reveal her feelings before it's too late? Give her back to me. This is published by Glacier Bay Books and written and drawn by Hana Chattani. Tragedy follows those whose lives are linked by a family heirloom and the strange curse it bequeaths.  The trauma and loss wreaked upon each generation by the last. This sounds wonderful. I love that it is a Shojo Horror Mystery title and I cannot wait to grab this. Super interesting and as always great attention to detail from the folks at Glacier Bay Books. I need to grab this as soon as I can. From Tokyo Pop we got Acetown Volume 1, an action drama BL series written and drawn by Kyuko. In a city where lawlessness rules, Yuki and his best friend Tetsu attempt to rob the headquarters of the local Seidokai in order to steal money to pay for Yuki's little brother's hospital bill. The mission is a failure but peaks the interest of mob boss Kazutaka Hyodo. He offers Yuki a deal, come to visit him once a week and he'll take care of his brother's fees. Yuki accepts this arrangement without question and so makes his first visit. This one sounds like it has a lot of angst, drama and street action grit so I'm pretty sure a lot of people are excited to dive in with Acetown Volume 1. Tier Moon Empire Volume 1. This is being published by J Novel Heart, a fantasy historical series by Nozomu Mochitsuki and Art by Mizu Morino. As the flames of revolution scour the Tier Moon Empire, its ever selfish princess Mia Luna Tier Moon meets her doom by the way of public beheading, only to wake up in the past as her 12 year old self. It's time to shape up, recruit some allies and exploit her knowledge of the future to save her empire. Is she up to the task? Not even slightly, but it's her only choice if she hopes to spare herself from yet another gruesome end at the blade of the guillotine. Now this is pretty interesting you got a sort of, you have sort of a time travel variation of an isekai story so that's pretty cool plus the fact that it takes the cute elements and mashes them up with French Revolution vibes.  Digital manga publishing is putting out I Should Not Love You. This drama romance BL series is written and drawn by Chize Ogawa. Since he was little, Taisei Fujiman has been known as the pretty boy in his town and throughout his pampered and self-indulgent life thus far there has only been one thing standing in his way. Keita Okachimachi, his former middle school classmate. Therefore when Taisei is once again reunited with Okachimachi after three long years apart, Taisei can't help but get riled up and thus begins Taisei's grand plan for revenge. Except something's wrong even though he loathes Okachimachi with every fiber of his being. Why is Taisei's heart beating so fast that he can hardly think straight? If you're in for a good BL romance series, you might want to give I Should Not Love You a shot. Yen Press is putting out a beloved series that was super hyped and highly requested. This is the Summer Hikaru Died Volume 1. This is a horror mystery supernatural BL series written and drawn by Mokumokuren. Two boys lived in a village, Yoshiki and Hikaru. The two did everything together until the day Hikaru was encompassed by a mysterious light. That was when everything changed. Hikaru most of all, Yoshiki still wishes from the bottom of his heart to always stay by his side. But is there even a Hikaru left to be with? I love the supernatural aspect to this. By throwing that in there you just piqued my interest. The Summer Hikaru Died comes out real soon so I do recommend checking this out as well. Secrets of the Silent Witch from Yen Press. We got the first volume here coming out. This is an action fantasy school life series written by Matsuri Isora and art by Tobi Tana. Monica Everett is the Silent Witch, the only mage in the world who can use Unchanted Magecraft. But underneath all the fancy titles, she's also the shyest girl you'll ever meet. In fact she learned Unchanted Magecraft just so we wouldn't have to speak in public. Monica may be talented, but she has zero confidence. And now she is being tasked with infiltrating a prestigious academy and protecting the kingdom's second prince. How will she survive? I really like the art on this one. I love magical inspired stories like this. So I'm actually really excited to check this out. Oh boy, the Great Snake's Bride Volume 1. This is being put out by Seven Seas. This is a drama romance supernatural story written and drawn by Fushiyashi Kumo. Now let's see if I can read this description without raising some eyebrows out there.  Mio, an unlucky woman from the nearby village, is offered as tribute to the Great Snake. Mio fears that she will be devoured, but the snake treats her like a wife rather than a Mio. His flicking tongue vibrates through gentle words, as his powerful, slithering body wraps around her in an embrace. What does it truly mean to be the bride of a beast? Now I know what you're thinking, this is kind of weird, and I know that, but if you go back and study some Japanese folklore and tales of yokai, you will know that there is a lot of interactions between these mystical, magical creatures and regular humans. And that is sort of the main inspiration here for the Great Snake's Bride. Now there is a bit of not-safe-work stuff in here as to get to know each other, but the story is actually pretty sweet. I have read some of this. Any of you are of the mindset that this won't bother you as much, the fact that it's a giant snake. I think you'll find something to enjoy here. It's a quiet, serene series with burst of action and great artwork. I think the art is a great selling point from Fushiashi Kumo. So I do recommend Great Snake's Bride. If you can get past the whole giant snake god deity thing, I think you'll find something to dig here with this romantic series. The Devil is a part-timer anthology series. This is being put out by Yen Press, the comedy supernatural isekai series. This is written by Satoshi Wagahara and art by Akio Hiragi. The Devil King and his friends check out a wedding venue, buy swimsuits to work at the beach, and get marooned on a desert island. This collection of original comic stories drawn by a lineup of artists and fans of the series collects episodes which may or may not have taken place during the main story. So this is pretty fun.  I think you'll be right at home with this comic anthology series with multiple artists working on it and of course the different stories within. Soichi, Junji Ito's story collection hardcover. It's been a while since I've talked about a Junji Ito story collection book so I'm excited to get this even though I'm not a fan of Soichi because he really creeps me the f out with his obsession of biting nails.  Whether it's summer holidays or a birthday party, Soichi can turn any occasion into a nightmare. In a heartbeat, what is the terrible secret of his origin? 10 tales that celebrate the sinister and hilarious world of Soichi. I'm no stranger to Junji Ito. I trust his writing. He makes some fantastic work. So yeah, I'm really excited. Yay. All sarcasm aside, for real though, I am excited to get it. It's another wonderful Junji Ito collection for my bookshelf. But yeah, these releases look great and I think Viz Media does a wonderful job with the Ito books. So if you're an Ito fan, do check it out and let me know what you think of Soichi as a whole because I do remember that he did show up in other short story collections outside of this but I was not vibing with that necessarily. 12 of the most anticipated releases for the month of July. But what about you guys interested in any of these releases? Let me know in the comment section down below. And if you're not, let me know what are some of the other books that are coming out that you're interested in. That's going to be it for now. Thank you everybody for tuning in. I truly do appreciate it. I've got to go. Stay safe. God bless. I will catch all of you on our next episode.


How is a child's development affected by their social relationships and the world around them? Ecological systems theory provides one approach to answering this question. The ecological systems theory was developed by Yuri Bronfenbrenner. Bronfenbrenner believed that a person's development was affected by everything in their surrounding environment. He divided the person's environment into five different levels. The microsystem, the mesosystem, the exosystem, the macrosystem, and the chronosystem. In this lesson, you will learn about these different environmental levels by meeting five-year-old Alex and examining the influences in his life. We will begin with the first level of Bronfenbrenner's theory, the microsystem. The microsystem is the system closest to the person and the one in which they have direct contact. Some examples would be home, school, daycare, or work. A microsystem typically includes family, peers, or caregivers. Relationships in a microsystem are bidirectional. In other words, your reactions to the people in your microsystem will affect how they treat you in return. This is the most influential level of the ecological systems theory. Let's look at the microsystem Alex lives in. The first part of his microsystem is his home environment. This includes his interaction with his parents and little sister. Alex's school is also a part of his microsystem. His regular school interactions are with his kindergarten teacher and the other children in his class. The next level of ecological systems theory is the mesosystem. The mesosystem consists of the interactions between the different parts of a person's microsystem. The mesosystem is where a person's individual microsystems do not function independently but are interconnected and a certain influence upon one another. These interactions have an indirect impact on the individual. One aspect of Alex's mesosystem would be the relationship between his parents and his teacher. His parents take an active role in his school such as attending parent-teacher conferences and volunteering in the classroom. This has a positive impact on his development because the different elements of his microsystem are working together. Alex's development could be affected in a negative way if the different elements of his microsystem were working against one another. The exosystem is the next level we will examine. The exosystem refers to a setting that does not involve the person as an active participant but still affects them. This includes decisions that have bearing on the person but in which they have no participation in the decision-making process. An example would be a child being affected by a parent receiving a promotion at work or losing their job. One part of Alex's exosystem would be his father's workplace. Alex's father is in the Navy. This often takes him away from the family and Alex sometimes does not see his father for months at a time. This situation impacts Alex and he becomes anxious when his father leaves. Alex's anxiety has an effect on his development in other areas even though he has no interaction with his father's work or say in a decision-making process. The fourth level of ecological systems theory is the macrosystem. The macrosystem encompasses the cultural environment in which the person lives and all other systems that affect them. Examples could include the economy, cultural values, and political systems. The macrosystem can have either a positive or a negative effect on the person's development. For an example, consider the different effects of the development of a child growing up in a third world economy versus that of the United States. An important aspect of Alex's macrosystem is the fact that he is a military child. Because of this, he has already moved three times and lived in two different countries by the age of five. Alex is also influenced by the values of the military community that he belongs to. The chronosystem is the final level in ecological systems theory. The chronosystem is the dimension of time in relation to a person's development. Time can be relevant in different ways. One way time can be an influence is the timing of an event during a person's development. For example, the death of a parent would affect a three-year-old differently than a teenager. Time can also be an influence because of historical events or conditions that exist during a person's life. An example would be the effects of growing up during the Great Depression or during World War II. Technology is one important part of Alex's chronosystem.  He even received his own iPad as a Christmas present. This could have a developmental impact on his learning style and social skills. Alex's experience with technology is also very different from that of a child growing up 20 years earlier. Ecological systems theory was developed by Yuri Bronfenbrenner. He divided the environment into five different levels. The microsystem is the most influential, has the closest relationship to the person, and is the one where direct contact occurs. The mesosystem consists of interactions between a person's microsystems. The exosystem affects a person indirectly without their direct involvement. The macrosystem includes all other systems and a societal culture surrounding a person. Finally, the chronosystem refers to the dimension of time and can be divided into two parts. The importance of the timing of an event during a person's development or events that are unique to a particular generation. Each of these levels includes systems that influence the development of an individual in some way.


Nigeria has assured Spain and Qatar of smooth diplomatic relations. President Mohamed Abu Hari gave the assurance while receiving the ongoing ambassadors of the two countries in separate audiences. He told Marcelino and Sorena that Nigeria was glad to have a relationship with Spain in trade, technology and education. And when he met his excellency, Abdulaziz al-Muhannadi, President Abu Hari said relations between Nigeria and Qatar have been strong and credible. Hello, hope you enjoyed the news. Please do subscribe to our YouTube channel and don't forget to hit the notification button so you get notified about fresh news updates.


My name is Andrew Rujage, and I'm the IT Regional Director for Africa. The Regional Office for Africa is in Addisababa, Ethiopia. It is often referred to as the political capital of Africa. It is the youngest continent in the world, but 95% of the young people are employed in the informal economy with absolutely no guarantees. There must be digital transformation. They must transition into digital economies. The strongest asset in doing this is the young people. Probably one of our biggest barriers to connectivity is broadband infrastructure. The whole continent is covered by satellite coverage, but the space segment is very expensive to this day. We are still priced out of range. The power is so unstable that anytime we could be cut off. So I have this portable dongle where I can quickly switch off, but you could ask me, why don't you use solar? It's like we are starving, so why don't I eat cake? What keeps me going is the promise of this young continent and the fact that ITU is making a difference.