Yeah, no, that's great. You have the wrong screen on. Nope, still the wrong screen. Just take a minute. Alright, look at that. Also, even when the light's not on, it's still... It's still working? Okay, cool. Yeah, first. We'll do back and forth with this. Okay. And that's your water? Yeah, it's my water. Oh, yeah. I was going to... I was going to try and put this, like, up here, but it's fine. Yeah. I'll put that here. Or here. Better. Nope. What are you doing? I was going to put it up there so we could see it if we were not standing right here, but... Oh. It's not long enough. I see, though. Yep. Is this one's mine? Yes, that's yours, that's mine. Tell you what. Let's see a trash can. Okay, we're going to start them in a few minutes. Yeah, that's fine. I'm happy. Yeah. I wish they had enough light out for you. You are nice to me. Yeah, I'm not worried. Yeah. Okay, just for you, Dave. Yeah. We approve of heckling. Look at the top, though. It's not like a runny... The rap band? Heavily influenced by country? Unless you like that sort of thing. Center room, people, come on. You can do it. Lazy fucks. I tried. They didn't listen to me either. Sorry? I said I tried. They didn't listen to me either. Oh. Okay. Now for the next talk, we have a couple guys from Facebook presenting us how to build better Floss Community Relationships. Right. Yep, yep. It's yours. All right. Hello everybody. My name is Davide. This is Phil. And we'll be talking about building better Floss Community Relationships at Facebook. Before I start, quick note. There's a lot of teams at Facebook that work with open source, either an internal project that are made open source or work with open source communities. This talk is primarily about our experience in the operating systems team. Operating systems is a production engineering team at Facebook. We take care of the bare metal experience in the fleet. So we own things like the bare metal operating system, which is sent to us, that runs on every machine at Facebook. We take care of configuration management, where we use Chef, we deal with provisioning, how you just send us on the machine, and with the packaging infrastructure. Our main customers internally are either services that run directly on bare metal, so things like databases or Hadoop, or other services that are built on top of the bare metal that then other teams build things on. Think about the containers platform, for example. So a little bit about what we're talking about in this talk. So we're going to start with a look at open source at Facebook. This is going to be one place where we are talking about something that's not specific to our team. Why open source has been in the Facebook ethos since the beginning. We'll look at a bunch of different teams and the things they do. And then we will go into why you would do this. This is an open source conference. Most of this is not going to be new to you guys. But it is useful, I think, to talk about how you justify the value to the business in creating open source relationships. We'll go into how you do this, or how we do this anyway, some tips and tricks and things to think about. From there, we will look at our journey over the last year with the relationships we built and how we scaled out, the way in which we were building these relationships. And then finally, we will look at lesson plan. So if we talk about open source at Facebook, as I said, it's part of our ethos, and we have an open source team. And their job is to shepherd open source at Facebook. And what I made by that is they do things like ensure that, help you to figure out how to open source something. If you go and talk to them, they'll help you deal with the packing stuff and the lawyers and the licenses and all that. But they're also engineers, so let's say you have some software and you're like, hey, I would really like to open source this, it's got all this weird Facebook specific crap in it and they'll say, okay, they'll help you figure out how to factor that out and make a module or a plugin or a config file or whatever the right thing to do there is. They also write a bunch of tools. So there's a tool called ship it, they wrote. And what it does is take an internal code repo and sync it to a GitHub repo, commit by commit. And the benefit here is that because it's commit by commit, you as an internal engineer actually have real commit access on the GitHub repo so you get credit for your work. The community you're working with has the full context, it's not some code drop that came out once a month, they get commit by commit with logs, everything that's happening. And also the internal engineers can continue to use the internal tools and whatever that they're used to. So huge benefit there in terms of us really being able to bridge that gap. They write other tools as well, they keep GitHub issues in sync with our internal issue tracking stuff and all those sorts of things. And they also provide a lot of guidance on is this really going to be something that's worthwhile open sourcing? Are you going to be able to build a community? What kind of messaging do you want to put around it? Does it fit in with other projects that we've done? Those sorts of things. So they're a great team and they help a lot with this stuff. So that said, looking back at Facebook and our history of open source, as most of you know, the site started as a lamp stack. Mark sat in his dorm room and wrote a PHP app. So PHP is open source and Linux and MySQL and all this stuff. So we started as an open source company. And as we move forward, we continued to use open source and contribute to open source. And that's been true and a core part of the engineering culture since the beginning. One of the stories that's sort of interesting there is HHVM or as it was previously known as HPHP or HipHop depending on who you are and where you came into the story. So we used PHP and we started investing in it and contributing to it and in particular we wanted to make it more performance as the site got bigger and bigger and bigger. And so Facebook contributed various performance fixes to the PHP and then somebody internally was like, well, I wonder if we could take a different approach that would have bigger gains. And they wrote a PHP to C++ compiler. And it was awesome. It was terrible. It was awesome. And it added just an order of magnitude of performance. We open sourced it, other people started using it. Lots of wins. But it added just downsides if you were trying to do something quickly, having to compile your code base, not so fast. And it turns out that we eventually ran into scalability issues with this one as well and instead we wrote a JIT VM called HHVM. Also open sourced, also used by a bunch of different companies. The interesting part of the story for this talk is not the technology. The interesting part of the story is that that team continues to work with the PHP community today. They help write standards. They help move the language forward. When they want to add something to HHVM, they sit down and talk to the Zen guys. They contribute features to Zen PHP. They continue to be an active member of the community. They didn't go off, start with PHP and write their own language, or sit in a bubble, do their own thing. They're active members of the PHP community and they continue to make sure that HHVM is simply another runtime for the same language that everyone else is using, regardless of which runtime you choose. Another story is MySQL. So as I said, here's MySQL shop and we've had MySQL engineers for a long time. In the early days, the way you contribute to MySQL was send a patch to Sun. As I think most of you know, the story of MySQL has evolved over the years.  And that went really well for a while. And ultimately all of those companies ended up sort of choosing their own direction. And out of that project came several other projects. And today what we do is we have a simple fork of MySQL on GitHub. We do all of our contributions and all of our development. We're very close to what we're running for thought, includes things like MyRockTV and it's just like any other open source project. And what I think is interesting about this story is that over a long history of a community that went up and down, that was very ambiguous at times, different companies, different ways of looking at it, different ways of contributing, the team worked really hard to adapt to the way the community worked and continue to contribute in useful ways. And the third example I want to give is the kernel. So our kernel team is interesting because... So I've been at Facebook for six years. Before I came to Facebook, I did attempted to recruit me a few times though. This is a session. And one of the things I found was that as I started research in the company is that the kernel team had contributed an almost full rewrite of the UDP system in the network stack of the kernel. And I thought, well, that's kind of cool. Open source, they're contributing. Maybe I'll pay attention to this company. So I came to the company for that and other reasons. And the kernel team started to grow. Now six years ago, the company was very small. We're obviously now very big. So the fleet grew, the kernel team grew. And as the kernel team grew, there was more and more and more patches. I imagine we probably have a few red-eyed employees in there somewhere. You know how painful it could be to have a whole lot of patches on her. So eventually, the kernel team realized that this was untenable. So they decided to change their approach. They started with an upstream-only development model. Every feature, every fix, every change that we want to make, we develop on one side stream, we add it upstream, and then we map for it if we need to. Which means every time we move the kernel forward, instead of having to port a bunch of patches, we just drop a bunch of patches, which is a lot easier. It also means we can move faster and all those sorts of things. So a really interesting story. The kernel team wrote a really good blog post on this and it will be in the references at the end of this slide. Now to be clear, we haven't always been awesome at this. There have been a lot of learning lessons at the beginning. We made plenty of mistakes, but we tried to fix things and every new relationship tried to do something better. One good story early on that we're talking about is HBase. So HBase is a data store that we use internally at Facebook for many things, most notably messaging. We started using open source HBase years ago, but pretty quickly there were a number of things we wanted to do, a number of Facebook performance improvements we wanted to make. So we forked it, and we worked on this forked internal version for years. As the worker, as we made more and more fixes, this version diverged from the community one. We got to the point where it was so different that we couldn't really move code back and forth. We couldn't really contribute to open source HBase anymore, and we couldn't import patches from open source HBase anymore. At the same time, the community made their own performance improvements. So we went there and we tried running open source HBase against our fork to see what would happen. It turns out open source HBase was better on almost all better performance metrics that we heard about. So we switched. We set up an effort. We slowly transitioned over to open source HBase, and these days we run open source HBase everywhere. And we work with the community. So whenever we have to make performance improvements to HBase, we do it in the open, and we are able to get the benefit of people making improvements to HBase as well internally. For ZooKeeper, that's a similar story. ZooKeeper is a key value data store that's used all over Facebook infrastructure. Again, we started with the open source version, forked it early on, and made a ton of internal fixes to it. Then later realized it was a bad idea, and now we're in the process of switching back to open source. A different story where things went actually quite well since the beginning is Chef. Now Chef is a special case here, and we'll talk about Chef more later in the talk. Chef is special because since the early times, it was both a business relationship with Chef, the company, but there was also a relationship with Chef, the community. And we tried very hard since the beginning whenever we were working on Chef and with Chef, not to focus on the commercial part, but also work with the community. There's a steady flow of patches and contributions and discussions between us and Chef and Chef and us. And these, frankly, work great. We've been running Chef for four years, and we had a very good relationship with this community throughout the journey. There's also a lot of projects at Facebook that are not things we work with the outside communities, but projects we developed internally and later open sourced. This is a short list of some projects you may have heard of, Voice Query, React, RocksDB, Macrouter, the Buc build system, a number of projects around 360 video and VR. All of these are things that were developed internally and then we released in the open. Pretty much all of these have, like, a GitHub repo. And if you look in the GitHub repo in the log, you'll see that there's a bunch of commits from Facebook employees, of course, but there's also a lot of commits from community members. And all of these projects are deliberately managed as community projects, so they're not Facebook-only things. They're projects that are co-maintained with the community. They're community members that have input in what to do with the projects that participate in design discussions. They're open mailing lists and IRC channels. And we've tried as much as possible to build community around these projects because we know it's the model that works. So with that, let's talk a little bit about the why. And as I said, most of you know why one would want to use open source, just right here. And probably most of you know why you don't have a relationship with the open source communities that you work with, but that's not always as easy to make a business case for. So let's talk a little bit about that. So efficiency is kind of the easy one, right? So when you talk about being efficient in regards to software, you have this, you know, the same thing that you always talk about, right? If I use open source software, it's a thing I didn't have to write. But as you use open source software, if you're trying to build a relationship and you're trying to be more involved in a community, you're following what's going on and probably using more recent versions of software. Which means that you have less patches you're maintaining as opposed to using a four-year old or five-year old or a six-year old version in which you have all of your local hacks and features and fixes and stuff. And as you get closer to what the community is using and you're keeping less of this internal, then you're maintaining less code, which is great. And as you do this and build a better relationship, it becomes easier to contribute. People know what you're doing and they accept your patches. And that's great because now you're helping the community.  And that's no fun. So, you know, this feels good, right? We all like contributing to open source. We all like knowing that people are using our software. And then finally, you know, the sort of more eyeballs generally tends to mean better code, right? More reviews, more people using it, all of that sort of standard stuff that you talk about when you talk about contributing to open source. So, the other thing is less time-listed, right? As you get closer to the community as you're more aware of what they're doing, you're less likely to do the thing where you find a bug. You spend a couple hours debugging it. Then you go in your right patch and test it. It works, you know, great.   I've all been there, I've been there.  Or let's say maybe you don't have the expertise or the time to write that PR. So instead, you spend hours doing S-traces and gathering logs and gathering data, and you write up this really great bug report because that's what you do, a good community member.   So now you're wasting more time or you're wasting their time or you're wasting both. And it turns out that when you do this, this causes just a little bit of animosity. It makes it hard to build relationships.  Another reason is direction. So, it turns out it's nice to know what's coming down the pipeline. So, whether that be, hey, when I upgrade to SunOS 7, I'm gonna have to deal with system D all of a sudden, or whether that's something small, like say, net catch changed its command line engines or tail no longer takes minus number or whatever it is that you care about knowing that these changes are happening means that you don't get blindsided by it when you start upgrading. Even more importantly, if you're involved in the community it means that when someone goes, hey, should we change this thing? You can be like, I have some opinion! Right, you can all of a sudden say, hey, I don't know if that's a great idea or hey, maybe that's a great idea but think about this use case or whatever the case may be is. And the more you get involved in those sorts of conversations, where people know what's going on, and eventually you get to a point where people understand that you're not just there for yourself, you're there for the community, for the project, for the software, for people, and so all of a sudden you're in a place where you can actually start suggesting changes. You could start being part of the direction itself. And on the topic of people, people are important. We always say code wins arguments, right? But it turns out all of that code is written by people, so people really do matter. And it turns out that when you can contribute your software to upstream as an internal employee, that surely tends to make you happier. You get to see, you get credit for it, you get to point your friends to it, you're like, look, I'm going to deny it, that's not just this internal thing you do at work. And as we all know, happier engineers tend to be better employees. They work harder, they're more loyal, etc. Right? Excuse me. So the other thing is it goes both ways, right? We've been talking about how to engage with the community. But the community can be more engaged with you as well. So after four years of being involved with Chef, it is not uncommon for someone to send a call to us. And then one of the guys internal Chef to tag me and say, hey, Phil, you guys care a lot about this code. What do you think? Because they're invested in our use case. They're invested in what we do. They know what we do and they care about us as a community member. So it turns out that as you engage with the community, there's a really interesting side effect that we did not sit down to plan. This was not one of our goals. It was a bump in recruiting. So again, it didn't set out to do this.  They use this and they use that and they contribute to this and those are things I care about. So that was useful. And finally, good relationships are contagious. So I'll tell a story a little bit later about a way in which some relationships lead to more relationships across. But in general, when you're engaging with an open-source community, there's a decent chance some of those developers were in some other open-source community. And so when you want to contribute to this second community, you already have a strong foothold.  Now, let's talk a bit about how you go around building our relationship with communities. And the main thing here is that you want to build social capital with the people working there and you, of course, you have to do actual work in a project. Now, the best way to meet people is meet people in person. This can be easy or it can be hard. It really depends on the project. Some projects are very geographically distributed so it can be difficult to physically meet with people. So once every project has some kind of nexus, like a conference, everybody goes to a meet-up, some local event, somewhere where there will be a core set of developers that you can engage in person and start getting to know, start talking about what you're interested in and what they're interested in. Some projects that are more corporate-driven, you could meet at the company office and go there and offer to come to their office and discuss your use case or to present a tech talk maybe. At the same time, you can also invite your office to give a tech talk or to talk about their use case or your use case. It really doesn't matter how you do this but if you can somehow meet in person it makes things so much easier. We all know how easier it is to work with people after you share the beer or a meal together. This goes a long way, especially in the beginning, in building a relationship with folks and with a project team. Now, of course, you also have to do actual work and the way you do actual work very much depends on the process themselves. I always like to use mailing lists for coordinating works. Some projects use lack. In some cases, people like to have long design discussions on IRC, while in other cases, they prefer having those in person at events like conferences or meetups or they have those on lists again. It very much depends. The important thing here is figuring out early on what's the medium that people use to communicate and start engaging in it. So start looking at what people are talking about and try to pitch in when you can offering advice or answering questions. All you have to do is try to understand what makes the project and these people think. What's the higher level goal? What do they care about? Why do they work on the things they're interested in and what are your goals? And start talking about that as well. Another thing you want to pay attention to here is what the project workflow is. Now, every project has its own special set of things they do to develop. Like, it might be tools they use, it might be an approach to testing, it might be how they use branches for development, it might be code review. Some projects might have weird legal limitations around what they're doing. It really depends, but at this stage you want to understand how people work and you want to try to work on their terms. It makes no sense to jump into a project at first and start imposing people, oh, you have to do things my way. That never goes well. Another thing that's important at this point is try to understand what we call your context. What I mean here is that you want to get in when you start this conversation, and try to understand what they're talking about first. Try to understand what they care about, try to understand what the projects they are cares about, what their own map is, why are they interested in specific features of things. And then also provide your context and give what you can to these conversations.  Nobody likes getting an announced PR, their effectors have their code base for no reason. It's just not good. But if you talk to people first, maybe you'll find out that they do want your help, help. Maybe they were working only before and you just didn't know about it. Maybe somebody wants to pitch in and help you. Or maybe they think it's a terrible idea and then you have an opportunity to persuade them, it's not. Either way, if you start having this conversation early on in the appropriate setting, it makes things so much easier and it makes it a lot easier for your changes to land afterwards. Another thing to consider is speed. And what I mean here is that if you want to contribute to a project, of course, follow its development and figure out where things are happening and how. For most projects, this means looking at what's going on in master. But you're not necessarily going to run master in production. In some cases you might, like say, you're early on integrating a project and it's like some component on the side, running master might be helpful because it makes it very easy for you to test changes quickly and to port changes quickly from mainland. But in practice, that's not always possible. On the other hand, as Phil said before, you don't want to run a four-year-old version of the codebase because you'll be effectively isolated off from the community. You won't be able to contribute bug reports. You won't be able to move code back and forth. You'll have to find an epimedium. What the medium is depends really on, like, what resources are, how your deployments work, and also how the project releases work and what dependencies they have. One possible choice here is using whatever the latest project stable is, or the stable minus one, or some release that's packaged in a distribution. It's also something that can very much change in the history of the project. Maybe at the beginning you have to track master closely, but then as the amount of contribution you make slows down, you can use something else. The goal here again is to make sure you can keep up with the development and keep a constant flow of patches and non-code contributions between you and the project and you. Finally, in all of these conversations, the most important things is being honest. You'll want to be upfront first, what your goals are, why you care about the project, why are you going to help, and what do you want to help on. If you do this, it will be a lot easier to interact, and people will also be upfront. And one start second guessing why this large company is suddenly interested in their project. So let's talk a little bit about our journey. So as Davida said, the primary goal of this is to talk a little bit about our journey of the operating systems team into building these relationships. So at the beginning of the year, we realized that the scope of our team had grown, that we had a lot of ideas to contribute to a lot of different products, and we knew we wanted to grow the set of relationships we had. And it's not that we hadn't had great community relationships, we'd worked with a variety of communities over the years. It was just a realization that all of a sudden we were going to have a much larger number of them, and we thought, let's take stock, let's figure out what we've done well, what worked, what didn't work, and the next set of communities and a very intentional manner. So we decided to figure out there's some considerations you want to make when you're going to engage with a community. And one of them is your goal, and your goal may change over time, and your goal may be big or you're going to be small, but actually understanding what your goal is will really help in how you're going to engage with a community. The second thing is, as Doug was talking about, what speed can you reasonably expect to keep up with this project to make it move? Project moves very, very slowly. There's no need to be like, oh, build it every day if they're getting one commit every two weeks. So it entirely depends. Additionally, you care about the size of your change. So if I'm going to make a three in line fix to some little project, maybe I don't need to say get on a plane and go talk to them. That may be overkill. But at the same time, if I'm going to do a massive refactor, maybe I don't do a giant bypass. And finally, not so much applicable to the examples I'm going to show, but knowing that if, knowing whether or not you've had a previous engagement with this community and how it went, is also really important. And that may not necessarily be your team or you in person. It could be the team that sits in the next building over but still has the same name on their jacket had a really bad interaction with this community. And that's going to be important for you to know. Bless you. That sort of, as Doug has said, a good example is Chef. This has been one of our longest standing community relationships that our team was sort of directly involved with. But it wasn't an exact match, right? A lot of the projects we were looking to interact with, we weren't going to have a business relationship with either because we didn't have necessarily interest in it or that wasn't an option or whatever. So we had to sort of compare carefully. Now, with Chef, we worked really hard to ensure that we engaged with the open-source community of Chef as well as the company equally. We worked really hard to make sure that we balanced this. So in the early days, there was a now the Chef service was open-source but in the early days there was a proprietary one and an open-source one and a proprietary one led the open-source one. And we ran both in production. Even though we wanted the new features in the closed-source one, we wanted to make sure that it was open-source in production so that we always filed bugs against both and so that we could always talk about performance in a way that was applicable to what everyone had access to, not just the people who were paying for it. That was one of our first attempts to make sure that we were engaging with the open-source community affected. And then the client, which has always been only open-source, if we found a bug, we didn't just file a support request. We went to GitHub, we wrote it out and made sure it was public for everybody.  So, our goals changed over time but our initial goal was scalability. So we picked Chef at the time because for a bunch of reasons, one of which was it scaled better than its competitors but we also limited it a lot more scale added than it currently had. So we said when we talked to them about kind of this sort of fixes we'd like to see and scalability improvements we wanted to see and they started working on this very actively. And in order to actually test this we needed to and move as fast as we needed to we were basically getting leading edge releases sometimes several times a week. And these weren't just releases they were making. This was like, do commit some code and build a .Facebook RPM and like email it to me. That's how fast we were moving. We were literally upgrading much of the fleet every few days to try and keep up with these releases and give them good feedback and talk about what the next bottom line was. So that goal led to that speed. At the same time, once we'd sorted out all the scalability issues and didn't really care about it anymore, our focus changed. Instead of worrying about the scalability of the Chef server we started worrying about features on Chef client we wanted to implement. And so it turns out that to implement most of these features as like one person instead of a massive development team or company I would take me maybe a couple weeks because I was also doing other things. And so when you think about that and you think about the rate of change that the client was at we kind of looked at it and thought you know what could probably do this quarterly and that's hopefully what we did. We upgraded both Chef client and Chef server about one support at this point. And by being involved in the mailing lists and the Slack channel and all that sort of stuff we're more than capable of keeping up with the changes and the delta's not so big that we can't actually contribute meaningfully. We got involved in community events. We I gave a keynote at ChefConf and several other talks. I did panels. I went to Velocity. We always were involved in the various community efforts in and around DevOps and Chef. We went to the Chef developer we still go to the Chef developer summit every year we talk about the features we want to add the things we're thinking about we give other people input on the things that we're thinking about. This sort of stuff is critical to actually being a member of a community. We got a bunch of benefits out of all of this right. So they implemented 96 work for us as well as massive scaling changes. We implemented multi-package. We implemented a massive improvement to their system support. Our client engineering team implemented a significant amount of OS10 support that was not there. As we engaged with the community and made all of these changes, what we found was people were really interested in the way we use Chef because it's a little different from the way other people use Chef. People were interested in the tooling that we wrote and the code that we wrote and the cookbooks. So we open sourced pretty much all of it. As much of it as we possibly could which again helped us to show the community what we're doing and communicate well. So we took all of these lessons from all of these other teams and from our interactions with Chef and other people. What do we want to contribute to this year? What are the big places where we can actually make a meaningful contribution? One of the things that really stood out to us was Anaconda. Most of you probably know what Anaconda is the installer in Fedora right now. So we looked at that and we thought, well what's our goal? Our goal was to have a single network installer that can install a variety of versions of Red Hat on us. And that was really good. We didn't want to be on some ancient version. We wanted to be on the team with leading edge hardware support, walk saw, I think six support. There was no real good option for this. The reason there was no really good option for this is because when the Anaconda team forks off Anaconda for any given Fedora release Master then drops every feature that's not required in Rawhide anymore and all those features only live in that one branch for that version of Fedora. And we don't run Fedora, we run SundoS. So now they re-fork that Pharrell and the number of features there are even more so. So the Sund6 version can install Sund7 and Sund7 can install Sund6 and so on. So this was not a pull request, right? There was no single pull request that was going to do this. This was a workflow change. Turns out you don't want to send a pull request for a workflow change. We were smart enough to know that. So I emailed Anaconda guys and I said hey can we come visit you? There's stuff we'd like to talk about. We really like a shop there. And I said sure, we're in Westford, Massachusetts and so I bought a plane ticket and co-worker of mine Brian and I went out and sat in their office. And we started that conversation not with hey here's what we need or here's what we want or here's what we plan to contribute. Instead we said hey what does being a good community member look like to you? What is a good customer or a good user? How does that look? They're super involved in this community and they gave us a whole bunch of input on their good customers and bad customers the feature requests they liked the feature requests they hated and from where they started talking about the branching stuff and how like all of the weird red hat internals and where they could merge things and where they couldn't merge things and from there we had all this context about their workflows and their needs and their desires and we were able to frame all the things we wanted to do within that context and we actually had that conversation and they were so much more willing to accept the things we wanted to do that in fact they just said cool let's just spend the next couple days hacking on this and we did and it was great so we set up a bunch of photo facets we talked about changing a couple of the workflow pieces we flew back to San Francisco kept in touch with IRC and eventually all of this stuff got merged and today we have a single installer built off of master that can install CentOS 6 and run it's got bleeding edge hardware support and all the IPv6 stuff we need which by the way is where most of our internal hacks came from we run an IPv6 on the clusters so we had this like just stack of v6 fixes on ancient versions of Anaconda we're not running a 4 year old piece of software anymore which is awesome it was great in order to do this development we had to figure out the speed at which we wanted to and it turned out that like there was no Fedora release that was close enough it was way too far so we realized we were going to have to build off of Git so then the question became how often do we build off of Git and what we found was doing this monthly meant that we could let a release date long enough that we didn't take down imaging infrastructure on Facebook we were more than close enough to be like they do development but they're not so fast that within a month you can't still contribute patches and stuff so it was a good speed compromise and we got all the sort of features that we wanted out of this another project where we realized early on we wanted to work closely with the community is SystemD now SystemD at Facebook came along when we started looking at moving from center 6 to center 7 but this was about 2 years ago and as you all know center 7 comes with SystemD by default and we had basically 3 choices we could keep using sys5 and maintaining that on our own we could move to SystemD and embrace it or we could do the crazy thing and write our own in it and we decided to go with SystemD but there were several reasons for it and one reason was that there were a number of features in SystemD that we could take advantage of SystemD gave us a good way to do service supervision and we had like 5 or 6 internal homegrown ways to do that that we really wanted to get rid of SystemD also had interesting features around resource management and that combined with the work we were doing on Zero2 gave us an interesting tool to test this in production so we started looking at what Red provided and Red was packaged with a pretty old version of SystemD and we realized fairly quickly that that was not going to cut it because it was old enough that any bad report would have filed to upstream and it was far enough that we couldn't really move code back and forth because master had evolved so much so we started looking at how upstream developed and we figured out that if we were going to run SystemD we could run the latest stable the latest stable minus 1 that would be fine now it just so happens that Fedora Rohite packages the latest stable and usually when upstream releases Fedora Rohite updates in like 2 weeks maybe so that's great all we had to do was back port from Rohite into send 7, deploy to the fleet test, fixbox and repeat that's what we did later on we took her back port and released it on github and we'll have the link at the end and SystemD maintainers at rail built a copper repo for it so if you want to play with it and you need like recent SystemD on send 7 you're welcome to use it now we did a lot of changes internally in SystemD that then we contributed I guess the main thing that's worth talking about here is the secret 2 support secret 2 is interesting because secret 2 was developed by a Facebook by Tejon who's on our kernel team and the kernel secret was maintained upstream and Tejon worked early on with the SystemD community on this and in addition to the code itself there were a lot of conversations around what would be the best way to implement this how to deal with changes on the kernel side how to deal with APIs that on the kernel side were not solidified yet and all of this was possible because we had an early engagement with the community itself another thing that we were able to adopt that was really helpful is the testing process so our stream has this tool called MKOSI that lets you from a SystemD checkout it will build it and spawn a quick container so you can start SystemD in it and see what's going on and test features now this is useful for two reasons one because this is the workflow that the system uses when we make changes we talk to our stream, we can talk on the same footing we can give logs, people understand what's going on also we didn't have to make up a testing process for our system it was already there we could just take whatever thing gave us and it would work fine which is great this was a massive time saving and it was something that made our engineers much happier another thing we did was we went to a conference we filled myself and Zil on our team we went to SystemD.com in Berlin back in September we talked about this work I gave a talk there where we talked about how we use SystemD in production the issues we encountered and we had a lot of good discussions there with developers and with the community at large I want to talk briefly about a couple of other projects where we were able to have good interactions with the community Innistrips in particular is a great example of a serendipitous interaction that happened at a conference when we were at SystemD.com we met the SystemD maintainers for a while and we started chatting with the SystemD maintainers for Innistrips now it just so happens that in Facebook we use heavily network strips network strips is the part of Innistrips that takes care of setting up the network if you're not using something like Network Manager or NetworkD and we used that all over the fleet and over the years we had piled up a number of fixes and improvements and features on it that we used internally and but we never really found the right avenue to send us upstream so they kind of lingered inside and we had to forward them and the thing about this within a couple of days the maintainers moved their repository to GitHub created a new org made us maintainers and gave us commit access so we were able to contribute very quickly a number of fixes on V6 number of new features we were able to contribute per device route and we also were able to get features in turns out upstream made fixes that we didn't know about that happened to fix real bugs we had in production that we also didn't know about one thing that it's worth talking about briefly here when we early started looking at this codebase the codebase was interesting in that there was a lot of code that was a mix mesh of tabs and spaces which made it kind of difficult to make feature changes because you would end up mixing feature changes with formatting and it was kind of unwieldy to work with so we were thinking early on to re-format it but sending out a large PR to change spacing is usually not great especially as your first contribution to a project so we talked to the team and we approached them and sent an email it was like what do you think about this if it would make life easier for us to contribute would you accept it and we had a conversation about it and it was fine in the end so we sent this and that made it massively easier for us to send the other fixes the thing that's important here is not the white spacing part but the fact that we did have the conversation and I'm pretty sure we had not done that we just send the PR and be done with it we would not have been as well accepted another project where we'd like to be more involved is in the packaging space RPM, YAM and DNF so of course we run RPM at Facebook around centers and over the years we've found a number of issues with running RPM at scale mostly around RPM-DB corruption we have tools to fix this we have a number of tools we've wrote internally that deal with fixing the RPM database and making it work well at scale and we're pretty happy with RPM in general but we'd like to be able to contribute these fixes upstream we'd like to be able to open service these tools we'd like to make in general RPM more resilient we'd also like to help test YAM scale and we'd like to make sure that we move to DNF we can also keep DNF performing well at our scale so having done all of this it's good to sort of look back at the lessons we learned or remembered listening first is kind of really the big one and it seems so obvious to people when you're talking but it's not always easy to do when you're really excited about making some contribution so actually remembering to listen first when you go and engage with a new community or a new developer is really important and you gather all of the context about their limitations about the things they want to do about the things they're excited about it helps you to make sure that you know how best to present the changes you want to make and then providing context to how your space change to minit scraps and I had just sat down and the first time I tried to prep one of our fixes for pushing upstream I was like oh I have to fix this and I started writing this white space and I got it already and I was about to pull up send the pull across and I realized this is only my first pull request to this community and we talked to them in person and all but also god that just looks like you know credits and I was like I don't want to be that guy and so as you said we sent a email it was fine pull request emerged providing people context on why you're doing something makes a huge difference drive by pull requests of almost any size less likely to be accepted and then finally we didn't talk about this much in this talk but non-code contributions can be a real thing when you're engaging with a community you have to realize and think about what it is that you're best able to contribute in this moment and even if you're a developer it may not be code maybe you don't know the language maybe it's a functional language and you just don't even want to wrap your mind around that maybe you just don't have resources at the moment maybe the code base is huge and you're just like I don't have time I can't wrap my head around this for whatever reason code may not be the thing I'm sure are going to contribute to this community and you have a great budget to donate or maybe you know that you can sit on IRC and answer questions or maybe you can add documentation or provide testing hardware figuring out in a given moment what the way you can best contribute is going to make you the best community member that you can be which is going to make all the rest of this really easy so those are really tiny and for some reason clickable even though it's a slide but these are the links to basically everything we've talked about including the blog post from the kernel team and his talk and a couple of my talks and all that stuff we'll provide the slides to DefConf so that you can go download them and make with the actual clicky clicky and with that said if you've got questions we'll do our best to answer them yeah so the question was for the reporting on the MySQL side there's a sense that the community has moved to MariaDB why are we still on MySQL the answer is frankly I don't know there is there is been discussion I think it's largely because of the massive investment we've made and the the effort involved to try and take all of our delta on top of MySQLDB and move to MariaDB there's also just a lot of different people who are involved in different there's like nine forks of MySQL at this point and they all have a very specific use case in mind and so whether or not those are going to align well there is a MySQL engineering Facebook page and I think a group but don't co-mail it and you can actually ask in there and I'm certain someone else is asking there's probably an answer but if not you should ask and are MySQL engineering team a great group of guys and they're all happy to wax philosophical on the various branches of MySQL Somewhere over here there was a question No? Yes? I swear I saw one Yeah, in the back So the question was how do you deal with non-responsive upstreams we've done a bunch of this You talk to them for the most part you try to talk to them Usually if it's like a tiny project that's done it's just not that much to do so it works in that case you might have fixes to contribute either there will be a maintenance fork somewhere on GitHub that people maintain that's actually upstream or you will see that whatever is packaged in Federa and Debian is upstream plus this stack of patches and that's effectively becomes your upstream, you'll talk to the package maintenance for the distros Otherwise, yeah We did this with Young, right? So we have two or three pull requests against Young, which have just sat there for like a year and so like what did I do? We talked to some people at Red Hat and we're meeting with them tomorrow, right? I was like, hey, I got some stuff for you I know you're kind of dead, but except those pull requests have been great So we're going to sit down and we'll talk to them because it turns out that they're humans who have a job and shit to do and if you've got to have a conversation with them it's going to go better There's a bunch of cases I don't remember which one it was There was an Ohio plug-in which is a piece of chef that some dude had written It was like on his personal gain I know what it was It was a plug-in to run LSPCI and enumerate the bus and provide all that data And it's like maybe 25 lines of Ruby We're not talking a significant piece of software here And there was a bug in it It was just a bug and so we sent a pull request and that dude has disappeared He's just not caring about that thing anymore He's got another job or whatever And so the pull request is there and one of these days maybe I'll call my fork the real fork or something, I don't know But it was a two-line fix to a 20-line piece of Ruby that I think there's six people in the world to use So I didn't care It just doesn't matter If you use it, you'll go see the pull request If I do some real development on it I would go, hey, this is now the real one Come check out James H's That's my GitHub handle James H's fork and it's fine The beauty about open source is that if someone truly, really truly not responsive can always fork it I recommend that as a last option for the backup Yes It depends We sponsor a ton of conferences We have donated hardware to a couple different teams We've donated money to a couple different teams We I mean, it sort of depends Yeah, sometimes it's like sponsoring hackathons It's very much a project specific thing It depends on kind of what the project needs what people need, what people want Also, it frankly depends on what resources you have on your side Some projects, for better or for worse the engineers you have on your side are super engaged with the community and really like doing hackathons and showing up For other projects, you might not have that and then maybe what you can contribute is more like that We also ask a lot of times What would you like? Any other questions? Going once Going twice Sweet, thanks guys Thank you very much This isn't yours, right? That is not mine I'll laptop away It's alrighty Good to see you Hey, it's pleasure to finally meet you It happens, it's totally cool We all have lots of work to do Are you going to be running on Tuesday? Are you going to be at the office on Tuesday? Okay, cool Awesome So you may want to go ahead and there's a Google blog that Lucas made Just throw in an hour there and be like this is the Anaconda hour I've been trying to get people to do that but only Valentina has done it for our PIM Good They're all available except one to two So grab the time that's going to work for you guys because otherwise I think what's going to end up happening is people are going to get scheduled for their own meetings and then we won't be able to do it with anybody So I'm really trying to get everyone to do the thing where they're like this is the time I will drag my team over and I think that will be really good Thanks


