Okay. Welcome everybody.  This is the first talk of the DebConf proper after Debian Day. And I actually think our first speaker doesn't need very much the way of introduction. Stefano Azzacchiaroli, the Debian project leader, is going to give us bits from the DPL. Better. I hope the battery stays up with me. Okay. So thank you everybody for coming up this early in the morning. I'm glad that we did... working still. Okay. I'm glad that we did manage to enter the auditorium. So in this talk, I just want to make a kind of a health check of Debian after 17 years almost of its life. And it seems to be kind of a tradition to start the bits from the DPS talk looking back, looking at how all this started. So I went back and read for the end time the message that Ian sent to a news group, something like 17 years ago, and it was something like a fellow Linuxer. This is just an announcement to announce the imminent completion, not the completion of a brand new Linux release, which I'm calling the Debian Linux release. That was August 16, 1993. And in that message, you can find something of the original goals of Debian, and which are kind of inspiring to look at. So back then Ian was aiming at making GNU Linux competitive with the commercial operating system. Back then it was kind of completely unknown to the great public, and so the first goal was to have that operating system be competitive. So it was inspired by distribution quite popular back then called SLS, but the goal was to make it better, make it a distribution in which quality was really important. You wanted to make Debian easy to install for any user. You want to build it in a collaborative manner in which all packages were managed by experts of the specific software which was being packaged and using an open model in which everything was done in the public. And also, more importantly, you wanted Debian to be free as in freedom. So back then, there were not many distributions. Debian was one of the sole ones. Together with that, we started not far away. And today, the situation has pretty much changed. So nowadays, Debian has something like 30,000 binary packages. If you look today in the IMD64 seed main, we have spawned something like 120 derivative distributions, which are distributions which are based on our packages. And we have released 11th time and we are close to release for the 12th time. We are about 1,000 packaging contributors, of which 900 are developers and about 100 are Debian entertainers, plus thousands of other contributors of relevant work like translations, websites, and this kind of stuff. We are probably among the biggest distributions. We are the one with the largest number of ports available, and we are going to release two non-Linux ports for the first time with Squeeze. So I would say, well done. It's pretty impressive with respect to the original goal and with respect to our condition back then. However, I feel that when we talk with us and when we think about Debian, we have some kind of bad feelings in some moment. So I feel that sometimes we have the feeling and sometimes I also have the feeling that there are now a lot of other distributions. We are not alone anymore. And we feel that some other distributions are releasing more frequently than us and we feel a bit better about that. We know that other distributions have more users than Debian has and we feel a bit better about that too. We feel that some other distributions are innovating more, that some other distributions are getting more credit, more press, more relevance, all in all, than Debian. So I ask myself and I ask you, do you think Debian is better than other distributions? Why are you contributing to Debian in the first place? And even more so, do you think Debian is still relevant 17 years after its original creation? Do you think that the free software ecosystem will miss something if Debian will disappear one day from another? So my answer to that, to both of them, is yes, absolutely. But I would like, before presenting my, I mean, the reasoning for my answer, I would like to know from you. So have you ever asked yourself this question? What is your answer to that? Why do you think Debian is still relevant nowadays? I think that we have a microphone, some comments on that? Jonas? Most certainly, yes. That's the easy part. It was written there. Should I reason it or should I... So why do you think it is the case? Because the resolving above is flawed. We have the most users, because we have distribution users. Okay, fair enough. And similar with some of the others. We don't release less frequently. Release four times a day. So you're saying that Debian is relevant because it's the basis for several other distributions out there. That's your argument. Anything else, Phil? I'm kind of scared of what Phil is going to say, but... Hi there. Yes, okay. I've always thought that Debian is relevant because it does what I want. It does what? It does what I want. And there are about a thousand people who think that it does what they want enough to work on it. And even if the rest of the world goes somewhere else, there'll still be a thousand people that you'd have to kill to stop working on Debian. Anything else for us? I think it's extremely relevant because it still follows that model, wherein experts maintain packages of the software that they know. And when we were looking for a distribution to use at Stanford, we were looking for something not that we were going to consume, but something where when we came up with things at Stanford that we needed, we would be able to get them back into the distribution and then they would have the benefit of being part of the distribution and not some add-on that we have to maintain independently. Absolutely. Sam? For me, Debian is a great distribution because it's something that I can choose to contribute to. I know that there's a community aspect to it. If I am part of the Debian community and I'm working on Debian, I know that my needs and concerns are going to be one of the factors. It's not something where my contributions will be accepted as long as they're consistent with someone's commercial agenda. But whenever the person who owns the whole thing, their needs diverge from mine, I'm out on the street. Here I know that maybe someday the community will disagree with me. That's okay. It's at least a community process to understand that that disagreement has a cost. Absolutely. Take a couple more, Matt, and then... I apologize in advance for a long answer. I think in order to answer... Okay, we postponed that to the question time. I think in order to answer this question, you have to think about what Debian is and what it's for as well. I think it's not a trivial question. And I think there are at least a few different angles to look at this question from. Debian is an operating system that works very well for a lot of people. It's also a platform for developers to use to make things, whether that's a derivative distribution or an embedded system or lots of different things. And it's also a project. It's an activity that people do. And I think in each of those dimensions Debian is actually doing very well. As a platform, the extent to which other products are based on it is proof of that. And in terms of a project, I think it's important to contribute to and continues to attract contributors. So I think yes. Okay, thanks. One more? I think all these answers are great. But for me, the underrepresented really critical element in Debian is unlike any other distribution, it's the commercial or Linux. It's the only one that has maintainability through release after release after release. I call it eternally regenerative software administration. It is so awesome. And I think we should remember that and acknowledge it more often because the others that everyone mentioned seem to be the one that people think of first. But for me, it's always the regenerativity. Thank you. Okay. Just one more there and then we post on the left, the remaining for the question time. Just a brief one. First of all, we set standards. Standards in terms of documentation which documented standards which don't stink, they get updated. It's not that we drag for 17 years original documents which steal in that shape, right? And that's important. Okay, thank you. So I'm glad to have this small question time because you have done the talk for me. But not entirely. I have some answers which have not appeared yet and I would just like to go through them briefly. So one of the first reasons why I think Debian is better is because it has a focus on quality which is not there in all our distribution out there. So we have, as someone already said, package maintainers which are experts of the software they package. This interestingly enough was one of the initial goals set by Ian Marduk. So in Debian, unlike some other distribution, if you are a maintainer for a package, you most likely know this software. You do not know only the packaging aspect but you know the software. And that puts you in a better position to fix the software and more importantly to contribute back your work upstream to contribute to the free software world in general. A second reason why I think we have an important focus on quality is that we don't have any second class packages. So in principle, all packages in Debian Archive are subject to the same quality constraint and to the same quality requirements. That's not always true in practice because we know we have orphan packages but the goal we set for all packages, it is the same. Third point, our motto we release when it's ready which is something which makes us release slower than other but still it means that for us the quality of the packages is not something that we are ready to trade with some specific data or with some specific external requirement. This is something quite peculiar in the context of distribution nowadays. And I think that our user are very well aware of that so this is just a couple of recent feedback I got after becoming DPL talking with big companies, talking with part of the government which want to switch to the free software. I got feedback like we chose Debian because we need to rebuild packages because we need to change them and that's actually the essence of free software and Debian is the only one where we find packages that do not fail to build from sources constantly and this for them was really important and the second piece of feedback that I get is something like we choose that distribution Debian based which is a commercial distribution because we need some commercial guarantees but we choose that and not another commercial distribution because we trust Debian packages and we know they are based on Debian packages so we chose that instead of that other. More generally there are lots of technical reasons for which people prefer Debian so I made a quick experiment on Identica I kind of put out a meme saying why do you think Debian is better than others and I got tons of technical reasons number of ports, stability it's running anywhere people like the testing suite, the policy it's huge, we have a lot of packages and there are a lot of technical reasons we might agree upon. I don't think these are actually the most important parts of Debian, I think there are some more profound philosophical reasons for which Debian is relevant in the free software world of today is how much we care about freedom so Debian is based on some firm principles which bind together users and developers by the means of social contact so we write down very clearly what are our goals what are our commitments and we bound ourselves to respect them in front of the users in essence that means that we have been promoting the culture of free software since 1993 and that we have users which are aware of that users trust our choices in terms of free software and believe that our choices are for the greater good of free software second point about freedom is that I like to think of Debian as a distribution which is free the bottom up what does it mean? that means that we are free in the software we distribute and that starting from squeeze will be including firmware finally no GR for deciding that firmware is an exception at the last minute thanks to the amazing work of the kernel team but also it means that we are free in our infrastructure we do not have any nobody in Debian would accept to propose non-free services that developers have to use to do their packaging work and nobody will accept among our users to have to use some non-free web services in a way that integrates with the distribution so we really did a good job in pushing the culture of free software and our users are very well aware of that second point what is still on the philosophical level is that we are independent so in the so called blogosphere there have been a lot of discussion recently distinguishing corporate from non-corporate distribution and Debian is an independent distribution what does it mean? that means that there is no single company which is behind us which gives us infrastructure which gives us money which gives us hardware we live up on the donation of a lot of companies but a lot of individuals that gives us money and hardware and besides that we only have a gift economy and that puts us in a relatively independent position from money and from choices which comes from corporations and people trust that our choices are not kind of driven by commercial needs by money needs third and last point on the philosophical level is that Debian is better in decision making now I understand that we do not all agree that we are kind of completely okay at taking decisions but at least on paper we are quite good at that so if you look at our constitution so if you look at our constitution there are two very clear principles the first one is what I call doocracy even if it is not called that way in the constitution and essentially it says that anyone which is working on a specific task and it is in charge to work on a specific task it's free to take any decision regarding his own work so if you are a package maintainer you are fully entitled to take all decision on that package and either if they are technical or if they are non-technical so second point democracy so we have doocracy as the default so decision are taken by who do the job and when that does not work or when we do want to override the doocracy we have completed democratic process in which collectively we can take any kind of decision taken together the two points mean that reputation in debian follows work and that we don't have any benevolent detector we don't have any oligarchy some people claims we do not have any cabal too and essentially that means that we have no decision which are imposed from the outside the decision are all our fault if you do something good and all our merit if you do something good ok so this for me is what defines the specific role of debian in the distribution ecosystem of today and that for me also mean that we have a kind of responsibility so we have the responsibility to ensure that debian shall live long and prosper because if we one day to the other we disappear the free software world I think will suffer from our absence so what should we do to ensure that debian will live long and prosper well we should fix some problem that we do have in our project there are values I thought that how to list the problem we have there are value possibility to do that the way I chose to do that in this talk is to start from the lack of manpower so the lack of manpower is something that if you ask anything in debian what is their problem one of the thing they will say ok we don't have enough manpower we need more manpower and we are starting to I think believe that that's why other people do things better than us because they have more manpower than we do so I ask myself is it really the case and my answer is twofold well it is surely the case so we could definitely use more manpower basically everywhere in debian nevertheless we should also put into better use the manpower that we do have and which in some way we tend to waste so I go briefly about how I think we should put into better use the manpower we have and our first way to do that is to change our culture with respect to releases so right now we have a kind of culture in which releasing is the job of the release team and of a few people which do NMUs and that is something we really need to change because we cannot go on and release that way for much longer we need to realize that releasing is a shared responsibility so as a package maintainer your first task is to ensure that your package is in good shape and that it has no RC bugs and that in generally follow all the guidelines for packaging we have in debian but when you are done with that it is also your responsibility to ensure that other packages in the archive have no RC bugs because it's not tenable that only the release team should care about fixing the RC bugs in 30,000 packages in the archive that simply does not work and the way to go forward and relax and change this belief is simply to use NMUs more do NMUs welcome NMUs so my personal experience is what the initiative I called RCBW a release critical bug of the week I just tried to do one NMU per day but the point was not really the duration and the point was not even fixing as many RC bugs as possible the point was experimenting with how much people welcome or don't welcome NMUs and I was impressed by the result so I did something like 180 NMUs and I got no complaint nobody complained about a single NMU although I got a couple of override of uploads and I get a lot of thank you messages so that is impressive for me because I've always thought that we are kind of too attached to our packages we kind of don't like our package of yours and I was really impressed to see that actually people welcome that that people see that you are trying to help their work when they are overworked and we don't have time to fix the specification and even more importantly we had a buff on this topic yesterday and everyone who participated in this buff agreed with this interpretation so anyone which was at the buff and which has done NMUs reported the same experience people do welcome NMUs and NMUs as a way to collaborate and that's I think the first step to release in a more shared way second way to use better the manpower that we do have is taking responsibility so lack of manpower is something that I've been hearing whining about in volunteering everywhere so when I've been doing volunteering even in non-computer related stuff everyone cries for the lack of manpower but we have an advantage in other volunteering realities we have computers, we are geeks, we are hackers and with computers a single motivated individual can do wonder so if you take one person which is motivated and capable in one night of hacking can solve a longer standing problem which is in Damian so I know that it's easier to rent on lists about core teams which are not doing their job properly but it's even if it's more difficult it's more and more productive to actually propose yourself to join that team I don't have the feeling that we are anymore at the point where core teams are close identities which do not accept members what I do see is rather a lot of core teams or non-core teams looking for volunteers and not finding volunteers so think about it try to say okay I'm ready to do this experiment I want to be part of that team and just show that you are capable of doing the job you really can and if you look at the core teams in Damian you will find out that we have some relatively young DD we joined some important teams and started doing some wonderful job there and that's something you can do too we all can do that third and last point about using in a better way the manpower we do have is trying to reduce the inertia of the project so folklore says that large changes are impossible in Damian that we have too much inertia on how we take decisions this is true when you look from the outside but it's something that is easy changeable it is enough to realize that in a project as big as Damian you simply will never have unanimity in a project with 1,000 developers and in which the Damian Development mailing list is open for posting to anyone out there in the world who want to say his opinion on Damian you will never have unanimity so looking for consensus is good when you are doing a big change which can affect a lot of packages we will never have unanimity because we will never have that on any single subject one of the most funny question I've been asking the first interviews after becoming DPL it was something like how do you think about being the DPL in a project which have 1,000 developers and 10,000 opinions this is true so that simply means that we will never have unanimity so look for consensus but at some point it is the one who is ready to do the job and decide so if I can like paraphrasing Linus I would like to say talk is cheap show me the NMUs we find our way decision which is kind of prominent and someone has just to start doing the job and so this is it for what concern using better than Empower we do have and if I had to summarize it I would use this quote from Sam that comes from Sam which said be bold and this is true we have computers if you do mistake most of them we can undo them so it just take you to go ahead and do the work okay so this what I had to say about using better what we have so how do we reach out to find more manpower so a first way to to have more manpower is to be able to retain the offer of help that we get so that it's very very much needed to have a welcoming community so look at what this distro watch to say about Debian you will find something like discussions on developer mailing list and blogs can be uncultured at times and it is full glory that to join Debian you need to grow a thick skin so you need to be able to withstand steps from people which are not related to your technical work you need to be able to withstand a community in which people are grumpy in which people hardly acknowledge the good you did and just look at the bad you did people sometimes fail to give credit people rarely thank other people we see insults on mailing list sometimes so this is simply not acceptable not because we want to have a happy family but because this way we are losing manpower every time you do one of these things you are probably killing a potential contributor maybe not the one to which you are applying but someone else which is lurking which is looking at the exchange on the mailing list and thinks you know what I don't think I want to be part of this so I simply don't buy the argument that the requirement of having a thick skin is a guarantee of hacking abilities it is not it is just a requirement of having something which has a thick skin and which will probably perpetrate the need of having a thick skin to stay in Debian so for me the requirement of having a thick skin is just a way to lose potential contributors so another way to get more manpower is getting more users so recently I've been reading on mailing list arguments like we don't need more users we don't need more bug reports we just want full grown experts from day one okay the last one is for me but that's not the way it works in free software free software for me is participation and participation starts with some initial involvement and involvement is something that goes bit by bit starting from the first bug report so if we want to have more manpower we should be also be more welcome into noobs that doesn't mean that we should accept bogus bug report but we need it to be kind of tolerant from people which are starting and which potentially can become some very valuable Debian hacker like one year later as a bonus point on this we want to be the universal operating system well the universal operating system is everywhere of every kind okay last point on how to get more manpower for me is working more with derivatives so we saw that we have kind of more than 100 derivatives out there some of them has more than 10 times the user base of Debian and in an ideal free software world that means that every contributor of a derivative distribution is also a Debian contributor but in that ideal free software world we also have that every Debian patch is pushed upstream so I think we agree that not every Debian, sorry I think that we agree that it is not yet the case that every contributor derivative is also a contributor of Debian because sometimes the work doesn't get forwarded to us but it's also the case that it is not true that everything we do in Debian gets forwarded upstream so I think we should work better in both ways and as a first way to do that I've tried to reaching out about derivatives and explaining to them what we do and I was impressed by the result people in derivatives distribution care about Debian, care about our free software principle and are simply kind of scared of us so it's just enough to show really I mean I get to reply like are you sure you want us to work for you so it is really easy just a way to go there and get other people to know you and as a first step I'm very happy to have the initiative of the derivatives fund desk we just started recently for the moment it has a wiki page and a couple of contact points and that is the contact point you can give to any developer of a Debian based distribution for if he wants to contribute his work back to Debian so this is the place where we can reach out to us and say okay I have this kind of work I would like it to be in Debian because I care in free software and how it works how can I do to put into Debian who should I contact so if you want to join this list this is a place where we can really attract more manpower from our derivative distribution and improving the way patches flows between us and them okay so this was equal on let's say some of the outstanding problem that I see in Debian I just have a couple of final slides to throw out some discussion subject that we would like to discuss with you later on so the first potential direction I think we should think about is quality so Debian started with the focus on quality it still has a focus on quality but we can't be happy for the status quo quality doesn't wait for us so other people are starting to focus more and more on quality Lucas does not only rebuild packages for Debian it rebuilds packages also for other distributions so we cannot hope to have enough quality just because we care about FTBFS quality is something we should try to get more and more every day and the potential direction in that is having more testing but with testing here I do not mean only the PU part stuff so not only on the package itself but also in the software so having more unique test suites for the software repackage and suites which are not only runnable at the end of the build process but we should be able to find a way to test packages as they are used by users so sometime ago we had some proposal to do that in DPKG but that's really a direction we should take and that ultimately will mean more RC bugs and more RC bug fixing so second potential direction so Joy will probably kill me for this slide so I think it's the time to start having a serious discussion about a proposal called CUT and the reason is that it is a fact that we have a lot of users which do love our release cycle but it is also a fact that some users don't and as a consequence of this too we have a lot of users which are using the testing distribution which initially was not meant to be used by users but in fact it's something which is really peculiar it's something that it is not there in any other distribution out there it is a mix of recent software and tested packages which is really really peculiar so the question is do we need or want to bless that suite I'm not saying we do I'm saying that we need to discuss that because it's a potential improvement of Debian which will be quite peculiar and quite interesting for a lot of users out there so if you're interested in that here is a proposal of Joy there will be a buff here but the timing is completely wrong so Daniel will say when it is the actual buff which is Friday at 5pm in inter-school thanks so the buff will be actually we change it because people which are not at the conference would like to participate and there will be so video streaming which is not possible to have in this room final slide on another direction I think we should take known package known developer project members so this is a quote from my platform is there just because a lot of people seems to have liked it and it says the best operating system is mainly but not only made of software it is also made of translations, graphics, music etc etc etc so what those are all software okay okay documentation is software okay it is made by a more varied kind of software than what we take today so we are already benefiting from a lot of work of these people we have a lot of people working on some ancillary part around the Debian operating system also people doing marketing which is hardly software I found one so we are already benefiting from work of these people and I think we should reward them more so something which is kind of very hard to do because it is hard to mix it properly with the bureaucracy which is at the basis of Debian but we need to think about how to have project members which are known packages so that's it for me and I would like to add your thoughts on all this matter thanks are you going to argue that marketing is software? no no not that allow me just for a second to stick my neck out and put together a straw man for you one of your arguments up there was that in order to get more manpower we need to have more users because developers don't start out as full developers they start out as users and progress and gain skills now you also point out that there are derivatives of Debian today that have 10 times as many users as Debian and I've observed the trend that a number of people who start out as users of those derivatives go on to become developers in those derivatives and then move on as well to be contributors in Debian as well when you couple this with the fact that Debian today does not have the infrastructure to accommodate orders of magnitude more bug reports from users sent to our BTS does it make sense to offload that particular task to the derivatives or is it something that Debian should focus on directly okay that's a pretty interesting question so let me point out that what you said in the beginning it's already happening so for instance we already have an important flow of developers in Debian which came from Ubuntu they started to know Ubuntu they became user of Ubuntu, developer of Ubuntu I believe at some point they become more interested in the relation between Ubuntu and Debian and they end up being developers in Debian this is a service which derivatives and for sure Ubuntu is the most important one among them in that respect it's already offering this service to Debian so I don't think we should have as a goal to offload users to derivative distribution I mean if it happens okay but I don't think we should abide to our we should reject our responsibility of having direct users for this reason so you talked about teams needing manpower and every team wishing for more, teams wishing for more members but not having volunteers I haven't looked at the whole DevCon schedule yet but is there somewhere where teams can come up in front of us and say I want help it's really not that hard to join us please join me and wherever you can hear about all the work, all the teams that need people so I smell like this is kind of subliminal advertisement of open hatch right so yes I completely agree and I think we are so another argument to get more manpower is surely communicate better so communicate better not only in what we are because I don't think we are doing yet a particular good job in pushing out our values and but we are I think we are improving significantly but also communicate more about what we need and in fact I think it's a kind of a meta problem so because we also need in Debian people which is able to do this kind of communication and I don't think we have much of those people in Debian yet so there is a kind of a chicken and egg problem sorry he volunteers to do it talk with him afterwards okay I do there is a question here from Matt hi I'm Matt stand up hi I'm Matt Zimmerman I had a comment on releasing when it's ready I think it's a great ideal for Debian to have and it's not right for every project not right for every user but having that option and having a project that's standing up for that I think it's a great thing for free software I think though when we talk about releasing when Debian is ready we can do a better job of defining what that means when is Debian ready we say it's ready when there aren't any RC bugs for example so when no packages are flawed in a fundamental way and I think that's a little bit it's looking at a little bit in the wrong direction rather it should be considered ready when Debian is suitable to be used for its intended purpose it should be defined in terms of what you can do with it Debian is ready when you can do all of these things with it it's more of a user centric definition rather than saying it's ready based on a mathematical formula of how many bugs there are so I think by turning that around we could change the dynamic of releasing when it's ready it wouldn't seem quite as cumbersome as it is if it meant something more specific yeah so I have the impression that yeah I mean you alright it seems something cumbersome at the moment something difficult to achieve it can be defined in other ways but I have the impression that the one you suggested a bit more blurry so you will then need someone deciding whether you have met the criteria you put forward and that is on paper so go ahead yeah I'm someone that has used Debian for quite a while and I do develop open source software I've never participated and I think one thing that would greatly increase participation is a hello world if Debian had the equivalent of a hello world for participation in terms of okay let's say that you want to create your own binary package or your own source package and just have a path do this do this do this all the way to here is the joke package that actually makes it up and you can actually see your joke package like with Wikipedia you know there's very little barrier to entry you can just do your thing and oh my god you're live like you can see it right there and it's very exciting if there were a way to go all the way from start to finish with a pretty well paved path where it's not like well go to the you know get a mentor oh geez what's a men now I'm going to join that now I'm going to do this and here's the file system hierarchy sprawling document here's the you know it gets exhausting so if there were a nice cleaner way to do that hello world is good just a comment on that I think we used to have a hello package I have no idea if it exists any longer but okay and beside that so what is really good is a packaging guide which comes from Ubuntu actually and which you have been discussing on the Debian derivatives mailing list to promote as more general like Debian derivative packaging guide and that's kind of good and I've heard that there are also work in progress at this conference to actually improve the our current packaging document I think what we need is kind of the experience of someone outside because we are all people that know how to do the packaging so we are not any longer really good at looking if a document for beginning packaging for scratch is good or not so this is something that for instance someone like you can contribute to so letting us know whether what we have right now is good or not and how to improve it so I've got the five minutes time anything else? Steve? Hi yeah Steve McIntyre just a quick question I guess not so much for you Zach but for the rest of the audience can we have a quick show of hands who's at the first Debian conference this year wow and how many people do we have here who are just going through new maintainer or just become new Debian developers or Debian maintainers cool okay thanks for coming along and volunteering really echoing what Zach was saying earlier I said something about this last year as well please don't be scared of getting involved in these scary core teams there's lots of people out there who would love to talk to you would love to share beer with you and have you help them with their work don't be intimidated there's lots and lots of cool stuff that you can do to make a difference yeah thanks for this comment Steve there's one question here I believe it will be the last one Hi I'm CJ in addition to more manpower we need a lot more women power so just in case that was not a sexist remark English word for available power so thank you I enjoy that


