George Bruno with the 21 Report at the 21 Convention's Patriarch Edition, our first one 2019. And I'm talking with Bobby Dino. Welcome. Hey George, thanks for having me. Absolutely. How is the convention going for you so far? This is amazing. I didn't have, I'd been told what the convention was about and I'd seen things online and when I started writing and started getting notice for my writing, I really wanted to be involved with it just because I totally value the idea of the progression of men. That being said, I had no idea how awesome and what a great, fantastic thing Anthony Johnson has put together here. You can't really get a grasp on it until you see it.  It's incredible. I'm just, I'm really glad to be here. Yeah, yeah. You're making a difference in guys' lives, whether you know it or not, with every tweet, everything you say, everything you write, every time you show up on stage, you're going to, I always tell guys that you never know what you're going to say, how it's going to affect somebody inside and spark something inside of them that's going to make them unrecognizable a year from now. Somebody might hear you speak on stage and you'll see them a year later and they might be 50 pounds lighter because you somehow encourage them, spark something inside of them where they start hitting the gym or somebody was on a depressive track and living in despair and you gave him new meaning, but you never know that those things are happening outside of our sight and we only see them maybe a year later or once a year at conventions like this. Yeah, interesting thing with this, when I started doing my writing and it really started blowing up to where it was just being read everywhere. When you have a website, you can see where people are downloading stuff and I mean, there were countries I didn't even know existed that people were reading, right? And I started getting these DMs and they were coming from literally all over the world. I went to Dubai, I'd get them from Russia and they were these questions mostly from young men that could identify with the fact of my back story of my father passing away before I was born and not having a dad, they identified with that factor and they would ask me, how do I be a man? How do I do this? How do I do that? And a lot of this stuff really made me like stop and kind of really think where I was at because I had taken all these things for granted. These were just things that I just do. And now I'm asking how do you do? How do I get that vibe or that energy to where nobody wants to mess with me? How do I get quick getting picked on? So as you're saying with not seeing results until maybe a year later, so you talk to these guys and they get back at you. Some of them get back at you. Some of them are just whatever, you know. And you'll hear these progress stories, oh hey, it's great, I'm doing this now. And yeah, I did what you said about leaving that toxic environment and doing this and it's so much better. And it's surreal. Because hey, most of these people you're helping if it's on social media, you're not right there with them. So they're telling you this and it's like, wow, so some guy in the UAE, I just helped him have a better life. That's incredible that we can do that. Yeah. What kind of things do you write about? So my background is from 2000 to 2010 I was incarcerated in California, California state prison system. I went in as this kid that was just without a father. My grandparents were trying to do the best they could to raise me, but they were old. And I was this kid that was always trying to pull the wool over their eyes, right? And I bumped my head off a lot of things, so to speak. I was like a pinball, you know, just constantly. And I ended up getting in some trouble. While I got in a fight with somebody, unfortunately, during that altercation, an innocent bystander got hurt. So now I've just messed up somebody's life that has nothing to do with what was going on. And so I paid the price for it. I went while I was in there, I was still dumb, picked up more time.  Like I'm not going to get out. If I keep thinking that I need to be part of this clique, like everything in prison is very racial. So if I need to be part of this group and do what they say, and that's essentially my life that's going down the toilet. So about halfway through, I had to tell those guys at a very serious risk of personal injury or death that I wasn't going to be part of their group anymore. I did. I was on my own at that point. And I started planning my life. So when I came home, I had the mindset that I was going to be successful. But I also had the mindset that I didn't want anyone to know where I was at. So I would tell my wife, don't tell anyone. Even my daughter knew. My daughter is eight now. But even as she was younger, she knew, don't say prison, don't say where daddy was. And then I was counseled by some mentors that if you really want to embrace who you are and really want to move forward and help people, you need to embrace everything from your past. So I started at the behest of my wife. She said, it might be good for you to write down some of these stories you've told me about what happens in there, right? No, you're a great writer.  Do it. Write it down. Oh, OK. So I wrote it. And then she said, maybe you release them. Let people see them. I said, OK, we'll try it, right? And that very first post that I released on social media, I even wrote something along with it like, I'm going to probably lose all my followers right now. But here you go. The exact opposite happened. Ed Latimore retweeted it, Alexander Cortez retweeted it, Ivan Throne, all these different people just started. This is the group. I can't believe what I'm reading. And it blew up in September of last year. I had 120 followers and I have about 8000 now. I mean, it just, yeah, it just, it was crazy. So people, I know that there's an entertainment value to the story. People like, you know, the true crime and the prison type stuff. But in each one of these, there's some kind of lesson. And there are people that get it and they appreciate that. And that's who I'm reaching out to is that you don't have to bump your head up against things and possibly even be incarcerated. You can learn from what you read and stay away. How did you get involved with 21? So that's interesting because I was very interested in 21. Like when I first came on to the social media scene and saw what was going on there, I thought, wow, that's really great. That's something that's excellent. But I didn't think seeing what the other speakers, what they did and who they were and their history and the organization and all that. I didn't really think that that was something that was going to happen. I haven't thrown who's become a great friend of mine, someone I talk to and text with every day. He was saying, you have to go to this. You have to go to this. One day I get a DM from Anthony Johnson saying, hey, there's a few people that are telling me that you should come and speak at this convention. Would you come? Absolutely. It was just out of the, it was one of those things to where it just manifested. Yeah. Yeah. And boy, am I glad that it did. Yeah. Yeah. So as far as your experience here now with the Patriarch edition of the 21 convention, how do you feel you fit in? It's interesting because I'm pretty sure there's not anybody here with my back story or at least not anybody that's speaking that has had the same kind of situation. But that being said, I feel that I fit in as a man that's trying to help other men. I feel that while we all have our strengths, like you're talking about your trade as a barber, my trade, when I came home, I was a mill ride. I worked in oil refineries. But we have these strengths that we come with or these trades or skills. But it's all this whole that's being filled by men who are helping other men. I feel, I felt nothing but just a welcomeness and love from everyone.  How does a man start life over again? How do you do that? I feel, obviously, one is very more honorable than the other, but I feel that life in the military and life in prison is very similar for what you're saying. You have somebody telling you when to do this and when to do that and when to eat. However, one is very honorable to get into and the other one, you have to do something bad to get there. So automatically, you kind of have two different mindsets right off the bat. I feel that the best way for someone to start over is to assess what they want to be, essentially taking responsibility for their or accountability for their lives and saying, what I'm doing now isn't working. I want to be here, however I'm here. And I think that you need to make a plan and not a wish list. People I think get plans and wish lists messed up. I want to be a race car driver. Okay, well that's a wish. That's there's no plan there. How are you going to get to that? If you're able to do that and you're coming from a mindset of accountability to where I need to be accountable for my actions and for what's going to happen in my life and you make a plan, you can come back from it. One of the saddest misconceptions and one of the reasons why the institutional recidivism rate is so high sits at about 67% right now, which means essentially three people get out to go back. One of the reasons why it sits that high is because these men, and I know from experience because I was told the same thing, they think that there are no opportunities for them when they come home, none. Your parole officer is going to try and get you messed up and thrown back in prison. No job will hire you.  While some people may have experienced those type of things, that is not what it has to be. I believe largely that you create your own reality, you're in charge of your own destiny. I believe that if you have a plan and follow through with your plan that you will manifest. And I believe that anyone can do that, prisoner, anybody. Give some hope to the guy who's made some mistakes and might even need a third chance. Not just a second chance, but a third chance. Talk to him. If you are incarcerated, if you know somebody that's incarcerated, the best thing to do is realize that hope is not lost. The institutions are places largely of despair. There's no hope.  The real world, you don't need to do that. You're living in a bubble and that's what you experience in that bubble. The reality is that if you accept responsibility for your actions, take accountability and then commit to a plan, you will manifest that plan. While you're thinking, oh, the parole officers, oh, this or that, when people see that you're doing good, they usually want to help. They usually want to continue, they like seeing that. People like seeing other people make it. For the most part, you might have some haters, but for the most part, people like seeing people make it. If you commit and follow through with your plan, you will most likely have a lot of people behind you and you will experience success. I did it. I did it because I accepted responsibility. Everything was my fault, good and bad and I committed to making my life a positive force and it's happened. I'm sitting here with the man, with George Bruno right now. It can be done. I'm proof. That's good. Let's talk about the shaved head. The one that's just dripping. When did you start shaving your head? So it was kind of interesting. I'm originally from Orange County and growing up, I was in rock bands and I like to go to the beach so I kind of had this long hair. When I went into the institution, probably from stress, all of a sudden it started coming out of the back and one day this guy giving me a hard time, he says, hey, why are you growing your hair so long when you got a bald spot in the back? I said, I don't have a bald spot. Yeah, you do go look in the mirror.  And once I saw that, I just went into my mind to where I said, I'm not going to be some bald looking like a monk. So I started shaving it then and just didn't stop. Nowadays I shouldn't say shave, I use an electric razor, I'm a little bit more 21st century. It's just one of those things to where it was probably more out of vanity than anything else. It works. Well, thank you. It works. Okay, or every couple days? Every couple days. Okay. Yeah. Okay. And then how long have you had the beard? Beards a new development. So my wife and my daughter, they've both told me, we like you with the stubble, right? So I said, okay, I'll have some stubble. And then they said, you should try a beard. I said, ah, I don't want a beard. My grandfather was a Marine Corps officer and he was very, I couldn't have any facial hair growing up. I was hippy stuff. So that's always been in my mind to where I've just always been clean-shaven. And if I did have stubble, it was because I was being lazy. They had convinced me, oh, you should do it. It looks good. Okay. I started growing it out and all of a sudden I'm getting comments from everybody. Hey, nice beard. Nice beard. Oh, that looks good.  It's a good combination. The shaved head and the groomed beard that just kind of fades up like that. I mean, it's just, it's a nice look. It works. Well, thank you. Absolutely. Oh, we're getting some good thunder. This is really good thunder. God agrees. So what is the future for Bobby Dino? So the future now, I'm continuing to write. If you go to bobbydino.com, I have a blog there to where you can read a lot of these prison articles and read these stories. I've also just incorporated a nonprofit in California for at risk youth and young and recently released youth and young adults. And it's to help them do what we're talking about. Show them that there are options. If they want to do continuing education, they can do that vocation. Some people aren't meant for school. We need welders. We need plumbers. There's grants that are going to be offered to help with education as well. So while I've been writing, I've always, from when I've been in there and saw what happened with a lot of those young kids, this has been on my heart since I've been in prison that I wanted to do something when I came home. So this has taken up so much of my time and a lot of my money, too, because, you know, lawyers and accountants don't work for free and you use those when you're making a nonprofit. But that being said, it's something that's on my heart and that's what we're going to work towards. Excellent. Great to get to know you. I was looking forward to it. I know. Me, too. And this is fun. I think there's a future for you. Well, thank you. I appreciate that. I appreciate that, George. Thank you. Pleasure. Thank you.