you say you knew it would be violating decorum rules, but did you have any idea that the backlash would be like this from your colleagues? No, we had no idea that what we were doing would break a rule that could lead to our possible expulsion or our actual expulsions. I didn't know I couldn't do that. That was good, wasn't it? Because I did know I couldn't do that. Ha, ha, ha, ha, ha, ha. Hello, welcome back viewer. Well, another day, another media narrative that it's different when Democrats do it. You may have heard of the so-called Tennessee Three. Three Democrats who were expelled from the Tennessee State Legislature for breaking rules and decorum by taking part in a Democrat insurrection that stopped Democratic proceedings. For the past few weeks, this story has been pumped out by our Democrat state media, who are, as usual, deceitfully crafting myths and theatrics straight from the movies for the purposes of propaganda to benefit the Democrats. So in this clip, we have Don Lemon and Tennessee State Rep Democrat, Gloria Johnson, who just straight up lies to cover up the truth about what actually happened at that Tennessee State Legislature right after this important free coin offer from Noble Gold. The second and third largest bank runs in history happened last month. The government is taking steps to guarantee all deposits. That means more money printing. Thousands have approached Noble Gold investments to secure their wealth with gold. Gold is the most stable asset outside of government control. Hurry and go to noblegoldinvestments.com to secure your wealth. Bag of free, five-ounce America the Beautiful Coin if you qualify, noblegoldinvestments.com. That's noblegoldinvestments.com. You can find the link to that in the description or pin comment. If you call, make sure to tell them drone tech sent you. And remember, there's always risk in investment and there are no guarantees of any kind. I wanna ask you about, you've been very upfront after the vote last week that you felt race played a role in Jones and Pearson's removal. Exactly, and it wasn't just her. Minus Fox News, all the other so-called mainstream media outlets supported that narrative with all the headlines blasting the skin color of two Democrats involved in the so-called protest. I say so-called because if this were a group of right-wing Republicans, the media would definitely be calling it an insurrection or a violent uprising. One of these Democrats, Justin Jones, has actually already been banned from the Capitol once for assaulting one of the speakers. In another incident, Justin Jones and his BLM mob had stopped traffic and then assaulted one of the drivers with the traffic cone who was trying to get away. Yeah, real upstanding civil rights hero you have there. Just it enraged them because to them, we are not equal. To them in the South, we still are separate and unequal.  Ah yes, civil rights heroes who are most known for wanting to take away your most basic constitutional rights. Unsurprisingly, this is a lie, but Don Lemon is actually about to call her out, but don't fall for it. It's just a trap so that she can then dismiss the charges and reassert the narrative by simply lying, which Don Lemon will help her to legitimize. That you felt race played a role in Jones and Pearson's removal, but there are some of your Republican colleagues who are saying the difference was in their estimation that it wasn't race, that you argued, your attorney argued to the contrary, that you never shouted a pound of the podium or displayed a sign containing political statement last week and also that you chose not to participate in a letter that their attorneys had submitted, that your attorney didn't take part in that letter that you submitted your own. Do you still believe that it was race and how do you respond to your colleagues who are saying that?  This is the most maddening part of this entire thing. Yes, you heard that correctly. She herself and her lawyer already argued that she shouldn't be removed because she didn't take part in the actions that broke the rules. Get out of my sight. She didn't break the rules, thus she wasn't punished. Do you still believe that it was race and how do you respond to your colleagues who are saying that? You know, I've been sitting in that body for a while. I hear racist statements all the time. Of course, the racism trump card. I guess she's already digging in on that hill so no turning back now that it's been exposed that you yourself and your lawyer argued that you shouldn't be punished because you didn't break the rules.  Right? Right? No, you can't. And it was just a few weeks ago that one of my colleagues in our criminal justice committee, oh, oh, we were, we had a bill. They have a bill to bring back the firing squad and the electric chair. And one of my colleagues said, I think we should bring back hanging by a tree. He literally suggested lynching. I think it's very clear. No. I'm sorry, what's racist about that? Did he say let's bring back hanging just for black people? No, he did not say that.  But the fact is such a law would include white people. Basically, this is gonna be the everything I don't wanna hear is racism defense. I think it's very clear. There have been statements in committee for years and they've made themselves clear. If you heard the questioning of those two young men compared to my questioning, you definitely heard racially tinged questions. No. What were those questions? Why aren't you telling us? Why don't you have examples? Why isn't Don Lemon asking? It's blatant, quite frankly. Representative, do those statements make it onto the local media? Would you like to see more coverage? We just did a segment. No, he doesn't ask what those questions or statements were. Instead, he asks this Democrat as she thinks the media should be producing more deceptive propaganda that's targeted at her political opponents. Hard-hitting stuff there, Don. This is yet another case of the Democrats, their state media and their voters convincing themselves that it's somehow different when they do it, when their partisan standards come back to bite them. Take a deep breath and just realize that in the end, we will win. These people aren't lying and gas-lying in the country because they're confident in the narratives that they're spreading. Thanks a lot for watching. I hope you enjoyed it. If you did, please hit that like button, share, subscribe, hit that notification bell, and make sure to leave a comment to let us all know what you think. Thanks a lot. I'll see you all in the next one.