Everybody forced here. I'm ripping 2022 tops Star Wars Chrome sapphire edition five box number one random pack style So before we do the random I have the boxes here what it's gonna happen Let's be box one I'm gonna pull the cards out just as they lay and set them down just like that that top pack where it sits is gonna be one And it's gonna go down to eight no matter how it's facing up or down I forget that's how we're gonna go and then so one through eight is here and then nine through sixteen and so on I'm gonna go left to right. That's how it's gonna be. We know which pack is which already Let's do the random now or randomize the names and the pack numbers one through forty each the same amount of times put Them side-by-side. That's how we know who has what Good luck everybody We're gonna go six times on our random that is a five and a one five and a one six times one two three four five and six Got Christopher L then to Daniel w e and six times on the pack numbers one two three four five and six Pack seven down to pack 30 who's got what here move it all over Scroll down here.  I'll come out Only 40 Christopher L 7 to on with one Ben H 23 Daniel w ice 37 to Kuyah 3 Jimmy C 38 Michael T 33 Brandon a 36 Brian s 25 Daniel w e 10 Brian s 19 Simon H 4 Daniel w e 21 Michael T 6 Charles B 17 Andy s 15 Charles B 28 Said Andy. It's already s 15 Charles B 28 Kevin P 5 Charles B 29 Kevin P 26 see Chan 31 sol C 27 Ben H 24 Jimmy C 35 Alex P 14 Simon H 22 Brian V 40 Brent M 32 Krista 18 Chris D 8 Mike K 11 Human 34 Charles B 39 Kevin H 20 Simon s 12 Matt P 16 Brandon a 2 Kevin H 13 Brent M 9 and Daniel w e with 30 We copy and put those into the Results post here. I'll post it get you a link in chat so you can Check it again. If you need to I know I went quickly through that. Let's go ahead and get started now I will not be able to slow down enough to call out every single person's name and every pack here I'm just gonna make sure I'm calling out the right number as we go along Count by eight count by eight. It's all I gotta do so simple, but it's not All right packs one through eight again I'm gonna pull them out just as they lay in the box You get the facing up perfect just like that Pack one at the top pack eight to the bottom there pack one Good luck. Everyone see some fire here. I'm not gonna be able to call out every single one of these a lot of text on these pack two Call out some of the nicer ones, of course though rescue a nice Vader in the layer there Hawn and Chewie Pack three Get some color in pack three here C3 peel and Luke Chewie and Hawn The light green is 75 is out Guinness has been could no be Nice card there. That was number three number four Mark Hamill in the control room Chewbacca poses his prisoner on to number five Pack six have one more color coming in this in this box eat Cantina meeting there Grand Moff Tarkin nice Leia card C3 peel and Leia Number seven Leia Oversea over observes the battle. Oh aqua coming up here for a pack seven Vader strangles the rebel and aqua as a Millennium Falcon speeds through space 22 of 99 Nice color there pack seven and all these will get top-loaded and pack eight to conclude box one here R2 left behind 3po there and R2 and see 3po sup Bradley One sec guys Here we go nine through sixteen in this box now number nine rebel pilot repairs for the raid and aqua in the first pack here number nine in Is the incredible see 3po 59 of 99 and a Leia in 3po there Nice number 10 now the biggest here for the personal last night was a gold Luke to 15 very very big card Cantina meeting Vader the strangles the rebel 11 Tarkin Leia observes the battle 12 R2 left behind got a green coming up the green is to 50 it is Mark Hamill in the control room Nice Hamill R2 and see 3po Daniel there's Daniel W. E. three times Daniel W. E. has three spots. He has 10 21 and 30 Daniel Wi has 37 That was that last one Pack 13 hiding lame Falcon Is a princess or no rebel leaders wonder their fate 14 now Force be with you stormtroopers Tuscan Raider 15 Harrison Ford is Han Solo ice 3po Governor of Imperial Outlands and Number 16 now we've got an orange three colors in this box It is that is really nice 3po Ben and Luke 15 of 25 Congrats pack 16 Matt P. Congrats Matt Good stuff there and number 16. Congrats again Matt Get that one mad for you And then the last one here was a the chasm. All right 17 through 24 I can count by 8 I guess 17 has a light green keep cushing there to 75 the Millennium Falcon very nice Last Star War love that card. Who will win the last Star War? 18 solo blast a stormtrooper The lightsaber guards 19 now Yes, every card's being top-loaded elevator and a soldier 19 aqua 1099 The victors receive their reward 20 21 this 21. Sorry 21 Princess Leia.  They're a nice one there for Ben H with pack 23. There we go card number one Chewie and number 24 Magda base Luke And Ben H also has 24 here. So I should have this one. There's a fan for Or the Wookie a gold So 15 Carrie Fisher and Mark Hamel Ben H back-to-back packs big cards Wow, dude Card number 65 gold 5 of 15 Carrie Fisher and Mark Hamel and space pirate Han Solo man Great packs there. All right Go moving on 25 Luke Skywalker base Brian s pack 25 Break just heated up big time Okay, put in a mag Wookie Chewbacca Ben with the lightsaber 26 aqua coming up now. It is to 99. It is a mighty explosion 27 destroy's imperial ship Insighting the Death Star 28 now It's your tackler battle Wookie 29 Loot prepares to swing across the chasm. We've got one of the light greens To 75 is the droids tried to rescue Luke 43 is 75 and space pirate Han Solo nice 31 third. Oh, yeah, 32 Victor's received the rewards plenty of falcon flies through space aliguinis 31 31 right here 3PO explosion Excuse me funny falcon 32 3PO Heroism R2-D2 Rebel Starship and droids try to rescue Luke Last box. Thanks everybody for joining One more of these up next with plenty of spots guys.  All right number 33 Very nice Horrified Luke sees his family killed You say very nice kind of a it's not that nice I guess Luke in disguise nice card 34 here Princess Leia captured We got an orange The orange Wow back to back the same card this time. It's orange dough Luke Skywalker on Tatooine the 74 nice Luke And then 3PO Ben and Luke 35 3PO fools the guards 2D2 Tuscan Raiders You laughing rod That's 36 now nice Han and Chewie 37 Sol and True prepare to leave Luke Got they light green as 75 R2-D2 on the Rebel Starship Han and Chewie shoot it out 38 daring rescue Chewie and Han Solo 39 C3PO and Luke our camel control room Vader and Leia and 40 battle outer space Chewbacca as a prisoner The last card is the droids on Tatooine That'll do it. Thanks again everybody and every single one of those cards will be top-loaded a few of them will be magged We do appreciate it one more of those coming up next