Okay, so this is module 3, just like before, it's Creative Commons Share Share Like. We're going to cover the next topic in the workflow, which is expression and differential expression. So the learning objectives for this module are to just introduce you to the concept of expression estimation for known genes and transcripts. We're going to talk about the terminology and definitions around FPKM and talk about how that differs from using rock counts. We're going to briefly talk about some differential expression methods and very, very briefly the downstream interpretation of expression and differential expression. So you guys have already sort of maybe started doing this in your mind, looking in IGV at the alignments that you made yesterday, where basically you have at this time showing an IGV view, you have each of your reads aligned to some part of the genome, and since this is RNA-seq data, we were seeing generally quite nice alignments to the expected transcribed portions of genes. And some of the things you can see immediately from those coverage plots, remember this top row here, gives you a kind of histogram estimate of the number of alignments, number of reads at any given position. From that, you could already start to get the idea of expression and differential expression levels, right? If you saw basically a lot more reads piling up in the tumor than the normal, you might say that this gene is up-regulated or down-regulated. I guess in this case the tumor is on the bottom. You can also see things like, in this case, 3' end bias, right? So the coverage is really low at the 5' end and it's kind of increasing and highest at the 3' end. And this is quite commonly observed for polyase selected libraries where maybe your RNA is a bit degraded and fragmented. So really the whole purpose of this module is to formalize the prediction of expression levels and differential expression along the same kind of concepts as what you're doing in your brain by just looking at the numbers of alignments for one condition versus another condition. And probably the most common way that this is done is by calculating an FPKM or RPKM value. These are basically the same concept, highly related terms. They stand for either reads per kilobase of transcript per million mapped reads or fragments per kilobase of transcript per million mapped reads. And the distinction between fragments and reads, pretty much everyone refers to FPKM now. In the early days before you had paired-end reads, each fragment of RNA that was sequenced was represented by just a single read and so you could say, okay, let's calculate reads per kilobase. But then you had two reads per fragment. So it was a little bit ambiguous what you meant when you said reads per kilobase per million. So we changed the terminology to say fragments because the two reads are measuring the same single fragment. In RNA-seq, the relative expression of a transcript is hopefully proportional to the number of CDNA fragments that originate from it. But there are, of course, some biases that you have to take into account. So the number of fragments is going to be biased towards larger genes. So the bigger your gene is, the more pieces it's going to fragment into when you're constructing your library and the more chances that a fragment will randomly come from that big gene versus a small gene, just because there's more space from which fragments can occur. So you need to take into account gene size, especially when you're comparing expression-level estimates between genes. So a large gene and a small gene might have the same number of transcripts per cell, but you will get more fragments from the large gene because there's more RNA to fragment and to get sequence reads off of. So you need to account for that. The other thing you need to account for is the total number of fragments in the library. So if you have two libraries from, let's say, even biological or technical replicates, and you do one lane of sequencing data for one of the replicates and four lanes of sequencing for the other replicates, for any given gene or transcript, you're going to have a lot more reads or fragments coming from just in absolute terms, the library that you sequenced four times as much, right? And there's always this kind of variability in how much sequence data you get, even if you try to make it as similar as possible and just do one lane each and the cluster density is very similar and so on, you're still going to have some just variability in the total output of the data from that lane. And that doesn't have anything to do with the amount of transcript copies in the cell.  So you need to account for that library depth. And the FPKM or RPKM, that's basically what it's trying to do. It's trying to normalize for the size of the gene and the size or total depth of the library in all in one go. And it's just a simple formula for how it does that. It takes the number of mappable reads or fragments for a given feature, which could be a gene or a transcript or an exon, and it multiplies that by 10 to the 9, which is the thousand times the million, and divides by the total number of mappable reads in the library times the number of base pairs in the gene transcript or exon. So that's how you calculate an FPKM. There are some good BioStar posts on this topic if you want to read more about FPKM. It's arbitrary. We just decided to normalize to an imaginary gene of 1000 bases and an imaginary library of 1 million reads. And so 1000 times 1 million is 10 to the 9. It could have been FPKB for fragments per thousand bases of transcript per billion read library. It's just a choice that was made. It's not important. You could use something else. It's just a convention. So how does cufflinks work? Cufflinks is a very sophisticated piece of software. It has very complex statistical models built into it. It is not a straightforward thing to explain in one slide, but that's what we're going to do. Just conceptually, the way it works is you have your top hat aligned reads, right? So your paired end reads have been aligned to various places of the genome, and you may or may not have known transcripts to map or align those two. And what happens is sort of overlapping fragments are kind of bundled together and assembled. And then these assembled bundles of fragments are connected in an overlap graph. And what it tries to do is find the minimal number of paths required to cover this graph that's created. You have to read about like graph theory to understand the details of that. But it basically tries to infer, it looks at sort of mutually incompatible fragments, which result in different paths through this graph, and then it tries to infer the minimum number of different isoforms that would explain that graph. And so in this toy example, you're getting, for example, these three transcripts, where you've kind of got like X on one and two or one and three with a skip over X on two. Another isoform that's including all three, and then one that's basically reading through the whole region. So it tries to estimate all these or infer all these possibilities from the sum of all the different fragments that align to a particular locus. And then the abundance of each of those inferred isoforms is estimated with a maximum likelihood probabilistic model, which tries to make use of information like things like the fragments length distribution and other details. So it basically tries to assign each of the fragments to one or more of these different isoforms that it's inferred from the data itself. So the good thing about this is that it doesn't necessarily need to know what the transcripts are. It's basically determining the transcript structure, the different isoforms from your data. You can then map that back to known transcripts. And that's what we're going to do today using the reference only mode of running cufflinks. Does it accept a known transcripts as it arguments? Yeah, pretty much. And that's the way that we're going to run it today. There's actually a really good, pretty good overview. If you go to this link, I just added it recently. So it might not be in your printouts, but it's on the version on the Wiki or if it isn't, I'll put it there. Or you can just search for cufflinks, how it works, and you'll find it. And this is created by the creators and they try to explain briefly each of the different components of cufflinks and how it works. And they link you to all of the papers. There's probably about five or six different papers that they recommend that you read in order to really understand what cufflinks is doing. But they do a nice job, like kind of an educational overview and review and giving you the key papers that you should read. Same kind of thing with cuff diff. It's fairly sophisticated. Maybe it's not quite as complicated as cufflinks. But what it does is try to determine the variability and fragment count for each gene or transcript across replicates. So the fragment count for each isoform is estimated in each replicates as described in the last slide. And then there's a measure of uncertainty that's determined that arises from the ambiguity of read mapping. So in simple terms, transcripts with more shared exons and fewer uniquely assigned fragments will have more uncertainty. And I think it's easier to understand that if you just think about like a simple example, right? Where with a lot of genes, pretty much all genes are alternatively expressed, right? There's more than one transcript for almost every gene. And you can see how if you have like big differences between genes, let's do a skip. There's going to be certain features, certain reads like, for example, reads that map across this junction that uniquely differentiate this transcript from that transcript, right? The more similar the transcripts are, or the different isoforms are for a particular gene, the harder it is to know like these reads here, right? We have no idea if they're coming from this isoform or from this isoform, any reads that align in these shared regions. When you have genes that have lots and lots of similarity and only a few subtle differences, the individual isoform level estimates of expression have more uncertainty in them. So the more unique features there are that differentiate between the different isoforms, the more certainty you have. And COFTIF tries to estimate that uncertainty. And it combines the uncertainty from mapping ambiguity with the variability that you observe across your replicates to come up with a kind of total measure of uncertainty or variance for each expression estimate. And then that's modeled in the statistic to determine statistical significance. So if you're comparing a set of 10 normals and 10 tumors, it's going to take into account the uncertainty in the estimates and the variability within the conditions to determine whether a certain full change difference between those two conditions is significant or not. So we're going to run in this tutorial today cufflinks, COFTIF, and cuffmerge. So we just have a quick slide talking about why cuffmerge is necessary. The reason for cuffmerge is that you have this assembly process that cufflinks is doing, right? It's not just mapping fragments, reads to known isoforms. It's trying to infer the isoforms from the data. Even if you give it a GTF file and you're guiding it, it still goes through this process of trying to say, based on the data, based on this RNA-seq data, I think there's a transcript that looks like this. I think there's a transcript that looks like that. The problem is when you then run it on two different samples, it doesn't come up with exactly the same set of possible transcripts, right? The data is different, even if you were doing technical replicates just because of random variability in the reads. There might be subtle or slight differences between the transcripts that are inferred in one sample versus another. So when you go to do differential expression, you don't have an apples-to-apples comparison. You're not able to directly compare them until you run cuffmerge, which basically goes through all of the different samples that you've run cufflinks on and comes up with one common representation. So it basically merges together the different assemblies to come up with one consistent assembly of the different isoforms and then reassigns expression estimates across all the samples. So the simplest example of how this would work would be, let's say in sample one, cufflinks inferred these two isoforms because it had reads supporting these axons as well as some supporting these junctions. And then in another sample, maybe this isoform wasn't expressed. Maybe it's just the top isoform that was detected. And there were no reads sort of supporting this junction, so it didn't infer that isoform. When you run cuffmerge, it'll say, okay, in all the samples, these two isoforms exist. So I'm going to assign a value to this isoform in this sample and this isoform in this sample and I have, I'm going to say this isoform in the sample is the same as this one. This one's missing, but I'm going to assume that it also could possibly exist and maybe I'll assign it a value of zero. It's not there, but in the data file, it will now have a value. So then when you're doing differential expression, it'll say, okay, as a value of zero here and something there, maybe this is an upregulated isoform. So that's why you need cuffmerge. It also does some filtering steps. Again, at this stage, you can provide a reference GTF to merge these novel or inferred isoforms with known isoforms from ensemble or UCSC or something like that. And it makes a final GTF file that you can use with cuffdiff. So once you run cufflinks, cuffmerge, and cuffdiff, you're basically at the stage where you want to summarize and explore and interpret the data. And they've provided an R package to help you do this. It's supposed to be, I don't want to say it's that user-friendly because it's quite complicated, but it's a way to get you to very fairly sophisticated representations of your data really quickly. If it works, you can basically take your cuffdiff object, feed it into Cumberbund and cut out all these different kinds of visualizations and plots. You get distribution plots, correlation plots, MA plots, clustering, heat maps. And I've shown a few examples here. And we're going to run through this, so you're going to get a file that has all these kinds of plots for the data you've been working with. You can get like your typical sort of heat map where you're showing the expression level of genes in maybe your tumor versus your normal. You can look at expression changes on a per isoform level. So these are four different isoforms for the same gene. You can also get representations of the isoforms that were predicted by cufflinks. Compare those to known isoforms from Ensemble. Look at other tracks, like conservation tracks. So you can do a lot of useful stuff with that. Well, sometimes there are issues with like usually that when I've had problems it's version compatibility issues where like you've upgraded your cuffdiff software and not your Cumberbund software. There can be, and then you point, you try and import your cuffdiff object and it throws a bunch of errors because it didn't understand it. It tends, in my experience, tends to be sort of all or nothing. It usually works, and if you have a problem, it's usually something like that, like an incompatibility between the software you run.  And now Cumberbund is newer or older than the cuffdiff. Yeah, you can have sometimes issues. So in the course materials, we kind of provide two parallel paths to get representations like these. Not all of them, but they're highly overlapping. One we've called the kind of old school R tutorial, which is just using core functions or popular functions in R to produce these kind of plots. It has nothing to do with the tuxedo suite or cufflinks. It's just regular R. And then the other is Cumberbund. So I don't know which one we'll go through today. There's sort of advantages and disadvantages to both, but we'll go through one of them and you guys can go through the other one on your own time and you can kind of see there's going to be like two or three different ways to produce these kind of plots. And if you find Cumberbund is just too confusing or too black box-like, and you want to kind of create plots more from the ground up, the supplementary R old school R tutorial is probably a better starting point. It's sort of, no matter what you do, you find that there's something about a plot you want to change. And I usually find it's easier to tweak plots that I've created from the ground up as opposed to Cumberbund ones where I don't know all the idiosyncrasies of how they created these plots. So there are alternatives to FPCAM. It's probably the most common way of representing expression values for RNA-seq data, but the next most common would be to use the raw read counts. And this is very popular in the use just for differential expression analysis specifically. So instead of calculating FPCAMs, you just assign each reader fragment to some definition of genes or transcripts and determine the raw counts. So like in these examples here, we would literally just say I have this definition of an isoform and I'm going to count up the reads that I see aligning to that isoform. And there are different parameters you can use to deal with these issues where the reads could be counted towards one or another isoform. At the gene level, you would kind of just collapse this into one representation of the gene and you would just count up all the reads that align to that gene locus. And you would have like a raw count like 1,522 reads aligned to this gene locus. And then you can use statistics that are specifically designed to work with raw counts to determine differential expression between your different conditions. So the software that we're going to use to do that is called HTC Count. There are others. We're going to go through how to run it in the modules. There are some caveats to doing transcript analysis. Basically it's kind of tricky or not that advised. The author of the tool himself doesn't really guarantee the best results at the transcript level. So we personally use this mostly for gene expression level differential expression. But you can read the debate on transcript level used. So which should I use? FBKM versus raw counts. We tend to use both side by side and for different purposes. If you want to benefit or leverage the benefits of the tuxedo suite like the Novo assembly of transcripts and the sort of general ease of use of running the software and Cumberbund visualizations and all those kind of things, then you probably go with FBKM estimates. FBKM values are good for visualization. It's tricky to visualize with raw read counts. As soon as you start to think about it or use them, you tend to sort of create some version of an FBKM value because of the reasons we discuss. The raw counts don't take into consideration things like the total library depth and the size of genes. So as soon as you start comparing one gene to another, you're going to mislead yourself if you're not accounting for gene size and so on. So for creating visualizations, calculating fold changes, that sort of thing typically would use FBKM. But just in terms of wanting to have robust statistical methods for differential expression, the raw count methods are very popular. Those software packages that do differential statistics on raw counts tend to have sort of more sophisticated options for specifying experimental designs. So if you have like a complicated experimental study that maybe has like, I don't know, a multi-factorial design or a time series or something like that, you might find that some of the differential expression software in R for count-based methods work better for you. So I've just listed a couple of the more popular DC. There's also DAGSEEK, EDJAR. There's others that use these count-based differential expression. I think it was actually the authors of CUFDIF that produced this figure to show that their recent version of the software CUFDIF2 produced differential expression predictions. So the numbers shown are just the number of differentially expressed genes that were predicted to be significant in a particular study. And they're highly overlapping, but there are significant non-overlapping as well. So there's some that are unique to CUFDIF, some that were unique to EDJAR, and actually quite a large number that were unique to DCK and a pretty good overlap. So I think you can argue that if you really don't want to miss anything, if you want to catch every potential differentially expressed gene or feature, and then you're going to go and validate those at biological level, there may be a union of more than one method may be advisable. So that's what we typically do. Just a few reminders that just because RNA-seq data is such an awesome technology, it doesn't absolve us from some of the basic facts of statistics and experimental design. You would never be able to tell that reading the RNA-seq papers from the last five years. But it's true. You still have biological variability that you need to account for. So it's expensive, I get it. You know, RNA-seq was very exciting, but too expensive. So in the early days, there were literally papers published comparing one RNA-seq library to another RNA-seq library for two conditions. So you have, right, N of 1. Statistics are impossible, and though you do see people calculating some kinds of statistics in those situations, but they're not really valid. So there are tools now, like these guys have created a tool called Scotty that helps you do a power analysis for your RNA-seq experiments to try and get a sense of how many replicates you might want. You do need replicates. There are BioStar posts discussing this in detail and also about different study designs. Another important lesson that was well-learned in the microwave days is the need for multiple testing correction. So I don't know if most of you are aware of the concept of multiple testing correction. Not really, okay, some of you. So the idea is that as more attributes are compared, there's a greater chance that the treatment and control groups will appear to differ on at least one attribute by random chance alone. So because you have variability in your data, when you compare, let's say, a set of normals to tumors, there's a certain amount of random noise or variability. Just by chance, if you keep comparing gene after gene, eventually the cookie's going to crumble in such a way that just by chance all of the samples were a little bit higher in the tumor and a little bit lower in the normal, it's just going to look like a significant difference. But if you repeated that experiment in another biological replicate of the whole study, because that was just random noise or chance, that would disappear. And it's just a function of doing multiple tests that eventually more and more of the results will be kind of spurious or due to random fluctuations in the data. And so this was well-known from array studies where you had, let's say, tens of thousands of genes or maybe hundreds of thousands of exons that you need to basically correct for the number of tests you do. So whatever your p-value is, you kind of have to make it... you have to penalize the p-value for the number of tests that you ran so that when you see a corrected p-value, you can really believe, okay, even given the possibility for multiple testing-related false positives, this is likely to be actually really significant. With RNA-seq, it's a bigger problem than ever because of the complexity of the transcriptome. Now we're not measuring just genes and exons, but we're measuring every exon-exon junction. We're measuring intron expression. We're inferring all these novel isoforms. You could have literally millions of different kinds of features that you might potentially want to run a differential expression test on. So this problem of multiple testing is basically more important than ever. You really want to think about issues like pre-filtering your data to limit the number of tests to begin with and running multiple testing correction. And there's a really good bioconductor package called MULT Test with reasonably good documentation that you can read on how to do that. Also, because this is a well-recognized issue, a lot of software now incorporates this into the software. So when we run CuffDiff, it's going to give us both raw p-values as well as corrected p-values, taking into account this multiple testing correction issue. But I don't know about all of the count-based methods, whether they would build that in or leave that up to you. So you need to read the methods and be aware that if they haven't provided a reasonable multiple testing correction, then you want to do it on your own. So downstream interpretation is definitely something we would like to have a whole separate course on. Basically, the expression estimates and differential expression lists you get from CuffLinks or CuffDiff or the other workflows that we're going to discuss can be fed into many of the different analysis pipelines and interpretation pipelines that exist and are used for other kinds of data like microarray data. So we do have the Supplementary R tutorial and the Cumberbund tutorial that gives you a start on some of the kinds of visualizations, like heat maps and so on that you might want. If you want to do classification analysis, there are lots of good packages in R. WECA is a good learning tool. I often use Random Forests R package, and there's actually a series of four tutorials in Biostar on how you would go through the process of... This is based on microarray data, so it involves some microarray preprocessing, but then there's some tutorials on how to do classification analysis and survival analysis. And those kinds of approaches will work just as well for RNA-seq data as they do for array data. There's really no important distinction. You can do pathway analysis using things like David or Ingenuity Pathway Analysis or Cytoscape, and there are many good R-Bioconductor packages for that as well. So the last, or not the last, the second-last module is going to cover these sections. So we have our raw sequence data. We've performed our read alignment. We're now going to do transcript compilation or estimation using cufflinks. We're going to merge those, in this case, onto our known GTF for known genes, and then we're going to do cuffdiff for a tumor versus normal comparison, and then visualize those results in either Cumberbund or this old-school R tutorial. So just to briefly recap what we're going to do in the exercises, we're going to generate expression estimates with cufflinks. We're going to run cuffmerge and then cuffdiff, and then we're going to summarize the results with either Cumberbund or the old-school R methods. There are a lot of files for all those parts, so the main Tutorial Module 3 Part 1 Linux you'll see on the Wiki. This is what's going to get you to run the cufflinks, cuffmerge, cuffdiff commands, all the Linux commands. And it's going to create the files that you need to run the Cumberbund that should actually say .r, which is the r script. It also creates the files that you need to run the supplementary R or old-school R. And then there's an optional part where instead of using cuffdiff for differential expression, we provided some sample code on how you would do it with edge r and the raw counts. We probably won't have time to get that, but you can take that away with you.  So generating expression estimates, we're going to start with our line SAM and BAM files that we generated yesterday. And these are going to be used by cufflinks. We're going to do it for all transcripts on the target chromosome, which is still chromosome 22. There's an option in this step called dash capital G. I guess there was also such a step in top hat. This forces cufflinks to calculate expression values for the known transcripts based on the GTF file that you're going to provide. To discover novel transcripts with cufflinks, you would not use the dash G option and do the de novo transcript assembly. That's going to be done in module 4. So you can just wait and we're going to show you how to do that. You can also use a combination of the dash G option, dash big G option with the dash little G option, in which case the known transcripts are used as a guide, but novel transcripts are still predicted. So Malachi is going to go over these tomorrow. These are basically like the three main methods of running cufflinks. We're just going to do today the simplest method, which is saying we know what the transcripts are in our genome. Later today, sorry. Not tomorrow. This afternoon I should say. So, we're just going to do it with known isoforms. We're going to get basically one isoform level and one gene level expression file for each library. We're going to have these FPKM estimates. We already talked about what FPKM is. We're going to run kind of some parallel optional alternatives as we go along. So we already started this yesterday, right? We had run top hat and star aligners. So we're going to kind of keep going with those if you want to see how it differs or doesn't differ to use the star alignments versus the top hat alignments. And then we're going to also explore this count-based method. So you're going to run HTC count. So in the end we're going to have three expression estimates for each sample. We're going to have the top hat alignments followed by cufflinks, star alignments followed by cufflinks, and then the top hat alignments using HTC count. And of course we could have done the star with HTC count, but it just gets a little bit ridiculous. We'll do differential expression analysis. So first we're going to have to run that cuff merge, which is going to combine the different expression estimates from the four cufflinks runs into one combined result. We're going to then compare tumor and normal to identify differentially expressed genes and isoforms. These commands can get pretty complicated when you have replicates. So especially if you're doing the integrated assignment later be really aware that spaces and commas and positioning matters in the way you set up these commands. The comparisons that we're going to do are just tumor versus normal for all replicates. And now we're going to summarize and visualize those results using our either cumberbund to produce these kind of plots or some very limited post-processing of files and then pulling them into R to do kind of the old school R analysis. And that's going to replicate a lot of the things that cumberbund does. So we'll look at like technical replicates and correlation between the different libraries visualizing the differences between and among replicates and then examining the different differential expression estimates and getting a list of the top differentially expressed genes. And if you follow through all of the materials and all of the optional and extra stuff you will eventually have gene expression estimates and differential expression estimates from both cufflinks and edge R and you can see this is the result that I got when I did it which is that there is fairly significant overlap and non-overlap between those methods. So again you may want to consider using one or the other or both in terms of predicting differentially expressed genes from your data. Okay.