President of the United States, accompanied by Secretary Hodel and Secretary Harrington. Thank you very much. Thank you. Please. My goodness, all these congressmen here I should have brought a gavel. Well, to get serious, this week we were all given a grim reminder of the human cost of our national security. We grieve the loss of our brave sons, but let no one doubt our resolve to protect our vital interests in the Persian Gulf or anywhere else. The Gulf is a particularly volatile area, but an area of utmost importance to us and to the free world. Our fleet has been there for almost 40 years, helping to ensure freedom of navigation and protect commerce. As difficult yet essential mission will continue. Today we import only about 5% of our petroleum from the Gulf. Western Europe and Japan have a much higher dependency. We saw in 1974 and 1979 the disastrous effects which a disruption of Gulf oil can have upon the economy of the United States and our principal trading partners. We're working to see that that experience is not repeated. Achieving this requires American military and political strength, the cooperation of our allies, as well as economic strength and independence, especially in matters concerning energy. And today I'm pleased to sign House Resolution 1941 into law. This legislation eliminates unnecessary restrictions on the use of natural gas. It promotes efficient production and development of our energy resources by returning fuel choices to the marketplace. I've long believed that our country's natural gas resources should be free from regulatory burdens that are costly and counterproductive. This bill polishes unnecessary restrictions on natural gas and petroleum markets. It also eliminates complicated natural gas pricing procedures, which distorted supply and demand and raised energy prices paid by consumers and industry. Moreover, as natural gas is a clean burning fuel, restrictions inhibiting its use have not been in the best interest of the environment. Removal of these and other regulatory obstacles will benefit our economy, energy security and environment. In my recent message to Congress on energy security, I urged several measures to ensure our nation has a strong domestic oil and gas industry and substantial protection against oil supply interruptions. These measures taken together will result in increased energy security. I have on three occasions proposed comprehensive natural gas legislation to the Congress. HR 1941, while not encompassing all that I've proposed, is a step in the right direction, a step away from bureaucratic controls and a step toward a freer and efficient marketplace. However, much remains to be done. Price decontrol and mandatory contract carriage are still needed if the great potential of our domestic energy resources is to be achieved and energy cost to consumers lowered. I would urge the Congress to move forward from here and take action on other deregulation proposals which are awaiting their action. With that said, I applaud those who have worked so hard to bring it to my desk and I will now sign the legislation.