Hey guys, my name is Damian. I'm here to talk about an article written by Christina Tran called The Ever So Popular Coffee Date. I've been on a few coffee dates. I've taken some girls, you know, either friends or somebody I wanted to date and they go pretty well, but there are some downsides to the date, but there are also some positives. But let's talk about it a little bit more. One of the problems is it just lacks creativity.  Maybe one thing you guys can do is maybe go bowling or maybe go to a local spot that people are hanging out at. A good place where you can have a nice little conversation, but then also something that maybe she wouldn't be expecting or maybe he wouldn't be expecting too much. Now, it would strain away from going to movies just because the whole time you're in the movie, you can't really talk. You're kind of just there to watch the movie and that's not good for a first date. You really want to get that connection and really talk to the person, get to know the person a little bit more. Another problem with a coffee date is just it's not a good environment for a first date. Coffee shops are usually very relaxed, very mellow, and you know, usually people that go to coffee shops like to go study with their friends and stuff for tests in school and that's not a good place for a first date. One solution to this is maybe take her ice skating or bowling. Listen to what she says. Maybe she's been wanting to go somewhere recently and then this would be the perfect opportunity to take her. And one final thing that's really wrong with a coffee date is that it's just too cheap. A lot of girls spend many hours doing their makeup, getting ready for the date and guys, I know it's a good cheap spot to go to, but if they're taking that much time out of their day to do their makeup, the least you can do is spend a little bit extra money. Take time to hear what she says. Maybe she's been really wanting to go to a place and this could be the perfect chance to take her and make a good first impression on your date. Don't forget to like and subscribe and the article I talked about will be in the description down below. Don't forget to check out the Psych2Go website and also follow them on Tumblr, Twitter, and Facebook. My name has been Damian. I hope to see you guys in the next video. Bye.