I have my Linux machine, my client inside Virtuobox and let's have a look at doing some DNS client operations and we'll use NSLookup to basically see the mappings from domain names to IP addresses in the internet. Normally this happens in the background but we can have a command line tool to inspect things ourselves. Currently it's not installed so I need to install the DNS utilities. DNS Utils is the package which includes the things that I want to use in particular NSLookup. It may be installed on your system, in mine it's not. So it's going to install some additional packages and use about 12 meg of disk space so that's why it's not installed by the cut-down server initially. Yes, I'll install and now I should have, and just to show by installing DNS Utils I should have the command I'm looking for which is NSLookup. NSLookup does a manual lookup if we provide a domain name. For example, google.com.au, it does a lookup and tries to find the corresponding IP address and it finds the answer is <IP_ADDRESS>. The purpose here isn't to explain how the domain name system works, it's to show what NSLookup does for us. Normally DNS runs in the background, we don't do this. For example, when I open my browser and type in a domain name, like google's domain name, then it calls a DNS client to do the lookup for us. We're basically manually calling the DNS client to do the lookup using the program NSLookup. So it gives us a mapping from a name to an IP address. You may see different information because DNS, DNS is a complex system where we may have multiple mappings, we have cases and that may mean that people in different locations or on different computers can get different responses. Just looking at the output of NSLookup, the first two lines are not telling us the result but telling us the server that we got the answer from. So basically we asked this particular server, 1387176.10 and that may be given as a domain name there in some cases and here would be the IP address and port 53 which is the port number used by DNS servers. We asked this server, what is the IP address for this domain name? And the answer we got back was this 216 address and it's a non-authoritative answer, meaning the answer we got back is like a cached value. It's not coming from the authority server where this domain name is registered. So it may be different in different cases and it may be out of date because it's a cached value but normally it would be a correct. Try it on different domains. Type sandylands.info and it tells us the IP address for that is 103.363.107. We can, and it tells us that we got it from the same DNS server and that DNS server would be my local DNS server for the university network. Try a couple of others and let's look up on Facebook, some different output here. Again, we've done a look up, we've got an answer but we see that there's that Facebook or www.facebook.com is really an alias or a nickname. The real name or canonical name is star.mini ctanr.facebook.com and the IP address given is for that domain name. So this is saying that Facebook is just a nickname for this longer domain name. And again, the complexities of DNS means you may get different results depending on which regions you're in, which DNS servers you ask. A couple of others, google.com.au gives it, sorry, if we do and compare google.com this 216 address 199.68 and do google.com.au.67 almost the same 67.68, most likely they are both hosting Australian web server content although it's more complex than just going by the IP address. And we can, as another option, I'll just clear, we can specify which DNS server to look up. So when we just, sorry, when we type just the domain name then we'll ask our default DNS server but we can supply as another parameter a known DNS server. And I know that there is a DNS server with the address 8.8.8, which is actually the free DNS server that Google provides. So in this case, I haven't asked my default DNS server, I've asked a specific DNS server, there's all eights address and I've got the answer from that server and noting it's a different answer. So different DNS servers have different mappings from the same domain to IP address. And you need to look at the background of DNS and how, say, websites have content in different locations and to understand how all that works. So use NSLookup to do manual lookups with domain names and optionally supply a DNS server that you wanna ask to get the answer from.