The cry of a newborn child.  For babies born this year of 1941 will live 14 years longer than those born 25 years ago. For this triumph over disease and death, one American woman is chiefly responsible. She is Dr. S. Josephine Baker. Tonight the Cavalcade of America sponsored by Dupont, maker of better things for better living through chemistry, brings you the story of a great physician, a great humanitarian and a great citizen, Dr. Josephine Baker. On our program she will be portrayed by Agnes Morehead of the Cavalcade Players. Wednesday, August 3rd, 1901 at 21 John Street, Room 201. Civil service examinations for position of inspector, New York Department of Health. Salary, $30 per month. Open of health, isn't it? It is indeed, madam. I'm the commissioner. What can I do for you? I have a letter here from Supreme Court Justice... Okay, okay. Here's the lady, her appointment, O'Malley. Right. But don't you want to know about my qualifications? Have you a good stout pair of walking shoes? Why, yes. Then you're qualified. Give her the Hell's Kitchen district, O'Malley. That's 4 to 3rd Street to 59th and 7th Avenue to the Hudson. Right. You think you can handle all that? Well, yes, I suppose so. I'm not sure. I'm entirely clear on my duties, commissioner. As I understand it, I'm to make a detailed report on health conditions in these tenements. Well, not too detailed. Just ask the janitor of the building if there's any sick babies around. Do what you can for them. Well, commissioner, I'll do the best I can. Book agents on your way. Folks in this house can't read. I'm not a book agent. I'm the new health inspector. Yeah? I wish you'd report to Dave on the top floor for dumping garbage in a dumb way to shaft. You mean it's still there? Sure. Who's going to clean it up? Well, I thought you were the janitor of the building. Yeah. What can I do for you? Clean out that garbage. That's a good one. You think I want to catch one of them diseases? What diseases? How should I do? Listen, you don't know health's kitchen very well, do you? No, but I know something about diseases. Yeah. There's only one disease. That's brats being born in the first place. I don't think I'm going to like you very well at all. No?  I'm the new health inspector in this neighborhood. If you're looking for health, you come to the wrong neighborhood, lady. I thought I might be able to help you. Who's asking the likes of you for help? Helping people is my business. You see, I'm a doctor. You? A doctor? Yeah. But we ain't got money to spend on doctors and such. Well, you don't understand. I'm paid by the city. Oh, that's a new one on me.  That's better. Well, may I have a look at that baby? She ain't no pretty sight with them blotches all over her. Well, maybe we can do something for them. All right. Come on in. Careful, you'll step into them slops. Oh, what's it new, lady? Did you think he was coming to call on Mrs. Vanderbilt? Of course not, but I hardly know where to begin. You've let things get into such a state. You said you wanted to look at the baby. Them things is between me and my old man, and he's too drunk to care. I stopped caring when the last one died. You lost one baby? Yeah, but I ain't sorry. She's out of the stink hole anyways. Well, you're not going to lose this baby, Mrs. Latter. Listen to who's talking. Madam Fifth Avenue. My name is Dr. Baker. Now get me a clean towel and some warm water. Clean towel? In this house? To make me laugh. Before running the streets and this brat howling all day long, this gauze will do for now, I guess. Before I go, you'll wash those towels. What is it, ma'am? What's wrong with your child? I'm afraid your boy is in Syria. He'll have to go to the hospital. For me, for no hospital. That isn't important. They don't do nothing for colored folks, know how.  I'll see to it your boy gets the proper treatment, Mrs. Ingram. And the rest of you, of course, will have to have antitoxin injection. He ain't going to stick no needles into us, folks. Oh, there's no need to be afraid. Listen, ma'am. The Lord himself was scared and cried out on the cross. Who are you to tell us folks not to be afraid? Who was I to tell them not to be afraid? That was a question I couldn't answer because I was afraid myself. Afraid that there was something terribly, desperately wrong with what I was doing. So often it seemed I'd come too late to do any good. It's you. What do you come back for? Who tells you to come sneer to my house all the time? I just called to see how your little girl was getting along. My little Maria. She's a dead. Oh.  She takes it about when she's sick. She drinks it in milk. If you'd only been willing to let us take her tonsils out, Mrs. Benelli, she might have had a chance. Her whole system was being poisoned. I told you. You tellin' me. Go ahead, tellin' me.  Maybe you'd like to try now. Well, we've got another, you see. So get out. I'm sorry I spoke that way, Mrs. Benelli. I know how you must feel. You know how.   You're supposed to clean that house.  So get out, like I say.  Sometimes New York seemed to me like some monstrous charnel house, each cubicle with its little coffin and the mourners grouped around it. Their faces gaunt with the premonition of deaths yet to come. When I returned from the rounds of my squalid district, I would sit in my office long and long, studying the results of my work. Results that added up to nothing. Oh, Dr. Baker, you still here? Yes, Inspector. Come on in. I'd like to talk to you about this tenement work. You've been here for some time, haven't you? Long enough to stop worrying about those slum people, Dr. Baker. You're wasting your time. You really think so? Yes. What's more, you're making it pretty tough for the rest of us here. You realize that? I'm making things tough for you. Yes.  But that's my job. I guess you just don't know any better.  The boys? Yes. You want to keep your job, don't you, Dr. Baker? Not that badly. Well, what do you get out of it? Those people will never thank you for it.  But they don't understand. Precisely, Dr. Baker. They don't understand. And what's more, they never will. You are listening to the DuPont Cavalcade of America, presenting the story of Dr. S. Josephine Baker, the great American woman physician. Agnes Morehead is playing the role of Dr. Baker. I had failed dismally, and I knew it. I could help a few, but there were too many of them. What was the answer? I was not to know so soon. It was not long after this that an epidemic of typhoid broke out, and I was sent to a mansion on Park Avenue. Good morning. Good morning. I'm Dr. Baker of the Department of Health. Oh, it was good of you to come, Dr. Baker, but we have our own doctor. Of course, and I'm sure he's doing everything possible for your children, but I've come on other business. May I come in, please? Certainly. You'll forgive me if I seemed a little rude, but this whole experience has been rather shattering to say the least. Yes, I can understand that. But you can help us a great deal and perhaps prevent this happening to other families if you'll answer a few questions as honestly as you can. Do my best, Doctor.  Emphatically, no. And what about the servants? There were three maids in the butler. I couldn't blame them for leaving. Naturally, they were frightened, but thank heaven there's such a thing as loyalty left among some servants. Then one of them is still here. My cook, Mary Mallon. Mary Mallon. Could I talk with her? Frankly, I'd rather you didn't. She hates and fears all doctors why she even threatened to leave rather than be examined by our own doctor. Hmm. That's peculiar. Not under the circumstances.  Mm-hmm. Well, supposing we don't tell her I'm a doctor. Well, if you insist that I can assure you it will lead you to nothing, I'll ring for her. But please don't antagonize her. I don't know what we would do if she leaves, and I'll try to be as tactful as possible. You rang, Mum? Come in, Mary. This is Miss Baker. She wants to ask you a few questions. Well, be quick about it, Mum. I got a cake in the oven. Mary, was there illness in the last house where you were? What's that to you? Mary, please be civil. I'm sorry, Mum. But is it my fault if people take sick? I didn't mean to imply it was your fault, Mary, but you see, we're trying to find out what is causing this sickness. Well, what do you want me to do? I want you to come with me downtown and submit to an examination. I won't do it. If you promise me you'd keep these people away from me, Mum. I'm quitting. No, Mary, don't talk like that. Please, you can't leave me alone at a time like this. Please don't send her away. I'm quitting. Dr. Baker, I'm afraid I'll have to ask her to go. Doctor, so it's one of them doctors. Mary, I'll handle this. Go on back to the kitchen. With pleasure, Mum. You see how it is, Dr. Baker. Yes. But I've been assigned to get some samples from the laboratory tests in Mary's case. If she won't give them willingly, we shall have to take her to the hospital by force. Have you the right to do that? Mrs. Smith, if necessary, that is what we shall do. But surely just because it may have been typhoid, the last place Mary worked... It may have been typhoid everywhere Mary's worked. I've made sure of that. But she's never had typhoid. She says she can prove it. It may be possible for some people to carry typhoid bacillus and never contract the disease themselves. That's what we have to find out. Will you cooperate? Very well, Doctor. I'll do what I can. I'm back again, Mrs. Smith. Oh, come in, Dr. Baker. I told Mary... Oh, don't be alarmed. I'm sure that there won't be anything for these officers to do. Well, I hope not. Boys, maybe it would be better if Mary didn't see you at first. Sure, Doc. We understand. We'll wait around back. Call us if you need us. All right. Thanks, boys. Mary's in the kitchen. Come this way, Doctor. Were you able to reason with her at all? You saw how she is. It's a pity she feels it. Well, here's the kitchen, Doctor. Why, Mary! Don't come no closer. If you know what's good for you. Mary, put down that butcher knife. This is no way to... I'm warning you. Both of you. Don't come no closer. Mary, listen to me. I know it's hard for you. Maybe you don't even believe it, but it's true. Every time you cook for people, they'll get typhoid bacillus. It's a lie.  But you've made other people sick. Deep in your heart, you know that's true. It can't be just an accident. Remember the Harvys Mary and the Layton? It was their twin babies that died. Remember them and all the others. Every place you worked. It ain't true, I tell you. It ain't true. Yes, it is, Mary, and you know it. Now put down the knife, Mary, and come with me. You want to put me in jail. Like a criminal. And I never done nothing wrong in my life. Now you've never done anything wrong. But if you cook for people again, now that you know it, it will be wrong. It'll be a crime, Mary. Cookin' is all I know. What can I do? He'll help you to get other work, if you'll help us. He'll tell people. I'll never get to work again. I won't tell anyone if you'll help us. You better do what she says, Mary. It's a trick, I tell you. They want to put me in jail. I'll have your pictures in the paper, Mary. Typhoid, Mary Mallon, that's what they'll call you. You don't want that, do you? No. No, I'll come with you. Good. All right, officers, you can come in now. Police. Police, you lied to me. You brought the police. They're not going to take you to jail. No, I should say they ain't all the way to there. Where's she going, Dr. Baker? To that window. Take the alleyway, Casey. I don't catch her right enough. Yes, we must, but be gentle with her. She's not a criminal, you know. And what is she? She's the most tragic person I've ever known. Well, Dr. Baker, I want to congratulate you for your part in this Typhoid, Mary case. Control of these carriers will save thousands of lives. Commissioner, how would you like to save not thousands, but millions of lives every year? That suits me just fine, Dr. Baker. How do you suggest we go about it? Well, the Typhoid Mary case set me to thinking, Commissioner. Why do we wait until people are sick to pay some attention to them? Why not catch them when they're well and try to keep them that way? Mmm. Sickness among the poor starts in the cradle, Dr. Baker.  That's why I want to catch them early, the moment they're born, even before they're born. Dr. Baker, there's a child born in this city every three minutes. Every three babies born, one dies before the age of five. Mmm. Pretty discouraging, anyway, you look at it. Give me a staff of 17 nurses and one neighborhood as an experiment, Commissioner. I think we can change that. Well, I suppose we could finagle some money by juggling the items on the budget here and there. How much would it take? Very little. Give me three months. After that time, I can't show you concrete results. Then there'll be no need to go on with it. The results of that modest experiment were amazing. In the first year, 1,200 fewer children died in my experimental neighborhood than the year before, while the death rate for children in the rest of New York remained the same. Such was the beginning of the world's first bureau of child hygiene. New York City advanced from the highest death rate of any great city in the world. I like to think that I had something to do with that. It is the year 1918. In a tenement to New York's Lower East Side, two little girls are giving their baby brother his bath. Their mother looks on fascinated. Mmm. Such a beautiful sight. Regular little mothers I'm bringing into the world.  Oh, and by the school, they're teaching you to give the baby a bath, huh? Such a thing. And by whom may I ask is this big idea? By Dr. Baker. And by the doctors know about raising babies, might I ask? Have they been a mother? But, Mama, you're not getting the idea. Dr. Baker's a lady. She might be a mother under the proper conditions. Let's hope she's getting a husband soon. Okay, Rosie, get ready to tell. Now, Mama, look. You drive the baby like this. Oh. But gently like blotting paper. Not rubbing and rubbing like this. Oh. Oh. See, see, see. Making crying. Uh-huh. And what makes the baby cry is a bad condition. So don't make a bad condition. Ah, but now comes the diapers. So we'll see how they're teaching you lesson number one. Rosie, Rosie, no, no, not like that. Remember how they said the two corners together like this. And we slip it through like this. This. Oh. It's not too tight, Mama, and it's not making a bad condition. So now the baby sleeps, but with the window open. Sophie, the best I will take in the fancy diaper I will take. But the open window, the baby will catch a death of cold, so I say no never. Oh, but Mama, just this one. So why is today the best day the baby should catch pneumonia? Mama, he will catch pneumonia. And besides, we want everything to be the best today because I didn't tell you sooner, so you should wait and see what final idea she has. Dr. Baker's coming here to see us. What? And the house upside down. Important company, and she doesn't call me so I should hear about the idea of a fine thing. Mama, Mama, Mama, come on, Rosie and I are winning the prize from the little mama's club. And why? Because we say, don't mind the house, mind the children. Mmm. So I explain to you having the family already, huh? Don't for the baby. That's the name of our competition. Sophie, tell Mama about it. Oh, all right. Tell me. Well, Foy, don't give the baby herring and don't give the baby beer to drink. Yes. And don't let the baby run in the mud gutter. Don't let the baby eat dirty things in the floor that he threw down at Foy's. And don't leave the baby alone in the carriage and play with your friends. Why? He'll jump out. Mama, don't give the baby sour cucumbers and don't leave the baby sit on the stove. And don't... Oh! Oh! Oh! Come in, come in, Dr. Baker. Oh! Excuse me, please, my house is just a little upside down. I don't think it is at all. I see you have the window open. That's fine. The children should get plenty of fresh air. Just like I'm telling always to my husband, Doctor, don't go around closing the windows all the time. It makes a bad condition.  I know everything is being done for the baby in this house, Mrs. Rabinowitz. And when you're too busy, these girls of yours will make very good impressions. Yes, yes, yes. Such bright youngsters. Yes, doctor. Tell me, is all over the country such ideas nowadays? Yes. Yes, I think pretty nearly all over the country. To such simple focus these, Dr. Baker herself brought a great new idea. That children are the most important people in the world. To her profession, she brought a new science, the science of preventive health work for children. And through bureaus of child hygiene patterned on Dr. Baker's pioneering in New York slums, her ideas have spanned the civilized world. A child born in the United States this year of 1941 will live 14 years longer than one born 25 years ago. This is the gift of Sarah Josephine Baker to her countrymen. I like to stand at the corner of Fifth Avenue and 42nd Street in New York City and watch the crowds pushing and milling back and forth. But sometimes seeing more set expressions and determined faces all bent on getting somewhere at the cost of the men and women at their elbows. I've stood there and wondered, wondered deeply and been sadly perplexed. Should we bring more and more babies into this troubled world? Yet I have faith in the ultimate decency of mankind. I can still see the light in the mother's eyes when her baby was assured of health. Of course, I would do it again. At this time we bring you Dupont's weekly story of chemistry at work and our world. For centuries men looked wistfully at the fragile beauty of a spider web in the sun, sparkling and silvery as a dragon flies wing and wondered about the marvelous little mechanism with which a spider spins his thread. How did the spinneret work? It was a wonderful way to make thread. Could we learn the trick? Today, man makes and uses spinnerets. In the Dupont rayon plant at Richmond, Virginia, thousands of these man-made spinnerets are at work. You've seen pictures of old-fashioned stovepipe hats, the kind Abraham Lincoln wore. Imagine a miniature stovepipe hat the size of a dime made of an alloy of precious metals.  You have to look at them under a microscope. Although the metal is only eight-thousandths of an inch thick and although the holes are only two-thousandths of an inch across each hole is drilled out from the back to form a little funnel. Compared with tool work of such precision the mechanism of a wristwatch is as cumbersome as that of a locomotive. How do metal spinnerets make thread? In the Richmond plant they operate in a shallow bath of brownish liquid called a coagulating agent. If your eyes are good you can see something flowing out of them that might be smoke. Actually it consists of filaments of a syrupy liquid coming out of the spinneret holes. A fraction of a second later these filaments harden just as a spider's thread hardens when it touches the air. A workman called Spinner picks up the strand of filaments so fine you wonder how he can catch it between his fingers and tosses it deftly over a whirling glass wheel. At the same time with his other hand he pours some of the brownish liquid over it. The filaments whirl away over the glass wheel twisting into yarn. Man has learned the spider's age-old spinning secret. Man-made spinnerets are at work for us today. Are they as good as the spiders? Yes, better. Man's spinnerets produce a fiber that is uniform, smooth and strong. The tremendous practical future benefits of these spinnerets man's improvement on nature are only beginning to be felt in our time. But already millions of women are wearing lovely fabrics only a few could afford not long ago. And in a time of national emergency when sources of supply vary almost from day to day it's a comforting thought that Americans can have cloth made from cellulose in the case of rayon and from coal, water in the case of nylon. For nylon as well as rayon is made with a spinneret. Nor does a spinneret's job end with textiles. From nylon spinnerets we can draw materials for webbing, cordage, filters, surgical sutures, racket strings and bristles for brushes. Man has learned how nature spins. Another achievement has been chalked up by the chemists who bring us better things for better living through chemistry. Next Monday night the Cavalcade players bring you an exciting radio drama adapted from the new novel Red Lanterns on St. Michael's by Thornwell Jacobs. It is the story of the first submarine exploit in the history of the American Navy of Perry White a young Southern idealist and his effort during the Civil War to smash the federal blockade of Charleston, South Carolina. In our story of chemistry at work in our world we will tell you how cellophane cellulose film is helping to conserve and protect the nation's food. We hope you'll listen next week when DuPont again presents The Cavalcade of America. Josephine Baker was written by Robert Tallman for the Cavalcade players. The orchestra and the original musical score are under the direction of Don Voorhees. On The Cavalcade of America your announcer is Clayton Collier sending best wishes from DuPont. The work of the National Broadcasting Company.