Erin, why did you opt to go with Garcia as an opener instead of a just traditional starter tonight? Just because they're so good at their rosters built to take advantage of the platoon advantage. So it felt like I was going to go to J pretty early and aggressively as long as they went with the heavy lefty lineup, and that was the reason. Was there anything that Garcia could have done to remain in that game, or was it simply based on the lineup that Cash put out there? It was a little lineup based, but you know, and then, you know, kind of labor a little bit through that first inning, as on the verge of getting out of it, though, with two strikes there with a Rosarena when he gets them, clips them. But no, that was the plan all along to, we're going to go short with him knowing we would have Davey available, you know, later in the series if need be to. And what did you think was going on with Happy to not seem particularly sharp for him? Yeah, another, you know, like Davey in the first, the Zunino two strike two out. Looked like he made a decent pitch. I don't think he got it up as much as he wanted to, but Zunino put a pretty good swing on it to give him the two run homer there with two outs and two strikes, you know, got clipped a little bit with a couple of righties, you know, generated for the most part some weak contact with the lefties. Maybe not just quite the life on the heater at times.


Welcome to WTDC 17 here in Buenos Aires, Argentina, where I'm very pleased to be joining the studio today, Mr. Shola Taylor, who's Secretary-General of the Commonwealth Telecommunications Organization. Shola, great to see you in the studio. Thank you very much, as usual. I'd like to start off by asking you a little bit about the theme for this year's conference. WTDC 17 is ICTs for SDGs. How does this theme resonate with your members? Well, one of the reasons why we're here at CTO is because the theme resonates very deeply with our members. As a matter of fact, the 2030 sustainable agenda was one of the factors that drove the strategic plan of the CTO. We actually use that as one of the inputs, as we find it very valuable. Our members have seen the value in the use of ICTs in applications, in agriculture, in education, in health, and constantly, when in touch with them, in responding to their needs. But the important thing is that we see the theme as responding to the needs of our members. So that's very important for us. Now, you represent a wide spectrum of members, both in developing countries. What specific challenges are your members facing in integrating ICTs into their development agenda? Well, the Commonwealth of Nations comprises 52 countries and with a population of 2.2 billion. Now, 60% of these are less than 30. Basically, almost half do not have access to internet. So one of the big challenges we have is how do we get all of these half a billion, billion people who have to be connected to the internet. One is investments. We did investment very badly. Secondly, we also need good regulations. We need good policies. We need policies to drive the investments, universal service frameworks. We've had it in many countries, but are they working? We are trying to see how we can review these frameworks to better meet the needs of our members. And we're constantly looking at the programs we have. We have what we call a member action plan, whereby for each country, we actually look at what the needs are because the needs vary from country to country. And we try to respond to the very needs of our member countries. And what regulatory and policy measures do you think needs to be put in place in order to bring connectivity on a global scale that's over the next billion? Well, the challenge for us is, first of all, to understand the needs of our members. The needs vary from country to country. But what we see, most important thing, is that we need to have policies that addresses the needs of our members. Issues like cyber security, for example. Issues like cyber crime, cyber standards. Our countries want to develop broadband. They need to have the right speed. What speed do they have? What speed do they need to provide? How do they need to define the speeds for hospitals, health clinics, educational institutions, rural populace as a whole? So we are constantly looking at the policies, regulations in countries, spectrum, for example. How do you ensure that our countries use the spectrum efficiently? Quality of service. We need to ensure that the populace have access to good quality of service. And all those kind of issues, environments, how do we respond to the issue of climate change? How does ICC help? So constantly we are looking at all these issues and depending on the countries, we provide advice on policy and regulatory issues. Finally, at the end of this conference, what concrete steps do you hope will be taken? Well, for us, it's important that ITU should focus, ITVD in particular, should focus on its mandate. We want to see concrete plans. We want to see actions which also resonate with the kind of thing that we're doing. We have a very strong partnership with the ITU. So we want to see outcomes that will define new partnerships, to spend the current partnerships, to ensure that the programs we have in the countries are actually responding to the needs of the countries. Sheldon Taylor, thank you very much indeed. Thank you very much. Thank you.