I was on vacation last week so I didn't get to check out Sound of Freedom.  And here's the deal. People are very passionate about this movie because it's on a very tough subject matter which is child trafficking. It's awful, terrible thing, but the movie doesn't get a pass just because it's on a topic that needs to be addressed. And here's the thing. The movie's two hours and 15 minutes long. I didn't like the pacing. I don't think it's as impactful as people are making it out to be. The movie definitely has its heart in the right place.  As a critic though, this kind of missed the mark for me in a few areas. But overall, not a terrible watch. Just not something I would say, run out and see right away.


Well, I think the short-term future of the Internet is more silly kinds of enclosure and legal threats, but I'm hoping that the long-term future is something we can't even imagine right now but that develops on top of this framework and takes communication in completely new directions. I've seen the flourishing of all sorts of distributed search and conversation mechanisms and I hope we'll continue to see more of those.


Don't get it to the right spot, I got no power. So now we're going back to same position. Inside, outside, and the beautiful part of what we're learning right now with this tie, if you're an underhook guy, you can do everything we're doing with this tie with an underhook. If you're a double outside tie guy, you can do everything with these double outside ties that we're doing with this tie. If you're a rushing guy, most of what we're doing with this tie, pressure, he drives in, disappearing, get into this guy's legs, we can do it with any tie you want. So it's the concept, we're just working from one home base with our tie. Now, instead of swearing, I'm stepping past. I'm focused on getting my belt buckle close to his hips, still pulling everything. Right here, a pressure in, now I step through. Notice my hips come in, still in good position, driving across. We're back on the armpit now, back on the armpit. Inside, outside, pressure, back foot, steps all the way through, still pulling, still pulling. Right here, hips are in, back to straight, and just bumping them across. That's all we're doing right now. Back to your stance one more time.  Now we're going to lean, shuffle into that guy. Back and pull it.