Hi, I'm Markus and today I'm going to give you a quick overview of our battery management offer with a heavy focus on the L9963. So first of all I'd like to talk about ST Microelectronics strong engagement in the battery management market. In the field of automotive lithium-ion cell management, ST has a long history of more than 10 years. We have designed and produced several generations of balancing and monitoring solutions. We are very excited as this is the first time that we have approached the open market with a cell management solution making our IP and know how available to a broad customer base. Besides the cell management shown here today, ST is positioned to serve as a system solution provider. That means that all the relevant components in a battery management system ranging from processing, communication, load actuation, sensor acquisition can also be provided by ST. So having said that, let's focus on the target applications that ST addresses with the L9963. The cell management solution shown here today is qualified for automotive usage and designed for safety requirements up to ASIL-D. So primarily we address automotive battery systems with the highest demands for safety and analog accuracy. Target applications are battery systems in full electric and hybrid electric vehicles but also other kinds of transportation. The use cases however are not limited to automotive applications. You will find the same requirements and also the increased sensitivity regarding safety in home energy storage and various consumer and industrial applications. And then finally in terms of customer support, ST provides a wide range of resources. For cell management we are in production with a qualified device. Those samples are available today and for development purposes we support our customers with evaluation boards and GUI software. We think it's important to put ourselves in the customer's shoes and create systems similar to those they would likely need. We have an example here of a cell management system that we have put together in-house. All of these hardware and software resources allow users to create prototypes and test environments to evaluate the device and its performance. For application development we provide a detailed set of recommendations and guidelines and a documented API. Check out the 9963 website on st.com and find out more about the device and our solutions for BMS systems.