Anyways, hi, I'm Contra, and let's talk about some build systems. So this is me. You can follow me at any of these links. My name is Contra. I co-founded a company called Fractal, and we are based out of Phoenix. So at Fractal we spend a lot of time on open source, and we currently have like 250 projects on GitHub to show for that policy, so we're really invested in it. We believe that open source is not only good for the community, but also good for business. So we try to stay true to that message. Before we get really deep, I'd like to bridge the gap between people who are and aren't familiar with build systems. Basically, build systems are tools that help automate your workflow and let you focus on what really matters, because at the end of the day we just want to write code.  So compiling, minifying, and bundling any other word that ends in ing, they're all within the domain of a build system.  I know that I wouldn't be the same developer if I didn't have build tools to back me up and help me save time. To be super blunt about it, though, the current batch of tooling is just not cutting it. They don't work well, they waste time, and they cause immense frustration. The problems we need tooling for are fundamentally different than the problems of yesteryear that these tools were created to solve. We're simply using the wrong language to communicate the job that needs to be done. So we have new problems. We need to come up with a new solution. First let's define what this solution should do. It needs to read in some files, transform them a few times, and then save them. Seems simple enough. Now when I ask people to envision that process, we usually end up with something like this. In this example, we're doing two transforms. First we pass multiple files to concat, concat outputs one new file. That sunglass touch at the end. That new file gets passed to a minifier, which then outputs the modified file.  We essentially drop the input in at the top, let it fall through the transformations, and then save the result. This idea probably sounds familiar. It's kind of like basic functional programming. Let's compare that to our current day tools. The primary abstraction in these systems is a task, which describes the input, transformation, and the output. This means each transformation is logically separated from all of the other ones, and your file system becomes mutable state in between them. This mutable state is used to communicate information between these tasks, and basically it slows everything down by radically increasing the amount of IO that's getting completed. It's slow, it's confusing, and it creates a hell constructed entirely of temp folders. So these are some different tools that follow that model. The IO costs that come with the task-based system increase not only with the number of files, but also with the number of transforms. This is super frustrating when you use something like live reload, and your reloads aren't exactly live anymore. You end up waiting like 30 seconds for some results to show up on a page, and it becomes kind of ridiculous. These flaws are a symptom that we're just using the wrong abstraction here. The dialect of a build system should be molded around the way that our brains envision the problem. We still want tasks to logically separate sets of operations, but a lower level abstraction is needed to give us that granular control over transformations. It's clear that a file pipeline can help us fill this gap and solve the problem. So instead of inventing our own data pipeline system, we can reuse an existing one, streams. Streams are a dependable way to compose large systems out of small components that do one thing well. They help separate concerns by restricting the implementation surface area into a consistent interface, which can then be reused anywhere. You simply plug the output of one stream to the input of another and then let the data flow. Here's a great quote by Doug McIlroy. We should have some ways of connecting programs like garden hose, screw in another segment when it becomes necessary to massage data in another way. So in this example, we have A pipe to B, pipe to C, pipe to D. And in Unix, streams are implemented by the shell with the pipe operator. You guys are probably familiar with this. In Node, streams are implemented by a built-in stream module and you chain them by calling .pipe. Node streams have this unique benefit of JavaScript's flexible type system. It means you can have a stream of just about anything. That could be objects, strings, buffers, numbers, functions, whatever you want. And this is super cool because you can model transformations on any type of data, not just text. So we've now lifted that limitation and I think that makes streams in Node super cool. So this becomes really useful when we start thinking about what exactly does a file consist of? The file objects we pass around are more than just text these days. We have metadata like file attributes, which describe permissions, modification times and other junk, source maps, which are used to keep track of changes and keep your code debuggable, ASTs, which prevent CPU waste from reparsing the same files over and over. Like if you uglify something and then you want to go remove console.logs, each tool is going to parse that AST twice. So you're just wasting CPU there. Whereas if you have this file pipeline, they can reuse that same AST and there's no need to reparse it. So we can finally decouple these individual transforms by passing metadata around in these streams. So after being completely unsatisfied with the current batch of build tools, I decided to create Gulp. Gulp has existed for less than a year and it's already one of the most popular projects on GitHub. We currently have somewhere around 800 plugins. So anything you want to do, you can pretty much do it already. I'm also pleased to announce that just yesterday we passed Grunt and GitHub stars. We have somewhere like 8,300 now. So we're now like the most popular build system on GitHub. Super cool. I'm really excited about that. The next version of Grunt is actually being rewritten to use Gulp under the hood. So that feels pretty good. We won there. So the main goal of this project is to provide a common interface around these highly modular pipeline transforms and have a friendly API to tie them all together. The common interface is simply a stream that takes a defined file object and possibly outputs a file object or maybe more file objects. It's completely up to the transform. As the benevolent dictator for life of this project, I make sure that things stick to this. All development of Gulp follows this ideology and we try to keep the API as simple and as node-like as possible to stay true to our catchphrase, which is, if you know node, you know Gulp. We also like to squeeze performance wherever possible. Globbing is lazy, tasks run in parallel, files are processed in parallel, and IO is the bare minimum needed to get the job done. So people have been benchmarking Gulp against other build systems for a really long time and we're always at the top of the list. I have never seen anything beat us in a benchmark. So we're like extremely proud to be able to say that Gulp is the fastest build system out there and those milliseconds really matter. I see tweets like this come in all day and let me tell you there's no better feeling than having people use your open source project and say stuff like this. I actually just added this slide like 30 seconds before I came up because somebody just tweeted this. So yeah, it feels good. I'm sure there's better feelings than this, but this is pretty cool too. Personally, this is why I like to do it. All the love feels really good, I have to say. So let's cover a few of the APIs you'll need to know to get going. First off, we have Gulp.task, which registers an asynchronous function with Gulp. After registering, you can call it from the CLI. In this example, if you wanted to call this, you would type Gulp do-stuff in the CLI and it would run your little function. Just to be clear, when I say asynchronous function, I mean we support a variety of different control float techniques, that being callbacks, you can return streams, promises. I think we just added support for like RxJS, you can use generators, anything you want to use, we're completely agnostic to it. So we don't try to have really a preference there. Next up, we have Gulp.src, and this is our input to the pipeline that we talked about. This is what actually reads the files from the disk. It takes in a glob and starts spitting out the files lazily as they're found. So this means that we don't do batching as stuff is picked up from the file system. It goes through your pipeline and then all the way out to your destination. When you're using library load, you'll start noticing changes immediately. Let's say you have 100 CSS files, you don't wait for all 100 for them to be processed. You start seeing changes immediately as they go through the pipeline. Finally, we have Gulp.dust, which is the output of the pipeline. When files are passed to this, it simply just writes them to a folder. What's cool about this is after the file is written, it gets re-emitted so you can continue the pipeline and add more transforms after that or maybe more outputs. So it's not necessarily one source, one output. It's one source or many sources to as many outputs or transforms as you want. So to put that all together, we come up with this sample task. Basically what this does is read in some JavaScript files, concatenate them into all.js, writes them to a build folder, then passes the file after it's been written to Uglify, renames it, adds .min to it, and then writes it to that same build folder. So at the end of this, we end up with two files, all.js and all.min.js. And what we actually did here is decrease the IO overhead two times because we're only reading in the files once, whereas in something like grunt, you would read them in twice to construct the unminified and then the minified. So my favorite thing about this is with the pipeline, you can immediately look at this and see the entire process that happens to a set of files. When you look at a grunt file, it's not readily apparent what sets of files you're actually dealing with. Every task is at the same level, so you kind of need to go through each one and see, okay, this writes to this folder, this reads from that folder, okay, what reads from this folder. And you have to construct the pipeline yourself by looking through and grokking that big JSON blob, whereas here, it's just right there. Concat, build, uglify, rename, build, done. So let's compare some real code here. We're gonna compare a task runner and a streaming build system with like a little demo project. In this file, we're gonna lint, concat, minify, and then run again if any of those files change. So this first file is a grunt file. Let me see if I can scroll this. Sorry, this is a big grunt file. So you can see it's pretty long. Like I said, everything is flat. We've got concat, uglify, jshint, watch. And then we have like this funky load npm tasks thing that loads in the modules and wires them up into the task system. And then we create a task called default and say do all these things when somebody runs the grunt command. So a couple of things to note here. Every task specifies input and output on the file system. So we see right here concat, source, give it a glob, test, give it an output JavaScript file. And then we see that this does the exact same thing. It reads what concat put out and then this is the output file there. Jshint, no output file here, but it also specifies those inputs. So what I dislike the most about grunt is that your build file is this funky JSON language that defines task and task options. Like I look at this and I just don't think that it looks good. To me, I am a programmer. I like to write code, not configuration. One other thing to note, each task is executed synchronously. So as you add more tasks, your build time is just gonna increase linearly, that's not good. So declarative configuration for a build seems completely wrong. I think trying to shoehorn this into a declarative language leads to a massive over configuration like what we just saw. The grunt file we looked at before was like the smallest grunt file I've ever seen. It was just the bare essentials to do a basic operation. When you start to add more stuff, it becomes super complex and you hit the wall of configuration where you end up with something like this. So basically what happens is you have two choices. You can start writing code to generate your configuration which defeats the whole purpose of having configuration or you end up with monstrosities like this where the config language tries to support every possible use case. Why? That's all I have to say about that. So to me, JavaScript is already this beautiful and expressive language.  I would rather be writing JavaScript than writing whatever this is. And just for reference, this is from Ant. If anybody's worked with Ant before, this specific example was from a Drupal build file. So this is the same thing as our grunt file that we covered earlier. No need to scroll here. It's only like ten lines of code. So you can see with Gulp, we use code instead of configuration. Couple things to note. Concat and Minify are in the same pipeline so the data's only read once. This is plain JavaScript. There's no custom language to learn so the learning curve is minimal. Like I said earlier, if you know Node, you know Gulp. The plugins are super simple and take few to no config options. We enforce this heavily actually. We have like this super strict set of guidelines that we tell plugin authors that they have to follow. And this makes sure that we keep high quality modular plugins and that we don't have people writing the same plugins over and over just because they didn't want to send a pull request. But we have like this blacklist file with like about 80 plugins in it that didn't follow these guidelines and we'll go open an issue there and say, hey, you need to follow these guidelines. Here's the exact thing that you broke. Like whatever, we're gonna add you the blacklist in a week if you don't fix it. And if they don't fix it, then they don't show up on our plugin page anymore. So I think that barrier to entry really kind of keeps the ecosystem clean. So my favorite thing is files and tasks are processed asynchronously. So more files and more tasks doesn't equal longer builds. You can add as many tasks as you want and it's not gonna increase the build time. Having no mutable state is really the secret sauce to solving all of these performance bottlenecks that afflict the task based systems. So I've seen many real world examples where Grunt was taking 30 seconds to build and a Gulp file can do it in 300 milliseconds. So that's like orders of magnitude faster. So removing mutable state to allow asynchronous execution is super, super important not only for a build system but also for applications. So what are some takeaways you can get out of this?  Streams are awesome and pipelines are pretty dope. Hopefully you've at least learned about the merits of streams. And I have a good document here. If you wanna learn more about streams, you can check out this stream handbook by Substack. I think that you'll be a better programmer just by learning about streams even if you never actually use them. You can never learn enough control flow techniques in my opinion. So for this talk, I put up a special link you can use to get shirts. We usually completely sell out in about ten minutes. So get one while they're still available. I think we're already half sold out somehow this got leaked. Yeah, they sell out really fast. They're hot shirts. I forgot to pack one, so I chose the closest thing that I have. Just whatever red shirt I brought with me. So I'm pretty bummed about that. But if you wanna get a shirt, there's the URL right there. Give you guys a second to take a picture of that. And that was my rant. I left a lot of time for Q&A if anybody has any questions. Hi, I'm a big fan of Gulp and I've been using it for most of my new projects now. And I love it. One pain point that I kind of keep running into is I use Browserify with Gulp. And I know the Gulp Browserify is on a blacklist. And there is a recipe on the Gulp document for how to do Browserify. But it kind of sucks because then you're forced to use Browserify and watchify to watch a change in cash and all that stuff. And then, so in my Gulp fight, there's all these beautiful Gulp watch tasks that are very standard for Gulp. And then you have this blob of Browserify config stuff that's really ugly. And now I am left to depend on watchify for watching my files. And sometimes that doesn't really work well. And so there's a lot of instances where my files are not being watched. And the changes are not being detected. So is there any talks or plans to make this better? Or is it just something that Browserify and watchify have to do? Yes, there are plans to make that better. So currently, the whole problem there is right when Gulp was released, we had somebody come out and make the worst plugin I've ever seen. It just didn't work. It was super buggy. So that was why that ended up on the blacklist. It's not because it's a bad idea or anything, just because the module that somebody published was, I mean, not to be mean or anything, but it wasn't any good. And that kind of goes back to the quality thing that I was talking about earlier. So while you can still use this module, we don't officially endorse it. If somebody opens an issue about it, we'll just tell them, no. We don't have anything to do with this. Don't use this. So we have this really long issue thread going regarding Browserify. And I detailed this. I don't have time to write it, but I left a blueprint basically if somebody wanted to write a good Gulp Browserify plugin, how they would go about doing that. So really, I'm just waiting for somebody who has the time to come in and take that blueprint and actually make the thing and publish it. And then we can get rid of that recipe, which is just a stop gap until somebody does that. So I am excited for when somebody actually publishes a good Browserify module, because we'll be able to tell people to use that. So that's coming soon, I think, though. I think a couple of people have kind of raised their hands as wanting to do it in that GitHub issue thread. So stay tuned. We'll tweet about it from the Gulp account.  So what are you recommending or seeing with RequireJS builds? So just to be clear, that isn't a top plugin. That list is unsorted. I think it's sorted alphabetically or something. So that's why AMD Optimize would be at the top. So that's in no way like an endorsement from us that it's our best plugin. I use Browserify personally, but I know that one of the pain points with Gulp is dealing with these third-party tools like RequireJS that want to handle their own I.O. So essentially, what we tell people to do is, OK, we can't really make a plugin to make this kind of fit our paradigm. So go and just use the RequireJS module directly. But some people have actually stepped up to the plate, like that AMD Optimize module, where they basically rewrote the RequireJS Optimizer using the Gulp philosophy. And you can pipe files in, and then you get an Optimize file out. And it works really great from what I hear. So if you're going to do AMD, definitely give that a try. I'm not sure how stable that is, since it's relatively new. But if that doesn't work, you can always just use the RequireJS module. Another feature that I'm not sure if you have plans for is that listing of tasks that are defined by Gulp. I think that when I'm writing the build tools for someone else to consume, instead of having them to open the Gulp file and look at other tasks and figure out what tasks do, having a way to, on from the command lines, do Gulp help for something, lists a task. I think Grunt had this feature, and I think that was one of the more useful ones, especially when you're interfacing with a new application. So I don't know if Gulp has that feature planned. Gulp 4. Gulp 4, it's coming. So we completely rewrote the whole task system for Gulp 4. We went away from what we have currently where you specify a function, and then you can specify an array of dependencies that get executed before that task. So if I say, OK, before JavaScript happens, and you have this clean task that needs to run that wipes the folder of any JavaScript files that were outputted in the last run, you would specify your JavaScript task and say, clean is a dependency. And then it would run it beforehand. But we kind of are going away from that model. That's kind of like an ant-like model, or more like Maven, I guess. So what we're doing instead is we have this new composable task system that we're using called Boc. And what that lets you do is just go back to using plain functions without dependency trees or graphs or whatever we have going on right now. Because it's overly complex, in my opinion. So what that lets you do is you'll be able to tack on description attributes to these functions that you register into the task system. And our command line tool we'll have in dash dash help, or I think it's dash dash tasks right now. The ability to, when you list out the whole tree of tasks, it'll show you the descriptions next to it. And any other meta information that you tack onto it. So it makes it completely flexible in that respect. Can I set that out? Gulp4, we said it was going to come out in May, and then it didn't come out in May soon. If it doesn't come out by 2015, I'll punch myself for that. Because it'll be out soon. It's really close. We were waiting on the source maps thing to be done. We have Gulp source maps, which is the best source maps out of any build tool. We were waiting for that to be done, which it's super stable now. Every plugin has it, basically. You can do 10 CSS things, and you have source maps the whole way through, which is insane. No other build system has ever done that before. So we were waiting for that to be done before we move forward. So we're really close. I'd say a month away if I had to give you a hard estimate. Yes? So can you talk a little bit more about how dependency management will work in Gulp4? Because I'm curious about that. I use, for example, cleaning tasks quite a bit. So how would you figure that out in this new system? Yeah, so one of the huge pain points right now with the task dependency system is that, for example, the clean task, like maybe you want to run the clean task before every single task that you have in your build file. Well, now you have to go and add that before every single task. Or you have to make these weird pseudo tasks that run it beforehand. And basically what people have started doing is writing modules that just let you run stuff in series because we run everything in parallel. So there's a module called Run Sequence that solves that. And it lets you specify nested arrays of how things should be executed. So what we did was take that idea and apply it in a more functional respect. So you can type, like, Gulp.series and then pass it Gulp.parallel with some functions in it and another Gulp.parallel with some functions in it. And it'll execute those two parallel sets in series. And you can nest those infinitely. So you can do some really cool stuff by combining those. I think not only is that cool for our task system, but just for asynchronous, control flow management in general, it's super cool. If you want a preview of that, github.com slash faded p-h-a-t-e-d slash bock b-a-c-h, like the composer. And that has some docs describing how the whole new task system works. Also there's a Gulp4 branch, if you're interested in that, on GitHub 4.0. Two quick questions. You mentioned that you contributed a lot of projects. I think you said, like, a few hundreds or something. What other interesting things have you guys worked on? So currently I'm working on an open source genetics analysis library called Genome.js. That's genomejs.com, if anybody's interested. And that's been super fun. That's just kind of a passion project of mine. I'm also working on a lot of WebRTC stuff for doing peer-to-peer video calls and encrypted data transfers and stuff like that. So that's two of the things I've mainly been invested in. We're also doing some work with doing smaller React components. So the React component ecosystem is super new. So it's kind of like this awesome Wild West where you come up with an idea for something cool. It's like Node when it first started.  You make a little React module for it. And then, oh, no one's ever done this before. I'll publish this. And now other people can use it. So we are starting to come out with a ton of stuff like that. I actually have this whole framework around WebRTC and React where you can just drop a call in at any point in the page or drop in video streams that are coming from someone else's webcam across the world. So React components, WebRTC, and genetics analysis stuff are kind of my main focuses right now. Then a second quick question. What was the most insane non-build system related use of Gulp that you've seen? Netflix has a pretty crazy Gulp file that they do a lot of non-build related stuff with. I know a lot of people use it for deployment. It's become pretty big for deployment, which was surprising because I didn't even think about that when I was making it. But it actually kind of makes sense. Like you're just streaming files to servers and setting stuff up. So I'm curious to explore that a little bit more and maybe flesh out how to possibly use Gulp as a deployment system because I think that's just super interesting. So yeah, I think deployment and just weird odds and ends stuff are the weirdest things I've seen people do with it. Sorry. So there's one thing I've been trying to figure out how to do better in Gulp that's been driving me nuts. And I've had people point me to a few different plugins, but none have really kind of got at this the way I want. So in my source.js file, I have some files that I want to remain as is.  So I might have an all directory or a feature to text directory with a bunch of different files. And currently, I'll have a concatenation task that'll drop all those subfolder things into a temporary file and pull them in later. But is there a better way to in one task? And this may be two in the weeds and we can talk later if it is. But is there a simple way to identify if it's in a sub directory, concatenate it. But if not, just pass it through the stream and don't. So I would recommend just writing some custom logic for that. If there's not a plugin already, just write a plugin. I think one of the greatest things about Gulp is that you can write a plugin and it ends up being like 10 lines of code or something. And it's super simple.  That's the whole thing. So I think that if you need custom logic like that, you can just write a little plugin that does it, publish it. Maybe somebody else will get some use from it. If you don't want to publish it, there's GulpTap, which is a module that just kind of lets you tap into a stream of files and do arbitrary logic in there. So you could possibly use that to kind of encapsulate that stuff that you want to do. Yeah, I'm actually playing around with that right now. If you have time after just like five minutes, I think I'm not wrapping my head around tap properly. So cool. Thanks, man. Cool.