Welcome to Recall Roundup. Check to see if you have any of these products in your home. High site is recalling about 1.7 million stainless steel pots and pans due to fire and burn hazards. Now the thermal wall pans were sold under the Royal Prestige brand name. The cookware can collapse, crimp or severely deform when it's exposed to heat and there has been more than 1,000 reports of that happening. If you do have this recall cookware you want to contact High Site and High Site will repair your cookware or if it's been damaged will send you a free replacement. Target is recalling children's two-piece cotton and fleece pajama sets. Now they do not meet federal flammability standards and then as a burn hazard. For children, Target's Circo and Exhilaration tags are at the neck of these pajamas. They were sold in infant toddler as well as boys and girls sizes and certain item numbers are included in this recall. You can find out more about those at Target's website. If you do have one of these recalled sets of pajamas, take them back to Target right away and you will get your money back. And finally Fisher Price is recalling about 800,000 rock and play infant sleepers due to risk of exposure to mold to the infant that is sleeping in it. Now if you do have one of these, inspect yours to see if mold has grown between the removable cover, the seat cushion and the hard plastic frame. If you have mold and you see it in there, contact Fisher Price and Fisher Price will give you cleaning instructions. Fisher Price will also give you further assistance if you need it. There have been about 600 reports of mold growing in these. That's recall roundup. You can check our website saferproducts.gov for more information about these recalled products as well as others.