Our Prophet sallallahu alayhi sallam foretold that this Ummah would experience tribulations, genocide, and killing. In the hadith that Haqim relates in his Sahih, this nation of mine is a nation, a community that receives a special grace, a special mercy. Its punishment is in this life, earthquakes, tribulations, this was foretold. Whenever we are confused, perplexed, overwhelmed, distraught, disconsolate, we go back to the Book of Allah Ta'ala.


What's up everybody, Jason here for jazbyzcasebreak.com. 2022 hip-raid jazbyz exclusive dual case break football edition. Random teams number two just sold out. And again, 20 total boxes, two cases. Plus we have a little hitless giveaway guys. So first of all, this is a product curated with us and hip-raid. We tell them this is what we want. This price point, let's make a deal. Let's do it. So they got these cards for you guys in here as the sell sheets. Of course, there's more than just what's on the sell sheet. This is kind of just like a little preview of what to expect. And again, two cases, 10 boxes each. 32 total spots, everybody gets ran a team in the NFL. One card per box. And of course, just in time ran a season. Remember, this product should contain mostly, if not all, autographs. The hitless promo that we have is for customers that unfortunately go hitless. Don't worry, you'll still have a chance to win something. We'll take all the hitless names, randomize them, and the top two each win, the tops Trevor Lawrence boxes ship sealed from 2021. So here's the dice roll, here's the customer names. Mack, down to Tony. We got Cardinals, down to the commanders. And here we go, roll it. Three and a six, nine times. One, two, three, four, five, six, seven, eight. And ninth and final time, three and a six, nine times. David, down to Robert. Three, six, nine, one, two, three, four, five, six, seven, eight. Ninth and final time. Boom. Broncos, down to the Steelers. All right, again, guys. Oh, we got it. We got it. We got it. We got it. We got it. All right, again, guys. I'll give you guys a little trade with it right now.  David with the Broncos, Logan with the Colts, Brennan with the Bangles, Ben with the Saints, James, you have the Chiefs, Victor, Vikings, Ryan, Chargers, Brody, Packers, Jeff, Raiders, Tony, my Eagles, Phillip, Bucks. I was just thinking of that song right now when I said that to you. Andy with the 49ers, Oliver with the Lions. Andy again with the Cowboys, Victor with the Jets. Jeff Ann with the Panthers. Sean Healy with the Giants. James with the Voggans, Victor with the Rams. Robert with the Titans. Kevin with the Seahawks. David with the Ravens. Kevin with the Dolphins. Stewart with the Bills. David with the Jaguars. Chad B with the Bears. Danny with the Commanders. Guy with the Texans. Travis with the Browns. Mike with the Cardinals as well as the Patriots. And Robert with the Steelers. Dude, I've seen the Ying-Yang Twins live. I went to one of the Millennium Tours last year. Goddamn. They were so hype. I was just, my wife was just making sure I wasn't just looking around me. What everybody's shaking everywhere.  William with Skybox Metal Universe. Spot Elite. They don't tour on their own. Gilo, they were touring with that Millennium Tour, the Millennium Tour that I went to go see. The main feature was like, it was like a marion with B2K. I don't know if you remember them, you know, R&B. Then, like I seen Mario, I seen Lloyd. I seen Ying-Yang Twins. I seen Pretty Ricky. They were pretty wild too. Pretty Ricky was pretty wild. Who else did I see? Did I say Mario already? I think I said Mario already. It was just like a whole, it was just like a whole set list. And then my wife just went to the most recent one with my sister like two, three weeks ago. That one was almost the same amount of people. Almost the same people, but that one was featuring a Shaunty and Ja Rule. So, that one, I mean they went for a Shaunty because, you know, my wife and my sister love Shaunty. But it was a pretty cool, it was a pretty cool little thing right there. That was awesome. So, Randall got three. Shaunty with two. And Jeff got eight of them. Holy schnikes. This mixer is happening guys. Four, five, six, seven, eight. Woo! Twelve left. Yeah, Jamie, my sister, my sister is the one that kind of like loved V2K. I started obviously liking them because of her. She'd be bumping them all the time. But it was a cool experience. Like I said, it was a pretty fun concert.  Alright, sorry guys, I have to go get the case until I forgot. And let me know if anybody does complete a trade, guys. Please let me know in the chat. Yes, confirm. You know, that way I know it's a trade. Confirm Colts for Texans? Let's just do that one then. Looks like Jamie's gonna pass on that. So Colts for Texans. Here we go. So Logan. Oh, you guys are just right here next to each other. Um, Stu, this is the, uh, Jasper's Hit Parade exclusive. I also believe you're in this. You have the Buffalo Bills. I'm about to start. We just had one quick trade. Um, the last filler for the mixer is up and we're down to 12 left. Once that sells out, we'll do the mixer filler. We'll do the giveaway for people that bought full spots in the main mixer and then the mixer will be breaking. If we could sell this out by the end of this break, I'll probably do the filler by, like, 9-ish, 9, 15, 9, 30. Fill it really quick, 5, 10 minutes. Do the giveaway. And I'll probably be starting the mixer no later than, like, 10. Maybe 9, 45, 10 Pacific. So if you're in the Eastern time zone, you know, 1 a.m., 12, 45 or so. Alright. So let's do this Hit Parade. And again, guys, this is a, uh, remember, too, guys, this is, uh, Hit List promo too. So review that go Hit List. I'm gonna make sure I get all of them in here.  But if you do hit, if you don't hit anything, you'll be part of the giveaway. One trade, guys. Logging on how to text this guy has the cults. Alright, here we go, guys. And we have a Marshall Fulk for the Rams Flashback, Prison Flashback autographs. That's a 37 out of 49. That is Rams. Going to, uh, Victor Zamora. Ooh, my boy Devante Smith. Fly goes fly. That is a variation, 20 of 20 orange. Uh, for the Eagles. Going to Tony. Last Bob Mojo. And when you have an eagle, you gotta have a stealer, right? TJ Watt. Signature Highlights. Uh, looks like it's not numbered, but a nice hit there for the stealers. Going to Robert. We have a Rashad Bateman Prism Rookie Autograph. That is for the Baltimore Ravens. Going to David Lee. We have a Ron Dale Moore Rookie of the Year for the Cardinals to 99.  I actually haven't been taking out the hits. So let me see. Cardinals. We got Ravens. Stealers. Amonra for the Detroit Lions. That's a rookie ticket. Lions has gone to Oliver. Yeah, I think he's going to have a good season. Hopefully, you know, for my fantasy purpose, I kind of want him to have a good game against the Eagles, but you know, me being an Eagles fan, I don't want that. But I guess that's the consolation, is that if he has a great game, well, it benefits me. Elijah Moore, 19 out of 99 for the Jets. Victor with that one. Nice Kyle Pitts. He doesn't really sign much, guys. Three color patches is rare. An autograph for Spectra Football. That is a 15 out of 35. And that's going to go to the Atlanta Falcons and Jimmy. There you go. Pitts is the sell sheet case hit. Nice. I think he's going to have a monster year too, Amarillo. Amarillo loves his tight ends, man. And Pitts is not just your ordinary tight end as well. All right. Christian McCaffrey, little rookie patch autograph from Origins. Hopefully, he can stay healthy. That is a Panthers win to Jeff. My name, Jeff. And last box here. Get back, win two out of three leagues, get tomorrow, hoping you score just another win. I know, right? Oh, you're ready to shine. That's right, huh? I think it's going to be rockin', dude. Did you see, though, T-Ball? I was talking about it the last couple of days, but make sure to buy beer before the third quarter, because I think once the third quarter starts, half-time's over, they're not selling any more beer tomorrow. Traylon Burks. That is a legacy patch autograph, numbered at 25. And I believe Traylon Burks wasn't dropped at two again. Titans, that's right. Robert. Yeah, that's what I was going to say. As long as you tailgate, as long as your little buzz going in there, you're fine, but for the people that are not going to tailgate, they better drink as much as they can in the first half. So I don't know. It's going to be interesting how that goes. All right. First case done. Titans, Robert. Adam Camaro. That's a rookie ticket. Number to 75. Saints on the board. That's going to Ben. Another Traylon Burks. Another one there for the Titans at 249. That's our first repeat team. Robert. We have a Cortland Sutton rookie ticket for contenders to 99. Must be like the retro. I don't remember seeing that one. Denver Broncos. David with that one. We have a Cadarius Tony playoff ticket playoff to 99. That's for the Giants and Sean. All right guys. Six more boxes. And how about a Deandre Swift little raider rookie from Donner's football. That is for the Detroit Lions and Oliver. Very nice. I have them also on my fantasy team in one league. And Ezekiel Elliott for the Cowboys. Going to Andy. That is a black gold sizable signatures. RPA to 225. Nice. Black Gold is a fun product too. All right. Four more guys. Four more. I bought another Davante Smith pen pals. Fly Eagles Fly. Couple repeat teams now in this case. Eagles going to Tony. All right guys. Three more. We have Ramondri Stevenson in 99. Patriots going to Mack. How about a Trevor Lawrence? I think this was the sell sheet hit I believe. David with the Jaguars. 54 out of 100. Teelo. Boom. And last box Mojo. Damian Pearson. That is a rookie for the Houston Texans. 73 out of 199. He's a starting running back for the Houston Texans guys as a rookie. And that is going to go to the Houston Texans and Logan. Trade Mojo. Working out for you buddy. And there you go folks. That was the break. So let me just double check all the teams that I pulled out here are not there anymore. So Texas took out. Jaguars took out. Patriots took out. Eagles. Cowboys. Lions. Giants. Broncos. Titans. Saints. All right. Then we've got Titans again. Panthers. A lot of Falcons. Jets. Troy Lyons again. Ravens. Arizona Cardinals. Steelers. Eagles. That's perfect. Alrighty. Now we're going to take these customer names here. I'm going to separate sheet here. We're going to go pitless. And only these customers here will have a chance of course to win back some, win back something of course. So let's quickly do that. So 15. So pretty much half the customers did get a hit. Other half unfortunately. And again top two get a Trevor Lawrence box. Here we go. Roll. Five into one. Six times. Good luck. One. Two. Three. Four. Five. Six. And boom. Six. Five. One. Kevin M. And Kevin Wilson. The Kevin's are going to get a box of tealot tops. So there you go. There you go. Appreciate it guys. Another one should be in the store if it isn't already. If not I'll post it up. We are trying to sell out this mixer. And whoa. It sold out. So coming up next is the filler. And then the mixer. Stay tuned guys.


I work for the Chief Economy team and what we do, we provide economic support on cases, on mergers, antitrust and state dates. So I analyze the data and I give my advice to the case teams. I think the best part of my work is that I find it very meaningful. It matters and because of that I'm passionate about it. I think it's important for European consumers to make sure there's competition in the market and so to contribute to that is very valuable to me. I could mention two main ones, quantitative skills, data analysis is something I use every day and we had great practical classes at TSC and secondly, qualitative so I had great access to all the theory which is held in the professors of TSC and it's been great. I think TSC, Na1, MyCV is excellent to the extent that sometimes when I tell people I'm from TSC we have such high expectations that I'm not even sure I'll be able to fulfill them so I couldn't recommend more.