So, I will just be very short and introduce Wookie, who will now give you an embedded Debian presentation. Wookie. Okay, hello everyone. So, I work for Alhaf1. We do embedded development for anybody who will pay. And we try and base it on Debian when there are letters. I've been interested in this for a while. I'm normally project leader for the last three years or something, which means very little has happened in that time. But I'll tell you where we are and where we're going. How many, before we start, how many of you already know all about embedded development? Well, you know, are interested, have done some, know what we're talking about. And how many of you, this is a kind of new area and you've got some widget, you just think it would be cool to put Linux on. Okay, a few of each. So, to some extent I've got you here under false pretensives today. The talk was billed as it was suggested to me in fact by Lars Visnius that what we should do to encourage Debian to support embeddedness would be demonstrate all the cool things you can do with embedded widgets and how easy it is and why we should all do it. So, I thought that's a good idea, but I've just spent. So, the idea was I'd sit here and show you how to download the tools and install the tool chain and configure it for cross-building, build a kernel for your little widget, download all the sources and then explain about how cross-building works, build a root fest, stick it on the machine and it would sing songs or whatever. And you'd all be suitably impressed and could go home and do it yourselves. So, I spent the last week doing that. We got as far as installing the tool chain, that worked quite well. Fixed a couple of things, configured for cross-building and try and build things and nothing worked at all really. It was all a disaster. So, the current state of the tools is that lots of things don't work. If you want to do, as I just described, then go and use Scratchbox or Open Embedded because they actually do work. If you want to try and do it the pure Debian way, it makes life difficult. For some reasons, I'll go on to explain. So, what I'm actually going to talk about today is, say at Plan B, the reason why I haven't got all this working and marvellous and beautiful is that I spent most of the last month fighting software patterns and not preparing this talk or working on embedded Debian or anything else I was supposed to be doing. So, that's my excuse for any disorganisation that may occur in the next hour or so. This worked quite well though. So, we had a major success on that front. So, the backup. This is what you'll get. I'll just explain what embedded Debian is for those of you who don't know and tell you where we've got to and explain some of the pros and cons of this approach. What we're trying to do, how it's supposed to work and what we need to do next to actually make it work. One of the things I want to... We kind of got into it in the previous session. I don't know if there's anyone who's here who wasn't there about why Debian supporting embedded stuff more than it does now. It's probably a good thing for everybody. So, embedded Debian is an official subproject. It's all very exciting. The idea is that lots of people who are already familiar with developing the Debian way they use it would like to just be able to produce a mini version for a specific purpose. There's an awful lot of companies like mine that people who don't know about embedded systems realise that they probably want to use Linux on their hardware. They need easy ways to build a system with this stuff on. Alternatively, we build them a base system that they can put their special thing on. As someone mentioned this morning, people often have a great deal of expertise in their particular application area that they really don't know about building basic Linux systems. In principle, Debian ought to be a good base for this kind of thing. Partly because of the multi-architect support and all the tools we've got. The other thing, of course, is that it all has to be proper free tools, none of this Montevista and their secret configuration system which is proprietary. Started in the year 2000 by a guy called Frank Smith from Amarix who thought, basically what I think, that this would be a good idea. They produced a tool chain that worked for ARM and PowerPC, I think. Also, a handy tool called, I'm sure it should be Mdebsis, which is quite primitive, but it's also quite neat. Basically, you use the kernel configuration language and extend it into user space so you can configure which tools you want, whether you want ping or mount or whatever. Then it just goes and fishes the relevant binaries out of the Debian archive and puts together a root of s. The problem with that was keeping it in sync with the changing packages was a real pain, so inevitably it got left behind by both the kernel and Debian. Also, it was written in CML2 which never made it into kernel favor, which put it at something with disadvantage. It did get updated to the new kernel config language and people have used it for real commercial projects. It works. It's arguably one of the best ways of producing a really small system is positively fishing out the binaries you want as opposed to building packages and throwing away the bits you don't want because it guarantees you don't end up with anything. You didn't really, really need. Since then, we basically started again with a new scheme using d-package cross and a thing called the stag framework, which is basically the work of Philip de Swert, who unfortunately isn't here today. We've been fiddling with that for a year and a half now. There's also been new tools, which is mostly the work of Nikita Yushenko. People used to use all sorts of cross-compilers from all over the place. It would make a lot more sense if you used the standard Debian source. Somebody did a thing called toolchain source, which was a package which was basically just the toolchain source from which you could build a cross-compiler, which is all right, but it tends to get out of sync with the compilers people were using in the rest of Debian. Obviously, it was much smarter to actually build the cross-compilers from the same source package that we built the normal compilers, which after all is something that the upstream source can do, so our packaging ought to be able to do it too. Nikita fixed all that, so now we can build cross-compilers for all Debian architectures from the same source. They may even work. They're all available on mdebian.org. Obviously, increasingly, for a long time basically you wanted an x86 compiler to whatever target you want to use, but these days there's more than one fast development machine you might conceivably be using. Hopefully this week we'll get the PowerPC and AMD64 development host versions working, so you'll have from all those three fast architectures to all the weedy small ones. Now, we don't want to put all of those tools in Debian because there's an awful lot of combinations you can work it out, an 11 factorial or something, which hardly anybody needs, especially all the ones, like you really don't need a cross-compiler that runs on-arm and produces x86 binaries, that will be dumb. So trying to put all of them in the Debian bucket is just a waste of space really, so we'll just host them on mdebian.org or somewhere useful. So reasons why Debian isn't really where you want to start, it's all built natively, and there's good reasons for that, and it's simple, that's the way everything was designed to be done, but embedded developers really don't like natively building. I mean, you can do, and indeed it can be quite practical if you have a fast enough target machine, so if you've got a fast-arm box you can build your arm binaries on that, and it does save a lot of aggravation, and that's how quite a few people I work with actually operate. You can buy 600 MHz arm desktop box, which will compile everything pretty slowly by modern standards, but still fast enough. But in practice, most embedded developers need to be able to cross-build things. Normally Debian doesn't care at all about the size of binaries, however we care a little bit, but basically eight people go. You can't buy hard this small than 40 gig. Why are you complaining about a couple of 100K here and there? And the answer is, of course, because that thing's got 64 MHz of flash in it. So your entire file system has to fit in 64 MHz.  So there is a dramatic difference. I mean, embedded used to mean 32K. These days it means less than 32 MHz, so it's got a lot bigger, which is why Linux has become practical in embedded systems. In your average standard Debian package, there's a whole load of stuff that you don't need on your average embedded system. All the documentation, most of it, example files, Vim colouring schemes, 27 languages that you aren't going to use, all that sort of thing. So you want to be able to get rid of that. And by default, we tend to enable everything. So if it's possible to use something with X, then it will be compiled to do so. Or with some fancy font mangling system, or whatever, all of that stuff. And again, people want more control than that, and often might not on a lot of systems. There is no display. You don't want any of the X versions, but you still want the underlying functionality. Reasons why Debian is good. The code base is nice. Everything's consistent. Files are where they're supposed to be. I mean, that's why a lot of us started using Debian in the first place. I know I used to hate Red Hat. But it was a great revelation to find that config files were always actually in slash ETC, where they were supposed to be, and not somewhere bizarre. All that stuff. I mean, to some extent, I think that has gone upstream, and the world's a tidier place than it used to be in 1997. But even so, it is nice. And you know it builds on all the architectures without aggravation because we checked. The multiple architecture support's good. A lot of the targets people are actually using embedded systems supported in Debian. Not all of them. People do use weird stuff like SH4. Actually, we got an SH4 build. People had one for a while, but I'm not sure it's defunct. But in practice, most people are using ARM, or PowerPC, or 68K. Or X86, of course. And our management tools are quite nifty. If you start to look at how it all works, we can in fact do most of what's needed in terms of cross-building and installing packages, not to the default file system, but to a target file system, all of your own, a charoute, or whatever. It's all there. And it's a matter of bringing together these tools so that it works in a coordinated way. As we were discussing earlier, we quite like having derived distributions. It provides useful ideas and feedback, and gets things fixed that wouldn't otherwise be fixed. And the familiarity of developers is one of the reasons why they quite like to be able to use something like Debian on their small devices. Not exactly the same, but having a lot of the things they used to. So people who don't come from that background are quite happy to use any strange embedded system you give them, whereas people who are just used to Linux looking like Debian, or like their other boxes to behave in a similar way. So that's the main target, I think, is people who are already Debian users, but do embedded things and want easy ways to prototype systems. Embedded Debian probably isn't the best way of producing general production embedded systems. There's something like Open Embedded. I think we'll always have much finer grain control over what you can do. Because absolutely everything is possible within that framework. But it is horribly complicated, even by our standards. And it will be nice if we could produce something that will let people prototype stuff quicker and easier than that. So to make this work, we need a scheme to cross-compile things. It doesn't break horribly. Dealing with optimisations, generally things are optimised for speed, whereas for an embedded system, you probably want to optimise for space. And in fact, it might go faster anyway. There's arranging things so that you can manage the packages on the target device, which of course aren't going to be the same set of packages as on your host device, a build device. There'll be a small subset of them. And as we'll talk about later, these are actually a slightly different arrangement, potentially. So you need some mechanism to say which bits you want. Splitting packages up into smaller pieces helps a lot. So you have all the languages split out into a separate little language package, and the docs split off, and the X versions split off, and so on. The finer grain your package management is, the easier it is to get the bits you actually wanted rather than a whole load of stuff you didn't. One of the things that we kind of think about regularly at these events, but haven't reached final conclusions on it, I don't think, is the packaging namespace. So if you take Debian installer as an example, that is basically an embedded system based on Debian, but it's designed to live in the same namespace. All the Debian installer packages exist in parallel with the normal packages because of what it's designed to do. But in a lot of cases, you probably don't need to do that. What you actually want to do is build a whole separate namespace set of packages for your particular target, which don't have to work with Debian ones. On the other hand, there's a set of people who want to be able to prototype something quickly using a standard base system, a standard small base system, and then sticking random Debian packages for obscure or complicated stuff because it's not in our little mini build. And if you want to do that, you've got to have a compatible system. So you've got to be using the same LibC. You can't be using LibC and then sticking random Debian packages and expect it to work. I mean, you can do that to some extent, but that's making it a lot of difficult. So there's various ways you might want to do this. And you probably can't support all of them at once. It would be nice if we could, but we certainly have to start with, we've got to pick something and do that and prove it works before trying to satisfy all conceivable schemes at once. It just makes your life so difficult that you never get anywhere. One thing people do want is a customization mechanism for their particular device. For the reasons of all the derive distributions that we're talking about, there's always some stuff you want to change. It might just be the kernel. It might be some kind of unified graphical goodness for the front end on your little widget. So a kind of organized way of applying your set of patches so that you can keep porting that forward as things move on easily will be a very nice feature. That's something Open Embedded does really well. You've got to stick into the deep-packaged cross kind of Debian way of cross-compiling things because we have one dirty, great big patch instead of parts of little ones, which is what you really want. Staying in sync with Debian is the other thing. There's a very small number of people actually working on this at the moment. That's one of the reasons it's progressing fairly slowly. And Debian keeps moving on and our tools get left behind. Once we have a whole load of changed packages, if those changes aren't kept basically in Debian itself, then in practice it'll just get left behind immediately and become useless, and better Debian will only work unless, if either, several hundred people start working on it, or we have a mechanism for keeping the changes from standard Debian within normal packages and maintainers actually looking after those changes. So if that's work, we have to get a fair amount of buy-in from Debian that this is something worth doing. So there's two major issues which are largely independent. There's cross-compiling things. Now that's useful for embedded people, but it's useful for other reasons too. As I mentioned, if your buildies are sufficiently slow, you might actually want to cross-build that architecture just because you can do it in hundreds of time. I think it would also be... It gives the same benefits to Debian that building for a lot of architectures has given us in the past. You know, nobody else used to do that, and it meant that Debian was the only thing where you could guarantee everything worked on big-endian and little-endian and different sizes of pointers and all the things that vary across architectures, the fundamental stuff. An awful lot of those bugs were pushed upstream over the years as we've discovered that things were broken because people only write for the architecture they know. You can't necessarily be expected to know that ARM has really strange float format, which you're finally getting rid of. Those things have got fixed over the last decade. We can now not care about anymore. I think if we decided that Debian should be cross-buildable and fix things accordingly, because the mechanisms all exist. They've been there for a long time. There's an awful lot of crap or cruft in autoconf and package confing and all that stuff, which in theory means cross-building should work the way it's intended, but it doesn't for a lot of detailed reasons like people never try it and nobody understands autoconf and just copy the script from somewhere else and you have the same badness that everybody else had. An awful lot of the fixes are in fact already an open embedded because they've been going through this process for a year and a half. There is a great load of goodness in there which tells you what needs changing to make things build properly. To some extent they're pushing that upstream as well. Do you want to say this for the end? If you can remember. I think there will be quite a lot to talk about like this. There is a whole load of stuff which has to be run at build time. Lots of things build stuff and then run it for tests. There's a limit to how much of that you can do without creating a whole target environment that looks like the target environment and running things in it, which is what Scratchbox does. I think we want to use a lot of the good things that Scratchbox has done. To a large extent, I'll talk about that more on a later slide actually. The other part of this is package modifications, which is throwing away the docs at the most primitive level. You can have a lot of basic heuristic rules which say throw away all the examples and throw everything in user share. We don't care about that except for about six files that are actually important, which will do the right thing for a lot of packages. In a lot of cases, you'll need specific rules for a particular package that say the way it should be done for a small builders like this. In fact, we want three different versions of it for different purposes. These two things, the cross-compiling part and the building-shrunk packages part, are mostly independent. What we're trying to do is reuse the existing package management system, d-package and apt, and add-cross compilation support, which in fact already exists in the form of d-package cross, which is a tool designed to just build. With d-package build package, you just add a couple of options and say build it for ARM. Remove the stuff we didn't want and have a scheme for installing the packages either onto the development host for testing or on the target itself. You can either build your root file system on your development box, so you make all your packages and then you install them to the virtual target and then you copy the results across onto your actual target, or you can make packages which the target can install itself. There's two different models. It depends whether you want to just make a widget and give people a system image or whether it's kind of like a PDA and they actually want to be able to have a set of packages which you can choose things from and shop and change. The things we fiddled with, these slides are now going to get in slightly randomised order, so I do apologise if it becomes a bit disjoint. That's the fault of software patterns. Deep package cross is this thing that has existed in Debian for a while. I think it was originally produced for people who just needed to build an ARM version of a particular package in order to do a port as binary upload. Nevertheless, it's basically a wrapper for deep package build package which sets a whole load of stuff and can fill in config variables in order to do arbitrarily complicated things in order to set all the things that should be set, such that if your package build system is properly constructed, it will just spit out the right thing at the end. As Scratchbox buyers can tell you, life is nothing like that simple in practice, but the principle seems reasonably sound. It automatically means that the build system is told to use the right compiler and the right bin utils and the right strip and all that sort of thing. The way we implemented this is basically just wrappers for deep package and apt, which give it the right options. This is what your standard setup on your normal Debian box. This is a repository with binary and source packages in it. You can get a list of those packages which apt puts in a local database so you know what's available. Then you get those into your local cache. You can build them or you can just install them and there's a database of what's installed. We all more or less know how that works. To do that for the embedded setup, we have basically the same thing but slightly more complicated. Now there's a second repository list for the target architecture and a second locally available database for the target architecture and a second local database of installed packages for the target architecture. It's not difficult. That way you can manage the set of packages on your device separately from the set of packages on your machine. Now apt and deep package already provide all the technology we need to do this. We don't have to write any new software. It's great. Why wasn't that the next slide? Because I'm rubbish. How do I go backwards? I'll show you that in a minute. The way you do this, you download your sources and build everything on your development machine. The parameters which control the cross-compiling live in ETCD package cross-compile which tells it which architecture it should be assuming you have a default one and where the tool chain lives and stuff like that. If that also provides a mechanism for special versions of things which I'll come to in a minute. That's quite a new feature. You build things with deep package, build package the way you did before. Then there's a wraparound deep package for actually installing the packages you've built into your local target system. On the actual device when you get later, so you haven't built a tool up tool now, but when you finally dig it out and make it work, you can use I package to install those packages rather than deep package if you want to save the phenomenal amount of space you'll save by doing that because deep packages databases are very large especially when you've got a lot of packages. I package is a lot more efficient in that regard but it's basically compatible so you can choose which one you want to use on the end device. You can't use I package for all this build stuff because it's not smart enough. This is the neat new feature that's been added to deep package cross recently which is basically you can have a set of modes. You can have arbitrarily complicated flags for all sorts of purposes. It's very generic but there's a special Mdebyn flag which basically says all the tools that you normally use for building so this affects a DEB helper if we got ran to it it would affect CDBS and any other obscure build schemes which we don't know about can be told things like by default throw away the docs by default remember to link with the target architecture libraries and not the host ones when doing deep package shlib depths and generating the runes because a lot of the packages are built with the same tools by changing those tool scripts a little bit to just make them cross compiler where you get quite a lot of this almost for free by basically setting this flag so that bit works it was working in February but since then something's changed and it's now broken again as I discovered this week which is why I'm not going to demonstrate it by typing it because all you get is obscure runes about not being able to set cross prefix to cross prefix but you can also specify in the scope here all the extra flags so if you want to build everything with dash m cpu strong arm or you want to add soft float or other compiler flags basically you stick them in here and they give them to every single package that gets built you can specify different C library and so on so that's the kind of fundamental control level mechanism so this is how the wrapper stuff to make app to do all that stuff about retaining a separate set of lists for the architecture it's not very complicated you tell it what the app to architecture is and that it should be using a different sources dot list because you probably want to get your file from somewhere else 15 minutes Jesus right okay and that the cache is somewhere else and so on and the that anything that gets installed gets installed to a different place from the default root file system basically the same but the package stag the package is a wrapper for it which just gives it the right runes every time so that does quite a lot of what you want at the basic level so there's a fundamental problem of how do you control the bits that are different for embedded builds now we kind of hummed and hard about this we're now on the second generation of the scheme which I still view very much as an experimental implementation so the moment you have your Debian directory which contains the control files and stuff everything you need to build Debian rules so now we have an Mdebian directory as well so if an Mdebian directory is present then the tools these new tools will use that preferentially so that's how you have different packages different dependencies and different build options the problem with that is because it's a separate directory it's not at all obvious to your maintainer that there's all this basically we've got two copies of a lot of information we could copy the standard rules and then change them a bit and those will go out of sync horribly over time if anyone can think of a much better scheme the main advantage of this was that we could we could tack it on to existing packages without getting anybody's way so we could experiment with this system prove it was actually valid and then worry about we could get that into people's packages without it changing anything at all one jot of their work which would be relatively painless we were hoping so that's the advantage of this scheme it's entirely a non-intrusive but it may not be the best way to keep maintenance in the long term so package doesn't change much we had this in Debian's sub-directory with new build info which is usually very similar but just slightly different blah blah blah told of that splitting the docs there is a good thing because as Timo will tell you later in the week the docs produce an awful lot of circular dependencies in Debian which makes it incredibly hard to build the whole thing from scratch you have to have Debian already in order to build Debian it's a bit of a pain for embedded systems so you've got to build the whole thing from a tool chain up from G-Lib C upwards because that way it definitely comes out right so the way you actually use this you install you know modified tools modified debhelper and d-package and d-package cross set that mdibi in flag and then just build things with a dash A arm instead of what you normally did and in principle it spits out all your Debian packages for another architecture as I observed earlier that generally doesn't work except for extremely simple packages and that's where we're going to have a session afterwards and sit around and hack some things and discuss about stealing a number of the good bits out of scratchbox especially the ability to run non-native binaries in order to do compile time tests the multi-arch stuff I think is also very interesting in this regard it's primarily aimed at x86 and d64 but in fact you can also get it to run arm test binaries during the build which you know could be useful so yeah so as I said the tools will fix will improve packages from our point of view without you making any changes to them at all and then there's a more specific set of changes you can make if necessary so these are the scripts that need modifying in d-package dev because all of them need to know about basically just knowing about the mdibi in directory and using it preferentially if it exists it's not rocket science actually if you look you'll find there's lots of trivial modifications to all the scripts so things that don't work so well d-package cross as I said was really designed so it's a handy tool if you need to build something for arm you need to have all the libraries it needs at the very least to and d-package cross basically lets you get those libraries from the existing architecture pile so you already, with Debian already has all the arm libraries pre-build and it's just you can basically do d-package cross package name it'll fish out the library files and the package name and architecture it'll fish out the library files and the header files for package config files for all the libraries you need stick them in the right place so that the cross build system will just find and use them what it doesn't have is a neat way of actually sucking the binaries in the first place as far as I can tell you you have to go to packages.dibbyn.org and download them with Wooget each time which is incredibly rubbish because we have lots of other tools that sort of do that like apt build but I couldn't get it so that it would just get the few packages you need for this particular build dependency apt would get carried away and go no but if I need those I need all these and then it says we'll download 336 megabytes of packages basically an entire system and you go no I don't need an entire system I just need the stuff for this package now that could just be because I'm very stupid and someone will explain to me later what the right rune for that is but it was annoying me this week you do need to be root for a lot of this stuff to work but then that's kind of true for package building anyway with the fake root stuff I can see that it could be a problem in some environments it kind of depends whether there's lots of developers trying to use a system or if it's just you and your box in which case it probably doesn't matter if we put in runes for an awful lot of packages the fact that all the bodys for cross building something properly go in it should be d-package cross compile it's going to get to be a very big file after a while if we've got little secret runes for a thousand packages in there so I probably need splitting up but that can come later the other thing I think that needs a bit of thought is on embedded systems almost invariably you don't use a whole load of the base file stuff you use busybox instead and you don't tend to use standard xlibs and all the associated cruft you use tiny x instead so there's a kind of base system which you will usually want to use which has a fundamentally different set of dependencies and I haven't quite got my head round exactly how we're going to do that I'm sure we can but it needs somebody smarter than me to explain to me what the correct runes are so once you've generated a whole load of these packages then you use stagget as I mentioned earlier so you just do staggetarm update staggetarm install package and it will just take your packages from the pile so once we have produced an example embedded Debian we can do a standard one which will probably satisfy a lot of people which is basically probably 500 packages from Debian that people actually use and a much smaller base system box and tiny x then most people can just point their point stagget at that and use it and that way they can produce embedded systems in about a quarter of an hour and then they put their one application on top that they actually want to use that's new or different that's the idea so we have the tools to do this but they don't work very well which is why we have more people in this room to come and have a good hack later so we can at least get things up to date and see how much of a system we can build that works we have a build machine which is five minutes right okay does that include questions as well right okay I better shut then don't I I'm nearly at the end which is good and we need to build actually build an example distro that people can try out that means making a list of the things packages that people actually need I'm not sure what the minimal set of packages is but making a list to say these are the first 200 that we ought to compile and then that will satisfy a lot of people or 500 or however many it is adding QEMU actually I've mentioned earlier didly-do covered that pretty much somebody from Debian install ought to come and help because I haven't taken enough notice of exactly how they've done what they've done and I'm sure that we ought to make sure that we're not inventing things which they've already worked around and the other thing is that ultimately Scratchbox guys are well ahead of me on this they've been playing this game for a couple of years already discovered that it's hard work and doing things this way is difficult so basically Scratchbox works around a lot of these problems not fixing all the broken build systems and just providing a big sandbox so that the broken build systems still do the right thing which is very cool but what I'm kind of interested in is whether it's possible to actually fix all the build systems and do it kind of cleanly and properly with rather less stuff needed to make it work I don't know maybe it isn't in which case those solutions are in fact already the best way of doing it and I should just give it with this because the other thing is can we persuade everyone in Debian that cross-compilability is a good thing because if we can't do that this probably isn't going to get very far and can the changes we make to in Debian be kept in step with Debian as it rushes along in its headlong epicness again if not we have a problem we'll just keep getting left behind and we'll never get anywhere there are all sorts of odd build systems out there most of this stuff should work for Autoconf and for Debhelver but when people do exotic kind of build it and then build it again from the results of the amazing Makefile which built all your Debian Makefiles and stuff life will get difficult these people have all helped out OMS has provided the build box we've got somewhere in the States or New Zealand or somewhere I don't know where it is but basically we've got a box we can play with that's that, right probably good oh yeah okay as we went all the trouble to make it appear on the camera so this is just an example system which we didn't build with embedded Debian of course because it's rubbish and doesn't work this was built with open embedded this is the kind of cool stuff you can do this is 64 mega flash packed with Firefox and a proper email client which is are you supposed to sit up there? yeah sorry magic technical people make my thing appear yes someone ask a question there's a whole in the ETCD package cross-compad you have all the configure variables for a particular architecture and for Linux oh sorry yes repeat the question where are we going to put all the configure variables so deep package cross basically takes care of that there's a set of files so there's one for if you're using Linux configure variables look like this if you're using ARM configure variables look like this so we can add an arbitrary set of those files if you're using embedded Debian some configuration variables look like this that's right so that's a feature of deep package cross alright so we've got our netbook so this is a quick 30 second demo just to show that you can do quite neat things we should have the Nokia people here because this is even cooler I'm sure because it's newer so these are a whole load of apps this is the GNU palm top environment plus Mozilla, AbbeyWord, GNUmeric GPDF blah blah blah and this little thing in the corner Therian editor is a scheme which basically means you can stick in so that's what fits in 64 mega flash but if you've got things that don't fit you obscure one of my packages in Debian for drawing cave surveys which requires TCLTK and all of Tetech and a whole load of garbage and basically you can just fish all of that stuff out of Debian standard Debian packages stick them on a compact flash and put them in and add a little app icon and that appears and runs so you can add a random vertical app to the basic system slowly so this is a strong ARM 400 megahertz PXA thing as you can see GPDF runs really really quickly but it does work and what this gives you it is so that's Therian TCL thing finally started up Mozilla goes fast enough to be quite usable it's a little bit sluggish but it works and what this lets you do is have all the stuff you need on a basic system so text editor, email, web browser PDF reader calendar app blah blah blah and that was built with open embedded and it took I don't know about eight of us eight months or something that was a big job we spent a lot of science money on that does it? oh it does yes indeed and to be fair it included a lot of work if you look at the standard version of Balsa it's got a lot more menus and options and things it's been this has had a human interface man go over it and basically throw away most of it people don't know any of these things get rid of them hide them in extra menus that say more at the bottom here we are like that so all the extra cruft that used to live there is hidden from your normal user and quite a lot of the work went into that and that's the sort of thing where open embedded is good because there were some fairly heavy patches but it's got a mechanism for keeping your dirty great patch for your special version of the applications so anyway yes that's cool toy it does yes so open office goes in on the compact flashcard that's what the mechanism was devised for and I haven't got that on this card I'm afraid because I was much more interested in cave surveying open office it does run it very slowly I'm sorry but we'll have to we'll have to stop there so the thing I do need to say is there will be a hackfest for the rest well Tuesday and Wednesday and the rest of today on embedded Debian so anyone who's interested in this sort of thing please come to wherever the hacking is there's a room for it I gather smoky yes smoky or something and we will be there in the corner playing with this stuff thank you


Welcome back to Kids Fun Science. My name's Ken. Today's experiment is neutral buoyancy. As always, adult supervision is required. What you need for this experiment is a plastic cup, olive oil, rubbing alcohol, water, and an eyedropper. Some safety precautions go in here. Make sure you perform this only under adult supervision. Rubbing alcohol is very poisonous if ingested and is flammable, so keep away from open flame. To set up this experiment, you're going to need rubbing alcohol and a plastic cup. So you're going to pour the rubbing alcohol about halfway full. It doesn't have to be precise, but about halfway. And once you get that done, then we are going to add the olive oil. So just go ahead and get your olive oil. I don't think it matters if it's lighter or regular. I pour it in the cup because I'm going to use an eyedropper. It makes it a little easier than trying to put the eyedropper in the olive oil and contaminating it. So then I got the olive oil there in my cup and I got a cup with mini there with water, just regular tap water. So what we're going to do is take an eyedropper and we're going to pull out some of the olive oil and we're going to put it in the rubbing alcohol. And what it's going to do is it's going to make some some really neat spheres. As you see as they're dropping down little round ones there going down and they'll just sink all the way to the bottom. So go ahead and make a whole bunch of those. And once we get that done, it should look something like this. I'll come up to the top view so you can see what the the olive oil looks like a little little like clear balls there. So that's pretty cool. And so those are on the bottom, you can make more than if you want to. Now the tricky part is so we're going to start adding water. If you add it too quick like I am right here, it will start popping the olive oil spears. So you got to be very careful when you're adding the water. You could add it drop by drop with an eyedropper that it will take a very long time as you're going to have to do hundreds of drops because it will pop the spears. If you end up popping too many of the olive oil spears, go ahead and add a little bit more. They will sink to the bottom, but you do not want to put the water in. I'm doing a little bit too fast here. So you want to go a little bit slower and I'll show you how I'm doing it before I was just doing the eyedroppers. I started pouring it in just to speed it up a little bit, but the eyedroppers are guaranteed that it won't pop them, but you do want to go very slow. So gently, if you're going to do without the eyedropper, gently pour it against the side of the cup and very slowly drips or pouring very slow at a time, because if you if you go too fast, it will ruin the olive oil. So as you can see here, I'm just kind of going this. When you get to a point where you start to get more saturated, then you can start doing drop by drop or you can do drop by drop the whole time. If you want the experiment to completely not destroy all the olive oil. So that's how I do it right here. As you can see as the water is starting to get in there, the solution is getting a little bit more mixed up water and alcohol, rubbing alcohol. And so you can start to see the spheres are starting to become neutral buoyancy. And we're going to see that as we go a little bit more as they add more and more water. I'm going to start pretty soon going to drop by drop as we go. But I'm going to explain the science behind this. So the science behind this is the olive oil initially sinks because it's denser than the rubbing alcohol, but however it is less dense than water. So by adding the water to the alcohol, the density of the water slash alcohol solution gradually increases until it becomes equal to that of the olive oil. At this point, the olive oil will either sink or nor float. It will become suspended in a state of neutral buoyancy. The density of the olive oil is now equal to what the surrounding solutions like fish, submarines, and the Goodyear blimp all experience neutral buoyancy if the density is equal to their surroundings. The olive oil is really interesting to observe because it forms these tiny little spears that we saw earlier when we added to the water. This is because oil does not mix with water due to oil's non-polar nature. Water molecules are polar, meaning that it contains both a positive and negative end. A non-polar substance such as oil is completely neutral so it doesn't really mix with the polar substance. This property of the oil makes it easy to observe when neutral buoyancy has been achieved, as you can see right here. I hope you enjoyed this video. Remember to click thumbs up and to subscribe, and thanks for watching!